Re: 2.3 Proposed Features
- From: Joe Tennies <rotund fatnsoft com>
- To: desktop-devel-list gnome org
- Cc: malcolm commsecure com au, hp redhat com
- Subject: Re: 2.3 Proposed Features
- Date: 05 Feb 2003 00:38:27 -0800
----------
<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 <rotund fatnsoft com>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]