On Mon, 31 Jan 2011 00:23:46 +0100 Jan Kundrát <[email protected]> wrote:
> Hi Niklas, > I see you already subscribed to the mailing list, so I'm simply > replying there as well. I hope you don't mind. Can I bounce both of > your messages to the ML so that the archives contain the whole > history of this thread? I resent my last one to the ML ten minutes after I sent it to you -- I would have done that in the first place, but PEBKAC... > To be honest, I wasn't even aware of that feature when I wrote that > part of the code. Now I wonder what's better, having all values stuck > together in the config file, or breaking existing users' > configuration? If we want to perform the change, the sooner the > better... Well, I've added the settings I need to gui/. It occurred to me that most if not all of the other settings are directly related to the IMAP account -- so how to change it probably ties in with how it's going to handle multiple accounts. It's going to handle multiple accounts, right? ;-) > Cool. A feature often found in other MUAs (and I guess it's quite used > today with all the wide-screen panels) is having the whole window > divided into three columns instead of just two, so that you get a list > of mailboxes, a list of messages and then, in the right-most column, > the actual message. Nobody requested that so far, but I guess it > would be nice to have if you have time and motivation for that. Well, to just split the window vertically into three is trivial (just change the orientation of the splitter!), but it only really makes sense if you have a different style of widget in the list view, I think, with the subject above the autor name or something. Else it becomes too wide. > And one more thing for the toolbar -- when I look at a pure Qt project > like Arora, I see they do not offer "basic" things like user-definable > keyboard shortcuts for various QActions, It's a pity, and of course > Trojita currently doesn't have anything like that either. I don't want > to depend on kdelibs/kdeui at this point, but if you came across a > reasonably small library which would deal with that, I'd be all in for > integrating that, too. KDELibs should definitely be avoided. I'll be on the look-out. nn
