Re: File and Font selection box ideas [long] (was Re: GNOME and the File selection dialog box)
- From: Miguel de Icaza <miguel nuclecu unam mx>
- To: martin home-of-linux org
- CC: nils rhlx01 rz fht-esslingen de, gnome-list gnome org, gtk-list redhat com
- Subject: Re: File and Font selection box ideas [long] (was Re: GNOME and the File selection dialog box)
- Date: Fri, 4 Sep 1998 12:04:54 -0500
> Just spend some hours adding a new gnome_font_selection_with_default ()
> function to libgnomeui and then found out that there's also a Gtk Font
> selection dialog which is much better ...
The idea is to phase our our current gnome-font-selector and just
use the one in Gtk, as the author has promised to adapt the
GtkFontSelector to fit the gnome needs as well.
> The `GtkFileSelection' widget should be subclassed from GtkFrame and not
> GtkContainer and not even GtkNotebook: you can include a GtkFrame in a
> GtkContainer and you can include a GtkContainer in a GtkNotebook with less
> then ten lines of code but not the other way around.
I do not understand the argument here. Can you show us a detailed
example of why we should use a GtkFrame as the base widget?
> For instance, when a new file/font is choosen, it should emit a signal to
> itself and let the signal handler either accept or refuse the selected
> file/font. One can then subclass `GtkFileSelection' to `GnomeFileSelection'
> and use the signal handler to to specific things when a file/font is selected.
I do not like this approach. An interface that shows me lots of fonts
and the complains about not being able to use one is pretty bad. I
like more the idea of the filter which was suggested by the
GtkFontSelector author: You pass a number of criteria about the fonts
that can be shown and only those are shown.
> > > My idea is to have the GTK file selection (or - more generally
> > > spoken - all metawidgets like filesel, colorsel, fontsel...) so extensible,
> > > extended with hooks for nearly anything that a specific GNOME file selection
> > > could be done without hazzle by subclassing the GTK file selection.
>
> No. I disagree.
>
> Ok, at the moment you can't subclass the GTK file selection - so you're right.
>
> But for the future we should use my idea above - if you don't like subclassing:
I like Martin's proposal (ie, subclass the Gtk file selection).
Miguel.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]