[from gnome] Re: 2.3 Proposed Features

[Joe Tennies <joe fatnsoft com>]

On Wed, 2003-02-05 at 00:38, Joe Tennies wrote:
> ----------
> <snip>
> ---------- 
> 
> > No. GTK has clearly defined scope, which is to provide the GUI
> > toolkit.  Other things go in other libraries. For example font
> > configuration is in fontconfig, font rendering in Xft, general utility
> > stuff in GLib, i18n text layout in Pango, configuration in GConf, and
> > so on.
> 
> That's the code layout and maintainers viewpoint. But it's not keeping
> the dependencies orthogonal. To install GTK, I have requirements on
> pango, glib, fontconfig and Xft. So they are really one big bunch. Now,
> admittedly, GTK has some facilities to have some of this stuff left out
> or substituted, but not a lot of it.
> 
> However, I would expect to be able to install GTK + GLib + friends
> without requiring gconf or gnome-vfs, since they provide disparate
> functionality.
> 
> ----------
> </snip>
> ----------
> 
> Here's what I think you are missing  in your thought process.  GTK+ is
> trying to become a cross-platform gui toolkit.  Therefore, gconf and
> gnome-vfs would only become a required for a certain scenario.  What
> will need to be done is to "generic" a general interface that gconf and
> gnome-vfs will fit into.  Perhaps, an implementation for PDAs and other
> embedded systems would actually stub both portions out.  The
> implementation on Win32 would use the registry and the .3 file
> extensions.  The implementation on Mac would use file headers and ...
> config files???  (Does Mac have a registry-like entity?)
> 
> They would then act correctly to the environment in which they were
> placed.  You could implement any portion as you pleased as long as the
> information sent to the implementation fit a certain standard and the
> information received from that implementation fit that certain standard.
> 
> (Yes, stubbing out is an implementation of it.  Perhaps you required a
> mime type in a gstring to be sent in to the file selector, you could not
> use the information (like the current file selector implementation
> does... perhaps the GUI actually shows it as "All Files (*.*)" but the
> actual info is ignored"))
> 
> You have to differentiate the front end with the back-end, which can be
> tough at times.

Oh yeah.  One other thing that has probably been brought up on the GTK+
group many times before, but I couldn't find too quickly doing a google
search or a mailing list search.

If you are really going to try to make a cross-platform GUI library that
at least has some native look-and-feel component to it, I think there
needs to be some special case widgets that do not require to be added to
a container widget.

The two I most see this on is the status bar and the menu bar.  I don't
feel as though these two really reside within the window (much like the
title bar does not).  I think that you should have a status bar and menu
bar associated to a window instead of each to containers within a
window.  The obvious place for this is the Mac.  (Yeah, a menu bar that
changes w/ every window is goofy looking, but it's not as bad as having
a menu bar in a window on a Mac.)  Another good argument is that no
window should have 2 menu bars.  (I know this becomes an HiG issue then,
but I don't know of one that allows this anyways, and it doesn't make
sense to have two in a window.)  Same thing goes for the status bar.

I can understand this for the sake of simplicity and to allow them to be
placed in other locations as you are trying to be a widget layout group,
but I think you are losing the cross-platform side of it that you are
aiming for.  The location of these should be set by a theme, not that
layout engine.  (Yes, QT does this, and I think they made the correct
choice.)

Perhaps you could make the bars in a container a depreciated to be
removed when 3.0 comes out and add the window one to 2.4.

I don't know that this ends up a patch, though I'd work on it if it
was.  I see this as a change to spec, which should be a different
group.  Getting GTK+ 2.4 specs and a GTK+ 2.4 implementaion should
become seperated.  Though you should obviously talk to the various
people implementing versions of GTK+ to make sure the proposal is still
reasonable for them to avoid the W3C style of releasing specs that never
gets used.

People may argue that this will stiffle development as the development
cycle woudl become longer, but once again the GTK+ X11 version could
release tons of point releases.

Perhaps another way to look at it would be that you could release the
X11 version as a sample implementation.  The GNOME crew is debating
whether to require 2.2 or 2.4 of GTK+ on their next version of GNOME.  I
think the GTK+ community should decide on the spec they want (the high
level interface) and perhaps release a "quick" version that implements
it.  As stated above, that does not mean you cannot stub functions.  You
just need to argue the general interface to the function... keep the
design phase and the implementation phase seperate.

For instance, change:

void gtk_file_selection_set_filename( GtkFileSelection *filesel,
                                      const gchar      *filename );
to

void gtk_file_selection_set_filename( GtkFileSelection *filesel,
                                      const gchar      *filename 
                                      const gchar      *mimetype);

There's no reason you couldn't stub out the mimetype to actually do
NOTHING!  Just make sure that the result makes sense in the current
implementation.  (I chose mimetype as it is a very cross-platform way to
describe a file, not that it is the GNOME way... this may not be what
you want in your spec.)

What I'm arguing is that you should make a design that is loose enough
that you have room to truly work with.  Things you'd like done that
don't neccesarily have to be implemented (like the mimetype above)
should be in the spec, but not neccesarily implemented in the X11/sample
version.





-- 
Joe Tennies <joe fatnsoft com>