Greetings to everyone. At FND's suggestion, this is a followup to recent threads:
Accesskeys for per-tiddler buttons? http://groups.google.com/group/tiddlywikidev/browse_thread/thread/4cde060751595fc3 Patch to allow "close all" toolbar button http://groups.google.com/group/tiddlywikidev/browse_thread/thread/48983fc48549b81b Patch to add accessKey for "close all" sidebar button http://groups.google.com/group/tiddlywikidev/browse_thread/thread/8859ce042ee603b3 on the subject of how TiddlyWiki handles keys and how to improve TW. There are some patches in those threads, and one of the patches is attached to ticket #452 in Trac. Also see http://tiddlywiki.org/wiki/Dev:Accesskeys_vs._events A few people have been working on the problem, all with different goals. Until they get hammered by peer review, my goals are: - Extend TW's letter-key shortcuts to work reliably on sidebar macros (always) and toolbar commands (for a tiddler, when that tiddler has the focus). Shortcuts may set focus or click buttons or follow links. Nothing else is needed right now. - Ideally, run as a plugin, but will that make _other_ _typical_ plugins work automatically with my code? - Run in phases: 1. The core code defines the shortcuts it wants. 2. Plugins load and define the shortcuts they want. 3. User preferences load and make changes to the definitions. Somewhere above here, my code loads. 4. Conflicts are detected. (Two different commands/macros want to use the same key. Thinking about this feature, it's not as easy as it seemed at first.) Now HTML rendering begins. 5. Conflicts are displayed. 6. As sidebar elements are created, shortcuts are assigned to them in a predictable documented way. Multiple copies of the same macro in the sidebar are handled. Sidebar elements may be hidden. I'm not sure if they can be destroyed. 7. As toolbars are created and get focus, shortcuts are assigned to buttons in a predictable documented way. Sidebar macros in toolbars are handled. Multiple copies of the same command in toolbars are handled. As toolbars lose focus or are destroyed, shortcuts are removed. My goals are NOT: - Work with every plugin that has been written or could be written. - Support multikey sequences or non-ASCII key events. The implementation of letter shortcuts using HTML's "accesskey" property works for me now and will handle the number of keys I want. - Support changing definitions without a restart. The questions of compatibility with old core code, compatibility with current plugins, and demands on future plugins are too difficult to deal with yet. With all the macros I've looked at, all instances behave the same way, so it doesn't matter which one gets a shortcut. And with all the commands I've looked at, all instances behave the same way except for which tiddler they act on, so it doesn't matter which instance in a particular toolbar gets a shortcut. The point is to be predictable. Rather than macro vs. command, the user probably cares about sidebar vs. toolbar, or taking-a-tiddler vs. not. If the data supported it, it would be possible for a macro/command to ask for two keys. It _might_ also be possible for a given key to do different things at different times. The point is to predictably map keys _to_ macros or commands or nothing, when the code currently sees macros/commands as _having_ keys. Considering the boring life of a sidebar element, it might be easier to create a good design by looking at those first. The current code that assigns the key "F" to find fields is broken in two ways. It assigns a key twice if the sidebar contains two find fields. It also assigns a key if you open the SidebarOptions shadow tiddler. As one solution, if each macro knew how many instances existed, it would know whether to assign a key to the next-created instance. For detecting conflicts, a JavaScript map from keys to commands/macros is necessary. One question is whether to detect conflicts in the shortcut data that code sets, or conflicts caused by parsing templates? A plugin may ask for shortcuts for toolbar buttons, but a user may choose not to display those buttons. Parsing the templates ahead of time, to figure out what they will do later, sounds more like an undecidable problem the more I think about it. For handling multiple copies of a macro/command, a hash can record which macros/commands have been handled. The sidebar needs one of those hashes and the current toolbar needs another. My code doesn't try to solve the sidebar problem at all. It isn't nearly robust enough at solving the toolbar problem. It does, however, try to search the toolbar of a tiddler as the tiddler gets focus and to assign accesskeys, and removes accesskeys when the tiddler loses focus. "Try" because I don't have a clear idea of what should be searched, either in terms of HTML child nodes or JavaScript command and macro objects. The view and edit templates are good places to start looking, though. My code reacts to mouse-over and mouse-out events, but I've already seen it not work as I expect. Reacting to focus and blur events might solve that problem. As long as the main contents of tiddlers aren't searched, opening toolbar contents as tiddlers isn't a problem. There's a lot I don't know yet about TW's code and existing plugins. Comments are welcome. -- Derek --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en -~----------~----~----~----~------~----~------~--~---
