> On July 29, 2014, 3:33 p.m., Aleix Pol Gonzalez wrote: > > kinit/kinit.cpp, line 1481 > > <https://git.reviewboard.kde.org/r/119497/diff/1/?file=293442#file293442line1481> > > > > do you need $DISPLAY in OS X? > > RJVB Bertin wrote: > Nope. It can be set if the user has XQuartz installed and running, but > that shouldn't make a difference. > > In fact, $DISPLAY shouldn't be used on OS X because we wouldn't want > things like socket names change when the user starts or quits XQuartz with > KDE apps and/or services running. > > Ian Wadham wrote: > Perish the thought ($DISPLAY fluctuating between a value and an empty > string). On my system, OS X 10.7.5 (Lion), XQuartz was installed by Apple and > $DISPLAY is always set to a value, even if XQuartz (X11.app) is not running > (i.e. no X11 server running). I presume installing X11 somehow "doctors" the > OS X (Darwin) startup procedures so that DISPLAY is already defined in every > user's ~/.profile. I do not know if that would be the case if a FOSS version > of XQuartz would be installed (e.g. on OS X 10.9.x Mavericks). > > The big thing is that $DISPLAY -is- used (non-portably) in KDE to help > name a socket in kdeinit4 (kinit.cpp), wrapper.c, kwrapper and KCrash - and > FAIK it may be used in this way in several other places. If $DISPLAY is not > used consistently in all those places, communication with kdeinit4 can break, > as it does already in KCrash/kdeinit4 on Apple OS X. And THAT is what we are > trying to fix here. KDE apps on Apple OS X MUST be able to report a crash > reliably. > > This is why I keep asking for help from a KDE core developer. How > widespread is this problem in KDE on Apple OS X? What are the implication for > KDE apps? Should references to $DISPLAY in KDE be eliminated from the OS X > version? What do kdeinit4, kwrapper and klauncher really do? Is whatever they > do actually portable to Apple OS X? Or are we all, KDE guys and MacPorts guys > alike, just crossing our fingers and hoping for the best? > > I tried using lxr.kde.org to find further references, but there are > thousands: mostly because "display" is a commonly-used English word in > programming. And I did tick the case-sensitive box, but it does not seem to > work. > > RJVB Bertin wrote: > Hmm, interesting. I should find some time to play with this in my 10.9 VM. > Know however that even if $DISPLAY is always set, it will not always have > the same value. At least for me, XQuartz has the annoying habit of increasing > the display number after a restart. > > If it's too complicated to remove all references to $DISPLAY from KDE > code (which wouldn't surprise me at all) there remains another approach. > Identify an appropriate location in the startup/initialisation code that all > KDE applications and services share, and set $DISPLAY to something sensible > (but preferably NOT a valid X11 display specifier). The only possible > undesirable side-effect I can see from here would be that shells in konsole > risk to inherit that value. > This probably isn't the most elegant solution, but then again that's > because KDE apparently never imposed the use of its own internal > variable/function (or one from Qt) instead of directly querying $DISPLAY.
Restart of what? My system (Lion) has Apple OS X's XQuartz and $DISPLAY has a random temp-file path prepended every time Apple OS X starts of restarts. And that path is different every time. But so what? $DISPLAY keeps the same value no matter how many times I start XQuartz (X11) by running Gimp or whatever. And that value, determined immediately after boot or restart, should be picked by all KDE components, which come into existence later. - Ian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/#review63447 ----------------------------------------------------------- On July 27, 2014, 9: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, 9: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 > >
