Re: [KDE/Mac] Multiplatform frameworks

[Marko Käning]

Hi Ian,

On 02 Mar 2015, at 03:30 , Ian Wadham  wrote:
> I am talking about regular apps, not Frameworks, but I am glad that 
> Frameworks'
> doctools is inserting the "kf5/" subdir.

> But also I expect "/Library/Application Support/kxmlgui5/“,

> If I have understood [2] correctly (BTW there seems to be a misprint under 
> KXMLGUI5DIR),
> it seems to me that "kxmlgui5/", "applications/" and "icons/", *whatever* 
> they contain, would
> be out-of-place [3] in "/Library/Application Support/" because they are not 
> apps.  

I remember to have had discussions about these locations with David a while ago
on KDE-MAC…

I recall him also pointing out that some apps might not be KDE-based, but using
KF5 libs back then, which complicates things even more.

Yes, I always also wondered about how all this could be kept consistent in an
Apple-ish manner in the light of KF5 apps also having stuff in kxmlgui5…

Greets,
Marko



P.S.: When starting off with OSX/CI I wanted to do everything OSX-compliantly, 
but
after all saw that I would get nowhere if I tried to do this monster-undertaking
all on my own. As you know, I finally had to come up with an OSX/CI system which
uses almost the same folder structure like KDE's Linux build slaves. (Except the
application install location in /Applications/KF5/ everything looks like on 
Linux.)

Re: Review Request 121390: make Qt5 theme build on Linux again

[Marko Käning]

