KDE Telepathy 0.4 -- feedback requested

[Koriun]

right click on the systray's arrow, select System Tray Settings, It can be added under the Extra Items section

You think it can be there. but it is not there.

[claydoh]

.

another thing I haven't found in telepathy is the icon in the tray area.. any hint to enable it?

right click on the systray's arrow, select System Tray Settings, It can be added under the Extra Items section

[Koriun]

yep, I need proxy support as well.. I was able to use gtalk in kopete behind proxy using a different server and a different port (443) but it is no more possible.

another thing I haven't found in telepathy is the icon in the tray area.. any hint to enable it?

Also in many cases it is not possible to overwrite default server/port.

@lucazade: are you sure that u used gtalk behind proxy ?

[lucazade]

Hello,

I would like to use KDE native IM instead of pidgin. But the problem is that kopete can't access to network via proxy.
And Telepathy which is going to replace kopete also cannot access to network via proxy too.

For several protocols (ICQ, Facebook, googletalk) there are proxy setting, but it is not well designed and it is seems that set value is not used (No connection to networks)

i can do any kind of checks/tests to be helpful to KDE Telepathy project.

OS: Kubuntu 12.04, KDE 4.8.4

yep, I need proxy support as well.. I was able to use gtalk in kopete behind proxy using a different server and a different port (443) but it is no more possible.

another thing I haven't found in telepathy is the icon in the tray area.. any hint to enable it?

[Koriun]

Hello,

I would like to use KDE native IM instead of pidgin. But the problem is that kopete can't access to network via proxy.
And Telepathy which is going to replace kopete also cannot access to network via proxy too.

For several protocols (ICQ, Facebook, googletalk) there are proxy setting, but it is not well designed and it is seems that set value is not used (No connection to networks)

i can do any kind of checks/tests to be helpful to KDE Telepathy project.

OS: Kubuntu 12.04, KDE 4.8.4

Looks good, with this release I can connect to my company's Jabber server using SSL with a self-signed certificate. This did not work in the prior release.
Was also able to set my avatar picture and transfer a file.
I can finally switching from Kopete to Telepathy for Jabber, which I wanted to do for a while because the Kopete systray icon never worked and that was most annoying.

Would be great to see this appear in the 12.04 backports, thanks!

Here is my feedback: Everything is working quite well, except for the quick chat which I could not figure out or get to work, either way its a mystery. The contact list widget and the individual contact widgets can't yet go into a panel, which is frustrating. You also have no group view in the contact list applet, which is not so great if you have as many contacts as I do. As far as stability is concerned its working well. I haven't had any issues so far.

[buzzmandt]

so my kde-telepathy has been working very well until today, now it wont connect. account manager just shows 'connecting......'

[SteveRiley]

...URLs from KDE maillist...

Thanks, Sumski. Looks like I need to join that list.

[jovin]

Hmm. My avatar is still not shown and my name is always set back to my ICQ number. Pretty much like the previous version.

Grrr.

[sumski]

http://mail.kde.org/pipermail/releas...ay/005645.html
http://mail.kde.org/pipermail/releas...ay/005668.html
http://mail.kde.org/pipermail/releas...ly/006164.html
http://mail.kde.org/pipermail/releas...ly/006196.html

[SteveRiley]

For a moment let's just forget that KDE's secret storage implementation is not finished and apparently only semi-maintained right now.

This is curious. KWallet, which does a reasonable job of staying out the way when you don't put a password on the wallet itself, seemed to work well enough. I recall the discussion around replacing it with KSecretService. But can we interpret your sentence to mean that KSecretService has been (possibly only partially) abandoned even before it's finished?

[kubicle]

Actually there is. For a moment let's just forget that KDE's secret storage implementation is not finished and apparently only semi-maintained right now. There is only one glib-only general purpose library to access the upcoming cross-desktop-secret-storage system and that library is libgnome-keyring. So the well designed cross-desktop system actually will want to use libgnome-keyring as there is no other viable candidate short of reimplementing the entire client-side shebang.

Umm...I'm not sure I follow the logic. Doesn't that sound more like a choice made out of (perceived) necessity rather than (solid) design?
(And one could have a differing opinion on how "cross-desktop" that secret service currently is)

Simply because a library has gnome in the name does not mean it depends on other gnome components nor that it is not cross-desktop.

We would have to define what we mean by "cross-desktop", I'll give you that libgnome-keyring has light dependencies since that is your view of cross-desktop apps (to me cross-desktop means at least some collaboration in the development, perhaps I'm in the minority with my cynical views).

And my issues are not really centered around libgnome-keyring, it's just one of the telepathy dependencies...and I don't really mind the other dependencies themselves either, I use some gtk/gnome software regularly (I'm not a complete fanatic )

My main gripe is relying on the "cross-desktop" backends that are solely developed by the G-men...you can be sure you'll get the shorter end of the stick every single time (the shorter end might be enough in many cases, but let's not pretend it's the Holy Grail). EDIT: I don't want to imply any malice on their part, it's just that gnome is what they know best, and probably what their employers (when applicable) set their priorities on.

[apachelogger]

I'm aware of that (and Steve mentioned in an earlier post), but there really is no reason why a (well designed) cross-desktop backend would have such hard dependencies.

Actually there is. For a moment let's just forget that KDE's secret storage implementation is not finished and apparently only semi-maintained right now. There is only one glib-only general purpose library to access the upcoming cross-desktop-secret-storage system and that library is libgnome-keyring. So the well designed cross-desktop system actually will want to use libgnome-keyring as there is no other viable candidate short of reimplementing the entire client-side shebang. Simply because a library has gnome in the name does not mean it depends on other gnome components nor that it is not cross-desktop.

[kubicle]

My statement was directed at those who may get the impression that the gnome key itself would be installed and run by installing this.

My mistake. I thought you were talking to me.

A valid point that need to be looked at, hence the testing and input :arrow:

I can't deny the feature set and plasma integration are nice, and it indeed might currently be the right way forward (I might be tempted to overlook the possible issues if I used IM more). And I do appreciate the efforts of everyone involved.

Even NetworkManager is in pretty good shape now (but it took literally years to get there).