Re: 2.3 Proposed Features

[Havoc Pennington <hp redhat com>]

On Tue, Feb 04, 2003 at 12:07:17PM -0500, Ettore Perazzoli wrote:
> On Tue, 2003-02-04 at 01:49, Havoc Pennington wrote:
> > Woot, let's stick ourselves with supporting a huge hunk of bloat in
> > libgnomeui for the next 5 years, duplicating a feature that will be in
> > a GTK release 3 months later. Even better, apps can randomly select
> > which API to use, so the UI can be all inconsistent. That will rule.
> 
> Havoc, your sarcam was totally uncalled for.  :-)
> 

Yeah, sorry ;-)

> I am not advocating "bloat" or "duplication".  All I can see is that the
> file selector issue has been never resolved, at least partially because
> people thought it would have to go into GTK, and the requirements list
> for having it in GTK was too long for anyone to come up with finished
> implementation.

I don't agree that it's due to the requirements list length. The
requirements list isn't very long, or very challenging. It is not
really a hard problem.

It may be due to the requirements list *content* - but that issue is
going to come up for libgnomeui too.

> At this point, either we have to solve the issue in GTK or I'd rather
> stick it into libgnomeui (thus also taking advantage of all the GNOME
> features and simplifying the implementation).

There's no "or" - GTK will have the filesel either way, because it has
to be a complete GUI toolkit. libgnomeui version would be "and"

> GTK-only applications are always going to be inconsistent with the rest
> of the desktop anyways, in a way or another, simply because they don't
> have access to the full set of features of the other libraries.

I don't believe that. libgnomeui can be realistically deprecated by
GTK 2.6. Once we do menu/toolbar API, the remainder of libgnomeui
worth caring about is trivial to move (icon themes, session
management, and some way to display help). I have a plan for kicking
gconf below the GTK level, and even failing that we have a way to
proxy gconf settings to gtk-only apps that we are already using in
places.

The only real unresolved issue is gnome-vfs, which is quite hard to
get on the right level of the dependency stack, and would be a
nightmare to try to standardize with KDE.  gnome-vfs has lots of loose
semantics, and kioslave even looser, and they're both heavily bound up
with file manager internals. But thankfully all the core libs need it
for is the filesel, and we can make that work.

libgnomeui had some value for encouraging innovation when it was more
prototype-like but we put it in the platform, and in the platform it's
just bloat and confusing.

Qt, GTK, VCL, WINE, and XUL is *enough* GUI toolkits, thank you. ;-)

>  For example, I am still curious how the icon / MIME type handling
> and Nautilus integration are going to work in a GTK-only file
> selector.

It's really very simple; this stuff has to work on win32 and in theory
Mac as well.  So there's an abstraction of it with various
implementations, and platform-specific stuff can be plugged in.

Details of the abstraction have been discussed a bit, I guess Owen's
presentation will focus on this kind of issue.
 
> Yes, except when you have to complicate the API in GTK because you can't
> rely on features that are available in GNOME.

Such as what? There's really nothing left GNOME-specific after a few
simple changes. gnome-vfs is really the only thing. GConf, SM, and
Help are all very possible to flip down to the proper layer in the
dependency cake.

> > Cut and paste or static link is far preferable; it's some temporary
> > pain for maintainers, there's no impact there at all after 6 months.
> 
> Shortening the GTK release cycle and syncing it up with the GNOME
> release is even better than that.

You may be right here.

Havoc