Git policy: git merge or git cherry-pick

[Lukast dev]

Hello,

I would like to have your opinion about the preferable and consistent way of
merging of the code from the features branches we have into master.

There are more ways:
1. git cherry-picking
a) cherrypick single commits
b) produce one squashed patch for master and commit it

2. git merge

We discussed about it a little, but I think we need more arguments for the
decision.

boud:
o cherry-picking gives the nicest history I think
about merge
o but then the development branch should never be deleted, otherwise
we have one big commit that nobody can every bisect anymore and never
figure out the history of
o if you are going through master trying to find a particular commit
that broke something -- you get big mega commits again

sebsauer:
o cherry-pick'ing is useful if you have only 1-2 commits you like to
take over else, if you like to take over a range or everything, then
just merge. That's at least how I do it :)

Zagge:
o git merge

CyrilleB
o personnaly I go for merging
o then in the master history you get one commit that correspond to the
new feature, and if you want more details you can follow the history
of that commit
o boud: I'd still like the commit message to have the log, though
(example git merge --log origin/words-toc-korinek-tvrdy )

slangkamp
o rebase should also be possible in some cases


Jan, how did you merged your gluepoints branch?
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Git policy: git merge or git cherry-pick

[Lukast dev]

> git checkout master
> git merge flake-odf-gluepoints...
> git pull --rebase
> git push
>
> Ciao Jan

Thanks Jan.

I also did "git merge --log" with the branch with TOC feature.
That --log was suggested by boud, it shows more
verbose commit message.

For the nice commit message you need to
commit with commit messages like:

Introduction for the commit (~75 chars suggested by boud)

More verbose description (unlimited most probably)
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

koabstraction and compiling error

[Lukast dev]

Hello,

would you somebody fix the compilation of the calligra when
apps like words, tables and stage are turned off from compilation?

Krita users/developers usually compile only Krita so this compilation
error occurs [1]
The solution is to turn off the compilation of the koabstraction but
then I think it should
be resolved by cmake automagically if possible.

I think it also applies for the cstester module.

Please, if you can fix it, Krita users will be happy. In the mean time
we will advice users to turn off the
compilation of the modules cstester and koabstraction.

[1] http://forum.kde.org/viewtopic.php?p=187357#p187357
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Suite version number

[Lukast dev]

> While in theory it can be Calligra 1.0 but I am definitely not for
> Kexi 1.0 and Krita 1.0.

+1 from me..
No Krita 1.0, please :)
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: spring cleaning of branches

[Lukast dev]

> remotes/origin/words-toc-korinek-tvrdy

I asked for removing of this one right after the merge process.
I don't know why it is still around, so feel free to remove.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Calligra userbase page

[Lukast dev]

I would not put Flow in Creativity Applications.
I find it office application.

For me creativity category is for creating some form of art.
I haven't seen much art with diagrams yet :)

2011/4/18 Cyrille Berger Skott :
> Hi,
>
> In preparation of the first calligra snapshot release, I have put some flesh
> into our userbase pages:
>
> http://userbase.kde.org/Calligra
> http://userbase.kde.org/Applications/Office#Calligra
>
> Please check for any wrong information. And don't hesitate to put some more
> information.
>
> --
> Cyrille Berger Skott
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

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

[Lukast dev]

I would wait. It's broken.

