More customizable context-menu -> user-defined click/doubl-click actions
HansBKK
On Tuesday, January 3, 2012 11:05:49 PM UTC+7, Terry wrote:
On Tue, 3 Jan 2012 00:39:33 -0800 (PST) HansBKK <han...@gmail.com> wrote:
>> Are these issues from above worth adding as a wishlist item or further discussion?
>>It seems there needs to be an easy standardized way to control what happens when the user left-clicks (single vs double, "new" vs when already selected) as well as the right-click context menu.
> These things have been discussed before, I think searching for "act on node" or actonnode or something might turn up one relevant thread.
Yes, this is a followup to those issues resulting from having come across them in searching for a solution.
> There are perhaps three different issues here, so some thinning is required before you could file a wishlist item:
> - I don't think it's possible to support single and double click actions without using a timer, which Edward doesn't want, which I understand, as they do scary things to code execution pathways
I have no idea about this, nor why new code would need to do anything different - Leo seems to currently be distinguishing between single and double-click just fine?
> - Leo has very little support for multi-node operations / multi-node selection, basically the few commands from the contextmenu.py plugin
Regarding the below, set aside multi-node for the moment, and take into account my lack of knowledge on implementation, filter out the more difficult blue-sky possibilities.
We have the ability to turn full-command strings into context menu choices now. Build on that - make the choices that are currently "baked in" available via full-command strings and set them as enabled by default in leoSettings
Allow the user to add to the contextmenu.py list, and also to override or delete the default ones (currently "baked in") as desired in myLeoSettings. Allow for filtering commands out based on presence/absence of a list of @ directives (ideally allowing user-defined custom ones?).
If not too difficult (blue-sky flag), allow custom scripts to be included, ideally via full-command strings as well.
Ideally also allow these to be applied to URLs, parsing the protocol (http/ftp) vs file and file extensions (maybe even mime types)
Perhaps these last three factors would best be abstracted into a separate formally defined list of "node types", which match labels to the user's node definitions, and the actions availability tied to the labels.
--------------------
- how do you decide which plugin gets to say what single-click and double-click do?
Don't leave it to the plugins, give that control explicitly to the user in myLeoSettings. The choices are those already on the right-click list as above; just add the ability to prioritize/skip over inappropriate commands, taking into account the above "if this node type then this command" logic.
Require all plugins to "publish" their actions as full-command strings, and allow them to **assist** the user by adding example node-types-to-command settings which would show up automatically on the context-menu list, but as lowest-priority items on the click/double-click lists - they would not be allowed to "hijack" the current settings. If the user wants that plugin to handle a given node type that used to be handled by a different full-command string, s/he can then just increase that plugin's command-string priority.
Obviously it would be nice if the config facility for these settings were user-friendly, but I think enabling explicit and granular control is more important.
OK, back to:
> - Leo has very little support for multi-node operations / multi-node selection, basically the few commands from the contextmenu.py plugin
This would require either Leo being able to automatically filter which commands are appropriate to multiple nodes being selected and which aren't. This is happening now, although I don't know if accurately or not, I seem to recall observing some (at the time unimportant) inconsistencies.
Adding an additional "dimension" to the user settings to specify this would IMO be needlessly complex.
Alternatively, if the multi-node operations side of things makes the rest of the above much more difficult, I would suggest simply making all such operations full-command strings based on marked nodes instead, as with the current "clone-marked-nodes".
HansBKK
It runs as a portable app, which means you can sync your config to multiple desktops, or use it via flashdrive from any arbitrary machine without messing with their registry.
If you want to check it out, some anti-malware programs will flag it because it's built using AutoIt and uses UPX compression, but that's a false positive.
Terry Brown
HansBKK <han...@gmail.com> wrote:
> On Tuesday, January 3, 2012 11:05:49 PM UTC+7, Terry wrote:
> > - I don't think it's possible to support single and double click
> actions without using a timer, which Edward doesn't want, which I
> understand, as they do scary things to code execution pathways
>
> I have no idea about this, nor why new code would need to do anything
> different - Leo seems to currently be distinguishing between single and
> double-click just fine?
Only if single click just selects the node, in which case you don't
notice the fact that *both* the single and double click actions are
taken. Right now the only other thing I can think of that a single
click might do is start editing of a selected node (there's a flag for
that), and without a timer to see if the click was actually the first
of two, you can't have both single and double click actions. Not worth
the complexity unless there's a more important use case, although I did
have timer code working at one point.
> Allow the user to add to the contextmenu.py list, and also to override or
> delete the default ones (currently "baked in") as desired in myLeoSettings.
> Allow for filtering commands out based on presence/absence of a list of @
> directives (ideally allowing user-defined custom ones?).
>
> If not too difficult (blue-sky flag), allow custom scripts to be included,
> ideally via full-command strings as well.
>
> Ideally also allow these to be applied to URLs, parsing the protocol
> (http/ftp) vs file and file extensions (maybe even mime types)
So it seems like there's two things here,
1 have a @setting, probably a @data node, where the user can list a
bunch of 'full-commands' to be listed on the context menu. That
wouldn't be too hard
2 make sure the functionality of plugins is exported as commands - a
mix of documentation and wrapper functions
3 (because lists are always longer than you expect :-) I'm not sure
how this relates to single/double click actions. On the context
menu you pick the item you want - the system doesn't have to guess
which has priority. I think the act-on-node machinery allows a
plug-in to act *and* pass on to subsequent plug-ins, or act and not
pass on.
As an aside, this and another post recently have shown that some people
view Leo's 'full-commands' as a way of extending / scripting Leo. I
think the other post used them to construct an outline, something I'd
never have thought of. While the commands are fine for things like
key-bindings, Alt-X do-something, and maybe a list of commands on the
context menu, as in (1) above, they're always going to be limited.
They don't have conditional constructs and can't do things like
inserting a list of choices based on context as opposed to just
offering themselves. If you really want to shape Leo to your needs,
Python is the way to go.
Not that there's anything wrong with extending Leo with lists of
commands, it's a tribute to Leo's flexibility that you can do that.
Cheers -Terry
HansBKK
2 make sure the functionality of plugins is exported as commands - a
mix of documentation and wrapper functions3 (because lists are always longer than you expect :-) I'm not sure
how this relates to single/double click actions. On the context
menu you pick the item you want - the system doesn't have to guess
which has priority.
The complexity comes from the fact that "node type" can be set by not only @ directives but the protocol spec of a URL, file:// vs http:// etc. The file extension/MIME issue should perhaps just be passed on to the OS/browser. . .
Terry Brown
Hmm, for a given node type, you want all the actions that make sense
for that node type in a user ordered list, and then some action (double
click?) causes the one highest on the list to occur?
I don't think we'll get there any time soon, most commands / plug-ins
which provide commands rely on the user to say "this command is
relevant to this node", by explicitly running the command on the node.
So there's no general method for having plugins identify whether the
commands they provide are relevant. act-on-node sort of addresses
this, but it's not widely used, and many plugins provide multiple
actions, so the user would still have to pick.
- it would be easy enough to provide a setting which adds command
bindings as context menu entries, if that helps
- having Leo "do something sensible" with *url* nodes is a different
issue, basically Leo will / should just tell the OS to "do something
sensible" with the URL.
Cheers -Terry
HansBKK
Hmm, for a given node type, you want all the actions that make sense
for that node type in a user ordered list, and then some action (double
click?) causes the one highest on the list to occur?
For a given node type, all actions for any node in a - to start with system default - ordered list - just one list.
- note that the ordering idea is just one way to indicate priority - perhaps a syntax-driven numeric weighting scheme would be easier to implement
- this list also provides the mechanism for controlling the right-click syntax options
A syntax-specified "filter" for each action indicates for which node types it makes sense, perhaps allowing for an "all except these" syntax also.
A double-click on a given node - assuming Leo continues to not distinguish between them?
triggers the highest-priority action that is applicable to that node.
I don't think we'll get there any time soon,
most commands / plug-ins which provide commands rely on the user to say "this command is relevant to this node", by explicitly running the command on the node.
So there's no general method for having plugins identify whether the commands they provide are relevant.
act-on-node sort of addresses this, but it's not widely used, and many plugins provide multiple actions, so the user would still have to pick.
- it would be easy enough to provide a setting which adds command bindings as context menu entries, if that helps
@data contextmenu_commands
# stickynote Create a sticky note
# read-at-file-nodes Read file node
delete-node Simple Delete
Improvements on this would include the ability to override or delete the ones currently "baked in".
I've since learned (accurately?) that @command nodes will allow user-defined scripts to be included in the list.
- having Leo "do something sensible" with *url* nodes is a different issue, basically Leo will / should just tell the OS to "do something sensible" with the URL.
Currently my only added plugin is active_path, which I'm very happy with. Planning to check out the various "file launching" capabilities next, including
- experimenting with @URL for this, comparing with @MIME - would you say the below is still accurate?
- use @url for opening URLs
- use @mime nodes for opening files on the local file system.
- if necessary, trying to figure out node-actions and file-actions
- but looks like I'll need to figure out some Python to pass the filename from the @file spec
I also plan to try the Vim integration - I believe Leo doesn't handle block selection (ie column-mode)?
From a Leo-usability POV, I'll be curious to see how my context menu and click events evolve over that process.
But I also plan to stick to keyboard-based triggers as much as possible, seems most consistent and productive. . .