KDE Telepathy 0.4 -- feedback requested

[jovin]

I'm going to try it out.
Excited to see the changes and all.

[claydoh]

On my installation, I'd get libgnome-keyring and libgnome-keyring-common, but not libsoup-gnome (I don't use gstreamer), is telepathy hardcoded to use gstreamer?
I've said it before, but telepathy's so called "cross-desktopness" is rather overrated. Poor design, bad implementation...(and I don't mean the kde-telepathy parts, you can only work with what you've got).

Do note these are the support libraries, not the actual keyring for anyone worried that KTP installs the gnome password manager.

They really need to invent a name for this, as telepathy is the backend framework used by KTP and Emapthy im clients.

[kubicle]

Do note these are the support libraries

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.

Don't see the issue.

You will, once everything starts breaking every time telepathy is upgraded. It's going to be NetworkManager all over again.

I don't really object releasing with it, as there are no major version upgrades allowed after a release (although when the ubuntu devs upload a new version of telepathy just before the release freeze, you'll get the usual *shrug* when you mention that the current telepathy-kde doesn't work with it)...but the thing is coming nowhere near my machines.

[claydoh]

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.

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

You will, once everything starts breaking every time telepathy is upgraded. It's going to be NetworkManager all over again.

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

[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).

[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]

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.

[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?

[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

[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.

[SteveRiley]

...URLs from KDE maillist...

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

[buzzmandt]

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

[Guest]

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.

[lasse]

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!

[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