A select summary.

[Michael Meeks <michael ximian com>]

Hi Martin,

	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 ).
	
> Just got a super-great idea how we can drop GNOME::DirectoryFilter
> and keep things extensible and general enough for all kinds of
> selector widgets.

	I like the idea, personaly.	

> However, if we use just one sequence - let's call it
> "filter-patterns" - this can be a simple sequence<string> property
> in the property bag.

	Yes, this is a good plan.

> And a filter pattern can be a string which is one of (exclamation
> mark at the start means drop the URI if the pattern matches, for
> instance for dot files)
>
>        mime-type:something
>        !mime-type:something

	I think, once we are at this stage of complexity, we might as
well go for an XML string, so that we can have translated descriptions
and other rich attributes, ie. for a file selector you might want
something like:

	<mime_type>
		<value>application/x-excel-95</value>
		<descr>Excel 95 file</value>
	</mime_type>
	<regexp>
		<value>.*tar.*</value>
		<descr>Tar archive</value>
	</regexp>

	Or whatever, since often users want to sub-filter their views,
and the MS dialog has this nice drop down combo allowing trivial
sub-filtering 'Text Files: *.txt'

> Then it's up to the component to override the default "check_uri"
> and/or "scan_directory" signal handlers to provide a custom filter.

	This sounds ok, I would be inclined to have a 'mode' property,
that if you set to 'MANUAL_FILTER' instead of 'BUILTIN_FILTER' just
emits signals on the event source - if you are _really_ wedded to this
concept - but I would like to see at least some use for it before
putting it in [ and not a contrived one ].

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

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

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

	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.

	Regards,

		Michael.

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