Re: File Dialog
- From: Vlad Harchev <hvv hippo ru>
- To: Maciej Stachowiak <mjs eazel com>
- Cc: Derek Simkowiak <dereks kd-dev com>,Havoc Pennington <hp redhat com>, gtk-devel-list gnome org
- Subject: Re: File Dialog
- Date: Sun, 27 Aug 2000 15:59:36 +0500 (SAMST)
On 25 Aug 2000, Maciej Stachowiak wrote:
> Derek Simkowiak <email@example.com> writes:
> > -> Also there's the issue of hooks to enable the dialog to become
> > -> GNOME-ified, I believe this would mean all the filesystem access
> > -> functions should be virtual methods, at a minimum.
> > I would like to have the "issues of hooks to enable the dialog to
> > become GNOME-ified" clearly defined. I want to make sure I do whatever's
> > necessary with my widget.
> I don't think this is even worth considering. The GNOME 2.0 file
> selection dialog is likely to require so many kinds of changes to
> provide all the features that are available with various GNOME
> libraries, that is incredibly unlikely building on a Gtk-only widget
> will be a at all useful (no matter how much a priori thinking about
> what extensibility hooks might be needed has gone into it).
Providing Gtk-only version of them isn't needed. Seems everyone forgot about
gmodules that gtk can load at runtime (the list of gmodules to load could be
set in environment variable - current gtk supports this). So, by slightly
touching internals of gtkfiledialog we could provide means for replacing
standard gtk filesel widget with custom one.
> For example, one proposal on the table is to embed suitably
> scaled-down (functionally, not just visually) versions of the various
> Nautilus directory views via Bonobo.
It seems it could be done easily. Even if compatibility requires existance of
the members 'GtkCList *dir_list, *file_list;' in the widget's structure, it
would be possible to provide them using hidden lists that are maintained in
parallel to icon lists (though questionable that it will work with apps that
delete rows from those lists). If we are going to break source compatibility
for GtkFileSelection widget, then it's even easier - we shouldn't expose those
2 clists at all, but instead of this export limited set of signals generated
by these Clists, e.g. "filelist-select-file", "filelist-unselect-file",
> - Maciej
> gtk-devel-list mailing list
] [Thread Prev