Re: 2.3 Proposed Features

[Joe Tennies <joe fatnsoft com>]

One more thing that I think would help is to start splitting the GTK+
team from the GTK+ implementation team.  They share some things, but
they are quite different beasts.  I'm not saying that people working on
any particular implementation cannot be a part of the design team, but
GTK+ has some real potential to become a cross-platform widget library.

Getting it to work on Win32 seemed to be in people's mind as they worked
on 2.0, but I think that too many of the people start to think in the
X11 world and forget the others.  Honestly, a good Mac person in there
would help a lot as Mac chose a much different HiG to Windows and GNOME.



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.
> 
> Am I correct with this thinking Havoc?
> 
> I'd think a simple way to figure out what features/functions should be
> in the GTK+ proper is "What would I need to make a front-end to a
> command-line program?"  This means that a database is obviously out.  A
> user would expect some way to do file saves/loads.  I user would expect
> support for drag-n-drop.  A user would expect buttons, etc.  They would
> not expect network support (yes, a ripper would have a CDDB one but
> that's like interfacing 2 CLI programs).  I hope that made sense to
> someone other than me.
-- 
Joe Tennies <joe fatnsoft com>