Passive Notifications in Kate Part
by Dominik • November 6, 2012 • Developers, Users • 14 Comments
In KDE 4.10, Kate Part got a new MessageInterface. The idea of this interface is to have a standardized way of showing notifications in a non-intrusive way, similar to how KMessageWidget in kdelibs works. Using the MessageInterface is extremly easy, for instance to show a quick notification, you write
KTextEditor::Message *message = new KTextEditor::Message(KTextEditor::Message::Positive,
"Code successfully reformated.");
document->postMessage(message);
That’s basically it! The result looks like this (with a nice fade-in and fade-out animation):
As developer, once you called postMessage(), you can safely forget the message pointer. It’s automatically deleted either if the user closes the notification, or if the document is closed or reloaded. The API for more tricks. You can add multiple actions through KTextEditor::Message::addAction(), which then appear as buttons. For each added action, you can control whether triggering the action should close the widget or not.
Further, you can set an auto hide timer through Message::setAutoHide(int timeInMilliSeconds).
If you want a message to only appear in one specific KTextEditor::View of the Document, you just call Message::setView() before calling postMessage(). If several messages are in the queue, the one with the highest Message::priority() is shown first.
This notification system is already used in Kate Part by the data recovery (swap files), or to show a notification when loading remote files, and in some other places.
The cool thin is that this solution requires no special code in KateView or other classes, hence, it’s a perfectly clean solution with an easy-to-use API. You as KTextEditor user (developer) should definitely consider using it when it’s public.
Note: The MessageInterface is a KTextEditor interface; however, since the 4.10 branch is frozen for BIC changes, we cannot just add this interface for KDE 4.10. Instead, for Kate Part users (Kile, KDevelop, …) this interface will only be available in KDE5.
Finally, an example of all four message types: Positive, Information, Warning and Error:
So, do I understand correctly that tis does not use KMessageWidget internally? If no, what is the reason?
Of course, this is a very welcome addition, I just want to make sure I understand the implementation details right.
Thank you!
It uses KMessageWidget internally, that’s also why we have the same message types (Positive, Information, Warnung, Error)
The MessageInterface is just an easy to use thin wrapper that completely hides the implementation. So no worries!
Well done – the notifications look very nice.
Some small suggestion: The spacing between the notification and the window-border should be equal to other elements. For example: The Text-Input-Area has more space to the left window-border than the notifications. At the right side the notification should not be wider as the scrollbar.
Another small one: The spacing between the notification and the text-input-area should match the spacing to the borders.
I believe with those two little changes it would look even better.
)
Right, I’ll probably take a look into this in the evening.
The “[X] Some error occurred… (X)” notification has a significant usability issue IMO. I trip on it on Dolphin all the time.
The red square with white cross sign on the left looks too much like the red circle with white cross on the left.
I frequently try to click the left square to dismiss the notification, thinking that’s a clickable button. But it’s not…
Worse, the left square, being close to the text, on the left, tends to be closer to your point of eye focus, than the circle on the right, which with a wide enough window/screen, is almost on peripheral vision …
If this is really an issue, then it’s an issue of KMessageWidget. Still, I’m not convinced that this is really a usability issue. The actions including Close are all buttons intentionally, and thus distinct from the rest of the widget
I can not back up my view with a study, but I would follow Pedro Alves in this point. In KWrite, for example, the “red square with white cross”-icon is used, if “Quit” is added to the toolbar. As a suggestion, the complete notification area can be made clickable. A button would be cleaned from the interface, but perhaps discoverability of how to interact with the widget is lost.
I don’t know if I’m just another exception or whether it is really a usability issue, but I also agree with Pedro. Although I implemented the code in Dolphin to use KMessageWidget and did quite a lot tests with it, I still regularly click on the left ‘X’-icon instead on the right close-button. But as Dominik said: This must be handled inside KMessageWidget and submitting a request at bugs.kde.org would be useful (sadly I cannot do this myself anymore as I cannot promise having enough time for being responsive for any discussions on the submitted bug).
Hi Peter and others, thanks for your input. I wouldn’t have thought that so many of you (even developers) run into this problem. Maybe it’s really an issue. But then, I’m not an expert, so I’d like to point you all to bugs.kde.org and open a report
@Wolfgang: Making the entire area clickable is not really intuitive either imo, besides, we sometimes have more than one button, and e.g. if you make the entire area clickable, it’s not clear which action would be executed (think of the abort loading thing).
Peter, another question: In dolphinviewcontainer.cpp, you have the code
264 m_messageWidget->setWordWrap(false);
265 const int unwrappedWidth = m_messageWidget->sizeHint().width();
266 m_messageWidget->setWordWrap(unwrappedWidth > size().width());
Does this really work? If so, I’d consider using this as well, if the widget does not fit.
to answer my own question: no, it does not work, at least not in Kate…
What always bothers me is the coloring in that widget. Blue and green looks good but red and yellow are plain. I hope the widget on KDE side can be fixed for it. Meaning, red needs to be darker so it is visually stronger and white text on it. And green should be darker as well with white text.
What comes to icons on left, I would just make them bigger so they don’t look like a buttons. And then add right a button “close” instead a X.
Of cource none of these are possible to solve by Kate Devs in here.
Sorry about button. Just waked and hard still to concentrate
Well, that is not an issue of the KMessageWidget but more of the oxygen color scheme / default settings.
KMessageWidget just uses getColorsFromColorScheme(KColorScheme::NegativeBackground, &bg1, &fg); for the color (and adds a faint gradient to it), so you can change that color in System Settings → Application Appearance → Colors → Color selection → “Negative Background”