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, [email protected], http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5
