Re: file selector re-visited



Michael L Torrie <torriem cs byu edu> writes:

> > > Is it not improper for XMMS to be working in this manner?  They are
> > > expecting the internals of the file selector to be a certain way.  Should
> > > not they be treating the file selector like a black box, as much as is
> > > possible, and sticking to the APIs?  What is the official recommendation
> > > on this messing with internal widgets directly?  Is the file selector
> > > design so bad that this is required to make it useful to XMMS?
> >
> > No its not improper -- its long-established tradition for programs
> > like the GIMP to do it. This is the main reason why we didn't consider
> > even small rearrangements of the file selector for GTK+-2.0.  Even a
> > small rearrangement is an API change, and breaking the API without
> > fixing all the major issues was not considered a good thing.
> >
> > The file selector design is not good, but fixing it requires:
> >
> >  UI testing
> >  API design
> >  Consideration of issues like integration with gnome-vfs
> >  A complete rewrite from scratch (The current code is unmaintainable)
> >
> > And thus was decided to be a 2.2 issue not a 2.0 issue.
> >
> > Regards,
> >                                         Owen
> >
> >
> 
> I know this is a little late to say this, but this file selector thing
> doesn't point to very good design back in the beginning.

The filesel was added before I was involved with GTK+ (that is,
a _long_ time ago ;-) It's certainly not how I would design
things, but at the time, everything had to be done from scratch
without a lot of experience; some things ended up better
than others. I think

> I'm not sure for the reasoning behind waiting to change the file selector
> API.  I realize it takes extensive resources and time to create a new one,
> but I don't think that breaking older programs need be that much of a
> worry.  The whole gtk api has evolved in the pre 2.0 tree, and will break
> applications anyway.  At the very least, perhaps a new dialog box could be
> developed and merged in eventually that would eventually replace the file
> selector, but still leave the original one for programs that need it.
> Call it gtkfilesel2 or something.  I might just work on something in the
> next year...

In 2.2, the plan is to add a new filesel, called something else,
so we can fix the API without breaking all the apps that poke
into the guts of GtkFileSel.

Its something there has been a lot of interest in working on the file
selector people, which is great. And I really we get a good effort
going by these people for the GTK+-2.2 widget -- if I don't
have to touch a line of code in that, that's great. But there
is a certain bandwidth needed for api and code review, for coordination,
and simply for making sure that things are tested and integrated
properly that wasn't there for 2.0. That's why we are waiting
for 2.2 on this.

In general, the application API in GTK+-2.0 has been barely been
changed incompatibility at all, instead we've added new facilities
along side. The widget/object implementor API has changed a bit more,
but still is mostly compatible.

> Finally, is it appropriate to integrate with gnome-vfs?  It's my
> understanding that gtk is a standalone widget set that should have no ties
> to gnome at all.  The Gnome framework should create a replacement dialog
> box at the gnome level that includes gnome-vfs functionality.  I guess
> that does beg the question, what features should the gtk version have?
> Posix file system only?  Windows drive letters?  Probably just that.

I don't want to add a dependency on gnome-vfs, but I think there
should be some thought to the question:

 * What is the relationship between the GTK+ fileselector, and
   a fileselector for GTK+ programs using gnome-vfs (or other
   such extended ideas of the filesystem.)

Perhaps there needs to be a virtual base class, or a method of
plugging in a "filesystem object". Or perhaps this issue should
be ignored and a completely different file selector used.
It's just an issue that needs to be thought about.

Regards,
                                        Owen





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]