Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

[René J . V . Bertin]

> On Jan. 10, 2017, 9:28 p.m., Anthony Fieroni wrote:
> > So when Karbon works, i'm +1, please try words / sheets are they worked as 
> > well as Karbon?
> 
> René J.V. Bertin wrote:
> I cannot tell yet, but I'm not expecting any issues because of this 
> patch. As you can see it only touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.
> 
> René J.V. Bertin wrote:
> I can confirm Words works too with this patch.
> 
> (I did have to fix a small issue in the words-odf filter, I've taken the 
> liberty to push the fix: 
> https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)
> 
> René J.V. Bertin wrote:
> Sheets works nicely too!
> 
> Anthony Fieroni wrote:
> I response for only Karbon, wait for Camilla and Dag Andersen.
> 
> René J.V. Bertin wrote:
> Evidently.
> 
> Plan also works as far as I can tell (I never used it before).
> 
> There is an issue with `calligraplanwork` however, but given the error I 
> think it has nothing to do with my changes. If anything, I may have missed a 
> location where a change is required, for instance to install required DBus 
> service files.
> 
> Dag Andersen wrote:
> Afaics this should be ok.
> The defines in KoResourcePaths.h doesn't seem to be used?
> Can't comment on apple stuff, never seen one close up ;)
> 
> René J.V. Bertin wrote:
> > The defines in KoResourcePaths.h doesn't seem to be used?
> 
> No indeed. As I tried to explain in the description, they're more a 
> proposal:
> 
> > the change to KoResourcePathsImpl::mapTypeToQStandardPaths() only has a 
> real interest if it's used throughout the code to replace the explicit use of 
> QStandardPaths locations.
> > For now I have set this up through build-type specific preprocessor 
> macros in KoResourcePaths.h [...]
> 
> I don't want to start changing a huge amount of unknown code to use those 
> macros because there are lots of places that would have to be changed, and I 
> don't think it can be done by a few simple search-and-replace runs in an 
> editor. Above all, I want to be sure that you agree about this approach.
> 
> And let me repeat: this isn't necessary for the kind of build that 
> interests me on Mac, so there's no hurry as far as I'm concerned ;)
> 
> Dag Andersen wrote:
> Afaik KoResourcePaths is used in all calligra.
> There are issues and I have a patch waiting 
> (https://phabricator.kde.org/D2577) that didn't get into 3.0.
> It's fairly big so I'm waiting for 3.1 to look at it again.
> 
> Different thing: in KoApplication line 242 you added a comment:
> // add the paths that Krita5 sets in XDG_DATA_DIRS
> Krita is not using any calligra libs anymore, so this could possibly be 
> removed but I don't know if any other app depends on this, so...

> Afaik KoResourcePaths is used in all calligra.

True, but there are also many places where QStandardPaths locations are used 
directly. I don't know the code so cannot say if that's because they were never 
converted or because the current KoResourcePaths mapping function is too 
expensive. my rewrite should reduce the calling cost significantly but using 
preprocessor macros will of course be even cheaper but again, I don't know 
whether that cost is relevant.
Standardising (making sure the right locations are used) is a different topic 
altogether of course.

> // add the paths that Krita5 sets in XDG_DATA_DIRS
Krita is not using any calligra libs anymore, so this could possibly be removed 
but I don't know if any other app depends on this, so...

The point is not that Krita uses calligra libs (or not), but how it handles the 
QSP locations problem on MS Windows. It's been released for a while now so I 
presume it's seen more testing too, so adding the locations it defines should 
only help if anything.
OTOH I haven't tried to figure out if and how it actually uses the value of 
XDG_DATA_DIRS. From what I can tell that variable is used only by the 
Unix/Linux QStandardPaths, and it isn't read out anywhere in Calligra's code. 
But without a Windows dev system to verify this I cannot propose to 

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

[Dag Andersen]

> On Jan. 10, 2017, 8:28 p.m., Anthony Fieroni wrote:
> > So when Karbon works, i'm +1, please try words / sheets are they worked as 
> > well as Karbon?
> 
> René J.V. Bertin wrote:
> I cannot tell yet, but I'm not expecting any issues because of this 
> patch. As you can see it only touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.
> 
> René J.V. Bertin wrote:
> I can confirm Words works too with this patch.
> 
> (I did have to fix a small issue in the words-odf filter, I've taken the 
> liberty to push the fix: 
> https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)
> 
> René J.V. Bertin wrote:
> Sheets works nicely too!
> 
> Anthony Fieroni wrote:
> I response for only Karbon, wait for Camilla and Dag Andersen.
> 
> René J.V. Bertin wrote:
> Evidently.
> 
> Plan also works as far as I can tell (I never used it before).
> 
> There is an issue with `calligraplanwork` however, but given the error I 
> think it has nothing to do with my changes. If anything, I may have missed a 
> location where a change is required, for instance to install required DBus 
> service files.
> 
> Dag Andersen wrote:
> Afaics this should be ok.
> The defines in KoResourcePaths.h doesn't seem to be used?
> Can't comment on apple stuff, never seen one close up ;)
> 
> René J.V. Bertin wrote:
> > The defines in KoResourcePaths.h doesn't seem to be used?
> 
> No indeed. As I tried to explain in the description, they're more a 
> proposal:
> 
> > the change to KoResourcePathsImpl::mapTypeToQStandardPaths() only has a 
> real interest if it's used throughout the code to replace the explicit use of 
> QStandardPaths locations.
> > For now I have set this up through build-type specific preprocessor 
> macros in KoResourcePaths.h [...]
> 
> I don't want to start changing a huge amount of unknown code to use those 
> macros because there are lots of places that would have to be changed, and I 
> don't think it can be done by a few simple search-and-replace runs in an 
> editor. Above all, I want to be sure that you agree about this approach.
> 
> And let me repeat: this isn't necessary for the kind of build that 
> interests me on Mac, so there's no hurry as far as I'm concerned ;)

