reading KDE configuration doesn't work

[GoogleCodeExporter]

Reading KDE configuration doesn't work.

I'm using libproxy on openSUSE 11.2 M7 (test release) with the KDE module
installed. ~/.proxy.conf and /etc/proxy.conf doesn't exist. The KDE proxy
server is set manually and works fine for web browsing in konqueror.

However, after starting my KDE 4 session, I don't get the KDEs proxy server
from libproxy (or the tool "proxy"), but always "direct://".

Original issue reported on code.google.com by lukas.so...@gmx-topmail.de on 15 Sep 2009 at 9:26

[GoogleCodeExporter]

Hm, it seems that libproxy doesn't read the file correctly.

1.) After having a short look to the source code: The KDE directory is 
hardcoded to
$HOME/.kde but that is not necessarily the case. openSUSE for example uses
$HOME/.kde4 as directory for KDE4.

2.) Also when I copy the respective file to the $HOME/.kde directory tree, 
libproxy
still always responds with direct://

Original comment by lukas.so...@gmx-topmail.de on 18 Sep 2009 at 3:33

[GoogleCodeExporter]

Lukas,
Thank you very much for your report. This is very valuable input for us.

for 1) We'll have to find a 'reliable' way to find the kioslaverc to query the
content of it. 

For 2) this might be that the session was not detected as running. Another 
thing to
look into.

Original comment by dominiqu...@gmail.com on 19 Sep 2009 at 6:49

[GoogleCodeExporter]

for 1)

The only reliable way I can imagine is to link against KDE.

Let me explain:

At http://techbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy 
you
find some information about KDEs filesystem hierarchy. It points out that the 
actual
KDE home dir ($HOME/.kde, $HOME/.kde4 ...) is readed from the $KDEHOME 
environment
variable. If this variable doesn't exist, it defaults to the hardcoded 
$HOME/.kde.

The problem is that many (but probably not all) distributions have changed this
default for KDE4 to $HOME/.kde4 (compile time switch) which exists apart of
$HOME/.kde which is used for KDE3. Some of them consider to change it back for 
KDE4
to $HOME/.kde in the future
(http://lists.alioth.debian.org/pipermail/pkg-kde-talk/2009-February/001147.html
). So
we have (and will also have in the future) a situation that is highly different
between the distributions and their versions.

As I don't know another reliable way, I propose to link against KDE4 and use for
example KStandardDirs
(http://api.kde.org/4.0-api/kdelibs-apidocs/kdecore/html/classKStandardDirs.html
) to
find kioslaverc (static function locate/locateLocal). We could even use
KConfig/KSharedConfig
(http://api.kde.org/4.0-api/kdelibs-apidocs/kdecore/html/classKConfig.html and
http://api.kde.org/4.0-api/kdelibs-apidocs/kdecore/html/classKSharedConfig.html)
 -
this would have the benefit that we don't only read from our file, but also 
take care
of possible global KDE fallback settings and KDE's restriction management (kiosk
mode) would be honored. This would integrate very well in KDE4.

