File and Font selection box ideas [long] (was Re: GNOME and the File selection dialog box)

[Martin Baulig <martin home-of-linux org>]

Miguel de Icaza <miguel@nuclecu.unam.mx> writes:

> > 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. 
> 
> I agree with this idea.  If the Gtk maintainers allow me to go and
> break their Gtk file selector, I would be happy to follow this
> approach.

Hi,

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 ...

Well, I've got some comments about both of them:

1.) Both the GnomeFontSelector widget and the GtkFileSelection widgets
    are subclassed from GtkWindow. Very bad idea.

    First, I wanted to integrate a font selection dialog into one of
    the properties notebook pages of GTop - not possible.

    Fine. Looked for a method to set the font name in the box - also
    impossible, but required no modifications to the widget, just a
    new function -> done.

    Next problem: if you look at my code, you'll see that there are
    about 4 pages of code just to set a font name. There are also about
    4 to 5 pages of callback code to change the font name on user
    interaction, but it wasn't possible to re-use them.

    So, when rewriting the File/Font selection dialogs, please make sure
    they can more easily be extended.

2.) I only had a short look at gtkfilesel.c and also tried it out.

    First impression: Looks better than the GnomeFontSelector widget,
    but I think there needs to be some way to disable some of the
    functionality - in some situations (for instance when included in
    a properties dialog) it may be better to have only the first notebook
    page but not in a notebook, ...

    Yes, I think I'd prefer the Gnome one if it had the posibility to
    edit the font name ...

3.) There is one main advandage of the Gtk Font selection widget which
    sould also be used for the File selection dialogs:

    * the Gtk people are using two widgets:

      GtkFontSelection        - which is derived from GtkNotebook

              and

      GtkFontSelectionDialog  - which is derived from GtkWindow

    This means you can include the dialog in other widgets.

Ideas for the future:
--------------------

A really important issue is to split the File selection widget into:

    GtkFileSelection           - subclassed from GtkFrame

          and

    GtkFileSelectionDialog     - subclassed from GtkDialog

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.

This will mean that the `GtkFileSelection' widget can be included in any
other dialog widget, notebook page, ...

The `GtkFileSelectionDialog' is the ``real'' File selection dialog, it should
be subclassed from GtkDialog or GtkWindow and use the `GtkFileSelection'
widget.

To make it more extensible, the `GtkFileSelection' widget should have some
well-chosen signal handlers and use them in it's callbacks.

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.

Second issue - subclassing and hooks:
------------------------------------

To cite this from above:

> > 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:

It's easier than adding hooks. To copy&paste some code from the GTOP_MDI_BRANCH
of GTop (removed function bodies):

<=====
/* called whenever the widget becomes visible on the screen. */
static void
gtop_fsusage_map (GtkWidget *obj)

/* called whenever the widget becomes invisible on the screen. */
static void
gtop_fsusage_unmap (GtkWidget *obj)

/* called when the widget is destroyed. */
static void
gtop_fsusage_destroy (GtkObject *obj)

/* provides initializations that are independent from the arguments
   of gtop_fsusage_new (). */
static void
gtop_fsusage_init (GTopFsUsage *fsusage)

/* creates a new widget. */
GtkWidget *
gtop_fsusage_new (GTopPage *owner, gint ftype)

/* class init - read below ! */
static void
gtop_fsusage_class_init (GTopFsUsageClass *class)
=====>

You get all this function by subclassing. Most important of all this
functions is the class_init one - here you can add your own signal
handlers and hooks.

If the parent class sends itself a signal to do some action, the
derived class can catch this signal and do its own stuff with it.

Ok, fine - the parent class needs to provide some basic hooks and
signal handlers, but there's nothing bad with subclassing - you
can even do more with it than with normal hooks.

Good luck,

Martin

-- 
----------------------------------------------------------------
   Martin Baulig - Angewandte Mathematik - Universitaet Trier
   
   baulig@castor.uni-trier.de, http://www.home-of-linux.com/
   Key: 1024-bit key with ID C8178435 created 1997/01/24 
   ID:  67 C1 84 A0 47 F5 11 C5  5F 68 4C 84 99 05 C3 92
   Finger baulig@math38 or fetch mykey.asc from the url above
-----------------------------------------------------------------