Anyway, you don't join a project - there's no membership list, and there's nobody who will tell you do this or do that or whatever.
What you do is get on the forums (usually mailing lists, IRC, and bug tracker), start following the discussions, and help out where help appears to be needed. That's it.
If you wait for hand-holding or permission you won't get anything done. You have to be persistent and just start doing stuff.
We're trying to do a variety of things that might appeal to people who aren't using Linux or open source already. There isn't necessarily a strong connection between all of them (though there is some "platform" that we've been sharing among features so far, such as an XMPP server connecting everyone's desktop, friend lists, groups, etc.)
Even if your schedule had a bunch of more immediately practical classes (XML, Java, blah blah) they'd be obsolete soon enough. Look at college as a place to learn the more unchanging basics (e.g. algorithms, how-a-programming-language-works, etc.) and broaden your mind beyond computers (take classes you're interested in).
Learning to write may be the most useful software development skill you can learn in college, more so than a lot of the more specialized CS or software engineering classes; most any class with papers (vs. problem sets) will help you learn to write.
The place to learn the syntax of a particular language, or a new API or technology, is from books. Or online docs. Read as much as you can. Also read about things like interaction design, development methodology, coding style, etc. not just technical manuals. There are tons of people on the internet dishing out advice to new programmers, for example http://joelonsoftware.com/ is popular.
As you read, you have to write code. Try to use what you learn, and try to read things that address problems you're having. This will make the reading "stick."
A tough thing for new programmers is to realize that you have to write tens of thousands of lines of code before you stop sucking. Maybe 100K lines or more. No matter how smart you are. That's going to take a couple of years of daily practice, and lots of smart people aren't used to needing that much practice.
You're way better off putting a big dent in this _before_ you start your first job. Especially because many entry-level jobs have you write the wrong kind of code. It's best if you try to design and architect all your nonworking, terrible practice code, but your first employer won't let you. So even when you get a job, if you want to get good at programming you should probably have a weekend project that's more "from scratch" with you in charge, vs. the more common first job of maintenance programming directed by others.
To me I'd really want to hire someone who could show a lot of code already written in spare time. It means they have a lot of their initial tens of thousands of lines of practice behind them, and it shows that they really like the work and are capable of doing it.
Sample work (and practical experience) will make a much bigger difference in interviews than which classes you took. If you have good sample work you don't even need a degree in a computer-related field.
What software technologies are used - OS, language, database, etc.? What kind of hardware is needed to run a realm? What programming tricks are involved in making this thing scale up to so many users? What limits the scalability - i.e. when a realm has too many users at once, what's the performance bottleneck that creates the limit? How would you architect things differently if you started over?
Read my blog post - it's a reply to _other_ people proposing GNOME 3, I'm saying "_if_ we did a GNOME 3, here is how it would make sense and what it would look like"
You can't make the daemons optional because the desktop environments are not a set of independent apps, they are a "swarm of processes" that work together. Some of the processes have graphical representations (such as the panel and window manager) and some don't. But all of the processes _do something_, they aren't just sitting there for the hell of it.
So saying "make the daemons optional" is no different from saying "make the window manager optional" - you have to answer the question "what is going to do the thing that the daemon did"
What would "make the window manager optional" mean? Either it means you can swap in any WM (as you can), or it means you suck the WM function into an existing process - old WMs like WindowMaker essentially put the whole desktop in one big process.
In fact, in essence gnome-settings-daemon is a "catch-all" daemon that does a bunch of unrelated/random stuff to avoid having tons of separate daemons. So some of the "sucking the functionality in to a single process" has already been done.
You refer to gconfd and gnome-settings-daemon specifically I think because those daemons don't have GUIs and thus it isn't user-visible what they do; but that doesn't mean they do nothing. Stuff virtually everyone does care about would break if you removed them.
For example, the control center will not even think about working with old-type UNIX config files, because when the control center changed a setting the rest of the desktop would not know about the change. In most cases this would mean the change would not take effect. In KDE this is addressed through the dcop daemon rather than a special config daemon, but there's still a need for a daemon here.
gconfd also keeps a shared cache of all the settings, so guess what... it *reduces* memory usage overall.
The desktop need not be implemented in this "swarm of processes" way - desktops as diverse as Enlightenment and Lotus Workplace use a single-process approach. But there are advantages to multiple processes.
The headline is inaccurate. The information that will be released on Monday is regarding the development direction of Red Hat Linux. Further information on the retail product line will be forthcoming closer to the product launch plan this fall.
- advanced user environment A
- advanced user environment B
- advanced user environment C
- advanced user environment D...
and guess what, all the choices eventually grow to be configurable so that they act like any of the other choices, or indeed like any hisotrical OS ever. So useful. What a good way to spend our time, writing multiple "design your own UI" construction kits.
Maybe it's time for something different. If people want to work on developing it, who are you to tell them how to spend their time?
You are free to work on developing your own "advanced user environment E" if you don't have enough options in that area yet. Or free to create add-ons or partial replacement apps for any existing environment. Isn't open source great?
If you want to understand GNOME direction though, I'd suggest some good books, such as "User Interface Design for Programmers," "The Inmates are Running the Asylum," "Designing from Both Sides of the Screen," etc.
Technical users are so quick to assume that all software should be written for them, and that despite having zero expertise in interaction design they know exactly how a GUI should be (it should be exactly like the GUI I got used to in 1992, darnit! must... not... learn... new... things...)
The historical situation of 1001 choices, as long as they are all confusing and hard to use, is a good way to keep free software limited to 0.5% of the users in the world. It's hypocrisy to brag about choice when all the choices are the same.
It's not like there's any danger that there won't be enough hyper-configurable advanced user features and environments available. Somehow, I have faith that we're safe there. So why not let just *one* project try something different without whining about it endlessly.
All that said, I don't even agree with the premise that geeks only like the hyper configurable environments; OS X is pretty popular with the geek crowd these days. As is GNOME 2, for that matter.
In any case, I guess we'll see in a few years how it all turns out. My prediction is that there will be lots of environments and add-ons available, for different target audiences, and everyone will be happy.
GNOME 2.2 uses a common spec agreed on between GNOME and KDE, the common spec was primarily designed by Lubos Lunak of KDE and is similar to what KDE 3.1 uses.
The older attempts are things that replace XMapWindow() via LD_PRELOAD and things like that.
The answer as quoted is not correct. Bluecurve is a theme, and some default configuration options. It does not to my knowledge break anything. A theme + config options should not even be able to.
We introduced a bug, renaming.desktop files, but that was since fixed and I would not categorize it under the name "Bluecurve" anyway, it was just a random bug.
Here is a not-affiliated-with-Red-Hat link that catalogs everything in some detail: http://www.cyber.com.au/users/mikem/redha t8kde.htm l
But in general, please send specifics if anything is broken; we have rapidly fixed everything we've been told about or discovered.
They are investigating whether poor usability in most open source software is connected to open source licensing and open source development methodology. That is, does open source = poor usability.
Two alternative explanations for poor usability should be explored (and need to be disproven before blaming "open source") IMO:
- by historical accident, most open source
developers are unix programmers who don't
know a UI from a hole in the ground.
i.e. the argument is that more UI-attuned
open source communities can do just fine
with the open source licensing/methodology.
- open source GUI software is simply quite
immature. We're just maturing on the server
side; the UI is still comparable to Linux 2.0 or
earlier, not Linux 2.6.
Lots of our GUI software is very newly-written.
And a lot less people are working on it than
are working on the kernel and Apache and
so on.
This will change as the userbase grows.
I also don't take it as a given that commercial software is hugely better; some important commercial packages (such as Quicken) have pretty awful interfaces. Though some are very nice, for sure.
Some quick bugzilla.gnome.org queries would demonstrate with hard evidence that you are incorrect, if anyone were interested in reality. Wait, this is Slashdot.;-)
We've thought about this in detail, that's why GNOME does compat exactly like Windows; instead of breaking old libs, we make new libs with a different name that install next to the old libs. See
http://pobox.com/~hp/parallel.html. So no app
has to port until they feel like it.
There's still some basic speed you need to have, and I think there's an issue of how to be sure you aren't constantly buffering and never displaying, but I'm not sure.
With the tk toolkit, FVWM 2.4 and crappy hardware,
I see almost no tearing. It is certainly nothing
compared to the tearing that gtk+ produces.
I'm talking about tearing between the frame and client, not flicker inside the client. GTK 2 does not flicker inside the client, at all, ever. Tearing between the frame and client is not something that's possible to eliminate entirely without an X extension. It's less visible or more visible in some cases, can depend on what graphics you have and so on, but it's always there.
Why would this be substantially better than what gtk does now:
[create pixmap]
[draw on pixmap]
[blit pixmap to screen]
[delete pixmap]
(Note that only GTK 2 does that.) The server-side backing store is better because it would be for the window manager frame and all subwindows. The GTK backing store is only for the client window, and does not include the frame/client as an assembly, thus you see the frame/client out of sync.
Additionally, there is an unavoidable tearing problem for the few GTK widgets that still have their own X window in GTK 2; these have the same issues as frame/client because X has no way to move multiple windows atomically. Server-side backing store could also give the impression of atomically moving many windows at once.
GTK could avoid this problem by never having widgets with their own X window, which is indeed the long-term plan.
In any case, the point I'm making is not that GTK is cool or whatever, but that you need to think about this problem in terms of whether intermediate/inconsistent drawing states appear on the screen. It's a synchronization/flicker/tearing issue. Speed isn't what gives the perception that it's "wrong"
As the author of a window manager and big hunks of GTK, I don't think your analysis is quite right.
The primary problem is synchronization, not delay. GTK 1.2 is very fast, its geometry code
is not causing any slowness. You are confusing slow with flicker. Flicker looks slow but slow is not the problem; no matter how fast code is, if it flickers, you will see it, and it will look slow.
Similarly when opaque resizing a window; it has nothing to do with quantization or speed, the problem is that
the window manager frame and the client are not resized/drawn at the same time resulting in a
"tearing" effect. This would be visible no matter how fast you make things.
As you say, putting the toolkit in the server or putting the WM in the toolkit are overradical ways to fix this. It's not even necessary to backing store all X windows. It could be done with an extension allowing us to push a backing store on a single X window during a resize, for example. However fixing it 100% pretty clearly requires server changes, and that's why you haven't seen a fix yet.
Write a window manager and fix some GUI toolkit bugs, that's a good way to understand X well.
Hack on GUIs like GNOME and KDE to understand
where progress is needed on the UI front, and where
changing the window system could help.
(I think almost everyone who's actually hacked on this stuff a lot will tell you that
replacing X isn't interesting, but if you want to make a credible claim one way or the other, getting experience is the only way.)
Precisely. There is a reason GTK doesn't work like anygui, and a reason Qt/Swing/Mozilla/etc. also don't work like anygui, and a reason the
AWT approach was dumped.
You can do cross-toolkit abstraction if you do it like AbiWord, where they often add features and hooks to punch through to platform-native if required. But that doesn't work in a generic XP toolkit.
Wrapper toolkits are very limited in power, there's just no way around it.
Python needs to bite the bullet, suck it up, pick one of the existing actively-maintained modern toolkits despite the possible flamewar, and then simply address its limitations (e.g. porting to platforms as required). Until then it won't have a standard GUI. Sometimes there is no silver bullet.;-)
X is very simple, for a windowing system, it's not complex at all. Plus no one has to see that stuff,
it's always hidden behind toolkits.
X doesn't have a drag-and-drop system, so I don't see how ROX could use it. DND is built on top as a custom protocol (Xdnd) shared by GTK, Qt, etc.
I would guess that ROX just uses Xdnd, isn't it GTK-based?
Berlin is far more complex than X.
Porting GNOME/KDE to Berlin would be infeasible, but said infeasibility would have nothing to do with different CORBA implementations.
Most UNIX vendors do not reimplement X, they are basically using the open source implementation with some minor tweaks. The open source implementation (primarily maintained by XFree these days) is generally more robust than the proprietary ones.
The point is a tradeoff, you punt multiprocess/acceleration in favor of smaller size.
If you want multiprocess/acceleration, you can use the small X server developed for the iPAQ, it's not very large, framebuffer with multiprocess and hardware accel and all that would be just as big as X. So then it would be pointless.
It's not like there's a tradeoff here; accessiblity is also nicely cleaned up in GTK 2, and goes well beyond keybindings to support
screen readers and so on.
Slashdot Mirror
My standard advice: http://ometer.com/hacking.html
Anyway, you don't join a project - there's no membership list, and there's nobody who will tell you do this or do that or whatever.
What you do is get on the forums (usually mailing lists, IRC, and bug tracker), start following the discussions, and help out where help appears to be needed. That's it.
If you wait for hand-holding or permission you won't get anything done. You have to be persistent and just start doing stuff.
We're trying to do a variety of things that might appeal to people who aren't using Linux or open source already. There isn't necessarily a strong connection between all of them (though there is some "platform" that we've been sharing among features so far, such as an XMPP server connecting everyone's desktop, friend lists, groups, etc.)
There are two very specific features we already started on:
http://mugshot.org/links-learnmore
http://mugshot.org/radar-learnmore
So those are very specific, but the project is open to all kinds of stuff, no need to artificially limit it.
Even if your schedule had a bunch of more immediately practical classes (XML, Java, blah blah) they'd be obsolete soon enough. Look at college as a place to learn the more unchanging basics (e.g. algorithms, how-a-programming-language-works, etc.) and broaden your mind beyond computers (take classes you're interested in).
Learning to write may be the most useful software development skill you can learn in college, more so than a lot of the more specialized CS or software engineering classes; most any class with papers (vs. problem sets) will help you learn to write.
The place to learn the syntax of a particular language, or a new API or technology, is from books. Or online docs. Read as much as you can. Also read about things like interaction design, development methodology, coding style, etc. not just technical manuals. There are tons of people on the internet dishing out advice to new programmers, for example http://joelonsoftware.com/ is popular.
As you read, you have to write code. Try to use what you learn, and try to read things that address problems you're having. This will make the reading "stick."
A tough thing for new programmers is to realize that you have to write tens of thousands of lines of code before you stop sucking. Maybe 100K lines or more. No matter how smart you are. That's going to take a couple of years of daily practice, and lots of smart people aren't used to needing that much practice.
You're way better off putting a big dent in this _before_ you start your first job. Especially because many entry-level jobs have you write the wrong kind of code. It's best if you try to design and architect all your nonworking, terrible practice code, but your first employer won't let you. So even when you get a job, if you want to get good at programming you should probably have a weekend project that's more "from scratch" with you in charge, vs. the more common first job of maintenance programming directed by others.
To me I'd really want to hire someone who could show a lot of code already written in spare time. It means they have a lot of their initial tens of thousands of lines of practice behind them, and it shows that they really like the work and are capable of doing it.
Sample work (and practical experience) will make a much bigger difference in interviews than which classes you took. If you have good sample work you don't even need a degree in a computer-related field.
What software technologies are used - OS, language, database, etc.? What kind of hardware is needed to run a realm? What programming tricks are involved in making this thing scale up to so many users? What limits the scalability - i.e. when a realm has too many users at once, what's the performance bottleneck that creates the limit? How would you architect things differently if you started over?
Read my blog post - it's a reply to _other_ people proposing GNOME 3, I'm saying "_if_ we did a GNOME 3, here is how it would make sense and what it would look like"
You can't make the daemons optional because the desktop environments are not a set of independent apps, they are a "swarm of processes" that work together. Some of the processes have graphical representations (such as the panel and window manager) and some don't. But all of the processes _do something_, they aren't just sitting there for the hell of it.
So saying "make the daemons optional" is no different from saying "make the window manager optional" - you have to answer the question "what is going to do the thing that the daemon did"
What would "make the window manager optional" mean? Either it means you can swap in any WM (as you can), or it means you suck the WM function into an existing process - old WMs like WindowMaker essentially put the whole desktop in one big process.
In fact, in essence gnome-settings-daemon is a "catch-all" daemon that does a bunch of unrelated/random stuff to avoid having tons of separate daemons. So some of the "sucking the functionality in to a single process" has already been done.
You refer to gconfd and gnome-settings-daemon specifically I think because those daemons don't have GUIs and thus it isn't user-visible what they do; but that doesn't mean they do nothing. Stuff virtually everyone does care about would break if you removed them.
For example, the control center will not even think about working with old-type UNIX config files, because when the control center changed a setting the rest of the desktop would not know about the change. In most cases this would mean the change would not take effect. In KDE this is addressed through the dcop daemon rather than a special config daemon, but there's still a need for a daemon here.
gconfd also keeps a shared cache of all the settings, so guess what... it *reduces* memory usage overall.
The desktop need not be implemented in this "swarm of processes" way - desktops as diverse as Enlightenment and Lotus Workplace use a single-process approach. But there are advantages to multiple processes.
The headline is inaccurate. The information that will be released on Monday is regarding the development direction of Red Hat Linux. Further information on the retail product line will be forthcoming closer to the product launch plan this fall.
Havoc Pennington
Red Hat, Inc.
Right now on UNIX/Linux you can choose:
...
- advanced user environment A
- advanced user environment B
- advanced user environment C
- advanced user environment D
and guess what, all the choices eventually grow
to be configurable so that they act like any of
the other choices, or indeed like any hisotrical
OS ever. So useful. What a good way to
spend our time, writing multiple "design your own UI" construction kits.
Maybe it's time for something different.
If people want to work on developing it,
who are you to tell them how to spend their time?
You are free to work on developing your own
"advanced user environment E" if you don't have
enough options in that area yet. Or free to create add-ons or partial replacement apps for any
existing environment. Isn't open source great?
If you want to understand GNOME direction though,
I'd suggest some good books, such as
"User Interface Design for Programmers,"
"The Inmates are Running the Asylum,"
"Designing from Both Sides of the Screen,"
etc.
Technical users are so quick to assume that all software should be written for them, and that despite having zero expertise in interaction design they know exactly how a GUI should be (it should be exactly like the GUI I got used to in 1992, darnit! must... not... learn... new... things...)
The historical situation of 1001 choices, as long as they are all confusing and hard to use, is a good way to keep free software
limited to 0.5% of the users in the world.
It's hypocrisy to brag about choice when
all the choices are the same.
It's not like there's any danger that there won't
be enough hyper-configurable advanced user features and environments available. Somehow,
I have faith that we're safe there. So why
not let just *one* project try something different
without whining about it endlessly.
All that said, I don't even agree with the premise
that geeks only like the hyper configurable environments; OS X is pretty
popular with the geek crowd these days.
As is GNOME 2, for that matter.
In any case, I guess we'll see in a few years
how it all turns out. My prediction is that
there will be lots of environments and add-ons available,
for different target audiences, and everyone
will be happy.
GNOME 2.2 uses a common spec agreed on between
GNOME and KDE, the common spec was primarily
designed by Lubos Lunak of KDE and is similar
to what KDE 3.1 uses.
The older attempts are things that replace
XMapWindow() via LD_PRELOAD and things like that.
The answer as quoted is not correct.
.desktop files,
a t8kde.htm l
Bluecurve is a theme, and some default
configuration options. It does not to my
knowledge break anything. A theme + config options
should not even be able to.
We introduced a bug, renaming
but that was since fixed and I would not categorize it under the name "Bluecurve" anyway, it was just a random bug.
Here is a not-affiliated-with-Red-Hat link that
catalogs everything in some detail:
http://www.cyber.com.au/users/mikem/redh
But in general, please send specifics if anything is broken; we have rapidly fixed everything we've
been told about or discovered.
They are investigating whether poor usability
in most open source software is connected to
open source licensing and open source development methodology.
That is, does open source = poor usability.
Two alternative explanations for poor usability
should be explored (and need to be disproven
before blaming "open source") IMO:
- by historical accident, most open source
developers are unix programmers who don't
know a UI from a hole in the ground.
i.e. the argument is that more UI-attuned
open source communities can do just fine
with the open source licensing/methodology.
- open source GUI software is simply quite
immature. We're just maturing on the server
side; the UI is still comparable to Linux 2.0 or
earlier, not Linux 2.6.
Lots of our GUI software is very newly-written.
And a lot less people are working on it than
are working on the kernel and Apache and
so on.
This will change as the userbase grows.
I also don't take it as a given that commercial
software is hugely better; some important
commercial packages (such as Quicken) have
pretty awful interfaces. Though some
are very nice, for sure.
Some quick bugzilla.gnome.org queries would demonstrate with hard evidence that you are ;-)
incorrect, if anyone were interested in reality.
Wait, this is Slashdot.
(Apparently I'm in an answer-the-trolls mood...)
Well actually at least half the GTK bugs are found when users report them to bugzilla. I'm sure you did that right?
If you don't think the demos coincide with how one would actually use GTK, maybe you aren't using GTK as intended...
Yes, that's correct. The win32 version is not yet
released though, it's just in "preview" status. Should be out in a few months.
We've thought about this in detail, that's why GNOME does compat exactly like Windows; instead of breaking old libs, we make new libs with a different name that install next to the old libs. See http://pobox.com/~hp/parallel.html. So no app has to port until they feel like it.
There's still some basic speed you need to have, and I think there's an issue of how to be sure you aren't constantly buffering and never displaying, but I'm not sure.
I'm talking about tearing between the frame and client, not flicker inside the client. GTK 2 does not flicker inside the client, at all, ever. Tearing between the frame and client is not something that's possible to eliminate entirely without an X extension. It's less visible or more visible in some cases, can depend on what graphics you have and so on, but it's always there.
(Note that only GTK 2 does that.) The server-side backing store is better because it would be for the window manager frame and all subwindows. The GTK backing store is only for the client window, and does not include the frame/client as an assembly, thus you see the frame/client out of sync.
Additionally, there is an unavoidable tearing problem for the few GTK widgets that still have their own X window in GTK 2; these have the same issues as frame/client because X has no way to move multiple windows atomically. Server-side backing store could also give the impression of atomically moving many windows at once.
GTK could avoid this problem by never having widgets with their own X window, which is indeed the long-term plan.
In any case, the point I'm making is not that GTK is cool or whatever, but that you need to think about this problem in terms of whether intermediate/inconsistent drawing states appear on the screen. It's a synchronization/flicker/tearing issue. Speed isn't what gives the perception that it's "wrong"
As the author of a window manager and big hunks of GTK, I don't think your analysis is quite right.
The primary problem is synchronization, not delay. GTK 1.2 is very fast, its geometry code is not causing any slowness. You are confusing slow with flicker. Flicker looks slow but slow is not the problem; no matter how fast code is, if it flickers, you will see it, and it will look slow.
Similarly when opaque resizing a window; it has nothing to do with quantization or speed, the problem is that the window manager frame and the client are not resized/drawn at the same time resulting in a "tearing" effect. This would be visible no matter how fast you make things.
As you say, putting the toolkit in the server or putting the WM in the toolkit are overradical ways to fix this. It's not even necessary to backing store all X windows. It could be done with an extension allowing us to push a backing store on a single X window during a resize, for example. However fixing it 100% pretty clearly requires server changes, and that's why you haven't seen a fix yet.
Here is the classic paper on how X could be improved, for example: http://www.std.org/~msm/common/WhyX.pdf.
Write a window manager and fix some GUI toolkit bugs, that's a good way to understand X well. Hack on GUIs like GNOME and KDE to understand where progress is needed on the UI front, and where changing the window system could help.
(I think almost everyone who's actually hacked on this stuff a lot will tell you that replacing X isn't interesting, but if you want to make a credible claim one way or the other, getting experience is the only way.)
It has a horizontal scrollbar, yes.
Precisely. There is a reason GTK doesn't work like anygui, and a reason Qt/Swing/Mozilla/etc. also don't work like anygui, and a reason the AWT approach was dumped.
You can do cross-toolkit abstraction if you do it like AbiWord, where they often add features and hooks to punch through to platform-native if required. But that doesn't work in a generic XP toolkit.
Wrapper toolkits are very limited in power, there's just no way around it.
Python needs to bite the bullet, suck it up, pick one of the existing actively-maintained modern toolkits despite the possible flamewar, and then simply address its limitations (e.g. porting to platforms as required). Until then it won't have a standard GUI. Sometimes there is no silver bullet. ;-)
X is very simple, for a windowing system, it's not complex at all. Plus no one has to see that stuff,
it's always hidden behind toolkits.
X doesn't have a drag-and-drop system, so I don't see how ROX could use it. DND is built on top as a custom protocol (Xdnd) shared by GTK, Qt, etc.
I would guess that ROX just uses Xdnd, isn't it GTK-based?
Berlin is far more complex than X.
Porting GNOME/KDE to Berlin would be infeasible, but said infeasibility would have nothing to do with different CORBA implementations.
Most UNIX vendors do not reimplement X, they are basically using the open source implementation with some minor tweaks. The open source implementation (primarily maintained by XFree these days) is generally more robust than the proprietary ones.
GTK 1.2 and GTK 2 can be installed simultaneously, I would expect all distributions to do that for the forseeable future.
Deprecated means "will disappear in some future version, when not many people are using it anymore"
The point is a tradeoff, you punt multiprocess/acceleration in favor of smaller size.
If you want multiprocess/acceleration, you can use the small X server developed for the iPAQ, it's not very large, framebuffer with multiprocess and hardware accel and all that would be just as big as X. So then it would be pointless.
It's not like there's a tradeoff here; accessiblity is also nicely cleaned up in GTK 2, and goes well beyond keybindings to support screen readers and so on.