for 2)
I didn't understand how libproxy detects if a KDE session is running. However,
http://techbase.kde.org/KDE_System_Administration/Environment_Variables#KDE_SESS
ION_VERSION
points out that KDE4 sets the environment variable KDE_SESSION_VERSION to "4" 
(while
KDE3 doesn't set the variable at all). So, for KDE4 this would be a reliable 
way to
detect the session.

Original comment by lukas.so...@gmx-topmail.de on 21 Sep 2009 at 8:51

[GoogleCodeExporter]

I got 2 implemented now using the KDE_FULL_SESSION envvar. Unfortunately this 
proves
that the plugin is a bit more broken than expected... chasing for a double-free 
now.

Original comment by dominiqu...@gmail.com on 24 Sep 2009 at 5:08

[GoogleCodeExporter]

svn 428 fixes number 2, svn 429 the double free revealed bz svn 428.

Original comment by dominiqu...@gmail.com on 25 Sep 2009 at 2:15

[GoogleCodeExporter]

about svn 428: You check if KDE_FULL_SESSION contains "true". That's not a good 
idea.
Quote from
http://techbase.kde.org/KDE_System_Administration/Environment_Variables#KDE_FULL
_SESSION

> If you plan on using this variable to detect a running KDE session,
> check if the value is not empty instead of seeing if it equals true.
> The value might be changed in the future to include KDE version information.

Original comment by lukas.so...@gmx-topmail.de on 25 Sep 2009 at 4:43

[GoogleCodeExporter]

Thanks for the pointer... will update the code.

Original comment by dominiqu...@gmail.com on 25 Sep 2009 at 5:04

[GoogleCodeExporter]

Okay, it seems that 2. is solved.

What do you thing about 1.? Is linking against KDE an option? If so, I could 
propose
a few lines of code to get the values from kioslaverc using KDEs directory 
hirarchy
for global admin defaults and kiosk lookdown...

Original comment by lukas.so...@gmx-topmail.de on 28 Sep 2009 at 11:48

[GoogleCodeExporter]

I'm just looking into it. All the nice kde stuff certainly is C++ while all of 
our
lib at the moment is plain C...

besides that: the config file parser seems to have gone broken at one point and 
even
finding the config file does not return proper values at the moment.

Original comment by 2hazel.e...@gmail.com on 28 Sep 2009 at 6:01

[GoogleCodeExporter]

I just commited a new config_kde module. It's now written in C++, links against
libkdecore and uses kde internal functions to find the configuration path.

Lukas: can you test if this works for you as good as it does for me? (Let me 
know if
you'd prefer some binaries, I could probably provide some using openSUSE
BuildService, as you're using openSUSE too).

Original comment by dominiqu...@gmail.com on 3 Oct 2009 at 1:54

[GoogleCodeExporter]

That are great news.

For testing I would prefer binaries as I don't know anything about library 
building.

After a short look to the source code, let me do the following comments:

1.)
> - At the moment we're not compatible with KDE3. Sorry.
That's IMHO not a problem. Allmost all distributions that will ship with the 
next
version of libproxy will not ship KDE3 as full-featured DE anymore.

2.)
If the KDE proxy configuration is manually (ProxyType == 1), than libproxy uses 
the
value of "httpProxy". But KDE provides own entries httpsProxy and ftpProxy for 
the
respective protocolls which should be readed out also. Furthermore, for manual 
proxy
configuration there exists a list with exceptions ("NoProxyFor") for which a 
direct
connection should be used instead of a proxy (if "ReversedException" is false 
which
is the default). Respectively, if "ReversedException" is true than the list 
contains
the the URLs for which a proxy should be used - for all other values a direct
connection is preferred.

3.)
As we are linking to KDE, we could easily make use of KDEs config system 
(including
automatic cascading to system administrators default values and taking care of 
the
kiosk system). Forgetting about KStandardDirs, including instead:

#include <KConfig>

and then declaring something like

KConfig configfile("kioslaverc");  // accessing config file
KConfigGroup kde_proxy(&configfile, "Proxy Settings");  // accessing respective 
group

Than, all values can be accessed by something like

kde_proxy.readEntry("ENTRYNAME", DEFAULT)

The type of the returned value depends on the type of DEFAULT: It is int for 
int,
QString for char*, bool for bool...

IMHO it's worth to do it this way. It's easy and integrates perfectly with KDE.

Original comment by lukas.so...@gmx-topmail.de on 3 Oct 2009 at 4:15

[GoogleCodeExporter]

for 1; agree, that's why we went that way
2) this is marked in the module as a urrent shortcomming
3) sounds like a great idea, thanks!! (Would you happen to have a patch just 
ready? :) )

Original comment by 2hazel.e...@gmail.com on 3 Oct 2009 at 7:00

[GoogleCodeExporter]

besides: even though there is certainly still room for improvement, we might 
have to
release it in it's current form in order to get it shipped 'somewhat' working 
at all
in the upcoming distros.. most of them are in a hard freeze by now.

Original comment by dominiqu...@gmail.com on 3 Oct 2009 at 8:28

[GoogleCodeExporter]

Just a hint: If solving 2.: The field "NoProxyFor" has no IDN/percent encoding 
and
can therefor contain non-Latin1 characters.

Original comment by lukas.so...@gmx-topmail.de on 4 Oct 2009 at 9:14

[GoogleCodeExporter]

A patch for 3.) is attached.

