Re: [Deskbar] Scrapping priority

[Raphael Slinckx <raphael slinckx net>]

On Fri, 2005-11-18 at 12:55 +1100, Nigel Tao wrote:
> I haven't thought too hard about it, but now that we can drag 'n' drop
> handlers to put them higher in the list of suggestions, should we junk
> the concept of priority (the integer)?
> 

Yes, and maybe we should trash it in the maches too, since it's not
persistant anyway (i can only remember whith file/folder it's used to
sort them together) ? (more below)

> I was trying to find a specific (disabled) Handler in the Preferences
> UI, and it appeared somewhat arbitrary - it's sorted by priority, but I
> can't see priority in the UI.  I was wanting for the list to be
> automatically sorted:
> first enabled, then disabled handlers.
> for enabled handlers, in the order that they will be presented.
> for disabled handlers, alphabetically by name.
> 

In theory, the enabled should be first and disabled after by
construction, if it isn't the case it's a bug.

The disabled handlers are not sorted and so the order between disabled
handlers is arbitrary, this can be changed in the reorder_with_priority
function somewhere, you will see i put the enabled handlers in priority
order, then disabled handlers in no particular order. you can change the
second step to sort by name (sorting should be utf8 compatible but i
don't know how python handles that)

Concerning matches persistance, i ran across a problem while trying to
implement history persistance. The problem will be the same if we ever
want to remember a particular match priority (i'm thinking almost only
about search engines, for other handlers having a per-match-priority
makes no sense).

Since we abuse wrapped C structures, there is no way to use the builtin
cPickle module to store results on disk, that was my first attempt to
store history in a pickled file then reload it on startup. Pixbufs are
lost, as well as any other info coming from C world.

The only solution i see here is to have matches serialize to strings or
simple python structures, that we can store, and then easily be
recreatable from that string.
That won't work because the Class of the match isn't known to the core,
as isn't the Handler class since it's all pluggable, and i get things
like (unable to import pathprograms when trying to recreate a path
program match)

Do anyone see a solution to this problem ?

Maybe the match should return a {
"handler-class": "HandlerName",
"match-class": "MatchName",
"constructor-params": ("foo", "bar", "name/uri/path")
}

Then at load time, query all the loaded handlers against exported_class
== "handler-class", then query the handler to return the constructor of
the match == "match-class", create the match from the serialized dict
infos: match = RetunedMatchClass(matched_handler,
*infos["constructor-params"])

Would that work, or can't i use the constructor outside the handler
scope ?


Raf