GNOME::Selector

[Michael Meeks <michael ximian com>]

Martin,

On 31 May 2001, Martin Baulig wrote:
> If you look at libgnome/idl/Gnome_Selector.idl - the CORBA API is now
> almost fully API documented.

        Ok I read it carefuly.

> I also painted a nice "Anatomy of a GNOME Selector" diagram - look at
> the Gnome_Selector.idl for the URL.

        I read both diagrams.

> After dinner, I'll start documenting GnomeSelectorClient and
> GnomeSelectorComponent.

 
        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.


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

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

        Now, on the positive side, I think Martin is trying to provide a
generic interface for lots of types of selector - hence GNOME::Selector -
and indeed this may be a worthy goal, however - I feel it is over
complicated for what we need in a specificaly file-selection API, and that
the genericicity is not useful - inasmuch that I cannot envisage other
types of selector [ ie. non-file selectors ] using it. eg. the URI,
directory-filter etc. have no meaning in a colour selector - indeed the
code sharing here would be non-existant.
 
        So ... nicely documented as the API is, powerful and flexible as      
it undoubtedly is, can we switch to a control / property bag interface  
that is more useful and useable ?

        Regards,
        
                Michael.
        

[1] - but I see that as either the mime sniffer, or extension's fault.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot