Le October 22, 2006 12:15, Olivier Goffart a écrit : > Le dimanche 22 octobre 2006 17:43, Michaël Larouche a écrit : > > I have some thoughts messing up in my head about Telepathy adoption. This > > maybe look weird from the guy who volunteer to do the testbed Telepathy > > plugin but these points need to be taken into account. > > > > - Mapping configuration GUI to connection manager key/value configuration > > > > This is my short term concern about Telepathy adoption. Each connection > > manager has different key/value for a defined protocol. We can't show a > > raw key/value UI to the user, like the current basic UI in Telepathy > > plugin. So we need a set of UI configuration template for each protocol. > > How we will manage those templates ? In plugins ? As a fallback for an > > unknown protocol and/or connection manager, we will use the basic > > key/value UI until someone made a UI for it. > > > > Maybe we should considerate creating those UI using Kross and/or KJSEmbed > > for easy deployment, update and creation, and require no compiling :) > > Is there something equivalent to the jabber:x:data forms that could be used > to generate ui dynamically ? > (ie: does the connection manager export the list of possible keys ?)
Of course you can request the possible parameters. But they are no equivalent of jabber:x:data or XForms or whatever. > > - Creating a list of "certified" connection managers tested and reliable > > with Kopete > > [...] > > > - Respect of KDE settings (Proxy, Phonon, Address Book, etc...) > > > > They are some bug report about some protocol plugin that doesn't respect > > the KDE proxy settings. How do we ensure those settings are respected > > using Telepathy. > > > > Also for the voice and video, we will need to tell the connection manager > > to use those devices and settings from Phonon configuration. > > In others words, that mean that we almost have to write a KDE connection > manager for each plugins. > > So IMO, we should keep kopete as it, and have > - official supported protocols: kopete protocols > - unofficial protocols: for advanced users: telepathy connection manager > using the telepathy protocol No, we just need an interface to push those setting in the connection manager and read them from KDE config. > > - Specific interface for type of protocols, to not loose specific > > functionality of each protocol (disco search in Jabber) > > > > This is about regression of features. The main point of Kopete is to > > integrate many protocols into a consistent interface but without loosing > > the native features of protocols. This is one reason I started using > > Kopete(or any similar program) because I wanted multiple native support > > for each protocol, which is not the case in Jabber Transport. I was tired > > to switch to a native MSN client just to transfer file. > > BTW, pyMSNt has now reliable MSN file transfer support. I know, but I will still not use Jabber transports today. > > I'm thinking about Service discovery in Jabber. > > Robert McQueen talked about maybe doing interface for specific protocols > > in Telepathy specification. > > I'm not in favor of this? There is already an existing powerfull protocol > for showing UI which is called X11, and his library XLib (or some wrapper) > > So if connection manager have an UI, they should show them directly. > Which also mean of course different appearance depending the used toolkit. > (but there will always be difference, because kde's ui will follow his own > HIG) > > - What about the UI in protocol plugin ? > > > > What we shall do about the UI in protocol plugin ? We can't use them > > anymore since the implementation is separated by D-BUS. > > That's the same problem as above, is it ? Yes, this is similar to the configuration GUI problem. > -- > Olivier -- Michaël Larouche KDE developer working on Kopete, Gamefu(KDE), Solid...on dial-up :P -------------------------------------- Website: http://www.tehbisnatch.org/ MSN: [EMAIL PROTECTED] IRC: irc.freenode.org/DarkShock Jabber/email: [EMAIL PROTECTED]
pgp6YcN7K23Fz.pgp
Description: PGP signature
_______________________________________________ kopete-devel mailing list kopete-devel@kde.org https://mail.kde.org/mailman/listinfo/kopete-devel
