KMessage/KMessageHandler: a core/ui seperation for displaying message.
englich at kde.org
Sun May 28 19:16:09 BST 2006
On Sunday 28 May 2006 17:06, Michaël Larouche wrote:
> I rencently wanted to make a notification framework for Kopete4 to replace
> all the KMessageBox in the code. Then Olivier Goffart remembered me of the
> thread "core/ui separation".
Nice work. My comments:
* It is heavy to make such a generic class as KMessageHandler a QObject for
the only purpose of memory management, imho(or is there any other reason?). I
would use a reference counting mechanism instead, since it doesn't decide
that all users should use QObject, and it is also a more flexible memory
* I would like to put KMessage and KMessageHandler in separate files to make
things easier to navigate/less to include, etc.
* Make the values in MessageType OR'able(1, 2, 4, 8), such that they later on
can be used in code which needs to say "I accept these kinds of messages",
and so on. Add "typedef QFlags<MessageType> MessageTypes;"
* I would put the private parts of KMessage in the cpp instead, since it's
public API. (Or no, it wouldn't work?) It would also be nice to get the other
private functions out of the public API. Since d-pointers should be added
anyway I guess they can be moved there(no?).
* Doxygen is automatically inherited from super classes, so it's not necessary
to @copydoc it(well, Adriaan, correct me on that if I'm wrong).
* I would tone down some of the test code: "You revealed Apple's secret and
you are now sued by them", and "Loading of kde_pron". I would come up with
* To me it looks like calling KMessage::short(type, text) is identical to
calling KMessage::shortMessage(type, text). If they're not, why/when would
one want to pass an empty QString to short()? I also think it's better to
code information about a message in data, instead of the name of a function
* What reasoning concluded KMessage::Sorry is needed? Debug, Warning, Error,
Fatal are all "message types" that can easily be distinguished and
motivated(imho), and they aren't controversial. For example, it's what DOM 3
Core and Qt happens to have. However, what is a message that is of type
Sorry? Why isn't a warning or fatal error of type Sorry? What is the possible
actions a message handler can do on Sorry? I think that a need of "Sorry"
originates from that this KMessage/KMessageHandler is insufficient in some
It could be an idea to abstract the message into its own class, "KMessage",
that instances of are sent to the message handlers. In this way one doesn't
have to distinguish between short/shortMessage, and users can sub-class
KMessage to make them carry exactly what they need. KMessage would have the
pure virtuals "MessageType type() const", "QString message() const", and
"QString title() const", perhaps. DOM 3 Core uses this design, obviously I
find it sensible.
I don't really get how this is supposed to be used. The purpose of message
handlers is to abstract the code, to give flexibility. That a global, static
message handler is used counter acts that. Who is entitled to change that
message handler? Some library in kdelibs? A user application? I don't know
about all usage scenarios this is intended for so it's a bit difficult to
comment and propose alternative solutions. All I can is that a global message
handler is limiting, and that one wants to move away from global things, not
More information about the kde-core-devel