Re: Review Request 120149: [OS X] improved menubar experience: protected Preferences menu and cleaner system tray
On Sept. 15, 2014, 12:19 nachm., Thomas Lübking wrote: kdeui/actions/kaction.cpp, line 188 https://git.reviewboard.kde.org/r/120149/diff/2/?file=312029#file312029line188 given KAction, KMenu and KMenuBar are all deprecated in KF5, is this actually of any upstream relevance? René J.V. Bertin wrote: I wouldn't know. It's been mentioned often enough that KF5 is still quite a while away from being release-ready on OS X, and in the meantime the best way to maintain momentum in getting it that far is to improve the user experience of what *is* available on the platform. Meaning KDE4 ... As to upstream relevance ... it clearly is unfortunate that KAction, KMenu and KMenuBar have been deprecated, because Qt's baked-in heuristics haven't changed in Qt5. From what I see that makes it neigh impossible to address the issues I'm trying to address in KF5 . Thomas Lübking wrote: Hint: KStandardAction is *not* deprecated so if setting the explicit role in KStandardAction::preferences() is sufficient, you won. René J.V. Bertin wrote: To rephrase what I was getting at in the issue above: `KStandardAction::preferences()` could work, but only if no other menu action is created first that has a label that starts with Config ... and of course just about any slightly elaborate KDE app has several Configure actions in its Settings menu ... with the one that *should* go under Preferences last (and thus added last). The more I think about it, the more I feel that Qt goes too far out of its way to bend applications to OS X conventions. Those apps that do want to adhere to those *guidelines* can always make sure that they create the Preference (and About) action(s) first on OS X. But a functioning UI that doesn't hide a few surprises seems more important overall. I'll try to see what dfaure thinks of this - is he already getting updates from this RR through one of the reviewer groups? is he already getting updates Yes - but that was rather a joke (if nobody else has an answer, david likely has ;-) You'll have to file a bug or patch against Qt, notably if this only has relevance on OSX (and since then esp. the Qt devs focussing on OSX will have to review it) On Sept. 15, 2014, 12:19 nachm., Thomas Lübking wrote: kdeui/actions/kstandardaction.cpp, line 173 https://git.reviewboard.kde.org/r/120149/diff/2/?file=312030#file312030line173 Will it? I don't see such code in QAction, setText is not virtual and why setTextWithCorrectRole itfp then? René J.V. Bertin wrote: True. Does C++ offer any mechanism by which one could overload a class's member function (or extend a class) without creating a child class? That might offer a solution on KF5. If no, the setText call can go back to where it came from (personally I do find it more logical to set a role after having set the text, though). Thomas Lübking wrote: you can simply override a protected or public function by just adding the exact same signature to the derived class, BUT: KAction *ka = new KAction(this); QAction *qa = ka; ka-setText(foo); // calls your reimplementation qa-setText(foo); // calls the QAction function, despite qa == ka, ie. is actually KAction to have the above example work, the function needed to be virtual (and that means virtual in the base class, ie. QAction) Q_SLOTS are usually not virtual, but QMetaObject::invokeMethod(slotFunction) will resolve the best matching ::slotFunction() for the object (though by runtime resolution) René J.V. Bertin wrote: (Q_SLOTS are usually static member functions, no?) I know you can override a function through a derived class, and still invoke the overriden version, but that's irrelevant in a situation where there is no derived (child) class. As when KAction is removed, leaving KF5 apps with just QAction. That's why I specifically asked a about overriding a function without deriving the class... Q_SLOTS are usually static member functions, no? No. That's why I specifically asked Misunderstanding. No, you can't. You can trick the linker in resolving a function from another shared object (QAction replacement in KDE library) and ignoring the other variant, but that's obviously not an option. If this doesn't improve in Qt for you, you'd end up w/ a watchdog object to track QAction text changes and fix the broken text based Qt role assignment. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120149/#review66546 --- On Sept. 15, 2014, 11:03 vorm., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit:
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)
On July 29, 2014, 5: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? René J.V. 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. René J.V. 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. Ian Wadham wrote: 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. René J.V. Bertin wrote: I meant restarts of the X server - it does crash sometimes, sometimes I have to restart it for other reasons, like after logging off and back in. I recall that I used to have those weird (socket based?) $DISPLAY values too, but now they're of a perfectly normal host:X.Y form on my systems. Except that X tends to increase each time I start XQuartz. I ignore how common this is, but I think that if you're looking into the use of $DISPLAY on OS X, you could just as well take all possible situations into account. I'd suggest to use the fact that the actual value is irrelevant and without important to clamp it to something appropriate (why not Qt4:Mac) in such a way that all those younger components pick up that value. And not the actual, current value of $DISPLAY, which may or may not have remained unchanged. (I specifically used the term clamp to draw an analogy signal acquisition, where unconnected inputs can carry all kinds of bogus signals.) René J.V. Bertin wrote: I've looked into the $DISPLAY value variations mentioned (= described from memory) above. The big lines hold: - When I log in, $DISPLAY is not set. This is probably because I
Re: About X11's WM_HINTS.UrgencyHint and KF5's NET::DemandsAttention
On Wednesday 03 September 2014 14:36:48 Paulo Lieuthier wrote: Hello everyone, I'm a LXQt contributor and I've been working on getting it rid of Xlib calls by using KF5's WindowSystem. It looks nice so far. The problem I'm having now is that I can't get the taskbar to indicate a window needs attention by using the KWindowInfo class. This is how it worked before: XWMHints *hints = XGetWMHints(QX11Info::display(), window); ... bool urgencyHint = hints-flags UrgencyHint; ... And that's how I've been trying: KWindowInfo info(window, NET::WMState | NET::XAWMState); bool urgencyHint = info.hasState(NET::DemandsAttention); Isn't NET::DemandsAttention supposed to be equal to WM_HINTS.UrgencyHint? What am I missing? Small additional update after trying to integrate the UrgencyHint into DemandsAttention: some window managers (at least KWin and openbox) set the state DemandsAttention on a window which has the UrgencyHint set. So for all applications which are not a window manager the following code will return the correct state: KWindowInfo info(window, NET::WMState); bool demandsAttention = info.hasState(NET::DemandsAttention); please be aware of the highly async nature of the setup though. It's not an intermediate change after a window set the urgency hint, it needs the wm to pick it up first. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Using Gerrit for code review in KDE
On Monday, 15 September 2014 16:49:39 CEST, Milian Wolff wrote: Where do I see the diff there? Thanks to Ben and his review of my patches, Gerrit is now replicating all of the changes under review into KDE's git as well. In the context of this discussion, it means that there's now a link to KDE's quickgit for showing these diffs -- just click on the (quickgit) on the change screen. Of course that's a read-only view and therefore not suitable for adding comments, etc. This doesn't change anything for users of KDE's git as these refs are not cloned by default. With kind regards, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated Sept. 16, 2014, 10:49 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Repository: kde-runtime 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. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears on top. The patch just raises the dialog box. 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now. 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in. Diffs (updated) - drkonqi/gdbhighlighter.cpp 7cd0aa9 drkonqi/main.cpp 75e060e drkonqi/reportassistantpages_bugzilla.cpp 86ca327 Diff: https://git.reviewboard.kde.org/r/119498/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 will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software. Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often fails to complete the backtrace report and then fails to connect to bugs.kde.org. With my patches, Dr Konqi on Apple OS X can generate a full crash report, including the backtrace and the results of the dialog with the user. Sometimes, however, it fails to submit the completed report to bugs.kde.org. This problem is still under investigation. 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. File Attachments Log of Dr K ASSERT problem https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt Thanks, Ian Wadham
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: This part of the patch, to fix the bug in the backtrace lines highlighter, has been re-written as suggested by Thomas, by adding a dummy entry to the lines, and the ASSERT remains because we should never get past the dummy, however many '\n' characters are in the last entry in the backtrace. On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/main.cpp, line 111 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293511#file293511line111 This can go unconditionally. Show really only shows the window. Becoming active and then raise for that is WM detail - and WMs have to deal with inadequate raise requests anyway ;-) Ian Wadham wrote: I do not understand your comments at all. I just know that the raise() is essential in this context, otherwise the end-user never sees Dr Konqi's window and never investigates or reports the crash. On Apple OS X, an app which is started properly, by clicking an icon or running an Apple OS X open command, will raise the app's window, but Dr Konqi is not being started this way. Thomas Lübking wrote: You can omit the system test. It's ok to call raise() here on any system. For safety, raise() will be used on all platforms and window managers, making sure the Dr Konqi dialog is always visible. On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/reportassistantpages_bugzilla.cpp, line 286 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line286 #ifndef Ian Wadham wrote: No, #ifdef. The lines following 286 apply to Apple OS X and nothing else. ATM they are only explanatory. But there is a place to add code if anybody can think of something appropriate (e.g. to check for cookies on the user's browser of choice in a portable way, maybe using Qt). René J.V. Bertin wrote: Probably not relevant here at all, but mentioning a place to add appropriate code for this kind of thing reminds me of the fact that browser plugins are organised in a quite different way on OS X, and it would be great if konqueror could pick them up. Just sayin', for the record :) Thomas Lübking wrote: I meant to use an #ifndef (and reverse the logic of course) because some #else branch is actually not required - unless of course you indeed want to add some apple specific code. The cookie-checking code will be bypassed on Apple OS X for now, because it can cause Dr Konqi to crash. It is intended that it will be replaced by code to handle the new token-checking policy of Bugzilla 4.4.3 and later (4.4.5 on bugs.kde.org). On July 27, 2014, 11:17 a.m., Thomas Lübking wrote: drkonqi/reportassistantpages_bugzilla.cpp, line 300 https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300 this is commented. if the test is pointless altogether (i do not know. no idea. no record on drkonqui) just remove it with the comment in the commit message, but ifdeffing a void statement makes us look silly ;-) Ian Wadham wrote: The comments on lines 295-298 explain why I have commented out the return statement. I am hoping a KDE core developer can suggest a better way of handling the situation than aborting Dr Konqi. Thomas Lübking wrote: Well, the claim is that aborting for no cookie support is wrong in the first place. If so, drop the code. If not (or unsure) please don't break it with an unrelated patch. Aaron J. Seigo wrote: The login relies on cookies so the check must stAy. The check should remain osx in case in future this works. However what should probably happen is the Login button and text fields should be disabled pendiNg a call to see if cookies are enabled. That check should made async and the message boxes removed in favour oof inline messages Incliding A link to tirn cookies on instead of a yes/no dialog. Sorry for the typos. This form barel works at all with the android web browser :( miAnimizin Ian Wadham wrote: The login works OK, cookies or not. Dr K asks you to enter user name and password every time, regardless of whether you are already logged in and have cookies. In my case, the cookies are in Firefox in whatever location it uses with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able to. I have tried (briefly) going the KDE way, using Konqueror and defining it (to KDE preferences) as my preferred browser and then logging in to BKO with Konqueror, but on Apple OS X that is cumbersome to set up and does not work predictably in Dr K, as it must if we want the average user to report bugs. After the login, it was possible to report a bug completely https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie check enabled one cannot report anything, because Dr K crashes in the middle of
Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119498/ --- (Updated Sept. 16, 2014, 11:08 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Changes --- Patches for reviews 119497 and 119498 are an inter-dependent pair, but on two different KDE 4 repositories. Repository: kde-runtime 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. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two... In this review we have three portability problems: 1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X open command, it always appears on top. The patch just raises the dialog box. 2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now. 3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in. Diffs - drkonqi/gdbhighlighter.cpp 7cd0aa9 drkonqi/main.cpp 75e060e drkonqi/reportassistantpages_bugzilla.cpp 86ca327 Diff: https://git.reviewboard.kde.org/r/119498/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 will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software. Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often fails to complete the backtrace report and then fails to connect to bugs.kde.org. With my patches, Dr Konqi on Apple OS X can generate a full crash report, including the backtrace and the results of the dialog with the user. Sometimes, however, it fails to submit the completed report to bugs.kde.org. This problem is still under investigation. 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. File Attachments Log of Dr K ASSERT problem https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt Thanks, Ian Wadham
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119497/ --- (Updated Sept. 16, 2014, 11:14 a.m.) Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne. Changes --- Patches for reviews 119497 and 119498 are an inter-dependent pair, but on two different KDE 4 repositories. Repository: kdelibs Description --- *NOTE: Issues for KCrash have been fixed. Changes to kinit/kinit.cpp (kdeinit4) have been discontinued. For a summary, scroll to the very end of this page. 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 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
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)
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? René J.V. 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. René J.V. 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. Ian Wadham wrote: 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. René J.V. Bertin wrote: I meant restarts of the X server - it does crash sometimes, sometimes I have to restart it for other reasons, like after logging off and back in. I recall that I used to have those weird (socket based?) $DISPLAY values too, but now they're of a perfectly normal host:X.Y form on my systems. Except that X tends to increase each time I start XQuartz. I ignore how common this is, but I think that if you're looking into the use of $DISPLAY on OS X, you could just as well take all possible situations into account. I'd suggest to use the fact that the actual value is irrelevant and without important to clamp it to something appropriate (why not Qt4:Mac) in such a way that all those younger components pick up that value. And not the actual, current value of $DISPLAY, which may or may not have remained unchanged. (I specifically used the term clamp to draw an analogy signal acquisition, where unconnected inputs can carry all kinds of bogus signals.) René J.V. Bertin wrote: I've looked into the $DISPLAY value variations mentioned (= described from memory) above. The big lines hold: - When I log in, $DISPLAY is not set. This is probably because I
Re: Review Request 120149: [OS X] improved menubar experience: protected Preferences menu and cleaner system tray
On Sept. 15, 2014, 2:19 p.m., Thomas Lübking wrote: kdeui/widgets/kmenu.cpp, line 174 https://git.reviewboard.kde.org/r/120149/diff/2/?file=312033#file312033line174 this is *utterly* wrong - you're manipulating a QAction reference just because it (at this very time!) hints it won't show it's icon in menus? The only sane approach is to fix the menu to honor this value and if that's not possible, clone the action (w/o icon), watch the original one for changed() and destroyed() for aligning updates and forward the clones signals to the original one. René J.V. Bertin wrote: I don't understand at all what you're trying to say. Do you mean that the user could change `isIconVisibleInMenu()` while the app is running, and that the change should be apparent in the menu without relaunching the application, or recreating the menu? If so, is that even possible on OS X? (I could check but I have no idea what kind of application might do such a thing...) And if that's indeed what you mean, what do you think is worse - Qt ignoring `isIconVisibleInMenu()` altogether, or me not supporting potential changes to the flag and/or icon? I do agree that my code changes the action object the user passes in. The thing is that it's probably not possible simply to clone the action and add the clone, because then everything the user does to his/her copy after adding it will have no effect ... René J.V. Bertin wrote: I've played around a bit with Qt's systray example. Here are my findings: - In Qt4, `isIconVisibleInMenu` is ignored completely for system tray menus, be it when adding a QAction or when changing the property later. - Icon changes are respected. - In Qt 5.3, `isIconVisibleInMenu` is respected when adding a QAction to the system tray menu, but subsequent changes to it have no effect. - Icon changes are respected, unless `isIconVisibleinMenu` has been turned off, in which case the previously show icon remains visible. Based on these findings, I think someone could file an upstream bug report for Qt5, but for KDE/Qt4 it seems that we can stick with my proposal. With the current state of things, the user will have to restart the application if s/he wants to change icon visibility in the systray menu, whether my patch is applied or not (actually, without my patch visibility will never change...) Thomas Lübking wrote: You are changing a clients code QAction from with a library, what is completely inacceptable. Eg. a very common constellation is to use the very same QAction for a toolbutton and a menu entry. When it passed your code, puff, gone is the icon from the toolbutton. It is not *simple* to clone the action, but it is possible. You'll have to track it's changes and forward them to your clone as you've to forward your clones triggering to the original action (ie. what Qt should be doing for this ominous systray menus - is it dbusmenu-qt?) René J.V. Bertin wrote: OK, so I did understand you correctly. If cloning the action is so complicated it is really not the way to go given how Qt 4.8 clearly *forgot* to check for the flag. I patched the code (1 additional check in 1 `if` expression), and all of a sudden even dynamic hiding/unhiding of the icon works. I'm pretty sure that Qt5 has another simple omission which explains why the icon isn't hidden when the `iconVisibleInMenu` flag is switched off. Bug reported upstream: https://bugreports.qt-project.org/browse/QTBUG-41348 - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120149/#review66546 --- On Sept. 15, 2014, 1:03 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120149/ --- (Updated Sept. 15, 2014, 1:03 p.m.) Review request for KDE Software on Mac OS X, kdelibs, KDEPIM, Marco Martin, and Olivier Goffart. Repository: kdelibs Description --- This review is for 2 sets of changes; an initial one to the way system tray are rendered, and a newer set that protects the Preferences menu from getting linked to any action with an appropriate title. -- the system tray: Until now, system tray menus had some rendering issues on Mac OS X: - The menu title, the 1st menu item that on Linux shows the application name, remained empty - Menu items that can (in principle, potentially) show an icon always showed the icon Point 1 was resolved by emulating the Linux addTitle/setTitle action in `KStatusNotifierItemPrivate::init()` : the menu title is
Re: Review Request 120149: [OS X] improved menubar experience: protected Preferences menu and cleaner system tray
On Sept. 15, 2014, 2:19 p.m., Thomas Lübking wrote: kdeui/actions/kaction.cpp, line 164 https://git.reviewboard.kde.org/r/120149/diff/2/?file=312029#file312029line164 would this eg. work with kwrite (Configure Editor...)? - or other kpart driven things? René J.V. Bertin wrote: The question is, should it work? KDevelop for instance has a Configure Editor item in its Settings menu, added *before* Configure KDevelop..., and in that case it's not the editor's configure dialog that should get linked to the Preferences menu item. If kwrite is nothing but a wrapper around an editor kpart (kate?) then I guess the end result will depend on how that kpart creates its configure action... If it uses KStandardActions and the wrapper (kwrite) doesn't (or only does after the kpart did), the Preferences menu ought to link to Configure Editor In short, it's neigh impossible to cater for all possible cases. In a sense it wouldn't disturb me at all if KDE applications simply used their own menu organisation, but it's Qt that obliges us to take action because otherwise it's there that the organisation can get messed up. René J.V. Bertin wrote: This is where Qt initialises `menuRole` with `TextHeuristicRole`, a value only used on Mac: Qt 4.8.6 : QActionPrivate::QActionPrivate() : group(0), enabled(1), forceDisabled(0), visible(1), forceInvisible(0), checkable(0), checked(0), separator(0), fontSet(false), forceEnabledInSoftkeys(false), menuActionSoftkeys(false), iconVisibleInMenu(-1), menuRole(QAction::TextHeuristicRole), softKeyRole(QAction::NoSoftKey), priority(QAction::NormalPriority) Qt 5.3.1: QActionPrivate::QActionPrivate() : group(0), enabled(1), forceDisabled(0), visible(1), forceInvisible(0), checkable(0), checked(0), separator(0), fontSet(false), iconVisibleInMenu(-1), menuRole(QAction::TextHeuristicRole), priority(QAction::NormalPriority) Overriding that one way or another will make KDE menu(bars) behave exactly as they do on Linux, with only a few OS-specific items in the Application menu (Hide, Hide others, Show All). The added benefit would be for KDE applications like `konsole` that do not use the global menubar. Does KDE have a particular/special status making it easier to propose changes to the Qt API? Thomas Lübking wrote: Does KDE have a particular/special status making it easier to propose changes to the Qt API? dfaure, I assume ;-) No - not really. None that i'm aware of. Would it help to alter KStandardAction::preferences() to explcitly set the PreferencesRole for this one (ie. would an explicit PreferencesRole trump TextHeuristicRole hitting for configure shortcuts or similar? René J.V. Bertin wrote: I've dug into the Qt code (4.8.6 for now), and am now seeing how far just removing the guesstimating on the About and Preferences will take us. `KStandardAction::preferences()` *already* sets PreferencesRole, that's one reason I moved up the setText call to before the block that sets the MenuRole (even if ATM that indeed doesn't change a thing). And that works ... as long as `KStandardAction::preferences()` is called before any other menu actions are added to a menu. It's the first action that gets added and that matches Qt's heuristics that ends up under the Preference menu item. I'm hoping this is limited to the items of menus belonging to the the global menubar, but I haven't traced the underlying code in full detail so it could even be that any menu action/item could end up there. https://bugreports.qt-project.org/browse/QTBUG-41351 - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120149/#review66546 --- On Sept. 15, 2014, 1:03 p.m., René J.V. Bertin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120149/ --- (Updated Sept. 15, 2014, 1:03 p.m.) Review request for KDE Software on Mac OS X, kdelibs, KDEPIM, Marco Martin, and Olivier Goffart. Repository: kdelibs Description --- This review is for 2 sets of changes; an initial one to the way system tray are rendered, and a newer set that protects the
Re: Review Request 120182: KIO::CopyJob: Do not query for free space when filesystem type is unknown
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120182/#review66682 --- better idea, testing for KDiskFreeSpaceInfo's success. http://www.davidfaure.fr/2014/copyjob.cpp.diff - David Faure On Sept. 13, 2014, 12:38 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120182/ --- (Updated Sept. 13, 2014, 12:38 p.m.) Review request for kdelibs and David Faure. Bugs: 336529 http://bugs.kde.org/show_bug.cgi?id=336529 Repository: kdelibs Description --- This patch stops KIO::CopyJob from querying for free disk space when the filesystem type is unknown. Diffs - kio/kio/copyjob.cpp 713255b123d284bbbaab67073466605efdd96aee Diff: https://git.reviewboard.kde.org/r/120182/diff/ Testing --- Mounted Andriod filesystem through sshfs and attempted to copy files through sftp. Thanks, Dawit Alemayehu
Re: Using Gerrit for code review in KDE
On Mon, Sep 15, 2014 at 09:34:27AM -0700, Thiago Macieira wrote: On Monday 15 September 2014 16:49:39 Milian Wolff wrote: Where do I see the diff there? In the gerrit that runs on qt-project, I can easily click one button to go to a unified or side-by-side diff view. Is that a custom extension? It's an extension. Generally, it seems as if the qt-project gerrit has a much cleaner GUI. I'm pretty lost when looking at the one up there... i don't know what you are comparing with, but if it's an installation of a recent (2.8+) gerrit ... well, welcome to the future: that's the ChangeScreen2, soon to be the only option. i'm not quite sure how anybody can think that flat buttons and a totally overcrowded ui can be an improvement, but whatever. Ossi, where's the source code for the Gerrit the Qt Project uses? try qt-project.org. ;) qtqa/gerrit, to be precise.
KF5 tab style issues
Hi there, I've encountered strange issue with the style of kf5 kdevelop tabs. Specifically the close button takes more space then anything else. It seems to be drawn by QCommonStyle class, which is inherited by KStyle. What I'm not sure, where is the bug. Is it in the * QCommonStyle because it draws that big close button, or * KStyle because it does not override close button by itself, or * my specific style/setup combo, which I'm not sure what it is because Qt5 seems to choosing proper style magically by itself? As for the last one, I've seen it on at least one other machine (scummos), so it doesn't seems to be specific to my setup. Any hint, what should I fix, would be appreciated Cheers Michal
Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)
On Tuesday September 16 2014 11:31:30 Ian Wadham wrote: The socket name is generated in 3 or 4 places, I am not sure how many. All of these must line up if KCrash, kdeinit4, klauncher, kded4 and kwrapper are to run as and when required and interact correctly on Apple OS X. And I am not even sure how much or how many of those background processes are really needed on Apple OS X or what their usual uses are or what their uses should be on Apple OS X or even whether new versions of all the processes are going to be used in KF5. I think that's irrelevant. It's a blackbox ... so be it. We just know all apps must use the same $DISPLAY value. I'm pretty sure all apps also go through a shared KDE initialisation phase, probably part of kdelibs. Forcing the DISPLAY env. variable to a sensible, constant value at the start of that phase should set the variable as required. It's a hack, but we're probably not going to be able to do any nicer for KDE4. KF5 will probable (hopefully)? evolve to using something other than $DISPLAY ... unless that same thing is used by Wayland! R.
Re: KF5 tab style issues
On Montag, 15. September 2014 22:42:03 CEST, Michal Humpula wrote: I've encountered strange issue with the style of kf5 kdevelop tabs. Specifically the close button takes more space then anything else. It seems to be drawn by QCommonStyle class, which is inherited by KStyle. If it's the stock item (iirc kdevelop had a lot of handcrafted GUI stuff), this is controlled by QStyle::PM_TabCloseIndicatorWidth QStyle::PM_TabCloseIndicatorHeight the QCommonStyle implementation returns (dpi adjusted) 16px - actual styles may of course re-implement this. * QCommonStyle because it draws that big close button, or No. QCommonStyle is no final style (plus the value seems reasonable) * KStyle because it does not override close button by itself, or No. KStyle is no final style. * my specific style/setup combo, which I'm not sure what it is because Qt5 seems to choosing proper style magically by itself? - Just upload a screenshot somewhere ;-) You can also control the Qt5 style by eg. QT_STYLE_OVERRIDE=fusion Cheers, Thomas
Re: KF5 tab style issues
On 09/15/2014 10:42 PM, Michal Humpula wrote: Hi there, I've encountered strange issue with the style of kf5 kdevelop tabs. Specifically the close button takes more space then anything else. It seems to be drawn by QCommonStyle class, which is inherited by KStyle. What I'm not sure, where is the bug. Is it in the * QCommonStyle because it draws that big close button, or * KStyle because it does not override close button by itself, or * my specific style/setup combo, which I'm not sure what it is because Qt5 seems to choosing proper style magically by itself? As for the last one, I've seen it on at least one other machine (scummos), so it doesn't seems to be specific to my setup. Any hint, what should I fix, would be appreciated Cheers Michal Hi, please file a bug at https://bugs.kde.org/enter_bug.cgi?product=Breeze (component QStyle) providing application, steps to reproduce and screenshot tab close buttons in oxygen-demo5 (second page, and checking on the show tab close button options, look good here, but again there might be application specific issues ... Thanks ! Hugo
