Re: Many questions for Stage

[C. Boemann]

On Friday 02 October 2015 09:54:59 David Faure wrote:
> Here are some questions to ensure I won't change behavior that was there on
> purpose, or that I didn't miss something obvious:
> 
> * Shape animations: Move up / Move down doesn't move the setting "start on
> mouse click / start after previous animation / start after next animation".
> Shouldn't it? I expected it to.
sounds like a bug imho

> * Color selection: there's no color picker and no way to just type a color
> name like #RRGGBB? Or did I miss it?
picker would be nice - but the #RRGGBB was left out intentionally as it 
clashes a bit with the coor independence idea - but thinking back it might 
make sense to assume sRGB profile for those values (however that does mean that 
not all values will produce a valid color and not all colors will have a name)

> * The "connect shapes" tool in Stage only works with paths that I had
> imported from an ooimpress presentation. More precisely, I'm surprised that
> the regular text boxes from Stage cannot be used with the "connect shapes"
> tool. Is this on purpose? Or could this be added?
I think this is because of the placeholde stuff stage puts outside it's 
textboxes so the connection tool misses that this is indeed a shape that can 
be connected to.

> * How do I insert an arrow between two text shapes then? I can do it in
> OOimpress. (I don't mean the right-pointing arrow that I can insert with
> Add Shape in stage, but rather diagonal lines with an arrow at the end).
Fixing above bug i would assume :)

> * Weird: after inserting such an arrow in OOImpress and opening the
> presentation in Stage, I can't set a shape animation on that arrow. I just
> can't select it, when in the animation tool.
probably because on load it some how doesn't get an animation id set (can't 
remember the real name but all shapes should get this assigned - connection 
shapes being a bit special might sneak out of this assignment )

> * When changing an image ("double click to choose image" or "Replace
> image..."), if the aspect ratio changes then the user has no way to make it
> correct again. Resizing will respect aspect ratio (I love that in general,
> but not when it's wrong to start with), and the Picture editing tool cannot
> change the size of the shape itself. What do you suggest would be the best
> GUI for allowing to set the image shape to the size of the underlying image
> data again? (In addition I suppose there should be a keyboard modifier for
> resizing without keeping aspect ratio, but that's not really what I needed,
> it would take some guessing to go back to the right size).
No answer but agree it needs a solution

> * I miss the "reopen on the page/slide where I was when closing the app"
> feature. I had code for that in KWord (and in the ODF specs) long ago... I
> can't really remember what it was though. Maybe something in meta.xml or
> so.
it's not in Words either, but the info is in the settings.xml iirc and yeah 
needs to be done

> * I miss "click on 4 text shapes and change the font for all of them". This
> worked in KOffice :-) (the Text editing tool only applies to one shape). Is
> there any way to make this happen again with the current design?
Not easily done and not something i'd like either - you only have one 
selection at a time and that is where the font color is applied. As much as I 
can see it is nice for a specific case in general i think it's too much of 
specialization that will cloud the general usage.

best regards
Camilla
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: ChangeListLevelCommand bug?

[C. Boemann]

On Sunday 04 October 2015 14:59:21 David Faure wrote:
> On Sunday 04 October 2015 14:52:54 Camilla Boemann wrote:
> > Could look like that yes - unfortunately the guy who were most into this
> > have not been active for over a year so i think the best way to know for
> > sure is to debug it - all i can say is that the layout works
> > 
> > so it's either the interaction  - but your evidence suggests that is
> > correct
> > 
> > or the setup of the indentation - as you suggest that is the culprit'
> 
> If that is the case, where do you suggest to debug this further?
> i.e. where is the code that translates "int level" to an actual position in
> cm or pixels?
The redo method calculates the margin in pt. However this is only called for 
level 2-10

initially the list is created and the level 1 is set in ChangeListCommand line 
80

level 1 is set to MARGIN_DEFAULT*(lev+2)
level 2 is set to MARGIN_DEFAULT*(lev+1)

which in both cases result in a value of 54 :(

btw for a description of how the geometry of the list modes works take a look 
at:
libs/textlayout/documentation/list_alignment_mode.txt

(the gui creates lists of mode aligment_mode)

I'd say +1 is the correct thing and ChangeListCommand should be changed

And yeah it seems really bad this is set in so wildly different places

best regards
Camilla




___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: [Maniphest] [Commented On] T665: Show default (empty) document on startup in document-based Calligra apps

[C. Boemann]

On Monday 18 January 2016 11:28:17 René J.V. Bertin wrote:
> On Monday January 18 2016 10:05:32 boemann wrote:
> >One thing tohugh - it shouldn't be an empty document - I wan to get away
> >from this  as we need all sorts ofinitial setup, and i want to remove the
> >custom dialog for the same reason - but anyway the default startup
> >document should be the blank template
> >
> >but as i said i fear it's not such a low hanging fruit at all
> 
> I've never understood why applications would ever need an actual on-disk
> template for a blank document. Even without using an OO programming
> language proper initialisation of the internal document structure should
> give you (wait for it) an empty document.
> 
> R.
Well what you would get is a really empty document then - not pages, no font, 
no margins, no nothing - all of those decisions is what is stored in a 
template. Having to code all those decisions just for the sake of not loading 
a file with those decisions "coded" through a much nice user interface called a 
wordprocessor is well.. stupid.


___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Text styles UI IRC meeting

[C. Boemann]

On Monday 13 December 2010 22:02:37 Elvis Stansvik wrote:
> 2010/12/11 Elvis Stansvik :
> > 2010/12/11 Elvis Stansvik :
> >> Hello Calligra people,
> >> 
> >> With Chrismas closing in, I've been tasked with organizing an IRC
> >> meeting on the design of the text styles UI, which is badly in need of
> >> a re-work.
> > 
> > Of course I forgot to say (it's in the Doodle though); the meeting
> > will take place in #calligra-styles-ui on Freenode.
> > 
> > Elvis
> > 
> >> I've created a Doodle with suggestions for times/dates:
> >> 
> >> http://www.doodle.com/p8bc5difrvw45brn
> >> 
> >> People who want to attend should fill in their preferred dates/times.
> 
> Okay, so me, Casper, PierreSt and Thomas P have filled in dates, and
> it seems either Monday 20/12 (in one week) or Sunday 26/12 is the best
> date.
> 
> How about you Cyrille, are you available on any of those dates? Anyone
> else that really feels like/should participate?
> 
> If I get to pick one of those two dates, I'd say I prefer sunday
> 26/12. Especially since I'm not sure that Internet access has been
> delivered to our new apartment by monday 20/12. But either of the two
> dates works; If there's no Internet I'll just do it from school. They
> have Inkscape installed there.
> 
> Elvis
> 
> >> Having at least Casper and Cyrille there is important. And we'd really
> >> like to have Thomas Pfeiffer there for usability input. Thomas, are
> >> you available on any of those dates?
> >> 
> >> I recently dug up an old mockup for the text styles UI I did once and
> >> put it on the wiki [1]. I'm willing to do some Inkscaping during/after
> >> the meeting to make a new mockup that reflects the new design
> >> decisions. I'll also log the conversations and write meeting minutes.
> >> 
> >> I estimate the meeting will take a couple of hours, plus minus 30
> >> minutes.
> >> 
> >> Best regards,
> >> Elvis
> >> 
> >> [1] http://community.kde.org/Calligra/Words/Text_Styles_UI_Mockup
> 
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
I'd prefer 26th as well as I'm in London on the 20th (though I am able to 
attend as I indicated)

Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Screenshots

[C. Boemann]

For Words I've been preparing a document, that I'd like shown, but I've not 
had time to finish it yet.

I would however also like to make sure the application looks it's best, 
regarding docker placement etc.

I don't think we should reuse the same document in every screenshot, It will 
just look unimaginative.

So if I forget about this again please due to many othe things, send out a new 
mail. And I definitely agree it's important and would like to take you up on 
the offer :)

Casper

On Monday 13 December 2010 11:53:59 Johannes Simon wrote:
> As pointed out by some users on both our website and dot.kde.org, the
> screenshots that can currently be found on our website could be improved a
> bit. I agree here, and I am going to take on this task. Basically, my goal
> is to have loads of pretty screenshots of all Calligra apps, all with the
> Oxygen style and window decoration. However, I'll need a bit of input from
> you:
> 
> 1) Does anyone have pretty-looking odt/ods/odp documents (or document
> layouts), pictures or vector graphics that I could reuse? This is probably
> the most important point. A brief look at http://www.apple.com/iwork/
> (it's no secret that I'm an Apple fanboy, hah) will show you that the
> actual documents pictured are just as important as the cool user interface
> around it.
> 
> 2) Ideas of what to highlight in each app are very welcome. If you have
> this super-cool, unique, useful or whatever feature X in mind you have
> implemented in your app, let me know and I'll take a screenshot that fits
> into the theme of the others.
> 
> 3) Cool would be something that reappears in every screenshot (or where
> applicable, at least). Like the giraffe [1] we had in one of our release
> announcements. If you have something in mind that I could use here, let me
> know.
> 
> [1] See http://www.openclipart.org/detail/17628. The original release
> announcement this appeared in (2.0 beta 1) doesn't seem to be on
> koffice.org anymore. ___
> 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: New design to Arrange docker

[C. Boemann]

On Saturday 18 December 2010 09:33:51 Yue Liu wrote:
> Hello,
> 
> Currently the Arrange docker lacks buttons for distribute commands,
> until now only karbon has menu items to reach those commands, so I
> made a new design of the Arrange docker. The icons are missing.(I
> don't know who made icons for KOffice, the oxygen team?) Those blank
> buttons represent the 8 distribute commands in Karbon's menu
> respectively.
> 
> So what do you think about it? Is it ok with the new design?
Uhm not really. We should try really hard to not make dockers more than 2 rows 
in height. (and not too wide either, something like 5:1 width:height ratio)

Also the align buttons are rather more specialized, and provide redundant 
functionality (although more convenient than moving by hand). 

Also not all applications will work with this. Words in the vertical axis 
comes to mind. It's a technical challenge

I suggest that these distribute icons are available through a popup menu tool 
button in the docker.

best regards
Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: git and shell prompt

[C. Boemann]

On Thursday 16 December 2010 09:54:04 Cyrille Berger Skott wrote:
> Hi,
> 
> Yesterday I have introduced the commands related to branches, and I am
> expecting that really soon we will all be working with multiple branch. The
> problem is to remember in which branch you are at the moment, of course you
> can run "git branch" and you will know. But frankly, you are going to
> commit to the wrong branch more than once, unless the name of the branch
> is screamed in your face.
> 
> But with bash and zsh, it is possible to have the name of the current
> branch in the prompt (you can have other things, but for me the branch
> name is what is interesting).
> 
> For zsh, I added this to my .zshrc :
> 
> 
> #
> # VCS support
> #
> 
> autoload -Uz vcs_info
> 
> precmd() {
>   psvar=()
>   vcs_info
>   [[ -n $vcs_info_msg_0_ ]] && psvar[1]="$vcs_info_msg_0_"
> }
> 
> PS1VCS=%(1v.%F{yellow}%1v%f.)
> 
> 
> And then you just need to add $PS1VCS to your PS1 line. For instance, mine
> looks like this:
> 
> export PS1="%B%F{cyan}%T%f %F{red}%n%f%F{%{$(echo -n 
'\e[1;33m')%...@%f%m
> %F{green}%~%f$PS1VCS%F{%{$(echo -n '\e[1;33m')%}%%%f%b "
> 
> 
> And I get this in my calligra prompt:
> 9:53 cyri...@navis
> ~/Projects/kde4/src/calligra/krita/plugins/extensions/dockers
> (git)-[master]-%
> 
> (with some colors :) )
> 
> I am no user of bash, but here is an example of how to achieve the same
> result: http://glandium.org/blog/?p=170 .
The code in that link didn't quite work out for me, so here is what it looks 
like for me after I've worked on it (add it to .bashrc and make sure PS1 is 
not reset afterwards):

  local vcs base_dir sub_dir ref
  sub_dir() {
local sub_dir
sub_dir=$(readlink -f "${PWD}")
sub_dir=${sub_dir#$1}
echo ${sub_dir#/}
  }

 git_dir() {
base_dir=$(git rev-parse --show-toplevel 2>/dev/null) || return 1
sub_dir=/$(git rev-parse --show-prefix)
sub_dir=${sub_dir%/}
ref=$(git symbolic-ref -q HEAD || git name-rev --name-only HEAD 
2>/dev/null)
ref=${ref#refs/heads/}
vcs="git"
  }

 git_dir ||
 base_dir="$PWD"

 echo "${base_dir/$HOME/~}${vcs:+[$ref]${sub_dir}}"
}

PS1='${debian_chroot:+($debian_chroot)}...@\h:$(__vcs_dir)\$ '
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Braindump and calligra

[C. Boemann]

On Sunday 19 December 2010 18:58:58 Cyrille Berger Skott wrote:
> Hi,
> 
> I would like Braindump to be included in calligra. For those who don't know
> or have forgotten, Braindump is a rich notes taking application based on
> flake (better described in [2]). Its code is currently living in [1].
> 
> It is currently shipped stand alone. I had like to include it in calligra,
> for the following reasons:
> 
> * convenience, as flake's API change, braindump tends to lag behind, I also
> tend to forget to do releases after major koffice/calligra releases, making
> the lag even worse, and releasing translation is a bit painfull, I had
> rather do once for calligra, rahter than twice
> * increased potential user base, I don't think there are much packages of
> braindump, making it very invisible to users, being part of calligra would
> increase the visibility of braindump
> * I also think that braindump will gives value to calligra users, and would
> fit well in our current offering
> 
> With braindump, apart from the main applications, comes two shapes, a web
> shape (that basically embedd a web page in a document) and a state shape
> (that show checked/unchecked or progress).
> 
> So I would like to know what you guys thinks about having braindump inside
> calligra ? Any thoughts, or objections ?
> 
> 
> [1] http://gitweb.kde.org/scratch/berger/braindump.git
> [2] http://blog.cberger.net/2010/03/18/braindump-0-8-0-2/
It sounds like a good addition :)

Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: No application/vnd.oasis.opendocument.text-template?

[C. Boemann]

On Monday 27 December 2010 21:38:48 Jaroslaw Staniek wrote:
> Hi,
> Is it intentional not to have
> application/vnd.oasis.opendocument.text-template on the list of
> supported mimetypes in words.desktop?
Not to my knowledge
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Merge request of new tool docker

[C. Boemann]

Hi

I hereby request a merge of the all-tooldocker-boemann branch into master.

It introduces two new dockers, which are unrelated:
1) Tool options docker.
2) A docker that hijacks the tool bars

Plus it fixes the bug that dockers were left hidden when the application is 
closed while the startup widget is shown.

Tool options docker
-
It presents a single docker that contains the tool option widgets of the 
current tool.

The docker is fixed in size so we no longer have moving around of dockers when 
switching tool.

The docker can lay out the option widgets of the current tool in different 
ways.
 - horizontally when docked at the top or bottom of the window
 - vertically when docked at the sides of the window
 - in tabs if put into tab mode (behaves the same no matter where it's docked)

The docker default has no title bar, as the name of the option widgets serve 
as titles. If the user clikcs the unlock button in the top right corner. It 
gets a titlebar, and another button to toggle tabbed mode.

For an idea of how this is should look, try the text and default tools.

If the size f the option widgets is larger than can fit in the docker 
scrollbars will appear, so the docker never resizes itself.

The docker that steals tool bars
---
It basically just steals the tool bars and puts them in a docker. This allows 
the user to put the tool bars and other dockers side by side, giving greate 
flexibility of layout.

If the Tool Bar docker is hidden (via settings menu) then the tool bars are 
shown in their normal place.

Known issues

The Tool Options docker doesn't remember if it's in tabbed mode

The Tool Options docker has a repainting problem when going into tabbed mode.

The Toolbars can not be manipulated while in the Tool Bars Docker. You need to 
close the docker (bringer the dockers to their normal position) and then 
manipulate them.

Best regards
Casper Boemann
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Merge request of text layout restructuring

[C. Boemann]

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

Re: Merge request of new tool docker

[C. Boemann]

On Tuesday 04 January 2011 21:20:58 Thomas Pfeiffer wrote:
> > Hi,
> 
> This is the first time I can look at a calligra feature I helped shape from
> the early concept stage, so it's exciting to see it in action and discuss
> it
> 
> :)
> :
> > Found three other issues:
> > * if you close the tool docker, there is no way to get it back (short of
> > restarting the application)
> 
> This definitely needs to be fixed. There should be a menu entry to show it
> again.
I've made it not closable instead - like the tool box

> > * if there is only one tool widget, it should not show the lock/tab
> > button, and only show tool options, no group widget
> 
> Sounds like a good idea.
I'm not so sure. The docker is the container for various tool options. If the 
ability to switch mode depends on what tool is active, then the user will have 
to activate the right tool in order to unlock the docker. I think the user 
will get quite confused, and think the unlock is suddenly missing.

> > * File > close --> you get a "tool docker"
> > 
> > I am a bit uncovinced by the so call "tool bar docker", I understand the
> > idea, but then I would suggest to not give the choice to the user and to
> > always have it, make it movable and use a single line.
> > Right now it feels unnatural.
> 
> I agree. It should behave as much like other dockers as possible.
> Especially making it movable would be important for users who want to save
> vertical space and put it with other dockers next to the document.
> As for the number of lines: Couldn't it be made like the tools docker (i.e.
> it arranges the icons depending on the amount of horizontal/vertical space
> given)?
> Having it occupy two lines even when spread out over the whole width isn't
> good, that's for sure.
> Making it work like a normal docker would allow for maximum layout
> flexibility, which would be great.
Sure but what should the name be?
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Merge request of new tool docker

[C. Boemann]

On Wednesday 05 January 2011 09:42:10 Cyrille Berger Skott wrote:
> On Wednesday 05 January 2011, Thomas Pfeiffer wrote:
> > > > > * if there is only one tool widget, it should not show the lock/tab
> > > > > button, and only show tool options, no group widget
> > > > 
> > > > Sounds like a good idea.
> > > 
> > > I'm not so sure. The docker is the container for various tool options.
> > > If the ability to switch mode depends on what tool is active, then the
> > > user will have to activate the right tool in order to unlock the
> > > docker. I think the user will get quite confused, and think the unlock
> > > is suddenly missing.
> > 
> > Oh, yes, true. I got confused here. Thought there were whole applications
> > that  only used one-widget-tools, but that's not the case of course. I
> > agree that the behavior should not change between tools. But there still
> > should not be two titles if there is only one group. And the tab switch
> > does not make sense either, so it might be disabled (would be less
> > "jumpy" then showing/hiding it). But the lock switch should stay.
> 
> Fine with me. However, I am not quiet sure why this docker deserve a lock
> (more than the other ones), I wonder if the lock button and tab button
> should not be moved to the title bar.
uhm they are already in the titlebar (when the docker has one), or are you 
thinking of something else. Btw I really like you second idea of a menu 
instead, i'll experiment with that.



> > > > I agree. It should behave as much like other dockers as possible.
> > > > Especially making it movable would be important for users who want to
> > > > save vertical space and put it with other dockers next to the
> > > > document. As for the number of lines: Couldn't it be made like the
> > > > tools docker (i.e. it arranges the icons depending on the amount of
> > > > horizontal/vertical space given)?
> > > > Having it occupy two lines even when spread out over the whole width
> > > > isn't good, that's for sure.
> > > > Making it work like a normal docker would allow for maximum layout
> > > > flexibility, which would be great.
> > > 
> > > Sure but what should the name be?
> > 
> > Ah, yes, the titles... Why not Toolbar?
> 
> I wonder if it would not brings confusion with the "toolbox", also the
> toolbar hardly countains any tool, but only shortcuts. So maybe "shortcuts
> bar" ?
> 
> "shortcuts bar" might sound weird for krita since it has things that are
> not shortcuts in there (patterns/brush configuration...), but they might
> be moved to their own docker.
How about no title, but just a blank titlebar (except for the normal buttons)?
The menu action can still have different text afaik
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Missing signals

[C. Boemann]

I'm well aware of those connects, but would like to keep it, to remind me

On Sunday 09 January 2011 07:48:19 Thorsten Zachmann wrote:
> Hello all,
> 
> I have seen the following error messages when debugging something else. Can
> this connections be removed?
> 
> Object::connect: No such signal
> SimpleParagraphWidget::paragraphStyleSelected(KoParagraphStyle *) in
> /home/tz/develop/kde/git/calligra/plugins/textshape/TextTool.cpp:1600
> Object::connect:  (sender name:   'SimpleParagraphWidget')
> Object::connect:  (receiver name: 'TextToolFactory_ID')
> Object::connect: No such signal
> SimpleStylesWidget::paragraphStyleSelected(KoParagraphStyle *) in
> /home/tz/develop/kde/git/calligra/plugins/textshape/TextTool.cpp:1608
> Object::connect:  (sender name:   'simplestyleswidget')
> Object::connect:  (receiver name: 'TextToolFactory_ID')
> Object::connect: No such signal
> SimpleStylesWidget::characterStyleSelected(KoCharacterStyle *) in
> /home/tz/develop/kde/git/calligra/plugins/textshape/TextTool.cpp:1609
> Object::connect:  (sender name:   'simplestyleswidget')
> Object::connect:  (receiver name: 'TextToolFactory_ID')
> Object::connect: No such signal SimpleStylesWidget::doneWithFocus() in
> /home/tz/develop/kde/git/calligra/plugins/textshape/TextTool.cpp:1610
> Object::connect:  (sender name:   'simplestyleswidget')
> Object::connect:  (receiver name: 'TextToolFactory_ID')
> 
> It seems the signals have already been removed.
> 
> 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: Fwd: Will Calligra Suite join OpenDoc Society?

[C. Boemann]

On Wednesday 12 January 2011 10:19:40 Boudewijn Rempt wrote:
> Hi!
> 
> KOffice used to be a member of the Dutch OpenDoc society, and Calligra has
> just been invited. The cost is negligable at a very fair 0 euros for open
> source projects... And I would really like us to join! Any objections?
I would say it's a no-brainer that we should join.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.4 Release Plan

[C. Boemann]

On Wednesday 12 January 2011 16:41:55 Cyrille Berger Skott wrote:
> Hi,
> 
> Time to work on a release schedule for the first calligra release, aka 2.4
> (and not 1.0 :) ).
> 
> If we were to strictly follow our schedule, we would have schedule that
> looks like this: (with year+1, ie 2010->2011)
> 
> http://community.kde.org/Calligra/Schedules/KOffice/2.2/Release_Plan
> 
> Meaning we should have a soft-freeze tomorrow... :) Since KOffice 2.3 took
> much more time to be ready, I would be tempted to suggest to push a little
> bit the release of the RC1 to the end of May (giving us one more month).
> 
> So the real question is what do you guys prefers ? a RC1 at the end of
> april (actually right on my birthday ;P) or a RC1 at the end of May ?
For Words to be ready (and thus to be included in the release), it would need 
the extra month.

I really don't want to see Words released being the same old ¤%¤#" as KWord!
I want it to signal a change.

best regards
Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.4 Release Plan

[C. Boemann]

On Wednesday 12 January 2011 20:09:59 Boudewijn Rempt wrote:
> On Wednesday 12 January 2011, Cyrille Berger Skott wrote:
> > Hi,
> > 
> > Time to work on a release schedule for the first calligra release, aka
> > 2.4 (and not 1.0 :) ).
> > 
> > If we were to strictly follow our schedule, we would have schedule that
> > looks like this: (with year+1, ie 2010->2011)
> > 
> > http://community.kde.org/Calligra/Schedules/KOffice/2.2/Release_Plan
> > 
> > Meaning we should have a soft-freeze tomorrow... :) Since KOffice 2.3
> > took much more time to be ready, I would be tempted to suggest to push a
> > little bit the release of the RC1 to the end of May (giving us one more
> > month).
> > 
> > So the real question is what do you guys prefers ? a RC1 at the end of
> > april (actually right on my birthday ;P) or a RC1 at the end of May ?
> 
> With all the time the creation of calligra has eaten away from hacking
> time, I support another month as well. I'd even support two months, if
> that helps us make a real bang with the first calligra release.
Yeah, but I'm torn because we should also remember that the longe we go 
without releasing anything the longer it takes for us to establish ourselves

Right now we are nothing, to the outside world.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.4 Release Plan

[C. Boemann]

On Wednesday 12 January 2011 20:32:04 Boudewijn Rempt wrote:
> On Wednesday 12 January 2011, C. Boemann wrote:
> > On Wednesday 12 January 2011 20:09:59 Boudewijn Rempt wrote:
> > > On Wednesday 12 January 2011, Cyrille Berger Skott wrote:
> > > > Hi,
> > > > 
> > > > Time to work on a release schedule for the first calligra release,
> > > > aka 2.4 (and not 1.0 :) ).
> > > > 
> > > > If we were to strictly follow our schedule, we would have schedule
> > > > that looks like this: (with year+1, ie 2010->2011)
> > > > 
> > > > http://community.kde.org/Calligra/Schedules/KOffice/2.2/Release_Plan
> > > > 
> > > > Meaning we should have a soft-freeze tomorrow... :) Since KOffice 2.3
> > > > took much more time to be ready, I would be tempted to suggest to
> > > > push a little bit the release of the RC1 to the end of May (giving
> > > > us one more month).
> > > > 
> > > > So the real question is what do you guys prefers ? a RC1 at the end
> > > > of april (actually right on my birthday ;P) or a RC1 at the end of
> > > > May ?
> > > 
> > > With all the time the creation of calligra has eaten away from hacking
> > > time, I support another month as well. I'd even support two months, if
> > > that helps us make a real bang with the first calligra release.
> > 
> > Yeah, but I'm torn because we should also remember that the longe we go
> > without releasing anything the longer it takes for us to establish
> > ourselves
> > 
> > Right now we are nothing, to the outside world.
> 
> We could go with a really long and relaxed beta period :-)
could work, with a bit of enhanced publicity
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.4 Release Plan

[C. Boemann]

On Wednesday 12 January 2011 20:41:27 Boudewijn Rempt wrote:
> On Wednesday 12 January 2011, C. Boemann wrote:
> > On Wednesday 12 January 2011 20:32:04 Boudewijn Rempt wrote:
> > > We could go with a really long and relaxed beta period :-)
> > 
> > could work, with a bit of enhanced publicity
> 
> Another option could be to go to a fast & furious two month schedule to
> show the world the rapid progress. But we'd have to say every time "it
> cooler than it every was, but sorry, not good enough yet".
I'd prefer the longer beta period, but not too long.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.4 Release Plan

[C. Boemann]

On Thursday 13 January 2011 14:51:32 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?
by having a required-items-list rather than a date, and biweekly evaluations 
if we should remove some. It should be emphasized that we do not want to go on 
forever and that the list should be what is needed in order to be user ready. 
The required-items-list should not be confused with our feature list, which we 
will happily release even when not fulfilled.

So some apps like Krita may not have anything, and apps that don't want to be 
called feature ready in 2.4 could also omit filling out this required-items-
list.

I still think Words, Tables and Stage needs to be user ready before we 
release. And most of what is required here is user interface. but the exact 
list is up to the app to define.

best regards
Casper Boemann
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Don't show template selection ui any longer

[C. Boemann]

On Thursday 13 January 2011 23:40:25 Sebastian Sauer wrote:
> Hi,
> 
> please find attached a patch that disables the templates-dialog per default
> for Calligra words and tables. Stage is not changed since imho the default
> empty template doesn't really make sense for presentations.
> 
> What do you think? Good idea or not?
full support from my side
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Merge request of text layout restructuring

[C. Boemann]

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

Re: words - call for help

[C. Boemann]

On Friday 14 January 2011 14:29:42 brian larochelle 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
Hi brian, and no you are the first to show interest, so you are "hired"

the right place to look is:

caligra/plugins/textshape/dialogs/

Where you'll find:
SimpleStylesWidget.cpp // The two white  boxes you see in the docker
StylesWidget.cpp // the thing that pops up when you hover the white box
StylesModel.cpp 
StylesDelegate.cpp

You will not need to look elsewhere in the code

thanks
Casper Boemann
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Merge request of text layout restructuring

[C. Boemann]

On Friday 14 January 2011 14:40:55 Pierre Stirnweiss wrote:
> 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... ;)
Sure

btw the branch still exists, as it will be reused for the next steps
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: words - call for help

[C. Boemann]

You should come to irc channel #calligra 

my nick is boemann, but i'm not going to be much around before sunday night, 
as i need to help my mother move to a new apartment this weekend.

I will check in from time to time though, and maybe estan (the author of the 
blog) or some other dev will be able to give you a lending hand too. We are 
very friendly :)

best regards
Casper

On Friday 14 January 2011 14:54:51 brian larochelle wrote:
> thanks Casper/Pierre
> that is very helpful.  the world suddenly became much smaller and less
> scary
> 
> :)
> 
> i'll be poking around with this over the next few days.  hopefully with
> some results
> 
> On Fri, Jan 14, 2011 at 8:46 AM, C. Boemann  wrote:
> > On Friday 14 January 2011 14:29:42 brian larochelle 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
> > 
> > Hi brian, and no you are the first to show interest, so you are "hired"
> > 
> > the right place to look is:
> > 
> > caligra/plugins/textshape/dialogs/
> > 
> > Where you'll find:
> > SimpleStylesWidget.cpp // The two white  boxes you see in the docker
> > StylesWidget.cpp // the thing that pops up when you hover the white box
> > StylesModel.cpp
> > StylesDelegate.cpp
> > 
> > You will not need to look elsewhere in the code
> > 
> > thanks
> > Casper Boemann
> > ___
> > 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: Flake tools at the bottom of the toolbox

[C. Boemann]

On Tuesday 18 January 2011, Sven Langkamp wrote:
> We should think about the possibility to remove some of the flake tools.
> At the moment we have two tools for gradient, path and freehand.
Combining gradient,pattern tools to one, and combining path and freehand tools 
is very much on my wishlist.

As for placing the krita tools on top, doesn't seem anymore inconsistent than 
placing them on the bottom.  The other apps don't have those tools so how can 
it be inconsistent.

I too would like to see some change to the toolbox. In kword I try to use it 
as a kind of mode switcher. Write tool (for basic writing and formating), a 
(yet unimplemented) review tool handling spell checking, change tracking and 
statistics.
 
best regards
Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Cleaning up the paint API of KoShape

[C. Boemann]

On Sunday 23 January 2011 18:02:53 ja...@gmx.net wrote:
> On Sunday 23 January 2011 15:36:15 Inge Wallin wrote:
> > There is a big wart on the KoShape API and that is the one for painting.
> > 
> > Currently we have these two functions:
> >  virtual void paint(QPainter &painter, const KoViewConverter &converter)
> >  =
> > 
> > 0; virtual void paintDecorations(QPainter &painter,
> > 
> >   const KoViewConverter &converter,
> >   const KoCanvasBase *canvas);
> > 
> > The biggest problem is the KoViewConverter parameter.  There is no reason
> > why this should be necessary. It should be the responsibility of the
> > calling code to set up the painter so that the shape itself can just
> > paint from (0, 0) to size() and that's it (if we for the moment ignore
> > painting outside the shape).
> 
> I fully support the idea to clean up the painting API. It would even be
> applicable to how tools are painting, as they do essentially similar things
> in their paint routine.
> If I recall correctly I even once started something similar, e.g. applying
> the zoom only once when setting up the painter. But what we still need to
> consider is that we sometimes need to know the zooming factors when
> painting. For instance when painting handles which should have the same
> size, independent from the actual zoom, you need to know the scaling to
> compensate for when painting.
> So I think what would be a prerequisite is to closely check all the shapes
> and their painting routines to come up with a list of required data which
> needs to be passed to the painting routine.
> 
> > Now we are forced to do things like
> > 
> >  painter.fillRect(converter.normalToView(QRectF(QPointF(0.0,0.0),
> >  size())),
> > 
> > background());
> > 
> > This is actually the way that is documented in the apidox.
> > 
> > The other problem is that having a separate paintDecorations() method can
> > potentially introduce inefficiencies. My suggestion would instead be to
> > introduce a new parameter to KoShape::paint(): PaintMode.  This could be
> > an enum with the values { paintContentsOnly, paintDecorationsOnly,
> > paintAll}, and maybe in the future more values. I can also imagine it as
> > a bitmap with Contents and Decorations as bits. I'm open to suggestions
> > here.
> > 
> > So the resulting API would become:
> >  typedef enum {
> >  
> >paintContentsOnly,
> >paintDecorationsOnly,
> >paintAll
> >  
> >  } ShapePaintMode;
> >  
> >  virtual void paint(QPainter &painter, ShapePaintMode paintMode) = 0;
> >  
> >  ...or the alternative definition of ShapePaintMode.
> 
> Why not create a class KoShapePaintingContext (just like we have
> KoShapeLoadingContext, KoShapeSavingContext, etc.) ? That object one can be
> passed as the only parameter, providing access to the painter, paint mode
> and other data/methods (canvas, KoToolBase::handlePaintRect, etc) we might
> need (see above).
+1
and a forprint boolean in there, rather than say only pain decorations. Let's 
just give the paint method the info it needs to paint what it want without 
actually telling it what to paint.

> > If this is ok with the rest of you, I am willing to do the work.  My
> > suggestion for the workflow to create as few interruptions as possible
> > would be the following. I discussed this with Casper.
> > 
> > 1. * Rename the current KoShape::paint() as KoShape::paintOld() and mark
> > that as deprecated.
> > 
> >* Change all the places that call KoShape::paint() to instead call
> > 
> > paintOld().
> > 
> >* At the same time, define a new KoShape::paint() with the new
> >signature
> > 
> > as defined above and create empty implementations in all shapes.
> > 
> >* At the same time mark KoShape::paintDecorations() as deprecated.
> >Step 1 is done in a branch, and should be possible to complete fairly
> > 
> > quickly, in under a day at least.
> > 
> > 2. Put the result of step 1 up for review and commit it.
> > 
> > 3. Work in another branch (or perhaps the same) to implement the new
> > paint() methods in all shapes.
> > 
> > 4. Put this up for review and commit it.
> > 
> > 5. Fix all the places in the code that call the paintOld() and
> > paintDecoration() methods to instead use the new API.  This will probably
> > take a bit longer and this can be merged with master also during the
> > work, possibly after review(s).
> > 
> > 6. Remove paintOld() and paintDecorations() from KoShape and all
> > implementations from shapes.
> > 
> > Done.
> 
> I am not sure why you would commit the intermediate steps. I think it would
> be better to just let them be reviewed and then carry on with the next
> step in the branch. Merge back to master once all steps are reviewed and
> complete
Hmm I'me actually changing my mind and thinking it would be okay to do it all 
and then merge. But the original idea was to get the dependent work out there 
as soon as possible. Thinking about that though, I se

Re: Review Request: Moving anchor strategy into text shape

[C. Boemann]

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. Well totally controlled by the textshape. This abstraction will allow 
any application to gain layout and painting. 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.

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 >f/1/?file=7551#file7551line56> (Diff
> > 
> > revision 1)
> > 
> > class ToCGenerator;
> > 
> >56
> >
> > ~Layout();
> >   
> >   the destructor should be marked virtual
> >   
> >plugins/textshape/TextAnchorStrategy.h >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 >g/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 >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/KoTextShapeC

Re: Review Request: Moving anchor strategy into text shape

[C. Boemann]

On Thursday 27 January 2011 11:15:22 Pierre Stirnweiss wrote:
> 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
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

Re: Review Request: Moving anchor strategy into text shape

[C. Boemann]

On Thursday 27 January 2011 11:49:40 Pierre Stirnweiss wrote:
> > 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
But do you really see this as a realistic use case? I mean yes one might want 
that , but rarely without wanting the full blown layout too.

Anyway there will not be that much interaction between the layout and loading. 
So I guess we could make it into a separate text-layout library. But first I 
would like a usecase of someone not wanting the full blown layout after having 
loaded everything into a library that loads all sorts of formatting 
information.
> 
> > 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

Interactive stuff on canvas. Was: spreadsheets with control thingies

[C. Boemann]

Hi

This is actually a variation of an issue that has come up several times over 
the years

Be it buttons to control videoplayback, buttons to delete a note/annotation, 
radiobuttons to control the content of spreadsheets.

The common thing here is that the buttons are sor of part of the content, and 
not some control associated with a specific flake-tool.

How do we best handle this stuff without messing too much with our flake 
philosophy?

Camilla

On Friday 04 July 2014 09:35:44 René J.V. Bertin wrote:
> Hi,
> 
> Someone send me a spreadsheet (.xlsx) containing a very simple set of
> controls (radio buttons) that calligrasheets failed to show (but
> LibreOffice did just well enough so I could fill in the thing).
> 
> Is this something being worked on/planned and/or should I upload the file on
> the bug tracker?
> 
> R.

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Sad news

[C. Boemann]

On Wednesday 27 August 2014 00:04:43 Mehrdad Momeny wrote:
> Hi Calligra developers,
> I hope you are all fine.
> 
> I guess some of you should know Mojtaba Shahi, He was working on some parts
> of Calligra as I know. I have a really sad news for those of you, it's yet
> unbelievable for myself.
> Mojtaba has passed away some days ago due to a brain stroke.
> Today was his burial in his hometown, Mashhad.
> 
> May his soul rest in peace now.
> 
> Regards,
> Mehrdad Momeny
> 
> PS: He and his family were a life long friends to me and my family.
Oh no

That is terrible news. I worked with him quite a lot over the Internet, 
initially being a sort of mentor for him, watching how his English and coding 
skills grew steadily to the point where he contributed so enormously to 
Calligra. For example the comment functionality was all his doing. And we 
talked about all kinds of stuff so he was not only a great coder but also a 
great part of the Calligra society. I am deeply saddened and it's only a small 
consolation that Calligra will always carry a bit of his legacy.

Please convey my most heartfelt condolences to his family and friends. I know 
he will rest in peace - He was such a good person.

Yours truly
Camilla Boemann
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: How to get all characters on a page in Words and their position

[C. Boemann]

On Tuesday 30 September 2014 08:04:44 Pierre wrote:
> 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_1
> > Text 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
correct - except the qtextdocument you get can span several pages, so for each 
textshape you need to use its KoTextLayoutArea and parse down through it 
(which isn't straight forward as in the text ABCD you can find that A and D is 
on your page but B and C might be on the previous page
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Words - how to add a way for users to change page styles ?

[C. Boemann]

On Monday 20 October 2014 00:35:47 Pierre wrote:
> 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
there was some Toulouse student work done in the words-pagelayout-toulouse 
branch

it features a page layout tool which is supposed to offer direct manipulation 
of page layout

I agree nither the LibreOffice nor MS-Word interfaces are shining examples of 
good ui
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: How to deal with typo "2" instead of "2.1" for "GNU Lesser General Public" in headers?

[C. Boemann]

I'm normally really cautious about such changes but yes since 2.0 doesn't 
exist I'd say it's a no-brainer  that it's just a typo. I for one might have 
made that typo many times myself

so please go ahead

 On Sunday 04 January 2015 19:18:10 Boudewijn Rempt wrote:
> On Sun, 4 Jan 2015, Friedrich W. H. Kossebau wrote:
> > can it be assumed (and should we) that all contributors actually agreed to
> > the "2.1" version of the "Lesser" given there is no "2" version?
> 
> Yes.
> 
> > Especially as at least all files I checked also contain "or (at your
> > option) any later version.", where "2.1" would be a theoretical later
> > version of "2"?
> > 
> > To be on the really safe side I guess one would need to get all
> > contributors explicitely agree to the correct version. But pragmatically
> > I would just assume people very much were in agreement with 2.1, and this
> > can be considered just a typo.
> > 
> > So would anyone strongly advise against simply applying a patch to all
> > those license headers and change the "2" to "2.1"?
> 
> Not me.
> 
> Boud
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: KoPathShape saveOdf and loadOdf oddities

[C. Boemann]

On Saturday 17 January 2015 09:58:28 Stefano Bonicatti wrote:
> Hello, we have a problem in Krita with drawing a polygon or a bezier curve
> (or basicly anything that uses KoPathShape) in a vector layer, then
> transform it so that the lines increase their thickness, then save the file
> in .kra format and then reload it: the thickness is not kept.
> I've found that this is because loadOdf does something different than
> saveOdf when loading and i don't get why.
> First it only loads some attributes back, then it checks for some specific
> element names (and in my tests i never entered in those ifs), then the
> transformation matrix is baked into the viewbox and the path geometry only,
> while the stroke is kept unchanged.
> This is wrong though because the original transformation, before saving,
> changed also the stroke thickness.
> Why baking the matrix into the path geometry only? Why loadOdf doesn't just
> do the "opposite" of what saveOdf do?
> 
> I tried replicating what saveOdf does writing simply this:
> 
> Q_D(KoPathShape);
> loadOdfAttributes(element, context, OdfAllAttributes | OdfViewbox);
> KoPathShapeLoader loader(this);
> loader.parseSvg(element.attributeNS(KoXmlNS::svg, "d"), true);
> d->loadNodeTypes(element);
> loadOdfAttributes(element, context, OdfCommonChildElements);
> loadText(element, context);
> 
> as a replacement for loadOdf and it works as expected.
> Though not being 100% that this doesn't give problems somewhere else, i'm
> writing here for clues.
I tried: creating - increasing thickness - save as odf then load it back. In 
words the thickness is preserved - so i don't think it's as bad as you say. 
However the line ending is not preserved

maybe it's part of the same issue - but i would be very cautious of changing 
the loadOdf - iirc it was fine tuned to load files created by other applications

still something fishy is going on so i would think it more likely that we need 
to change the save method

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Merge window before the port starts

[C. Boemann]

On Sunday 25 January 2015 11:59:39 Inge Wallin wrote:
> Hi,
> 
> As you have probably seen I have two patches that I deem mature on the
> review board right now. These are branches that have been Ok'ed and are
> ready to merge. And I know that there are others with similar branches
> laying around. It would be a pity to let them bitrot more than necessary.
> 
> I talked with Cyrille on IRC and he suggested that we open a merge window
> just before the port starts.  The merge window should be very short (1-2
> days only) and only for patches and branches that are:
>  - Well tested and reviewed
>  - Finished in some sense - no work in progress
> 
> He asked me to propose this on the ML, which I hereby do, and to forward his
> support for the idea.
> 
> I, myself, see no reason why we cannot open master for patches of this type
> already now, but I will let you decide whether opening master now or wait
> for a merge window is the best way forward.
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel


I support this idea, but only in order to save work that would otherwise be 
lost due to bit rot. So it should not be a free for all to put in some new 
features. If the work you have laying around can easily be saved after the 
porting then I think it's better to wait until 3.1 (I hope 3.0 should be the 
shortest release cycle ever, so 3.1 will not be far behind)

For 2 reasons  i think we shouldn't open up already:
 - it is a save-your-work kind of window
 - the longer we wait the more time people will have to polish their saved wor 
for better quality.

That said i'm not opposed to a 1 day window already if people have finished 
work.

I also think we should have people list right now what work they want to save 
and what the status of said work is so we know how much we are talking about.

best regards
Camilla

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: Merge window before the port starts

[C. Boemann]

On Sunday 25 January 2015 14:26:01 Inge Wallin wrote:
> So let's have a short window before the porting starts then.
> 
Could people please reply with what stuff they would like in at that point.

For my own part I have nothing.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

RE: 2.9 final release date

[C. Boemann]

+1

-Original Message-
From: calligra-devel-boun...@kde.org [mailto:calligra-devel-boun...@kde.org]
On Behalf Of Boudewijn Rempt
Sent: Tuesday, February 3, 2015 9:57
To: calligra-devel@kde.org
Subject: 2.9 final release date

Hi,

While there are still about 150 open bugs for Krita, my feeling is that
we're getting ready for a 2.9.0. There has been some nice work on Kexi,
Words and Sheets as well.

We have one last beta planned for February 12th (tagging 8th), so I would
like to propose to have release 2.9.0 pretty soon afterwards:

tagging: February 22nd
release: February 26th

After that, I propose a new 2.9 release every month.

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: What to do with "kword" bugs at bugzilla?

[C. Boemann]

On Thursday 05 February 2015 00:08:23 Christoph Feck wrote:
> Hi,
> 
> currently there are over 100 open bugs/suggestions for kword. Does
> someone from the Calligra Words team volunteer to check which of them
> applies to Calligra? If not, I can close them as "unmaintained", and
> ask reporters to add a comment, if they still apply.
> 
> Please keep me in CC, because I am not subscribed to either of the
> office lists.
> 
> Christoph Feck (kdepepo)
> KDE BugSquad
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
No, we duplicated all the old kword bugs to calligra when we forked the code. 
And since then we have sort of dropped kword and build a new app called words. 
Sure it has inheited some, but only about 20% is original kword ccode, so it 
doesn't make sense for us to go through kword bugs

best regards
Camilla Boemann
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: [Kexi-devel] RFC: plan for starting the Qt5/KF5 port

[C. Boemann]

On Wednesday 25 February 2015 10:01:16 Boudewijn Rempt wrote:
> > Applying full astyle is IMHO not OK, and even against efforts of
> > everyone who keeps eye on proper coding style while doing code
> > reviews.
> 
> Sorry, our current code base is a mess. I don't care about kexi, and I 
> won't touch kexi. I won't touch any library except for pigment. But the 
> mess we have with bracket placing, include styles, spaces around function 
> arguments, initializer lists... It just needs cleaning up.
I'm not against cleaning up coding style, but any such commit should follow 
what we are practicing already, and not some half broken astyle. I have no 
idea what astyle does and doesn't do, but i will not accept commits away from 
our qt/kde style.

so show me that it doesn't mess up please


___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: Re: [Kexi-devel] RFC: plan for starting the Qt5/KF5 port

[C. Boemann]

On Wednesday 25 February 2015 10:18:19 Boudewijn Rempt wrote:
> On Wed, 25 Feb 2015, C. Boemann wrote:
> > On Wednesday 25 February 2015 10:01:16 Boudewijn Rempt wrote:
> >> > Applying full astyle is IMHO not OK, and even against efforts of
> >> > everyone who keeps eye on proper coding style while doing code
> >> > reviews.
> >> 
> >> Sorry, our current code base is a mess. I don't care about kexi, and I
> >> won't touch kexi. I won't touch any library except for pigment. But the
> >> mess we have with bracket placing, include styles, spaces around function
> >> arguments, initializer lists... It just needs cleaning up.
> > 
> > I'm not against cleaning up coding style, but any such commit should
> > follow
> > what we are practicing already, and not some half broken astyle. I have no
> > idea what astyle does and doesn't do, but i will not accept commits away
> > from our qt/kde style.
> > 
> > so show me that it doesn't mess up please
> 
> Check David's notes in kde-dev-scripts, please. That's what I was
> referring to. And sure I'll be careful.
Okay , I've read up on those, and on the astyle documentation. If astyle does 
what it intends then it looks nice and i would support running it. I have no 
issue with the history, it will be messed up anyway

Also didn't we talk about renaming classes as well?
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: RFC: plan for starting the Qt5/KF5 port

[C. Boemann]

On Friday 27 February 2015 01:21:56 Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 25. Februar 2015, 15:41:33 schrieb Boudewijn Rempt:
> > On Wed, 25 Feb 2015, Dmitry Kazakov wrote:
> > > Hi!
> > > 
> > > My 2 cents :)
> > > 
> > > 1) astyle
> > > 
> > > Last time astyle was applied to Krita code (something around 2010-2011,
> > > it
> > > was applied partially?) I really didn't like the result. At least the
> > > thing it did with braces and indentation. I guess we just need to choose
> > > really carefully what to change and what not. E.g.
> > > one-line-return-if-error ifs might not have braces. That is I don't
> > > agree
> > > that the policy statement "Use curly braces even when the body of a
> > > conditional statement contains only one line" should be followed
> > > blindly.
> > > 
> > > For the rest, e.g. include style, tab vs spaces, lines with trailing
> > > whitespace I'm ok with fixing it automatically.
> > > 
> > > 2) If astyle applied, it must be applied to master-only. Under no
> > > circumstances to calligra/2.9. Without being able to use 'git blame'
> > > it'll be tough to fix many kinds of bugs and do bisecting.
> > 
> > Okay.
> 
> If not using astyle on calligra/2.9, then it should be better only applied
> at the end of the porting, close to 3.0 release, to not complicate forward
> porting of commits to calligra/2.9. Would you agree?
> Perhaps also even only after 3.0, during 3.1, when the chances are even
> lower that stuff needs to be forward ported from 2.9.
> 
> So okay if I move that item to a section "Stuff to be done after the port"?
> 
> Cheers
> Friedrich
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel

I say it should be done now, and be done to 2.9 too

And I almost don't think maintainers should be able to say no. The long term 
goal of having a clean codebase is more important than short term issue with 
git blame (have a separate permanent checkout before this revision where you 
can run git blame)

After all maintainers and developers come and go. It's important all of our 
codebase is as easy and consistent to look at as possible - and yeah i know 
that is an argument for keeping easy history too - sigh

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Preview of astyle-kdelibs changes up in a branch (was: Re: [Port blocker] Re: [Kexi-devel] RFC: plan for starting the Qt5/KF5 port)

[C. Boemann]

On Wednesday 04 March 2015 12:23:41 Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 4. März 2015, 00:10:28 schrieb Friedrich W. H. Kossebau:
> > Am Dienstag, 3. März 2015, 23:37:02 schrieb Jaroslaw Staniek:
> > > First let's verify if astyle-kdelibs changes only whitespace.
> > 
> > Okay, I propose that we wait with the porting start until this got sorted
> > out.
> > 
> > No pressing need to really start porting today, 2-3 more days don't hurt
> > here, and there are enough bugs to fix for 2.9. Better have all
> > maintainers
> > aligned in the goals.
> > Most people have more time only at the WE anyway :)
> > 
> > Kicked off a qt5 build for the night to hopefully get that "normalize"
> > tool, might give a diff some testing tomorrow afternoon.
> 
> I found meanwhile that the normalize tool can be compiled on its own, is not
> part of the actual Qt build. So I did, and with the patched astyle ran
> astyle- kdelibs on this morning's Calligra master.
> 
> Please see the result committed as branch for preview to the central repo,
> with 3rd-party, libs/{db,koreport,koproperty}, plugins/reporting not
> touched, (because either going to be removed or 3rd-party):
> 
> astyle-kdelibs-result-2015-03-04-kossebau
> 
> Would those changes work for everyone? Please give feedback as quickly as
> possible, so you are heard.
> (The branch will be deleted later on, just used for convenience to have
> everyone see the possible changes.)
> 
> Cheers
> Friedrich
> 

Fully support it!
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

RE: Does it ever load?

[C. Boemann]

It probably doesn't load if it has been stuck that long - feel free to mail me 
the file privately if you want me to take a look and possibly fix it

-Original Message-
From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of John 
Culleton
Sent: Wednesday, March 4, 2015 13:56
To: Calligra Suite developers and users mailing list
Subject: Does it ever load?

I am just starting with Calligra Word. I use Slackware Linux 14.1 which hasn't 
been updated in a while. I am trying to load a MSWord doc file that takes a 
long time to load into Libre Writer.
But with Calligra Word it seems to be an asymtotic function i.e. never quite 
getting there. I could eat breakfast and have a second cup of coffee. Right now 
it is stuck at 43% loaded. I'll write again if/when it loads.

--
John Culleton
Wexford Press
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html
Updated PDF e-book: "Create Book Covers with Scribus 1.4.5" coming soon at 
http://www.booklocker.com/!
___
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: Preview of astyle-kdelibs changes up in a branch (was: Re: [Port blocker] Re: [Kexi-devel] RFC: plan for starting the Qt5/KF5 port)

[C. Boemann]

On Thursday 05 March 2015 02:56:11 Friedrich W. H. Kossebau wrote:
> * also patched with astyle_comma.diff (not part of provided spec.diff)

so what does that patch do - what should we look for
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: Preview of astyle-kdelibs changes up in a branch (was: Re: [Port blocker] Re: [Kexi-devel] RFC: plan for starting the Qt5/KF5 port)

[C. Boemann]

On Thursday 05 March 2015 02:56:11 Friedrich W. H. Kossebau wrote:
> Am Mittwoch, 4. März 2015, 12:42:59 schrieb Boudewijn Rempt:
> > Here's a scratchpad to note problems that might have to be solved:
> > 
> > https://docs.google.com/document/d/1jhq6oXuXKvTilJhcoS6FVKO7yYRu2yCgBS9ojh
> > c2 QRU/edit?usp=sharing
> 
> And here another preview version, that
> * excludes more generated files or external libs
> * used astyle also patched for forEachElement
> * also patched with astyle_comma.diff (not part of provided spec.diff)
> 
> branch astyle-kdelibs-result-2015-03-05-kossebau
> 
> Please give that another check (e.g. for generated files/imported libs that
> should not be touched), and update the scratchpad with your notes.
> 
As i already like the previous results this is just an improvement afaict.

However, as a pure enhancement, do you know how difficult it would be to 
reformat all ctor initialize statements to be like:

class::class()
: super()
, member(val)
{

I know it would require a patch, just wondering how much work it would be. If 
you don't want to spend time on it we can keep it as it is - but we have like 
3 different styles in use so it would be nice to clear it up too,

Please :)
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: RE: Does it ever load?

[C. Boemann]

I got the document and it loaded in 3 seconds - so don't really know what it 
was about 


On Thursday 05 March 2015 22:29:48 matus uzak wrote:
> Hey, anything special about the document?  Or a deadlock in the layout
> engine? :)
> 
> On Mar 4, 2015 3:04 PM, "C. Boemann"  wrote:
> > It probably doesn't load if it has been stuck that long - feel free to
> > mail me the file privately if you want me to take a look and possibly fix
> > it
> > 
> > -Original Message-
> > From: calligra-devel [mailto:calligra-devel-boun...@kde.org] On Behalf Of
> > John Culleton
> > Sent: Wednesday, March 4, 2015 13:56
> > To: Calligra Suite developers and users mailing list
> > Subject: Does it ever load?
> > 
> > I am just starting with Calligra Word. I use Slackware Linux 14.1 which
> > hasn't been updated in a while. I am trying to load a MSWord doc file that
> > takes a long time to load into Libre Writer.
> > But with Calligra Word it seems to be an asymtotic function i.e. never
> > quite getting there. I could eat breakfast and have a second cup of
> > coffee.
> > Right now it is stuck at 43% loaded. I'll write again if/when it loads.
> > 
> > --
> > John Culleton
> > Wexford Press
> > Free list of books for self-publishers:
> > http://wexfordpress.net/shortlist.html
> > Updated PDF e-book: "Create Book Covers with Scribus 1.4.5" coming soon at
> > http://www.booklocker.com/!
> > ___
> > 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

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: Proposal: standardized (subdir) names for 3rdparty/generated code

[C. Boemann]

> filters/words/msword-odf/wv2
> from what I heard this can be considered a fork already.
> but for now I would still treat it as 3rdparty lib,
> until the further fate of this lib has been discussed
> -> filters/words/msword-odf/3rdparty/wv2
it's very much a fork or rather a takeover and will remain so, so please don't 
mark it as 3rdparty and please do reformat it

thanks for your efforts
Camilla
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Calligra Icons

[C. Boemann]

On Monday 27 July 2015 00:51:55 Ken Vermette wrote:
> 'Ello Calligra devs;
> 
> This is Ken Vermette from the VDG.
> 
> We're working to better round out application icons for the upcoming 5.4
> release, and we've produced two sets of icons for Calligra applications.
> One set is "libre-like" in being colour-coded. The next set is a more
> traditional set of icons with a uniquely drawn image for each application.
> Here's some links to the two versions as they are now;
> 
> https://share.kde.org/index.php/s/xgusKHJAjt5OIyW
> https://share.kde.org/index.php/s/QKBBJJxskII2J4i
> 
> (Icons in order are Karbon, Flow, Author, Braindump, Sheets, Plan,
> Plan(work), Words, Kexi, and Stage for both images)
> 
> We'd like to get your feedback for which version is preferred, and any
> feedback for the preferred version or specific icons. We currently have the
> more traditional set in master, though we can easily switch. If opinions
> are split the VDG seems to be leaning towards the traditional set.
> 
> The artwork freeze is the 6th, so if I could have any feedback before the
> end of the month it would be greatly appreciated so I can make changes and
> ensure the repos are updated. I can also outright replace some icons if you
> tell me what is needed in the next few days. I apologise for the hasty
> timeline. :/
> 
> Thank you, great work on Calligra!
>  - Ken
I'd prefer to not change our application icons at all - I'm sorry but I find 
you new ones very anonymous and I would prefer if we keep our current ones
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Increasing Calligra minimum CMake version required

