Re: isn't it time for...
... (on a related note) providing the handbooks/documentation, even if it means shipping the ones for 2.9 or transferring the user to the web-based docs as I've seen Calligra 2.9 apps do? The link between the "Help" menu and what documentation is ultimately opened (and how) is among the things I haven't yet figured out in KDE, otherwise I'd probably be suggesting this via a RR... R.
Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds
> 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 contai
Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds
> 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 dro
Jenkins-kde-ci: calligra master kf5-qt5 » Linux,gcc - Build # 207 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/calligra%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/207/ Project: PLATFORM=Linux,compiler=gcc Date of build: Tue, 17 Jan 2017 07:01:10 + Build duration: 1 hr 59 min CHANGE SET Revision 1dcbacd0155ac7f48076650249811043b84037ba by Dag Andersen: (Sheets: Fix all failing unit tests. again...) change: edit sheets/tests/TestValueConverter.cpp change: edit sheets/tests/TestValueParser.cpp JUNIT RESULTS Name: (root) Failed: 2 test(s), Passed: 152 test(s), Skipped: 0 test(s), Total: 154 test(s)Failed: TestSuite.libs-koodf-TestNumberStyleFailed: TestSuite.libs-pigment-TestColorConversionSystem COBERTURA RESULTS Cobertura Coverage Report PACKAGES 144/171 (84%)FILES 1202/2604 (46%)CLASSES 1202/2604 (46%)LINE 77591/259089 (30%)CONDITIONAL 51606/282178 (18%) By packages braindump.braindumpcore FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/134 (0%)CONDITIONAL 0/98 (0%) braindump.plugins.stateshape FILES 4/14 (29%)CLASSES 4/14 (29%)LINE 24/280 (9%)CONDITIONAL 3/140 (2%) braindump.plugins.webshape FILES 4/9 (44%)CLASSES 4/9 (44%)LINE 22/295 (7%)CONDITIONAL 1/114 (1%) braindump.src FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/3 (0%)CONDITIONAL 0/0 (100%) devtools.rng2cpp FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 600/693 (87%)CONDITIONAL 596/814 (73%) filters.libmso FILES 10/12 (83%)CLASSES 10/12 (83%)LINE 880/7716 (11%)CONDITIONAL 2165/19897 (11%) filters.libmso.generated FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 4193/12624 (33%)CONDITIONAL 3969/23069 (17%) filters.libmsooxml FILES 2/35 (6%)CLASSES 2/35 (6%)LINE 3/8010 (0%)CONDITIONAL 2/24349 (0%) filters.libmsooxml.generated FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/743 (0%)CONDITIONAL 0/3336 (0%) filters.libodf2 FILES 6/29 (21%)CLASSES 6/29 (21%)LINE 97/1606 (6%)CONDITIONAL 82/2174 (4%) filters.libodf2.chart FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/582 (0%)CONDITIONAL 0/1321 (0%) filters.sheets.excel.sidewinder FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 654/685 (95%)CONDITIONAL 1918/3502 (55%) filters.sheets.xlsx FILES 4/5 (80%)CLASSES 4/5 (80%)LINE 111/281 (40%)CONDITIONAL 67/460 (15%) filters.stage.powerpoint FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 1651/2710 (61%)CONDITIONAL 1999/6134 (33%) filters.stage.powerpoint.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 56/58 (97%)CONDITIONAL 92/194 (47%) interfaces FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 54/61 (89%)CONDITIONAL 36/73 (49%) libs.basicflakes.plugin FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 23/31 (74%)CONDITIONAL 1/8 (13%) libs.basicflakes.tools FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/819 (0%)CONDITIONAL 0/413 (0%) libs.flake FILES 111/180 (62%)CLASSES 111/180 (62%)LINE 5273/13803 (38%)CONDITIONAL 2895/9878 (29%) libs.flake.commands FILES 19/49 (39%)CLASSES 19/49 (39%)LINE 805/2153 (37%)CONDITIONAL 410/1380 (30%) libs.flake.svg FILES 1/20 (5%)CLASSES 1/20 (5%)LINE 8/2480 (0%)CONDITIONAL 1/1706 (0%) libs.flake.tests FILES 49/49 (100%)CLASSES 49/49 (100%)LINE 3740/3773 (99%)CONDITIONAL 1718/3394 (51%) libs.flake.tools FILES 9/43 (21%)CLASSES 9/43 (21%)LINE 155/1625 (10%)CONDITIONAL 45/952 (5%) libs.kundo2 FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 205/730 (28%)CONDITIONAL 69/390 (18%) libs.main FILES 27/74 (36%)CLASSES 27/74 (36%)LINE 709/7217 (10%)CONDITIONAL 771/17163 (4%) libs.main.config FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/218 (0%)CONDITIONAL 0/478 (0%) libs.main.gemini FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/2 (0%)CONDITIONAL 0/0 (100%) libs.main.tests FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 258/271 (95%)CONDITIONAL 138/236 (58%) libs.odf FILES 39/46 (85%)CLASSES 39/46 (85%)LINE 2087/5584 (37%)CONDITIONAL 1318/4284 (31%) libs.odf.tests FILES 17/17 (100%)CLASSES 17/17 (100%)LINE 4854/5100 (95%)CONDITIONAL 3516/7158 (49%) libs.odf.writeodf FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 77/106 (73%)CONDITIONAL 29/59 (49%) libs.pageapp FILES 15/35 (43%)CLASSES 15/35 (43%)LINE 543/3106 (17%)CONDITIONAL 271/1791 (15%) libs.pageapp.commands FILES 3/7 (43%)CLASSES 3/7 (43%)LINE 97/180 (54%)CONDITIONAL 63/124 (51%) libs.pageapp.dialogs FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/99 (0%)CONDITIONAL 0/16 (0%) libs.pageapp.tests FI