ase see my blog post: 
> http://blog.martin-graesslin.com/blog/2014/02/running-frameworks-powered-applications-on-wayland/
> 
> Btw. the QtWayland PPA will be available starting with Qt 5.4 - a version 
> I'm already using.
> 
> René J.V. Bertin wrote:
> @Thomas: we're not talking about compile time checks. Those evidently 
> don't have any implication on the runtime environment (if done correctly :)).
> I guess my point is simply that the fact that you can (= it's possible 
> to) compile Qt/KDE with every conceivable display/rendering engine present 
> doesn't mean that indidual KDE applications or plugins can no longer decide 
> to support only a subset to be set at build time. *)
> 
> No issue either with "Unix but not OS X" - that's what I came up with for 
> lack of something better. Turns out Yichao has his own alternative to 
> HAVE_X11, I'll see if I can make do with that.
> 
> *) or else I'll start making a ruckus to have kwin and more Plasma 
> goodies on OS X!! ;)
> 
> Martin Gräßlin wrote:
> Yes, it's not about compile time checks, it's about introducing runtime 
> checks as Thomas and I wrote ;-)
> 
> René J.V. Bertin wrote:
> Actually, Thomas wrote "The compile time checks have no implication on 
> the runtime". Surely a typo, but those can have devastating consequences 
> around code ;)
> 
> René J.V. Bertin wrote:
> (published too fast again)
> 
> Actually, that blog post of yours also starts out by talking exclusively 
> about compile-time checks for about 2/3 of its length. It's only after the 
> screenshot that it becomes clear you actually use the compile-time check to 
> include a runtime-check or not. A casual reader might be tempted to stop 
> reading early, thinking he got the message ...
> 
> And I can't stop thinking something that has been stamped into me: "ifs 
> are expensive". Guess that shows my age ...
> 
> Thomas Lübking wrote:
> That's not a typo. Meaning distorting partial quote.
> I wrote:
> "The compile time checks have no implication on the runtime 
> *environment*."
> 
> "Ifs are expensive" might be stamped into your mind and/or true, but 
> they're completely inavoidable in this context.
> 
> Just that X11 was available at runtime does NOT ("no more w/ Qt5") mean 
> that it's available at runtime.
> => Keep the branching out of hot loops (as always) ;-)
> 
> René J.V. Bertin wrote:
> yes, I know I didn't copy the last word of your statement. That doesn't 
> change the fact that your 2nd word was *compile* instead of *run*, in a 
> context where you (at least) seemed to be saying that I apparently claimed 
> that those (= compile time) checks had an impact on runtime performance.
> 
> Anyway, yes, I understood perfectly well that X11 might not be available 
> at runtime while it was when compiling, and that an application trying to do 
> X11 calls will exit with an error when trying to connect to an inexisting X11 
> server. (Or crash if X11 was actually uninstalled ... but it would take other 
> runtime checks to protect against that, and frankly that'd just be crazy.)
> 
> > "Ifs are expensive" might be stamped into your mind and/or true, but 
> they're completely inavoidable in this context.
> 
> Not true, see my remarks about using function pointers above. Not that 
> that would be particularly clever and less expensive when X11 is the only 
> platform that provides a certain functionality ... :)
> (I do seem to recall that using function pointers instead of normal 
> functions was hardly more expensive on x86)
> 
> Yichao Yu wrote:
> Sorry somehow my filter missed this review request and I've just seen it 
> today...
> 
> To answer Martin's concern, I totally agree and it's in my mind the first 
> time I added X11 support back to the Qt5 version. The X11 related stuff in 
> `libqtcurve-utils` have also always had that check. All X11 related functions 
> are guarded by both a compile time check (e.g. if libxcb/X11 is not found or 
> somehow the user simply don't want to link to them...) and a runtime check 
> (i.e. the X11 related functions are no-ops if X11 is not initialized first at 
> runtime).
> 
> Now (AFAIK) the compile failure on OSX seems to be related to some 
> sturture name conflict (or whatever it is that causes a forward declaration 
> of `Display` not working...). The real issue is already addressed in another 
> review request and it is not n

Re: Review Request 121390: make Qt5 theme build on Linux again

[Marko Käning]

ase see my blog post: 
> http://blog.martin-graesslin.com/blog/2014/02/running-frameworks-powered-applications-on-wayland/
> 
> Btw. the QtWayland PPA will be available starting with Qt 5.4 - a version 
> I'm already using.
> 
> René J.V. Bertin wrote:
> @Thomas: we're not talking about compile time checks. Those evidently 
> don't have any implication on the runtime environment (if done correctly :)).
> I guess my point is simply that the fact that you can (= it's possible 
> to) compile Qt/KDE with every conceivable display/rendering engine present 
> doesn't mean that indidual KDE applications or plugins can no longer decide 
> to support only a subset to be set at build time. *)
> 
> No issue either with "Unix but not OS X" - that's what I came up with for 
> lack of something better. Turns out Yichao has his own alternative to 
> HAVE_X11, I'll see if I can make do with that.
> 
> *) or else I'll start making a ruckus to have kwin and more Plasma 
> goodies on OS X!! ;)
> 
> Martin Gräßlin wrote:
> Yes, it's not about compile time checks, it's about introducing runtime 
> checks as Thomas and I wrote ;-)
> 
> René J.V. Bertin wrote:
> Actually, Thomas wrote "The compile time checks have no implication on 
> the runtime". Surely a typo, but those can have devastating consequences 
> around code ;)
> 
> René J.V. Bertin wrote:
> (published too fast again)
> 
> Actually, that blog post of yours also starts out by talking exclusively 
> about compile-time checks for about 2/3 of its length. It's only after the 
> screenshot that it becomes clear you actually use the compile-time check to 
> include a runtime-check or not. A casual reader might be tempted to stop 
> reading early, thinking he got the message ...
> 
> And I can't stop thinking something that has been stamped into me: "ifs 
> are expensive". Guess that shows my age ...
> 
> Thomas Lübking wrote:
> That's not a typo. Meaning distorting partial quote.
> I wrote:
> "The compile time checks have no implication on the runtime 
> *environment*."
> 
> "Ifs are expensive" might be stamped into your mind and/or true, but 
> they're completely inavoidable in this context.
> 
> Just that X11 was available at runtime does NOT ("no more w/ Qt5") mean 
> that it's available at runtime.
> => Keep the branching out of hot loops (as always) ;-)
> 
> René J.V. Bertin wrote:
> yes, I know I didn't copy the last word of your statement. That doesn't 
> change the fact that your 2nd word was *compile* instead of *run*, in a 
> context where you (at least) seemed to be saying that I apparently claimed 
> that those (= compile time) checks had an impact on runtime performance.
> 
> Anyway, yes, I understood perfectly well that X11 might not be available 
> at runtime while it was when compiling, and that an application trying to do 
> X11 calls will exit with an error when trying to connect to an inexisting X11 
> server. (Or crash if X11 was actually uninstalled ... but it would take other 
> runtime checks to protect against that, and frankly that'd just be crazy.)
> 
> > "Ifs are expensive" might be stamped into your mind and/or true, but 
> they're completely inavoidable in this context.
> 
> Not true, see my remarks about using function pointers above. Not that 
> that would be particularly clever and less expensive when X11 is the only 
> platform that provides a certain functionality ... :)
> (I do seem to recall that using function pointers instead of normal 
> functions was hardly more expensive on x86)
> 
> Yichao Yu wrote:
> Sorry somehow my filter missed this review request and I've just seen it 
> today...
> 
> To answer Martin's concern, I totally agree and it's in my mind the first 
> time I added X11 support back to the Qt5 version. The X11 related stuff in 
> `libqtcurve-utils` have also always had that check. All X11 related functions 
> are guarded by both a compile time check (e.g. if libxcb/X11 is not found or 
> somehow the user simply don't want to link to them...) and a runtime check 
> (i.e. the X11 related functions are no-ops if X11 is not initialized first at 
> runtime).
> 
> Now (AFAIK) the compile failure on OSX seems to be related to some 
> sturture name conflict (or whatever it is that causes a forward declaration 
> of `Display` not working...). The real issue is already addressed in another 
> review request and it is not n

Re: Review Request 121390: make Qt5 theme build on Linux again

[Marko Käning]

> On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote:
> > this is wrong - please have a look at various frameworks on how to do it 
> > properly. In the end it should be:
> > #if HAVE_X11
> > // x11 specific stuff
> > #endif
> > 
> > obviously it also needs a runtime check:
> > if (QX11Info::isPlatformX11())
> > 
> > as we no longer should assume that X11 is the only platform on Unix(non 
> > OSX).
> 
> René J.V. Bertin wrote:
> I found a reference to HAVE_X11 online, but that token is not defined. 
> Note also that the Qt5 theme is supposed to build without KF5 too, for pure 
> Qt5 applications, so this kind of token should rather be provided by the Qt 
> cmake files rather than KDE's.
> 
> I'll leave the runtime checks to the QtCurve devs, as they obviously 
> should be made in lots of locations and it's their call. I myself don't see 
> the point in doing a runtime check whether a platform "is" X11, though. It's 
> known at build time if a platform "is" X11. Doing a runtime check before each 
> theming action if `Q11Info::isX11Active()` (or some such call) seems to be an 
> expensive concession to a rather improbable set-up. If distros really decide 
> to give the user a choice between X11 and Wayland at login ... let them 
> figure out how to streamline that first, and then add runtime checks for the 
> active graphics backend where really needed...
> (In fact, I myself would avoid anything tied to the display layer as much 
> as possible; the fact I had to go back in a few months after the previous 
> porting effort goes to show how easy it is to break builds on other platforms 
> with that kind of functionality - as if my own error wasn't enough already.)
> 
> Martin Gräßlin wrote:
> HAVE_X11 is neither defined by Qt5 nor by KF5. It needs to be set 
> manually depending on whether the source is built with or without X11 support.
> 
> Concerning the runtime check:
> kwrite -platform wayland
> 
> and your app is going to crash like hell if there is no runtime checks.
> 
> René J.V. Bertin wrote:
> ```> neon5-exec /opt/project-neon5/bin/kwrite -platform wayland
> This application failed to start because it could not find or load the Qt 
> platform plugin "wayland".
> 
> Available platform plugins are: linuxfb, minimal, offscreen, xcb.
> 
> Reinstalling the application may fix this problem.
> Abort (core dumped)
> ```
> 
> Right, so with runtime checks it doesn't crash, it just self-destructs. 
> Very useful difference :)
> Of course an application will crash if it tries to use an unavailable 
> displaying method, or if the linker tries to load shared libraries that 
> aren't present. In fact, with X11 it might actually exit nicely with a 
> message about a display rather than crash.
> 
> This just underlines my point: the only use for runtime checks in this 
> context if is the same binaries are supposed to work with multiple displaying 
> backends (or platform plugins). Whether QtCurve ought to support that is a 
> call for its developers to make, like I said above. The only way to do that 
> properly without (too much) overhead is to do the check at initialisation 
> time rather than preceding each backend-specific call, i.e. use 
> functionpointers or some OO/C++ alternative. I don't know how preferable 
> Wayland is to X11; without that I see only an interest for people working on 
> Wayland development under X11 for this kind of runtime switch support.
> To put this into context: I've often thought how it'd be nice if Qt-mac 
> would be able to use X11, but I've always dismissed the possibility that that 
> might be a runtime switch, exactly because it would introduce too much 
> overhead and/or complexity for a feature that'd be used only rarely.
> 
> Thomas Lübking wrote:
> > Right, so with runtime checks it doesn't crash, it just self-destructs. 
> 
> You're missing the point entirely. The compile time checks have no 
> implication on the runtime environment.
> Of course you cannot use the wayland platform plugin if it's not 
> available, but you *can* compile Qt/KDE w/ X11 and wayland present - but 
> making X11 calls when running on the wayland PP will crash the application -> 
> thus you must check whether you're operating on X11/xdg at runtime.
> 
> Also testing for "UNIX but not OSX" to make X11 calls is plain wrong. 
> Could be framebuffer console or wayland and no X11 installed at all.
> 
> Martin Gräßlin wrote:
> for more information please see my blog post: 
> http://blog.martin-graesslin.com/blog/2014/02/running-frameworks-powered-applications-on-wayland/
> 
> Btw. the QtWayland PPA will be available starting with Qt 5.4 - a version 
> I'm already using.
> 
> René J.V. Bertin wrote:
> @Thomas: we're not talking about compile time checks. Those evidently 
> don't have any implication on the runtime environment (if done correctly :)).
> I guess my po

Re: Review Request 119363: Port kde-baseapps to use docbook 4.5

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119363/
---

(Updated Feb. 28, 2015, 10:51 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.


Repository: kde-baseapps


Description
---

This suggests to upgrade the docbook DTD from 4.2 to 4.5.

---

There is still an open issue here:

 Spaces in DATA_INSTALL_DIR need to be handled properly, so that the path in 
the DTD file

/Library/Application\ Support/kf5/kdoctools/customization/dtd/kdex.dtd

 is correctly set, i.e. using "%20" instead of a space.


Diffs
-

  doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
  dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
  kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
  kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
  kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 

Diff: https://git.reviewboard.kde.org/r/119363/diff/


Testing
---

Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR 
path) 


Thanks,

Marko Käning

Re: Review Request 122556: Bump Qt version to 5.4

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122556/#review76012
---


I'd vote for keeping it compatible to Qt 5.3, if that's possible.

- Marko Käning


On Feb. 13, 2015, 9:06 a.m., Arjun AK wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122556/
> ---
> 
> (Updated Feb. 13, 2015, 9:06 a.m.)
> 
> 
> Review request for KDE Base Apps.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> `QUrl::fromUserInput(userInput, workingDirectory, UserInputResolutionOptions 
> options)` seems to be Qt 5.4+. We either need to bump requirement to 5.4 or 
> do what kompare 
> [did](https://projects.kde.org/projects/kde/kdesdk/kompare/repository/revisions/master/entry/libdialogpages/diffpage.cpp#L45)
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 6df9015 
> 
> Diff: https://git.reviewboard.kde.org/r/122556/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Arjun AK
> 
>

Re: Review Request 121805: kconfig: fix building when KDE_INSTALL_DIRS_NO_DEPRECATED is set

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121805/#review73185
---

Ship it!


Thanks for fixing this, Jeremy! :)

- Marko Käning


On Jan. 3, 2015, 3:20 nachm., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121805/
> ---
> 
> (Updated Jan. 3, 2015, 3:20 nachm.)
> 
> 
> Review request for kdelibs and Marko Käning.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> Use KF5_INSTALL_TARGETS_DEFAULT_ARGS so kconfig will configure when 
> KDE_INSTALL_DIRS_NO_DEPRECATED is set.
> 
> 
> Diffs
> -
> 
>   src/kreadconfig/CMakeLists.txt 3804e16 
> 
> Diff: https://git.reviewboard.kde.org/r/121805/diff/
> 
> 
> Testing
> ---
> 
> It builds again on osx where it didn't previously.
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

Re: Review Request 120149: [OS X] improved menubar experience: protected Preferences menu and cleaner "system tray"

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120149/#review71081
---


Is this not yet committed to KDE?

- Marko Käning


On Sept. 25, 2014, 4: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. 25, 2014, 4:03 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, kdelibs, KDEPIM, Qt KDE, 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 implemented as a 
> deactive standard menuitem followed by a separator. This makes the item stand 
> out on a GUI that doesn't support the kind of formatting in menus as used in 
> the Linux implementation.
> 
> Point 2 was identified as a Qt issue: `isIconVisibleInMenu` is ignored for 
> systray menus. It was resolved by adding `KMenu::addAction` methods that 
> overload the ones from QMenu that were hitherto inherited unchanged by KMenu. 
> The only different method is `addAction(QAction*)` which removes the icon 
> from the `QAction` if `isIconVisibleInMenu()` is false. The other `addAction` 
> methods are "overloaded with themselves" with `using QMenu::addAction;` in 
> the header file.
> 
> -- the Preferences menu item
> This is a menu item living in the Application menu, a menu that sits in the 
> menubar between the Apple (?) menu and the File menu. This menu also contains 
> the Quit command.
> KDE and Qt applications typically do not set up their menus in this fashion, 
> so Qt provides an automatic way to put relevant menu items (actions) in the 
> Application menu, using Apple's naming. The algorithm is described under 
> QMenuBar in the Qt documentation: for the Preferences action, it will 
> consider any action that has a text containing `config`, `options`, 
> `settings` or `preferences`, and put it under the Preferences label if its 
> menu role is set to `heuristic` (which appears to be the default).
> In practice, many applications provide a series of menu actions with names 
> that trigger this method, and they do not always create their own 
> preferences/settings/configuration menu first. Yet it is the first menu 
> action that matches that will be installed under the Preferences menu, with 
> the Command-, shortcut. A good example is KDevelop: it will have a 
> Preferences menu that activates the `Configure Selection` action - which does 
> not open a settings dialog but launches the configure or cmake procedure for 
> the selected project ...
> 
> My proposed solution overrides this Qt behaviour. On OS X, the `KAction(const 
> QString &text, QObject *parent)` constructor calls a modified (static) 
> function `setTextWithCorrectMenuRole` which checks the text against the 
> patterns Qt will consider for `PreferencesRole`. If it finds a match, it will 
> force the role to `NoRole`, unless it is a perfect match with the standard 
> KDE configuration action for the application (`"&Configuration appName..."`) 
> in which case it sets the role to `PreferencesRole`. This latter 
> consideration allows kdelibs to "catch" the configuration menu for 
> applications like KMail, which appear not to be created using 
> KStandardActions.
> This approach can be extended to other menu actions that end up incorrectly 
> in the OS X Application menu.
> 
> Applications that create menu actions using QAction or a different KAction 
> constructor will see no change (and should use `setMenuRole` selectively on 
> OS X).
> 
> 
> Diffs
> -
> 
>   kdeui/notifications/kstatusnotifieritem.cpp 1b15d40 
>   kdeui/actions/kaction.cpp 9e8f7fb 
> 
> Diff: https://git.reviewboard.kde.org/r/120149/diff/
> 
> 
> Testing
> ---
> 
> Testing was done wi

Re: KDE-CI IRC meeting - Your possible KDE contributions in non-C++

[Marko Käning]

Hi Mario,

thanks for organizing this!

> Prospective agenda for the IRC meeting:
> - Ben: Short introduction to KDE CI
> - Everybody: Short introduction incl. their skills and wishes for KDE CI
> - Ben: What needs to be changed
> - Everybody: Work on a roadmap and distribute work till next meeting
> - Everybody: Determine date for the next IRC meeting

I could give a short presentation about my OSX/CI system and describe where
I'd need support. Hey, we should go through our list of topics for the IRC
meetings, which we created months ago! :-)