2011/5/6 Cyrille Berger Skott :
> I did not tag yesterday, because I lost the release script :(
>
> But after seeing this on IRC, I am not sure if we shouldn't wait a little:
>
> 08:26 < Zagge> words is totally broken :-(
> 08:27 < Zagge> boemann: sebsauer: if you type text and come to the bottom of
> the page
>               it deletes all from the current page and starts again
> 08:28 < Zagge> actually it adds more pages but does not show them
>
>
> What do you think ?
>
> --
> 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

Reverting commits

[Lukast dev]

Matus,

please, first discuss the revert with the author and then revert.

Thank you

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

nofill and nostroke support problem

[Lukast dev]

Hello,

Zagge discovered major problem for the nofill, nostroke patch. I would
like to ask you for help
how to make proper support for nofill, nostroke.

Currently I decided to implement the idea to render subpaths
separately so that I can turn off stroke and fill.
But...

> 1. When a shape has a filling and you create a shape with a hole in it like a 
> doughnut it now also fills the hole in the center as both path are handled 
> separately which they should not.

...then the path behaves differently when you setup fill rule [1]. If
I render the path by subpaths (convert them to QPainterPath and put
them in QPainter), the fill rule is broken as the path is not
evaluated correctly.

> 2. If you have a gradient background each subpath shows the full gradient 
> inside itself instead over the complete shape.

I have no idea at all how gradient fills are done.

[1] http://doc.qt.nokia.com/latest/qt.html#FillRule-enum

Have you got idea how to do it correctly?

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

Re: nofill and nostroke support problem

[Lukast dev]

Hello,

so far no response...we had discussion with boemann, so I paste it here,
maybe it will inspire somebody for some idea.


(11:47:40 AM) boemann: LukasT: suggestion: paint fill and outline as two steps
(11:48:13 AM) boemann: if say nostroke the just replace that part of
the path with a move
(11:49:04 AM) boemann: then you can still paint/fill like now but the
disabled part is not drawn

(12:03:52 PM) LukasT: boemann: what do you mean by replace that part
of the path with move?
(12:08:29 PM) boemann: like create a qpainterpath copy but where the
disabled parts are nor drawn
(12:10:16 PM) LukasT: boemann: how to create  qpainterpath copy where
the disabled parts are nor drawn? some pseudo code?
(12:10:43 PM) boemann: well i have not looked at the code in detail
(12:10:47 PM) boemann: or at all
(12:11:08 PM) LukasT: boemann: but I want some pseudo code of :how to
create  qpainterpath copy where the disabled parts are nor drawn:
(12:11:11 PM) boemann: but i assume you have some kind of generic path
you create the qpainterpath from

(12:11:22 PM) LukasT: boemann: we have KoSubpath
(12:11:35 PM) LukasT: boemann: that is set of points which is
converted to QPainterPath
(12:11:57 PM) LukasT: and N KoSubpaths are converted to one
QPainterPath so that fill rule can be evaluated
(12:12:10 PM) boemann: right and then instead of adding that to the
qpainterpath you just do a qpainterpath::moveTo() to the final
position of that subpath
(12:12:11 PM) LukasT: I tried to render the shape per subpath
(12:12:41 PM) boemann: that way you still end up with one qpainterpath
but with subparts disabled
(12:13:04 PM) LukasT: boemann: but how that solves nostroke? nostroke
means that the shape of the subpath is filled but the stroke is not
there

(12:13:29 PM) boemann: yes you need to paint in two steps
(12:13:35 PM) boemann: first fill then stroke
(12:13:46 PM) boemann: and create two different qpainterpaths
(12:13:57 PM) boemann: for stroke moveTo should do
(12:14:03 PM) LukasT: boemann: sounds like a good plan, I will try
(12:14:18 PM) boemann: but for fill you might have to do a lineTo to
get the right result
(12:18:15 PM) LukasT: boemann: I think there might be a problem with
rendering fill and stroke separately
(12:18:23 PM) LukasT: boemann: the order of the shape subpaths
(12:19:14 PM) LukasT: boemann: is important, some part (subpath) of
the shape can cover part of the other subpath's outline
(12:20:37 PM) boemann: hmm
(12:20:47 PM) boemann: true

(12:21:48 PM) boemann: in that case i think there is no other solution
than to implement the fill and draw ourselves
(12:22:08 PM) LukasT: that is complex task
(12:22:40 PM) boemann: sure is
(12:23:00 PM) boemann: better way would be to patch qt
(12:23:21 PM) LukasT: yes
(12:25:43 PM) boemann: i still think the nofill attribute on subpath
level is flawed
(12:25:49 PM) boemann: it just doesn't make sense
(12:30:45 PM) LukasT: boemann: it's like injecting fill rule algorithm :)


These methods gave me some hope for the nofill, nostroke problem
http://doc.qt.nokia.com/latest/qpainterpath.html#toFillPolygons
http://doc.qt.nokia.com/latest/qpainterpath.html#toSubpathPolygons

but I still haven't found what I'm looking for...(read in the melody
of that U2 song)
No solution found :-(

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

enhanced-shape and A,W command definitions

[Lukast dev]

Hello,

I was fixing bug https://bugs.kde.org/show_bug.cgi?id=277540 and I noticed
that OpenOffice and MS Office render the W command differently.

MS Office 2007 rendering
http://wstaw.org/m/2011/07/18/round-callout_ms2007.png

OpenOffice
http://wstaw.org/m/2011/07/18/round-callout_ooo.png

We render like this

Calligra
http://wstaw.org/m/2011/07/18/round_callout_calligra.png

I fixed [1] the problem in bug 277540 in filters, where I changed
the equation of the enhanced path from W to V, so if you open
doc/ppt, the shape is rendered correctly, but from different equation.

But maybe it should be fixed in the EnhancedPathShape?

The specification says that when A (or W) command occurs,
line to is drawn from current point to the starting point of the arc.

OOo and MS2007 probably set the current point to the starting point of the W arc
but calligra sets the current point to 0,0 if the command is first and
no other subpaths
are present.

What is your opinion?

[1] 
http://quickgit.kde.org/?p=calligra.git&a=commit&h=6de876c0abc1d8dc50a6e9a9a360b9c505052b97
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: enhanced-shape and A,W command definitions

[Lukast dev]

Similar problem is with T and U

T
Draws a segment of an ellipse. The ellipse is specified by the
center(x, y), the size(w, h) and the start-angle t0 in degrees and
end-angle t1 in degrees.

U
The same as the “T” command, except that a implied moveto to the
starting point is done.

According my testing OpenOffice handles size(w, h) as major radius and
minor radius.
So that does MS Office 2007 ODF import filter. We handle it as major
and minor diameters.

If I fix the equations in the filters, they are displayed correctly in calligra
but wrongly in OOo and MS Office 2007.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: remove split view functionality

[Lukast dev]

> It's not like other apps all have this feature

For Krita this feature is useful and it is found in Gimp like this : View ->
Add View.
It's not visually the same, you get new float window, but it is view on the
same document.

It will be missed feature, but nobody maintains it and it is very buggy for
a long time,
so I somehow agree with removal.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: [calligra] krita: Port Krita fully to the NG iterators.

[Lukast dev]

Hi,

> This brings up the point that all devs (incl krita) should (i would say must)
> be subscribed to calligra-devel mailing list. It doesn't contain many messages
> besides such important stuff.

I'm subscribed, but from my pov it does sometimes contain quite a lot of mails
and I don't read every e-mail, especially not every review request.

> As a little extra:
>
> git merge --squash 
>
> does the squashing for you and produces a nice commit message with all the
> individual commit messages in one.
>
> all you have to do is:
>
> git commit -a

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

Re: [calligra] libs/pigment/tests: disable the composite op test

[Lukast dev]

Hi,

do we have some mechanism to say : expect_fail ?
That would be better solution and the test would "pass"

Lukas

2013/3/12 Boudewijn Rempt :
> Git commit bbd1958cbf6a628297fe65a3c3e15d7dd69b9a74 by Boudewijn Rempt.
> Committed on 12/03/2013 at 13:02.
> Pushed by rempt into branch 'master'.
>
> disable the composite op test
>
> It needs to be fixed, but we need to get to 0 failures on the buildbot
> first, as discussed in Essen
>
> CCMAIL:calligra-devel@kde.org
> CCMAIL:kimages...@kde.org
>
> M  +1-1libs/pigment/tests/KoRgbU8ColorSpaceTester.h
>
> http://commits.kde.org/calligra/bbd1958cbf6a628297fe65a3c3e15d7dd69b9a74
>
> diff --git a/libs/pigment/tests/KoRgbU8ColorSpaceTester.h 
> b/libs/pigment/tests/KoRgbU8ColorSpaceTester.h
> index 0cce738..241dc7b 100644
> --- a/libs/pigment/tests/KoRgbU8ColorSpaceTester.h
> +++ b/libs/pigment/tests/KoRgbU8ColorSpaceTester.h
> @@ -25,10 +25,10 @@
>  class KoRgbColorSpaceTester : public QObject
>  {
>  Q_OBJECT
> +void testCompositeOps();
>  private slots:
>  void testBasics();
>  void testMixColors();
> -void testCompositeOps();
>  void testCompositeOpsWithChannelFlags();
>  };
>
>
> ___
> 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: Coffice milestone 2

[Lukast dev]

Hello,

great work! Btw why do you ship gdbserver in apk? Because of debug
version? That would be 137kb less ;)
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Callgira 2.7 Beta 2

[Lukast dev]

Hi Friedrich,

> Any reasons against using xz known?

I was wondering if Windows has tools to unpack xz
and yes, 7-zip can do that :)

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

How to merge rebased branch properly?

[Lukast dev]

Hello,

recently I did this command in my branch krita-gmic-ltvrdy:

git pull --rebase origin master

It merged somehow master into my branch and rebased all
commits of branch on top, then when I pushed some new commits,
it also managed to push some commits again (rebased ones)

I had to merge, weird commit that followed
http://quickgit.kde.org/?p=calligra.git&a=commit&h=cb53a2c814b83e55d30bb2963596ff9be7ad8adb

Now I don't know how to merge the branch correctly. Command:

git merge krita-gmic-ltvrdy

replays all the commits from branch on top again...I just wanted to have
merging commit.
I think it is not ok, the rebase step was huge mistake of mine :-/

Can you suggest correct way to merge feature branch in this case?
Should I squash the commit like this
http://stackoverflow.com/a/5309051/1068199?

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

Re: How to merge rebased branch properly?

[Lukast dev]

DmitryK mentioned some other possibility to preserve history, to create
another branch and merge that new branch.

I would like to preserve the commits as I dropped some code that might be
needed again and squash will destroy history
of the branch.

Dmitry,can you explain the solution with more details (git commands
ideally)? What should be done to preserve history and have easy merge?

Lukas


2013/9/7 Cyrille Berger 

> Yes, never rebase commits that have already been pushed (git should not
> even let you do that), and yes the calligra policy is to merge-squash.
>
> --
> Cyrille Berger Skott
> __**_
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/**listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: How to merge rebased branch properly?

[Lukast dev]

Hello,

thanks DmitryK, I tried your advice. The problem occured when I did

git pull --rebase

There many conflicts arised due to duplicated commits.
So I did
git rebase --abort and
git rebase -i

and I dropped all the duplicated commits and pushed.I did not squash the
commits, I'm sorry about that. Next time I will
be more careful -- this way I'm sure no other commits of others are lost.

Lukas


2013/9/8 Dmitry Kazakov 

> Hi, Lukas!
>
> The only problem of a rebasing a pushed branch is that you cannot push it
> again due to non-fast-forward-merge. If your commits are not destroyed by
> the rebase (that could happen with merge commits actually) you can still
> push them into repository, but under a different HEAD.
>
> So to do that you should:
>
> 1) git checkout krita-gmic-ltvrdy # checkout to your rebased branch
> 2) git checkout -b krita-gmic-ltvrdy-2nd-try # create a new branch, so
> that no conflicts would happen
> 3) git push origin krita-gmic-ltvrdy-2nd-try
>
> After that, if you think you commits in the branch are ok and bisectable,
> you can merge this branch to master as usual.
>
>
>
>
> On Sun, Sep 8, 2013 at 2:42 PM, Lukast dev  wrote:
>
>> DmitryK mentioned some other possibility to preserve history, to create
>> another branch and merge that new branch.
>>
>> I would like to preserve the commits as I dropped some code that might be
>> needed again and squash will destroy history
>> of the branch.
>>
>> Dmitry,can you explain the solution with more details (git commands
>> ideally)? What should be done to preserve history and have easy merge?
>>
>> Lukas
>>
>>
>> 2013/9/7 Cyrille Berger 
>>
>>> Yes, never rebase commits that have already been pushed (git should not
>>> even let you do that), and yes the calligra policy is to merge-squash.
>>>
>>> --
>>> Cyrille Berger Skott
>>> __**_
>>> calligra-devel mailing list
>>> calligra-devel@kde.org
>>> https://mail.kde.org/mailman/**listinfo/calligra-devel<https://mail.kde.org/mailman/listinfo/calligra-devel>
>>>
>>
>>
>> ___
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>>
>
>
> --
> Dmitry Kazakov
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: [calligra] krita/plugins/extensions/gmic: Fix typo

[Lukast dev]

Hi Yuri,

please, do not change gmic copy in krita extension.
It will be synced with upstream releases in the future and your commits
will be lost.
Please commit to upstream at http://gmic.sourceforge.net

Thanks
Lukas


2013/10/21 Yuri Chornoivan 

> Git commit cce64b6094eb5eccb4213aa826a5e77a335af233 by Yuri Chornoivan.
> Committed on 21/10/2013 at 04:43.
> Pushed by yurchor into branch 'master'.
>
> Fix typo
>
> M  +1-1krita/plugins/extensions/gmic/gmic.cpp
>
> http://commits.kde.org/calligra/cce64b6094eb5eccb4213aa826a5e77a335af233
>
> diff --git a/krita/plugins/extensions/gmic/gmic.cpp
> b/krita/plugins/extensions/gmic/gmic.cpp
> index 33d41f5..ba83331 100644
> --- a/krita/plugins/extensions/gmic/gmic.cpp
> +++ b/krita/plugins/extensions/gmic/gmic.cpp
> @@ -1415,7 +1415,7 @@ inline unsigned int gmic_hashcode(const char *const
> str, const bool is_variable)
>return hash&255;
>  }
>
> -// Tells if the the implementation of a G'MIC command contains arguments.
> +// Tells if the implementation of a G'MIC command contains arguments.
>  //
>  inline bool gmic_command_has_arguments(const char *const command) {
>if (!command || !*command) return false;
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel