Resetting metadata after new from template ?
Hi Right now, when we create a new empty document (at least for words), like any other office suite, it is created from a template. But we currently lack the reset of some metadata from our templates, leading to funny situations… For instance, any document created by calligra using the A4 template is more than 7 years old :) We have several possible fix : - strip metadata from templates : we would still copy the metadata for user templates, including creation date, bad imho - strip all metadata when creating a file from template : bad too, users could have specific metadata they don't want to lose - override specific metadata like the creation date with sane values Each one is very simple to implement, I just don't know which one is the best. I would go for the third option, but I don't have a list of metadata to erase. (we already override the generator BTW, but elsewhere in the saving code) Any thoughts on this ? Thanks Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Resetting metadata after new from template ?
On Tuesday, February 02, 2016 02:08:53 PM Jaroslaw Staniek wrote: > On 1 February 2016 at 23:20, Pierre wrote: > > Hi > > > > Right now, when we create a new empty document (at least for words), like > > any > > other office suite, it is created from a template. But we currently lack > > the > > reset of some metadata from our templates, leading to funny situations… For > > instance, any document created by calligra using the A4 template is more > > than > > 7 years old :) > > > > We have several possible fix : > > - strip metadata from templates : we would still copy the metadata for user > > templates, including creation date, bad imho > > - strip all metadata when creating a file from template : bad too, users > > could > > have specific metadata they don't want to lose > > - override specific metadata like the creation date with sane values > > > > Each one is very simple to implement, I just don't know which one is the > > best. > > I would go for the third option, but I don't have a list of metadata to > > erase. > > (we already override the generator BTW, but elsewhere in the saving code) > > > > Any thoughts on this ? > > Very interesting finding > , Pierre. > If you ask me, the 3rd option looks best. Documenting the new behaviour, > whatever it is, in the API docs, would be useful. I just went through the ODF 1.2 spec part regarding metadata, I think we should reset all the meta data defined in the spec except "meta:user-defined"… And remember to fill in the meta:template with the XLink to the source template. If nobody disagrees nor sees anything hazardous in it, I'll implement that. signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Resetting metadata after new from template ?
On Thursday, February 04, 2016 01:55:19 PM Friedrich W. H. Kossebau wrote: > Hi Pierre, > > Am Dienstag, 2. Februar 2016, 22:21:59 schrieb Pierre: > > On Tuesday, February 02, 2016 02:08:53 PM Jaroslaw Staniek wrote: > > > On 1 February 2016 at 23:20, Pierre wrote: > > > > Hi > > > > > > > > Right now, when we create a new empty document (at least for words), > > > > like > > > > any > > > > other office suite, it is created from a template. But we currently lack > > > > the > > > > reset of some metadata from our templates, leading to funny situations… > > > > For > > > > > > instance, any document created by calligra using the A4 template is more > > > > than > > > > 7 years old :) > > > > > > > > We have several possible fix : > > > > - strip metadata from templates : we would still copy the metadata for > > > > user > > > > > > templates, including creation date, bad imho > > > > - strip all metadata when creating a file from template : bad too, users > > > > could > > > > have specific metadata they don't want to lose > > > > - override specific metadata like the creation date with sane values > > > > > > > > Each one is very simple to implement, I just don't know which one is the > > > > best. > > > > I would go for the third option, but I don't have a list of metadata to > > > > erase. > > > > (we already override the generator BTW, but elsewhere in the saving > > > > code) > > > > > > > > Any thoughts on this ? > > > > > > Very interesting finding > > > , Pierre. > > > If you ask me, the 3rd option looks best. Documenting the new behaviour, > > > whatever it is, in the API docs, would be useful. > > > > I just went through the ODF 1.2 spec part regarding metadata, I think we > > should reset all the meta data defined in the spec except > > "meta:user-defined"… And remember to fill in the meta:template with the > > XLink to the source template. > > If nobody disagrees nor sees anything hazardous in it, I'll implement that. Hi > Happy to see you pick this up, I have found this annoying/funny as well :) > > And I agree with & support your implementation plan basically, just a few > modifications I would like to propose, read on. > > IMHO the ODF spec has a flaw here WRT metadata and templates. Not only for metadata, there is almost no template specification, but that is understandable if we consider ODF to be a document representation specification and not an office suite specification. > There should be separate metadata for the actual template, and separate > metadata for the to-be-generated document. The first can be used as usual, > to know more about the template itself when managing templates, and the > second can be used to preset metadata of the actual generated document, as > it fits (e.g. keywords, language, or whatever user-defined keys are standard > with the organisation using the documents). (someone should bring this up in > the OASIS TC, what, me?) > > But we have to deal now with what there is in the current spec. So I would > agree that resetting/dumping most metadata on document creation makes sense. > > For the pre-defined metadata (as in ODF 1.2, §4.3.2) I think the following > metadata could be kept though, as they are about the document/content type > and less about the template, or only really make sense with the actual > document. > So if they are present and set, they could be considered to target the > created document, right? > * > * > * > > For and it is hard to tell, given their > less specific semantics. They could contain data only useful for template > management or could be preset metadata for the generated document. > Having to choose between the chance to leak template handling data into > generated documents and the inability to preset metadata for documents, the > second seems a greater issue for me (given I have no template tags like > "form letter to shutdown stupid customers" ;) ). > > So I agree, let's keep , but then also . > > And then there is RDF metadata (§4.2.2), which for the non-content-specific > statements has the same problem as and . > So better kept as is. > > Custom metadata (§4.3.1) would also be treated like and > for the same reasons, keeping as is. > > So in summary, IMHO we should reset/drop these predefined metadata types: > - res
Re: Coverity scan results
On Tuesday, February 16, 2016 09:00:58 PM Nick Shaforostoff wrote: > Hi! I just wanted to let you know that Coverity static analyzer scan results > are ready for most of KDE packages including Calligra. > > Please look at the results via > https://scan.coverity.com/projects/kde?tab=overview Hi I registered to look at the results, my access got granted 2 days ago, but when I click on «View defects», I'm redirected to https://scan.coverity.com/projects/kde/view_defects and I then get the message «Failed to view defects: It may take a few minutes before you can view your defects for the first time or when you change your email.» Do you have any idea why this happens ? Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Coverity scan results
On Friday, February 19, 2016 02:05:04 AM Nick Shaforostoff wrote: > > https://scan.coverity.com/projects/kde/view_defects and I then get the > > message «Failed to view defects: It may take a few minutes before you can > > view your defects for the first time or when you change your email.» > > which browser do you use? > i use chromium and it works fine. > if the problem persists - i suggest writing to Coverity support. I contacted them, it doesn't work with either firefox, chromium or konqueror, on different IP addresses… signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Static code analysis - the easiest way to improve
On Tuesday, March 15, 2016 05:45:44 PM Jaroslaw Staniek wrote: > On 15 March 2016 at 17:33, Tomas Mecir wrote: > > No change for me, unfortunately, still getting that red box (tried > > both password and github login). > > I see. All I did is asking scan-ad...@coverity.com 2 times or so. > And waiting 2+ weeks. Maybe they're fixing/enabling access one-by-one. Same for me, it took them some time and they fixed it. It seems to be fixed one-by-one. signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Congratulations on the handshake founding
Hi everybody I saw today on dot.kde that you received a 100k USD donation for the development of Calligra. This is an amazing news, congratulations everybody. I am so sorry not having time to be involved any more, but I keep an eye opened and if you have questions about some stuff I wrote, or just want to chat, I'm often on freenode (nick Pinaraf). Wish you the best Pierre signature.asc Description: This is a digitally signed message part.
Minimum dependency versions
Hello friends Long time no see, how are you all? Life and health have kept me away from this project for too long, but as you may have seen from the merge requests in gitlab I am trying to come back a bit. I am looking at the build warnings right now, and a lot of them are about deprecations, that's easy to fix so I will look into them (this may also ease future Qt6 transition, who knows). But the current minimum version requirements from CMakeLists.txt are a bit low. Is there a lot of people still trying to build Calligra with Qt 5.3 or KF5 5.7.0 ? These are years old, and I guess building Calligra with them has been untested for some time. May I suggest updating to Qt 5.12 / KF5 5.60 ? This would be a first step, and will make it easier to fix deprecation warnings in a way that should work with all supported Qt and KF5 versions. Regards Pierre Ducroquet signature.asc Description: This is a digitally signed message part.
Re: Minimum dependency versions
On Wednesday, February 10, 2021 9:13:49 AM CET Halla Rempt wrote: > On Wednesday, 10 February 2021 08:44:54 CET Pierre wrote: > > Is there a lot of people still trying to build Calligra with Qt 5.3 or KF5 > > 5.7.0 ? These are years old, and I guess building Calligra with them has > > been untested for some time. > > I think that the Jolla people still build the documents application with Qt > 5.9. Then Qt 5.9 instead of 5.3? At least we would come back into the easy-to-find- documentation level :) Do you have any insight about the KF5 version they use? signature.asc Description: This is a digitally signed message part.
Re: Minimum dependency versions
On Wednesday, February 10, 2021 9:30:43 AM CET Adam Pigg wrote: > I wish!!! ... try qt 5.6! > > On Wed, 10 Feb 2021 at 08:14, Halla Rempt wrote: > > On Wednesday, 10 February 2021 08:44:54 CET Pierre wrote: > > > Is there a lot of people still trying to build Calligra with Qt 5.3 or > > > KF5 > > > 5.7.0 ? These are years old, and I guess building Calligra with them has > > > been untested for some time. > > > > I think that the Jolla people still build the documents application with > > Qt 5.9. > > > > -- > > https://www.krita.org I created this MR then : https://invent.kde.org/office/calligra/-/merge_requests/10 At least it's no longer Qt 5.3 / KF 5.7, and a bunch of deprecated stuff is cleaned up (I built locally disabling deprecated Qt APIs). But Jolla decided to stay at Qt 5.6 out of fear from LGPLv3, as far as I understand. Does it means Calligra would have to be stuck in an untested setup? I no longer have a Jolla phone, do they update from Calligra frequently? And is there a lot of people still building with Qt 5.6 and testing so we are sure there is no regressions there? signature.asc Description: This is a digitally signed message part.
Re: Minimum dependency versions
On Wednesday, February 10, 2021 8:45:23 PM CET Camilla Boemann wrote: > I agree let's move ahead. We can't be defined by what Jolla does and needs > > However let's only do it if development is going to pick up. No need to > annoy Jolla and then for everything to stall. Well if everything stalls, it won't be an issue for them since they won't have much to gain from updating anyway… Should we proceed one LTS at a time, or just jump to 5.12, disable deprecated APIs and move forward from there? signature.asc Description: This is a digitally signed message part.
Re: Minimum dependency versions
On Wednesday, February 10, 2021 8:39:35 PM CET Carl Schwan wrote: > Le mercredi, février 10, 2021 7:45 PM, Pierre a écrit : > > On Wednesday, February 10, 2021 9:30:43 AM CET Adam Pigg wrote: > > > I wish!!! ... try qt 5.6! > > > > > > On Wed, 10 Feb 2021 at 08:14, Halla Rempt b...@valdyas.org wrote: > > > > On Wednesday, 10 February 2021 08:44:54 CET Pierre wrote: > > > > > Is there a lot of people still trying to build Calligra with Qt 5.3 > > > > > or > > > > > KF5 > > > > > 5.7.0 ? These are years old, and I guess building Calligra with them > > > > > has > > > > > been untested for some time. > > > > > > > > I think that the Jolla people still build the documents application > > > > with > > > > Qt 5.9. > > > > -- > > > > https://www.krita.org > > > > I created this MR then : > > https://invent.kde.org/office/calligra/-/merge_requests/10 > > > > At least it's no longer Qt 5.3 / KF 5.7, and a bunch of deprecated stuff > > is > > cleaned up (I built locally disabling deprecated Qt APIs). > > > > But Jolla decided to stay at Qt 5.6 out of fear from LGPLv3, as far as I > > understand. Does it means Calligra would have to be stuck in an untested > > setup? I no longer have a Jolla phone, do they update from Calligra > > frequently? And is there a lot of people still building with Qt 5.6 and > > testing so we are sure there is no regressions there? > > Hi, > > Your MR looks good to me. Concerning the minimum version requirement, I > worked a bit last year to remove a lot of warnings and I was blocked to > move further by the minimum requirements. > > Personally, I'm not sure if it is worth continuing to support Qt 5.6. > Calligra can't continue to use on Qt 5.6 as the minimum required version > for years when we are moving to Qt 6 in a timespan of 1 or 2 years with the > rest of KDE. Also as you said I'm not sure anyone is testing regressions > and the Gemini QML code is definitively using Qt 5.12 only code. Jolla > needs to move forwards with their LGPLv3 problem or they will end up > obsolete compared to the rest of the Qt world. > > I would propose moving all the way to Qt 5.12 or even 5.15, so we can start > fixing deprecations in time for Qt6. And maybe in the second step, we should > consider moving to C++17 too. > > Regards, > Carl Hi Since there seems to be an agreement on at least Qt 5.6, if you don't mind, I will go forward and merge my MR. The question remains regarding Qt 5.12 or later. From a technical perspective, I'll have a look at the impact of requesting this version as a minimum. But the question of our behaviour/relationship with Jolla remains. A Jolla developer commneted on my MR to thank us for keeping it to Qt 5.6. Does anybody here have an insight regarding their upgrade plan? They can't stay on Qt5.6 forever, at some point no community has to carry the burden of their decisions… Regards Pierre signature.asc Description: This is a digitally signed message part.
Code for msoscheme?
Hello I am looking at several warnings in the code generated by msoscheme in the libmso filters. The fix should be easy, but I can not find the the msoscheme source code. The url we have is on gitorious.org. Does somebody have a more uptodate location for this code, or should we consider it lost? Regards Pierre signature.asc Description: This is a digitally signed message part.
Re: Code for msoscheme?
On Thursday, February 11, 2021 9:45:01 PM CET you wrote: > On donderdag 11 februari 2021 21:40:19 CET Pierre wrote: > > Hello > > Hi Pierre! > > > I am looking at several warnings in the code generated by msoscheme in the > > libmso filters. The fix should be easy, but I can not find the the > > msoscheme source code. The url we have is on gitorious.org. > > Does somebody have a more uptodate location for this code, or should we > > consider it lost? > > No, it's in invent.kde.org. > > https://invent.kde.org/libraries/binschema > > ⤳Jos Thanks! Here you go then: https://invent.kde.org/libraries/binschema/-/merge_requests/1 :) signature.asc Description: This is a digitally signed message part.
Next release schedule/plans
Hi Since the tickets and things I want to do may have varying duration, I would like to know if there is any schedule/plan set for the next major release. Depending on the timeframe, I could switch from small tickets to bigger ones more easily. On a side note, is there any rule regarding the merge requests in the project? I'm not used to this kind of tool outside company projects where there are rules like 'another contributor approval is needed' or 'every single change must go through a merge request'. For the small fixes I am pushing so far, asking for a review may be overkill… Regards Pierre signature.asc Description: This is a digitally signed message part.
Clazy fixes and CI…
Hi In order to rejuvenate a bit some parts of the code base, I am looking into Clazy, especially the old-style connect fixit. In several projects, switching away from these made the application more reliable, with issues being catched at build time instead of run time. Do you see any reason not to do that? I plan to do it on words and its libs first since that's what I will test the most, but if you want I can do it on the whole project. After that cleanup is done, I will start looking into setting up a CI and running the unit tests we have automatically in gitlab. I think this could lower the entry barrier for new/junior developers… If somebody else already tried/did that, any feedback/hint/help is welcome obviously. Cheers Pierre signature.asc Description: This is a digitally signed message part.
Re: Clazy fixes and CI…
On Saturday, February 13, 2021 3:24:35 PM CET Dan Leinir Turthra Jensen wrote:
> Definitely support that effort as well, they are /much/ nicer to work with
> just all 'round, and even if we can only depend on Qt 5.6, we /can/ depend
> on a sufficiently modern compiler for our code to be less... ancient ;) So
> yeah, definitely go for it :)
>
Work is in progress then:
https://invent.kde.org/office/calligra/-/merge_requests/16
Some old style remain due to the use of Q_PRIVATE_SLOT.
Do we want to use Qt features marked as, I quote, "for use in private Qt APIs
only"?
This can be worked around for connect with a lambda, like
QObject::connect(findStrategy.dialog(), &KFindDialog::okClicked,
q, [this]() { q->d->startFind(); });
But if these are to leave and never come back, I'd much rather get rid of them
and not work around them :)
signature.asc
Description: This is a digitally signed message part.
Re: Clazy fixes and CI…
On Saturday, February 13, 2021 2:43:46 PM CET Pierre wrote: > Hi > > In order to rejuvenate a bit some parts of the code base, I am looking into > Clazy, especially the old-style connect fixit. In several projects, > switching away from these made the application more reliable, with issues > being catched at build time instead of run time. > Do you see any reason not to do that? I plan to do it on words and its libs > first since that's what I will test the most, but if you want I can do it on > the whole project. > After that cleanup is done, I will start looking into setting up a CI and > running the unit tests we have automatically in gitlab. I think this could > lower the entry barrier for new/junior developers… If somebody else already > tried/did that, any feedback/hint/help is welcome obviously. > > Cheers > > Pierre Hi My first Merge Requests regarding Clazy is kind of ready. There is still a lot to fix, but it's already kind of big… 453 files changed, 3158 insertions(+), 3215 deletions(-) If you want to review, do not hesitate, but I would understand if nobody had time for that. https://invent.kde.org/office/calligra/-/merge_requests/16 I've split it in commits, one commit per fix type + one extra for several small fixes I found while doing the others, including one typo that could break ODF compatibility on a specific attribrute. Number of clazy issues reported has been divided by 3, still a lot to do and far less automatic fixits available now… Regards Pierre signature.asc Description: This is a digitally signed message part.
Merge request in need of a review
Hi everybody While doing some cleanups (QRegExp => QRegularExpression conversion) I found in Words KWStatisticsWidget a TODO that was looking easy to do and would be a relaxation moment after spending days in cleanups : extract the statistics logic into a non-UI object so it can be reused by both QWidget and QML UIs. I've create a merge request for this change because I really would like to be sure it matches the expectation for UIs like gemini, and because of some trickery I used to compute statistics only when someone is listening to them. https://invent.kde.org/office/calligra/-/merge_requests/23 I would of course understand if nobody had time to spend on this topic. If there is no review nor objection, I will merge this request next week and let changes be made by iteration rather than before merging. BTW, for the french-reading people, I've written a small article about my recent "contribution spree" on calligra. Don't get it wrong, I'm not doing this to show off, I'm only trying my best to get new people to contribute to the project, showing that it's still alive. https://linuxfr.org/users/pied/journaux/723-5736-5696-un-mois-de-travail-de-resurrection-d-un-projet-libre Regards Pierre signature.asc Description: This is a digitally signed message part.
Proposed release calendar
Hi everyone I was looking at our current changelog in master, and while we don't have much to show regarding new features, several stability fixes were added, and the Qt 5.15 compatibility may come in handy for distributors. Since I don't know of any release calendar/planning, I would like to suggest the following approximate calendar : - end of month : 3.3 alpha 1, targeting 3.3 stable in the following months - end of 2021 : 3.4, switch dependencies to Qt 5.15 / KF 5.80, aka big-jump- proofness From a feature point of view, I have no plan, but I guess moving to Qt 5.15 won't take that much time so there will be some things to show… Is this ok for everybody? Regards Pierre signature.asc Description: This is a digitally signed message part.
Re: Words and large files
On Monday, March 22, 2021 9:01:21 AM CET Dag wrote: > Hi, opened the odf spec in words the other day. > This is a document with 800+ pages and a TOC of 60+ pages. > I did the same in LO to compare. > Don't take the absolute times too seriously as my box is well into its > teenage years. > But, I think comparison with LO says a lot: > > Open: 2,5 mins, LO: 40 secs. > Except that TOC page numers is not shown (just ###), navigation, scrolling > etc works fine. > Save: 4 mins, LO: 30 secs. > > And now to the bad part: > When a try to type a character words freezes for about 50 secs. > It seems the whole doc is re-layouted and also the TOC is updated (page > numbers appear). > > Then when auto-save kicks in words freezes again without any feedback. I > expected to see a status meassage and a progress bar, but no. > > Krita solved freeze by making a copy of the doc and save in the background. > > LO is better (but not good). > Generally you can type new text wo problems but it freezes for shorter > periods (maybe when updating page numbers), and it freezes when > auto-saving. > > It never updates the TOC, this needs to be done manually. > > Suggestions (just my 2 cents): > 1) TOC should be updated manually to avoid re-layout. > 2) Auto-save in the background. > 3) Minimize re-layout by e.g. only re-layout dirty pages before and > including the displayed page(s). Hi Thanks for bringing this topic back on the table, long time I did not try to do that. On my computer, opening with LO takes 4s, 20s with words… so about the same ratio as you have. Since my last experiment in this topic, the performance analysis tooling has improved so much that this will be a fun thing to do. I'll see what this gives. And I completely agree with at least parts 1 and 3 of your conclusion. Can not tell for the second part, I must think a bit more about it. And I disagree with René's conclusions. Having performance issue today doesn't mean we can not fix them. And unlike the webbrowser comparison, we are not chasing a perpetually moving target with thousands of corporate developers adding features on their engines while being 0.1 unpaid developer on our engine… It's more like a few unpaid developers against less unpaid developers. Still not the best position for us, but far more manageable. Pierre signature.asc Description: This is a digitally signed message part.
Re: Words and large files
So… firing up perf record and hotspot, with OpenDocument spec 1.2 (that's what I found in my homedir)… It takes about 21s to load, of which 34% is spent parsing the document (7s, still too much, but let's accept it so far) and 59% of the time is spent layouting. 14% of time is spent in KoTextRange::document() from KoTextRangeManager::textRangesChangingWithin. I've optimized this to remove this call to document, but I gained only 1s. I've done another minor optimization and found on my way that having private classes embedded in std::unique_ptr kills performance, but this will deserve a message on its own. Since the fastest code is the one we don't call, I've written a completely different way that doesn't call textRangesChangingWithin anymore. Much faster since I'm now down to 15s. All this is in my work/ducroquet/perfs-words branch. Feel free to have a look, I'll keep digging into this in the afternoon and the next days. signature.asc Description: This is a digitally signed message part.
Re: Words and large files
On Monday, March 22, 2021 9:01:21 AM CET Dag wrote: > Hi, opened the odf spec in words the other day. > This is a document with 800+ pages and a TOC of 60+ pages. > I did the same in LO to compare. > Don't take the absolute times too seriously as my box is well into its > teenage years. > But, I think comparison with LO says a lot: > > Open: 2,5 mins, LO: 40 secs. > Except that TOC page numers is not shown (just ###), navigation, scrolling > etc works fine. > Save: 4 mins, LO: 30 secs. > > And now to the bad part: > When a try to type a character words freezes for about 50 secs. > It seems the whole doc is re-layouted and also the TOC is updated (page > numbers appear). Another source of freeze that should not be underestimated is the collection of statistics. It's used both for the full stats dock widgets, and for the words/sentence count at the bottom. On my computer, it uses a full CPU for almost 1 second. Huge source of pain. I'll try to make it upgrade on the fly instead of calculating everything over and over. This should be much smoother. There is also a similar issue in the TOC generator. It reads the whole document each time it wants to generate, this seems suboptimal and is going to be barely usable on such a document. signature.asc Description: This is a digitally signed message part.
Re: Words and large files
On Monday, March 22, 2021 12:24:28 PM CEST Pierre wrote: > On Monday, March 22, 2021 9:01:21 AM CET Dag wrote: > > Hi, opened the odf spec in words the other day. > > This is a document with 800+ pages and a TOC of 60+ pages. > > I did the same in LO to compare. > > Don't take the absolute times too seriously as my box is well into its > > teenage years. > > But, I think comparison with LO says a lot: > > > > Open: 2,5 mins, LO: 40 secs. > > Except that TOC page numers is not shown (just ###), navigation, scrolling > > etc works fine. > > Save: 4 mins, LO: 30 secs. > > > > And now to the bad part: > > When a try to type a character words freezes for about 50 secs. > > It seems the whole doc is re-layouted and also the TOC is updated (page > > numbers appear). > > > > Then when auto-save kicks in words freezes again without any feedback. I > > expected to see a status meassage and a progress bar, but no. > > > > Krita solved freeze by making a copy of the doc and save in the > > background. > > > > LO is better (but not good). > > Generally you can type new text wo problems but it freezes for shorter > > periods (maybe when updating page numbers), and it freezes when > > auto-saving. > > > > It never updates the TOC, this needs to be done manually. > > > > Suggestions (just my 2 cents): > > 1) TOC should be updated manually to avoid re-layout. > > 2) Auto-save in the background. > > 3) Minimize re-layout by e.g. only re-layout dirty pages before and > > including the displayed page(s). > > Hi > > Thanks for bringing this topic back on the table, long time I did not try to > do that. On my computer, opening with LO takes 4s, 20s with words… so about > the same ratio as you have. > Since my last experiment in this topic, the performance analysis tooling has > improved so much that this will be a fun thing to do. I'll see what this > gives. > And I completely agree with at least parts 1 and 3 of your conclusion. Can > not tell for the second part, I must think a bit more about it. > > And I disagree with René's conclusions. Having performance issue today > doesn't mean we can not fix them. And unlike the webbrowser comparison, we > are not chasing a perpetually moving target with thousands of corporate > developers adding features on their engines while being 0.1 unpaid > developer on our engine… It's more like a few unpaid developers against > less unpaid developers. Still not the best position for us, but far more > manageable. > > Pierre Hi I've worked a lot on this topic in the past weeks. On my computer, loading this file is now down to 7s, vs 20s before. I'm sure there are other improvements to do. A big source of slowdown when loading this file is the 2799 bookmarks in the file. Our code was (almost) fine, but this is a nightmare regarding QTextDocument behaviours. For each bookmark, one QTextCursor is kept is KoTextRange, and QTextDocument::insert will go through each cursor to check if they need to be moved. This was accounting for about 20% of the load time on my computer… I have opened a bug report on Qt for that, QTBUG-92153, and I will try to write a patch. Until this is fixed in Qt (and it'll be some time before calligra uses the future Qt 6.x that will have the fix), I've a workaround in calligra which was important in beating the 10s milestone. I've seen other possibly nice performance improvements in lower-level areas. For instance, KoXmlNodeData::~KoXmlNodeData is taking more than 100ms… I'm sure there is some fun to do there playing with memory allocation heuristics and grouping them in a nice way. We could also revisit our compression algorithm choice, use more QStringView to reduce memory allocations… If anybody is interested… :) I will try to push readable and reviewable MR in the next week for all the changes I've done all over the place. Pierre signature.asc Description: This is a digitally signed message part.
Re: Krita donation proposal
On Tuesday, November 16, 2021 11:35:21 AM CET Halla Rempt wrote: > Hi, > > The KDE e.V. board still sits on this money, since there's almost nothing > happening in calligra land. Of everything that used to be Calligra, only > Plan and Krita show activity. Kexi also seems dormant. But the board needs > to spend that money, so what should we do? > > Not that I want to be greedy, but if Calligra cannot spend it on anything, > I'm find with taking a larger share for Krita... And is there a way to > spend it on Plan? > > Cheers, > > Halla Rempt Hi There have been discussions recently regarding these funds to use them to pay some developer time on calligra (code cleanup & fixes, upgrade to KF6/Qt6 in due time, new OpenDocument format supports…). These discussions happened in the past months, with the last email exchange being one or two weeks ago. The information I had was that these were 'marked bills', usable only for Calligra and not for Krita. If we can share, let's share, sure. Regards Pierre signature.asc Description: This is a digitally signed message part.
Re: Release
On Monday, December 13, 2021 8:28:44 AM CET Dag wrote: > @pierre: > If I'm not mistaken you are planning a new release soon? > I cannot see that you have created a release branch, so presumely string- > and feature freeze are in effect? > Do you have a target date in mind? > > Also I have created a few merge requests that you might want to get in. Hi I've looked a bit at the merge requests, thank you very much for these. The release will happen "soon", but I can't say when, my wife is now staying at the maternity ward so I can't really spend much time on anything yet (nor could I in the past weeks). signature.asc Description: This is a digitally signed message part.
Re: In Calligra Words switch to raster graphicssystem per default
On Tuesday 18 January 2011 09:36:52 Boudewijn Rempt wrote: > On Monday 17 January 2011, Sebastian Sauer wrote: > > Hi, > > > > please find attached a patch that makes sure Calligra Words uses the > > raster graphicssystem per default rather then the native one. This > > provides way better performance while dealing with documents compared to > > the native XRender backend cause of > > http://bugreports.qt.nokia.com/browse/QTBUG-16629 . > > > > What do you think? Good idea or to much of a hack? > > It's a hack, of course :-). I am wondering whether it's worth it to do this > all over KOffice -- and whether there's a way to actually measure the > improvement. > > Since raster is default on Windows (and maybe also OS X, though I thought > that Trolltech wanted to go with OpenGL there), it should be completely > safe. As far as I remember, Trolltech plan to switch to raster as default backend for Qt 4.8. So I agree with this plan. I'm only wondering about its effects on remote X connections. Of course, it's not that important for our use case (I mean, when I log on a remote computer, it's seldomly for word processing), but it may sometimes happen. signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 120250: Change blockLayout return to be more explicit
On Wednesday, September 17, 2014 08:09:24 PM Pierre Ducroquet wrote:
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120250/
> ---
>
> Review request for Calligra.
>
>
> Bugs: 306000
> http://bugs.kde.org/show_bug.cgi?id=306000
>
>
> Repository: calligra
>
>
> Description
> ---
>
> Returns an enum instead of a boolean and relying on an integer value aside.
> This allows the backtrack code to know that a layout ended because of a page
> break, and thus not follow the keep with next instead of ending up in an
> infinite loop.
>
> With that patch, we still have a difference between us and LibreOffice 4.3, a
> check of the OpenDocument specification will perhaps help : they decide to
> just skip the page break when it is in a keep with next block.
FYI, a patch implementing that way of layouting the text is much simpler :
index 3a1fa57..bd317b1 100644
--- a/libs/textlayout/KoTextLayoutArea.cpp
+++ b/libs/textlayout/KoTextLayoutArea.cpp
@@ -1226,10 +1226,12 @@ bool KoTextLayoutArea::layoutBlock(FrameIterator
*cursor)
c1.setPosition(c1.position() + 1, QTextCursor::KeepAnchor);
KoTextSoftPageBreak *softPageBreak =
dynamic_cast(d->documentLayout->inlineTextObjectManager()-
>inlineTextObject(c1));
-bool keepWithNext =
block.blockFormat().boolProperty(KoParagraphStyle::KeepWithNext);
-if (softPageBreak && !keepWithNext) {
-softBreakPos = pos;
-break;
+if (softPageBreak) {
+QTextBlock previousBlock = block.previous();
+if (!previousBlock.isValid() ||
!previousBlock.blockFormat().boolProperty(KoParagraphStyle::KeepWithNext)) {
+softBreakPos = pos;
+break;
+}
}
pos = text.indexOf(QChar::ObjectReplacementCharacter, pos + 1);
I'll try to dig up from OpenDocument specification a recommendation regarding
the proper way of handling that, if there is any.
signature.asc
Description: This is a digitally signed message part.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 120250: Change blockLayout return to be more explicit
On Wednesday, September 17, 2014 10:16:35 PM Pierre wrote:
> On Wednesday, September 17, 2014 08:09:24 PM Pierre Ducroquet wrote:
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://git.reviewboard.kde.org/r/120250/
> > ---
> >
> > Review request for Calligra.
> >
> >
> > Bugs: 306000
> >
> > http://bugs.kde.org/show_bug.cgi?id=306000
> >
> > Repository: calligra
> >
> >
> > Description
> > ---
> >
> > Returns an enum instead of a boolean and relying on an integer value aside.
> > This allows the backtrack code to know that a layout ended because of a page
> > break, and thus not follow the keep with next instead of ending up in an
> > infinite loop.
> >
> > With that patch, we still have a difference between us and LibreOffice 4.3,
> > a
> > check of the OpenDocument specification will perhaps help : they decide to
> > just skip the page break when it is in a keep with next block.
>
> FYI, a patch implementing that way of layouting the text is much simpler :
>
> index 3a1fa57..bd317b1 100644
> --- a/libs/textlayout/KoTextLayoutArea.cpp
> +++ b/libs/textlayout/KoTextLayoutArea.cpp
> @@ -1226,10 +1226,12 @@ bool KoTextLayoutArea::layoutBlock(FrameIterator
> *cursor)
> c1.setPosition(c1.position() + 1, QTextCursor::KeepAnchor);
>
> KoTextSoftPageBreak *softPageBreak =
> dynamic_cast(d->documentLayout->inlineTextObjectManager(
> )-
> >inlineTextObject(c1));
>
> -bool keepWithNext =
> block.blockFormat().boolProperty(KoParagraphStyle::KeepWithNext);
> -if (softPageBreak && !keepWithNext) {
> -softBreakPos = pos;
> -break;
> +if (softPageBreak) {
> +QTextBlock previousBlock = block.previous();
> +if (!previousBlock.isValid() ||
> !previousBlock.blockFormat().boolProperty(KoParagraphStyle::KeepWithNext)) {
> +softBreakPos = pos;
> +break;
> +}
> }
>
> pos = text.indexOf(QChar::ObjectReplacementCharacter, pos +
> 1);
>
>
> I'll try to dig up from OpenDocument specification a recommendation regarding
> the proper way of handling that, if there is any.
I found none neither in the 20.194 fo:keep-with-next section nor in the
text:soft-page-break section. I don't remember of any other section that may
contain that information, so I guess it's up to us to choose the way we want to
implement it… I suppose following the LibreOffice implementation will be better
from an interoperability point of view…
Can anyone check what decision microsoft took in office regarding that case ?
signature.asc
Description: This is a digitally signed message part.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 120250: Don't infinitely loop when backtracking keepWithNext with a page break
On Thursday, September 18, 2014 07:48:41 PM Camilla Boemann wrote: > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120250/#review66864 > --- > > Ship it! > > > Cool and a much simpler patch than I had feared - great work Thanks I guess it's safe to backport it to the 2.8 branch ? signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: 2.8.6 Changelog -- Reminder
On Tuesday, September 16, 2014 09:47:17 PM Jaroslaw Staniek wrote: > Hi everybody, > 2.8.6 release is appraching [1], it's time to collect changelog items. > I see a number of commits outside of kexi/ and krita/ .. any takers? > Earlier is better. Hi I think you can add a fix of a few crashes for words regarding the keepWithNext paragraphs. I found at least 3 bug reports on that closed by 4a6203319cba09dae354a6c58fd30aab70a7a5ee. How can I add that to the release notes ? signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: 2.8.6 Changelog -- Reminder
On Monday, September 22, 2014 09:46:44 PM Jaroslaw Staniek wrote: > Thanks, already added all items since 2.8.5. The one you mentioned is > added to a General section (since it's in the text layout lib) and > called: > > Prevent backtracking to undo the layout of a whole page, thus starting > an infinite loop. This can be triggered by a page break in the middle > of keepWithNext paragraphs. (bug 306000) > > Did I get it right? Yes you got it right, thanks signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: How to get all characters on a page in Words and their position
On Monday, September 29, 2014 11:22:48 PM Friedrich W. H. Kossebau wrote: > Hi, > > I would like to create a list of all characters (visible) on a given page and > their position relativ to that page's borders. > > How do I do that best? > > Background: > As you might have seen I have pulled Sven's ODT generator for Okular from an > attic branch and pushed it next to the ODP generator. Talked to the Okular > people at Akademy and they are quite happy about that, as it will, once > released, also meet some bigger request for support of DOC(X) in Okular. Most > features like navigation-by-toc already work, but at least one important thing > is still missing: > selection of text for copying. > > Due to Okular being started around PDFs this is done by an interface to the > generator which exports the text as described above, as a list of chars and > their position. So no native selection done by the generator, even if that > could provide better experience (surely someone is welcome to extend Okular to > also support native selection ;) ). See here for the API I need to support: > > http://api.kde.org/4.x-api/kdegraphics-apidocs/okular/html/classOkular_1_1Text > Page.html#a003032e4e1cd8c15f01ed639ce62d11f > > So I start from > KWPage page = pageManager->page(okularPage->number()+1); > and then how do I get all the text frames of that page and how do I best > calculate the distance of each char to the page borders? Hi Pages are sort of «pointers», empty shells. They are here to layout KoShape objects one after each other. So you have to get back to your shapeManager and use shapesAt(page->contentRect()). This will list you the shapes of the page, which you can then dynamically cast to TextShape objects, whose textShapeData contain a QTextDocument object. That should get you the text of a given page, as far as I remember. Regarding distance calculation, I don't really understand what you want to do. Do you want to be able to get, for any character, its position on the page ? Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Words - how to add a way for users to change page styles ?
Hi all Right now, words implement most features regarding page styles in ODF, but our user interface lacks far behind, allowing users to apply only one style to the whole document. This creates confusion and is a huge feature gap that require mostly user interface work. Creating such an interface is a complicated work, and I've never been satisfied by the LibreOffice nor MS-Word interfaces. I've just done a crude proof of concept in words showing how I think we could implement page styles. The crudeness makes the screen shots harder to understand, but I only want to show the «spirit» of the idea. Between each page, I add in the «empty» gray area the page style names. A double click on a page style name prompt you for the page style change (the hack implements this with a rude QInputDialog…), could offer you to introduce a page break… and you're done. This seems to me user friendlier than LibreOffice way of doing it (Insert > Manual Break, then choose to change the page style… and if you want to change a style afterwards, right click and get lost in paragraph properties) So attached to this mail is a simple screenshot of what this could look like… I won't share the hack code right now, it's broken and beyond redemption :) Thanks Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: 2.9 and 2.8.7
On Friday, November 07, 2014 11:57:45 PM Jaroslaw Staniek wrote: > That said, if we had to release 2.9 on time we would need beta soon. > So if 2.9 is delayed, 2.8.7 makes sense. Today I backported 6 fixes > from Kexi master to 2.8. > > I see Krita and others have no backported stuff. Is it planned? If we are certain we are going to make a 2.8.7 release, I'll backport a few words patches from master to 2.8. I just did not have enough time to backport them, if there is a delay of 2.9 then I'll just put the new stuff I'm working on aside and do the backports that make sense. signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 120733: Pass more data between layout and RootAreaProvider
On Saturday, December 06, 2014 07:11:04 PM Dan Leinir Turthra Jensen wrote: > This is, i know, somewhat late in the review phase, but i expect it's a > smallish issue anyway. In short, 4fa0b6e29d31d7755441b231ea3bf2ef068435b4 > breaks text input in Stage. Which i discovered while setting out to make a > presentation i've got to give on Monday ;) Fixed in commit bfac4d185e89ab78a8b98ef6a0a45a4d624dd182 I hope you'll have enough time for your presentation :) signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: calligra 2.9 Beta 1 changelog
On Monday, December 08, 2014 05:30:17 PM Cyrille Berger wrote: > Hi, > > If you can answer this email with a short list of what are the main > changes to your applications since 2.8. > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel Hi For words, one of the big changes that landed was some layouting rework that fixes a lot of small rendering glitches and is the first required step before we can handle more page layouting features and dynamically change pages layouts. So far it has no real user visible improvements (except old bugs replaced by new bugs) but that change had to be done first. I hope to have new features before the final release. Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: I'm back
On Tuesday, January 13, 2015 12:41:06 PM Inge Wallin wrote: > Hi everybody, > > Some of you know already that I have been very sick but perhaps not everybody. > However, I am much better now and recovery has gone so far that I feel that I > can come back into the KDE and Calligra families again and be active. The > most lasting difference between now and before is that I am ~20 kg lighter. > :) > > I have actually not been totally cut off, I have followed a bit on the web and > on mailing lists, but I have a pretty big backlog. I have started to cut that > down but it will take some time before I'm fully done with it. > > In the mean time I have been able to do some trivial hacking and actually have > a couple of branches on my hard drive. The question is whether it's too late > to merge them now before the big port to Qt5 and KF5. > > So consider me back with a vengeance and I am starting to feel really well > again. And I have missed KDE and Calligra a lot! > > -Inge Welcome back Inge, and take care of yourself ! signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: PDF-Import and/or PDF-Export
On Sunday 20 March 2011 09:06:31 Boudewijn Rempt wrote: > On Saturday 19 March 2011 Mar, Diego Turcios wrote: > > Hi I was looking at the KDE Wiki, and I have interest in the PDF-Import > > and/or PDF-Export project. > > I have some experience in QT c++. The project sounds interesting, I will > > like to know am little more about this project. > > I'm not totally sure which wiki page you were looking at :-). I guess > http://community.kde.org/GSoC/2011/Ideas#Project:_PDF-Import_and.2For_PDF- > Export, right? > > Sebastian Sauer is on holiday right now, but the description has most of > the basics. You need to investigate the poppler library to start with. The > idea is to be able to load PDF documents as editable text. Years ago, > KWord had this ability through using xpdf directly > (http://websvn.kde.org/branches/koffice/1.6/koffice/filters/kword/pdf/). > However, xpdf causes a steady stream of security issues, so it's necesary > to use a real library for that, poppler. I'm not sure myself how I would > go about it, but I would start browsing the old code and the poppler api > documentation (http://people.freedesktop.org/~aacid/docs/qt4/). Focus on > the import part first: right now our pdf export is not great, but it > works. Hi I had to parse PDF files for the OpenstreetMap project in france (data could be extracted from PDF generated from the cadastre) I don't know how you plan to use poppler, but for this case, I could not extract any useful information from its datastructures. I instead had to use libpodofo. I don't think you can use poppler for Calligra needs (except if you implement a new poppler backend), but I'd be happy to be proven wrong... Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: GSoC 2011
On Sunday 20 March 2011 10:24:48 Jain Basil Aliyas wrote:
> Hi,
>
> On Sun, Mar 20, 2011 at 2:04 PM, Boudewijn Rempt wrote:
> > On Sunday 20 March 2011 Mar, Pierre Stirnweiss wrote:
> > > Just something to keep in mind:
> > > on windows MSVC, libpoppler is a static library ("because poppler does
> >
> > not
> >
> > > have import/export thing for the core(private) api" dixit pinotree).
> > > Libpoppler is not meant to be used directly. For the karbon pdf filter
> >
> > this
> >
> > > is however what we do. This means that:
> > > -either we disable the filter on windows MSVC
> > > -or we link the filter to every library libpoppler was linked to. these
> > > should be exactly the same ones. that solution is not very practical to
> > > implement.
> > >
> > > So if during the course of refactoring, this could be avoided/fixed,
> > > all
> >
> > the
> >
> > > better.
> >
> > Yes, the words pdf import/export plugin should only use poppler-qt4 which
> > is a proper shared library.
>
> Okay, I will try to work on poppler-qt4 and investigate its capabilities!
>
> > If that doesn't provide enough capabilities, we will probably need to
> > work together with the poppler guys to improve that situation :-).
>
> Scribus uses podofo library <http://podofo.sourceforge.net/about.html> for
> working with PDF. Should I do a comparison study to find out which one will
> suite more for this work?
Huge warning about podofo : they have no binary/source compatibility guarantee.
It could be complicated to maintain a filter using podofo, except if they
improve this.
And even between minor releases, things could break.
For instance : their GetObjectLength got a new mandatory parameter in 0.8.3,
hence this kind of code :
#if (PODOFO_VERSION_MAJOR > 0) || (PODOFO_VERSION_MINOR > 8) ||
(PODOFO_VERSION_PATCH >= 3)
if (obj->HasStream() && (obj-
>GetObjectLength(PoDoFo::ePdfWriteMode_Compact) > 1)) {
#else
if (obj->HasStream() && (obj->GetObjectLength() > 1)) {
#endif
signature.asc
Description: This is a digitally signed message part.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: PDF-Import and/or PDF-Export
On Sunday 20 March 2011 13:25:34 C. Boemann wrote: > On Sunday 20 March 2011 13:18:28 Pierre wrote: > > On Sunday 20 March 2011 09:06:31 Boudewijn Rempt wrote: > > > On Saturday 19 March 2011 Mar, Diego Turcios wrote: > > > > Hi I was looking at the KDE Wiki, and I have interest in the > > > > PDF-Import and/or PDF-Export project. > > > > I have some experience in QT c++. The project sounds interesting, I > > > > will like to know am little more about this project. > > > > > > I'm not totally sure which wiki page you were looking at :-). I guess > > > http://community.kde.org/GSoC/2011/Ideas#Project:_PDF-Import_and.2For_P > > > DF - Export, right? > > > > > > Sebastian Sauer is on holiday right now, but the description has most > > > of the basics. You need to investigate the poppler library to start > > > with. The idea is to be able to load PDF documents as editable text. > > > Years ago, KWord had this ability through using xpdf directly > > > (http://websvn.kde.org/branches/koffice/1.6/koffice/filters/kword/pdf/) > > > . However, xpdf causes a steady stream of security issues, so it's > > > necesary to use a real library for that, poppler. I'm not sure myself > > > how I would go about it, but I would start browsing the old code and > > > the poppler api documentation > > > (http://people.freedesktop.org/~aacid/docs/qt4/). Focus on the import > > > part first: right now our pdf export is not great, but it works. > > > > Hi > > > > I had to parse PDF files for the OpenstreetMap project in france (data > > could be extracted from PDF generated from the cadastre) > > I don't know how you plan to use poppler, but for this case, I could not > > extract any useful information from its datastructures. I instead had to > > use libpodofo. I don't think you can use poppler for Calligra needs > > (except if you implement a new poppler backend), but I'd be happy to be > > proven wrong... > > > > Pierre > > Also libpodofo seems the only one remotely capable of generating > colormanaged pdf, which at least Krita might like FYI, podofo gives you the code for PDF vector graphics. depending on your needs, it can be great or terrible :) That "code" is well documented in the PDF specification. It uses a RPN-like notation. You push each token on a stack, when facing an operand you pop tokens, and you are done. It translates really easily to QPainter (circa 3/5 lines per token I'm really using)... signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Sprint Hotel booking
On Tuesday 29 March 2011 18:43:39 Thorsten Zachmann wrote: > Hello, > > as there has been some changes to the hotel bookings here is the final list > that I have at the moment: > > I hope it is ok that Benjamin uses the bed of Pierre Ducroquet from friday > to saturday. Please let me know as soon as possible if there are problems > with that or if it is fine. Hi I'm perfectly fine with that. The only problem I have is with the food accommodation : could you please ask the hotel whether they can provide gluten-free breakfast ? Else, I'll have to bring my own food... Thanks Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Sprint programme
On Thursday 31 March 2011 14:51:23 Cyrille Berger Skott wrote: > Hi, > > After reading [1], I have noticed we have a good list of user interfaces > topics, so I have divided both items into two sections, "general" and "user > interface". > > My suggestion for the programme is: > > Saturday, common session (if we managed to all fit in a single room...) > It would go like this: > 9:00 warming up, detailing the programme, decide what is common and what > should be in BoF > 9:15 general sessions part I > 10:30 break > 10:45 general sessions part II > 12:15 lunch > 13:30 user interface part I (I would suggest to start by having a few > person explain their vision for the different user interfaces, that would > serve as a basis for further discussion on how to implement the vision, > /me looks at Inge and Jaroslaw) > 15:00 break > 15:30 user interface part II > 17:00 evening relaxation and eating > > Sunday, "left-over" and BoF (left-over would be items of the common session > that we have not managed to finish). And we restart around 9:30. > > I also remind people that have added item, to be prepare to annimate > discussions around their items :) > > [1] http://community.kde.org/Calligra/Meetings/Begin_2011_meeting/Ideas Hi Based on my memories of the Berlin public transportation system, I'll probably arrive around 9:30 at Möckernbrücke U-Bahn station... (Arrival at Berlin Spandau at 8:51... If I'm lucky enough, I can perhaps make it for the 9:15... Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
OpenDocument specification meets unit test…
Hi
The problem is simple :
1) Writing unit test is boring
2) We do not have enough test of our style support
3) Writing unit test doesn't make you look great
4) Our current testing for OpenDocument support is quite poor
5) Unit tests aren't fancy
6) It's hard to have complete unit tests for something like OpenDocument.
So instead of writing unit tests, I decide to have something write them for me.
Since slavery isn't allowed in most countries, that is not a valid solution.
Hence the solution I thought about : parse the OpenDocument scheme (available
as
RelaxNG), extract from it each possible style attribute, and dynamically
generate and save style elements and see if they are loading and saving the
right way.
During my travel tonight, I started sketching on my netbook a basic parser for
Relax NG (using Python) and writing some stuff…
I just finished implementing the first version, using C++ of course (I don't
want to bring yet another complicated beast in Calligra).
So far, it works perfectly on KoTableColumnStyle (which means it complains
quite
a lot with the current implementation…)
Here is the code specific to table column in my unit test :
void TestOpenDocumentStyle::testTableColumnStyle_data()
{
QList attributes = listAttributesFromRNGName
("style-table-column-properties-attlist");
QTest::addColumn("attribute");
QTest::addColumn("value");
foreach (Attribute *attribute, attributes) {
foreach (QString value, attribute->listValues()) {
QTest::newRow(attribute->name().toLatin1()) << attribute << value;
}
}
}
void TestOpenDocumentStyle::testTableColumnStyle()
{
QFETCH(Attribute*, attribute);
QFETCH(QString, value);
basicTestFunction(KoGenStyle::TableColumnStyle,
"table-column",
attribute,
value);
}
And that's all. Every thing else (generating the style, testing it, parsing the
RNG mess…) is generic. If the parser was a bit better, I could easily add
support for other styles with just a few lines of code.
To make things more clear : this does not replace any current unit test. This
does not control the document parsing.
I'm gonna commit this to master after I merge my words table style branch (it's
fully functionnal, but still not complete, and I am tired of not being able to
track my progress).
Pierre
signature.asc
Description: This is a digitally signed message part.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Progress on OOo GDI Metafile
Hi Since a long time, people have been complaining about the OpenOffice GDI Metafile picture format being undocumented, hence impossible to implement. In the plane sunday, I decided to just jump in the OpenOffice.org code and write both a documentation and a pure Qt implementation of that format. Now, I understand why nobody did that. Attached to this mail is the first screenshot... Yes, choosing to display such a cross is perhaps a wrong idea... What do you think is best to add support for svm in Calligra ? Adding a QImageIOPlugin ? Or should I convert it to svg to be able to manipulate the vector elements ? Pierre <> signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Progress on OOo GDI Metafile
On Wednesday 06 April 2011 11:24:26 Cyrille Berger Skott wrote: > On Wednesday 06 April 2011, Jaroslaw Staniek wrote: > > But we can't we use QSvgGenerator to get option of conversion to svg? > > Well that was what I was thinking. If it is possible to generate a svg out > of the svm, then you can write a QImageIOPlugin using QSvg module. So my > suggestion would be, either: Yes, using QSvgGenerator, that's planned... But I must get a fully operationnal parser first... > * to create a library that transform it to SVG > * or a library that takes a QPainter, and then you can paint directly to an > image, widgets, QGraphicsItem, flake shape or to SVG. Yeah, I'm just wondering what's the best way to integrate that with Calligra ? signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Progress on OOo GDI Metafile
Hi Progress again tonight : text support, some colors, polygons, translucency, and rectangles... I start getting used to this, next step will probably be to factorize/simplify/clean the code, plus write a clean documentation... Pierre <> signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Progress on OOo GDI Metafile
On Thursday 07 April 2011 16:03:22 Inge Wallin wrote: > On Wednesday, April 06, 2011 01:12:51 Pierre wrote: > > Hi > > > > Since a long time, people have been complaining about the OpenOffice GDI > > Metafile picture format being undocumented, hence impossible to > > implement. In the plane sunday, I decided to just jump in the > > OpenOffice.org code and write both a documentation and a pure Qt > > implementation of that format. Now, I understand why nobody did that. > > > > Attached to this mail is the first screenshot... Yes, choosing to display > > such a cross is perhaps a wrong idea... > > > > What do you think is best to add support for svm in Calligra ? Adding a > > QImageIOPlugin ? Or should I convert it to svg to be able to manipulate > > the vector elements ? > > > > Pierre > > Good that you are documenting the format! It has been long needed. > > I think the only viable way would be to add a libgdi (I thought it was > called SVM - StarView Metafile) under the vectorshape and show it there. > That should be the simplest and most logical place. Well, the name in OOo is «GDI Metafile» or «StarView Metafile». So I don't know the official name... Anyway, wait until my parser is a bit more functionnal and proper state :) signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Progress on OOo GDI Metafile
Hi I could not spend a night with no progress on this :) Here is a first specification draft. Are you okay with that formatting/presentation, or do you think something more formal is needed ? Global file structure = The byte order of the file is Little Endian. The SVM file is composed of two parts : the header, followed by a list of actions. Each of these contain objects, referenced in the last section of this document. * Header - Signature, 6 bytes, equals to "VCLMTF" (without quotes) - VersionCompat object - compression mode, uint32 - MapMode object - width, uint32 - height, uint32 - action count, uint32 * List of actions Each action starts with a type index, on uint16, identifying it. The following data depends on that type. Actions === LibreOffice 3.3 implements about 52 different actions. I will describe here only the ones I saw in my documents. In almost every case (except the null action), an action starts with a VersionCompat object, which I will name actionCompat in the following text. Unless mentionned otherwise, each Action starts with such an object. - Action 103 : draw rectangle This action draws a rectangle of the given coordinates using the current paint context. It contains the following objects : - topLeft Point - bottomRight Point Objects === - VersionCompat A VersionCompat object contains two integers : - version, uint16 - size (in bytes), uint32 The total size refers to the «current context». For instance, the VersionCompat at the beginning of an action will refer to the size of the action. - Point A point contains two integers : - x, uint32 - y, uint32 - Polygon signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Text saving broken
On Thursday 14 April 2011 10:20:23 Thorsten Zachmann wrote: > Hello, > > when I wanted to test some stuff I found out that saving of text is > currently broken. > > At the moment we save text like that: > > svg:width="300.000pt" svg:height="200.000pt" > svg:x="108.74767855096pt" svg:y="113.47540983607pt"> > This is a > text > > > This is wrong as it should look like > > svg:width="391.41463414634pt" svg:height="239.36675700090pt" > svg:x="102.82926829268pt" svg:y="226.19060523939pt"> > > This is a > text > > > > We now miss the tag. > > The change causing that is at least after commit > 0e18ccbabb634a4769434452a960870549373691 > > which still works without problems. > > Would be nice if someone who had been working on text saving could have a > look at that. Fixed, was an unhappy consequence of the change tracking work. @Ganesh : I don't know the change tracking specification, but I really don't like the way the code had to be modified to support it. Is there no way to have it in a less mixed-in way ? I mean, right now, you can't tell between the classical text related calls and the calls for change tracking. It was already messy and dirty enough... Moreover, do unit tests only cover the case where change tracking is enabled ? In any case, there is a real issue since the regressions I fixed here are major and should have been spotted far sooner... (I'll try to find some ways to improve our unit testing in that area anyway). But, for instance, you often check a save format, between deltaxml and odf 1.2 : what are the differences ? Why are both needed ? If you don't mind, a short explanation email would be helpful (or an IRC session if you prefer...) Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Request for a mentor
On Friday 20 May 2011 20:47:24 Brijesh Patel wrote: > Hi, > I want to work on some project in Calligra as part of my season of > kde project.can some one give me an oppurtunity to work on some project > under his mentorship.I would like to work in any project in Calligra > Words.I have already talked with Casper Boemann but since he is busy would > someone else willing to mentor me.I know basics in qt and c++.I am > exploring more and more about it and also will start soon reading the code > base of Calligra Words. > > Thanks, > Brijesh Patel > IRC nick : erione Hi I'm not available as much as I want to be, but I may be able to help you... What is your project exactly ? Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Fwd: [calligra] libs/kotext/styles: Use QTextLength for paragraph margins
Hi Because of the following commit, regressions may happen in text layout. I did the needed changes to keep everything compiling, I did fixes in libs/textlayout to make sure it uses the proper values (btw, using QTextFormat is not enough, it's much better to just use "our" classes like KoParagraphStyle since they allow us much greater flexibility) If you spot any regression I missed, please report it as soon as possible. Thanks Pierre -- Forwarded Message -- Subject: [calligra] libs/kotext/styles: Use QTextLength for paragraph margins Date: Thursday 02 June 2011, 17:35:15 From: Pierre Ducroquet To: kde-comm...@kde.org Git commit c3447834635766efcf4108621618b1a97636c54d by Pierre Ducroquet. Committed on 02/06/2011 at 17:05. Pushed by ducroquet into branch 'master'. Use QTextLength for paragraph margins M +36 -23 libs/kotext/styles/KoParagraphStyle.cpp M +10 -9libs/kotext/styles/KoParagraphStyle.h --- signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Fwd: [calligra] libs/kotext/styles: Use QTextLength for paragraph margins
On Friday 03 June 2011 15:00:41 Cyrille Berger Skott wrote: > Hi, Hi Thanks for your report. > > I think it is causing failures in TestBlockLayout and TestStyles: > > TestBlockLayout: > http://my.cdash.org/testDetails.php?test=6288300&build=194054 Hum, fixed part one, I'm not sure about the second part... I suppose it wasn't failing previously ? > TestStyles: > http://my.cdash.org/testDetails.php?test=6280021&build=194054 Fixed. signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Fwd: [calligra] libs/kotext/styles: Use QTextLength for paragraph margins
On Friday 03 June 2011 22:54:02 Cyrille Berger Skott wrote: > On Friday 03 June 2011, Pierre wrote: > > > TestBlockLayout: > > > http://my.cdash.org/testDetails.php?test=6288300&build=194054 > > > > Hum, fixed part one, I'm not sure about the second part... > > I suppose it wasn't failing previously > > It was working before. Is the test passing for you ? Now it is with my last fix... signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Update from the ODF TC
On Monday 06 June 2011 16:45:33 Jos van den Oever wrote: > Hello Calligra-ers, > > As you may or may not know, I represent KDE in the committee that specifies > the OpenDocument Format. We have a weekly telephone call for the core TC > in which I and Thorsten Zachmann participate. In addition there is a > weekly call for the work group on change tracking and a biweekly call on > interoperablility. > > This is the overview page: > http://www.oasis-open.org/committees/office/ > Apart from telephone discussions topics are discussed on the mailing lists > http://lists.oasis-open.org/archives/office/ > Proposals for the specification are recorded and discussed here: > http://tools.oasis-open.org/issues/browse/OFFICE > > ODF 1.2 is mostly done and will become a standard in the near future. This > means we want people to suggest new ideas, improvements and enhancements to > put in the next ODF standard. If there are things you would like to see > changed in ODF now is the time to speak up. As TC contact, Thorsten and I > can put your proposals in the 'specification changes' system, but everyone > can also mail the public list: > http://lists.oasis-open.org/archives/office-comment/ > > I would like first to let people in Calligra brainstorm about what is > feasible and desirable. Ideas can be put as a reply to this mail. Changes > do not have to be features, they can also be clarifications or > simplifications. > > Best regards, > Jos Hello Well, I've got a lot of things to suggest :) 1) defaults That's a simple one : what is the default value of each attribute ? For some of them, that's obvious, of course (underline default to none). But... what about font size for instance ? I could go on and on, just listing attributes and determining arbitrary default values. 2) stricter RNG schema There are several attributes in the RNG schema that are described as a string, for instance some border or shadow attributes... That's making it impossible to check for strict document compliance. 3) increase the OpenDocument covered features/standardize more things There is a fallback mechanism to use pictures to replace unsupported elements. Good. The picture format is not defined. Bad. That's making the fallback mechanism just useless... It allows LibreOffice to insert SVM files as fallback... More complex one : macros. I understand macros language represent more or less the internals of the Office suite behind. But would it be possible to share a common, simple macro language with LibreOffice/OpenOffice.org, that would be standardised in OpenDocument ? It could be based on ECMA 262 (JavaScript the 5th), have a minimal API... A bit like DOM is standardised in the browser... Ok, that's insane, but... why not ? Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Using ODF Relax NG schema to generate easier XML writing classes
On Friday 10 June 2011 08:22:04 Jos van den Oever wrote:
> Here is an idea to improve code quality in Calligra.
>
> Currently, we use KoXmlWriter to write ODF XML. For this, functions like
> startElement, endElement, addAttribute are used.
>
> By using the Relax NG schema, we could generate a wrapper around this class
> which would give us functions like
>
> TextPWriter TextContentWriter::startTextP();
> void TextHWriter::writeTextOutlineLevel(quint32 level);
>
> that would wrap around KoXmlWriter or QXmlStreamWriter:
>
> class TextHWriter {
> friend class TextContentWriter;
> private:
> KoXmlWriter* const xml;
> protected:
> TextHWriter(KoXmlWriter* xml_) :xml(xml_) {
> xml->startElement("text:h");
> }
> public:
> ~TextHWriter() { xml->endElement(); }
> TextSpan startTextSpan() { return TextSpanWriter(xml); }
> void writeTextOutlineLevel(quint32 level) {
> xml->setAttribute("text:outline-level", level);
> }
> };
>
> These writer classes would all go in header files only and should not
> affect the compiled form; the functions are so simple and that they should
> all be compiled away.
> The classes would provide compile time checking of the code that writes
> XML. It would be easier for people to write code to write XML and it would
> be harder to make mistakes. When writing serialization code, one would not
> need to look up the what attributes can go in which element and what type
> they have; your development enviroment would tell you with autocompletion.
>
> Can you think of a reason why this would not work?
>
> Cheers,
> Jos
Hi
That is a really interesting solution. The biggest trick would be not to forget
to delete the objects at the right time if the endElement stays in the
destructor.
But I'm not sure how it would interact with the change tracking code, unless
you
can integrate change tracking in these classes, then it's just great...
Pierre
signature.asc
Description: This is a digitally signed message part.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Using ODF Relax NG schema to generate easier XML writing classes
On Friday 10 June 2011 12:49:18 Jos van den Oever wrote: > On Friday, June 10, 2011 08:22:04 AM Jos van den Oever wrote: > > Can you think of a reason why this would not work? > > I can now. The circular nature of element nesting make is harder to create > these classes. E.g. office:document can have (at some depth) a > "office:image" which can have an "office:document" inside. > > Who can think of an elegant solution for this? > > Find my first attempt attached. > > Cheers, > Jos I can't see that as a problem, with a good class definition... What is the problem exactly ? signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Using ODF Relax NG schema to generate easier XML writing classes
On Friday 10 June 2011 08:56:06 Jos van den Oever wrote: > On Friday, June 10, 2011 08:43:58 AM Pierre wrote: > > That is a really interesting solution. The biggest trick would be not to > > forget to delete the objects at the right time if the endElement stays in > > the destructor. > > But I'm not sure how it would interact with the change tracking code, > > unless you can integrate change tracking in these classes, then it's just > > great... > > The change tracking is a touch nut to crack indeed. I cannot oversee the > implications there. In my opinion, change tracking logic should be separate > from normal serialization. TC code would need to write fragments. So the > change tracking writer can also be a friend of the classes it needs to > write. > > Would that be enough or are there more problems? Can you give an example? > > Cheers, > Jos I'm sorry I don't know the change tracking enough to provide illustrations. At least in Kotext, it is quite complicated, far from separate from normal serialization. Looking at the code is hardly enough to understand what is change related and what is not... Also, another question about your proposal : would it be strict regarding the content types ? I mean : a positiveInteger attribute for a given node must remain a positiveInteger, and that could even be checked at compilation time... signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Using ODF Relax NG schema to generate easier XML writing classes
On Friday 10 June 2011 20:28:55 Jos van den Oever wrote:
> On Friday, June 10, 2011 20:24:08 PM Pierre wrote:
> > On Friday 10 June 2011 12:49:18 Jos van den Oever wrote:
> > > On Friday, June 10, 2011 08:22:04 AM Jos van den Oever wrote:
> > > > Can you think of a reason why this would not work?
> > >
> > > I can now. The circular nature of element nesting make is harder to
> > > create these classes. E.g. office:document can have (at some depth) a
> > > "office:image" which can have an "office:document" inside.
> > >
> > > Who can think of an elegant solution for this?
> > >
> > > Find my first attempt attached.
> > >
> > > Cheers,
> > > Jos
> >
> > I can't see that as a problem, with a good class definition...
> > What is the problem exactly ?
>
> I had code like this:
>
> class B;
> public:
> class A {
> B startB();
> };
>
> class B {
> public:
> A startA();
> };
>
> which is not possible. I changed it now to
>
> class B;
> class A {
> public:
> A(const B&);
> };
> class B {
> B(const A&);
> };
>
> which does work. The current header file is nearly a megabyte, but compiles
> down to nearly no code if you do not use much, in my current version which
> adds 'inline' to each function.
>
> Cheers,
> Jos
Yeah, so that problem is nearly void now
BTW, what RNG parser do you use to generate this .h file ?
So far, we have a terrible one in a test case (yeah, I write ugly code
sometimes, sorry about that, but this one was gonnabe too complex otherwise...)
Thanks
Pierre
signature.asc
Description: This is a digitally signed message part.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Cleaning your remote branch list
On Wednesday 29 June 2011 10:39:25 Cyrille Berger Skott wrote: > Hi, > > We just realized that git does not auto-clean the list of remote branches > from your local clone. To do that, the best is to run "git remote prune > origin", so that the list of branches only contains the active one. > > We do have a lot of branches, don't forget to tell Boudewijn or me when you > are finished with a branch so that we kill it from the server. Hi I'm done using the words-save-table-style branch, it can be removed too... Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: [calligra] libs/kotext/styles: Fix saving line-height to ODF. Just because the property exists doesn't mean it's valid.
On Friday 08 July 2011 18:51:17 Sebastian Sauer wrote:
> Git commit 9f017cf21d343c1408214499bd878b987d8daf6f by Sebastian Sauer.
> Committed on 08/07/2011 at 18:43.
> Pushed by sebsauer into branch 'master'.
>
> Fix saving line-height to ODF. Just because the property exists doesn't
> mean it's valid.
>
> M +3-3libs/kotext/styles/KoParagraphStyle.cpp
>
> http://commits.kde.org/calligra/9f017cf21d343c1408214499bd878b987d8daf6f
>
> diff --git a/libs/kotext/styles/KoParagraphStyle.cpp
> b/libs/kotext/styles/KoParagraphStyle.cpp index ac5d1d5..987b2bd 100644
> --- a/libs/kotext/styles/KoParagraphStyle.cpp
> +++ b/libs/kotext/styles/KoParagraphStyle.cpp
> @@ -283,7 +283,7 @@ void KoParagraphStyle::unapplyStyle(QTextBlock &block)
> const void KoParagraphStyle::setLineHeightPercent(int lineHeight)
> {
> setProperty(PercentLineHeight, lineHeight);
> -setProperty(FixedLineHeight, 0);
> +setProperty(FixedLineHeight, 0.0);
> remove(NormalLineHeight);
> }
>
> @@ -1946,10 +1946,10 @@ void KoParagraphStyle::saveOdf(KoGenStyle &style,
> KoGenStyles &mainStyles) } else if (key == KoParagraphStyle::LineSpacing
> && lineSpacing() != 0) { style.addPropertyPt("style:line-spacing",
> lineSpacing(), KoGenStyle::ParagraphType); writtenLineSpacing = true;
> -} else if (key == KoParagraphStyle::PercentLineHeight) {
> +} else if (key == KoParagraphStyle::PercentLineHeight &&
> lineHeightPercent() != 0) { style.addProperty("fo:line-height",
> QString("%1%").arg(lineHeightPercent()), KoGenStyle::ParagraphType);
> writtenLineSpacing = true;
> -} else if (key == KoParagraphStyle::FixedLineHeight &&
> lineHeightAbsolute() >= 0) { +} else if (key ==
> KoParagraphStyle::FixedLineHeight && lineHeightAbsolute() != 0) {
> style.addPropertyPt("fo:line-height", lineHeightAbsolute(),
> KoGenStyle::ParagraphType); writtenLineSpacing = true;
> } else if (key == KoParagraphStyle::LineSpacingFromFont &&
> lineHeightAbsolute() == 0) {
I don't disagree with the idea of this change, but this is not really a bug in
calligra itself.
I will fix the unit test you broke, by adding a specific exception for this
property. But the following code in OpenDocument relax ng is wrong :
normal
Since nonNegativeLength can be zero, it means that 0 is a valid line-height...
Still, the specification doesn't tell us what it means.
signature.asc
Description: This is a digitally signed message part.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: [calligra] libs/kotext/styles: Fix saving line-height to ODF. Just because the property exists doesn't mean it's valid.
On Tuesday 12 July 2011 14:17:12 Sebastian Sauer wrote: > Pierre wrote: > > On Friday 08 July 2011 18:51:17 Sebastian Sauer wrote: > >> Git commit 9f017cf21d343c1408214499bd878b987d8daf6f by Sebastian Sauer. > >> Committed on 08/07/2011 at 18:43. > >> Pushed by sebsauer into branch 'master'. > >> > >> Fix saving line-height to ODF. Just because the property exists doesn't > >> mean it's valid. > >> > >> M +3-3libs/kotext/styles/KoParagraphStyle.cpp > >> > >> http://commits.kde.org/calligra/9f017cf21d343c1408214499bd878b987d8daf6f > > [...] > > > I don't disagree with the idea of this change, but this is not really a > > bug in calligra itself. > > > > I will fix the unit test you broke, by adding a specific exception for > > this property. But the following code in OpenDocument relax ng is wrong : > > > > > > > > normal > > > > > > > > > > > > Since nonNegativeLength can be zero, it means that 0 is a valid > > line-height... Still, the specification doesn't tell us what it means. > > First the fix above makes sure we do NOT save ALWAYS as percent. Second it > makes sure all out code is consistent. Layouting and Words ALL do expect > !=0 (please grep yourself). > > That the specs are using nonNegativeLength does NOT mean that zero is > included. The specs are NOT that clever. The only way to check what ranges > are allowed and/or processed, what happens with invalid ranges, what are > the default values, etc. pp. is trying MSO and OO.org and looking at there > source- code (OO since MSO doesn't have that possibility). That's what I > did. The allowed minimum value is 0.02" what is btw EXACTLY what I wrote > down last year as comment and which was ignored by those who broke that > logic again. Please see in KoParagraphStyle.cpp line 1247 which says; > > // fixed value is between 0.0201in and 3.9402in > > You will not find that in the specs or in the schema. The specs and the > schema do NOT handle ranges, default values, exceptions, corrections, etc. > pp. You can also try yourself loading ODT's with different values into > OO.org (I btw did that last year and added the comment at line 1247 for > that and already fixed it before but seems someone keeps to break it). > > Now I like to know what unittest I broke? Hi Your mail sound angry, I don't see how I could offend you, so if I did offend you, I'm really sorry and be sure it wasn't meant to. When I said the spec is buggy, it *really* is. It is not smart enough to include ranges, that's one issue, but it is smart enough to say that a length of zero is allowed or not, and in line-height case, it is allowed since nonNegativeLength means >= 0, that's the difference with positiveLength which means > 0. The unit test that broke is the automatic OpenDocument test (TestOpenDocumentStyle). You didn't see the breakage since there are many other broken cases to fix, you would have to run the test manually to see it. I'll work around by faking the references and using positiveLength instead of nonNegativeLength here, but this really should be fixed in the specification, and I'll report that. Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Regressions || Huston we have a problem
On Friday 15 July 2011 12:30:01 Sebastian Sauer wrote: > Aloha, > > yesterday at the ODF plugfest 2011 ( > http://www.opendocsociety.org/news/2011- berlin-plugfest/ ) we had two > interoperability tests and failed on both of them. It seems both where > working at some point but cause of regressions didn't any longer at the > event. That is a problem. > > Let me add that the problem are NOT the regressions. That can happen. The > problem is that we did not discover them for more then a month till that > event. > > So, the question is how to improve that situation to make sure we are able > to discover regressions faster? > > I see two ways; > 1. unittests also for saving. > 2. cstester roundtrips. > > The first would be optimal but it would need *lot* of time especially if we > try to get a good coverage done. > > The second is the fastest way (I can think of atm). We could first fix > cstester so document-roundtrips are proper working and second move that to > a server that runs cstester against the large collection of documents > located on the KDE-svn server in the kofficetests directory. Maybe we can > run that once a day in an automated way and then incoperate that into our > IRC unittest-bot? Or maybe we can provide a webpage that shows in which > ways what documents changed from one day to the other? > > What do you think? Is there maybe a better way? Maybe even an easier way? > Or? Hi Really bad news indeed. What kind of regressions are we looking at ? Is it "global" regressions, affecting for instance the whole document content, or just "macro" regressions like a property not being saved properly anymore ? IMHO, both should be covered by different unit tests for better efficiency... signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request: Refactor kotext/KoTableCellStyle
For the record : 1) since these changes imply a lot of tiny changes spread accross kotext/textlayout plus a few tiny extra places, I prefer splitting it in several parts, hence this first step that only provides cleanups and almost get rid of KoTableBorderStyle… 2) the final aim is to be able to implement proper saving support for borders by just reusing the KoBorder code that works… Later, other classes like KoParagraphStyle shall be converted to using KoBorder too… ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Plugfest!
On Thursday, September 01, 2011 12:27:09 PM Boudewijn Rempt wrote: > Hi! > > The seventh plugfest will be in Gouda, the Netherlands, November 17/18 > (http://www.opendocsociety.org/news/gouda-odf-plugfest/) . By then, > Calligra should be in a good shape to compete again -- we're tagging our > release candidate the 18th, if everything goes according to plan! > > Michiel tells me this plugfest will be a bit bigger than normal, with many > big players in the Netherlands visiting to see the progress everyone's > made, as well as lots of people from Abiword. It would be great to have a > good representation from Calligra there as well :-) > > If you want to attend, please go to > > http://community.kde.org/Calligra/Meetings/Gouda_Plugfest > > And add your name. If you need travel sponsorship, please note it down and > I will try to get you sponsored one way or another. > > Plugfests are great fun, so don't hesitate! Hi My ability to go there depends on the calligra sprint dates… (I may have to choose between them, depending on the dates and my vacation days left) But I really want to go, so… We'll see :) Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Brainstorming about textshape/textlayout/kotext structure
On Monday, November 07, 2011 09:21:07 AM Pierre Stirnweiss wrote: > At the sprint, I'll be animating a brainstorming session about the > structure of the text handling in calligra. This is about the structure we > want to have for the current textshape/textlayout/kotext triplet. > So I can organise a bit myself, and also for everyone to have a clear > picture of who is interested/will participate, can the people who want to > attend please make themselves known. > Ideally there should be between 5 and 7 people (excluding myself). We > should have the core words developers for sure. I'd also like to have some > non words consumers of our text API (calligra active comes to my mind as > very relevant). Also, I'd like one or two non user of our API, who still > have some knowledge of it but who can then provide a distanced point of > view. > I hope we can pull Seb in with skype. > > Also for organisation of this: will there be an availability of post-its > and A4 paper in quantity? if not, i'd need to find a place where i can buy > this (i don't need the extra weight in the plane). > > Pierre Count me in… Pierre signature.asc Description: This is a digitally signed message part. ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Unit test coverage
I have never really looked deep into how unit tests are set. Is there somewhere something I can read to give me more insight into this. For example, how is the coverage of a file calculated? Pierre On Sun, Dec 12, 2010 at 10:43 AM, Cyrille Berger Skott wrote: > On Sunday 12 December 2010, Cyrille Berger Skott wrote: > > So kudo to Dag and Plan for the file with the highest coverage: > > http://my.cdash.org/viewCoverageFile.php?buildid=127785&fileid=508339 > Bah, there is an other page with test with higher coverage : > http://my.cdash.org/viewCoverage.php?buildid=127785&status=2 > > -- > Cyrille Berger Skott > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Developer Sprint
I won't be able to fill in the doodle until the 10th of January. I am already on holiday and will go back to work on the 10th. I don't have access to my calendar. If organisation can't wait untill then, then i'll just pray that the chosen date is not conflicting with anything. Pierre On Tue, Dec 21, 2010 at 10:17 PM, Jaroslaw Staniek wrote: > I am glad to see this thread and equally glad to see the long list of > valuable topics. > I'd like to add something popping on top of my head for quite some > time (while not working on picking new names for office suites ;)) > > I propose to go with Qt-only libs a bit more, to make our offerings > more independent each-other and drive potential contributions of new > kind (Qt only devs, non-KDE devs...). > Filters are good candidates for this group, and especially the > lower-level libraries like mso Smart Art, Diagrams... > > KoReports are nearly Qt-only already (as a fork of OpenRPT it has > never used kdelibs in fact). The same for KoProperty lib. > > I am investing into Qt-only Predicate a lot too > (http://community.kde.org/Predicate), as you know it'll be dependency > of kexi, hopefully 2.4. > > Moreover I also believe that every app has some nontrivial bit of code > that can be provided on the outside with a simple API, say, using the > Facade pattern. > > At a conceptual level the idea may evolve into slightly different > model of composing our building blocks: develop core functionality as > Qt-only and then extend for KDE, to get the integration level and > look&feel we all want. > > A bit like it is in WebKit/QtWebKit tandem. > > RFC. > > -- > regards / pozdrawiam, Jaroslaw Staniek > http://www.linkedin.com/in/jstaniek > Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org) > KDE Software Development Platform on MS Windows (windows.kde.org) > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Merge request of text layout restructuring
Hi, I am back from holidays. I have for the moment problems with my Virtualbox 4 installation which keeps crashing on me as soon as I push it a bit. That means I'll have difficulties for reviewing the patch right now. I am considering trying a development set-up on Windows until Virtualbox is stabilised again, but i am not sure how feasible this is (any hint in this direction is actually welcomed). PierreSt On Wed, Jan 5, 2011 at 4:44 PM, Sebastian Sauer wrote: > C. Boemann wrote: > > Last week I worked on the text layout, and I'm now requesting a merge of > > the branch I worked in: > > > > text-layoutrestructure-boemann > > > > What I've done is moving the text runaround properties from the KWFrame > > class to KoShape > > > > Secondly I moved the runaround code from KWord to the TextShape. > > However it is still the responsibility of the application to supply the > > textshape with the relevant shapes. > > > > This was stepd 2-4 in my big 7 step master plan that I've talked to all > > words developers about. > > > > Please take a look, and comment. > > > > I've made basic testing and I'm rather confident that there are no > > regressions. Many unit test might be broken, and should be disabled for > > now. > > > > Review mainly requested from hanzes,pierreSt ,pinaraf, sebsauer, but also > > anyone else who think they have something to contribute. > > Review done. In words/part/tests/TestDocumentLayout.cpp before 21 tests > failed > and now 25 are failing. The probably most interesting one seems to be in > placeAnchoredFrame3() which does; > > QTextLayout *lay = doc->begin().layout(); > QVERIFY(lay->lineCount() >= 2); > > Before the refactoring that lay->lineCount() call returns 17 here and after > it > returns 1. Also waiting for a few seconds after the layout doesn't change > that > result either. Can that be a problem? > > Beside this case it looks fine to me :-) > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Merge request of text layout restructuring
I have already seen that one. But I have also seen on the dot comments (in the article about KDE on windows) that calligra is not compiling and that Boud is looking into this. I am interested in more calligra specific information. Also, is Qt Creator a good solution for developing on windows? PierreSt On Wed, Jan 12, 2011 at 2:59 PM, Cyrille Berger Skott wrote: > On Wednesday 12 January 2011, Pierre Stirnweiss wrote: > > Hi, I am back from holidays. I have for the moment problems with my > > Virtualbox 4 installation which keeps crashing on me as soon as I push it > a > > bit. That means I'll have difficulties for reviewing the patch right now. > I > > am considering trying a development set-up on Windows until Virtualbox is > > stabilised again, but i am not sure how feasible this is (any hint in > this > > direction is actually welcomed). > All information is there: > > http://techbase.kde.org/Getting_Started/Build/KDE4/Windows > > -- > Cyrille Berger Skott > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Merge request of text layout restructuring
On Wed, Jan 12, 2011 at 3:13 PM, Boudewijn Rempt wrote: > On Wednesday 12 January 2011, Pierre Stirnweiss wrote: > > I have already seen that one. But I have also seen on the dot comments > (in > > the article about KDE on windows) that calligra is not compiling and that > > Boud is looking into this. I am interested in more calligra specific > > information. > > My problem is that I tried to compile against packages from the kdewin > installer since I didn't have enough space to use the emerge script. And > those packages have some errors that made my life hard. > > Damn, I was hoping to use these pre-compiled packages to avoid having to compile the whole stack under calligra. oh well, it will remind me of my time with gentoo. > > Also, is Qt Creator a good solution for developing on windows? > > Yes. > Are you using (if so) ms compiler or mingw compiler? It seems they have both pros and cons (disregarding any philosophical considerations). Pierre ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: 2.4 Release Plan
On Thu, Jan 13, 2011 at 2:51 PM, Inge Wallin wrote: > On Thursday, January 13, 2011 14:15:01 Cyrille Berger Skott wrote: > > On Thursday 13 January 2011, Tomas Mecir wrote: > > > As a disclaimer, I'm not active in Calligra development currently, so > > > my opinion may not be entirely relevant, but hopefully it will be > > > useful anyway. > > > > > > Wouldn't it be better to (at least for the initial release) use a > > > different development scheme with an alpha/beta version being released > > > every month or so, with no feature freeze in place? It could be more > > > work to manage it, but by maintaining a relatively constant stream of > > > pre-releases that each contains actual improvements (not only bug > > > fixes), you'd keep the general awareness of the project, while at the > > > same time having enough time to polish the applications to be end-user > > > ready for the first final version (2.4 or 3.0 or however you're going > > > to call it). > > > > One of my main concern with that is that I do think that having hard date > > gives us a focus. I think "a release when we feel we are ready" tends to > > make us go in many directions, because anyway we have time to fix things. > > While if you have a date, you have to focus on selecting what you feel is > > important to finish and fix before that date. > > That is probably correct. How could we make it so that we can keep focus > while still make sure that we get the necessary features and bugfixes in? > Perhaps by doing a suggested: every maintainer set a list of required to release features. Then we can set a fixed date for feature freeze and leave the release date opened. Pierre > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Merge request of text layout restructuring
Well, I have only looked at the code through gitweb, which seems not to allow an easy way of finding the relevant diff to master (maybe I am using the tool incorrectly): the commits specific to this branch do not seem to be highlighted. I have looked at the commits "Move text run around attributes from Words frame class...", "Move Line out into a file of it's own" and "Move Line and Outline from Words to TextShape". I would have liked a way to find a condensed diff to the master branch. At first view, things seem ok. I have not yet tested the branch in real life. I have a question though: what impact does it have (if any) on other apps using the textshape (Stage comes to my mind)? These where not getting this run-around behaviour from the textShape. Another minor thing. Shouldn't the properties/methods "textRunAroundSide" and "textRunAroundDistance" be called a more generic way? There might be other shapes which would run their content around shapes (the musicShape could an example of this). Perhaps remove the "text" from the name? Also, to be more consistent, the Through enum should be named RunThrough, it is after all set by setRunThrough(). In principle, I think we should merge this ASAP if we want it to be included in the next release. There should be enough time to test it and iron out things. The month before release would be a bad idea. PierreSt On Mon, Jan 3, 2011 at 11:25 AM, C. Boemann wrote: > Hi > > Last week I worked on the text layout, and I'm now requesting a merge of > the > branch I worked in: > > text-layoutrestructure-boemann > > What I've done is moving the text runaround properties from the KWFrame > class > to KoShape > > Secondly I moved the runaround code from KWord to the TextShape. > However it is still the responsibility of the application to supply the > textshape with the relevant shapes. > > This was stepd 2-4 in my big 7 step master plan that I've talked to all > words > developers about. > > Please take a look, and comment. > > I've made basic testing and I'm rather confident that there are no > regressions. > Many unit test might be broken, and should be disabled for now. > > Review mainly requested from hanzes,pierreSt ,pinaraf, sebsauer, but also > anyone else who think they have something to contribute. > > best regards > Casper > Best regards > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Merge request of text layout restructuring
Ah, so why does it still appear as a head in gitweb? It just proves that I really need to set up my development environment. Busy week end in sight Well, other comments still applies... ;) Pierre On Fri, Jan 14, 2011 at 2:23 PM, C. Boemann wrote: > On Friday 14 January 2011 14:20:45 Pierre Stirnweiss wrote: > > Well, I have only looked at the code through gitweb, which seems not to > > allow an easy way of finding the relevant diff to master (maybe I am > using > > the tool incorrectly): the commits specific to this branch do not seem to > > be highlighted. I have looked at the commits "Move text run around > > attributes from Words frame class...", "Move Line out into a file of it's > > own" and "Move Line and Outline from Words to TextShape". I would have > > liked a way to find a condensed diff to the master branch. > > > > At first view, things seem ok. I have not yet tested the branch in real > > life. I have a question though: what impact does it have (if any) on > other > > apps using the textshape (Stage comes to my mind)? These where not > getting > > this run-around behaviour from the textShape. > > > > Another minor thing. Shouldn't the properties/methods "textRunAroundSide" > > and "textRunAroundDistance" be called a more generic way? There might be > > other shapes which would run their content around shapes (the musicShape > > could an example of this). Perhaps remove the "text" from the name? > > Also, to be more consistent, the Through enum should be named RunThrough, > > it is after all set by setRunThrough(). > > > > In principle, I think we should merge this ASAP if we want it to be > > included in the next release. There should be enough time to test it and > > iron out things. The month before release would be a bad idea. > > > > > > PierreSt > > > > On Mon, Jan 3, 2011 at 11:25 AM, C. Boemann wrote: > > > Hi > > > > > > Last week I worked on the text layout, and I'm now requesting a merge > of > > > the > > > branch I worked in: > > > > > > text-layoutrestructure-boemann > > > > > > What I've done is moving the text runaround properties from the KWFrame > > > class > > > to KoShape > > > > > > Secondly I moved the runaround code from KWord to the TextShape. > > > However it is still the responsibility of the application to supply the > > > textshape with the relevant shapes. > > > > > > This was stepd 2-4 in my big 7 step master plan that I've talked to all > > > words > > > developers about. > > > > > > Please take a look, and comment. > > > > > > I've made basic testing and I'm rather confident that there are no > > > regressions. > > > Many unit test might be broken, and should be disabled for now. > > > > > > Review mainly requested from hanzes,pierreSt ,pinaraf, sebsauer, but > also > > > anyone else who think they have something to contribute. > > > > > > best regards > > > Casper > > > Best regards > > > ___ > > > calligra-devel mailing list > > > calligra-devel@kde.org > > > https://mail.kde.org/mailman/listinfo/calligra-devel > Good you think so becasue it was merged by sebastian more than a week ago > ;) > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: words - call for help
If my memory is not betraying me (being past 30 you can never be sure of this any more ;)), what you are looking for (to check current implementation) is in plugins/textshape/dialogs. There should be something called styleWidget, styleModel, (or similar names). PierreSt On Fri, Jan 14, 2011 at 2:29 PM, brian larochelle < larochelle.br...@gmail.com> wrote: > Hello, > I want to start looking at this tonight after work. Provided the girl will > leave me alone for a few geek hours ;), and no one else has shown interest. > I've been working with Qt over the past several months porting my iphone > application to Qt, which makes use of model/view. And I've always wanted to > contribute to kde. > > I'll start by rereading the wiki and irc logs, haven't had a chance to > really read them yet. Then work on navigating the source and find my way > around. At first glance, I'll likely start at the below locations. Any > pointers or additional info would be welcome :) > cheers, > > calligra/plugins/dockers/styledocker/ > calligra/words/part/dockers > > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Calligra Sprint 1.4.-3.4.
I don't seem to be able to log in anymore. Could our beloved admin have a look for me please? In the mean time, here is my info: flight cost: about 120EUR, both accomodation and sponsorship needed. PierreSt On Sat, Jan 15, 2011 at 5:28 AM, Thorsten Zachmann wrote: > Hello all, > > looks like not everybody has filled out > > http://community.kde.org/Calligra/Meetings/Begin_2011_meeting#Attendance > > yet. This is a reminder to fill it out by the end of the week (16.1.). The > information is needed so that we can get the approval of the costs by the > e.V. > board. > So if you like to join the sprint please don't wait any longer and fill it > out. > It does not matter if you have answered the doodle or not. Fill out the the > above now so that we can go on with the next steps. We need to hurry so > that > we can arrange visas for the people needing those. > > Thanks, > > Thorsten > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Re: koffice-essen branch interesting for a story in the Commit Digest?
I'd be delighted to see a calligra news dated for the 19th of December. I like this date a lot, since it's my birthday ;) But no pressure ;) Pierre On Sun, Jan 16, 2011 at 1:59 PM, Boudewijn Rempt wrote: > On Sun, 16 Jan 2011, Alexander van Loon wrote: > > > If possible I’d like to include it for the next Commit Digest of either > 19 December or 26 December (remember we are still > > catching up after delays) which will be prepared over the next week I > assume. I didn’t think of a deadline, but if you could e- > > mail it during the next week it would be good, let’s say before next > Friday? > > Ok, will do! > > Boudewijn > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Combined startup view and file menu
I like this idea a lot. PierreSt (who is still struggling to set a development environment in Windows. God the Linux package managers are a bless) On Thu, Jan 20, 2011 at 7:38 AM, Mani N C wrote: > I like the way Recent Documents are grouped and listed. > > For me the side pane looks cluttered in the top. How would it be, if it was > evenly spaced out and fonts/icons little bigger ? > > On the whole +1 from me :) > > > On Thu, Jan 20, 2011 at 1:10 AM, Jaroslaw Staniek wrote: > >> Another mockup. >> Variant of the 3.1 mockup: "Words" button's frame has been completely >> removed, so the button looks and feels like other menu items. >> >> >> http://community.kde.org/Calligra/Usability_and_UX/Common/Startup/Startup_view_integrated_with_the_File_menu#Startup_view_mockup_3.2:_with_view_hidden_and_no_button_frame >> >> -- >> regards / pozdrawiam, Jaroslaw Staniek >> http://www.linkedin.com/in/jstaniek >> Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org) >> KDE Software Development Platform on MS Windows (windows.kde.org) >> ___ >> calligra-devel mailing list >> calligra-devel@kde.org >> https://mail.kde.org/mailman/listinfo/calligra-devel >> > > > > -- > Mani Chandrasekar > > > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
kplato compile problem on windows
As some of may know, I am trying to get Calligra to compile on Windows
MSVC2010. I have encountered a couple of problems, which were easy enough to
solve (with the help of SaroEngels).
The one I am facing now is apparently way more complicated:
in kplato/libs/kernel/kpappointment.h we have the following:
class KPLATO_EXPORT AppointmentInterval {}
class KPLATO_EXPORT AppointmentIntervalList: public QMultiMap {}
This construct yields the error C2487:
'identifier' : member of dll interface class may not be declared with dll
interface
You can declare a whole class, or certain members of a non-DLL interface
class, with DLL interface. You cannot declare a class with DLL interface and
then declare a member of that class with DLL interface.
According to SaroEngels, both QDate and AppointmentInterval are problematic
here. A solution he proposed to this is to have the following:
class KPLATO_EXPORT AppointmentInterval;
class AppointmentIntervalBase : public QMultiMap
class KPLATO_EXPORT AppointmentIntervalList : public AppointmentIntervalBase
Any further thought on this?
PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: kplato compile problem on windows
The functions it is complaining about are the ones from QMap/QMultiMap
PierreSt
On Mon, Jan 24, 2011 at 9:19 AM, Thorsten Zachmann wrote:
> On Monday, January 24, 2011 08:57:15 Pierre Stirnweiss wrote:
> > As some of may know, I am trying to get Calligra to compile on Windows
> > MSVC2010. I have encountered a couple of problems, which were easy enough
> > to solve (with the help of SaroEngels).
> > The one I am facing now is apparently way more complicated:
> >
> > in kplato/libs/kernel/kpappointment.h we have the following:
> >
> > class KPLATO_EXPORT AppointmentInterval {}
> > class KPLATO_EXPORT AppointmentIntervalList: public QMultiMap > AppointmentInterval> {}
> >
> > This construct yields the error C2487:
> > 'identifier' : member of dll interface class may not be declared with
> dll
> > interface
> > You can declare a whole class, or certain members of a non-DLL interface
> > class, with DLL interface. You cannot declare a class with DLL interface
> > and then declare a member of that class with DLL interface.
> >
> >
> > According to SaroEngels, both QDate and AppointmentInterval are
> problematic
> > here. A solution he proposed to this is to have the following:
> >
> > class KPLATO_EXPORT AppointmentInterval;
> >
> > class AppointmentIntervalBase : public QMultiMap > AppointmentInterval>
> >
> > class KPLATO_EXPORT AppointmentIntervalList : public
> > AppointmentIntervalBase
> >
> >
> > Any further thought on this?
> If I understood the comment from jahm correctly it might mean you need to
> implemnt the functions it is complaining about in your inherited class but
> I'm
> not 100% sure about that. Maybe try it with one of the functions to see if
> the
> error message goes away.
>
> Thorsten
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: kplato compile problem on windows
I can try the nepomuk solution (using KPLATO_EXPORT on each methods of the
class instead of on the class itself) this evening. This would probably be
the minimal impact solution.
Just so I am clear, it seems that in nepomuk they have only specified
NEPOMUK_EXPORT on some of the methods. My assumption is that they exported
only the methods which were really used outside? Otherwise I don't really
understand why isFileDataObject would get the EXPORT and not isFolder for
example.
PierreSt
On Mon, Jan 24, 2011 at 10:23 AM, Dag Andersen wrote:
> Mandag 24 januar 2011 09:52:23 skrev Jan Hambrecht:
> > On 24.01.2011 08:57, Pierre Stirnweiss wrote:
> > > As some of may know, I am trying to get Calligra to compile on Windows
> > > MSVC2010. I have encountered a couple of problems, which were easy
> > > enough to solve (with the help of SaroEngels).
> > > The one I am facing now is apparently way more complicated:
> > >
> > > in kplato/libs/kernel/kpappointment.h we have the following:
> > >
> > > class KPLATO_EXPORT AppointmentInterval {}
> > > class KPLATO_EXPORT AppointmentIntervalList: public QMultiMap > > AppointmentInterval> {}
> > >
> > > This construct yields the error C2487:
> > > 'identifier' : member of dll interface class may not be declared with
> > > dll interface
> > > You can declare a whole class, or certain members of a non-DLL
> interface
> > > class, with DLL interface. You cannot declare a class with DLL
> interface
> > > and then declare a member of that class with DLL interface.
> > >
> > >
> > > According to SaroEngels, both QDate and AppointmentInterval are
> > > problematic here. A solution he proposed to this is to have the
> > > following:
> > >
> > > class KPLATO_EXPORT AppointmentInterval;
> > >
> > > class AppointmentIntervalBase : public QMultiMap > > AppointmentInterval>
> > >
> > > class KPLATO_EXPORT AppointmentIntervalList : public
> > > AppointmentIntervalBase
> > >
> > >
> > > Any further thought on this?
> >
> > I would try to change the class from to > QMultimap>. If I remember correctly from a short look yesterday, nowhere
> > in the code are the QMultimap methods of AppointmentIntervalList used,
> > beside within the implementation of AppointmentIntervalList itself.
> Not quite true, but refactoring is not a *big* thing, it's mostly
> lowerBound(), upperbound().
> So if this is the cleanest way, I can do that.
> > So maybe using the follwing construct will work:
> >
> > class AppointmentIntervalBase
> > {
> > // all your existing methods go here
> > private:
> > QMultiMap m_data;
> > };
> >
> > Ciao Jan
> > ___
> > calligra-devel mailing list
> > calligra-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/calligra-devel
>
> --
> Mvh.
> Dag Andersen
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: kplato compile problem on windows
But then, would it be possible to instantiate an AppointmentIntervalList
from outside?
Pierre
On Mon, Jan 24, 2011 at 10:28 AM, Pierre Stirnweiss <
pstirnwe...@googlemail.com> wrote:
> I can try the nepomuk solution (using KPLATO_EXPORT on each methods of the
> class instead of on the class itself) this evening. This would probably be
> the minimal impact solution.
> Just so I am clear, it seems that in nepomuk they have only specified
> NEPOMUK_EXPORT on some of the methods. My assumption is that they exported
> only the methods which were really used outside? Otherwise I don't really
> understand why isFileDataObject would get the EXPORT and not isFolder for
> example.
>
> PierreSt
>
>
> On Mon, Jan 24, 2011 at 10:23 AM, Dag Andersen wrote:
>
>> Mandag 24 januar 2011 09:52:23 skrev Jan Hambrecht:
>> > On 24.01.2011 08:57, Pierre Stirnweiss wrote:
>> > > As some of may know, I am trying to get Calligra to compile on Windows
>> > > MSVC2010. I have encountered a couple of problems, which were easy
>> > > enough to solve (with the help of SaroEngels).
>> > > The one I am facing now is apparently way more complicated:
>> > >
>> > > in kplato/libs/kernel/kpappointment.h we have the following:
>> > >
>> > > class KPLATO_EXPORT AppointmentInterval {}
>> > > class KPLATO_EXPORT AppointmentIntervalList: public QMultiMap> > > AppointmentInterval> {}
>> > >
>> > > This construct yields the error C2487:
>> > > 'identifier' : member of dll interface class may not be declared with
>> > > dll interface
>> > > You can declare a whole class, or certain members of a non-DLL
>> interface
>> > > class, with DLL interface. You cannot declare a class with DLL
>> interface
>> > > and then declare a member of that class with DLL interface.
>> > >
>> > >
>> > > According to SaroEngels, both QDate and AppointmentInterval are
>> > > problematic here. A solution he proposed to this is to have the
>> > > following:
>> > >
>> > > class KPLATO_EXPORT AppointmentInterval;
>> > >
>> > > class AppointmentIntervalBase : public QMultiMap> > > AppointmentInterval>
>> > >
>> > > class KPLATO_EXPORT AppointmentIntervalList : public
>> > > AppointmentIntervalBase
>> > >
>> > >
>> > > Any further thought on this?
>> >
>> > I would try to change the class from to > > QMultimap>. If I remember correctly from a short look yesterday, nowhere
>> > in the code are the QMultimap methods of AppointmentIntervalList used,
>> > beside within the implementation of AppointmentIntervalList itself.
>> Not quite true, but refactoring is not a *big* thing, it's mostly
>> lowerBound(), upperbound().
>> So if this is the cleanest way, I can do that.
>> > So maybe using the follwing construct will work:
>> >
>> > class AppointmentIntervalBase
>> > {
>> > // all your existing methods go here
>> > private:
>> > QMultiMap m_data;
>> > };
>> >
>> > Ciao Jan
>> > ___
>> > calligra-devel mailing list
>> > calligra-devel@kde.org
>> > https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>> --
>> Mvh.
>> Dag Andersen
>> ___
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: kplato compile problem on windows
> > > > (Personnally, I would go for Jan's solution and hide the QMap, because I > don't > like to inherits from the containers, but I guess it is a matter of taste > :) ) > > Which wouldn't *need* to add a AppointmentIntervalListBase, would it? Pierre ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: kplato compile problem on windows
do we have a consensus on one solution over the other? PierreSt On Mon, Jan 24, 2011 at 10:51 AM, Dag Andersen wrote: > Mandag 24 januar 2011 10:37:00 skrev Cyrille Berger Skott: > > On Monday 24 January 2011, Pierre Stirnweiss wrote: > > > I can try the nepomuk solution (using KPLATO_EXPORT on each methods of > > > the class instead of on the class itself) this evening. This would > > > probably be the minimal impact solution. > > > Just so I am clear, it seems that in nepomuk they have only specified > > > NEPOMUK_EXPORT on some of the methods. My assumption is that they > > > exported only the methods which were really used outside? Otherwise I > > > don't really understand why isFileDataObject would get the EXPORT and > > > not isFolder for example. > > > > Generally speaking, you only need to export what is really used outside > :) > > We usually export the whole class, because if a function is public, we > > assume that it wants to be used. I don't know what is the intent of > > "libs/kernel", if it is strictly private to kplato/plan, then exporting > > only the needed function make sense. > I put the basics into separate lib because I thought maybe in the > (distant?) > future one could use it independently of the current plan/kplato gui. > > > > (Personnally, I would go for Jan's solution and hide the QMap, because I > > don't like to inherits from the containers, but I guess it is a matter of > > taste :) ) > > -- > Mvh. > Dag Andersen > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: kplato compile problem on windows
On Mon, Jan 24, 2011 at 3:53 PM, Pierre Stirnweiss < pstirnwe...@googlemail.com> wrote: > On Mon, Jan 24, 2011 at 3:48 PM, Dag Andersen wrote: > >> Mandag 24 januar 2011 14:40:10 skrev du: >> > ok, no stress, i have still plenty of other things to do in setting up >> my >> > development environment on windows. i am still missing a lot of the >> > optional dependencies, i still can't commit from windows, >> > if worse comes to worse and i am left with nothing else to do, i can >> still >> > temporarily disable compilation of kplato. >> Done, even with minutes to spear :) >> God luck with windows. >> > > Thanks, it is actually proving way more cumbersome than anticipated. By the > time i am finished, virtualbox will probably be fixed, and i would be able > to run linux again oh well, at least it brings some value to the > project. > Modulo 3 changes in the kpappointment.cpp, that class is now compiling. I have reached a further error in kplato but haven't looked into it yet. I'll have more time tomorrow to finish up fixing the errors on kplato and i'll commit then. Pierre ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: tools docker etc in plan
To be honest, I think we should think a bit further. My impression (when I was looking into tools/plugins loading mechanism for the (still unfinished) change tracking tool) is that the system is very rigid and basically depends on the developer knowing what plugins are there what plugins would be usefull. There also is the case where some tools of one particular plugin does not make sense (expl, the change tracking tool of the textshape plugin doesn't make sense outside words, because odf does not foresee change tracking outside a text document). I think we should revisit how our plugins/tools are loaded and allow more flexibility at runtime to set which are the plugins to be loaded (also by users). After all, the whole point of the plugin system is to allow external plugins to be designed. So there should be a way to set this up, other than calligra core developpers explicitely allowing/disallowing plugins/tools. On a side note, it seems that at application startup, all the plugins are loaded serialised and only when this is finished will the application load further. That's ok when we have only a handfull of plugin installed but the system does not scale very much. Can't we have non critical plugins load in parrallel to further application startup?, in a different thread? PierreSt On Tue, Jan 25, 2011 at 10:49 AM, Dag Andersen wrote: > Atm I don't have any use for the tools docker nor actually any other docker > except the Scripting docker in plan. > This *may* change in the future of course, so it would be nice to have a > way > of controlling which plugins should be loaded. AFAICS it's possible to > *disable* plugins if you know their id. I'd rather have the possibility to > *enable* those I use and have everything else disabled. > Anybody knows how this could most easily be achived? > -- > Mvh. > Dag Andersen > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: tools docker etc in plan
On Tue, Jan 25, 2011 at 3:25 PM, Sven Langkamp wrote: > On Tue, Jan 25, 2011 at 11:07 AM, Pierre Stirnweiss < > pstirnwe...@googlemail.com> wrote: > >> To be honest, I think we should think a bit further. My impression (when I >> was looking into tools/plugins loading mechanism for the (still unfinished) >> change tracking tool) is that the system is very rigid and basically depends >> on the developer knowing what plugins are there what plugins would be >> usefull. There also is the case where some tools of one particular plugin >> does not make sense (expl, the change tracking tool of the textshape plugin >> doesn't make sense outside words, because odf does not foresee change >> tracking outside a text document). >> I think we should revisit how our plugins/tools are loaded and allow more >> flexibility at runtime to set which are the plugins to be loaded (also by >> users). After all, the whole point of the plugin system is to allow external >> plugins to be designed. So there should be a way to set this up, other than >> calligra core developpers explicitely allowing/disallowing plugins/tools. >> > > Only plugins that flake loads by default should need to be blacklisted. > Usually external developers shouldn't add plugins with that type. The change > tracking tool could be loaded as Words plugin, just as the Krita tools that > have the Krita/Tool plugin type. > The change tracking tool is (and up to now) need to be a tool of the textshape, so as far as I understand the system, I can't load the textshape without the change tracking tool. But maybe there is something I overlooked. But in a more general way, is there a way for me (as a user) to let's say, have the music shape enabled for words and not for stages? Can I change this at run time? Pierre ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: kplato compile problem on windows
Hi Dag,
sorry to nag you again. I have some questions related to the external (made
internal) dependency for the scheduler (librcps). Was there a reason to copy
the code inside our repository instead of linking to it as an external lib?
I have a couple of problems with it. The first problem, which is now solved
is that the files have a .c extension, although they are c++. I (locally)
renamed them. However, that fix might not be desirable, the code being from
external source. In that case I think there is the possibility to add a flag
to the CMakeList.txt. Tell me what you think is best.
The problem I am now stuck at is coming from this:
537 int job_compare(const void *a, const void *b) {
538 return a - b;
539 }
MSVC tells me that the size of const void* is unknown. On looking on the
web, I see people explaining that since the object type, and therefore size
is unknown you cannot (at least in msvc) do pointer math on these. There are
actually some quite heated discussions on the merit of msvc/gcc spawning
from this, funny.
Basically it seems that the consensus is to cast the pointer to a char* if
you want to do pointer arithmetic.
Now, I am not actually completely sure I understand what is wanted here, but
I assume this code is basically a: if(job a == job b) return 0 else return
!0. I guess then that casting the pointers to char* wouldn't affect the
logic, would it?
Any other suggestion for this? Should I contact the original author of the
lib?
Thanks,
PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request: Moving anchor strategy into text shape
Sorry to arrive after the battle, but I still would like to give an opinion
on this one.
I don't think this change is going in the right direction. It mixes
responsibilities between kotext lib/textshape/application even more.
I think we should have a clear separation of responsibilities:
kotext lib: handles character/string level
textshapes: handles lines inside a shape, given constraints of that shape
application: handles shapes
I think it is bad idea to put things like page size, page number,... inside
kotext. This lib is supposed to be used by applications which are not
necessarily page driven.
Equally, I don't think it is the responsibility of every text shape to have
a track record of the other shapes. Children shapes eventually, but
definitely not shapes that are unrelated. This should be at application
level.
Now you have even more diffusion of stuff. If this is the direction you want
to give to the text stuff, why are we still having a textshape and kotext
lib?
Pierre
On Thu, Jan 27, 2011 at 6:13 AM, Thorsten Zachmann wrote:
>This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100442/
>
> I just added some small comments mostly about the style. Would be nice if you
> could fix those before committing.
>
>
>
> plugins/textshape/Layout.h<http://git.reviewboard.kde.org/r/100442/diff/1/?file=7551#file7551line56>
> (Diff
> revision 1)
>
> class ToCGenerator;
>
>56
>
> ~Layout();
>
> the destructor should be marked virtual
>
>
>
> plugins/textshape/TextAnchorStrategy.h<http://git.reviewboard.kde.org/r/100442/diff/1/?file=7553#file7553line28>
> (Diff
> revision 1)
>
> class KoTextShapeData;
>
>28
>
> class TextAnchorStrategy : public KoAnchorStrategy {
>
> the opening { should be moved to the next line
>
>
>
> plugins/textshape/TextAnchorStrategy.cpp<http://git.reviewboard.kde.org/r/100442/diff/1/?file=7554#file7554line335>
> (Diff
> revision 1)
>
> bool TextAnchorStrategy::countVerticalRel(QRectF &anchorBoundingRect, QRectF
> containerBoundingRect,
>
>335
>
> switch (m_anchor->verticalRel()) {
>
> the indention of the switch and case is wrong here
>
>
>
> words/part/frames/KWTextDocumentLayout.cpp<http://git.reviewboard.kde.org/r/100442/diff/1/?file=7559#file7559line302>
> (Diff
> revision 1)
>
> private:
>
> 286
>
> // if part of page is already layouted than check if there
> are some anchored shapes and register them
>
> 259
>
> //QRectF bounds = m_state->shape->boundingRect();
>
> is it worth to keep the commented out code. If so please add a comment on
> why it is commented out, if not please delete it. That will make it easier
> later to figure out why the code is commented out
>
>
> - Thorsten
>
> On January 25th, 2011, 2:04 p.m., Matus Hanzes wrote:
> Review request for Calligra and Casper Boemann.
> By Matus Hanzes.
>
> *Updated Jan. 25, 2011, 2:04 p.m.*
> Description
>
> This patch moves KWAnchorStrategy into text shape.
>
> The reason is that it is not possible to do advanced shape anchor logic
> outside Layout.cpp.
>
> The main idea is to register the shapes into Layout.cpp and layout handles
> all the necessary things.
>
> The registration is done in KWTextDocumentLayout::positionInlineObject where
> all the words dependent data are set.
> (pageRectangle,pageContentRectangle,pageNumber)
>
> If the document or anchored shape changes
> KoTextDocumentLayout::resetInlineObject is called which resets all the shapes
> that are not valid and layout finds the right place for them.
>
> Any comments are welcome
>
>
> Diffs
>
>- libs/flake/KoShape.h (f7179d7)
>- libs/flake/KoShape.cpp (c5aee86)
>- libs/kotext/KoTextAnchor.h (2bbbf9a)
>- libs/kotext/KoTextAnchor.cpp (ece23d6)
>- libs/kotext/KoTextDocumentLayout.h (4284d37)
>- libs/kotext/KoTextDocumentLayout.cpp (6b66e0f)
>- libs/kotext/KoTextShapeContainerModel.h (ce3a6ae)
>- libs/kotext/KoTextShapeContainerModel.cpp (00ca9b5)
>- plugins/textshape/CMakeLists.txt (a23ecc3)
>- plugins/textshape/Layout.h (5e42b7a)
>- plugins/textshape/Layout.cpp (e1228e4)
>- plugins/textshape/TextAnchorStrategy.h (PRE-CREATION)
>- plugins/textshape/TextAnchorStrategy.cpp (PRE-CREATION)
>- words/part/CMakeLists.txt (2d5c667)
>- words/part/frames/KWAnchorStrategy.h (b39f377)
>- words/part/frames/KWAnchorStrategy.cpp (c168962)
>- words/part/frames/KWTextDocumentLayout.h (59add4f)
>- words/part/frames/KWTextDocumentLayout.cpp (15a8803)
>
> View Diff <http://git.reviewboard.kde.org/r/100442/diff/>
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request: Moving anchor strategy into text shape
On Thu, Jan 27, 2011 at 10:51 AM, C. Boemann wrote:
> Well this is a step on the road and not the end result. So bear with me.
>
> But I've indeed changed my mind about who does the layout and drawing, and
> have come up with an abstraction that will allow the kotext library to do
> just
> that.
So you mean, drawing/layouting would be done at kotext level?
> Well totally controlled by the textshape. This abstraction will allow
> any application to gain layout and painting.
This is already the case. kotext provides an abstracted interface for
layouting. the user of the lib needs to implement his layouting logic. What
layouting logic/paradigm would you favor for kotext? this would also mean
that any other layouting paradigm/logic, would still need to carry the
weight (memory footprint,...) of a layouting logic he does not even care
about?
Sounds like a step in the opposite direction of the goal of deploying/using
on a multitude of devices, for a multitude of use cases.
A bit like MS having internet explorer right tied up with their kernel. It
becomes awefully difficult to have a very lean kernel based on windows.
First app that will benefit from
> this is our very own Tables.
>
> But shapes and pages will soon be abstracted away as i said. Oh and no one
> requires those pagesizes and numbers to be filled out by apps that don't
> use
> it. For those apps the anchoring mode that relate to these things will
> simply
> not be activated.
>
Yes, no one has to fill these, but you are bloating a general purpose
library with specific cases peculiarities. You'll end up with a melting pot
library of things which do not relate to each other. You mention Tables, so
why not also add the Spreadsheet/Cell coordinates to the mix? And since
kotext could also be used in a painting application, the layer to which the
anchored shape belongs. then, one could use kotext for a music notation
stuff, so we could add score/voice/bar information.
I am exaggerating this a lot, but once the box is opened, it is very
difficult to draw a line.
Pierre
>
> On Thursday 27 January 2011 10:25:08 Pierre Stirnweiss wrote:
> > Sorry to arrive after the battle, but I still would like to give an
> opinion
> > on this one.
> > I don't think this change is going in the right direction. It mixes
> > responsibilities between kotext lib/textshape/application even more.
> >
> > I think we should have a clear separation of responsibilities:
> > kotext lib: handles character/string level
> > textshapes: handles lines inside a shape, given constraints of that shape
> > application: handles shapes
> >
> > I think it is bad idea to put things like page size, page number,...
> inside
> > kotext. This lib is supposed to be used by applications which are not
> > necessarily page driven.
> > Equally, I don't think it is the responsibility of every text shape to
> have
> > a track record of the other shapes. Children shapes eventually, but
> > definitely not shapes that are unrelated. This should be at application
> > level.
> >
> > Now you have even more diffusion of stuff. If this is the direction you
> > want to give to the text stuff, why are we still having a textshape and
> > kotext lib?
> >
> >
> > Pierre
> >
> > On Thu, Jan 27, 2011 at 6:13 AM, Thorsten Zachmann
> wrote:
> > >This is an automatically generated e-mail. To reply, visit:
> > > http://git.reviewboard.kde.org/r/100442/
> > >
> > > I just added some small comments mostly about the style. Would be nice
> if
> > > you could fix those before committing.
> > >
> > >plugins/textshape/Layout.h<
> http://git.reviewboard.kde.org/r/100442/dif
> > >f/1/?file=7551#file7551line56> (Diff
> > >
> > > revision 1)
> > >
> > > class ToCGenerator;
> > >
> > >56
> > >
> > > ~Layout();
> > >
> > > the destructor should be marked virtual
> > >
> > >plugins/textshape/TextAnchorStrategy.h<
> http://git.reviewboard.kde.org/
> > >r/100442/diff/1/?file=7553#file7553line28> (Diff
> > >
> > > revision 1)
> > >
> > > class KoTextShapeData;
> > >
> > >28
> > >
> > > class TextAnchorStrategy : public KoAnchorStrategy {
> > >
> > > the opening { should be moved to the next line
> > >
> > >plugins/textshape/TextAnchorStrategy.cpp<
> http://git.reviewboard.kde.or
> > >g/r/100442/diff/1/?file=7554#file7554line335> (Diff
> > >
> > > revision 1)
> > >
> >
Re: Review Request: Moving anchor strategy into text shape
> > Well as i said it's going to be abstracted away, and we are creating a > layout > engine for ODF after all. Meaning that a lot of the layout is quite > specified > how should look. If all a user wants is layout of text, then kotext is handly > a match anyway. And yes there might be a little overhead in terms of memory > footprint, but it's actually not that much. > > And we gain so much by having a shared library in terms of easier, smaller > and > more maintainable code. And the cells and layer coordinates you talk of, > are > actually going to be supplied by the application with the exact same > abstraction as the pages of a words document. > > Casper > ___ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel > There must be something I am missing here. We have already: kotext providing an abstracted interface for layouting lines (koTextDocumentLayout IIRC). one implementation of that interface is in the textShape (Layout). The text within a line is already drawn/layouted by Qt text engine. Now you are telling me that layouting gets drawn inside kotext and will be reabstracted later? If the purpose is to also have a shared layouting implementation without the bloat of textshape/texttool,... then I think a better solution would be to provide one in its own library which would depend on kotext. That way you can keep kotext clean of higher level layouting, such as lines/shape. Which would still allow for simpler use cases. Pierre ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Review Request 120250: Change blockLayout return to be more explicit
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120250/ --- Review request for Calligra. Bugs: 306000 http://bugs.kde.org/show_bug.cgi?id=306000 Repository: calligra Description --- Returns an enum instead of a boolean and relying on an integer value aside. This allows the backtrack code to know that a layout ended because of a page break, and thus not follow the keep with next instead of ending up in an infinite loop. With that patch, we still have a difference between us and LibreOffice 4.3, a check of the OpenDocument specification will perhaps help : they decide to just skip the page break when it is in a keep with next block. Diffs - libs/textlayout/KoTextLayoutArea.h 7a15191e5a3dfb05a3e62ae7b9aaadabcceeb1fb libs/textlayout/KoTextLayoutArea.cpp c74dbd490bf5c48386383f5d622722dfa8b5f7cc Diff: https://git.reviewboard.kde.org/r/120250/diff/ Testing --- Checked with the document from bug report 306000 : layouting the document now works and does not end up in an infinite loop. Thanks, Pierre Ducroquet ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 120250: Don't infinitely loop when backtracking keepWithNext with a page break
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120250/ --- (Updated Sept. 18, 2014, 5:59 p.m.) Review request for Calligra. Changes --- Simpler patch : don't backtrack the whole area. This does not match LibreOffice behaviour, but since that behaviour is unspecified and followed by at least another implementation... Summary (updated) - Don't infinitely loop when backtracking keepWithNext with a page break Bugs: 306000 http://bugs.kde.org/show_bug.cgi?id=306000 Repository: calligra Description --- Returns an enum instead of a boolean and relying on an integer value aside. This allows the backtrack code to know that a layout ended because of a page break, and thus not follow the keep with next instead of ending up in an infinite loop. With that patch, we still have a difference between us and LibreOffice 4.3, a check of the OpenDocument specification will perhaps help : they decide to just skip the page break when it is in a keep with next block. Diffs (updated) - libs/textlayout/KoTextLayoutArea.cpp c74dbd4 Diff: https://git.reviewboard.kde.org/r/120250/diff/ Testing --- Checked with the document from bug report 306000 : layouting the document now works and does not end up in an infinite loop. Thanks, Pierre Ducroquet ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 120250: Don't infinitely loop when backtracking keepWithNext with a page break
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120250/ --- (Updated Sept. 18, 2014, 6:01 p.m.) Review request for Calligra. Changes --- Fix description to match the new patch Bugs: 306000 http://bugs.kde.org/show_bug.cgi?id=306000 Repository: calligra Description (updated) --- The backtrack code can infinitely loop when encounteering a page break in a long keepWithNext block. With that patch, we still have a difference between us and LibreOffice 4.3 : they decide to just skip the page break when it is in a keep with next block. Diffs - libs/textlayout/KoTextLayoutArea.cpp c74dbd4 Diff: https://git.reviewboard.kde.org/r/120250/diff/ Testing --- Checked with the document from bug report 306000 : layouting the document now works and does not end up in an infinite loop. Thanks, Pierre Ducroquet ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 120250: Don't infinitely loop when backtracking keepWithNext with a page break
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120250/ --- (Updated Sept. 18, 2014, 7:41 p.m.) Review request for Calligra. Changes --- Don't backtrack one step too much Bugs: 306000 http://bugs.kde.org/show_bug.cgi?id=306000 Repository: calligra Description --- The backtrack code can infinitely loop when encounteering a page break in a long keepWithNext block. With that patch, we still have a difference between us and LibreOffice 4.3 : they decide to just skip the page break when it is in a keep with next block. Diffs (updated) - libs/textlayout/KoTextLayoutArea.cpp c74dbd4 Diff: https://git.reviewboard.kde.org/r/120250/diff/ Testing --- Checked with the document from bug report 306000 : layouting the document now works and does not end up in an infinite loop. Thanks, Pierre Ducroquet ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 120250: Don't infinitely loop when backtracking keepWithNext with a page break
> On Sept. 18, 2014, 7:06 p.m., Camilla Boemann wrote: > > as far as I see it this code will always backtrack one block too much - can > > you please check > > > > But it correctly doesn't back track at all if all blocks have keep with next Thanks, the new diff fixes that, my bad. - Pierre --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120250/#review66862 --- On Sept. 18, 2014, 7:41 p.m., Pierre Ducroquet wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120250/ > --- > > (Updated Sept. 18, 2014, 7:41 p.m.) > > > Review request for Calligra. > > > Bugs: 306000 > http://bugs.kde.org/show_bug.cgi?id=306000 > > > Repository: calligra > > > Description > --- > > The backtrack code can infinitely loop when encounteering a page break in a > long keepWithNext block. > > With that patch, we still have a difference between us and LibreOffice 4.3 : > they decide to just skip the page break when it is in a keep with next block. > > > Diffs > - > > libs/textlayout/KoTextLayoutArea.cpp c74dbd4 > > Diff: https://git.reviewboard.kde.org/r/120250/diff/ > > > Testing > --- > > Checked with the document from bug report 306000 : layouting the document now > works and does not end up in an infinite loop. > > > Thanks, > > Pierre Ducroquet > > ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 120250: Don't infinitely loop when backtracking keepWithNext with a page break
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120250/ --- (Updated Sept. 18, 2014, 7:57 p.m.) Status -- This change has been marked as submitted. Review request for Calligra. Bugs: 306000 http://bugs.kde.org/show_bug.cgi?id=306000 Repository: calligra Description --- The backtrack code can infinitely loop when encounteering a page break in a long keepWithNext block. With that patch, we still have a difference between us and LibreOffice 4.3 : they decide to just skip the page break when it is in a keep with next block. Diffs - libs/textlayout/KoTextLayoutArea.cpp c74dbd4 Diff: https://git.reviewboard.kde.org/r/120250/diff/ Testing --- Checked with the document from bug report 306000 : layouting the document now works and does not end up in an infinite loop. Thanks, Pierre Ducroquet ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Review Request 120375: Don't look further than what we are currently layouting
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120375/ --- Review request for Calligra and Camilla Boemann. Bugs: 332220 http://bugs.kde.org/show_bug.cgi?id=332220 Repository: calligra Description --- Don't look further than what we are currently layouting Diffs - libs/textlayout/KoTextDocumentLayout.cpp 3c869e017265e3776812e8ece5ee67ecfb275e48 Diff: https://git.reviewboard.kde.org/r/120375/diff/ Testing --- Fix bug 332220 by not looking for annotations after the line we are currently layouting. Since we are currently layouting it, we crash trying to use the next line if we go to far. Testing done on : - the two test cases for bug 332220 : no more crash, comment still visible. - a simple non-crashing file : no crash, comment still visible. Thanks, Pierre Ducroquet ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 120375: Don't look further than what we are currently layouting
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120375/ --- (Updated Sept. 26, 2014, 7:02 a.m.) Status -- This change has been marked as submitted. Review request for Calligra and Camilla Boemann. Bugs: 332220 http://bugs.kde.org/show_bug.cgi?id=332220 Repository: calligra Description --- Don't look further than what we are currently layouting Diffs - libs/textlayout/KoTextDocumentLayout.cpp 3c869e017265e3776812e8ece5ee67ecfb275e48 Diff: https://git.reviewboard.kde.org/r/120375/diff/ Testing --- Fix bug 332220 by not looking for annotations after the line we are currently layouting. Since we are currently layouting it, we crash trying to use the next line if we go to far. Testing done on : - the two test cases for bug 332220 : no more crash, comment still visible. - a simple non-crashing file : no crash, comment still visible. Thanks, Pierre Ducroquet ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
Re: Review Request 120468: Workaround bug 293337
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120468/ --- (Updated Oct. 2, 2014, 8:07 p.m.) Review request for Calligra and Camilla Boemann. Bugs: 293337 http://bugs.kde.org/show_bug.cgi?id=293337 Repository: calligra Description --- Check cell size constraints regarding requested row height to prevent infinite looking for space. When fixed row height < padding + borders, things go really bad : we are starving for space, but we can never get past this demand. My current solution is to acknowledge that we are in an impossible situation and, instead of asking for space, layout knowing that nothing fits in there. Diffs - libs/textlayout/KoTextLayoutTableArea.cpp 4fbec7b3b0a0e4b92a2bbbd925491b084e80748a Diff: https://git.reviewboard.kde.org/r/120468/diff/ Testing --- Document from bug report 293337 is now working, so both regular tables and weird too-small cells work. Thanks, Pierre Ducroquet ___ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
