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 <henm...@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@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-devel
