Version: 0.70.0 (using 4.2.00 (KDE 4.2.0), 4.2.0-15.fc10 Fedora) Compiler: gcc OS: Linux (x86_64) release 2.6.27.19-170.2.35.fc10.x86_64 I've setted the proxy settings in KDE system settings, but since I only access through proxy, I cannot connect to the IM's, like jabber (google), WLM and ICQ. If some debug info is needed please let me know. Best regards, Paulo Fidalgo
Since i believe those proxy settings only apply to things that use kio_http, that would be why the settings don't work.
Looking through the sources, I've noticed that there are generic way to use proxy in for different protocols. But now, this proxy factory is not implemented. Moreover, the usage of proxy settings is dropped while porting from kde 3.5.
Does still not work in KDE 4.3 Beta 1 (4.2.85) on OpenSuSE 11.1. This is the only reason I have to keep using Pidgin.
*** This bug has been confirmed by popular vote. ***
AM using kde 4.3 RC3 on kubuntu and i can confirm that kopete still doesnt work with http proxy, it doesnt have any UI for configuring http_proxy and doesnt respect the one configured in the kde systemsettings network proxy. i had to use pidgin for my IM needs but its always feels out of place. like its belong to another world (which is is) so please it would be nice if a kind soul can code the functionality into kopete. i would have if i could have
Is any kopete dev even looking into this ? I see that the severity of this bug is normal i would think that critical would be a more correct value because until this bug is fixed most people that would like to use kopete at work won't be able to.
Can someone please explain what the "Use proxy instead" option in the Account Preferences actually does if it doesn't tell kopete to use the proxy settings?
The "Use proxy instead" relates to file transfers. It will make those relay through some central server instead of being handled via direct IP connection.
seems i would never live to see the day kopete would support http-proxy. this has be one of the oldest bugs in the history of FOSS kde, Its really sad because Kopete is the only secured IM client which would could be used in an Enterprise Environment due the way it secures passwords (unlike pidgin) At the same time it cant be used because it doesn't work behind a network proxy found in many Enterprise set up
That is so true. I'm waiting (patiently) since the year 2003 for kopete to get a proxy support. It has prevent me to use it in every place I have worked (several universities and several compagnies, which all were using a http proxy). Please beloved developers, this bug is the most critical bug of Kopete right now and should be definitely solved one day!
Excuse me. There is some hope that this bug is resolved?
I've lost hope so i've moved on to using Pidgin as my instant messenger.
Same here. This bug is one of the oldest in the history of free desktop and from the response of the kopete developers I don't see this would ever be fixed. Kde really needs a new IM system if its ever going to complete the social desktop desktop user experience. I have since moved to pidgin -- Sent from my Nokia N900 ----- Original message ----- > https://bugs.kde.org/show_bug.cgi?id=186872 > > > > > > --- Comment #12 from Hugo Palma <hugo m palma gmail com> 2010-01-22 12:14:31 --- > I've lost hope so i've moved on to using Pidgin as my instant messenger. > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are a voter for the bug. > You are on the CC list for the bug.
*** Bug 210684 has been marked as a duplicate of this bug. ***
*** Bug 216219 has been marked as a duplicate of this bug. ***
*** Bug 220771 has been marked as a duplicate of this bug. ***
SVN commit 1131073 by shaforo: make kopete respect global KIO proxy settings when connecting to ICQ. It uses 'https proxy' field of Systemsettings -> Network -> Proxy dialog. CCBUG: 186872 CCBUG: 236721 M +24 -1 oscaraccount.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1131073
WLM plugin already has proxy support: http://websvn.kde.org/?view=revision&revision=987423 (available in KDE 4.4)
(In reply to comment #18) > WLM plugin already has proxy support: > http://websvn.kde.org/?view=revision&revision=987423 (available in KDE 4.4) I can't make it work (with http proxy), using account settings.
do pidgin or other win32 apps work via your proxy?
win32? i'm using (In reply to comment #20) > do pidgin or other win32 apps work via your proxy? win32? AFAIK some people is using WLM there. I will try amsn in my laptop tomorrow and tell you. Thanks.
(In reply to comment #20) > do pidgin or other win32 apps work via your proxy? Defenitely, yes. Any of (licq, psi, pidgin) works well. ps: our corporate proxy is squid/2.6.STABLE17
(In reply to comment #20) > do pidgin or other win32 apps work via your proxy? It works with pidgin, but through http method. Maybe this is the problem.
SVN commit 1138562 by shaforo: add UI for proxy parameters configuration to ICQ account preferences dialog. it will be more obvious to users as to where to configure proxy settings for ICQ. and it is done the way WLM protocol plugin does. future plans include: -proxy requiring authentication -SOCKS5 -system-wide proxy/account-wide proxy selection CCBUG: 119806 CCBUG: 186872 CCBUG: 236721 M +229 -211 icq/ui/icqeditaccountui.ui M +17 -2 icq/ui/icqeditaccountwidget.cpp M +29 -5 oscaraccount.cpp M +8 -0 oscaraccount.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1138562
Thanks for your efforts, kopete really needs more love. As i understand, proxy support should be implemented in each protocol? Would be great to have proxy support for jabber protocol as well. Or maybe implement some global proxy connection framework for all protocols...
It seems that the solution being implemented is having custom proxy settings for kopete and for each individual protocol. Is this true ? If so, it doesn't make any sense to me. Please, just change kopete so that it uses the KDE configured proxy settings.
(In reply to comment #26) > It seems that the solution being implemented is having custom proxy settings > for kopete and for each individual protocol. > > Is this true ? > If so, it doesn't make any sense to me. > Please, just change kopete so that it uses the KDE configured proxy settings. Hi, I think the problem here is not only using proxy settings to work but it should be also implemented methods to access IM server through the http protocol.
(In reply to comment #27) > (In reply to comment #26) > > It seems that the solution being implemented is having custom proxy settings > > for kopete and for each individual protocol. > > > > Is this true ? > > If so, it doesn't make any sense to me. > > Please, just change kopete so that it uses the KDE configured proxy settings. > Hi, > I think the problem here is not only using proxy settings to work but it should > be also implemented methods to access IM server through the http protocol. I get that it's not trivial. But it's simply annoying that an application that only functions when connected to the internet doesn't support proxies when this has been reported 2 years ago.
(In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #26) > > > It seems that the solution being implemented is having custom proxy settings > > > for kopete and for each individual protocol. > > > > > > Is this true ? > > > If so, it doesn't make any sense to me. > > > Please, just change kopete so that it uses the KDE configured proxy settings. > > Hi, > > I think the problem here is not only using proxy settings to work but it should > > be also implemented methods to access IM server through the http protocol. > > I get that it's not trivial. But it's simply annoying that an application that > only functions when connected to the internet doesn't support proxies when this > has been reported 2 years ago. Yes, the problem here is not how it is implemented, but just that it doesn't work (I don't know for icq)
The reason none of the previous patches will work is because the wrong assumption people get from the badly designed QNetworkProxy class. I am specifically talking about the HttpProxy and FtpProxy types specified in the afforementioned class. Unfortunately unlike SocksProxy and HttpsProxy (which also is badly labeled AFAIAC), the former types are only application when used in QNetworkAccessManager, not low level classes like QTcpSocket that inherit from QABstractSocket. If you chose to use QTcpSocket, then you have to connect to the proxy server yourself, just like QNetworkAccessManager would. You cannot simply call the setProxy(...) like it is currently done in both of the patches shown in this bug report. Anyhow, good luck...
Git commit c3ebe03d3fb61659e59ce58d1f452cd2d5cac16a by Pali Rohár. Committed on 20/05/2014 at 00:00. Pushed by pali into branch 'master'. Add support for system proxy settings via KProtocolManager in ICQ protocol Related: bug 236721 M +1 -1 protocols/oscar/icq/ui/icqeditaccountui.ui M +12 -17 protocols/oscar/oscaraccount.cpp http://commits.kde.org/kopete/c3ebe03d3fb61659e59ce58d1f452cd2d5cac16a
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.