As in kprotocolmanager.cpp (seems to be the central KDE component) the config 
file is
loaded without using "kdeglobals" but with using of system-wide fallback values 
(I
don't know why KDE does it this way).

Creating an instance of KConfig without having a QApplication object results in 
the
messege "QApplication::qAppName: Please instantiate the QApplication object 
first" on
the console. However, this does not disturb the functionality. To avoid this, we
would have to create a QApplication object before...

As I don't know how to build the library, I couldn't test it. At least it 
compiles.
If you could do a test build on obs?

Original comment by lukas.so...@gmx-topmail.de on 4 Oct 2009 at 9:15

Attachments:

• config_kde.diff

[GoogleCodeExporter]

Additional output of the library is not really acceptable, as we have 
implementations
relying on the output of proxy binary. All those would fail with the kde config
module. So using KConfig does not sound like a good idea.

Making an instance of KApplication might be an option, but it remains to see if 
a
library can do that without interfering with a mainloop having kapplication.

re the install / build: it's pretty much ./configure --with-kde4 && make && 
sudo make
install && sudo /sbin/ldconfig

This will install the lib in /usr/local/lib which will not conflict with the 
system
install. All programs will immediately start using this lib afterwards. In case 
of
problems, you can make uninstall it again and run ldconfig...

Original comment by dominiqu...@gmail.com on 4 Oct 2009 at 10:04

[GoogleCodeExporter]

Uploading a new version.

It compiles and builds fine and works for me.

About the additional output:

Using KApplication seems to be a bad idea. I've tested it with a KDE application
linking against libproxy and it worked fine, but when I use in libproxy a
QApplication instead of a KApplication it crashs. As the documentation of both
QApplication and KApplication says clearly that there should be only one object 
of
this type, this is not an option.

The additional output I had noticed came from a small KDE test program that I 
had
written - containing just a few lines of code that instanciate KConfig and
KConfigGroup and writes 1 entry to the console. It did not link to libproxy.

However, I've noticed that when libproxy is used, the respective message does 
not
appear in my application's output. I assume either it doesn't pass the 
library...

So this seems not to be an issue.

Original comment by lukas.so...@gmx-topmail.de on 4 Oct 2009 at 2:27

Attachments:

• config_kde.cc

[GoogleCodeExporter]

Lukas,

you can add 
http://download.opensuse.org/repositories/home:/dimstar/openSUSE_Factory/
as a repository an update to libproxy 0.3.1 from there to perform some tests 
(be sure
to uninstall the one you installed using make install; /usr/local/lib has 
precedence
over /usr/lib)

re your 2nd patch: I assume the lib is not fully linked and actually fails to 
load
with missing symbols. The compiler will not complain, as missing symbols are 
allowed
in a lib. But this is only an estimation so far... did not check it life (this 
is
just by looking at the patch, all the new introductions and no new libs being 
linked).

Original comment by dominiqu...@gmail.com on 4 Oct 2009 at 5:50

[GoogleCodeExporter]

Hm, I have to correct my Comment 17: After a new build, the message is appearing
again. And I don't know why. Maybe we fill a bug report for KDE and they can
implement it in a way without stderr output?

About testing: I've tested an actual SVN checkout with your KDE linked module 
and it
worked fine for me. Later this week I can test the repository, but the next 
days I'll
have much other work...

Original comment by lukas.so...@gmx-topmail.de on 4 Oct 2009 at 6:31

[GoogleCodeExporter]

Thanks for you help and time Lukas. As openSUSE and others are closing down we 
might
have to decide to ship it in the current form. It's better than what we had in 
when
you reported this issue, considering that kde module did not report anything at 
all.

Original comment by dominiqu...@gmail.com on 4 Oct 2009 at 6:40

[GoogleCodeExporter]

Finally, I've tested the repository. For me, it works fine.

The remaining shortcomings I'll report as seperate issue and recommand to close 
this
one as fixed.

Original comment by lukas.so...@gmx-topmail.de on 9 Oct 2009 at 10:39

[GoogleCodeExporter]

Thanks Lukas!

Our internal tests showed the same and I agree to close this ticket. The kde 
config
module is now in much better shape and does provide functionality for most 
parts used
in real life.

libproxy 0.3.1 release contains the new config_kde4 already (released 
yesterday).

Original comment by dominiqu...@gmail.com on 9 Oct 2009 at 2:37

• Changed state: Fixed