Greets,
Marko

P.S.: I already see that Jeremy has a shifted time-slot wrt me. I'll have
  to check whether I can make it 3pm my time some day. The bigger problem
  will be to synchronize with Ben...

Re: Severe behavioural change regressions in release branch

[Marko Käning]

> Earlier this year, I was working on lots of performance metrics of CMake
> and this was part of it. There ended up being more than a dozen branches
> resulting from that work (some of them still unmerged). Doing some
> digging shows that this is where the commit finally hit master:
> 
> commit bd20dd6b8a925a421167602027fff9b904fd0822
> Merge: b041fc1 e17a69b
> Author: Brad King 
> Date:   Thu Jun 12 11:28:44 2014 -0400

Yep, I can verify that I had to use on OSX/CI the version from June 3rd for 
quite
a while, since that was the only one which would give me the desired builds.

Greets,
Marko

Re: Review Request 120431: Fix and future-proof Dr Konqi security methods on Bugzilla

[Marko Käning]

> On Oct. 5, 2014, 9:43 a.m., Ben Cooksley wrote:
> > As this is needed to restore the functionality of Dr Konqi, can someone 
> > familiar with the codebase please review it so we can get this in?
> 
> Ian Wadham wrote:
> Perhaps I am the person most familiar with the codebase of Dr Konqi, 
> having worked on it for a few months now.
> 
> So, if nobody else steps forward within the next 24 hours, I will do my 
> own "Ship It" and commit to KDE 4 kde-runtime master in time for Thursday's 
> close of the KDE 4.14.2 bugfix release.
> 
> If KDE core developers want the Dr Konqi bugs fixed in KF5, they will 
> have to forward-port this change and my earlier changes themselves. I cannot 
> do that. I work on Apple OS X and we do not have KF5 and Qt 5 building there 
> yet.
> 
> I do not propose to address Thomas's comments. I have more important 
> things to do.
> 
> Albert Astals Cid wrote:
> With my release team hat:
>  - Sure commit to master if you can't find someone else to review and you 
> *know* your code is right and you're going to fix it when/if it break
>  - No, don't commit to KDE/4.14 this is a huge change and I 
> don't feel like it is guaranteed to go in, you can be a good guy and review 
> https://git.reviewboard.kde.org/r/120376/ since it seems that one fixes the 
> immediate problems people are having, no? (you say you're the one that knows 
> the code more yet have not reviewed it, why?)
>  - Your obsession to not contribute to KF5 based versions will byte you 
> again when you decide to move to KF5, you should really rethink it. Because  
> we do have KF5 and Qt5 building on MacOsX according to at least one of the 
> members of the MacOSX team, no?

I wouldn not phrase it an "obsession to not to contribute to KF5". ;)

In fact, it has been pointed out multiple times on KDE-MAC, in pm as well as in 
various RRs, that the "MacOSX team" at the moment mainly tries to get KDE4 into 
a working state, which is why Ian wants to push this forward.

And yes, we have KF5 on Qt5 in a state where my OSX/CI(/Jenkins) systems are 
able to build and install many projects successfully.
BUT, unfortunately, this does NOT mean that I am able to RUN every of these 
apps successfully, as the OSX/CI system's specifics (being that all frameworks, 
libs and apps live in their own install roots) in conjunction with a (still 
missing) working QStandardPaths patch lead to the problem that most of the apps 
can't find their config and data files at runtime at this point in time. :(

As I am *alone* on KF5, I haven't managed to proceed with the QStandardPaths 
issue, since many other things kept me far too busy (like the inclusion of new 
projects on OSX/CI, dealing with Jenkins master [also for Linux], tending 
project dependencies, creating a KDE4.13 branch on our macports-kde git repo, 
testing KDE4 applications, etc...).

Eventually I conclude herewith that the "MacOSX team":

- does contribute directly to Qt5/KF5 big time - althought it is only me ATM,

- does indirectly contribute to Qt5/KF5, as many RRs can be modified easily for 
inclusion into KF5, as it has happened already for e.g. 
https://git.reviewboard.kde.org/r/119847/ and 
https://git.reviewboard.kde.org/r/119848/ 

- believes that 1st priority should be to get KDE4 in good shape on OSX, which 
is why Nicolas wants to release KDE 4.13.3 this week and will proceed with 
4.14.x right afterwards,
 
- needs decent user feedback with valuable backtraces which is why a 
non-dysfunctional DrKonqi is required on all OSX versions, hence this RR.


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120431/#review67946
---