Afaik KoResourcePaths is used in all calligra.
There are issues and I have a patch waiting (https://phabricator.kde.org/D2577) 
that didn't get into 3.0.
It's fairly big so I'm waiting for 3.1 to look at it again.

Different thing: in KoApplication line 242 you added a comment:
// add the paths that Krita5 sets in XDG_DATA_DIRS
Krita is not using any calligra libs anymore, so this could possibly be removed 
but I don't know if any other app depends on this, so...


- Dag


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


On Jan. 10, 2017, 4:34 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Jan. 10, 2017, 4:34 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which 

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

[René J . V . Bertin]

> On Jan. 10, 2017, 9:28 p.m., Anthony Fieroni wrote:
> > So when Karbon works, i'm +1, please try words / sheets are they worked as 
> > well as Karbon?
> 
> René J.V. Bertin wrote:
> I cannot tell yet, but I'm not expecting any issues because of this 
> patch. As you can see it only touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.
> 
> René J.V. Bertin wrote:
> I can confirm Words works too with this patch.
> 
> (I did have to fix a small issue in the words-odf filter, I've taken the 
> liberty to push the fix: 
> https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)
> 
> René J.V. Bertin wrote:
> Sheets works nicely too!
> 
> Anthony Fieroni wrote:
> I response for only Karbon, wait for Camilla and Dag Andersen.
> 
> René J.V. Bertin wrote:
> Evidently.
> 
> Plan also works as far as I can tell (I never used it before).
> 
> There is an issue with `calligraplanwork` however, but given the error I 
> think it has nothing to do with my changes. If anything, I may have missed a 
> location where a change is required, for instance to install required DBus 
> service files.
> 
> Dag Andersen wrote:
> Afaics this should be ok.
> The defines in KoResourcePaths.h doesn't seem to be used?
> Can't comment on apple stuff, never seen one close up ;)

> The defines in KoResourcePaths.h doesn't seem to be used?

No indeed. As I tried to explain in the description, they're more a proposal:

> the change to KoResourcePathsImpl::mapTypeToQStandardPaths() only has a real 
> interest if it's used throughout the code to replace the explicit use of 
> QStandardPaths locations.
> For now I have set this up through build-type specific preprocessor macros in 
> KoResourcePaths.h [...]

I don't want to start changing a huge amount of unknown code to use those 
macros because there are lots of places that would have to be changed, and I 
don't think it can be done by a few simple search-and-replace runs in an 
editor. Above all, I want to be sure that you agree about this approach.

And let me repeat: this isn't necessary for the kind of build that interests me 
on Mac, so there's no hurry as far as I'm concerned ;)


- René J.V.


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


On Jan. 10, 2017, 5:34 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Jan. 10, 2017, 5:34 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to 

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

[Dag Andersen]

