> On July 28, 2014, 2:57 a.m., Ian Wadham wrote: > > kinit/kinit.cpp, line 119 > > <https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line119> > > > > The real issue is on this line. I do not know how "MAC_DISPLAY" got > > into the act, but clearly it has not been tested recently, if ever. There > > is no "MAC_DISPLAY" in Apple OS X. > > > > Also "DISPLAY" is a threatened species in Mac OS X and its existence in > > an installation appears to depend, in more recent versions of Apple OS X, > > on whether FOSS XQuartz (a non-Apple X11 emulator) is installed. > > > > It is not clear ATM whether the socket name on which kinit "listens" > > needs to be qualified in some way on Apple OS X, as opposed to Linux and > > X11, or whether $DISPLAY could safely have an empty string as its value. > > > > Also, I find it questionable that kinit.cpp, wrapper.c and kcrash.cpp > > use different methods or cloned source-code to evaluate the all-important > > socket name on which they will communicate. See kdeui/util/kcrash.cpp line > > 637. There must be a better way to program this... > > > > That is why I would like to see some KDE core developers reviewing this > > code. I am not a KDE core developer. > > David Faure wrote: > The reason we have $DISPLAY in the kdeinit socket name on X11, is to > allow the same user to have more than one graphical session. > I don't mean two full KDE-workspace instances running (they'd overwrite > config files), but it happened to me sometimes that I would use ssh -X from > another machine, then start one app (which wasn't running in the main > session). > What happens then is that another kdeinit4 starts, in that separate > session (which has a separate dbus session). So it should all be separate > from the main session, hence $DISPLAY. > > AFAIK this use case doesn't apply to Mac, so it would be ok to have an > empty string in there. > > RJVB Bertin wrote: > It doesn't, indeed, and OS X doesn't allow non-X11 apps to be started > remotely. > > (It doesn't really work for me on Linux either, launching a KDE app from > an ssh-X session rarely if ever started a new dbus session for me ...) > > David Faure wrote: > (It should have, after dbus got support for autostarting session, but > otherwise you can always do it by hand > eval `dbus-launch` ; kdeinit4 ; kmyapp > )
Ah, yes, I do get something like that printed on the terminal - but since I'm a tcsh-addicted dinosaur I cannot simply copy/paste the suggestion and I've never yet bothered to figure out how to translate them. Easier to start x11vnc and connect to the main session :) - RJVB ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/#review63291 ----------------------------------------------------------- On July 27, 2014, 11:15 a.m., Ian Wadham wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119497/ > ----------------------------------------------------------- > > (Updated July 27, 2014, 11:15 a.m.) > > > Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and > Michael Pyne. > > > Repository: kdelibs > > > Description > ------- > > When a KDE app crashes in Apple OS X, it just disappears from the screen. At > the most, the user is invited to report the crash to Apple. AFAIK this has > been a problem in KDE on Apple OS X for years, leading to frustration with > KDE among Apple users and MacPorts developers and an attitude among KDE > developers of "Why does nobody report the problem(s) on bugs.kde.org?" > > It is my strong belief that the failure to report crashes of KDE apps in > Apple OS X also exists in Frameworks. > > So far I have identified a number of portability bugs in KDE on Apple OS X: 1 > in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are > submitted in this review. Patches for three more are submitted in part 2 of > this review, against kde-runtime. I am still investigating the other two > problems in Dr Konqi - and there could be more than two... > > In this review we have two portability problems: > > 1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors > and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X > library (COCOA) and it crashes if they are closed prematurely. > > 2. The preferred way to start Dr K is via a socket message to kdeinit4, but > that fails in Apple OS X because kdeinit4 is listening with the wrong socket > name. The DISPLAY ID is missing from the end of the name. The fallback is for > KCrash to use fork() and exec(), which works, but could cause Dr K to be > polluted, depending on the nature of the crash. > > This "deafness" of kdeinit4 (and klauncher) could be causing other failures > in KDE software in the Apple OS X environment. > > > Diffs > ----- > > kdeui/util/kcrash.cpp 45eb46b > kinit/kinit.cpp e41845a > > Diff: https://git.reviewboard.kde.org/r/119497/diff/ > > > Testing > ------- > > Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs > via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an > Apple OS X environment and used it to test against the KDE 4.13 branch. I > have been testing with a KDE app that I can crash at will and using stderr > and Apple OS X Console log output to determine the outcome. > > Please note that I am the -only- KDE developer who has this kind of setup, > but I am NOT a KDE core developer. My experience before now has been in KDE > Games. However I used to be a UNIX and database guru before I retired in 1998. > > I NEED HELP from KDE -core- developers to proceed further. These problems > also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks > on Apple OS X. And I am sure there are many more Apple OS X portability > problems in KDE software. > > Without my patches, Dr Konqi is not started and, if it does get past its own > crash, KCrash reports: > KCrash: Attempting to start > /kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from > kdeinit > sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0 > Warning: connect() failed: : No such file or directory > > With my patches, Dr Konqi can always be started directly (using fork()) and > it -will- start via kdeinit4 and klauncher but it immediately runs into a > privilege problem with Apple OS X (a problem which I am still investigating). > > I would not have got this far without help from Michael Pyne, Thomas Lübking > and several of the MacPorts developers, as well as the unfailing enthusiasm > and encouragement of my friend Marko Käning. > > > Thanks, > > Ian Wadham > >