[C. Boemann]

On Sunday 16 August 2015 16:30:31 Stefano Bonicatti wrote:
> Hello, would it be a big issue to increase the minimum CMake version
> required from 2.8.0 to at least 2.8.12 or even 3.0?
> We have a little issue in Krita where using
> add_definitions(${KDE4_ENABLE_EXCEPTIONS}) gives an error when compiling it
> on Windows and VS2013.
> The problem is that the compiler flags contained in that variable spills
> into the rc compiler flags, and those are invalid for that compiler, so the
> compilation fails.
> Moreover add_definitions should be used only for defines not to add
> compiling flags but add_compile_options should be used, which is though
> available only from 2.8.12 and up.
> 
> As far as i know "all" maybe except CentOS, should have at least that
> version (for instance Debian stable has 3.0.2 already).
> The only real issue would be with packagers that want to compile latest
> Krita in older distros (what i don't know though is if they already have
> issues with other stuff, so that it's safe to update because no
> "regression" can happen).
> 
> I won't lie to you, this issue can also be solved by just setting
> CMAKE_CXX_FLAGS but this is a bit a dirty way to do it and it might get
> deprecated (shown by the fact that they're adding specific macros to add
> flags etc).
> Moreover do we really still have people testing the builds with CMake 2.8.0?
fine with me but not more than 3.0.2

Camilla
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: [calligra/calligra/2.9] libs/flake: Update tooltips to include keyboard shortcut.

[C. Boemann]

Yeah well it is used as a label in words, stage, sheets and flow, so adding 
extra text makes it spill over and possibly even becoming unreadable (depends 
on the tool obviously). Also 

and by asap I mean before the next release  - sorry if that came out a bit 
harsh.

But just because krita has a feature request doesn't mean we should 
short circuit the review process. If phabricator can't send to all of calligra 
then we must use reviewboard instead.

On Wednesday 19 August 2015 12:37:16 you wrote:
> Hi Camilla,
> 
> Before we "ASAP" revert or make it conditional, I'd like to know _what_ the
> problem is you see with this patch. And it's a bit difficult right now who
> to add individually to review request on Phabricator, but Friedrich was
> also cc'ed on the change.
> 
> Anyway, since this patch delivers a feature users have been asking for since
> 2006 or so, asking for an immediate revert without explaining what the
> problem is goes way too far.
> 
> On Wed, 19 Aug 2015, C. Boemann wrote:
> > please revert or make it conditional for krita only ASAP
> > 
> > And in the future please add the rest of calligra as reviewers on commits
> > to shared areas
> > 
> > Camilla Boemann
> > 
> > On Tuesday 18 August 2015 17:45:58 Michael Abrahams wrote:
> >> Git commit 8a450ef60839cf77486d1bb9eb25b63ffcb1e468 by Michael 
Abrahams.
> >> Committed on 18/08/2015 at 17:45.
> >> Pushed by abrahams into branch 'calligra/2.9'.
> >> 
> >> Update tooltips to include keyboard shortcut.
> >> 
> >> Summary:
> >> Tooltips will automatically change with changes to shorcuts.
> >> 
> >> Ref T199
> >> BUG: 348626
> >> 
> >> Reviewers: dkazakov, rempt
> >> 
> >> Maniphest Tasks: T199
> >> 
> >> Differential Revision: https://phabricator.kde.org/D245
> >> 
> >> M  +9-4libs/flake/KoToolManager.cpp
> >> M  +1-1libs/flake/KoToolManager.h
> >> M  +41   -9libs/flake/KoToolManager_p.cpp
> >> M  +9-2libs/flake/KoToolManager_p.h
> >> 
> >> http://commits.kde.org/calligra/8a450ef60839cf77486d1bb9eb25b63ffcb1e468
> >> 
> >> diff --git a/libs/flake/KoToolManager.cpp b/libs/flake/KoToolManager.cpp
> >> index 61e194c..16f817f 100644
> >> --- a/libs/flake/KoToolManager.cpp
> >> +++ b/libs/flake/KoToolManager.cpp
> >> @@ -788,19 +788,24 @@ void KoToolManager::registerTools(KActionCollection
> >> *ac, KoCanvasController *con return;
> >> 
> >>  }
> >> 
> >> +// Actions available during the use of individual tools
> >> 
> >>  CanvasData *cd = d->canvasses.value(controller).first();
> >>  foreach(KoToolBase *tool, cd->allTools) {
> >>  
> >>  QHash actions = tool->actions();
> >> 
> >> -QHash::const_iterator
> >> it(actions.constBegin());
> >> -for (; it != actions.constEnd(); ++it) {
> >> -if (!ac->action(it.key()))
> >> -ac->addAction(it.key(), it.value());
> >> +QHash::const_iterator
> >> action(actions.constBegin()); +for (; action !=
> >> actions.constEnd();
> >> ++action) {
> >> +if (!ac->action(action.key()))
> >> +ac->addAction(action.key(), action.value());
> >> 
> >>  }
> >>  
> >>  }
> >> 
> >> +
> >> +// Actions used to switch tools; connect slot to keep button
> >> tooltips
> >> updated foreach(ToolHelper * th, d->tools) {
> >> 
> >>  ToolAction* action = new ToolAction(this, th->id(),
> >>  th->toolTip(),
> >> 
> >> ac); action->setShortcut(th->shortcut());
> >> 
> >>  ac->addAction(th->id(), action);
> >> 
> >> +th->setAction(action);
> >> +connect(action, SIGNAL(changed()), th, SLOT(actionUpdated()));
> >> 
> >>  }
> >>  
> >>  }
> >> 
> >> diff --git a/libs/flake/KoToolManager.h b/libs/flake/KoToolManager.h
> >> index 6567346..fa12272 100644
> >> --- a/libs/flake/KoToolManager.h
> >> +++ b/libs/flake/KoToolManager.h
> >> @@ -44,7 +44,7 @@ class QCursor;
> >> 
> >>  /// Struct for the createToolList return type.
> >>  struct KoToolButton {
> >> 
> >> -QToolButton *button;///< a newly create

Re: Re: Re: [calligra/calligra/2.9] libs/flake: Update tooltips to include keyboard shortcut.

[C. Boemann]

On Wednesday 19 August 2015 20:19:10 Boudewijn Rempt wrote:
> On Wed, 19 Aug 2015, C. Boemann wrote:
> > Yeah well it is used as a label in words, stage, sheets and flow, so
> > adding
> > extra text makes it spill over and possibly even becoming unreadable
> > (depends on the tool obviously). Also
> 
> The text added is the shortcut, so it depends on that, not generic "text".
> But I guess that this isn't so useful for modebox apps. Though a tooltip
> that shows the shortcut should be useful even for those. If there aren't
> shortcuts, there isn't extra text anyway.
Yeah it's a hack to reuse the tool tip text as label text.


> I'll a check on
> qApp->applicationName when I'm back in Linux...
Thanks


> > and by asap I mean before the next release  - sorry if that came out a bit
> > harsh.
> > 
> > But just because krita has a feature request doesn't mean we should
> > short circuit the review process. If phabricator can't send to all of
> > calligra then we must use reviewboard instead.
> 
> Well, one can add calligra-devel as a cc' to the diff, which should help.
great that should cover it
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Let's use 3.0 only for next real release (was: Re: After 2.9.7)

[C. Boemann]

+ 1

On Thursday 27 August 2015 14:22:19 Friedrich W. H. Kossebau wrote:
> Hi,
> 
> Am Donnerstag, 27. August 2015, 09:57:32 schrieb Boudewijn Rempt:
> > I think that the frameworks branch is now ready to be called 3.0. It's
> > obviously not ready to release to end users, but we should make it the
> > new master. But let's call it the frameworks branch for now.
> 
> +1 for making frameworks master now :)
> 
> Proposal:
> Let's change and not (ab)use the "3.0" version label for the current
> development milestone in the frameworks branch where initial port could be
> declared done-with-no-big-regressions, and thus also not do the first
> release as "3.1".
> Let's instead use the "3.0" version for the first release. And simply keep
> the current 3.0 Alpha tag on the frameworks branch.
> 
> Not need to dump "3.0" in interface to public and waste time/space in the
> release notes, chats and interviews/articles on where 3.0 is and why 3.0 was
> skipped, where instead features could and should be highlighted :) Unless
> anyone can tell if there could be a great promotion spin done out of that?
> ;)
> 
> Internally we have been talking about 3.0 as switch-feature-development-to-
> frameworks milestone and 3.1 as first-qt5-based release, but well, we are
> smart contributors and can quickly adapt tag labels, right? :)
> 
> Objections?
> 
> Cheers
> Friedrich
> ___
> 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: Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)

[C. Boemann]

On Monday 31 August 2015 11:24:48 Friedrich W. H. Kossebau wrote:
> Am Freitag, 28. August 2015, 19:18:18 schrieb Friedrich W. H. Kossebau:
> > Am Freitag, 28. August 2015, 15:48:39 schrieb Boudewijn Rempt:
> > > On Thu, 27 Aug 2015, Friedrich W. H. Kossebau wrote:
> > > > * after that:
> > > >  2.9 only bugfixes, no more features
> > > >  master unfrozen, so open for features and porting from
> > > >  kdelibs4support
> > > 
> > > I also would like to cleanup the coding style, still...
> 
> Does any of the non-Krita maintainers want to do a cleanup of the coding
> style?
> 
> If not and it's only Krita where that should happen, could that be done
> after the split-off, Boud? Especially when you realize your plan to dump
> history and start out with a plain snapshot, that would then be a good time
> to also do the reformatting.
> 
> Yue, Jarosław, Tomas, Camilla, Leinir, anyone of you want to do a
> reformatting of any part of Calligra?
> 
> Cheers
> Friedrich
> 
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
I have no big urge to so no - I think we are generally there - but I also 
think that nw(ish) would be a good time

Camilla
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: [calligracommon] [Bug 346421] Calligra 2.9.2 build fails (fwd)

[C. Boemann]

It's in debian testing so okay with me


