Re: Clipboard Proxy objects

[Ulrik Sverdrup <ulrik sverdrup gmail com>]

2011/4/28 Karol Będkowski <karol bedkowski gmail com>:
> Hi,
>
> 2011-04-27 16:48:12 Ulrik Sverdrup <ulrik sverdrup gmail com>:
>>Hm ok. As currently implemented, there are only
>>3 extra objects, 'Selected Text', 'Clipboard Text' [..]
>>This is what exists in current master in fact. How
>>does it work?
>
> Seems to work ok. Maybe "Clipboard text" is redundant (next leave have
> the same value).
>
>>Also btw, I would like to merge in the user actions
>>plugin as it will probably be useful to a lot of
>>people. But I wonder if we can't make the
>>configuration storage simpler. For one thing, it
>>should be able to store "simple composed objects"
>>like the current source configuration scheme does
>>(Used by Triggers and Favorites).. that means.. you
>>can save arbitrary nested simple types (dict, list,
>>unicode).
>
> I check this and I see that may be problem with storing defined
> actions in source configuration style - there is no regular, one source
> for defined action. So this need some changes in ActionGenerators
> - handle its as sources.
>
> Storing configuration in ini-like file have IMHO many advantages (human
> readable, simple, resistant to updates and works ok.
>
> Karol

I think I mixed up your branches, yes, it is not using the
JSONExtendedSetting at all, I’m sorry for that. :-)

Your advantages absolutely make sense. A JSON (or similar) format can be
somewhere in the middle, human-readable and relatively simple to edit.
However since it’s very easy to just dump a whole dictionary, in practice
it will not be as easy to modify.

Please see my branch ``user_actions`` on github, there one small fix and
two commits to use some newer kupfer functions for parsing the commandline,
and using new-style command execution context. ([0])

[0]: http://kaizer.se/wiki/kupfer/PluginAPI.html#auxiliary-method-wants-context-self

Ah, and, I’m sorry if this is stupid but I have not tested my two latest
commits on that branch.. so there might be some kind of typo in there..

User actions will probably be a much-used feature if we include it, so we
want it to be reasonably stable and that configuration is kept across
Kupfer versions. Also, if there are some hard to solve parts it’s better if
we include the easy cases now (those that work well), and save less
finished parts for later.

I think you should use ``__name__`` or similar variable for the
configuration file. Most kupfer plugins try to work this way so that you
can even duplicate the plugins and have them work fine in parallel. So no
hardcoding of such things should be needed.

 -ulrik