On Thursday 26 October 2006 19:31, Michaël Larouche wrote: > I had a small discussion with Robert McQueen about my questions and nothing > to worry about :) > > > - 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 :) > > A general list of parameters is specificied in the spec. But using a > dynamic way for managing protocol parameter would be a idea to consider, to > have 3rd-parties UI configuration for new connection managers. > > Also if I remember to do it, I will retalk to Telepathy guys about creating > a spec just for protocol parameters. > > > - Creating a list of "certified" connection managers tested and reliable > > with Kopete > > > > We should create a list of certified and tested connections manager that > > ensure that work well with Kopete. Like integrate well into Kopete UI, > > support most features of X protocol. I'm pretty sure many advance users > > will complain about X protocol not working because of that connection > > manager. > > > > In short, going the Telepathy way will maybe make the user support more > > complicated because we have more variable configurations. So if we have a > > list of supported connection managers, we could tell the user "Hey use a > > supported connection manager !" ;) > > No problem on this side. >
What do you mean "No problem on this side"? Care to elaborate? > > - 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. > > For proxy, we just need to use "http-proxy-server" parameter. For the rest > I'll discuss that with Telepathy folks in time. But nothing is impossible. > > About audio/video: > > <Robot101> and don't worry about audio devices > <Robot101> connection managers don't use them > <DarkShock> that's the job of the streaming engine ? > <Robot101> well, we're going to make it into a library if possible > <DarkShock> ok > <Robot101> so you can just take gstreamer src/sink and hook it up, then > point the library at the channel > > > - 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. I'm thinking > > about Service discovery in Jabber. Robert McQueen talked about maybe > > doing interface for specific protocols in Telepathy specification. > > This is a low priority for Telepathy guys and they want to make > it(Telepathy) work without exposing protocol specific interface in the main > interface. > > To quote Robert: > "<Robot101> the idea is to make most stuff work without exposing > protocol-specific madness like that" > > > - 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. > > Somehow the UI in the current protocol will migrate to the main > application. Time will tell :) That will be interesting to see. -- Matt _______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