On Tuesday 08 September 2015 10:08:57 Boudewijn Rempt wrote:
> Is it okay to update to libwps 0.4? Or should we stay with 0.3 for now,
> or would it make sense to check the version and make the code conditional?
> 
> This is the patch they're talking about in the bug report:
> 
> diff --git a/cmake/modules/FindLibWps.cmake b/cmake/modules/FindLibWps.cmake
> index f8c8225..58ef2b5 100644
> --- a/cmake/modules/FindLibWps.cmake
> +++ b/cmake/modules/FindLibWps.cmake
> @@ -10,16 +10,16 @@
> 
>   include(LibFindMacros)
>   libfind_package(LIBWPS LibWpd)
> -libfind_pkg_check_modules(LIBWPS_PKGCONF libwps-0.3)
> +libfind_pkg_check_modules(LIBWPS_PKGCONF libwps-0.4)
> 
>   find_path(LIBWPS_INCLUDE_DIR
>   NAMES libwps/libwps.h
>   HINTS ${LIBWPS_PKGCONF_INCLUDE_DIRS} ${LIBWPS_PKGCONF_INCLUDEDIR}
> -PATH_SUFFIXES libwps-0.3
> +PATH_SUFFIXES libwps-0.4
>   )
> 
>   find_library(LIBWPS_LIBRARY
> -NAMES wps wps-0.3
> +NAMES wps wps-0.4
>   HINTS ${LIBWPS_PKGCONF_LIBRARY_DIRS} ${LIBWPS_PKGCONF_LIBDIR}
>   )
> 
> diff --git a/filters/words/works/import/WPSImport.cpp
> b/filters/words/works/import/WPSImport.cpp index eea2cc9..94b859d 100644
> --- a/filters/words/works/import/WPSImport.cpp
> +++ b/filters/words/works/import/WPSImport.cpp
> @@ -91,7 +91,9 @@ public:
>   bool isSupportedFormat(librevenge::RVNGInputStream &input)
>   {
>   WPSKind kind = WPS_TEXT;
> -WPSConfidence confidence =
> WPSDocument::isFileFormatSupported(&input, kind); +WPSCreator
> creator = WPS_MSWORKS;
> +bool needsEncoding = false;
> +WPSConfidence confidence =
> WPSDocument::isFileFormatSupported(&input, kind, creator, needsEncoding);
> if (confidence == WPS_CONFIDENCE_NONE || kind != WPS_TEXT) return false;
>   return true;
> lines 1-39/39 (END)
> 
> 
> 
> -- Forwarded message --
> Date: Thu, 03 Sep 2015 14:51:25 +
> From: Timo Gurr 
> Reply-To: bug-cont...@bugs.kde.org
> To: b...@valdyas.org
> Subject: [calligracommon] [Bug 346421] Calligra 2.9.2 build fails
> 
> https://bugs.kde.org/show_bug.cgi?id=346421
> 
> Timo Gurr  changed:
> 
> What|Removed |Added
> 
> CC||timo.g...@gmail.com
> 
> --- Comment #11 from Timo Gurr  ---
> (In reply to var.spool.mail700 from comment #10)
> 
> > https://projects.archlinux.org/svntogit/packages.git/plain/trunk/libwps-0.
> > 4. patch?h=packages/calligra
> > 
> > krita requires libwps 0.3 while arch has libwps 0.4
> 
> Would be really nice to see this patch applied because LibreOffice now
> requires libwps[>=0.4.0] and Calligra still requires 0.3.

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Porting code from Calligra to KWord

[C. Boemann]

Well i would have liked to actually release it first before it being copied, 
but it's free software so not much I can do about it

On Wednesday 02 February 2011 05:48:13 Ganesh Paramasivam wrote:
> All,
> 
> For completing the UI for change-tracking of tables for both Calligra
> Words and KWord, I need table editing to work on both the
> applications. Table editing currently is available in Calligra but not
> in KWord. So I will be taking this code from Calligra master branch
> and porting to KWord. I will attribute copyright's in KWord to the
> owners of this code.
> 
> I'm assuming that this should be okay. Please correct me if I'm wrong.
> 
> Thanks and Regards,
> Ganesh
> ___
> 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: release schedule proposal

[C. Boemann]

On Wednesday 02 February 2011 10:34:30 Pierre Stirnweiss wrote:
> On Wed, Feb 2, 2011 at 10:18 AM, Boudewijn Rempt  wrote:
> > On Wednesday 02 February 2011, Inge Wallin wrote:
> > > Do you plan to make real, i.e. not previews, of Krita in the mean time?
> > 
> > The
> > 
> > > reason I ask is that I wonder which Linux distros are going to package
> > 
> > the
> > 
> > > previews and how.
> > 
> > I think that (after a bit of cleanup), Calligra master contains a stable
> > version of Krita that is a big improvement over KOffice 2.3. So I would
> > want to communicate that to users. I think the same holds for the other
> > apps -- with 37 feature branches, we've clearly shown that we've grasped
> > the git way of working.
> 
> If I remember properly Oslo, we actually had planned to have a "always
> stable" master and features developed in branches that would be merged when
> "ready". Bug fixes should be done in master.
>  I think this is actually working pretty good as of now.
> 
> So would it be possible to have on a regular basis (monthly why not), a
> "stable snapshot". I am not sure there should be a link with a future
> "numbered" release (like 3.0 technology preview). That way we could have
> "numbered release" linked to evolution in the software rather than date
> constraint.
> 
> We could have the following then:
> - Calligra [last release number] Stable snapshot [YYMM]. These would
> provide both "maintenance releases" and new "finished " merged features.
> - Calligra [new release number]: when we decide we achieved technically a
> new Milestone.
> 
> Pierre
I like this very much, both now and as the future way of releasing.

i would assume our first release would then be:

Calligra Suite 2.3 Stable snapshot 201103


Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: release schedule proposal

[C. Boemann]

On Wednesday 02 February 2011 10:47:40 Boudewijn Rempt wrote:
> On Wednesday 02 February 2011, C. Boemann wrote:
> > I like this very much, both now and as the future way of releasing.
> > 
> > i would assume our first release would then be:
> > 
> > Calligra Suite 2.3 Stable snapshot 201103
> 
> I was rather hoping for a February release...
I think that would be pushing it as the text styles docker needs to be done, 
and we need to have our new executable names in order as well as getting 
translations and packaging ready

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: release schedule proposal

[C. Boemann]

On Wednesday 02 February 2011 11:08:56 Cyrille Berger Skott wrote:
> On Wednesday 02 February 2011, C. Boemann wrote:
> > Calligra Suite 2.3 Stable snapshot 201103
> 
> For packagers we would need a proper version number. One that is lower than
> the next stable, and bigger than the previous one.
so it would fit perfectly ;)
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Here comes success

[C. Boemann]

On Sunday 06 February 2011 11:50:58 Pierre Stirnweiss wrote:
> Voilà,
> 
> PierreSt
Magnifique
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: release schedule proposal

[C. Boemann]

On Monday 07 February 2011 10:10:13 Boudewijn Rempt wrote:
> The discussion seemed to have petered out without a real decision, so
> here's a really concrete proposal:
> 
> * Let's make a monthly calligra snapshot that's advertised as reasonably
> stable and full of you-need-to-try-this goodness until we are at a point
> where we can start a real release schedule
> 
> * first release: march 1st, from then on every 1st of the month
> 
> * internal numbering starts at 2.3.80
> 
> * external we call it the "march snapshot", "april snapshot"
i support that
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Passing an integer to a string to a method having QString as a parameter signature

[C. Boemann]

On Tuesday 08 February 2011 13:59:47 Gopalakrishna Bhat wrote:
> I was looking as this piece of code in KoTextEditor.cpp
> 
> 
> void KoTextEditor::newLine()
> {
>d->updateState(KoTextEditor::Private::Custom, i18n("Line Break"));
>if (d->caret.hasSelection())
>d->deleteInlineObjects();
>KoTextDocument koDocument(d->document);
>KoStyleManager *styleManager = koDocument.styleManager();
>KoParagraphStyle *nextStyle = 0;
>KoParagraphStyle *currentStyle = 0;
>if (styleManager) {
>int id =
> d->caret.blockFormat().intProperty(KoParagraphStyle::StyleId);
>currentStyle = styleManager->paragraphStyle(id);
>if (currentStyle == 0) // not a style based parag.  Lets make the
> next one correct.
>nextStyle = styleManager->defaultParagraphStyle();
>else
>nextStyle =
> styleManager->paragraphStyle(currentStyle->nextStyle());
>Q_ASSERT(nextStyle);
>if (currentStyle == nextStyle)
>nextStyle = 0;
>}
> .
> .
> .
> 
> }
> 
> 
> Here the parameter passed to styleManager->paragraphStyle(id) is a integer
> whereas its signature shows that it is a const QStringIs this the right
> way to call or am I missing something?
> 
> //snippet from KoStyleManager.cpp
> KoParagraphStyle *KoStyleManager::paragraphStyle(const QString &name) const
> {
> foreach(KoParagraphStyle *style, d->paragStyles) {
> qDebug() " if (style->name() == name)
> return style;
> }
> return 0;

from KoStyleManager.h:


/**
 * Return a paragraphStyle by its id.
 * From documents you can retrieve the id out of each QTextBlockFormat
 * by requesting the KoParagraphStyle::StyleId property.
 * @param id the unique Id to search for.
 * @see KoParagraphStyle::styleId()
 */
KoParagraphStyle *paragraphStyle(int id) const;
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: GSoC 2011!

[C. Boemann]

On Wednesday 09 February 2011 09:39:28 Boudewijn Rempt wrote:
> On Wednesday 09 February 2011, todd rme wrote:
> > I have a couple suggestions about possible projects:
> ...
> 
> I think these are pretty cool ideas! Have you added them to
> http://community.kde.org/GSoC/2011/Ideas?
i'v merged in the citation thing in another project idea
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: GSoC 2011!

[C. Boemann]

On Wednesday 09 February 2011 16:11:41 todd rme wrote:
> On Wed, Feb 9, 2011 at 3:50 AM, C. Boemann  wrote:
> > On Wednesday 09 February 2011 09:39:28 Boudewijn Rempt wrote:
> >> On Wednesday 09 February 2011, todd rme wrote:
> >> > I have a couple suggestions about possible projects:
> >> ...
> >> 
> >> I think these are pretty cool ideas! Have you added them to
> >> http://community.kde.org/GSoC/2011/Ideas?
> > 
> > i'v merged in the citation thing in another project idea
> 
> Thanks, but is it really a good idea to limit it to words?  At least
> in my field we are expected to use references extensively in
> presentation, and I can see use-cases for almost every other program,
> so I think a more generic solution (perhaps tied to the words flake,
> or perhaps to its own) would be better.
> 
> -Todd
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
It's indeed not tied to Words. Just the project title :)
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: GSoC 2011!

[C. Boemann]

On Thursday 10 February 2011 21:15:06 todd rme wrote:
> On Thu, Feb 10, 2011 at 1:26 PM, todd rme  wrote:
> > On Thu, Feb 10, 2011 at 3:42 AM, Cyrille Berger Skott
> > 
> >  wrote:
> >> On Wednesday 09 February 2011, todd rme wrote:
> >>> On Wed, Feb 9, 2011 at 3:39 AM, Boudewijn Rempt  
wrote:
> >>> > On Wednesday 09 February 2011, todd rme wrote:
> >>> >> I have a couple suggestions about possible projects:
> >>> > ...
> >>> > 
> >>> > I think these are pretty cool ideas! Have you added them to
> >>> > http://community.kde.org/GSoC/2011/Ideas?
> >>> 
> >>> I could do so, but according to the instructions only mentors are
> >>> supposed to do this.  I have no problem adding them if I have approval
> >>> from developers, though.
> >> 
> >> The instructions also say "If you are not a developer but have a good
> >> idea for a proposal, get in contact with relevant developers first."
> >> since the developers have validated your ideas, please go ahead :)
> >> 
> >> --
> >> Cyrille Berger Skott
> > 
> > Sounds good, I just wanted to make sure I actually had the okay to do so.
> > 
> > Who would be the mentor?
> > 
> > -Todd
> 
> I put them up.  Please look to see if they are written how you would
> like.  I didn't know who to put as a mentor, so I just referred them
> to the mailing list.  Please add a mentors if there is one.
Don't worry. We usually assign mentors when we decide on the project 
applications.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Looking for a list of TODO items for a newcoming

[C. Boemann]

On Tuesday 15 February 2011 03:23:56 Chris Morgan wrote:
> Hello.
> 
> I was interested in working on calligra and was wondering if there was
> a list of items that a beginner could start with.
> 
> Chris
there probably are things, but it's better if you say what areas interest you. 
Then we can probably find something in that area. The reason I answer like this 
is because finding something you think is funny is probably going to make you 
stay.

best regards
Casper Boemann
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: gsoc mentor

[C. Boemann]

On Tuesday 22 February 2011 21:31:42 jignesh kakadiya wrote:
> hi,
> I'm new to this list.
> I would like to contribute to "extend the notes-support in Calligra Words"
> for view+add+edit+delete+load+save notes/comments/annotations.I know c++
> and qt.So please tell me some suggestions for the topic.
> jignesh
Hi

Warm welcome.

Sebastian is going away for vacation so I'll have to answer.

Basically it's as it says: all things concerned to comments (as i like to 
refer to them).

I think first you should try and build calligra, look at the source code and 
get an idea of what is needed.

