Re: GNOME::Selector

[Dietmar Maurer <dietmar ximian com>]

Martin Baulig wrote:

> > interface is designed to handle lots of situations that I do not believe
> > are common - ie. overdesign.
> >
> >         + An example of this might be the pluggable filter for filtering
> > what URLs are allowed in a directory - and the complex event /
> > notification structure to allow this to occur. Here is how I would design
> > this API - and yes, this approach will not cover 0.01% of cases the
> > current design _might_ work with. [1]
>
> I thought a lot about this and I think I'll keep GNOME::DirectoryFilter.
>
> The API is really simple and easy to implement:
>
>         static void
>         check_uri_handler (GnomeDirectoryFilter *filter, const gchar *uri,
>                            gboolean directory_ok, GnomeAsyncHandle *async_handle)
>         {
>             gboolean success;
>
>             success = check_whether_uri_is_correct (uri);
>
>             gnome_async_handle_completed (async_handle, success);
>         }
>
>         static void
>         scan_directory_handler (GnomeDirectoryFilter *filter, const gchar *uri,
>                                 GnomeAsyncHandle *async_handle)
>         {
>             CORBA_any *result;
>             gboolean success;
>
>             /* .... read that directory .... */
>
>             gnome_async_handle_set_result (async_handle, result);
>             gnome_async_handle_completed (async_handle, success);
>         }
>
>         filter = gnome_directory_filter_new ();
>         g_signal_connect_data (G_OBJECT (filter), "check_uri",
>                                G_CALLBACK (check_uri_handler), FALSE, FALSE,
>                                NULL);
>         g_signal_connect_data (G_OBJECT (filter), "scan_directory",
>                                G_CALLBACK (scan_directory_handler), FALSE, FALSE,
>                                NULL);
>
>         GNOME_Selector_setDirectoryFilter (selector, BONOBO_OBJREF (filter));
>
> >         So, here is my file selector API (roughly):
> >
> >         char *mime_names [] = {
> >                 "application/x-gnumeric",
> >                 "application/x-xbase" };
> >         char *regexps [] = {
> >                 ".*\.xls" };
> >         CORBA_sequence_CORBA_string mime = { 0, 2, mime_names, FALSE };
> >         CORBA_sequence_CORBA_string regexps = { 0, 1, regexps, FALSE };
> >
> >         obj = bonobo_get_object ("bonobo:file_selector");
> >
> >         bonobo_pbclient_setv (
> >                 obj,
> >                 "mime_types", TC_CORBA_sequence_CORBA_string, &mime,
> >                 "regexps", TC_CORBA_sequence_CORBA_string, &regexps,
> >                 "saveas_uri", TC_CORBA_string, "file:/tmp/ILoadedThis",
> >                 "send_events_on_entry_change", TC_CORBA_boolean, FALSE,
> >                 "allow_multi_selection", TC_CORBA_boolean, FALSE,
> >                 "history_app_id", TC_CORBA_string, "MyAppName",
> >                 NULL);
> >
> >         Then perhaps the completion event would give me a status, <cancel>
> > or <selected> and a selection sequence etc. etc.
>
> You'd gain almost nothing with this:

This does not need a new and complex interface at all, as opposed to your approach.

> This'd make GNOME::DirectoryFilter obsolete - but we'd add these two
> sequence<string>'s and a bunch of enums to GNOME::Selector to come even close
> to the functionality of GnomeVFSDirectoryFilter - and this won't be extensible.
>
> >         + Again, there is eg. no code to set the 'URI', [ ie. a possible
> > preview in a RHS pane ], but this can trivialy be done by using the last
> > element of the selection - and changes in response to either user input or
> > setting of the currently viewed directory [ which should be done once at
> > startup ] - an application has no business going round automaticaly
> > selecting things in a selector for the user.
>
> No, it cannot.
>
> Again, you're trying to abuse properties for things which must be implemented
> as functions.

I think properties are well suited for the above case. So I do not understand why
you need such a complex asynchronous interface, especially when we can implement the
whole thing with our existing framework. Please can we try to find all advantages of
both approaches:

Advantages (Michael)

- no new complex/async interface
- easy to understand
- uses the existing framework/ code reuse
- uses regular expressions as filters

Advantage (Martin)

- a generic filter implementation


- Dietmar