Re: file selector re-visited
- From: Michael L Torrie <torriem cs byu edu>
- To: Owen Taylor <otaylor redhat com>
- Cc: <gtk-devel-list gnome org>
- Subject: Re: file selector re-visited
- Date: Fri, 29 Jun 2001 16:08:52 -0600 (MDT)
On 29 Jun 2001, Owen Taylor wrote:
>
> Michael L Torrie <torriem cs byu edu> writes:
>
> > Just a quick note and a question or too. First off, awhile I hacked the
> > file selector for gtk 1.2.8 to add some features and change it's look.
> > Now apparently XMMS 1.2.5 breaks with this custom widget design because it
> > reaches into the file selector object structure and accesses an internal
> > widget directory. This widget (formerly an input box) is now a drop-down
> > box, so things core dump.
> >
> > 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.
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...
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.
cheers,
Michael
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]