On Thu, Oct 8, 2009 at 3:46 PM, Terry Brown <terry_n_br...@yahoo.com> wrote:
>
> Seems to me it could be really handy to have a generic interface for
> user (i.e. manual) editing of *some* uA attributes.
I agree. At present there is a fairly lame interface (with commands) for
adding icons.
> I think the interface is easy enough, but how best to identify which uA
> parts are suitable for user editing?
>
I think this has already been solved, in some sense. uA's consist of an
outer dict d, whose entries are other dicts, called inner dicts. It is my
strong opinion that all plugins follow this convention.
Just for easy of explanation, suppose a plugin called gui_uas.py provided
the interface you desire. Then the key into d would be 'gui_uas'. The
value of d.get('gui_uas') would be another dictionary, say d2. The plugin
would prompt the user for the name of a uA to set, say 'my_ua'. This name
becomes the key into d2, and the value of d2.get('my_ua') can be anything
the plugin (or the user) wants. For complex values, it might well be
another dict, say d3, but it that is completely up to the designer of the
plugin.
Where I'm trying to make the point that different plugins etc. would
> probably want to group their attributes within different dicts
> in the '_edit' entry.
>
Yes. This is compatible with what I have just said.
>
> So the user would just see, for this node, a three line attribute
> editing area where the names of the attributes where 'needed_by',
> 'category', and 'processed'.
>
In my mind, the gui_uas plugin would likely have a way of the user
specifying the fields and values desired for the uA.
>
> 3) finally, not using an '_edit' convention, but instead having
> plugins register parts of uA they wish to expose to the user:
>
> g.registerAttribute(['todo','needed_by'])
> g.registerAttribute(['todo','metadata','created'], viewOnly=True)
>
It's possible. The uA architecture (outer and inner dicts) is general
enough to handle just about anything.
If I were to hazard a guess, it would be that the most general mechanism
would be for the user to specify the parts of a uA that she wants to set.
This avoids any "static" registration. But this is just a guess.
>
> would have the advantage that all the info. for the plugin would be in
> one uA entry, instead of split between ['todo'] for the bits the user
> shouldn't see, and ['_edit']['todo'] for the bits the user should see.
>
Plugins should *always* have one entry, the entry in the outer dict. This
gives the inner dict, d2. In my mind, we are, in effect, discussing the
possible values of d2.get('my_ua'), which would plausibly be yet another
dict, d3.
> So the above would indicate that the user should see attributes
> 'needed_by' and 'created', accessed as v.uA['todo']['needed_by']
> and v.uA['todo']['metadata']['created'] respectively, and that
> 'created' be seen but not edited.
>
In my mind, the data format is not the interesting question. The most
general format is the d3 dict, and that can have whatever keys are desired,
with whatever conventions are desired. The hard part, in my mind, is the
interaction with the user, which results in entries in d3, say.
I hope I have not misunderstood what you have said. I have tried to make my
remarks general, because the uA mechanism was intentionally designed to be
general. What any plugin does with that mechanism is basically completely
up to the plugin.
As I reread your questions, it seems like you may be asking about possible
conventions in the d3 dict, but still, I want to make sure you understand
the general ground rules.
Edward
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to leo-editor@googlegroups.com
To unsubscribe from this group, send email to
leo-editor+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---
