Re: The NEW gnome-terminal!

[Havoc Pennington <hp redhat com>]

Hi,

First note that using profterm for this release was not my idea. I've
always planned it for "the release after whenever profterm is actually
finished."


Second, a general point: the original idea of GNOME 2 was to just port
to new libs. That means the plan was that we would NOT compile with
GTK_DISABLE_DEPRECATED etc., we would NOT port to GConf, we would NOT
take advantage of the accessibility stuff, and we would NOT make the
rather large libgnomeui changes that were made. 

The vast bulk of actual work on GNOME 2 has been on doing all these
things we were NOT going to do.  Starting with Martin as the first
person to work on GNOME 2 much, and continuing to many other guilty
parties including myself, large pieces have been rewritten or
substantially so, and everyone has insisted on stripping out all
deprecated features and actually taking advantage of new libs, not
just porting to them. 

For example, adding full keynav and accessibility has in practice
meant a ton of new work, and also required getting rid of all
deprecated features since e.g. CList is not accessible. I don't think
this was foreseen in any way when we initially planned GNOME 2. :-/

This removal-of-deprecation policy is very obviously the cause of our
schedule being as late as it currently is. However at this point (as a
general matter) we have little choice other than to roll with it. I
don't know if it was really a good idea, but it's what people did.
On the plus side, the final result is looking quite nice.

The pressure to stuff in all these features has come from many
sources, I don't pretend to understand it, but that's what happened.
If people wanted both early release AND the new features, they have
now been educated in the meaning of the words "mutually exclusive."

Thankfully, I think we're winding down and moving toward a bugfix-only
state, and I hope we can get there ASAP.



Third, moving to the specific case of gnome-terminal, it has not yet
gotten the "disable deprecated" treatment for the most part, except
for Martin moving it to BonoboUIHandler. i.e. it still uses
gnome_config_* and so on. If we stick to the deprecated APIs, and want
to ship a 1.x-equivalent terminal, g-t is clearly the shortest route,
assuming someone does the work.

Mark indicated that he wanted a gconf-enabled proper-prefs/SM terminal
with tab support; I think profterm is the shortest route there, since
g-t really is not properly set up for those things, and adding them to
g-t breaks the schedule just as much as profterm does.

So what I said (IIRC) to the release team is that I would either leave
g-t mostly alone (just get it fixed, don't DISABLE_DEPRECATED, don't
add the features), or use profterm. Those are IMO the sane options.
Adding a bunch of new stuff to g-t is sort of the worst of both
worlds.

I put profterm in a separate module from the start precisely for this
reason; I assumed g-t could just be left alone, and we could add
profterm or equivalent later in 2.1.



Fourth, a practical point; if we stick to g-t someone needs to fix
it. ;-)


So, in short I think Miguel has a point that GNOME 2 was NOT supposed
to be about this kind of thing, but at the same time I can't blame
people for being confused, since in practice GNOME 2 has been about
DISABLE_DEPRECATED, largely driven by the UI and accessibility
projects. Time will tell if we screwed up or did the right thing.


All this said, I'm too much of a wuss to actually take a position on
the terminal issue. To me profterm is a volunteer project, I don't
want to fix g-t on my own time, because it's no fun and I use profterm
as a break from fixing crufty GNOME 1.4 RPMs and other work projects.
So that's what I plan to work on. 

But if someone wants to fix g-t bugs (vs. glomming on a bunch of
new/untested features), I can't argue with that, it's absolutely the
sensible thing to do.

Ultimately I'm happy to punt this decision to the release team. ;-)

Havoc