Re: gnome-vfs/GIOChannel for parsing
- From: Owen Taylor <otaylor redhat com>
- To: Michael Meeks <michael ximian com>
- Cc: gnome-devel-list gnome org
- Subject: Re: gnome-vfs/GIOChannel for parsing
- Date: 21 Feb 2003 16:07:28 -0500
On Fri, 2003-02-21 at 04:53, Michael Meeks wrote:
> On Thu, 2003-02-20 at 18:08, Havoc Pennington wrote:
> > In short it's a bug if we have "GTK apps" and "GNOME apps"
>
> That's just rubbish.
>
> > GTK should be a complete framework to write an app that works well on
> > UNIX/Linux X11 desktops, with a single coherent API with coherent
> > documentation
>
> Balls - Gtk+ should be a widget toolkit - and it should aim to be a
> good one. It shouldn't aim to be all of Gnome; there is no point in
> that - it's a massively redundant, and pointless duplication of effort.
This seems like a pointless argument. The question is - does a
stream API belong
- Below GTK+
- Next to GTK+
- Above GTK+
in the API stack. My guess is that it at least conceptually belongs
below GTK+, because we have, e.g.:
A) A stream API in GLib already
B) gdk-pixbuf probably should be using a stream API for the
loader stuff
There's no reason for GTK+ to swallow all GNOME related libraries.
I doubt we'll ever have a media framework "beneath" GTK+, for
example. Certainly database access libraries will never be part
of the GTK+ stack. Etc.
But if there is code that needs to be there for writing the
average GUI application, and especially code that GTK+ needs
itself, then it makes sense for it to be low on the library
stack.
> > and apps should not be tied to the desktop environment they are
> > running under.
>
> And what does that mean ? apart from "Hey - lets all sit down and
> re-write everything" - and/or bin any feature not in some common,
> standardized, insipid, least common denominator ? you sure this isn't
> the CADT development model ?
>
> The thing that most deeply concerns me about the "Gtk+ should swallow
> Gnome" camp, is that one company utterly controls glib/gtk+ - it would
> be terrible if one company swallowed Gnome.
Is your concern that one company utterly controls glib/gtk+ or that
one _person_ utterly controls glib/gtk+? (*)
Do you really think, that when we have a discussion about the
relationship between GTK+ and the GNOME release team, I go
off and talk to my manager to find out what I should answer?
Do you think that when Havoc has some code he wants to get into
GTK+, I just say "Oh, you work for Red Hat, commit whatever
you want"?
But anyways, I don't think it is really relevant. If we want
a stream interface that is going to be used by GTK+ and beneath,
then it has to be done in a fashion coordinated with the GLib/GTK+
release schedule
Regards,
Owen
(*) This, BTW, is quite far from the truth. I've been doing
most of the coordination recently, but the technical decisions
and (importantly) the work is done by a diverse team of people.
And Tim (who doesn't work for Red Hat) is still co-"dictator"
for GLib and GTK+. ATK is "controlled" by Bill and Padraig. Etc.
I've been very encouraged to see that a broader segment of the
GNOME community has been getting involved with GTK+-2.4
discussions and appearing on gtk-devel-list.
And it's certainly only in my interest to keep things
moving in a direction with a division of labor. I like having
some time to do something other than review GTK+ patches.
Like sleep.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]