Am 10.07.2012, 20:30 Uhr, schrieb Jan Kundrát <[email protected]>:
- Starting in the wide layout, going to compact, the message widget gets wider. That's correct as it has to fill up space which is suddenly bigger. However, going back to wide, its "big width" remains and one has to scroll even though it isn't really required. That'd be nice to get rid of. [...]
Ok, *that* turned out to be an interesting challenge (the reason for the comm lag ...)
No, i had not read through QWebView sources - yet.The solution (after maaaany weird attempts ;-) luckily turned out to be rather straight forward. Also it's not recursion prone, but please test it nevertheless (i've just finished today. Tested and works, but well ... we'll see)
- When I disable "show trojita's homepage on startup", the viewer shows a small black bar at the top of the page when I launch Trojita. Just a cosmetic issue.
It's pixmap garbage in an EmbeddedWebView. Gone with the updated patch.
I said "please spam me" - but it will i doubt this is still a case. The approach has changed fundamentally.- With a certain HTML message which I won't post to the ML (but can forward to you if you cannot reproduce that, it's some marketing crap),
- The MessageView takes too much vertical space; opening up your e-mail
I assume "no more" (please...)
I've seen you've meanwhile been anything than lazy and also added the patch - thanks alot.All right, my bad, this is because the searching API will try to treat the passed data as something which has to be transmitted using the
A proper fix would be to change the API to accept a "reasonable" data structure capable of conveying complex search criteria; however, this is something which I really don't want to do right now due to time constraints. Redmine #528 [2].
ACK
widget, and that looks like a more straightforward place for me. Your patch moves them to the right, reducing the space for the input box -- do you really want to do that?
No. I want to get rid of those buttons :-)
In future, I'd like to have a full-blown searching dialog -- no doubts about this one, I agree, absolutely. I think that it can be separate from how the quick search works, though. [...] Yes, a GUI for building that query is a must for normal users, I agree. I'm not convinced that it has to support actually parsing the raw user input in the IMAP format; if it was just a GUI capable of generating the query, it'd be perfectly acceptable for me.
I think that's what i had in mind - will be next task. Should be much simpler than weird size constraining =) I'll just write what i have in mind and you say whether you like it or not.
No, i did not intend to actually parse it, but perform a minimium sanity check (like does it contain uppercase IMAP commands, nobody searches like that)That said, if you feel like having support for entering the raw query directly *and* having it parsed in the GUI at the same time is the way
If you hit an issue or aren't sure about how to proceed or just stumble upon something "weird" in there, please don't hesitate to write a mail.
I will - but not necessarily.
It doesn't work if the server lacks the sort extension (gmail... unbelievable.)I'm a bit confused here -- the sort-by-click-on-the-header is implemented and should work; the menu control is there just to make sure users can notice that functionality. Is that what you're referring to?
--- t0 capability* CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH
---I've a QnD patch to at least swap order on clicking but would prefer a deeper approach with better visual feedback
It's possible to implement a tristate header, ie, click: ascending; click: descending; click: unsorted; click: asc...Finally, without the explicit menu, it might be problematic to "undo" the sorting; users would have to click on the "Seen" column to revert back to "no sorting, use the mailbox order".
I don't intend to change that just because gmail lacks that feature - i just want better handling in the GUI.Anyway, right now Trojita will only do a server-side sorting; doing that
Ok, I wasn't aware of that (and behind a 32MB line actually wouldn't care, but oc. /do/ see the point)is a pretty expensive operation). At the same time, this server-side thing has a few issues as well; it will obviously not work when offline and unless the server supports CONTEXT=SORT (no server supports that AFAIK), a newly arriving message leads to another request for complete sorting, which leads to "at least" 280kB of data to be downloaded on a mailbox with 50k messages [2].
In that case i'd suggest to disable the headers (so they won't show any hover indication etc.) Yes, oxygen has no hover indication, but virtually all other styles have ;-)All of that makes me feel that the GUI shall "hint" the user that they don't really want to activate sorting, unless they really do
No, suites me - i'll do (you may now conclude that i stopped reading the mail quite somewhere up and bite me into the messageviews ... ;-)As a last thing, if you'd like to contribute to Trojita, please consider subscribing to the mailing list, it's pretty low traffic and I'd much prefer all relevant people in there. If it doesn't suite you for some reason
Cheers, Thomas
0001-improve-message-design-and-layout.patch
Description: Binary data
