On 07/15/12 13:09, Thomas Lübking wrote:
I actually predicted that.
In EmbeddedWebView there's a
static const int constrainPadding = 72;
I see; that's probably what causes these gray areas around any messages
(right?).
If you raise that value to eg. 256 the issue is gone.
See comment above - we'd either have to tell the view the nesting level
or walk up the chain to the scrollParent and count EmbeddedWebView's on
the route to get a more precise idea.
Handing nesting level is faster, counting does not require API changes
-> your choice.
I don't have much of an opinion on this one, but given that
PartWidgetFactory::create() already knows the recursion depth, I think
that it wouldn't matter to pass that data to QWebView as its gets
created from this function.
So it looks like I actually have my opinion after all :).
The thing that's really missed in QMessageBox is the "[x] Don't show
again" checkbox.
The patch just warns once per session - could turn out to be too
annoying (ie. "don't tell me stupid computer" checkbox would be
mandatory - could still be done with a real QMessageBox instance - just
ask)
Ah, thanks for the patch, but I'm afraid I've just wasted your time
through my unfortunate choice of words :(. The thing is that I did not
want to introduce a blocking popup (a QMessageBox), but something like
KMessageWidget [1] [2] -- a simple widgets which appears as a part of
the window, not on top of it, so it's much less annoying. If you're
familiar with Rekonq, that's how it asks whether one wants to resume
previous session on startup after it crashed. Clean, not so intrusive.
Sorry that my wording of a "passive pop-up" caused this confusion.
Using that widget in Trojita would like require quite some porting,
though -- a hard dependency on KdeGui is something which I absolutely
don't want to do at this point. On the other hand, this widget should
then be used instead of that "load external elements from the web" in
the message view as well.
If you choose to go this route, please make it is a four-state widget:
- CONTEXT=SORT and CONTEXT=SEARCH both supported => don't show any
notice ever
- CONTEXT=SEARCH supported, CONTEXT=SORT unsupported => warn only when
sorting
- CONTEXT=SORT in there, CONTEXT=SEARCH missing => only warn when
searching (but I'd really like to see a server doing this thing...)
- both missing => A single message mentioning both sorting and searching
being slow should be shown when any of search/sort mode is active
In fact, it might be a five-state widget after all:
- SORT extension missing altogether => upon clicking the header, show a
notification about lack of the SORT extension
Anyway, all of the above is in the "nice to have, not necessary at all"
category. If you'd like to implement it, go for it, if anything else is
more important for you, do whatever fits you better.
Cheers,
Jan
[1] http://kate-editor.org/2012/07/08/rfc-data-recovery/
[2]
http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKMessageWidget.html
--
Trojita, a fast e-mail client -- http://trojita.flaska.net/