> On Jan. 10, 2017, 8:28 p.m., Anthony Fieroni wrote:
> > So when Karbon works, i'm +1, please try words / sheets are they worked as 
> > well as Karbon?
> 
> René J.V. Bertin wrote:
> I cannot tell yet, but I'm not expecting any issues because of this 
> patch. As you can see it only touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.
> 
> René J.V. Bertin wrote:
> I can confirm Words works too with this patch.
> 
> (I did have to fix a small issue in the words-odf filter, I've taken the 
> liberty to push the fix: 
> https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)
> 
> René J.V. Bertin wrote:
> Sheets works nicely too!
> 
> Anthony Fieroni wrote:
> I response for only Karbon, wait for Camilla and Dag Andersen.
> 
> René J.V. Bertin wrote:
> Evidently.
> 
> Plan also works as far as I can tell (I never used it before).
> 
> There is an issue with `calligraplanwork` however, but given the error I 
> think it has nothing to do with my changes. If anything, I may have missed a 
> location where a change is required, for instance to install required DBus 
> service files.

Afaics this should be ok.
The defines in KoResourcePaths.h doesn't seem to be used?
Can't comment on apple stuff, never seen one close up ;)


- Dag


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


On Jan. 10, 2017, 4:34 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Jan. 10, 2017, 4:34 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to dissociate the Apple build types from general Apple build 
> requirements. Testing for build flavour is done by checking 
> `APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
> (CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).
> 
> In addition to the introduction of the CMake option, the patch
> 
> - updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
> be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
> (except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
> shouldn't be *re*set and only needs changing (potentially!) in a standalone 
> app bundle build. I don't have a MS Windows dev. system so I've merged 
> Krita's way of setting `XDG_DATA_DIRS` with Calligra's current code. Note 
> that Qt/Win also doesn't seem to use that variable in `QStandardPaths`.
> - rewrites 

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

[René J . V . Bertin]

> On Jan. 10, 2017, 9:28 p.m., Anthony Fieroni wrote:
> > So when Karbon works, i'm +1, please try words / sheets are they worked as 
> > well as Karbon?
> 
> René J.V. Bertin wrote:
> I cannot tell yet, but I'm not expecting any issues because of this 
> patch. As you can see it only touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.
> 
> René J.V. Bertin wrote:
> I can confirm Words works too with this patch.
> 
> (I did have to fix a small issue in the words-odf filter, I've taken the 
> liberty to push the fix: 
> https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)
> 
> René J.V. Bertin wrote:
> Sheets works nicely too!
> 
> Anthony Fieroni wrote:
> I response for only Karbon, wait for Camilla and Dag Andersen.

Evidently.

Plan also works as far as I can tell (I never used it before).

There is an issue with `calligraplanwork` however, but given the error I think 
it has nothing to do with my changes. If anything, I may have missed a location 
where a change is required, for instance to install required DBus service files.


- René J.V.


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


On Jan. 10, 2017, 5:34 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Jan. 10, 2017, 5:34 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to dissociate the Apple build types from general Apple build 
> requirements. Testing for build flavour is done by checking 
> `APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
> (CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).
> 
> In addition to the introduction of the CMake option, the patch
> 
> - updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
> be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
> (except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
> shouldn't be *re*set and only needs changing (potentially!) in a standalone 
> app bundle build. I don't have a MS Windows dev. system so I've merged 
> Krita's way of setting `XDG_DATA_DIRS` with Calligra's current code. Note 
> that Qt/Win also doesn't seem to use that variable in `QStandardPaths`.
> - rewrites `KoResourcePathsImpl::mapTypeToQStandardPaths()` to use a much 
> more efficient static `QHash` table. *A priori* it should be possible to use 
> `QStandardPaths::AppDataLocation` to obtain the location of the app bundle 

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

[Anthony Fieroni]

> On Ян. 10, 2017, 10:28 след обяд, Anthony Fieroni wrote:
> > So when Karbon works, i'm +1, please try words / sheets are they worked as 
> > well as Karbon?
> 
> René J.V. Bertin wrote:
> I cannot tell yet, but I'm not expecting any issues because of this 
> patch. As you can see it only touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.
> 
> René J.V. Bertin wrote:
> I can confirm Words works too with this patch.
> 
> (I did have to fix a small issue in the words-odf filter, I've taken the 
> liberty to push the fix: 
> https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)
> 
> René J.V. Bertin wrote:
> Sheets works nicely too!

I response for only Karbon, wait for Camilla and Dag Andersen.


- Anthony


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


On Ян. 10, 2017, 6:34 след обяд, René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Ян. 10, 2017, 6:34 след обяд)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to dissociate the Apple build types from general Apple build 
> requirements. Testing for build flavour is done by checking 
> `APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
> (CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).
> 
> In addition to the introduction of the CMake option, the patch
> 
> - updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
> be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
> (except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
> shouldn't be *re*set and only needs changing (potentially!) in a standalone 
> app bundle build. I don't have a MS Windows dev. system so I've merged 
> Krita's way of setting `XDG_DATA_DIRS` with Calligra's current code. Note 
> that Qt/Win also doesn't seem to use that variable in `QStandardPaths`.
> - rewrites `KoResourcePathsImpl::mapTypeToQStandardPaths()` to use a much 
> more efficient static `QHash` table. *A priori* it should be possible to use 
> `QStandardPaths::AppDataLocation` to obtain the location of the app bundle 
> resources directory; it could be populated with symlinks into 
> `/path/to/foo.app/Contents/share` so resources can be found with minimum 
> changes to the build system (install locations). This will need to be 
> established going forward (knowing that my own main interest is with "linuxy 
> builds").
> - the change to 

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

[René J . V . Bertin]

> On Jan. 10, 2017, 9:28 p.m., Anthony Fieroni wrote:
> > So when Karbon works, i'm +1, please try words / sheets are they worked as 
> > well as Karbon?
> 
> René J.V. Bertin wrote:
> I cannot tell yet, but I'm not expecting any issues because of this 
> patch. As you can see it only touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.
> 
> René J.V. Bertin wrote:
> I can confirm Words works too with this patch.
> 
> (I did have to fix a small issue in the words-odf filter, I've taken the 
> liberty to push the fix: 
> https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)

Sheets works nicely too!


- René J.V.


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


On Jan. 10, 2017, 5:34 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Jan. 10, 2017, 5:34 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to dissociate the Apple build types from general Apple build 
> requirements. Testing for build flavour is done by checking 
> `APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
> (CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).
> 
> In addition to the introduction of the CMake option, the patch
> 
> - updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
> be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
> (except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
> shouldn't be *re*set and only needs changing (potentially!) in a standalone 
> app bundle build. I don't have a MS Windows dev. system so I've merged 
> Krita's way of setting `XDG_DATA_DIRS` with Calligra's current code. Note 
> that Qt/Win also doesn't seem to use that variable in `QStandardPaths`.
> - rewrites `KoResourcePathsImpl::mapTypeToQStandardPaths()` to use a much 
> more efficient static `QHash` table. *A priori* it should be possible to use 
> `QStandardPaths::AppDataLocation` to obtain the location of the app bundle 
> resources directory; it could be populated with symlinks into 
> `/path/to/foo.app/Contents/share` so resources can be found with minimum 
> changes to the build system (install locations). This will need to be 
> established going forward (knowing that my own main interest is with "linuxy 
> builds").
> - the change to `KoResourcePathsImpl::mapTypeToQStandardPaths()` only has a 
> real interest if it's used throughout the code instead of 

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

[René J . V . Bertin]

> On Jan. 10, 2017, 9:28 p.m., Anthony Fieroni wrote:
> > So when Karbon works, i'm +1, please try words / sheets are they worked as 
> > well as Karbon?
> 
> René J.V. Bertin wrote:
> I cannot tell yet, but I'm not expecting any issues because of this 
> patch. As you can see it only touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.

I can confirm Words works too with this patch.

(I did have to fix a small issue in the words-odf filter, I've taken the 
liberty to push the fix: 
https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)


- René J.V.


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


On Jan. 10, 2017, 5:34 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Jan. 10, 2017, 5:34 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to dissociate the Apple build types from general Apple build 
> requirements. Testing for build flavour is done by checking 
> `APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
> (CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).
> 
> In addition to the introduction of the CMake option, the patch
> 
> - updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
> be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
> (except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
> shouldn't be *re*set and only needs changing (potentially!) in a standalone 
> app bundle build. I don't have a MS Windows dev. system so I've merged 
> Krita's way of setting `XDG_DATA_DIRS` with Calligra's current code. Note 
> that Qt/Win also doesn't seem to use that variable in `QStandardPaths`.
> - rewrites `KoResourcePathsImpl::mapTypeToQStandardPaths()` to use a much 
> more efficient static `QHash` table. *A priori* it should be possible to use 
> `QStandardPaths::AppDataLocation` to obtain the location of the app bundle 
> resources directory; it could be populated with symlinks into 
> `/path/to/foo.app/Contents/share` so resources can be found with minimum 
> changes to the build system (install locations). This will need to be 
> established going forward (knowing that my own main interest is with "linuxy 
> builds").
> - the change to `KoResourcePathsImpl::mapTypeToQStandardPaths()` only has a 
> real interest if it's used throughout the code instead of explicit use of 
> QStandardPaths locations. For now I have set this up through 

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

[René J . V . Bertin]

> On Jan. 10, 2017, 9:28 p.m., Anthony Fieroni wrote:
> > So when Karbon works, i'm +1, please try words / sheets are they worked as 
> > well as Karbon?

I cannot tell yet, but I'm not expecting any issues because of this patch. As 
you can see it only touches common/shared code at the moment, and I am NOT 
building with `-DAPPLE_STANDALONE_BUILD`.

I *think* I should have most external dependencies installed for Words and 
Sheets, so I'll be looking at building them in the near future, and update this 
ticket accordingly.

I'm my point of view that's icing on the cake that can come after we've reached 
feature parity with Linux. I can imagine others think different (that's what 
Macs are for ;)). Hence this patch, it'll make it easier to follow both 
approaches simultaneously.


- René J.V.


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


On Jan. 10, 2017, 5:34 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Jan. 10, 2017, 5:34 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to dissociate the Apple build types from general Apple build 
> requirements. Testing for build flavour is done by checking 
> `APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
> (CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).
> 
> In addition to the introduction of the CMake option, the patch
> 
> - updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
> be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
> (except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
> shouldn't be *re*set and only needs changing (potentially!) in a standalone 
> app bundle build. I don't have a MS Windows dev. system so I've merged 
> Krita's way of setting `XDG_DATA_DIRS` with Calligra's current code. Note 
> that Qt/Win also doesn't seem to use that variable in `QStandardPaths`.
> - rewrites `KoResourcePathsImpl::mapTypeToQStandardPaths()` to use a much 
> more efficient static `QHash` table. *A priori* it should be possible to use 
> `QStandardPaths::AppDataLocation` to obtain the location of the app bundle 
> resources directory; it could be populated with symlinks into 
> `/path/to/foo.app/Contents/share` so resources can be found with minimum 
> changes to the build system (install locations). This will need to be 
> established going forward (knowing that my own main interest is with "linuxy 
> builds").
> - the change to `KoResourcePathsImpl::mapTypeToQStandardPaths()` only has a 
> real interest if it's used throughout the code instead of explicit use of 
> QStandardPaths locations. For now I have set this up through build-type 
> specific preprocessor macros in KoResourcePaths.h (because an enum would 
> probably have to be cast to work with the QSP methods). I haven't changed any 
> code to use those macros.
> 
> Not yet incorporated: tweaks to the `ecm_add_app_icon` calls to use its new 
> capability to generate an app icon from an SVG file (currently tested with 
> Karbon).
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 13ac88f 
>   libs/main/KoApplication.cpp 7b23f8d 
>   libs/widgets/KoResourcePaths.h 8830a5a 
>   libs/widgets/KoResourcePaths.cpp 7df9dc6 
> 
> Diff: 

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

[Anthony Fieroni]

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



So when Karbon works, i'm +1, please try words / sheets are they worked as well 
as Karbon?

- Anthony Fieroni


On Ян. 10, 2017, 6:34 след обяд, René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Ян. 10, 2017, 6:34 след обяд)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to dissociate the Apple build types from general Apple build 
> requirements. Testing for build flavour is done by checking 
> `APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
> (CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).
> 
> In addition to the introduction of the CMake option, the patch
> 
> - updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
> be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
> (except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
> shouldn't be *re*set and only needs changing (potentially!) in a standalone 
> app bundle build. I don't have a MS Windows dev. system so I've merged 
> Krita's way of setting `XDG_DATA_DIRS` with Calligra's current code. Note 
> that Qt/Win also doesn't seem to use that variable in `QStandardPaths`.
> - rewrites `KoResourcePathsImpl::mapTypeToQStandardPaths()` to use a much 
> more efficient static `QHash` table. *A priori* it should be possible to use 
> `QStandardPaths::AppDataLocation` to obtain the location of the app bundle 
> resources directory; it could be populated with symlinks into 
> `/path/to/foo.app/Contents/share` so resources can be found with minimum 
> changes to the build system (install locations). This will need to be 
> established going forward (knowing that my own main interest is with "linuxy 
> builds").
> - the change to `KoResourcePathsImpl::mapTypeToQStandardPaths()` only has a 
> real interest if it's used throughout the code instead of explicit use of 
> QStandardPaths locations. For now I have set this up through build-type 
> specific preprocessor macros in KoResourcePaths.h (because an enum would 
> probably have to be cast to work with the QSP methods). I haven't changed any 
> code to use those macros.
> 
> Not yet incorporated: tweaks to the `ecm_add_app_icon` calls to use its new 
> capability to generate an app icon from an SVG file (currently tested with 
> Karbon).
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 13ac88f 
>   libs/main/KoApplication.cpp 7b23f8d 
>   libs/widgets/KoResourcePaths.h 8830a5a 
>   libs/widgets/KoResourcePaths.cpp 7df9dc6 
> 
> Diff: https://git.reviewboard.kde.org/r/129800/diff/
> 
> 
> Testing
> ---
> 
> Karbon works as expected with this patch on Mac OS X 10.9.5 (and Linux) with 
> Qt 5.7.1 and KF5 5.29.0 installed under /opt/local . 
> 
> Without the patch Karbon crashes or aborts immediately on Mac because it 
> doesn't find a single resource in the locations indicated by the 
> inappropriate `XDG_DATA_DIRS` value.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

[Anthony Fieroni]

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




libs/main/KoApplication.cpp (line 252)


Correct is #elif
http://en.cppreference.com/w/cpp/preprocessor


- Anthony Fieroni


On Ян. 10, 2017, 6:34 след обяд, René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Ян. 10, 2017, 6:34 след обяд)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to dissociate the Apple build types from general Apple build 
> requirements. Testing for build flavour is done by checking 
> `APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
> (CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).
> 
> In addition to the introduction of the CMake option, the patch
> 
> - updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
> be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
> (except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
> shouldn't be *re*set and only needs changing (potentially!) in a standalone 
> app bundle build. I don't have a MS Windows dev. system so I've merged 
> Krita's way of setting `XDG_DATA_DIRS` with Calligra's current code. Note 
> that Qt/Win also doesn't seem to use that variable in `QStandardPaths`.
> - rewrites `KoResourcePathsImpl::mapTypeToQStandardPaths()` to use a much 
> more efficient static `QHash` table. *A priori* it should be possible to use 
> `QStandardPaths::AppDataLocation` to obtain the location of the app bundle 
> resources directory; it could be populated with symlinks into 
> `/path/to/foo.app/Contents/share` so resources can be found with minimum 
> changes to the build system (install locations). This will need to be 
> established going forward (knowing that my own main interest is with "linuxy 
> builds").
> - the change to `KoResourcePathsImpl::mapTypeToQStandardPaths()` only has a 
> real interest if it's used throughout the code instead of explicit use of 
> QStandardPaths locations. For now I have set this up through build-type 
> specific preprocessor macros in KoResourcePaths.h (because an enum would 
> probably have to be cast to work with the QSP methods). I haven't changed any 
> code to use those macros.
> 
> Not yet incorporated: tweaks to the `ecm_add_app_icon` calls to use its new 
> capability to generate an app icon from an SVG file (currently tested with 
> Karbon).
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 13ac88f 
>   libs/main/KoApplication.cpp 7b23f8d 
>   libs/widgets/KoResourcePaths.h 8830a5a 
>   libs/widgets/KoResourcePaths.cpp 7df9dc6 
> 
> Diff: https://git.reviewboard.kde.org/r/129800/diff/
> 
> 
> Testing
> ---
> 
> Karbon works as expected with this patch on Mac OS X 10.9.5 (and Linux) with 
> Qt 5.7.1 and KF5 5.29.0 installed under /opt/local . 
> 
> Without the patch Karbon crashes or aborts immediately on Mac because it 
> doesn't find a single resource in the locations indicated by the 
> inappropriate `XDG_DATA_DIRS` value.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>