startkde modifies PATH to add qt4 bin dir to the front

[David Faure]

Le mardi 25 juin 2013 20:25:10 Albert Astals Cid a écrit :
> El Dimarts, 18 de juny de 2013, a les 19:19:24, Albert Astals Cid va 
escriure:
> > El Dimarts, 18 de juny de 2013, a les 09:55:23, David Faure va escriure:
> > > Le lundi 17 juin 2013 20:15:23 Albert Astals Cid a écrit :
> > > > Maybe we should just make sure the qdbus calls in startkde have the
> > > > full
> > > > qualified path and that's it?
> > > 
> > > Ah! This is for the calls to qdbus from within startkde itself! Well
> > > spotted.
> > > 
> > > You're thinking of using something like @QDBUS_EXECUTABLE@ in
> > > startkde.cmake and substituting that with the path to qdbus at install
> > > time? I guess that would work, if someone switches to another version of
> > > Qt in another prefix, he has to recompile everything anyway.
> > > 
> > > But looking at startkde, the code in question runs after ksmserver
> > > exits,
> > > and waits for drkonqi instances to exit, using `qdbus` and
> > > `kreadconfig`.
> > > How about turning this shell code into C++ code, and making it part of
> > > ksmserver? After all we have C++/Qt/kdelibs APIs to write such stuff,
> > > without the need to write shell scripting with rudimentary tools :)
> > > 
> > > There's also a check that the dbus session is available, but surely
> > > we'll
> > > error out soon enough if this isn't the case?
> > 
> > Sure we could do all that, but given the black magic that is involved in
> > startkde (or so I've been told), i'd prefer to go for a simpler solution
> > like the attached patch.
> > 
> > If anyone is running without qdbus on the path can you give this a try?
> 
> So it seems a few people have tried and noone has complained about
> explosions, should we commit this for 4.11 Beta 2 to get wider testing?

Yes (it worked for me too).

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5