KMessage/KMessageHandler: a core/ui seperation for displaying message.

[Frans Englich]

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 
management mechanism.

* 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 
other texts.

* 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 
call.

* 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 
cases.

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.[1]

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 
increase it.


Cheers,

		Frans

1.
http://www.w3.org/TR/DOM-Level-3-Core/core.html#ERROR-Interfaces-DOMError