Hi David, thanks for your interest. As you've probably noticed, there's a lot of rough edges in Trojita. I'm trying to improve them (I definitely want to use this application myself) and Thomas has been a tremendous help in as well, which is great, but it's a rather slow process. If you'd like to start sending patches in, definitely go ahead!
Answers below. On Sunday, 28 October 2012 07:00:45 CEST, wrote:
First, and the biggest one, what keyboard shortcuts are defined (and how do I find them)
Thomas has already answered on how to find them. There are also some carefuly hidden gems like "m" for toggling the \Seen flag, "n" for going to the next unread message and "p" for the previous one, but even these are visible in the pop-up menu (right-click on a message for that). Right now, there are not many defined shortcuts, though. GUI usability has always been something of a second-importance for me; I've found it much more fun to focus on playing with IMAP and implementing the low-level stuff "right". I'm also afraid that keyboard shortcuts cannot be made perfect for everyone (some people come from Mutt, others from Alpine, yet others from Thunderbird or KMail), so I just kept postponing them forever -- the ostrich's algorithm can be surprisingly effective. I believe that adding a GUI for configuring them is the only reasonable choice in the end, but as you probably realize, coding that is much more boring that implementing message threading :). I do realize that it's a very short-sighted approach and that it hurts usability very much -- and I'd like to improve this now. Actually adding the keywords would be trivial, Qt has excellent support for that, as Thomas has already mentioned. Thomas, do you know about some semi-reasonable Qt library which would manage the GUI for configuring keyboard shortcuts for me? (Short of the whole of KDE, if possible -- that's a dependency which is too big to require unconditionally.) If no such thing is available, would you find something like this to be reasonable: - don't create QActions directly, call out to some factory class for that - the factory class is driven by an enum of some kind to know what action to return - the enum is used as an index to a big table of metadata for actions, each of them having configurable shortcut through QSettings - a GUI can be added which would just enumerate the given enum range and allow the user to override the shortcuts - thinking about it a bit, the cleaner way would be to hove some macro-assisted classes so that adding a new action is a one-liner I guess I'll show some code later, this is something which has cought my interest :). Let's track this at [1].
Second, is there a way to eliminate the preview pane? If I've got a spammy message that I want to delete, I don't like the idea of it being opened in the process of clicking on it to delete it.
Not right now. I've been thinking about adding an apline-like mode where you would browse the mailbox hierarchy at first, then upon selecting a mailbox you'd see just a list of messages, and finally by selecting a message you'll see just that. However, just hiding the message pane, as you've proposed, might work better. If you're interested and have some C++ knowledge, I'll be happy to accept a patch adding a third viewing mode, similar to the existing "classic" and "wide" ones. I've added a feature request [2] so that this doesn't get lost.
I also tend to want to have a larger chunk of index data available than I can get with the preview pane (even in wide mode, too much width is taken up.
I'm lost here -- could you please rephrase this?
Third, I love the debugging windows, and especially like the fact that they can be pulled out of the main GUI, but unfortunantly they are always on top of the main GUI. It would be nice if I could have them peeking out behind the GUI for me to keep an eye on, without them being in the way.
I suspect we cannot do much about this -- my knowledge of X11 internals is non-existent and Thomas suggested that it cannot be done easily. But Qt should remember the positions of the docks (at least until the application's exit), so you can just close each dock -- they should appear at the exact same place when you enable them again. Maybe with configurable keyboard shortcuts for showing/hiding them, you'd have all features you actually need here? With kind regards, Jan [1] https://projects.flaska.net/issues/565 [2] https://projects.flaska.net/issues/564