On Oct. 5, 2014, 6:27 a.m., Ian Wadham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120431/
> ---
> 
> (Updated Oct. 5, 2014, 6:27 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Runtime and Ben Cooksley.
> 
> 
> Bugs: 337742
> http://bugs.kde.org/show_bug.cgi?id=337742
> 
> 
> Repository: kde-runtime
> 
> 
> Description
> ---
> 
> When bugs.kde.org changed over to Bugzilla 4.4.5 in July 2014, the security 
> method used by Bugzilla changed from cookies to tokens that had to be 
> supplied as parameters with every secure remote-procedure call. Further 
> changes to security methods have been announced by Bugzilla and are 
> documented for unstable 4.5.x versions of Bugzilla software. Tokens will be 
> deprecated and then discontinued. When this happens, Dr Konqi will need to 
> supply a user-login name and a password with every secure remote-procedure 
> call. Furthermore, the traditional "User.login" call presently used

Re: Review Request 120363: proposal to use the NOGUI switch in CMake files to set the default value for GUIenabled

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120363/#review67927
---


See also bug 334174

- Marko Käning


On Sept. 25, 2014, 3:32 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120363/
> ---
> 
> (Updated Sept. 25, 2014, 3:32 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Applications can be defined in their CMake file as being `NOGUI`, but until 
> now this has had very limited effect. Especially on OS X, those applications 
> can still construct a minimal GUI and thus have "visual presence" in the Dock 
> and application switcher (and have a menubar as well).
> 
> This patch proposes to define a preprocessor token, `KDE_WITHOUT_GUI`, for 
> those targets, and uses that token to set the default value for the 
> `GUIenabled` option of the `KApplication` and `KUniqueApplication` classes.
> 
> This could potentially be combined on OS X with the CoreFoundation call that 
> turns a running application into an "agent" (see 
> https://git.reviewboard.kde.org/r/120354).
> 
> 
> Diffs
> -
> 
>   cmake/modules/KDE4Macros.cmake 073d726 
>   kdeui/kernel/kapplication.h fa2ab26 
>   kdeui/kernel/kapplication.cpp b093034 
>   kdeui/kernel/kuniqueapplication.h e05dcd7 
> 
> Diff: https://git.reviewboard.kde.org/r/120363/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.6.8 with kdelibs 4.14.1 (git/kde4.14), rebuilt kdelibs, 
> kde-workspace, kde-runtime, kde-baseapps, kdepim-runtime and nepomuk-core.
> If the documentation I read is correct, the `GUIenabled` switch has no effect 
> on Linux, so this patch shouldn't have any either on that OS.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 120363: proposal to use the NOGUI switch in CMake files to set the default value for GUIenabled

[Marko Käning]

Hi Thiago,

On 26 Sep 2014, at 07:01 , Thiago Macieira  wrote:
> And still it needs to be studied for Qt5, unless the plan is to never 
> transition to Qt 5 (which means KDE-on-Mac will stop compiling within 2 
> years).

did you miss our efforts on KF5 including setting up an OSX/CI system [1]?

René has also produced patches for KF5 frameworks, which my OSX/CI system
could prove to be buildable already. :-)

So, we’re aware of it, but René is up to now focusing more on cleaning up
KDE4, since we’re not yet there with any KF5 ports on MacPorts. But we’re
getting there these days. :-D

Greets,
Marko



[1] https://trac.macports.org/wiki/KDEProblems/KDEMacPortsCI/Status

Re: Review Request 112991: Fix compilation rules of KDE-Workspace under OSX/Macports

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/112991/#review67133
---


Thanks, Gilles, for letting us know, that this is covered anew by 
https://git.reviewboard.kde.org/r/120287/ !

Please join our discussions on MacPorts-devel and KDE-MAC mailing lists.

Greets, Marko

- Marko Käning


On Oct. 26, 2013, 6:57 a.m., Gilles Caulier wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/112991/
> ---
> 
> (Updated Oct. 26, 2013, 6:57 a.m.)
> 
> 
> Review request for kde-workspace.
> 
> 
> Bugs: https://trac.macports.org/ticket/33780
> http://bugs.kde.org/show_bug.cgi?id=https://trac.macports.org/ticket/33780
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> This patch fix broken compilation under OSX / macports about kde-workspace.
> 
> Patch do not touch implementation. Only compilation rules are changed in 
> cmake script to follow the way way than Windows rules, where no X11 lib are 
> available.
> 
> By this way, Oxygen is compiled and installed to macport and digiKam has a 
> suitable GUI under OSX.
> 
> See my Macports bug report for details : 
> https://trac.macports.org/ticket/33780 
> 
> Gilles Caulier
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt c37ab8b 
>   kcontrol/CMakeLists.txt a25aaa0 
>   libs/CMakeLists.txt 9d71a03 
> 
> Diff: https://git.reviewboard.kde.org/r/112991/diff/
> 
> 
> Testing
> ---
> 
> I tested this patch under my macbook pro, using a fresh install of Macports 
> (KDE 4.11.1 / Qt 4.8.5)
> 
> As kde-workspace macports package is broken, i checkout code from KDE 
> git/master repository and fixed compilation rules as well. 
> 
> 
> File Attachments
> 
> 
> patch to fix compilation rules under OSX with KDE 4.11 branch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2013/10/26/644e987a-967f-44f0-a266-428f4c9b9579__compilerulesOSX-KDE411.patch
> 
> 
> Thanks,
> 
> Gilles Caulier
> 
>

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

[Marko Käning]

le 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 120287: [OS X] make kde-workspace build

[Marko Käning]

> On Sept. 20, 2014, 10:20 a.m., Martin Gräßlin wrote:
> > CMakeLists.txt, lines 225-234
> > 
> >
> > tabs instead of whitespaces
> 
> René J.V. Bertin wrote:
> I looked into those yesterday, and cannot find tabs on my end. No idea 
> where they'd come from.
> 
> Martin Gräßlin wrote:
> I'd guess the editor you use changes it somehow. I'd suggest to use Kate 
> and enable show all whitespaces.
> 
> René J.V. Bertin wrote:
> No, really, those tabs aren't there. I re-reopened the CMakeLists.txt in 
> vi (which doesn't modify anything unless I ask for it) and there are no tabs 
> to be found. Same in KDevelop when I open the patch review tool. I wonder if 
> your editor isn't the culprit, or something on reviewboard?
> 
> I copied the .reviewboardrc file from another KDE project and edited the 
> obvious settings. I see nothing concerning tabs in there, but maybe there 
> ought to be?
> 
> René J.V. Bertin wrote:
> See my local copy of the diff I just added.
> 
> Thomas Lübking wrote:
> There're no tabs in the diff (checked teh only reliable way: okteta ;-)
> 
> Indention in those files is crazy (2 or 3 chars, never 4), what makes it 
> look like WS/tab intermix, but ">>>" seems only a RB indication that the line 
> was altered only by shifting.
> 
> René J.V. Bertin wrote:
> Just a question: would I still have triggered `-pedantic` mode if I had 
> included something like "and relevant code tidy-ups" in my RR title? :P
> 
> Also, is one supposed to go through an RR for each and every tidy-up one 
> might want to commit (now that I have commit access ...)?
> 
> Thomas Lübking wrote:
> You can stuff as many patches (commits) into one review as you like, just 
> that one patch may delay the "ship it" to all others than and at some point 
> ppl. will refuse to look at 3MB of patches at once ;-)
> 
> I don't think that pure tidy up commits belong into KDE4 at all, if you 
> really consider one necessary, better have it reviewed.
> 
> For KF5/master you ideally clean up code while editing the area anyway.
> Global astyle fixes should only be done when things become too much of a 
> mess - and be shown to the maintainer.
> (Reason is that you introduce "fences" to "git blame")

Reason being that "fences" to "git blame" get introduced is a very good point, 
indeed! (Never thought of that, actually.)
That's somewhat a problem of the SCM's way of handling the code lines then!
Would be cool if white-space commits could be marked as such, so that git could 
omit/bridge them in case of blame...


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120287/#review67023
---


On Sept. 20, 2014, 12:54 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120287/
> ---
> 
> (Updated Sept. 20, 2014, 12:54 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and kde-workspace.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> ---
> 
> A few rather straightforward patches to make the relevant bits of KDE4's 
> kde-workspace build and function on OS X.
> The main interest is having the systemsettings control panel to control the 
> various relevant KDE settings among which desktop search, fonts, colours and 
> even style.
> The oxygen style builds and looks good but shows some updating glitches due 
> to compositing.
> 
> I'm submitting this patch partly in hope it may be useful in bringing 
> kf5-workspace to OS X, one day.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 195f99c 
>   kcontrol/CMakeLists.txt fc666b1 
>   kcontrol/krdb/krdb.cpp 36fc99c 
>   kcontrol/style/CMakeLists.txt d832b20 
>   libs/CMakeLists.txt c0576fe 
> 
> Diff: https://git.reviewboard.kde.org/r/120287/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.6.8 and 10.9.4 with KDE/MacPorts (4.12.5 and more recently kdelibs 
> git/master, 4.14.1).
> 
> 
> File Attachments
> 
> 
> copy of the diff file saved locally, which had no tabs when I uploaded it. 
> Checksum: 3989cdd46af3c891e570974d66c330403dcd41c4ee5e17a372fa385080cbabd1 
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2014/09/20/b212730f-6258-4277-851c-226bc0673aa1__patchreview-20140920.patch
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119498/#review66626
---


And this should be marked as depending on RR 119497 in "Depends On".

- Marko Käning


On July 30, 2014, 3:04 p.m., Ian Wadham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119498/
> ---
> 
> (Updated July 30, 2014, 3:04 p.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
> -
> 
>   drkonqi/reportassistantpages_bugzilla.cpp 86ca327 
>   drkonqi/gdbhighlighter.cpp 7cd0aa9 
>   drkonqi/main.cpp 75e060e 
> 
> 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)

[Marko Käning]

> On Sept. 15, 2014, 9:26 p.m., Marko Käning wrote:
> > Hi Ian, shall I test this on a Mavericks VM before you're committing this? 
> > In case I shall do it, do you have a test case for me? Greets, Marko
> 
> Ian Wadham wrote:
> Thanks, but please wait until I drop the other shoe, review 119498, fix 
> Dr Konqi.
> 
> The test case I use is to start Palapeli (jigsaw puzzle), open any puzzle 
> and start dragging a piece, then, without letting go of the mouse button, hit 
> menu item Game->Restart Puzzle. That will cause a crash every time. You need 
> to set up and use a shortcut key for the Game->Restart Puzzle action (use 
> Settings->Configure Shortcuts...).
> 
> Marko Käning wrote:
> If this depends on issue 119498 it would be good to enter that id in the 
> "Depends On" field of this RR, I guess. That makes clearer what has to be 
> installed to apply this patch cleanly, no?

Sorry, above I don't mean issue, but review request 119498. :)


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119497/#review66598
---


On Sept. 15, 2014, 3:59 a.m., Ian Wadham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119497/
> ---
> 
> (Updated Sept. 15, 2014, 3:59 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
> Michael Pyne.
> 
> 
> 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 

Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)

[Marko Käning]

> On Sept. 15, 2014, 9:26 p.m., Marko Käning wrote:
> > Hi Ian, shall I test this on a Mavericks VM before you're committing this? 
> > In case I shall do it, do you have a test case for me? Greets, Marko
> 
> Ian Wadham wrote:
> Thanks, but please wait until I drop the other shoe, review 119498, fix 
> Dr Konqi.
> 
> The test case I use is to start Palapeli (jigsaw puzzle), open any puzzle 
> and start dragging a piece, then, without letting go of the mouse button, hit 
> menu item Game->Restart Puzzle. That will cause a crash every time. You need 
> to set up and use a shortcut key for the Game->Restart Puzzle action (use 
> Settings->Configure Shortcuts...).

If this depends on issue 119498 it would be good to enter that id in the 
"Depends On" field of this RR, I guess. That makes clearer what has to be 
installed to apply this patch cleanly, no?


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119497/#review66598
---


On Sept. 15, 2014, 3:59 a.m., Ian Wadham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119497/
> ---
> 
> (Updated Sept. 15, 2014, 3:59 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
> Michael Pyne.
> 
> 
> 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

Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119497/#review66598
---


Hi Ian, shall I test this on a Mavericks VM before you're committing this? In 
case I shall do it, do you have a test case for me? Greets, Marko

- Marko Käning


On Sept. 15, 2014, 3:59 a.m., Ian Wadham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119497/
> ---
> 
> (Updated Sept. 15, 2014, 3:59 a.m.)
> 
> 
> Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and 
> Michael Pyne.
> 
> 
> 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 119363: Port kde-baseapps to use docbook 4.5

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119363/
---

(Updated Aug. 24, 2014, 6:33 p.m.)


Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.


Changes
---

Add still open issue of proper handling of spaces in DATA_INSTALL_DIR to 
description


Repository: kde-baseapps


Description (updated)
---

This suggests to upgrade the docbook DTD from 4.2 to 4.5.

---

There is still an open issue here:

 Spaces in DATA_INSTALL_DIR need to be handled properly, so that the path in 
the DTD file

/Library/Application\ Support/kf5/kdoctools/customization/dtd/kdex.dtd

 is correctly set, i.e. using "%20" instead of a space.


Diffs
-

  doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
  dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
  kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
  kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
  kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 

Diff: https://git.reviewboard.kde.org/r/119363/diff/


Testing
---

Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR 
path) 


Thanks,

Marko Käning

Re: Review Request 119363: Port kde-baseapps to use docbook 4.5

[Marko Käning]

> On Aug. 23, 2014, 6:26 p.m., Scarlett Clark wrote:
> > I had to use this patch to get the frameworks branch to build while 
> > packaging for Kubuntu. Anyway we can get this pushed to at least frameworks 
> > branch?

I suggested the commit to frameworks to Luigi back then, but he had some 
arguments against it at the time.
Let's see what he thinks now, as I don't want to override him there.


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119363/#review65099
---


On July 20, 2014, 12:08 a.m., Marko Käning wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119363/
> ---
> 
> (Updated July 20, 2014, 12:08 a.m.)
> 
> 
> Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> This suggests to upgrade the docbook DTD from 4.2 to 4.5.
> 
> 
> Diffs
> -
> 
>   doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
>   dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
>   kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
>   kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
>   kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 
> 
> Diff: https://git.reviewboard.kde.org/r/119363/diff/
> 
> 
> Testing
> ---
> 
> Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR 
> path) 
> 
> 
> Thanks,
> 
> Marko Käning
> 
>

Re: Review Request 119363: Port kde-baseapps to use docbook 4.5

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119363/
---

(Updated July 20, 2014, 12:08 a.m.)


Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.


Changes
---

Remove distracting information


Repository: kde-baseapps


Description (updated)
---

This suggests to upgrade the docbook DTD from 4.2 to 4.5.


Diffs
-

  doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
  dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
  kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
  kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
  kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 

Diff: https://git.reviewboard.kde.org/r/119363/diff/


Testing (updated)
---

Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR 
path) 