You can then join us on irc (#calligra on freenode) or ask some questions here 
on mail.

best regards
Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: KoTableColumnAndRowStyleManager Question.

[C. Boemann]

On Monday 28 February 2011 10:00:15 Elvis Stansvik wrote:
> 2011/2/28 Ganesh Paramasivam :
> > Shouldn't the function return a reference or a pointer ? like this
> > 
> > KoTableColumnAndRowStyleManager&
> > KoTableColumnAndRowStyleManager::getManager(QTextTable *table)
> > 
> > If I were to set a row-style or a column-style for a table and do this
> > KoTableColumnAndRowStyleManager::getManager(table)->setRowStyle(0,
> > rowStyle) I would be setting these values on a copy of the return value
> > ( and not on the actual Manager ).
> 
> Yes you would.
> 
> Not sure, but I guess it works because KoTableColumnAndRowStyleManager
> is explicitly shared. I.e. all KoTableColumnAndRowStyleManager
> instances share the same data. Right Casper?
right, explicitly shared
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: breaking unittests is BAD

[C. Boemann]

On Monday 07 March 2011 06:40:15 Boudewijn Rempt wrote:
> Hi,
> 
> _If_ we want to be able to release master as a reasonably stable snapshot,
> we really have to be better about our unittests. Even if the unittests
> test something that is being refactored anyway in a branch, we should
> _NOT_ break those tests.
> 
> 
> Currently we have the following failures:
> 
>   7 - words-part-frame-TestDocumentLayout (Failed)
> 
> This one is a crash after a refactoring by Sebastian, and when I remove the
> cause for the crash, the test fails completely anyway.

I wouldn't mind if we just deleted that file. There is nothing in there that is 
worth salvaging.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: PDF-Import and/or PDF-Export

[C. Boemann]

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_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
Also libpodofo seems the only one remotely capable of generating colormanaged 
pdf, which at least Krita might like
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Interested in GSOC 2010 KDE project

[C. Boemann]

On Monday 21 March 2011 07:22:17 Bi Ran wrote:
> Hello Mr Sauer
> 
> I am Bi Ran, an year 3 computing student from National University of
> Singapore.
> I am interested in doing GSOC KDE project this year.
> 
> Project: Fix and extend LaTEX support looks interesting to me.
> I have experience developing in QT, and I have 2 year's LaTex experience.
> I am also good in algorithm. I have experience in ACM/ICPC, Google Code Jam
> and some other programming contests.
> 
> Can you give me some suggestion about what should I prepare to get a better
> chance to get this project?
> 
> Thank You
> 
> Warmest Regards
> Bi Ran
Hi

Sebastian is on vacation the rest of the month, but building Calligra, and 
looking at how our filter system works might be a good idea. You can always 
mail or ask on irc.

Also looking at ODF is a good idea

best regards
Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: New member

[C. Boemann]

Hi

You already seem far along

You more or less just need to pick a topic that interests you, and then ask 
how to do that and some people will probably answer.

I suggest you use irc to chat with us

On Monday 21 March 2011 18:21:38 jul...@juliankennedy.co.za wrote:
> Hi All
> 
> Im quite interested in contributing development to calligra. Some pointers
> in the right direction will be appreciated. I already know C++ and Ive
> written a few small apps in Qt. And I successfully got calligra compiled
> and running from source. So now I need to know how to get involved.
> 
> Regards
> Julian
> 
> ___
> 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: Suite version number

[C. Boemann]

On Thursday 07 April 2011 20:50:50 Boudewijn Rempt wrote:
> Hi,
> 
> We have discussed the possible version number for the first real release of
> Calligra a bit, wavering between 2.4 (because the gui is not yet done) or
> 3.0 (because of the new text engine). But I recently thought:
> 
> "Why not 1.0?"
> 
> There are many excellent reasons for using 1.0:
> 
> * it's the first release as Calligra, not KOffice
> * we're making a clean break anyway
> * it's very much a 1.0 level product, feature-wise
> 
> Of course, this has implications for the numbering of our snapshots as
> well, so we need to decide about this before the first snapshot release in
> 2 weeks and one day...
I'm all for a 1.0 release

Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Google Summer of Code Projects

[C. Boemann]

Hi Steven

Yes you need to hurry up a lot to make it as a GSoC, but we would like your 
contribution no matter if you make it or not.

Pierre has already hinted at the challenges with notes, though it is not 
impossible and would be very appreciated

So would working on the References tool.

Please contact us on irc asap

Casper

On Friday 08 April 2011 03:45:03 Steven Kakoczky wrote:
> Dear mentors, specifically Sebastian Sauer and Casper Boemann,
> 
> I know it's a little late, but I just found out about the Summer of Code a
> few days ago and thought that it was a great excuse for me to finally start
> working on an opensource project. Since it was short notice for me, I
> figured I'd go for something I'm already familiar with, namely KDE and
> Calligra. To be honest I have never worked on a real world project before,
> but have been working on my Computer Science degree for three years now.
> I've worked a lot with C/C++ and Java and have dabbled in Qt, but I've done
> GUI design with Java Swing. The project that really interested me was
> Implementing notes-support because I use notes/comments a lot in other
> software that I use and think that it is a project within my experience
> level to make a difference on. I would also be interested in finishing up
> the Layout tool or helping to make the References tool. I will be
> submitting applications for these through google as well, but I just
> wanted to get communicating with the mentors now to judge the viability of
> me being on the team right away.
> 
> freenode nick: skakoczky
> 
> -Steven Kakoczky
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Fix for Reducing the various hardcoded zoomlevel based on usability feedback from Anna

[C. Boemann]

No I'm not talking about removing anything from the bottom. I'm saying your 
patch currently removes some functionality there, which I'm not sure we want 
removed.

Please try and click on the number in the bottom right corner (without your 
patch)

best regards
Casper

On Tuesday 05 April 2011 00:15:39 Suresh Chande wrote:
> > On April 4, 2011, 6:31 a.m., Casper Boemann wrote:
> > > I think the 100% should staty. That is what Anna-lisa said too
> > > 
> > > Also I'm not either for or against it, but the options in the widget in
> > > the bottom corner is removed too with this patch
> 
> by "but the options in the widget in the bottom corner is removed too with
> this patch" I guess you are talking about the slider for zooming, right ?.
> There was a discussion to add the slider into the zoom. i am not entirely
> comfortable as this is not totally according the UI Experience where a
> slider exists inside a drop-down menu.
> 
> 
> - Suresh
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101022/#review2372
> ---
> 
> On April 3, 2011, 9:12 p.m., Suresh Chande wrote:
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > http://git.reviewboard.kde.org/r/101022/
> > ---
> > 
> > (Updated April 3, 2011, 9:12 p.m.)
> > 
> > 
> > Review request for Calligra, Marijn Kruisselbrink, Thorsten Zachmann, and
> > Casper Boemann.
> > 
> > 
> > Summary
> > ---
> > 
> > Ok Here comes my first fix..
> > 
> > Here is my fix I made to the zoom levels based on discussion and
> > agreement at the Calligra sprint that we do not want to have 33, 57 and
> > 127 etc % zoom levels . This fix removes the different zoom levels but
> > leaves fit to width and fit to page.
> > 
> > See testing done, Any suggestion how this should be it be fixed for
> > Tables ?
> > 
> > 
> > Diffs
> > -
> > 
> >   libs/widgets/KoZoomAction.cpp 488652c
> > 
> > Diff: http://git.reviewboard.kde.org/r/101022/diff
> > 
> > 
> > Testing
> > ---
> > 
> > This was tested in the Words and Stage application and it functions
> > according to expected outcome. I tested the Tables it seems as Tables
> > does not have Fit to Width or Fit to Page the menu is currently empty.
> > 
> > 
> > Thanks,
> > 
> > Suresh
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Progress on OOo GDI Metafile

[C. Boemann]

It looks understandable already, but I'm sure you'll refine it more as you go 
along

Casper

On Saturday 09 April 2011 02:38:15 Pierre wrote:
> 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
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

spring cleaning of branches

[C. Boemann]

Hi

I though it would be a good idea to clean out in our public branches as there 
are a lot of old ones hanging around.

My compiled list of branches to be deleted is this, but please see if you have 
something to add:

remotes/origin/words-change_tracking-ganeshp
remotes/origin/words-toc-korinek-tvrdy  
remotes/origin/words_text_anchors_moved_into_textShape_Hanzes
remotes/origin/words_dynamic_anchor_layout_Hanzes
remotes/origin/mywork
remotes/origin/inlineAnchorStrategy_Hanzes
remotes/origin/all-tooldocker-boemann


best regards
Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: [Bug 270713] Calligra Words crashes upon changing font

[C. Boemann]

Hi Ganesh, can you look at this

I've seen it too

On Wednesday 13 April 2011 04:05:18 Christoph Feck wrote:
> https://bugs.kde.org/show_bug.cgi?id=270713
> 
> 
> Christoph Feck  changed:
> 
>What|Removed |Added
> ---
> - Component|general |general
>  AssignedTo|unassigned-b...@kde.org
> |calligra-words-bugs-null@kd
> 
>||e.org
> 
> Product|kde |calligra-words
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Text saving broken

[C. Boemann]

Pinaraf, can you look at this one please


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.
> 
> 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: Building words in Qt Creator

[C. Boemann]

On Wednesday 20 April 2011 09:45:00 Diego Turcios wrote:
> Hi
> I am trying to build calligra in Qt Creator, but I got a mistake.
> First I am fallowing this guide [0].
> And this are the problems I get
> Starting /home/diego/qtcreator-build/words/part/words...
> words(18539)/kdecore (services)
> KServiceFactory::findServiceByDesktopPath: "wordspart.desktop" not
> found
> words(18539)/kdecore (services)
> KServiceFactory::findServiceByDesktopPath: "Office/words.desktop" not
> found
> words(18539)/koffice (lib komain): "words" part.desktop not found.
> 
> words(18539)/koffice (lib komain): Run 'kde4-config --path services'
> to see which directories were searched, assuming kde startup had the
> same environment as your current shell.
> 
> words(18539)/koffice (lib komain): Check your installation (did you
> install Calligra in a different prefix than KDE, without adding the
> prefix to /etc/kderc ?)
> 
> /home/diego/qtcreator-build/words/part/words exited with code 1
> 
> Still don't how to solve this small problem. Thanks for your time
> 
> 
> [0]http://community.kde.org/Calligra/Building/Developing_With_QtCreator
sounds like you forgot to run kbuildsycoca4
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

deleting children of KoShapeContainer

[C. Boemann]

Hi

I believe it's important for the KoShapeContainer to delete it's children.

I have a crash related to not all shapes being deleted.

However I also think that for some grouping ungrouping kind of things it is 
changing behaviour

Jan do you have some insights.

best regards
Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: GSoC Application Feedback

[C. Boemann]

On Tuesday 26 April 2011 15:31:30 Diego Turcios wrote:
> Hi
> I send an email to Lydia Pintscher asking for a feedback about my
> application, why it wasn't accepted.
> She answer me this
> 
>  Hi :)
> 
> Sorry, your email landed in spam and I just saw it now.
> Your proposal is quite specialized. I think it would be best to ask
> the Calligra guys directly about some feedback in this case.
> 
> Cheers
> Lydia
> 
> So I would like you guys to give me the feedback about my application. My
> application was Calligra Words PDF-Import and/or PDF-Export. This is the
> [0]link of the application.
> I imagined some things my application was missing, but better know real
> reason why.
> 
> Thanks for your time
> 
> [0]
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/diegotur
> cios/1
I've replied to him off-list.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Announcement draft

[C. Boemann]

[17:54]  ingwa: the following is a bit hard to read: What is not yet 
fully mature
[17:55]  better something like: We know the desktop interface is not 
yet mature
[18:00]  also it seems very office centric
[18:01]  "than other free office suites" implies Calligra is an office 
suite
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Announcement draft

[C. Boemann]

On Tuesday 26 April 2011 18:20:49 Jaroslaw Staniek wrote:
> On 26 April 2011 16:06, Inge Wallin  wrote:
> > On Tuesday, April 26, 2011 16:00:52 Inge Wallin wrote:
> >> Here is a first draft of the announcement of snapshot 1.  I have already
> >> had some feedback from Cyrille that I incorporated.
> >> 
> >> Please comment on the overall structure (is this what we want to focus
> >> on?) as well as the actual content.  Also remember that this is a first
> >> draft that will be polished over the next few days.
> >> 
> >> When we have the screenshots and visual tour on the website, I will also
> >> add references to those.
> >> 
> >>   -Inge
> > 
> > Based on feedback from my first draft, I have embellished it a bit.  Here
> > is a longer version. :-P
> 
> Nice work!
> First, one thing: I'd like to propose to have two messages: to users
> and developers. Only the latter would mention GUI/engine separation
> and stuff like that. If we start doing the separation for any
> announcement, we can escape from the 'geek' area.
> Simple test: just give the text to read to your family and see what's
> a like black magic to them, then improve incrementally.
Very good point. 100% agree
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: The snapshot and the new text layout code.

[C. Boemann]

On Thursday 28 April 2011 10:57:55 Inge Wallin wrote:
> Today is officially the tagging for 2.4 or 3.0 snapshot 1.  And I hear
> people expressing the opinion that the new text layout code should not be
> merged before the snapshot. This worries me.
> 
> We do the snapshots for two reasons:
> 
> 1. To get feedback on what we have now.
> 
> 2. To show some activity and let people know that the project is very
> active.
> 
> I would say that the most important development that we have going right
> now is the new text layout engine. It is crucially important for both
> Words and Stage.  Casper says it is ready, there has been a full-time
> tester (Swathi) testing it for over a week and she says that it is better
> than the old code.
> 
> Yet, if we continue on the set track, the new layout code will not be part
> of the snapshot.  In fact, Casper says that if this happens he doesn't
> want Words to be part of the snapshot at all. This means that reason 1
> will be completely failed.
> 
> So I suggest that we delay the tagging of the snapshot a few days and let
> Casper merge the branch. It only touches two parts of the engine: kotext
> and the text shape.  In addition to that, there are changes in Words and
> Stage. Things may be a little bit unstable, but since Swathi says it is
> already better than before, I think we can live with that.
> 
> Most importantly, if we *don't* merge it, we will not have words in the
> snapshot, which to me is failure, *or* we will have lots of feedback on
> things that will be thrown away, maybe even in the time between the
> tagging and the actual release day.
> 
> So please, let's agree to merge the text layout code, and if that means
> delaying the snapshot a couple of days, then it's a very cheap price to
> pay.
> 
>   -Inge
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
I couldn't have set it better myself.

I'll probably merge later today

best regards
Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Text layout has landed

[C. Boemann]

The text layout branch has landed in master

Please continue work in master or your own branches from now on!

Best regards
Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Google Summer of Code

[C. Boemann]

On Thursday 28 April 2011 15:12:16 Boudewijn Rempt wrote:
> Hi!
> 
> Quick question for our mentors and students: have you all been in contact
> with each other already? For Krita students, we have the requirement that
> students blog at least once a week. Maybe that's a good idea for the other
> Calligra students as well?
Been in contact with my student yes
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Text layout has landed

[C. Boemann]

On Thursday 28 April 2011 16:41:30 Thorsten Zachmann wrote:
> Hello,
> 
> On Thursday, April 28, 2011 13:26:22 C. Boemann wrote:
> > The text layout branch has landed in master
> > 
> > Please continue work in master or your own branches from now on!
> 
> I have to say that I'm a bit disappointed on how this thing went. I think
> for features big as that and which affecting all applications we should
> have reviews as agreed and we should follow these procedures.
> Also when asking people for opinion on the mailing list we should try to
> find a consensus. Maybe not all will like the result but why ask first and
> then nevertheless go on without taking into account what people answer.
> Merging such a big change only 2.5 hours there was a mail about what
> people think is not the nicest thing to do.
> 
> Would it be possible to get the diff that was applied as patch on
> reviewboard so that people can do a post review?
> 
> I hope we can fix the most stuff e.g. hanging/crashes/ not yet working
> features in the remaining time and I will do my best to help with it. But
> I think also everybody should test the stuff we have now and report
> problems so that as much cane be fixed until the snapshot will be tagged.
> 
> Thorsten
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
I apologize for being hasty, but after having had to spend yet another hour 
solving merge conflicts I just snapped.

I don't think a review process makes much sense for a change such as this. 
Naturally there will be unfinished things and things that can be improved in 
time. Rather than a review process it's simply better to just press ahead and 
make the improvements as they become obvious.

>From testing only Words seems worse of on some features (and a lot better on 
others). I'm confident that come the tagging of the snapshot next Thursday we 
will have progressed rapidly. And I believe that putting it in master a week 
before the snapshot is the way to get feedback and review. Not by hiding it 
away in a branch.

I'm sorry, but I actually see no other way than what I did, but I do apologize 
for not having waited longer.

Best regards
Casper
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Testing document loading/painting

[C. Boemann]

On Friday 29 April 2011 13:06:48 Thorsten Zachmann wrote:
> Hello,
> 
> I have been running cstester against 802 documents to see if there are
> problems.
> 
> The documents are from the following document types:
> 
>  41 doc
>  92 docx
>  62 odt
>  66 odp
> 156 ppt
>  75 pptx
>  57 ods
> 166 xls
>  87 xlsx
> 
> 23 Documents showed about 11 different problems. I have uploaded the
> documents to http://www.zagge.de/layoutproblem/ .Please note that I did
> not check if the documents are layouted correctly,only if they could be
> loaded and painted. Also there is still a problem with some text documents
> that produce an endless loop in cstester while they are opening fine in
> words.
> 
> Would be cool if we could fix those problems in preperation for the
> snapshot.
> 
> Thorsten
> 
> The following problems where found:
> Words (for some crashes you need to scroll down the document):
> -Assert during painting:
>   www.latrobe.edu.au%2Flims%2Fresearch%2Fdocuments%2Flevel-b-PD.docx
Fixed above

