> 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 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 > >
