Re: GNOME 2.0 planning: A longer range roadmap

[Havoc Pennington <hp redhat com>]

Hi,

Maciej Stachowiak <mjs eazel com> writes: 
> I am somewhat confused by your reply. I don't understand why you
> quoted just the above part of my message. Is your proposal below in
> lieu of trying to make a longer-term roadmap, or a complementary
> effort which will guide how we set up the roadmap?

I was trying to say that for the big-picture issue of devel platform
vs. user environment, the roadmap could always be the same. You would
still need to do the roadmap for specific features of the platform or
environment. But I'm not to that point yet in my thinking. ;-) Others
may be.

> >  - each release forever in the future is focused on user environment
> >    features, as befits a desktop project
> 
> I 80% agree with this, except for the fact that we are trying to build
> a platform for others to build on in addition to a desktop. You'd
> better believe devel platform tasks are critical release blockers for
> Windows and MacOS releases.

I agree with you; our job at Red Hat Labs is in large part to deal
with providing a platform for people to build on. So we are supposed
to have a plan here.

But believe that the Windows GUI toolkit platform is about 20% of the
size of GTK+. It has order of 15 widgets, at least that show up in
Visual Studio. So let's not get too panicky that we don't have an
UltraFrobinator in the platform. 

As I said, there are no emergencies in the platform; I believe that
our primary problems right now are that we don't have docs for
everything, we haven't really solved the language bindings problem so
force people into C, we lack an IDE, we lack a real process for making
library changes and doing API review (as with the Python PEPs) so we
get compatibility problems and immature/undocumented/unproductized
APIs get released.

I don't know if you're talking about a platform for ISVs (writing
either proprietary or free software), or a platform for say custom
embedded/in-house apps, or a platform for freshmeat.net type of stuff.

For the last, for hobbyist apps, then features are a big deal, and you
can expect people to use snazzy GNOME integration stuff. But really,
we hardly even need stable releases to satisfy this group.

For the first two, you can expect them to use GTK+ only. Speculating
on reasons:

 - At least some hope of cross-platform; if they don't use GTK win32,
   they will at minimum use only toolkit features that can be
   abstracted across platforms. For example, there is no way GConf
   will get used, since it doesn't run on Windows.  Similarly,
   GnomeUIInfo is useless since you have to write an XP menu
   abstraction anyhow.

 - It's smaller and easier to understand. It's a single package.
   These people are in the "what's GTK+?" stage. They find 
   GTK+ vs. Qt confusing. They only want to learn one thing.

 - Framebuffer support and less disk/memory usage.

 - Language bindings more complete and working.

 - Probably some stuff I don't know about.

Someone will post and say I'm wrong blah blah, but; sorry, based on
the evidence I don't think I'm wrong, though I don't know all the
reasons why things are how they are. You can prove it to yourself if
you watch gtk-list and gtk-app-devel-list for a while,
vs. gnome-devel-list, and compare the number of posts saying "we are
writing..." or "for my scientific app..." or "for my database
frontend...". For those two groups of professional developers, GTK+
constitutes the devel platform. At most they try to use GnomeCanvas
from time to time, but just as often they try some weird hack
involving GtkPixmap and GtkFixed. ;-)

We can maybe change that, but doing so is going to involve the kind of
productization and polish I mentioned earlier, not features. It's also
challenging because strong integration with GNOME is _not_ a feature
for most of this group. They are often running kiosk apps, or need to
run under KDE, or need to run on 10 Linux distribution versions, or
whatever.

Anyhow, a bit of a tangent. But my point is simply this: stability,
productization, docs, language bindings, IDE are the key problems. A
component system is a key element of achieving those, that's how
Delphi and Visual Studio work. But a GnomeFrobinator widget is not
going to tip the scales, solving or not solving those other problems
are going to determine whether we succeed.

What's the implication for releases? That we do not need to focus on
devel platform features for the use of professional non-hobbyist
developers. We should focus on writing the desktop, write library code
we need for that, and let it get picked up slowly by devel platform
maintainers (Bonobo, GTK+, libgnomeui) when it's finished, and if it's
of general interest to those professional developers. If your goal is
to create a quality devel platform to get these developers, frantic
hacking on the libs is NOT the way to get there.

Basically I don't understand why we keep trying to make gnome-libs
both an ISV platform and something that we'll enjoy ourselves as
desktop hackers. Why not separate the two? Why not just have
libstuffweuseinourapps or libfreshmeatappsthatdontmindbreakage and
leave the devel platform stable and relatively slow-moving?

