[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Object Widgets
J.D. Smith, firstname.lastname@example.org wrote:
> I guess the basic difference is one of organization.
Agreed. Once you go beyond sending the same message to every
subscriber, a decision on which messages to send to whom has to be
made somewhere. Exactly where doesn't matter much until you start
trying to share code with someone who has done it differently.
> You seem to favor many specialty methods for handling "messages"
> (though you can't really call them that anymore when there's
> no standard for delivery).
My actual messages tend to have a common organisation (an extension
of the must-have fields in an event structure. Recipients know that
there will be a field called 'data' for example, and use the structure
name or the widget/object id of the sender to decide what to do with
it. Using intermediate gossip objects (which I do subclass madly)
does the weeding out that you do at the list manager stage.
> One big idea using this stuff which I think is within
> reach is an image viewing application that supports easy to
> write, easy to exchange, easy to use "plug-ins", so that you
> can custom tailor an environment that works for you.
This is one of my major motivations. I don't want to have to
rewrite a spectral deconvolution widget because a user wants to try a
> What I really think could use some work in my stuff is the
> way in which messages, and the functionality they represent,
> can be advertised and subscribed to. Currently, this is not
> extensible enough.
This is where I'm bogged down. I have some tentative preference
manager objects which hand out and set preferences for all sort of
things, and I've been trying to find an elegant way for running
widgets to say 'tell me when I should change my background colour'.
Cludges are easy, but making it general and extensible is proving
harder than I thought.
> Anyway, food for thought.
Feeling slightly sick, Peter Rabbit went to look for