Thanks,

Marko Käning

Re: Review Request 119363: Port kde-baseapps to use docbook 4.5

[Marko Käning]

> On July 19, 2014, 2:18 p.m., Luigi Toscano wrote:
> > Where does kdelibs4support install the compatibility docbook elements? For 
> > example, dtd/kdex.dtd.cmake, and what is its content? It should install 
> > them on the same directory as the kdoctools files (usually), but even if 
> > they are installed in a different prefix like in the CI environment, it 
> > should work, as paths in dtd/kdex.dtd.cmake are fixed accordingly (see 
> > https://git.reviewboard.kde.org/r/116670 
> > 
> > Anyway, as you can see https://git.reviewboard.kde.org/r/11678 all the 
> > paths where catalogues are installed are considered, BUT it relies on 
> > QStandardPaths; that's why I think it could be related with the other 
> > QStandardPaths issues. 
> > See also the questions at the end of review 116670.
> > 
> > I would suggest to continue the discussion on that mailing list thread.
> > 
> > (as a side note: I've seen those commits with a commit message like "Fix 
> > compilation on MacOSX", I would rather use "Part docbook to 4.5" and the 
> > comment about the compilation on MacOSX in the other lines, as this is not 
> > real a fix but a workaround).
> 
> Marko Käning wrote:
> Yes, you are right, it would have made sense to write "port docbook to 
> 4.5" instead of fixing being workarounding. :)
> (Turns out I was editing my below review comment when you had already 
> sent yours - which I hadn't seen yet.)
> 
> OK, I'll return to the ML thread as soon as there are news.

BTW, your 2nd link is missing a trailing "1", but in your ML post you give the 
correct one as https://git.reviewboard.kde.org/r/116781/


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119363/#review62690
---


On July 19, 2014, 2:30 p.m., Marko Käning wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119363/
> ---
> 
> (Updated July 19, 2014, 2:30 p.m.)
> 
> 
> Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> I need to upgrade the docbook DTD from 4.2 to 4.5 to be able to build this 
> project.
> 
> ---
> 
> I have done similar checkins for other projects like step and kgeography, but 
> I am unsure whether this is really the way to go, although Nicolas made the 
> same for kalgebra lately.
> 
> Luigi wrote in 
> http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017471.html that 
> this should work with kdelibs4support installed. It is installed on the 
> OSX/CI system, but still it doesn't work.
> 
> ---
> 
> So, perhaps it is worthwhile diagnosing what goes wrong there instead of 
> committing this RR?!
> 
> What can I do to let kdoctools tell me where exactly it expects to find its 
> catalogues?
> 
> Let me add that kdoctools definitely expects its files in 
> "/Library/Application Support/kf5/kdoctools" in my case, because I had to 
> copy them to there manually after successfully building kdoctools:
> 
> ```bash
> $ ls /Library/Application\ Support/kf5/kdoctools
> customization
> ```
> 
> Also note, that I use this global setting for configurePlatformArgs: 
> -DDATA_INSTALL_DIR="Library/Application Support".
> 
> 
> Diffs
> -
> 
>   doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
>   dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
>   kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
>   kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
>   kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 
> 
> Diff: https://git.reviewboard.kde.org/r/119363/diff/
> 
> 
> Testing
> ---
> 
> Builds/installs fine
> 
> 
> Thanks,
> 
> Marko Käning
> 
>

Re: Review Request 119363: Port kde-baseapps to use docbook 4.5

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119363/
---

(Updated July 19, 2014, 2:30 p.m.)


Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.


Changes
---

Change title of RR according to the real topic


Summary (updated)
-

Port kde-baseapps to use docbook 4.5


Repository: kde-baseapps


Description
---

I need to upgrade the docbook DTD from 4.2 to 4.5 to be able to build this 
project.

---

I have done similar checkins for other projects like step and kgeography, but I 
am unsure whether this is really the way to go, although Nicolas made the same 
for kalgebra lately.

Luigi wrote in 
http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017471.html that 
this should work with kdelibs4support installed. It is installed on the OSX/CI 
system, but still it doesn't work.

---

So, perhaps it is worthwhile diagnosing what goes wrong there instead of 
committing this RR?!

What can I do to let kdoctools tell me where exactly it expects to find its 
catalogues?

Let me add that kdoctools definitely expects its files in "/Library/Application 
Support/kf5/kdoctools" in my case, because I had to copy them to there manually 
after successfully building kdoctools:

```bash
$ ls /Library/Application\ Support/kf5/kdoctools
customization
```

Also note, that I use this global setting for configurePlatformArgs: 
-DDATA_INSTALL_DIR="Library/Application Support".


Diffs
-

  doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
  dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
  kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
  kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
  kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 

Diff: https://git.reviewboard.kde.org/r/119363/diff/


Testing
---

Builds/installs fine


Thanks,

Marko Käning

Re: Review Request 119363: Patch for kde-baseapps to make it build on the OSX/CI system

[Marko Käning]

> On July 19, 2014, 2:18 p.m., Luigi Toscano wrote:
> > Where does kdelibs4support install the compatibility docbook elements? For 
> > example, dtd/kdex.dtd.cmake, and what is its content? It should install 
> > them on the same directory as the kdoctools files (usually), but even if 
> > they are installed in a different prefix like in the CI environment, it 
> > should work, as paths in dtd/kdex.dtd.cmake are fixed accordingly (see 
> > https://git.reviewboard.kde.org/r/116670 
> > 
> > Anyway, as you can see https://git.reviewboard.kde.org/r/11678 all the 
> > paths where catalogues are installed are considered, BUT it relies on 
> > QStandardPaths; that's why I think it could be related with the other 
> > QStandardPaths issues. 
> > See also the questions at the end of review 116670.
> > 
> > I would suggest to continue the discussion on that mailing list thread.
> > 
> > (as a side note: I've seen those commits with a commit message like "Fix 
> > compilation on MacOSX", I would rather use "Part docbook to 4.5" and the 
> > comment about the compilation on MacOSX in the other lines, as this is not 
> > real a fix but a workaround).

Yes, you are right, it would have made sense to write "port docbook to 4.5" 
instead of fixing being workarounding. :)
(Turns out I was editing my below review comment when you had already sent 
yours - which I hadn't seen yet.)

OK, I'll return to the ML thread as soon as there are news.


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119363/#review62690
---


On July 19, 2014, 2:09 p.m., Marko Käning wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119363/
> ---
> 
> (Updated July 19, 2014, 2:09 p.m.)
> 
> 
> Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> I need to upgrade the docbook DTD from 4.2 to 4.5 to be able to build this 
> project.
> 
> ---
> 
> I have done similar checkins for other projects like step and kgeography, but 
> I am unsure whether this is really the way to go, although Nicolas made the 
> same for kalgebra lately.
> 
> Luigi wrote in 
> http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017471.html that 
> this should work with kdelibs4support installed. It is installed on the 
> OSX/CI system, but still it doesn't work.
> 
> ---
> 
> So, perhaps it is worthwhile diagnosing what goes wrong there instead of 
> committing this RR?!
> 
> What can I do to let kdoctools tell me where exactly it expects to find its 
> catalogues?
> 
> Let me add that kdoctools definitely expects its files in 
> "/Library/Application Support/kf5/kdoctools" in my case, because I had to 
> copy them to there manually after successfully building kdoctools:
> 
> ```bash
> $ ls /Library/Application\ Support/kf5/kdoctools
> customization
> ```
> 
> Also note, that I use this global setting for configurePlatformArgs: 
> -DDATA_INSTALL_DIR="Library/Application Support".
> 
> 
> Diffs
> -
> 
>   doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
>   dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
>   kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
>   kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
>   kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 
> 
> Diff: https://git.reviewboard.kde.org/r/119363/diff/
> 
> 
> Testing
> ---
> 
> Builds/installs fine
> 
> 
> Thanks,
> 
> Marko Käning
> 
>

Re: Review Request 119363: Patch for kde-baseapps to make it build on the OSX/CI system

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119363/#review62691
---


OK, I have eventually noticed that kdelibs4support's customization files have 
to be copied into the desired folder

 /Library/Application Support/kf5/kdoctools/customization

which I hadn't done so far. Will report back whether I can build kde-baseapps 
without this RR.

- Marko Käning


On July 19, 2014, 2:09 p.m., Marko Käning wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119363/
> ---
> 
> (Updated July 19, 2014, 2:09 p.m.)
> 
> 
> Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.
> 
> 
> Repository: kde-baseapps
> 
> 
> Description
> ---
> 
> I need to upgrade the docbook DTD from 4.2 to 4.5 to be able to build this 
> project.
> 
> ---
> 
> I have done similar checkins for other projects like step and kgeography, but 
> I am unsure whether this is really the way to go, although Nicolas made the 
> same for kalgebra lately.
> 
> Luigi wrote in 
> http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017471.html that 
> this should work with kdelibs4support installed. It is installed on the 
> OSX/CI system, but still it doesn't work.
> 
> ---
> 
> So, perhaps it is worthwhile diagnosing what goes wrong there instead of 
> committing this RR?!
> 
> What can I do to let kdoctools tell me where exactly it expects to find its 
> catalogues?
> 
> Let me add that kdoctools definitely expects its files in 
> "/Library/Application Support/kf5/kdoctools" in my case, because I had to 
> copy them to there manually after successfully building kdoctools:
> 
> ```bash
> $ ls /Library/Application\ Support/kf5/kdoctools
> customization
> ```
> 
> Also note, that I use this global setting for configurePlatformArgs: 
> -DDATA_INSTALL_DIR="Library/Application Support".
> 
> 
> Diffs
> -
> 
>   doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
>   dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
>   kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
>   kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
>   kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 
> 
> Diff: https://git.reviewboard.kde.org/r/119363/diff/
> 
> 
> Testing
> ---
> 
> Builds/installs fine
> 
> 
> Thanks,
> 
> Marko Käning
> 
>

Re: Review Request 119363: Patch for kde-baseapps to make it build on the OSX/CI system

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119363/
---

(Updated July 19, 2014, 2:09 p.m.)


Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.


Changes
---

Add notes regarding kdoctools setup on the OSX/CI system


Repository: kde-baseapps


Description (updated)
---

I need to upgrade the docbook DTD from 4.2 to 4.5 to be able to build this 
project.

---

I have done similar checkins for other projects like step and kgeography, but I 
am unsure whether this is really the way to go, although Nicolas made the same 
for kalgebra lately.

Luigi wrote in 
http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017471.html that 
this should work with kdelibs4support installed. It is installed on the OSX/CI 
system, but still it doesn't work.

---

So, perhaps it is worthwhile diagnosing what goes wrong there instead of 
committing this RR?!

What can I do to let kdoctools tell me where exactly it expects to find its 
catalogues?

Let me add that kdoctools definitely expects its files in "/Library/Application 
Support/kf5/kdoctools" in my case, because I had to copy them to there manually 
after successfully building kdoctools:

```bash
$ ls /Library/Application\ Support/kf5/kdoctools
customization
```

Also note, that I use this global setting for configurePlatformArgs: 
-DDATA_INSTALL_DIR="Library/Application Support".


Diffs
-

  doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
  dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
  kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
  kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
  kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 

Diff: https://git.reviewboard.kde.org/r/119363/diff/


Testing
---

Builds/installs fine


Thanks,

Marko Käning

Review Request 119363: Patch for kde-baseapps to make it build on the OSX/CI system

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119363/
---

Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.


Repository: kde-baseapps


Description
---

I need to upgrade the docbook DTD from 4.2 to 4.5 to be able to build this 
project.

---

I have done similar checkins for other projects like step and kgeography, but I 
am unsure whether this is really the way to go, although Nicolas made the same 
for kalgebra lately.

Luigi wrote in 
http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017471.html that 
this should work with kdelibs4support installed. It is installed on the OSX/CI 
system, but still it doesn't work.

---

So, perhaps it is worthwhile diagnosing what goes wrong there instead of 
committing this RR?!

What can I do to let kdoctools tell me where exactly it expects to find its 
catalogues?


Diffs
-

  doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
  dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
  kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
  kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
  kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 

Diff: https://git.reviewboard.kde.org/r/119363/diff/


Testing
---

Builds/installs fine


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119240/
---

(Updated July 15, 2014, 11:02 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Software on Mac OS X, kdelibs, David Faure, Martin 
Gräßlin, Ian Wadham, Thomas Lübking, and RJVB Bertin.


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin) for Qt4!

(Unclear is atm where this would have to be fixed in KF5.)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

Diff: https://git.reviewboard.kde.org/r/119240/diff/


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

[Marko Käning]

> On July 12, 2014, 8:49 p.m., David Faure wrote:
> > Seems clear enough.
> > 
> > In KF5 the file is in frameworks/kwindowsystem/src/kwindowinfo_mac.cpp
> 
> Marko Käning wrote:
> Thanks for the info about KF5!
> 
> Which branch should this be committed to on kdelibs4? Simply on master or 
> also on (an)other branch(es)?
> 
> David Faure wrote:
> Commit to KDE/4.13, and merge (or ask someone to merge) to KDE/4.14 and 
> master.
> 
> [Or if you don't care for the 4.13 branch on mac, commit to KDE/4.14 
> directly and merge to master.]

I have committed this to KDE/4.13 no problem in 
http://commits.kde.org/kdelibs/d32b52996ce48d484bbf54a62321872a482e8d74 but I 
am unsure about how to MERGE this properly into KDE/4.14 and master without 
effecting other files.

Can someone jump in and explain how to achieve those two merges without 
cherry-picking using git?


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119240/#review62201
-------


On July 14, 2014, 11:49 p.m., Marko Käning wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119240/
> ---
> 
> (Updated July 14, 2014, 11:49 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X, kdelibs, David Faure, Martin 
> Gräßlin, Ian Wadham, Thomas Lübking, and RJVB Bertin.
> 
> 
> Bugs: 337154
> http://bugs.kde.org/show_bug.cgi?id=337154
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
> René J.V. Bertin) for Qt4!
> 
> (Unclear is atm where this would have to be fixed in KF5.)
> 
> See also this: 
> https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease
> 
> 
> Diffs
> -
> 
>   kdeui/windowmanagement/kwindowinfo_mac.cpp 
> ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 
> 
> Diff: https://git.reviewboard.kde.org/r/119240/diff/
> 
> 
> Testing
> ---
> 
> For more details see associated bug
> 
> 
> Thanks,
> 
> Marko Käning
> 
>

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119240/
---

(Updated July 14, 2014, 11:49 p.m.)


Review request for KDE Software on Mac OS X, kdelibs, David Faure, Martin 
Gräßlin, Ian Wadham, Thomas Lübking, and RJVB Bertin.


Changes
---

Oops, kde-mac got lost during updating the RR.


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin) for Qt4!

(Unclear is atm where this would have to be fixed in KF5.)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

Diff: https://git.reviewboard.kde.org/r/119240/diff/


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119240/
---

(Updated July 14, 2014, 11:26 p.m.)


Review request for kdelibs, David Faure, Martin Gräßlin, Ian Wadham, Thomas 
Lübking, and RJVB Bertin.


Changes
---

Remove the comment, as it will finally be kept in this RR as well as the commit 
message.


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin) for Qt4!

(Unclear is atm where this would have to be fixed in KF5.)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs (updated)
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

Diff: https://git.reviewboard.kde.org/r/119240/diff/


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119243: Better OSX integration: native file dialogs and unified title/toolbar

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119243/
---

(Updated July 14, 2014, 8:15 p.m.)


Review request for KDE Software on Mac OS X, kdelibs, Christoph Feck, Ian 
Wadham, and RJVB Bertin.


Changes
---

Added René (This wouldn't be needed, if he were making himself member of group 
kde-mac on RB.)


Bugs: 337356
http://bugs.kde.org/show_bug.cgi?id=337356


Repository: kdelibs


Description
---

This bundles both patches submitted by René J.V. Bertin in the associated issue


Diffs
-

  kdeui/widgets/kmainwindow.cpp 85beaccdb6f123d2996b8c2b5e38435265c63ff8 
  kio/kfile/kfiledialog.h 2b11796897ff095279e7c254a383a9e8e323ea0f 
  kio/kfile/kfiledialog.cpp 4005ba304a18b59572cc1aece3fcd122ce05fda9 

Diff: https://git.reviewboard.kde.org/r/119243/diff/


Testing
---

See issue for more info from René.

---

I myself haven't yet tested this. Will report back as soon as I got to it.


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119240/
---

(Updated July 14, 2014, 7:59 p.m.)


Review request for KDE Software on Mac OS X, kdelibs, David Faure, Martin 
Gräßlin, Ian Wadham, Thomas Lübking, and RJVB Bertin.


Changes
---

Added René!


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin) for Qt4!

