Re: "non standalone app bundle" builds on Mac
On Monday November 07 2016 18:14:35 Jaroslaw Staniek wrote: Hi Jarek, >Thanks for the interest! >In addition Kexi-specific things can be discussed at a kexi-devel list :) >There were enthusiastic people interested in contributing Mac builds of >Kexi but they disappeared so this task is open for maintainer. Bundling or >discovering server installation(s) (pgsql, mysql), bundling dependencies -- >these are all task for adoption. > > >In my opinion Kexi fits to a standalone path, just like on Windows, to >become as native as possible, well, but not more native than that. For Right, then there was Kexi too :) It that has been split off the rest of Calligra it's likely to be much smaller. It's also much more unique in its approach - if I'd discovered a use for it myself I would have started working on a port a while ago (port in MacPorts speak; ideally that's just a build script, Portfiles, that tells CMake where to install and get dependencies from). I've never been against making more-or-less standalone app bundles for Mac, though I do feel that for an application family like KDE it would make sense to put as much of the shared resources as possible into something that's installable independently, e.g. a "meta framework" (a bundled collection of libraries, for which Apple used the term before KDE, the confusion is not on me ;)). It'd be an interesting exercise for a more seasoned Mac developer than I am in this aspect, but it ought to be possible to bundle all KF5 frameworks that way into an object that can be installed into /Library/Frameworks. That'd be a perfectly native approach too, with a priori significant maintenance advantages, but out of scope in this conversation. Either way, I've always felt that making applications really work well on OS X was a higher priority than the kind of ribbon you wrap it up with. If you want to know what's feasible to preserve in a feature set used on a different platform you start by working in conditions that are as close as possible to those on that platform. In this case, installing shared resources into a prefix much like pkgsrc and gentoo prefix do, as well as MacPorts, Fink and HomeBrew on Mac (which some consider "nice for linux refugees" which isn't untrue but completely beside the point). Anyway, it's an approach I've been following for about a year now, and it's allowed me to contribute back quite a few improvements to KDE. The thing is that even if I were personally motivated to move on to tweaking the build system to make nicely wrapped-up autonomous app bundles where each app ships with yet another copy of all those Qt and KF5 libraries, I'd still have enough hay on my fork maintaining those MacPorts packages. Adding to that collection is a lesser and to me more satisfying investment than changing course. In short, I'll try to look into Kexi soonish, but I think I shouldn't be be getting involved while it's still undergoing review (remember, hays and forks). FWIW, as I wrote to Boudewijn, I think it'd make sense to investigate dumping cmake as the build system for "really native Mac" builds. Figure out once how to invoke cmake so that a project is built and installs as much as possible the way it should end up inside an autonomous app bundle (i.e. using Contents/MacOS and Contents/Resources, those are the only imperative folders I know of). Then use the CMake Xcode generator to create an Xcode project. Use the Xcode project from there on for Mac "bundled build"s, and cmake for everything else. >example KFileWidget being very Plasma-oriented is close to be removed on >Windows and could be also removed on Mac, in favour of a Url field + [..] >button (KUrlRequester). I have mixed feelings towards the KDE file widget. It's not uncommon that applications provide a non-stock file widget (in fact that's almost exactly what Qt's file dialog is) and KDE's has a number of very useful features that are missing in the Mac file dialog (like tree view). Put it into directory-selection mode however and it's really feels out of place (I much prefer the Mac approach here). >I've also not seen Mac builds of Kexi-derived projects: KDb, KReport, >KProperty. These are general-purpose frameworks and Kexi dependencies. If >they are missing for Mac it would be nice to see them available too as If? Is there reason to suspect that building them on Mac is going to require patching? >frameworks for general use. Framework in which sense? :) R.
Re: "non standalone app bundle" builds on Mac
On 8 November 2016 at 10:36, René J.V. Bertin wrote: > On Monday November 07 2016 18:14:35 Jaroslaw Staniek wrote: > > Hi Jarek, > > >Thanks for the interest! > >In addition Kexi-specific things can be discussed at a kexi-devel list :) > >There were enthusiastic people interested in contributing Mac builds of > >Kexi but they disappeared so this task is open for maintainer. Bundling or > >discovering server installation(s) (pgsql, mysql), bundling dependencies > -- > >these are all task for adoption. > > > > > >In my opinion Kexi fits to a standalone path, just like on Windows, to > >become as native as possible, well, but not more native than that. For > > Right, then there was Kexi too :) It that has been split off the rest of > Calligra it's likely to be much smaller. It's also much more unique in its > approach - if I'd discovered a use for it myself I would have started > working on a port a while ago (port in MacPorts speak; ideally that's just > a build script, Portfiles, that tells CMake where to install and get > dependencies from). > > I've never been against making more-or-less standalone app bundles for > Mac, though I do feel that for an application family like KDE it would make > sense to put as much of the shared resources as possible into something > that's installable independently, e.g. a "meta framework" (a bundled > collection of libraries, for which Apple used the term before KDE, the > confusion is not on me ;)). It'd be an interesting exercise for a more > seasoned Mac developer than I am in this aspect, but it ought to be > possible to bundle all KF5 frameworks that way into an object that can be > installed into /Library/Frameworks. That'd be a perfectly native approach > too, with a priori significant maintenance advantages, but out of scope in > this conversation. > > Either way, I've always felt that making applications really work well on > OS X was a higher priority than the kind of ribbon you wrap it up with. If > you want to know what's feasible to preserve in a feature set used on a > different platform you start by working in conditions that are as close as > possible to those on that platform. In this case, installing shared > resources into a prefix much like pkgsrc and gentoo prefix do, as well as > MacPorts, Fink and HomeBrew on Mac (which some consider "nice for linux > refugees" which isn't untrue but completely beside the point). > > Anyway, it's an approach I've been following for about a year now, and > it's allowed me to contribute back quite a few improvements to KDE. The > thing is that even if I were personally motivated to move on to tweaking > the build system to make nicely wrapped-up autonomous app bundles where > each app ships with yet another copy of all those Qt and KF5 libraries, I'd > still have enough hay on my fork maintaining those MacPorts packages. > Adding to that collection is a lesser and to me more satisfying investment > than changing course. > > In short, I'll try to look into Kexi soonish, but I think I shouldn't be > be getting involved while it's still undergoing review (remember, hays and > forks). > > FWIW, as I wrote to Boudewijn, I think it'd make sense to investigate > dumping cmake as the build system for "really native Mac" builds. Figure > out once how to invoke cmake so that a project is built and installs as > much as possible the way it should end up inside an autonomous app bundle > (i.e. using Contents/MacOS and Contents/Resources, those are the only > imperative folders I know of). Then use the CMake Xcode generator to create > an Xcode project. Use the Xcode project from there on for Mac "bundled > build"s, and cmake for everything else. > I hope special cases in a cmake buildsystem would not be a problem. I've worked with cmake-based build systems that support Makefiles generator (JOM/NMake) and VS generators in the same cmake scripts. The later is a multi-generator so it adds so much extra work since it's different than the Makefiles gen. For now I have not checked if the current xCode generator is as complex in use as the VS in this regard. Thoughts? In some pre-CMake times (qmake times) I've worked with bundling Mac binaries and once we have tools that work in batch mode we were OK. Medium or large apps were packaged using scripts. I'd appreciate some info on how do you see the current situation (of xCode cmake generator?) if we don't want to require manual mouse clicks in xCode to prepare builds. >example KFileWidget being very Plasma-oriented is close to be removed on > >Windows and could be also removed on Mac, in favour of a Url field + [..] > >button (KUrlRequester). > > I have mixed feelings towards the KDE file widget. It's not uncommon that > applications provide a non-stock file widget (in fact that's almost exactly > what Qt's file dialog is) and KDE's has a number of very useful features > that are missing in the Mac file dialog (like tree view). Put it into > directory-selection mode however and
Re: "non standalone app bundle" builds on Mac
On Tuesday November 08 2016 12:17:23 Jaroslaw Staniek wrote:
>
> I hope special cases in a cmake buildsystem would not be a problem. I've
> worked with cmake-based build systems that support Makefiles generator
> (JOM/NMake) and VS generators in the same cmake scripts. The later is a
> multi-generator so it adds so much extra work since it's different than the
> Makefiles gen. For now I have not checked if the current xCode generator is
> as complex in use as the VS in this regard. Thoughts?
I have no idea how it compares to the VS generator. It's been improved recently
and I've checked a few projects, but haven't gone much beyond that. I think
manual tuning of the project would be required, esp. if you want to do things
that you cannot really achieve directly with CMake.
> or large apps were packaged using scripts. I'd appreciate some info on how
> do you see the current situation (of xCode cmake generator?) if we don't
> want to require manual mouse clicks in xCode to prepare builds.
See above, Xcode projects are like MSVC projects in that you maintain them
manually ("what you see is all you get" ...). I actually have little experience
with the current Xcode versions as I've drifted away from development requiring
its use since I'm no longer using OS X 10.6 . However, as with MSVC there is
usually little more you have to do than simply adding new files to targets.
Once you have a project though you can build it from the commandline, there's
an xcodebuild utility that knows quite a few tricks for that.
>
> >
>
> Nope, really, clang shall build them just fine and they should work; only
> plugin paths are most probably something to test if we want to use non-Unix
> approach to paths.
Yes, QStandardPaths is a problem. Qt folks may disagree, but I have the
impression it wasn't designed with much regard for the potential special needs
of complex software like KDE's on platforms that don't use XDG-compliant
locations (that's what we're really talking about here).
It's also a pity that there is nothing (in the ECM for instance) that
determines the install locations from the QStandardPath locations, that should
remove the need for a lot of hacking and additional testing.
> As programming frameworks, so programmers can pick up them as they pick up
> parts of KF5 or some other extra Qt modules for they project. In a
I repeat, "framework" is a term that's already taken in the Mac universe :)
One habit that I see which stands in the way of building KF5 libraries
(including those with framework status) as a Mac framework is the way headers
are included.
KDE software mostly uses the form
#include
whereas on Mac you'd include the main header of a Foo.framework with (presuming
it's not ObjC)
#include
this tells the compiler to search for
{/System,}/Library/Frameworks/Foo.frameworks/Headers/Foo in addition to
/usr{/local,}/include/Foo/Foo plus any in other paths you may have specified.
You'd have to add the individual .framework/Headers directories to include them
if you don't use the "rich" specification. Not the easiest thing to do in Xcode
(the interface is a bit clunky).
A bit of a missed chance: most all of KF5's framework headerfiles install in a
way that would make them accessible using the Foo/Foo notation...
R
Re: "non standalone app bundle" builds on Mac
On 8 November 2016 at 13:09, René J.V. Bertin wrote:
> On Tuesday November 08 2016 12:17:23 Jaroslaw Staniek wrote:
>
> >
> > I hope special cases in a cmake buildsystem would not be a problem. I've
> > worked with cmake-based build systems that support Makefiles generator
> > (JOM/NMake) and VS generators in the same cmake scripts. The later is a
> > multi-generator so it adds so much extra work since it's different than
> the
> > Makefiles gen. For now I have not checked if the current xCode generator
> is
> > as complex in use as the VS in this regard. Thoughts?
>
> I have no idea how it compares to the VS generator. It's been improved
> recently and I've checked a few projects, but haven't gone much beyond
> that. I think manual tuning of the project would be required, esp. if you
> want to do things that you cannot really achieve directly with CMake.
>
> > or large apps were packaged using scripts. I'd appreciate some info on
> how
> > do you see the current situation (of xCode cmake generator?) if we don't
> > want to require manual mouse clicks in xCode to prepare builds.
>
> See above, Xcode projects are like MSVC projects in that you maintain them
> manually ("what you see is all you get" ...). I actually have little
> experience with the current Xcode versions as I've drifted away from
> development requiring its use since I'm no longer using OS X 10.6 .
> However, as with MSVC there is usually little more you have to do than
> simply adding new files to targets.
> Once you have a project though you can build it from the commandline,
> there's an xcodebuild utility that knows quite a few tricks for that.
>
> >
>
> > >
> >
> > Nope, really, clang shall build them just fine and they should work;
> only
> > plugin paths are most probably something to test if we want to use
> non-Unix
> > approach to paths.
>
> Yes, QStandardPaths is a problem. Qt folks may disagree, but I have the
> impression it wasn't designed with much regard for the potential special
> needs of complex software like KDE's on platforms that don't use
> XDG-compliant locations (that's what we're really talking about here).
> It's also a pity that there is nothing (in the ECM for instance) that
> determines the install locations from the QStandardPath locations, that
> should remove the need for a lot of hacking and additional testing.
>
> > As programming frameworks, so programmers can pick up them as they pick
> up
> > parts of KF5 or some other extra Qt modules for they project. In a
>
> I repeat, "framework" is a term that's already taken in the Mac universe :)
>
I know that so let's use 'Mac Frameworks' term for that :)
> One habit that I see which stands in the way of building KF5 libraries
> (including those with framework status) as a Mac framework is the way
> headers are included.
> KDE software mostly uses the form
>
> #include
>
> whereas on Mac you'd include the main header of a Foo.framework with
> (presuming it's not ObjC)
>
> #include
>
Maybe that can be seen as misfeature of Xcode and related tools because a
point is that the header is _silently_ found even if you're not
linking against respective library that the headers belong too. Then
linking errors (or worse, runtime errors) happen. With you're just
sure that if you used the cmake tools that find libraries (packages) for
you, you get much nicer preprocessor error if you missed certain entry in
target_link_libraries().
> this tells the compiler to search for
> {/System,}/Library/Frameworks/Foo.frameworks/Headers/Foo
> in addition to /usr{/local,}/include/Foo/Foo plus any in other paths you
> may have specified. You'd have to add the individual .framework/Headers
> directories to include them if you don't use the "rich" specification. Not
> the easiest thing to do in Xcode (the interface is a bit clunky).
>
> A bit of a missed chance: most all of KF5's framework headerfiles install
> in a way that would make them accessible using the Foo/Foo notation...
>
> R
>
I'd like to see the headers portable across platforms...
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
Need some help with styles
Hi, I'm tracking a bug in Sheets style handling but I'm uncertain of how
to fix it because I don't understand the code alt. how styles should
work.
I thought default styles where used when there was no style assigned to
an object, and *maybe* used to give default values for things not
specified in a style (but I thought parent style where used for that)?
In Odf::loadSheetInsertStyles()
we have code like this:
if (autoStyles.contains(styleNames[i])) {
Style style;
style.setDefault(); // "overwrite" existing style
style.merge(autoStyles[styleNames[i]]);
outStyleRegions.append(qMakePair(styleRegion, style));
} else {
which effectivly adds a default sub style to the autostyle.
Then there is the comment: // "overwrite" existing style
What can that mean?
Later a new style is composed based on this style with code in:
StyleStorage::composeStyle()
for (int i = 0; i < subStyles.count(); ++i) {
if (subStyles[i]->type() == Style::DefaultStyleKey) {
style = *styleManager()->defaultStyle();
qDebug()
Re: "non standalone app bundle" builds on Mac
On Tuesday November 08 2016 13:20:37 Jaroslaw Staniek wrote:
> > KDE software mostly uses the form
> >
> > #include
> >
> > whereas on Mac you'd include the main header of a Foo.framework with
> > (presuming it's not ObjC)
> >
> > #include
> >
>
> Maybe that can be seen as misfeature of Xcode and related tools because a
> point is that the header is _silently_ found even if you're not
No, I don't think you can say that. Support for this (and frameworks bundles)
has even made it into gcc (on Linux too); I doubt that would have happened if
there were anything wrong with the principle.
I'm fairly certain that Qt also use the notation in their code and
examples (#include ).
I see your point about protection, but it's simple enough to avoid that. How
can you pick up the wrong Foo/Foo headers but pick the right corresponding
libFoo or Foo.framework, or vice versa? If that happens there's something wrong
with your install.
The KF5 framework headers all live under ${prefix}/include/KF5, meaning that
even with a notation you still have to point the compiler to the
appropriate parent directory.
As a bonus you do not end up with endless compiler command lines on which you
can no longer find relevant information (or which might even lead to issues
when they become too long).
> you, you get much nicer preprocessor error if you missed certain entry in
> target_link_libraries().
I don't think the preprocessor cares what cmake did or didn't do :)
R.
Re: "non standalone app bundle" builds on Mac
On 8 November 2016 at 14:50, René J.V. Bertin wrote:
> On Tuesday November 08 2016 13:20:37 Jaroslaw Staniek wrote:
>
> > > KDE software mostly uses the form
> > >
> > > #include
> > >
> > > whereas on Mac you'd include the main header of a Foo.framework with
> > > (presuming it's not ObjC)
> > >
> > > #include
> > >
> >
> > Maybe that can be seen as misfeature of Xcode and related tools because a
> > point is that the header is _silently_ found even if you're not
>
> No, I don't think you can say that. Support for this (and frameworks
> bundles) has even made it into gcc (on Linux too); I doubt that would have
> happened if there were anything wrong with the principle.
>
> I'm fairly certain that Qt also use the notation in their code
> and examples (#include ).
>
> I see your point about protection, but it's simple enough to avoid that.
> How can you pick up the wrong Foo/Foo headers but pick the right
> corresponding libFoo or Foo.framework, or vice versa? If that happens
> there's something wrong with your install.
>
> The KF5 framework headers all live under ${prefix}/include/KF5, meaning
> that even with a notation you still have to point the compiler to
> the appropriate parent directory.
>
> As a bonus you do not end up with endless compiler command lines on which
> you can no longer find relevant information (or which might even lead to
> issues when they become too long).
>
> > you, you get much nicer preprocessor error if you missed certain entry in
> > target_link_libraries().
>
> I don't think the preprocessor cares what cmake did or didn't do :)
>
>
Fine with me, what are the KF5 rules say?
It's a SoK period so it's pretty possible that some students can help with
such changes :)
R.
>
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
Jenkins-kde-ci: calligra master kf5-qt5 » Linux,gcc - Build # 124 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/calligra%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/124/ Project: PLATFORM=Linux,compiler=gcc Date of build: Tue, 08 Nov 2016 13:35:02 + Build duration: 34 min CHANGE SET Revision c628b944a1aef24a5fe79c4b98f110c67eec670c by Dag Andersen: (Words: Do not open a "Connect Text Frame" pane to non-text shapes) change: edit words/part/KWView.cpp change: edit words/part/dialogs/KWFrameConnectSelector.cpp JUNIT RESULTS Name: (root) Failed: 5 test(s), Passed: 153 test(s), Skipped: 0 test(s), Total: 158 test(s)Failed: TestSuite.libs-koodf-TestNumberStyleFailed: TestSuite.libs-pigment-TestColorConversionSystemFailed: TestSuite.sheets-DatetimeFunctionsFailed: TestSuite.sheets-ValueConverterFailed: TestSuite.sheets-ValueParser COBERTURA RESULTS Cobertura Coverage Report PACKAGES 155/188 (82%)FILES 1343/2955 (45%)CLASSES 1343/2955 (45%)LINE 97563/319391 (31%)CONDITIONAL 63120/359389 (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/2456 (0%)CONDITIONAL 1/1698 (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.kross FILES 0/10 (0%)CLASSES 0/10 (0%)LINE 0/730 (0%)CONDITIONAL 0/496 (0%) libs.kundo2 FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 209/732 (29%)CONDITIONAL 70/410 (17%) libs.main FILES 27/73 (37%)CLASSES 27/73 (37%)LINE 734/7139 (10%)CONDITIONAL 785/16833 (5%) 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.command
Re: Need some help with styles
Hello Dag,
The way the inhertance works is described here:
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416276_253892949
Roughly, if a style does not define a property, there are quite a few places
where the code can look to find a value. First it looks in the parent styles.
If those do not define the property, that style of the parent element (and it's
parent styles) are queried. If that leads nowhere, the
comes into play and only then should the code resort to using an
implementation specific default value.
Cheers,
Jos
On Tuesday 08 November 2016 14:25:54 Dag wrote:
> Hi, I'm tracking a bug in Sheets style handling but I'm uncertain of how
> to fix it because I don't understand the code alt. how styles should
> work.
>
> I thought default styles where used when there was no style assigned to
> an object, and *maybe* used to give default values for things not
> specified in a style (but I thought parent style where used for that)?
>
> In Odf::loadSheetInsertStyles()
> we have code like this:
> if (autoStyles.contains(styleNames[i])) {
> Style style;
> style.setDefault(); // "overwrite" existing style
> style.merge(autoStyles[styleNames[i]]);
> outStyleRegions.append(qMakePair(styleRegion, style));
> } else {
>
> which effectivly adds a default sub style to the autostyle.
>
> Then there is the comment: // "overwrite" existing style
> What can that mean?
>
> Later a new style is composed based on this style with code in:
> StyleStorage::composeStyle()
>
> for (int i = 0; i < subStyles.count(); ++i) {
> if (subStyles[i]->type() == Style::DefaultStyleKey) {
> style = *styleManager()->defaultStyle();
> qDebug()< } else if (subStyles[i]->type() == Style::NamedStyleKey) {
> etc. (adding the different substyles)
>
> One problem here is that the position of the default substyle in the
> list seems to be random, and since all substyles positioned *before* the
> default substyle is forgotten about, the resulting style is also random.
>
> Boudewijn, git blame says you added this in 2009, I'm sure you can
> remember why? It is only 7 years ago :)
>
> The way I hit this was to format a number as scientific and then
> save/load; sometimes it is formatted as scientific, other times as a
> float.
>
> Cheers, Dag
Re: state of release and release plan
Ok, seems we have some sort of commitment from from Tomas, Camilla (separate mail) and me, which means Sheets, Words and Plan along with the shapes and filters we find is working. But, I am totally blank on release work, so who will possibly step up to handle that? Tomas Mecir skrev den 2016-10-26 14:58: 2016-10-26 14:03 GMT+02:00 Dag : I would support plan of course, but what about words and sheets? Camila and Tomas; what are you able to commit to, are there others? Varies. Bit more busy the last few months, will be better soonish. But still interested, ya. Sheets is in a decent shape, some things to sort out still, but nothing huge. Obviously there always are a lot of things that could be added/improved. Tomas
Re: Need some help with styles
Jos van den Oever skrev den 2016-11-08 16:24:
Hello Dag,
The way the inhertance works is described here:
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416276_253892949
Yes, this looks fairly sane, thanks.
Roughly, if a style does not define a property, there are quite a few
places
where the code can look to find a value. First it looks in the parent
styles.
If those do not define the property, that style of the parent element
(and it's
parent styles) are queried. If that leads nowhere, the
comes into play and only then should the code resort to using an
implementation specific default value.
I think Sheets are close to doing this, except for the case I outline
below but I have to look at it again with a clear head.
Thanks again.
Cheers,
Jos
On Tuesday 08 November 2016 14:25:54 Dag wrote:
Hi, I'm tracking a bug in Sheets style handling but I'm uncertain of
how
to fix it because I don't understand the code alt. how styles should
work.
I thought default styles where used when there was no style assigned
to
an object, and *maybe* used to give default values for things not
specified in a style (but I thought parent style where used for that)?
In Odf::loadSheetInsertStyles()
we have code like this:
if (autoStyles.contains(styleNames[i])) {
Style style;
style.setDefault(); // "overwrite" existing style
style.merge(autoStyles[styleNames[i]]);
outStyleRegions.append(qMakePair(styleRegion, style));
} else {
which effectivly adds a default sub style to the autostyle.
Then there is the comment: // "overwrite" existing style
What can that mean?
Later a new style is composed based on this style with code in:
StyleStorage::composeStyle()
for (int i = 0; i < subStyles.count(); ++i) {
if (subStyles[i]->type() == Style::DefaultStyleKey) {
style = *styleManager()->defaultStyle();
qDebug()
