Patch to add accessKey for "close all" sidebar button

[Derek Peschel]

This patch makes ctrl-Y (on Mac) or alt-Y (on Windows) close all
tiddlers. My recent patches define a few new access keys:

W close this tiddler
E edit this tiddler (or view in read-only mode)
R close other tiddlers
Y close all tiddlers

W is the standard Mac shortcut for "close window", R and Y are in the
same row of the QWERTY keyboard as W, but separated to perhaps prevent
typing mistakes. Separation also leaves "E" available for "edit
tiddler".

--- Lingo.js.orig.20091019 2009-10-18 14:37:46.000000000 -0700
+++ Lingo.js 2009-10-19 16:05:36.000000000 -0700
@@ -174,7 +174,8 @@

merge(config.macros.closeAll,{
label: "close all",
- prompt: "Close all displayed tiddlers (except any that are being
edited)"});
+ prompt: "Close all displayed tiddlers (except any that are being
edited)"},
+ accessKey: "Y");

merge(config.macros.permaview,{
label: "permaview",

[Derek Peschel]

Oops, sigh, I didn't test my patch and I got burned. Here's a working
patch.

Index: Lingo.js
===================================================================
--- Lingo.js (revision 10958)
+++ Lingo.js (working copy)

@@ -174,7 +174,8 @@

merge(config.macros.closeAll,{
label: "close all",
- prompt: "Close all displayed tiddlers (except any that are being
edited)"});
+ prompt: "Close all displayed tiddlers (except any that are being
edited)",
+ accessKey: "Y"});

merge(config.macros.permaview,{
label: "permaview",

Index: Macros.js
===================================================================
--- Macros.js (revision 10958)
+++ Macros.js (working copy)
@@ -193,7 +193,7 @@

config.macros.closeAll.handler = function(place)
{
- createTiddlyButton(place,this.label,this.prompt,this.onClick);
+ createTiddlyButton
(place,this.label,this.prompt,this.onClick,null,null,this.accessKey);
};

config.macros.closeAll.onClick = function(e)

[Eric Shulman]

>  config.macros.closeAll.handler = function(place)
>  {
...
> createTiddlyButton(place,this.label,this.prompt,this.onClick,null,null,this.accessKey);
...

This will set the access key on *every* instance of the closeAll
command. If this command occurs in more than one place in the
document, then there will be multiple DOM nodes with the same assigned
access key. This is generally not a good idea, as this can be handled
differently by different browsers.

-e
Eric Shulman
TiddlyTools / ELS Design Studios

[FND]

> This patch makes ctrl-Y (on Mac) or alt-Y (on Windows) close all
> tiddlers. My recent patches define a few new access keys

Thanks for this.
Since Google Groups wraps long lines and we're largely ticket-driven,
could you raise a ticket on Trac and attach your patches:
http://trac.tiddlywiki.org/register

-- F.

[Eric Shulman]

> > This patch makes ctrl-Y (on Mac) or alt-Y (on Windows) close all

note:
accessKeys in FireFox use Alt-SHIFT-letter
accessKeys in IE use Alt-letter, followed by Enter

Also, keep in mind that, athough it might seem that the unused
accessKeys are available to assigned to core commands, there are
currently some *plugins* that are already generating command links
with accessKey definitions (e.g., http://www.TiddlyTools.com/#GotoPlugin,
which uses "G"). I strongly recommend leaving as many of these keys
as possible unassigned by the core, so that they are available for
custom applications.

-e

[Derek Peschel]

On Oct 20, 1:33 am, Eric Shulman <elsdes...@gmail.com> wrote:

> This will set the access key on *every* instance of the closeAll
> command.  If this command occurs in more than one place in the
> document, then there will be multiple DOM nodes with the same assigned
> access key.  This is generally not a good idea, as this can be handled
> differently by different browsers.

You may be confusing two patches here. I deliberately wrote them this
way
but I didn't do a good job of explaining myself. The code you're
reviewing sets
the accessKey for the closeAll _macro_ which I had assumed goes in the
sidebar
only one time. The closeAll _command_ has no accessKey. One (on the
macro)
is enough.

Also, I based my code on the accessKey-setting code for the other
config.macros
entries. Do they have the same problem, or does only my code have the
problem
because it's used differently? Perhaps the <span> trick to put the
closeAll macro
in toolbars?

[Derek Peschel]

On Oct 20, 1:52 am, Eric Shulman <elsdes...@gmail.com> wrote:
> Also, keep in mind that, athough it might seem that the unused
> accessKeys are available to assigned to core commands, there are
> currently some *plugins* that are already generating command links

> with accessKey definitions (e.g.,http://www.TiddlyTools.com/#GotoPlugin,
> which uses "G").

You've written a number of plugins, I see, so your point of view makes
sense.

One problem is that there aren't many accesskeys available. Another
problem
is that you have different pieces of code, unaware of each other, all
trying to set
accesskeys. What if two plugins decide to use the same key? Core/
plugin clashes
are a symptom of the larger problem of code clashes, I'd say.

Does the TiddlyWiki architecture say anything about the order of
plugins loading?
In other words, can the user assume that accesskey assignments will be
read in
a certain order? Or are we talking about uncharted design territory?

A shadow tiddler with user customizations to keys might be the answer,
if it can be
parsed at the right time. Maybe after all plugins are loaded and
before any command/
macro instances are created?

As a user, I've never seen a good solution to the problem of finding
and customizing
plugin code. And the same problem applies to programs like Emacs,
though the set
of keys is much larger. My life is much easier when I know the entire
set of commands
I'm trying to assign keys to.

As an author, you may not want your key taken away from you. I see
the point which is
why the solution has to be well-thought-out.

Out of curiosity, do you think my patches so far can be implemented as
plugins?

-- Derek

[Derek Peschel]

On Oct 20, 1:42 pm, Derek Peschel <dpesc...@eskimo.com> wrote:
> Does the TiddlyWiki architecture say anything about the order of
> plugins loading?
> In other words, can the user assume that accesskey assignments will be
> read in
> a certain order?  Or are we talking about uncharted design territory?

Never mind the question... http://tiddlywiki.org/wiki/Plugins says:

"In general, plugins are processed in alpha-numeric order (by tiddler
title),
using case-sensitive ASCII sort order (i.e. A-Z precedes a-z)."

So we know more or less what happens now, i.e. how conflicts are
treated.

[Eric Shulman]

> "In general, plugins are processed in alpha-numeric order (by tiddler
> title),
> using case-sensitive ASCII sort order (i.e. A-Z precedes a-z)."

In addition to the above (which I wrote a long time ago), plugins now
also support use of a "Requires" slice value. If this slice is
present, it is processed as a space-separated, bracketed list of
tiddler titles, and any plugin tiddlers listed there will be loaded
first, regardless of the sort order of the titles. Thus, if PluginA
needs to have PluginB loaded first, PluginA can contain:
|Requires|PluginB|
to force an override of the normal load sequence and ensure that
PluginB is, in fact, loaded before PluginA is processed.

enjoy,
-e

[FND]

> do you think my patches so far can be implemented as plugins?

Almost anything can be implemented as a plugin - some things more
elegantly than others.
We often tend to implement features as plugins first, eventually
integrating them into the core once they're proven stable and useful.

In this particular case, you probably wanna override the core's closeAll
macro handler:
config.macros.closeAll.accessKey = "Y";

config.macros.closeAll.handler = function(place) {
createTiddlyButton(place, this.label, this.prompt, this.onClick,
null, null, this.accessKey);
};

To avoid overriding and thus duplicating the core code, you might
discover the respective element in the DOM and add an accessKey
attribute. However, that's probably more trouble than it's worth here.

Also see here:
http://tiddlywiki.org/wiki/Dev:Hijacking

HTH.

-- F.

[Derek Peschel]

On Oct 20, 1:33 am, FND <F...@gmx.net> wrote:

> Since Google Groups wraps long lines and we're largely ticket-driven,
> could you raise a ticket on Trac and attach your patches:
>      http://trac.tiddlywiki.org/register

Don't I need a Trac account to create tickets? Unfortunately,
clicking
on the "register for an account" link in http://trac.tiddlywiki.org/wiki
brings up http://trac.tiddlywiki.org/register which says

Error: Not Found
No handler matched request to /register

TracGuide — The Trac User and Administration Guide

If there are any other ways to register, for example from the login
page,
I haven't found them yet.

[FND]

> the "register for an account" link in http://trac.tiddlywiki.org/wiki
> brings up http://trac.tiddlywiki.org/register which says
> Error: Not Found

This should be fixed now. Sorry for the inconvenience.

-- F.