(Unclear is atm where this would have to be fixed in KF5.)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

Diff: https://git.reviewboard.kde.org/r/119240/diff/


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119240/
---

(Updated July 14, 2014, 7:10 p.m.)


Review request for KDE Software on Mac OS X, kdelibs, David Faure, Martin 
Gräßlin, Ian Wadham, and Thomas Lübking.


Changes
---

Assigning to kde-mac (Thanks, Ian!)


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin) for Qt4!

(Unclear is atm where this would have to be fixed in KF5.)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

Diff: https://git.reviewboard.kde.org/r/119240/diff/


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119243: Better OSX integration: native file dialogs and unified title/toolbar

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119243/
---

(Updated July 14, 2014, 7:08 p.m.)


Review request for KDE Software on Mac OS X, kdelibs, Christoph Feck, and Ian 
Wadham.


Changes
---

Assigning this RR to group kde-mac (Thanks, Ian!)


Bugs: 337356
http://bugs.kde.org/show_bug.cgi?id=337356


Repository: kdelibs


Description
---

This bundles both patches submitted by René J.V. Bertin in the associated issue


Diffs
-

  kdeui/widgets/kmainwindow.cpp 85beaccdb6f123d2996b8c2b5e38435265c63ff8 
  kio/kfile/kfiledialog.h 2b11796897ff095279e7c254a383a9e8e323ea0f 
  kio/kfile/kfiledialog.cpp 4005ba304a18b59572cc1aece3fcd122ce05fda9 

Diff: https://git.reviewboard.kde.org/r/119243/diff/


Testing
---

See issue for more info from René.

---

I myself haven't yet tested this. Will report back as soon as I got to it.


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

[Marko Käning]

> On July 12, 2014, 8:49 p.m., David Faure wrote:
> > Seems clear enough.
> > 
> > In KF5 the file is in frameworks/kwindowsystem/src/kwindowinfo_mac.cpp

Thanks for the info about KF5!

Which branch should this be committed to on kdelibs4? Simply on master or also 
on (an)other branch(es)?


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119240/#review62201
---


On July 12, 2014, 8:17 p.m., Marko Käning wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119240/
> ---
> 
> (Updated July 12, 2014, 8:17 p.m.)
> 
> 
> Review request for kdelibs, David Faure, Martin Gräßlin, Ian Wadham, and 
> Thomas Lübking.
> 
> 
> Bugs: 337154
> http://bugs.kde.org/show_bug.cgi?id=337154
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
> René J.V. Bertin) for Qt4!
> 
> (Unclear is atm where this would have to be fixed in KF5.)
> 
> See also this: 
> https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease
> 
> 
> Diffs
> -
> 
>   kdeui/windowmanagement/kwindowinfo_mac.cpp 
> ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 
> 
> Diff: https://git.reviewboard.kde.org/r/119240/diff/
> 
> 
> Testing
> ---
> 
> For more details see associated bug
> 
> 
> Thanks,
> 
> Marko Käning
> 
>

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119240/
---

(Updated July 12, 2014, 8:17 p.m.)


Review request for kdelibs, David Faure, Martin Gräßlin, Ian Wadham, and Thomas 
Lübking.


Changes
---

Follow Mario's suggestion to add dfaure as reviewer, as he's in charge of 
kdelibs.


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description (updated)
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin) for Qt4!

(Unclear is atm where this would have to be fixed in KF5.)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

Diff: https://git.reviewboard.kde.org/r/119240/diff/


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119240/
---

(Updated July 12, 2014, 7:02 p.m.)


Review request for kdelibs, Martin Gräßlin, Ian Wadham, and Thomas Lübking.


Changes
---

Add RVJB's link to Apple's documentation


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description (updated)
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

Diff: https://git.reviewboard.kde.org/r/119240/diff/


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119243: Better OSX integration: native file dialogs and unified title/toolbar

[Marko Käning]

> On July 12, 2014, 4:11 p.m., Aleix Pol Gonzalez wrote:
> > kio/kfile/kfiledialog.cpp, line 316
> > <https://git.reviewboard.kde.org/r/119243/diff/1/?file=289740#file289740line316>
> >
> > I don't know why you did that, but it doesn't look good.

Actually, when submitting this RR I was also stumbling over this commented out 
line and wondered why...

I am afraid we've to wait for René to figure this out.


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119243/#review62184
-------


On July 12, 2014, 11:55 a.m., Marko Käning wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119243/
> ---
> 
> (Updated July 12, 2014, 11:55 a.m.)
> 
> 
> Review request for kdelibs, Christoph Feck and Ian Wadham.
> 
> 
> Bugs: 337356
> http://bugs.kde.org/show_bug.cgi?id=337356
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This bundles both patches submitted by René J.V. Bertin in the associated 
> issue
> 
> 
> Diffs
> -
> 
>   kdeui/widgets/kmainwindow.cpp 85beaccdb6f123d2996b8c2b5e38435265c63ff8 
>   kio/kfile/kfiledialog.h 2b11796897ff095279e7c254a383a9e8e323ea0f 
>   kio/kfile/kfiledialog.cpp 4005ba304a18b59572cc1aece3fcd122ce05fda9 
> 
> Diff: https://git.reviewboard.kde.org/r/119243/diff/
> 
> 
> Testing
> ---
> 
> See issue for more info from René.
> 
> ---
> 
> I myself haven't yet tested this. Will report back as soon as I got to it.
> 
> 
> Thanks,
> 
> Marko Käning
> 
>

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

[Marko Käning]

> On July 12, 2014, 6:01 p.m., Martin Gräßlin wrote:
> > Which branch should that go in? I do not know what is currently a release 
> > branch.
> > 
> > It should probably also be forward ported to frameworks even if the Mac 
> > part is currently not compiled (hint: if someone adjusts the code it could 
> > be included again ;-) ).

I do not know where fixes like this should go to. This patch is based on master.


> On July 12, 2014, 6:01 p.m., Martin Gräßlin wrote:
> > kdeui/windowmanagement/kwindowinfo_mac.cpp, line 54
> > <https://git.reviewboard.kde.org/r/119240/diff/2/?file=289759#file289759line54>
> >
> > what's the "RJVB 20140706" standing for?

That's René's original comment. It will be taken out once this is ready for 
commit, since credit will be given by the commit message then. :)


- Marko


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119240/#review62192
---


On July 12, 2014, 4:22 p.m., Marko Käning wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119240/
> ---
> 
> (Updated July 12, 2014, 4:22 p.m.)
> 
> 
> Review request for kdelibs, Martin Gräßlin, Ian Wadham, and Thomas Lübking.
> 
> 
> Bugs: 337154
> http://bugs.kde.org/show_bug.cgi?id=337154
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
> René J.V. Bertin)
> 
> 
> Diffs
> -
> 
>   kdeui/windowmanagement/kwindowinfo_mac.cpp 
> ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 
> 
> Diff: https://git.reviewboard.kde.org/r/119240/diff/
> 
> 
> Testing
> ---
> 
> For more details see associated bug
> 
> 
> Thanks,
> 
> Marko Käning
> 
>

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119240/
---

(Updated July 12, 2014, 4:22 p.m.)


Review request for kdelibs, Martin Gräßlin, Ian Wadham, and Thomas Lübking.


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin)


Diffs (updated)
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

Diff: https://git.reviewboard.kde.org/r/119240/diff/


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119243: Better OSX integration: native file dialogs and unified title/toolbar

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119243/#review62168
---



kdeui/widgets/kmainwindow.cpp
<https://git.reviewboard.kde.org/r/119243/#comment43204>

Actually, I don't know whether I want this integration as default...


- Marko Käning


On July 12, 2014, 11:55 a.m., Marko Käning wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119243/
> ---
> 
> (Updated July 12, 2014, 11:55 a.m.)
> 
> 
> Review request for kdelibs, Christoph Feck and Ian Wadham.
> 
> 
> Bugs: 337356
> http://bugs.kde.org/show_bug.cgi?id=337356
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This bundles both patches submitted by René J.V. Bertin in the associated 
> issue
> 
> 
> Diffs
> -
> 
>   kdeui/widgets/kmainwindow.cpp 85beaccdb6f123d2996b8c2b5e38435265c63ff8 
>   kio/kfile/kfiledialog.h 2b11796897ff095279e7c254a383a9e8e323ea0f 
>   kio/kfile/kfiledialog.cpp 4005ba304a18b59572cc1aece3fcd122ce05fda9 
> 
> Diff: https://git.reviewboard.kde.org/r/119243/diff/
> 
> 
> Testing
> ---
> 
> See issue for more info from René.
> 
> ---
> 
> I myself haven't yet tested this. Will report back as soon as I got to it.
> 
> 
> Thanks,
> 
> Marko Käning
> 
>

Review Request 119243: Better OSX integration: native file dialogs and unified title/toolbar

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119243/
---

Review request for kdelibs, Christoph Feck and Ian Wadham.


Bugs: 337356
http://bugs.kde.org/show_bug.cgi?id=337356


Repository: kdelibs


Description
---

This bundles both patches submitted by René J.V. Bertin in the associated issue


Diffs
-

  kdeui/widgets/kmainwindow.cpp 85beaccdb6f123d2996b8c2b5e38435265c63ff8 
  kio/kfile/kfiledialog.h 2b11796897ff095279e7c254a383a9e8e323ea0f 
  kio/kfile/kfiledialog.cpp 4005ba304a18b59572cc1aece3fcd122ce05fda9 

Diff: https://git.reviewboard.kde.org/r/119243/diff/


Testing
---

See issue for more info from René.

---

I myself haven't yet tested this. Will report back as soon as I got to it.


Thanks,

Marko Käning

Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

[Marko Käning]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119240/
---

Review request for kdelibs, Martin Gräßlin, Ian Wadham, and Thomas Lübking.


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin)


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

Diff: https://git.reviewboard.kde.org/r/119240/diff/


Testing
---

For more details see associated bug


Thanks,

Marko Käning