Re: GNOME::Selector

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

Michael Meeks <michael ximian com> writes:

>         Firstly, it seems that you have fallen into the trap that bonobo
> is still digging itself out of, of thinking that simplicity in the C API
> is the important thing - au contraire, one should aim towards having no C
> client API whatsoever - then the interface is truly useful to scripting.
> So consider a scripter using the API.

This works perfectly fine if you script around the GnomeSelectorClient C API.

For GNOME::Selector, simplicity in the C API *is* the important thing, you
should not use the CORBA API directly unless you have a very good reason to do
so. And you'll never do this in a scripting language.

If you use GNOME::Selector in a scripting language, you're normally interested
in getting return values and error messages from the async functions, so you
need to use the C API and hook into the async callbacks.

    (gnome-selector-client-set-uri client #f
        "http://www.gnome.org/~martin/some-screenshot.jpg"; 5000
        (lambda (ctx handle type object uri completed success error result data)
         (if completed
          (if success
           (display-message-to-user "URI ~s loaded ok" uri)
           (display-error-to-user "Cannot load ~s: ~s" uri error))))
        #f)

You can even turn this into a synchronous API in your scripting language

    ;; Scan this directory, timeout after 5000 ms, return list of URIs on
    ;; success, throw exception on error.
    (set files (gnome-selector-client-synchronously-scan-directory client
        "http://www.gnome.org/~martin/screenshots/"; 5000)
    (display files)

>         Secondly, from whichever angle I look at it - I see that the
> 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'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.

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)