msm/profterm

[Havoc Pennington <hp redhat com>]

Hi,

I just added a CVS module "profterm" and have had "msm" in there for a
while. Wanted to explain what's in these modules to avoid any wacky
speculation. ;-)

What we have here is a) an unfinished terminal application
(gnome-terminal equivalent) I started to write at the ALS hackfest and
b) an unfinished session manager (gnome-session equivalent).

I've just updated the TODO for both of them. The TODO lists are
reasonably long. They aren't insurmountable but neither will they
happen for sure or instantly.

The essential purpose of both of these is a code/UI cleanup, and to
get the big-picture design of the apps right. The terminal
rationalizes preferences, session state, command line options, and
terminal classes into something coherent (essentially done by making
profiles the central UI feature - thus "profterm"). The session
manager is mostly just a gratuitous rewrite but might accidentally
have some nice features. I want to get the session manager, terminal
and window manager all working properly together to save/restore a
bunch of term windows, something we've never gotten quite right.

So, yay. People want to know if these modules are scheduled for GNOME
2, or even for GNOME at all. My opinion is that we shouldn't put
rewrites/new features into GNOME releases unless they are already more
or less working when we commit to them, assuming we have that option.
That's why these modules are currently separate from gnome-core, and
currently called something other than gnome-foo.

gnome-terminal and gnome-session are two features of GNOME 2 that do
mostly work as well as they did in 1.4 at the moment, and I think
getting panel and control-center to that status as well are the
highest priorities right this second. I would not consider breaking
terminal/session functionality to be the best idea on earth.

One of the reasons I don't think we should commit to unfinished stuff
is that "blessing" such stuff can discourage other projects that may
turn out to be better options. On several occasions we've waited much
too long for some "official" project to finish, until someone finally
figured out it wouldn't happen and did their own thing. So, I'm not
much on "official" projects. I'm all for redundancy and giving people
space to try out new stuff or hack on things they find fun.

So the logical conclusion of that is: I'm not staking out the
"official SM/terminal solution," if anyone thinks my modules are on
crack, or loves the existing modules, extra code is great. And in fact
right now the existing modules in gnome-core are clearly better.

If you think my modules are promising in some way, then I'd love to
have your hacks and patches that move them forward, and if the
modules ever get to a reasonable state we can propose switching to
them for whichever GNOME release is upcoming at that point.

In short:

 - I would love to have people try these modules and hack on them; 
   see their TODO lists, send me any patches you come up with.
 - we are definitely not putting them in GNOME without having 
   a good consensus to do so.
 - even if there's consensus I'm not in favor of putting them
   in before they work, as long as we have working alternatives.
 - I don't want to discourage other projects in the same problem
   domain, if anyone has cool ideas; we need to have lots of hacking
   activity.
 - while I have a bad habit of starting goofy projects like this, 
   we really should be fixing the panel and stuff instead. ;-)

So that's the story. 

BTW, I switched to GNOME 2 for my daily desktop today; Alex suggested
the excellent strategy of putting an "xterm" in your .Xclients, and
running your Emacs and gnome-session out of that. Then when GNOME 2
crashes, you keep the xterm and the Emacs, and don't lose all your
work. ;-) Also you can still work during rebuilds when you have
temporary ABI mismatches.

Havoc