>   www.dr-
ait.org%2FEngineering%20Chemistry_Model%20Question%20Paper_3.docx
>   
www.nerc.com%2Fdocs%2Foc%2Fdewg%2Fisn%2Ficcp_aief_dewg_r1%20(Clean).docx
>  
> 
www.coe.unt.edu%2Fsystem%2Ffiles%2F433%2F833%2FTEKS%20A2%20B%20Cab%20Ride.
> docx
> 
www.usg.edu%2Facademic_programs%2Fdocuments%2Fbaccalaureate_masters_propos
> al.docx www.msisac.org%2Fawareness%2Fdocuments%2FSGISM-
Matrix-2%301%30.docx
> -Crash in painting
>   words unexisting_file
> -Endless loop in layout
>   staff.georgianc.on.ca%2Fforms%2Fmultiplechoiceanswers.docx
>   eprints.pharmacy.ac.uk%2F1%3056%2F1%2Fpiperine.docMurdan.docx
>   policy.ballarat.edu.au%2Fforms%2FAnnual_OHS_Plan_Template.docx
> -Crash in words
>   wiki.services.openoffice.org%2Fw%2Fimages%2F9%2F91%2F%305%308IG3-
> SlidesNotesHandouts.odt
>   
wiki.documentfoundation.org%2Fcgi_img_auth.php%2Fc%2Fce%2F%302%305WG3-
> PrintingExportingEmailing.odt
>  
> 
www.odfauthors.org%2Fopenoffice.org%2Fenglish%2Fuserguide3%2Fimpress3%2F3%
> 30_published%2F%305%308IG3- SlidesNotesAndHandouts.odt
> 
> Stage PPT filter
> - Crash in filter
>   csrc.nist.gov%2Fgroups%2FSNS%2Fcloud-computing%2Fcloud-computing-
v26.ppt
> - Endless loop in ppt filter
>   cosmologist.info%2Fpolar%2FEB.ppt
>   www.huffenglish.com%2Fpowerpoints%2Fromeoandjuliet.ppt
>  
> 
www.lexington1.net%2Ftechnology%2Finstruct%2Fppts%2FLAppts%2F35%2FSubjPred
> .ppt promitheas.iacm.forth.gr%2Ffe-
> cone%2Fdocs%2FWorkshop%2FExperts%2FFORTH%20On%20the%20e-
content.ppt
>   www.eden-
> 
online.org%2Fcontents%2Fconferences%2Fannual%2FVienna%2FKeynotes_on_the_web
> %2FRichier.ppt
> 
eacea.ec.europa.eu%2Ftempus%2Ffunding%2F2%30%309%2Fdocuments%2F28-2%30%309
> %2Ftempus_call_28_2%30%309_e- form_submission.ppt
> - Invalid xml created
>   www.varnum.org%2Fpapers%2Fbasics-and-beyond.ppt
> 
> Stage MSOOXML filter
> -Crash in ooxml filter
>   www.usaswimming.org%2F_Rainbow%2FDocuments%2F4ea23365-
> de32-4324-959e-196e2a3%30d767%2FGOVERNESS%20PRESENTATION.pptx
> 
> Flake:
> -Crash in connection shape loading (already fixed)
>   drwho.virtadpt.net%2Ffiles%2FNOVALUG-Tor.odp
> 
> Tables:
> - Loading takes very very long
> 
www.inrets.fr%2Ffileadmin%2Fur%2Fma%2FFichiers_mistral%2FPage_Brenac%2FCont
> r- Bf-Aft-Accid-Study2.ods
> ___
> 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: Logo

[C. Boemann]

On Sunday 01 May 2011 23:39:41 Pau Garcia i Quiles wrote:
> Hi,
> 
> http://kodapp.com/
> 
> That logo looks too similar to KOffice's and Calligra
> (although in Calligra the K logo is much much less prominent), doesn't it?
To KOFfice I would agree. For Calligra we are in the process of finding a new 
logo, so the kod logo is not a concern for us.

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: The state of Calligra Words (a call for testing)

[C. Boemann]

On Thursday 05 May 2011 09:24:48 Cyrille Berger Skott wrote:
> On Wednesday 04 May 2011, Sebastian Sauer wrote:
> > We still have some days left to address any
> > such direct visible problems so our enduser-alpha-testers won't run into
> > problems to fast.
> 
> Actually you don't have so many days left... Since tagging is for today.
> So the question is: is the lack of working anchor a problem ?
No. It's not a problem. Runaround and inline anchors were merged in yesterday. 
So only floating anchors are not working, and that s okay for a snapshot (we 
might want to mention it though)
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: The state of Calligra Words (a call for testing)

[C. Boemann]

On Friday 06 May 2011 05:33:40 Thorsten Zachmann wrote:
> On Thursday, May 05, 2011 09:28:44 C. Boemann wrote:
> > On Thursday 05 May 2011 09:24:48 Cyrille Berger Skott wrote:
> > > On Wednesday 04 May 2011, Sebastian Sauer wrote:
> > > > We still have some days left to address any
> > > > such direct visible problems so our enduser-alpha-testers won't run
> > > > into problems to fast.
> > > 
> > > Actually you don't have so many days left... Since tagging is for
> > > today. So the question is: is the lack of working anchor a problem ?
> > 
> > No. It's not a problem. Runaround and inline anchors were merged in
> > yesterday. So only floating anchors are not working, and that s okay for
> > a snapshot (we might want to mention it though)
> > ___
> > calligra-devel mailing list
> > calligra-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/calligra-devel
> 
> words currently crashes when you select the blank page template. Maybe that
> should be fixed and ported to the snapshot.
> 
> Thorsten
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
Fixed (by deleting the template)
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: test server is back, now with calligra

[C. Boemann]

On Monday 09 May 2011 15:34:04 Jos van den Oever wrote:
> Hi all,
> 
> The test server is up again at http://158.36.191.251:8080/
> Press "Login as a Guest User" at the bottom of the login screen.
> 
> As before you can follow the progress of Calligra in steps of a few
> commits.
> 
> In Calligra/default you can see:
>   -- if Calligra compiles
>   -- how many tests are failing
>   -- how long each test took and if that's slower or faster then before
> 
> In Calligra/kofficetests you can see:
>   -- what files are causing crashes on a load/save cycle
>   -- how long these cycles take in the current and previous snapshot
>   -- see backtraces for crashes
> 
> http://158.36.191.251:8080/
> Press "Login as a Guest User" at the bottom of the login screen.
> 
> Have fun!
> Jos
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
Cool thanks 
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: styles docker

[C. Boemann]

On Thursday 12 May 2011 13:58:23 Pierre Stirnweiss wrote:
> i am trying to debug the styles docker in words. when clicked it should
> display a list of available styles, written with the corresponding
> character style. This preview is actually a pixmap generated as follow: a
> text document is used to apply the character style on the name of the
> style. This document is laid out (using the calligra layout engine). then
> the text document is painted on a pixmap. This pixmap is returned to the
> ListView (as decoration role). Before the new layout engine, this was
> working fine. Now it is not.
> I am trying to pinpoint where exacltly the problem lies. My question is as
> follow: is there a way to save or display this pixmap (in the sense of
> kDebug() << variable; allows you to look at values,...) so i can look into
> the generated pixmap?
> 
> Pierre
Yes convert to QImage and save from there
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Qt's minimal dependency (Re: [calligra] /: Merge branch 'mobile-qml-shantanu')

[C. Boemann]

On Friday 13 May 2011 17:44:36 Cyrille Berger Skott wrote:
> Hi,
> 
> We are supposed to be depending only on Qt 4.6, not 4.7. So we either have
> to: * decide to raise our minimum dependency to 4.7
> * or make active only builded when Qt 4.7 is detected

I have no problem with us raising the Qt dependency to 4.7.2

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Usage of libkundo2 in Calligra (Qt's maximal dependency)

[C. Boemann]

On Friday 13 May 2011 19:23:10 Alexander Potashev wrote:
> Hi,
> 
> I've recently "pushed through" a patch to Qt 4.8
> (https://qt.gitorious.org/qt/qt/merge_requests/2610) that will allow
> usage of different text in "Edit -> Undo %1"/"Redo %1" and "Undo
> History" dockwidget. "Undo History" is only implemented in Krita.
> 
> But since this feature will only be available in Qt 4.8, and Calligra
> will probably depend on it in a year, may be it's worth using a
> replacement library to take advantage of the same feature without
> waiting for new release of Qt?
> 
> How to use Qt 4.8's features without Qt 4.8: instead of QUndo* classes
> (it's called Qt's Undo Framework,
> http://doc.trolltech.com/4.7/qundo.html), the whole Calligra can use
> my library libkundo2 (https://github.com/aspotashev/libkundo2) which
> is a fork of Qt's Undo Framework.
> In order to port Calligra to libkundo2, you should run the script
> "forward-port.sh" from libkundo2 repository inside the calligra
> sources' root directory. There is also a script for backward porting
> -- "backward-port.sh". Running "forward-port" and then "backward-port"
> will still give you a diff, because the format of #include-s is not
> uniform throughout Calligra. See that diff in the attached file
> "calligra-includes.diff".
> Besides running the script, you should also link libkundo2's shared
> library to those Calligra's libraries and applications that previously
> used Qt's Undo Framework. You can find the patch doing this in the
> attached file "0001-link-kundo2.patch".
> 
> 
> Why we should use libkundo2 in the whole Calligra, not just in Krita:
> Krita uses the class KoDocument that operates with QUndoStack. If we
> switch Krita to libkundo2, we will have to also switch Calligra's core
> libraries to it, and then the whole Calligra.
> 
> But before starting using libkundo2, we firstly need to add
> dependencies on it to CMakeLists.txt files and probably move
> libkundo2's source code to git.kde.org.
> 
> 
> P.S. The second patch that has been merged to Qt 4.8 is
> https://qt.gitorious.org/qt/qt/merge_requests/1212, libkundo2 also
> fixes that bug.
> P.P.S. I'm doing all this, because Russian translators had a few
> discussions on how text of undoable commands should be translated to
> fit both the "Edit -> Undo %1" commands and the "Undo History" panel
> in Krita, Step and probably some other applications. There are some
> workarounds possible to do in translations (for example, using a
> colon, like "Undo: %1", to indicate that the text of the menu item is
> expected not to be a complete word collocation), but they are not
> perfect.
I don't think our core libraries should depend on an unreleased private 
library. So if we want this I only see two possible routes:

1. get libkundo2 released and wait until all distributions have picked it up 
and released with it. Meaning that qt 4.8 might be available at the same time.

2. add the library inside the Calligra repository.

Casper Boemann
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: In KoTextDocumentLayout::documentChanged update only following pages (fixes loop)

[C. Boemann]

On Sunday 15 May 2011 21:36:48 Sebastian Sauer wrote:
> Hi,
> 
> please see following patch for libs/textlayout/KoTextDocumentLayout.cpp to
> prevent doing full relayouts just cause we update the page-variable.
> 
> This fixes the infinite loop with the
> http://www.zagge.de/anchor/110407/wiki.services.openoffice.org%252Fw%252Fim
> ages%252F9%252F91%252F%25305%25308IG3- SlidesNotesHandouts.odt
> http://www.zagge.de/anchor/110407/wiki.services.openoffice.org%252Fw%252Fim
> ages%252Fe%252Fe6%252F%25303%25304CG- ChartsAndGraphs.odt
> 
> Ok to commit (will remove the #if 0-part + add dox before)?
> 
> diff --git a/libs/textlayout/KoTextDocumentLayout.cpp
> b/libs/textlayout/KoTextDocumentLayout.cpp
> index 71f7b91..0a5ec61 100644
> --- a/libs/textlayout/KoTextDocumentLayout.cpp
> +++ b/libs/textlayout/KoTextDocumentLayout.cpp
> @@ -245,12 +245,21 @@ void KoTextDocumentLayout::documentChanged(int
> position, int charsRemoved, int c
>  from = block.position() + block.length();
>  }
> 
> +#if 0
>  //TODO FIXME make corresponding root area as dirty and then do layout
>  // right now we are just marking all as dirty
>  foreach (KoTextLayoutRootArea *rootArea, d->rootAreaList) {
>  if (!rootArea->isDirty())
>  rootArea->setDirty();
>  }
> +#else
> +KoTextLayoutRootArea *area = rootAreaForPosition(position);
> +if (!area)
> +return;
> +for(int i = qMax(0, d->rootAreaList.indexOf(area)); i < d-
> 
> >rootAreaList.count(); ++i)
> 
> +d->rootAreaList[i]->setDirty();
> +#endif
> +
>  emitLayoutIsDirty();
>  }
> 
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
i think it's should be

qMax(0, d->rootAreaList.indexOf(area) - 1)

as a change on one page might allow it to fit on the previous page

it should also be possible to calc something similar for the last page to loop
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Infinite loop fix that disables the experitmenal iterative mode in KoTextDocumentLayout::positionAnchoredObstructions

[C. Boemann]

On Sunday 15 May 2011 21:40:45 Sebastian Sauer wrote:
> Following patch fixes infinite loops with
> 
> 
http://www.zagge.de/anchor/110407/www.coe.unt.edu%252Fsystem%252Ffiles%252F
> 433%252F833%252FTEKS%2520A2%2520B%2520Cab%2520Ride.docx
> http://www.zagge.de/anchor/110407/www.colfinder.net%252Fmaterials%252FMala
> ria_Course%252Fodt%252FUNIT_6.odt
> http://www.zagge.de/anchor/110407/www.itrainonline.org%252Fitrainonline%25
> 2Fmmtk%252Fwireless_en%252Ffiles_2%2530%25308%252F14_en_wimax-
> and-non-standard-solutions_handout.odt
> 
> We need probably a better long-term solution to still make 20.172 working
> as expected :-/
> 
> Commit, add comment and address later?
> 
> diff --git a/libs/textlayout/KoTextDocumentLayout.cpp
> b/libs/textlayout/KoTextDocumentLayout.cpp
> index 71f7b91..0a5ec61 100644
> --- a/libs/textlayout/KoTextDocumentLayout.cpp
> +++ b/libs/textlayout/KoTextDocumentLayout.cpp
> @@ -346,6 +355,7 @@ void
> KoTextDocumentLayout::positionAnchoredObstructions() }
>  break;
>  case 3: //experimental iterative mode
> +/*
>  // For iterative (20.172) we layout until no more movement is
> happening
>  while (d->anchoringIndex < d->textAnchors.size()) {
>  KoTextAnchor *textAnchor = d->textAnchors[d->anchoringIndex];
> @@ -362,6 +372,7 @@ void
> KoTextDocumentLayout::positionAnchoredObstructions() // move the index to
> next not positioned shape
>  d->anchoringIndex++;
>  }
> +*/
>  break;
>  }
>  }
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
no that is the anchoring code
having anchoring in general is more important than some loops

i'll look tomorrow at the loops
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Random failures in the test kotext-odf-TestChangeTracking

[C. Boemann]

Hi

is this still an issue and, Ganesh have you had a chance to look.

best regards
Casper

On Monday 16 May 2011 18:50:45 Ganesh Paramasivam wrote:
> Hi,
> 
> Looks like saving of delete changes in broken ( and probably not
> related to the random failures ). Will take a look at it.
> Can this wait till the weekend for a fix ?
> 
> Thanks,
> Ganesh
> 
> On Mon, May 16, 2011 at 2:04 PM, Cyrille Berger Skott
> 
>  wrote:
> > Hi,
> > 
> > I now get "permanent" failure in the unit test:
> > http://my.cdash.org/testDetails.php?test=6063659&build=187759
> > 
> > It seems it happened after the merge of the new text layout.
> > 
> > --
> > 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
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel