Re: KDE4 apps don't launch
Hi Brandon, and thanks very much for your very helpful reply. That console.app is a beauty. On 29/07/2011, at 10:49 AM, Brandon Allbery wrote: On Thu, Jul 28, 2011 at 20:19, Ian Wadham iandw...@gmail.com wrote: - Getting the links to sockets and temp dirs correct (on a Linux system, KDE does that automagically), For what it's worth, the problem on OS X is making KDE4 play along with the paths and temporary file ecosystem in OS X; KDE4 programs need relatively fixed pathnames for their sockets and caches, which are provided by the symlinks in ~/Library/Preferences/KDE4, while those symlinks are (or should be) configured to go where OS X wants them to go. But because the paths are built differently (most notably, KDE4 puts hostnames in its temp and cache pathnames, whereas OS X uses its own mechanism where such things are symlinked higher up in the path into a host-specific /private tree) the symlinks need to be rolled anew potentially whenever the network configuration changes. (That dependency on the network configuration also plagues XQuartz; if you are on a dynamic IP connection which changes often, you may well see things break until re-symlinked, The /private arrangement used by OS X avoids this.) I think part of the problem may also be When is a temporary file not a temporary file?. By default, KDE libraries (or some of their classes) keep quite long-lasting files in /tmp, such as caches for rendered graphics (pixmaps). I have always held the view that /tmp should be for truly transient files, such as intermediate output of compilers and sorts, but maybe I am being old-fashioned. OTOH and AFAIK files are always created and accessed in KDE in an abstract fashion, via the class KStandardDirs. This means that they can be re-directed via environment variables such as QTDIR, KDEDIR, KDEDIRS, KDEHOME and KDETMP (with which you are probably familiar) to locations more suitable for the platform. It is also a way to insulate a KDE development or test setup. I wonder if Macports could take more advantage of these features of KDE. Dunno about the socket situation though. snip I did go to the trouble of getting KDE4 built on my old iBook in expectation of my current situation (ensconced in a motel room, limited internet and no expectation of being able to set up the iMac or the external drive with XCode on it). :) Heh, heh. Some people have it easy :-) but living out of a suitcase is never fun. In my young day there were no laptops or networks and you were lucky if the hotel/motel had a telex machine ... :-) Cheers, Ian W. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: KDE4 apps don't launch
On Thu, Jul 28, 2011 at 13:19, Doug McComber doug.mccom...@gmail.comwrote: There's a bug in the way KDE4 is handled currently; I don't know what the correct fix is, but my current hack involves some launchd actions that create the necessary directories and symlinks thereto in ~/Library/Preferences/KDE. ln -s /var/tmp/kdecache-$USER $HOME/Library/Preferences/KDE/cache-$HOST ln -s $TMPDIR/ksocket-$USER $HOME/Library/Preferences/KDE/socket-$HOST ln -s $TMPDIR/kde-$USER $HOME/Library/Preferences/KDE/tmp-$HOST I have the first symlink. The second and third (ksocket and kde) were there but were linked to non-existent directories. Using find from the terminal I couldn't find a ksocket-* or kde-* directory anywhere. That's exactly the problem: the symlinks point to nonexistent directories, so kdeinit4 won't start up. You need to create the target directories: mkdir $TMPDIR/ksocket-$USER $TMPDIR/kde-$USER There are apparently some other issues people have run into as well, but the above was sufficient to fix it for me. What part of KDE should I possibly re-build via Macports to fix this? I wish it were that simple -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: KDE4 apps don't launch
On 28 July 2011 15:35, Brandon Allbery allber...@gmail.com wrote: On Thu, Jul 28, 2011 at 13:19, Doug McComber doug.mccom...@gmail.com That's exactly the problem: the symlinks point to nonexistent directories, so kdeinit4 won't start up. You need to create the target directories: mkdir $TMPDIR/ksocket-$USER $TMPDIR/kde-$USER There are apparently some other issues people have run into as well, but the above was sufficient to fix it for me. What part of KDE should I possibly re-build via Macports to fix this? I wish it were that simple -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms Works now. That was easy enough. I wasn't sure that I could just create the target directories. Thanks, Doug ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: KDE4 apps don't launch
On 29/07/2011, at 3:19 AM, Doug McComber wrote: I've installed Digikam and consequently KDE4. However no KDE apps will launch. They all exhibit the same symptom (bouncing in the dock for a while and not responding). Lucky you. I am having trouble getting Digikam to build, but have put the problem on the back-burner for now. I have just succeeded in getting a SVN checkout of KDE Games trunk working, outside Macports, but setting various paths and env variables to use a combination of my own source-code and build setup with KDE and Qt libraries from Macports. I am a KDE Games developer and wanted to see how the latest versions would go on the Mac. At first I noticed the bouncing in the dock and not responding behaviour and was Force Quitting apps and trying various things, such as running open on the command-line and even /Applications/KDE4/x.app/Contents/MacOS/x (i.e. direct use of the executable of x.app). After a few tries, the apps started to run and now they always run, whatever method I use. I think this was because KDE games (and maybe also Digikam) do a fair bit of graphics loading, rendering and caching before they start for the first time on a platform and were getting more of that done each time I tried. Mac OS X apparently does not like such things and after a while flags the app as not responding. Am I correct in this assumption? I've followed everything about KDE4 and Mac that I can find. While googling I found this older post from the list: There's a bug in the way KDE4 is handled currently; I don't know what the correct fix is, but my current hack involves some launchd actions that create the necessary directories and symlinks thereto in ~/Library/Preferences/KDE. ln -s /var/tmp/kdecache-$USER $HOME/Library/Preferences/KDE/cache-$HOST ln -s $TMPDIR/ksocket-$USER $HOME/Library/Preferences/KDE/socket-$HOST ln -s $TMPDIR/kde-$USER $HOME/Library/Preferences/KDE/tmp-$HOST I have the first symlink. The second and third (ksocket and kde) were there but were linked to non-existent directories. Using find from the terminal I couldn't find a ksocket-* or kde-* directory anywhere. What part of KDE should I possibly re-build via Macports to fix this? Brandon has already replied to this. The initial barriers to getting KDE apps to run appear to be: - Getting the links to sockets and temp dirs correct (on a Linux system, KDE does that automagically), - Getting dbus to run (also automagical on Linux), - Getting kdeinit4 to run (some KDE apps seem to require it, others not). I would like to find out more about the KDE desktop eco-system, how best to fake it on Mac OS X and how much of it really needs to be faked. As a KDE developer, the innards of the desktop have been mystifying me for years, ever since the advent of KDE 4. I will try to get some pointers on a KDE developers' mailing list. I also need to find out more about how Mac OS X starts up applications and would appreciate some pointers, hints or links from this list. I am new to the Mac. For example, where do stdout and stderr go when you do open x.app in a Terminal? I believe it would be worthwhile to build up a complete picture of how KDE apps should run in a Mac OS X environment and then enshrine that in the Macports Wiki or HowTo's, if not in Macports itself. There really are some excellent apps in KDE, such as KMyMoney, Digikam and the KDE Edu suite, not to mention KDE Games ... :-) ... and IMHO it would be well worth making sure these become easier to get running from Macports. All the best, Ian W. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: KDE4 apps don't launch
On Thu, Jul 28, 2011 at 20:19, Ian Wadham iandw...@gmail.com wrote: - Getting the links to sockets and temp dirs correct (on a Linux system, KDE does that automagically), For what it's worth, the problem on OS X is making KDE4 play along with the paths and temporary file ecosystem in OS X; KDE4 programs need relatively fixed pathnames for their sockets and caches, which are provided by the symlinks in ~/Library/Preferences/KDE4, while those symlinks are (or should be) configured to go where OS X wants them to go. But because the paths are built differently (most notably, KDE4 puts hostnames in its temp and cache pathnames, whereas OS X uses its own mechanism where such things are symlinked higher up in the path into a host-specific /private tree) the symlinks need to be rolled anew potentially whenever the network configuration changes. (That dependency on the network configuration also plagues XQuartz; if you are on a dynamic IP connection which changes often, you may well see things break until re-symlinked, The /private arrangement used by OS X avoids this.) - Getting dbus to run (also automagical on Linux), More precisely, it's rolled into the desktop manager. Since dbus isn't native to the OS X desktop, it needs to be hooked in after the fact. This is actually fairly easy, but MacPorts' service configuration stuff isn't (or wasn't as of 1.9.2; I haven't poked at 2.0.x yet) set up to handle services which have both system and session components. I don't know if this is likely to change, since I think dbus is the only thing that needs it. - Getting kdeinit4 to run (some KDE apps seem to require it, others not). Again, usually handled by the desktop manager. But I'm inclined to think that any KDE4 application that requires kdeinit4 to already be running is breaking the rules in its startup code somewhere; if you find a reproducible case, you should file a bug against it upstream. (Some people do want to run KDE programs under GNOME, LXDE, etc., where you would have the same problem of kdeinit4 not necessarily running.) I also need to find out more about how Mac OS X starts up applications and would appreciate some pointers, hints or links from this list. I am new to the Mac. For example, where do stdout and stderr go when you do open x.app in a Terminal? They are captured by launchd and syslogged; see /Applications/Utilities/Console.app. The giving up behavior you mentioned with respect to application startup is much the same as the launch feedback behavior of KDE4, aside from it not being (directly?) configurable. When the launch times out; an insensitive application icon is left in the Dock; if the application were to finish its initialization, it would still start up. There really are some excellent apps in KDE, such as KMyMoney, Digikam and the KDE Edu suite, not to mention KDE Games ... :-) ... and IMHO it would be well worth making sure these become easier to get running from Macports. I did go to the trouble of getting KDE4 built on my old iBook in expectation of my current situation (ensconced in a motel room, limited internet and no expectation of being able to set up the iMac or the external drive with XCode on it). :) -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
