Structural changes

by havoc

I think some people were confused about what I meant by “structural“
changes. I’m talking about things on the scale of whether apps involve
windows, dialogs, and menus (and thus whether there’s a window
manager, and which widgets are found in the GUI toolkit). Another
example might be removing files from the user model (including the
file manager and having open/save in applications). These are just
examples, they aren’t intended to be good ideas. Some of the stuff here
I would count as GNOME 3 material, but a lot of it is feasible in
GNOME 2 (and some of it isn’t even that interesting, it’s just code
cleanup).

Which structural changes are potentially interesting enough to justify
GNOME 3? I don’t know. Maybe there aren’t any. This is something
people would have to experiment
with
(google
cache, the site was down when I wrote this
).

My point is as much to discourage a flawed GNOME 3 as it is to
encourage an interesting one. I think some people are wanting total
freedom from backward compatibility, dogfooding, ABI stability,
freezes, etc. without adequate cause for said freedom. About anything
you can imagine as a tweak or evolution of the current desktop is
going to be feasible in GNOME 2.x. GNOME 3 should have strong cause in
real user-centered innovation, it should not be “we haven’t broken ABI
in a while, let’s go for it! woohoo!” because that approach is driven
by technical wanking, not by the goal of making a better desktop.

Unless someone starts some experiments and scopes out some interesting
new directions, I think we’ll be in the 2.x series forever.

BTW, if we did do a GNOME 3 in the sense that I’ve described it, I bet
the 2.x branch would continue indefinitely alongside; 2.x would be
much more suitable for technical workstation kinds of applications,
for example.

Keep in mind, there are some pretty interesting things to do on 2.x,
especially if you think about writing apps rather than modifying the
core platform.

(This post was originally found at http://log.ometer.com/2005–04.html#22)