[Inx] Qingy: GUI login
inx-one at optusnet.com.au
Sat Nov 22 07:21:18 PST 2008
On Sat, Nov 22, 2008 at 02:14:55PM +0700, David Kuntadi wrote:
> On Sat, Nov 22, 2008 at 2:04 PM, Karl Goetz <karl at kgoetz.id.au> wrote:
> > My random thought:
> > If inx wants to be CLI/no X based, does that include covering everything
> > up with framebuffer?
> > "No X" and "CLI" are different - afaik the projects always used them
> > interchangeably, but they are slightly different.
> Have you forgotten we have "links2 -g" ? It utilized Framebuffer.
This is an interesting discussion, and you make some good points,
So, true to form, I'm about to say why we aren't likely to go
all directfb and framebuffer-ish in INX... at least not right now. :)
First, directfb is dark voodoo. If you or someone else understands it,
please hack away... Directfb has probably caused me more sleepless
nights and fiddling about than anything else in INX :)
That said, I'm aware of qingy, and have actually run a couple of tests
with it. It's essentially a replacement for the "login" program - not
exactly the same as gdm, kdm, xdm or slim. Now, by default, the live CD
logs in automatically on all 6 tty virtual terminals. Since we don't
want 6 instances of qingy running on boot, we have a choice of
disabling automatic login or setting qingy up to only appear on tty1.
Of course a login manager is a bit pointless on a live CD, but it
might be useful on a hard drive install.
I made a different background picture just to see how it would look,
using the INX logo on a black background. It could be made to look
really good with a bit of theme hacking, but I'm not sure that the
degree of effort and time is justified (for me at least).
If someone in the team can come up with an interesting way to use it,
I'm not against it, but it isn't a priority for me personally at the
moment, since there are other things that need fixing and improving.
> If we could have firefox and office suite compiled using framebuffer,
> I believe INX would be the only choice for low end computers.
I do see your point - there are several ways of looking at the aims of
INX. On the one hand, I would like to make it slimmer than it is -
even a bare CLI disc built on ubuntu-standard makes an iso of over 120
MB, so it isn't easy to do this without for example removing man
pages, going back to vim-tiny, and so on.
Because of the automatic logins, which I think are a Good Thing for
making people aware that they have 6 ttys, INX uses more RAM than you
might expect. Squashfs also is a blocker for low RAM machines - if you
boot in a virtual machine for example, on login you will see RAM use
of only 20 MB or even less initially, but booting from the live CD
requires a minimum of around 96 MB... I could go on, but I'm not
writing a book, just an email ;-)
Please remember that the main aim of INX is *_educational_*. That
doesn't mean "no pointing and clicking", but, as far as I'm concerned,
the more I can encourage people to follow the bash tutorials the
happier I'll be. Very few people seem to comment on the tutorials,
despite the fact that they were the main reason for creating INX in the
Perhaps a future version could be bigger, and include some of these ideas.
The other issue with directfb is that it takes over the foreground tty,
as Samson discovered when he used mplayer to play a video from elinks.
While it is sort of possible to ctrl-alt-F[1-6] away from a running
framebuffer app, weird stuff happens, and the screen needs to be
redrawn on return.
So to end this rather long post - I am not against directfb, and I am
not against X for that matter - I use it daily. We just need to have a
clear idea of what INX should be. I'm open to having a different
version further down the road that includes more bells and whistles,
but there should at least always be an INX that emphasises the
console, command line, and the power of Bash.
Just my $20 worth, adjusted for inflation *grin*
More information about the Inx