KTp/Components/Chat Window: Difference between revisions

From KDE Community Wiki
< KTp
Line 2: Line 2:


==About Kopete's Chat Window==
==About Kopete's Chat Window==
==Design Decisions==
===Why not straight porting Kopete's window?===
===Why not straight porting Kopete's window?===
Kopete's Chat window is overly complex and deeply integrated with Kopete's internals, hence it is quite impossible to do a full porting without losing time and mental sanity. However, there are some things we can learn and even pick from Kopete.
Kopete's Chat window is overly complex and deeply integrated with Kopete's internals, hence it is quite impossible to do a full porting without losing time and mental sanity. However, there are some things we can learn and even pick from Kopete.

Revision as of 17:38, 7 February 2011

This page is about planning and design of Telepathy's Chat Window

About Kopete's Chat Window

Design Decisions

Why not straight porting Kopete's window?

Kopete's Chat window is overly complex and deeply integrated with Kopete's internals, hence it is quite impossible to do a full porting without losing time and mental sanity. However, there are some things we can learn and even pick from Kopete.

Mistakes which we should not repeat

  • I'm all for modularity, but having a KPart for each component statically referenced in the core is possibly something we don't want to repeat
  • Think about the future: try having an higer level of abstraction and avoid using custom widgets wherever possible

What we can pull

KHTML code looks quite fine, and theme support as well. Also, some bits here and there could be definitely ported over.

About our new chat window

Components modularity and integration

In my view, we would have a chat window almost identical to KMess' one: a single (tabbed) window, with a contact list, input+actions field and message view for each tab. KXMLGui can really come handy here, but I'd like to avoid using KParts as it really does not make a lot of sense to me, when we can simply use a set of widgets.

Interface

What comes to my mind is that the use case of such a window is similar to rekonq or chrome. Hence, the principle of ditching the menu bar could be appliable here as well (P.S.: the official MSN client already does this, IIRC).