I just don't get why we insist on creating that conflict of interest,
and have constant battles about gnome-libs. Let's just give everyone
their own sandbox to play in.

> I agree somewhat about new features not being born in these
> libraries. However, I wonder why you don't propose the same policy for
> Gtk or GLib; the former is about twice as large as libgnomeui and the
> latter about twice as large as libgnome.

GTK and GLib basically do use this policy, though I don't know that
Owen and Tim have historically thought of it in those terms. With
exceptions, stuff doesn't go in until it's already finished. The
exceptions I can think of (GObject, GtkTextView, GtkTreeView) are
exactly what have delayed GTK 2. Those went in because a) we were
willing to delay the release for them and b) we knew the people
writing them were employed to finish them and thus didn't have to
worry about them vanishing before finishing the feature.

Examples of features that have gone in pretty much already finished:
gdk-pixbuf, stock system, GtkImageMenuItem, GtkDialog, Unicode
handling in GLib, GMarkup, g_spawn_*, etc. Those were copied in from
or prototyped as gdk-pixbuf 1.0, GNOME stock system, GtkPixmapMenuItem
in libgnomeui, GnomeDialog, libunicode, [nothing], gnome_execute_*
respectively.

Even GObject and TextView are derived from working, successful
real-world prototypes, in the form of GtkObject and TkText.

The cases where we had no prototype outside of GTK are also the APIs
that are IMO most worrisome. They do make me nervous, and I wish we'd
had APIs in use to start from. But we didn't really have those
available, e.g. for the TreeView the best we could do was look at
Swing and ETable. We did have CTree and Tree as failed prototypes,
which is something, but not as good as a tested success. Anyhow, the
fact that we judged this risk worth taking doesn't mean it should be a
general policy, just means that sometimes an exception makes sense. Or
maybe it doesn't make sense - time will tell. ;-)

As you say below, there are cases where it was simply impossible to
have a prototype, because they were changes to the core of
GTK. e.g. you couldn't have platform-abstracted GDK or switched to
Pango in a separate module. But libgnomeui doesn't (and conceptually
shouldn't IMO) have this issue very often; there's no sense of "core"
there, just a bunch of independent widgets. If stuff requires
integration with all widgets or with the widget system it almost by
definition has to go in GTK+, where we can modify the widget system
core.

Also, while you keep trying to tell me that I'm privileging GTK and we
have to be fair to libgnomeui or something, I do think that argument
is basically bogus, because they simply are not equivalent. GTK is
where we have to add significant core-affecting features such as i18n,
cross-platform targets, accessibility, multiple display support; GTK
is what professional developers use; GTK is what will appear in the
feature matrix vs. Swing or Qt. While gnome-libs is basically supposed
to be a means to the end-user desktop end, not some kind of
competition for GTK. I mean seriously, we have enough problems with
the whole GNOME vs. KDE thing, why are we adding this. I don't get it.

> I also really like the idea of having an API freeze date for the whole
> GNOME world that is well before the ship date - as in months before,
> not weeks before. Anything not done by that date should be backed
> out.

Agreed, looking at http://www.kde.org/release.html, their library
freeze is 4 weeks into the 5-month release schedule. So 4 months
before release. That means that if we shoot for a November release the
no-exceptions completion date for new library features would be
July. Just enough time to support new libs such as VFS and do some
good cleanups, IMHO.
 
> Now this raises the point of new features being developed in modules
> already part of the platform, besides just libgnome and
> libgnomeui. For instance, for gnome-vfs we want to add authentication
> callbacks, we want to add some new calls like
> gnome_vfs_get_file_info_and_open to optimize performance, we want to
> add more modules like ssh and rsync, we want to add caching,
> etc. These are features that, in most cases, couldn't be done in a
> separate module unless that module cut and pasted the current
> gnome-vfs first.

There are two ways to do that:

 - add the features bin/source compatibly, and add them in the next 
   compatible release (as with GNOME 1.2, 1.4)

 - make a branch, work on the features, release an incompatible
   version, add incompatible version to the platform on the 
   next platform-breaking release.

GTK 1.2 was in 1.0, 1.2, and 1.4, but we still have a GTK 2 almost
ready for 2.0. libxml was in the stable releases, but we still have
libxml2 finished. It just hasn't gone into a GNOME release yet. And
that's a fine thing.

