Re: GNOME 2.0 planning: A longer range roadmap

[Maciej Stachowiak <mjs eazel com>]

Havoc Pennington <hp redhat com> writes:

> 
> 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. 
> 

The windows development platform is a lot more than that unless they
shrank it a lot since the last time I used Visual Studio. I could
probably name 15 acronyms for different technolgoies that are part of
the platform: COM, ATL, MFC, IE, DirectMedia, Direct3D, DAO, VBA, DTC,
ICM, ActiveX, GDI, DDX, ODBC, MTS.

This is not even counting the upcoming .NET stuff.

I worked with a windows -> unix source porting toolkit once, and it
had about 30 different shared libraries, each of which apparently
corresponds to a real windows DLL, and the windows developers in house
kept complaining how woefully incomplete it was.

And look at stuff like Mac where they have the full PDF renderning
model available to applications.

Also, it's not just quantity of stuff that counts but quality, and
level of integration.


Now granted, a lot of this windows stuff is lower level than anything
the GNOME project would consider in it's purview right now.  And we do
have some really cool stuff (the canvas, new tree and text widgets,
etc). But let's not assume we are all done here.

> 
> 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.
>

No, I think the main reason is many of the other libraries are not the
level of quality or stability of Gtk. Therefore, not assuming no one
will want them and not improving them will turn into a self-fulfilling
prophecy.

 
> 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. ;-)

I agree this is true, even searching freshmeat, Gtk gets three times
as many hits as GNOME. However, KDE gets 3 times as many hits as
Qt. Why is it that the KDE libraries apparently add so much more value
over plain Qt than the gnome libraries add over plain Gtk? I don't
know the answer, but it's definitely something we should think about.

Merging everything into Gtk is definitely not, IMO, the best way to
solvce this problem.

> 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.

I don't understand why it's assumed "any gnome-libs changes" ==
"frantic hacking".

> 
> 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.

In fact, those are the same three things I was thinking of. :-)

> 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 don't want to set it up to be a competition. It's just that I don't
like people setting all kinds of policies and requirements for others
that they are not willing to follow themselves. Your response to this
above basically seems to be "Gtk is more important so it should be
special", which I just don't buy (even though I do think Gtk is more
important, I don't think that means it should get to be special).

I don't think libgnomeui is the only relevant question here. For
example, I'd like to change a couple of things incompatibly in OAF for
GNOME 2 because I think there are some serious design flaws in there
but I didn't want to dealay GNOME 1.4. I am not going to buy into a
policy of not changing anything.

> 
> > 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.
>  

July sounds like a great date for API freeze to me. Do you hear that
everyone? Me and Havoc agree on something! :-) Maybe we can get
consensus on just this one point and figure out what that means.
 
> 
> 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)

Most features we have in mind are source compatible, but this doesn't
totally finesse the issue in the case that someone starts using a
half-done feature.

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

This has indeed worked great for Gtk and libxml, but has not worked as
well for gnome-libs. 

> 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.

OK, you are convincing me, but this leaves open the question of what
to do with gnome-libs for GNOME 2.0. I guess there is not time to add
a whole lot of new features to gnome-libs HEAD, but I think there is
time to finish up a lot of the things that were started.

> > 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."

That makes sense to me. I guess one problem is that with a heavily
layered devel platform, it may take many releases for a feature to
fully percolate up. 

> 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.

I think the July freeze you proposed sounds way better - if we can get
people to really stick to it. Indeed, if we want to release in
December, then active hacking until November is just not at all an
option for anything.

> 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?

I would say adapting current code and cleaning up APIs, and if
possible, removing and deprecating more stuff (I know george will hate
me for saying this, but gnome-libs HEAD still has a lot of stuff that
just feels really crufty) should be the general guiding principle. I
don't think there is adequate time for whole new widgets to be started
now, by any means.

I actually think you and I have very similar views on what stuff
actually should and should not get done, we just have really different
ways of approaching it that make it sound like we totally disagree.

> 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.

See how great it is to have a roadmap. :-)

> 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. ;-)

We also have to pick a hatchet-man empowered to butcher such non-done
features, and an appeals process for exceptions (like, say, vote of
the foundation board, which basically means impossible because most
people on the board care more about releasing on schedule than any
given feature, but it's good to have an out).

 - Maciej

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