Commit 7618ee65, custom shortcuts?
I just did a git-pull for the first time in a couple weeks, and in the
subsequent git-whatchanged, I see this:
commit 7618ee65e5ccc98b568ac5cdee0595004af8e4f0 Author: Heinrich Müller
<henmull <at> src.gnome.org>
Date: Thu Jan 12 23:21:41 2012 +0100
-roughly implemented custom shortcuts (file pan.shortcuts is auto-created
the first time pan is exited) [snip]
???
We've had custom shortcuts "since forever." In fact, Charles
reimplemented that shortly after the port to gtk2, from gnome1, back in
the pan-0.12 era, so we're talking what, maybe eight years ago now? And
AFAIK, when he did the C++ rewrite, that feature was in first public C++
release, 0.90, as well. If it wasn't, it was added relatively quickly,
well before 0.100.
The shortcut dump was (as the new one is) auto-created when pan was
exited, as accels.txt. It was (and still is, last I checked) more or less
a straight unordered function dump, along with assigned shortcuts, with
all lines semicolon-commented.
One could either edit the file directly or use the mouse-hover-over-menu-
item, hit-desired-key (or delete to remove the assignment), method, altho
the latter was somewhat limited due to the unavailability of the menu-
accelerator keys, since they'd activate the associated menu action instead
of assigning the key as intended. As a result, I used the edit-
file-directly method, here.
However, since the accels.txt file was a more or less unordered simple
function/hotkey dump, and pan rewrote it as such each time it closed, the
editing process wasn't as simple as one might have initially imagined. For
just changing a single entry, the simplest method was to use the editor's
search functionality, finding and editing the appropriate line (without
forgetting to remove the semicolon commenting it, thus signifying a
default setting, that was the usual first character of the line), then
saving (with pan closed, of course, so it'd load the new setting when it
opened and re-dump it each time it closed after that).
But I was rather more systematic than that. I setup a whole custom hotkey
scheme, thus editing quite a number of defaults. As such, I saved off the
dump as a different file, then reordered it so the entries appeared in the
same order as they did in the pan menus. I could then edit the copy and
replace the scrambled dump file (which pan would re-scramble every time it
exited) when necessary. Additionally, I kept a table that tracked all the
hotkeys used and the functions they were assigned to, so I could
immediately see what was free and what wasn't and what functions were
mapped to specific shortcuts without looking at the now ordered dump, thus
making it much easier to arrange it such that all group- operations
shortcuts were "g"-based, all thread-ops shortcuts "t" based, all
individual article operations "a" based, etc. Further, all pan's various
preferences windows (except the main one, which is always ctrl-p in the
apps I can set, thus including pan), the task manager and log windows,
etc, were all accessible using all combos with all three modifiers
(ctrl-alt-shift), L=log, T=tasks, N=newsservers, G=group- prefs... etc.
I still use that scheme today, and it still works. I've also mentioned it
several times over the years, and posted it a number of times, so it's
quite likely a number of other users are using either it, or some variant
thereof. =:^) (In some cases, they just wanted my file to start their
own theme with, so as not to have to do the reordering themselves. Whether
they ultimately decided to keep my theme or setup their own, then, I
haven't the foggiest, but I was happy to post it and prevent them having
to unnecessarily redo all the reordering I had already done.)
Thus, I'm quite wondering and worried about the new custom shortcut scheme
breaking what wasn't broken! =:^(
But I can't build ATM due to the gnome-doc-utils issue I just posted
about, so can't actually test the new behavior yet and all I have to go
on is the commit comment.
So, umm... is this supposed to be "new and improved" custom shortcuts
handling, or were you simply not aware of the old accels.txt mechanism?
If it's the former, I assume I'll be able to configure all the same
functionality, for the same shortcuts, even if I have to redo them
manually, correct?
If it's the latter, this might still be better if it has a reasonable UI
and/or a logically sorted config file. The old way seemed rather hackish,
but FWIW, it /is/ what the gtk-based claws-mail is using as well, with a
different filename of course, but because it used the same method, it was
rather easy for me to use the same techniques on claws-mail as I was
already using for pan, when I switched from kmail to claws-mail due to
kmail's akonadification. But I'm quite concerned that I don't lose the
ability to configure the same shortcuts for stuff that doesn't have
shortcuts by default, the old way, but that I was able to configure
shortcuts for using accels.txt.
--
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
_______________________________________________
Pan-devel mailing list
Pan-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/pan-devel
RSS Feed