Re: A select summary.

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

Michael Meeks <michael ximian com> writes:

> 	Since we seem to be moving towards some common ground, and
> understanding I thought I'd try and summarize some of the points:
> 
> 	* In Gnome 1.4 there are a load of diverse 'selection type'
> 	APIs, gnome-icon-list, gnome-font-selector, gnome-font-picker,
> 	gnome-color-picker, gnome-paper-selector and the file
> 	selector.
> 
> 	* A widely used API makes it easier for people to learn the
> 	API and understand and use new components.
> 
> 	* For the sake of scripting languages we should aim at
> 	exposing the API fully with CORBA where at all possible, hence
> 	the CORBA interfaces must be easy to use and simple to
> 	understand.
> 
> 	* Over-design is a real worry - GtkCList syndrome ie. there is
> 	a trade off beteen features and simplicity. ie. an extremely
> 	powerful interface can be too complex to be used effectively,
> 	( and of course an extremely simple one can be useless ).

Hi Michael,

yeah, that's really a good summary :-)

> > Well, if we put it somewhere else we need to find a solution for the
> > selector widgets in libgnomeui.
> 
> 	Yes, of course - I tend to think that a good way to get
> bonoboization under way is to ensure that we expose them as standard
> controls, and perhaps provide nice #defines in gnome-libs to make
> activating them easy.

After one long hacking day, they're now all derived from GnomeSelectorWidget
and no longer GnomeSelectorClient.

GnomeSelectorWidget is basically a BonoboWidget, but I added three GObject
properties "moniker", "corba-objref" and "corba-ui-container" so that you can
now do a

        g_object_new (gnome_image_entry_get_type (), NULL);

or

        g_object_new (gnome_image_entry_get_type (),
                      "moniker", "OAFIID:GNOME_UI_Component_PixmapEntry",
                      NULL);

or

        corba_objref = BONOBO_OBJREF (something);
        g_object_new (gnome_image_entry_get_type (),
                      "corba-objref", corba_objref,
                      NULL);

Btw. can you have a look at GnomeSelectorWidget, do you think it makes sense
to add these properties directly to BonoboWidget ?

So the code for the selector widgets in libgnomeui is now fully independent
of GNOME::Selector, it's just a "normal" Bonobo component.

But you can still use the GnomeSelectorClient C API (even if it's in a different
module) by doing a

    entry = gnome_pixmap_entry_new ();

    corba_objref = bonobo_widget_get_objref (BONOBO_WIDGET (entry));
    corba_uic = bonobo_widget_get_uih (BONOBO_WIDGET (entry)));

    /* This automatically QI's the corba_objref for GNOME::Selector so you
     * can use any Bonobo_Unknown. */
    client = gnome_selector_client_new_from_objref (corba_objref, corba_uic);

> > However, I'm starting to get really annoyed about all this stuff. So
> > at the moment, I'd appreciate a lot if someone could tell me what to
> > do. And whoever does this, please _look_ at this stuff before
> > flaming around.
> 
> 	Dude, I'm sorry you're annoyed - I know it's frustrating when
> people don't like a design you spent a lot of time on, and we do
> appreciate you very much and all the work you've put into Gnome 2.0.
> I just really believe that we can make things simpler, and that people
> will like them more like that.

At least, I'm starting to feel happy that we now have an actual discussion
about this API. Having a discussion about something means that at least
someone cares about it. A big progress after weeks and months of trying to
get people hacking ....

> > I'm also starting to dislike my own API after following advices from
> > people to use "standard Bonobo stuff" like PropertyBag's and
> > EventSource's - originally I had a small and clean C API in mind
> > (GnomeSelectorClient) which totally hides the fact that these are
> > components.
> 
> 	Yes, and I totaly understand why you designed the API the way
> you did, given that you planned to hide it behind an easy to use C API
> :-) it's totaly reasonable, but I hope we all agree now that this is
> not a good way to go. Can you expand the great idea above wrt. filters
> and consider a property based approach ?

Well, I still think that we "need" the C API - especially since it's so
nice and clean. However, I think we should put it in bonobo-extra or
somewhere else but not into the core libraries.

And I should add a comment to GNOME_Selector.idl that all these methods
which expect an `any async_data' argument are also callable with oneway
semantics and this argument being CORBA_OBJECT_NIL.

> 	So ... looking at the possibilities, here is what I would
> reccommend doing:
> 
> 	* Standardize the property based API eg.
> 
> 		* "filter-patterns" - RW XML string, with the following
> 		standard tags:
> 		* "selection" - RO sequence of strings, containing a
> 		description of the selection eg. URIs
> 		* "URI" - RW string, the currently visible / previewed
> 		selected element.
> 
> 	* Remove the GNOME::Selector interfaces where neccessary, but
> 	definately leave the IDL to define the enumerations and structures
> 	that we need to use.
> 
> 	* Talk to Jacob / help him write the file selector, and see if
> 	this can also be the icon selector.
> 
> 	* Implement the color / other selection controls, in libgnomeui
> 
> 	* Move the current C stuff to a super thin sugar / compat
> 	wrapper.
> 
> 	* Setup / install all the oaf files, the shlib components, etc.
> 
> 	* Relax and watch the plaudits roll in.
> 
> > my idea behind GNOME::Selector was to make the selector widgets in
> > libgnomeui suck a lot less than they did in GNOME 1.x and to give
> > them a common API.
> 
> 	I'm really glad you're working on getting this right Martin,
> and I'm confidant that all the stress will result in a beautiful end
> product.

Yeah, that'd be great !

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