[Rule-list] Suggestion for modifying XFree86 and Tiny X

[Bill Crawford]

On Wed, 20 Mar 2002, Eugene Wong wrote:

> One thing that I would like to see removed from XFree86 and Tiny X are the 
> parts of the code that changes the tty. You know how when you type "startx" 
> it automatically changes the tty? Well, I believe that it would be worth 
> removing that, so that people can change the tty manually when they want to. 
> For those who want it to be automatic, they can use the "tty" program in 
> their scripts. This will keep the XFree86 binaries smaller, and more focused 
> on what they should concentrate on.

 That's a very tiny part of the code; and since the X server has to
talk directly to the graphics hardware anyway, it has to take control
of it at some point.  There's nothing to stop you switching away from
the X display to another VT when you want to.  I do it all the time.

> Those who have slow hardware will especially benefit. Think about typing 
> "startx", and then having to wait a long time staring at a screen, while the 
> computer tries to get things started. If you were allowed to change 
> manually, then you type, "startx", before you're finished with your present 
> work, and then switch to the tty, when you're done. The present way doesn't 
> work very well.

 Start it once, then switch away to a console when you want to.  Or
use xterms as consoles.  Or use gdm/kdm/xdm to lauch the X server at
boot time and then switch back to the console.

 We used to share a 486 w/16MB at home, and a Cirrus Logic display
(not terribly fast).  We used to start two X servers, one from each
of two console logins, and switch between them ... that took ten or
twenty seconds to swap the background image back in after a bit of
work on the previous desktop.  Still quicker than starting straight
from the console every time ...

> I tried to look at the source code, and from what I found, it seems that 
> there is a function that makes use of VT_ACTIVATE to change the tty. Because 
> I can't compile it right now, and because noone on the list will answer me, 
> I can't really do much.

 The X server needs control of the display hardware, it cannot work if
it doesn't, so fighting it isn't going to achieve anything.  There are
ways around this (once you see the grey background appear, switch back
to your console) but once the server is starting up, on a low spec box
you probably won't be able to do much on the console until the server
and window manager are finished starting up anyway :o)

> Another modification would be to remove the automatic displaying of that 
> weaved background. I feel that it would be better for the users to call a 
> program in their scripts to add a background. Does this make sense?

 That background takes very little code to create, and is not stored
as a graphic as such; it takes very little by way of resources; is a
good indication that the server started up; and it's very easy to set
a background during startup (GNOME does it for example).  Starting a
server from a display manager lets you set the background before you
log in, even; you don't have to see the grey background.  It's there
as a reminder of a bygone age when folks used monochrome monitors, a
time when memory was tiny and CPUs huge and slow.  Some of the folks
who wrote the original X protocols and servers have been reminiscing
about this over on the XFree (Xpert) and DRI mailing lists.

 So, there's nothing to stop you setting a background from a script.
It just doesn't justify removing the weave ... after all, what else
can the server do?  If it doesn't set *something* as background then
you either get random garbage or whatever was left from the previous
X session garbled by use of the display memory by the console.  And
that's usually not very pretty on say a Sun workstation :o)

> A third modification would be to make/modify a window manager that actually 
> changed the priorities on the threads when they are minimized. Often times, 
> I like to load up web links in another window. This allows me to finish off 
> what I'm reading now and come back to that link when I'm done. Also, I won't 
> have to use that back button and find my way around the web site. The main 
> reason that they should be changed to a lower priority is because if the 
> windows are minimized, we definitely won't need to give it focus or see what 
> is going on. Another benefit would be that you could terminate/close/kill 
> that window if it is "stuck". Netscape gets like that sometimes. It makes it 
> really painful, if you know you don't want it anymore, but you have to wait 
> till it's done before you terminate/close/kill.

 That's not such a bad idea, but the truth is that once you minimise
a window, most applications will do absolutely nothing until you open
the window again.

 Netscape is a bad example but you can always just kill Netscape if it
is bothering you ("killall -QUIT netscape").  You can kill a minimised
window in most window managers anyway; and if Netscape doesn't respond
to the message from the window manager then there is little you can do
anyway other than directly kill the process.  Using "kill -STOP" would
suspend the process and stop it consuming resources if you wish.

> What are your thoughts?

 Being able to remember using a slow machine, I have sympathy, but I
also know it isn't insurmountable, and most of the things you suggest
would not actually make a great impact.

 On a more positive note, you might find the RULE project more useful
to you.  It's trying to adapt Red Hat to install on machines with very
limited memory and/or disk space.  There's a mailing list here:

	http://mail.freesoftware.fsf.org/mailman/listinfo/rule-list

and a web site somewhere here:

	http://www.freesoftware.fsf.org/rule/



_______________________________________________
Rule-list mailing list
Rule-list at mail.freesoftware.fsf.org
http://mail.freesoftware.fsf.org/mailman/listinfo/rule-list