Le lundi 31 juillet 2006 13:54, Michel Hermier a écrit : > Hi, Hi.
First, id' like to definite and delimit what libkopete is. for me, libkopete is just the layer between plugins (that include protocols) an the kopete application itself (that include the contactlist ui) libkopete has to maintain binary compatibility when it reach Kopete 1.0 For that reason, libkopete should be as small as possible, with a clean API. So the more we can move out of libkopete, the more it will be easy to maintain a clean API (without being excessive). Also, the more Kopete is modular, the more it is easy to maintain. > I would like to propose the separation of libkopete in to part. > The libkopete (core) which would contains the core objects. > And libkopeteui which would contains all the gui stuff from > libkopete/ui, libkopete/private, libkopete/avdevice and some of the > kopete application ui (for the default ui). > The libkopeteui would be to provide the standards object interface to > access and manipulate the gui. I don't think it is a good idea. Most of stuff which is currently in libkopete/ui is really an interface between plugins and the application. AddContactPage , KopeteView, EditAccountWidget are good examples. This is good But the implementation itself of the UI must stay outside of libkopete IMO > What is bothering me a lot with current code is that we can't reuse it > for plasma integration (and KPart). That's another problem. You can make the contactlist a kpart, this doesn't require it to be in libkopete. I personally would like the idea. > One of the main example is the contact list, one would probably ask to > put the contact list on the desktop (this was done via plugin). But > what the plugin has to do ? Handle the dcop communications, and fill > the contact list ... In fact reimplement all the code from the core > kopete application (at the exception of the dcop/dbus communications). I don't see at all how your proposal fix the problem Better dbus interface is probably a solution. What code from kopete need to be reimplemented ? > Another example would be the chat windows. They can't be really > skinned. What to do if a user want the look and fill of X or Y. With > this we could simply create chat window plugins, without changing the > core lib. Complex problem, but again you have not the solution. Most component of the current chat window are already in their KPart (and then re-usable). That's the case of the ChatMessagePart and of the KopeteTextEditPart. And chatwindow is already in a plugin, so it is possible to have another chatwindow plugin if you want another skin. Also, what would be nice, is if plugin would be able to add component to the chatwindow. It is already possible to add them as toolbar widget, but that's really ugly!!! hopefully with new IDEAL interface it will be possible better. > As I see it libkopeteui would use libkopete directly in a first time, > and go dcop/dbus/kpart, in a second time. dbus and kpart should not be a part of libkopete. I'm even wondering if it wouldn't be a good idea to put the dbus interface in his own plugin. So to conclude, we should cleanup libkopete and remove stuff from it instead of moving stuff inside. We may anyway rework the kopete/kopete/ part in order to modularize it.
pgp7UHftXwjYM.pgp
Description: PGP signature
_______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