i.e. do the unstable work _separately_ and merge it later. Keep your
release plans and schedules for separate projects separate. There is
no need to bundle this stuff.

If we do an incompatible platform release once per year, then no one
is ever going to be waiting too long.

I guess that basically what I'm saying is, treat the libraries the way
we treat GTK. Treat them as separate things from the desktop, that are
finished on their own schedule, and the desktop incorporates them when
it's convenient and possible to do so. The problem now is that we want
gnome-libs to be BOTH a bunch of shared code between chunks of our
desktop, AND a standalone library. I think a productized, stable,
general-purpose library requires its own lengthy release cycles.

> 
> >  - libraries do not have to be devel platform modules, they can be
> >    "stuff the panel and Nautilus happen to share" or
> >    "unreleased/experimental."  In general we should require #define
> >    I_AM_THE_PANEL_OR_NAUTILUS type of stuff for these so people don't
> >    use them accidentally.
> 
> I agree we should make more use of libraries that are not part of the
> platform. However, I don't think the needed #define should be that
> silly. How about just -DGNOME_USE_UNSTABLE_APIS.

The #define name was a joke. ;-)
 
> The thing is that devel platform changes are sometimes directly tied
> to user features. So for instance release goals like "make everything
> use GConf" or "make everything use gnome-vfs" imply needed devel
> platform changes (the latter could maybe get done as additions in a
> separate module only), but also have a definite user benefit if
> completed. I think we should explicitly have target releases in which
> to complete such features, rather than letting them happen as they
> may. 

If you need a devel platform feature for a user feature, then you have
to wait for the devel platform to evolve. e.g. we couldn't have
bidirectional text or flicker-free rendering until GTK 2 implemented
that. So putting those in the GNOME 1.4 goals would have been pretty
silly.

So my suggestion is, you first have a feature like that in the devel
platform release schedule, then in the _separate_ desktop release
schedule you have the feature "take advantage of new devel platform."
 
> In the case of gnome-vfs, since we can probably change all of the user
> environment without incompatible changes to gnome-libs, the target
> could be 2.2 rather than 2.0; maybe only some of the work will get
> done for 2.0. But I still like having a target rather than leaving it
> nebulous.

Sure, no problem. 

> This is the whole reason for my proposal that we look more than one
> release out, and tentatively schedule various features for one of the
> releases. That doesn't necessarily mean it has to be a blocker for
> that release, it just means that is what we are shooting for. 
> 
> And people (me and you included I'm sure) are probably way happier to
> have their feature scheduled for some specific later release than to
> be left out of 2.0 with no further statement on the matter.

I agree.

OK, like most of my mails, this one is basically me thinking out
loud. Conclusion I think I rambled around to: let's have regular
desktop releases which use the devel platform library versions
available at the time.  Let the libraries that make up the devel
platform release on their own schedule, and then incorporate them into
GNOME when they're ready. The driving force behind the desktop
schedule should be writing the desktop.

The problem this thread is sort of about is that we really want to use
GTK 2 because of some urgent issues such as i18n and accessibility,
but libgnomeui 2 isn't considered ready, and libgnomeui 1 won't work
with GTK 2.  So my view on that is that libgnomeui 2 _is_ basically
ready, because it just needs some cleanups, and big features can be
added in point releases. Some people think we urgently need new
features in there. I haven't seen an example that's really worth
holding up the release over. Everything but the cleanup can be done in
a point release. The 2001 release would be a big plus for GNOME, I
don't see what the big plus of hacking on gnome-libs until November
would be.

So perhaps this is the time to start getting concrete as you and
George have requested - what is it you want to do in gnome-libs that's
beyond just cleaning it up, including moving gnome-config to GConf and
adapting widgets to VFS in "cleanup"? Any new widgets or APIs? Why
can't those go in a point release, perhaps starting in an experimental
lib for GNOME 2 so GNOME itself and hobbyist apps can use them? What
is it gnome-libs really needs that can't be done by July?

In a roundabout way, I'm even agreeing with George here that there's
no black-and-white conflict between doing libgnomeui features and end
user features. What I'm arguing is simply that new libgnomeui features
maybe shouldn't go in GNOME 2, they can go in 2.2 if they are
bin/source compatible or in a separate module, and GNOME 3 otherwise.
So that's where I put them on the long-term roadmap you posted.

I think we can end the thread if we agree that anything in gnome-libs
that's not finished by July has to come out again. And agree that
there will be no whining when it's removed. ;-)

Havoc


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers