Question about ownership of KoShape

[Dmitry Kazakov]

Hi, all!

As some of you may already know, at the moment I'm working on adding
support of SVG to Krita. Obviously enough I use Flake as a internal
representation/rendering engine. And, yes, I base my work on SvgParser
class started by Jan Hambrecht in 2011.

Right now my main question is: who owns all the shapes in the document? As
far as I could understand, group shapes do not own them. So the question
seems to be a bit tough for me...

My guess is that the shapes are owned by KoShapeManager... If so, how
KoShapePainter should work? It has in internal shape manager that will
delete all the shapes after each painting. How can it be solved?

And the most interesting part:

SVG standard supports / paradigm [1]. Which allows one shape to
have multiple instances in different parts of the document. How can it be
solved within KoFlake? Copy-constructors are not allowed in KoShape, the
management is not reference counted. How can I solve the thing?

[1] - https://www.w3.org/TR/SVG/struct.html#UseElement

-- 
Dmitry Kazakov

Re: Calligra development wiki migrated and cleaned up, plus one proposal

[Dmitry Kazakov]

What is the blinking advertisement on the top-right corner? Is it about
calligra? And how costs and commits history is calculated? I guess, Krita
has more than 5 years history ;)


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

Re: Calligra development wiki migrated and cleaned up, plus one proposal

[Dmitry Kazakov]

On Sun, Dec 19, 2010 at 2:56 PM, Jaroslaw Staniek  wrote:

> On 19 December 2010 12:37, Dmitry Kazakov  wrote:
> > What is the blinking advertisement on the top-right corner? Is it about
> > calligra? And how costs and commits history is calculated?
>
> See https://www.ohloh.net/p/predicate for details.
> At contributors page you may see yourself, and you can login, claim
> that's yourself and share with outside world details about development
> if you care (e.g. tools you use for developing).
>
> >  I guess, Krita has more than 5 years history ;)
>
> True. It's 5-year moving window.
>
>
Ah, ok =)

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

Re: Developer Sprint

[Dmitry Kazakov]

>
> I will contact Claudia from the e.V. to help us with that part. For getting
> a
> visa I think we need to have a date fixed. So lets try to do that until at
> least mid of January.
>

I'm afraid the mid of January may be a bit late for that. For German Embassy
we need an original of the letter, so it must be sent via snail mail. So at
least two weeks are needed for transferring the letter, plus two weeks for
making visa at the embassy.

Btw, for not waiting the date fixed, the letter, i guess, may contain
something like "invited for 7 days in the period from 24.02 through 05.04".
I'm not sure about the exact wording, but that's the idea.

And one more point. The snail-mail letter should be sent as Registered
letter, otherwise it'll be lost somewhere on the border :(

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

Re: 2.8.x maintenance plan and 2.9 ?

[Dmitry Kazakov]

Oh, and we haven't backported the bugfixes for Krita yet...


On Thu, Jul 3, 2014 at 2:48 AM, Jaroslaw Staniek  wrote:

> OK, Changed the announcement (draft) to 2.8.5, added "Why is 2.8.4
> skipped?" section to the draft.
>
> One missing bit is Krita changelog.
>
>
> On 30 June 2014 00:09, Jaroslaw Staniek  wrote:
>
>> OK,
>> Updated http://community.kde.org/Calligra/Schedules/2.8/Release_Plan
>> and added a draft
>> http://community.kde.org/Calligra/Schedules/2.9/Release_Plan
>>
>> On 24 June 2014 14:16, Boudewijn Rempt  wrote:
>> > There is also an issue with the save as file dialogs in 2.8.4 that
>> needs to
>> > be fixed.
>> >
>> >
>> > On Tue, 24 Jun 2014, Jaroslaw Staniek wrote:
>> >
>> >> +1 for 2.8.5, there are plans for Kexi definitely :)
>> >>
>> >> On 24 June 2014 13:52, Cyrille Berger  wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> We never quiet reached a conclusive answer to that thread... But
>> since it
>> >>> is
>> >>> getting "late", I guess we would go for my original suggestion:
>> >>>
>> >>> - branch early august, around August 10th
>> >>> - release final in September
>> >>>
>> >>> Also, since the 2.8 branch seem to still be rather active, I guess we
>> >>> could
>> >>> schedule a 2.8.5 for early August.
>> >>>
>> >>> --
>> >>> Cyrille Berger Skott
>> >>>
>> >>> ___
>> >>> calligra-devel mailing list
>> >>> calligra-devel@kde.org
>> >>> https://mail.kde.org/mailman/listinfo/calligra-devel
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> regards / pozdrawiam, Jaroslaw Staniek
>> >> Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
>> >> Qt for Tizen | http://qt-project.org/wiki/Tizen
>> >> Qt Certified Specialist | http://www.linkedin.com/in/jstaniek
>> >> ___
>> >> 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
>>
>>
>>
>> --
>> regards / pozdrawiam, Jaroslaw Staniek
>>  Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
>>  Qt for Tizen | http://qt-project.org/wiki/Tizen
>>  Qt Certified Specialist | http://www.linkedin.com/in/jstaniek
>>
>
>
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
>  Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
>  Qt for Tizen | http://qt-project.org/wiki/Tizen
>  Qt Certified Specialist | http://www.linkedin.com/in/jstaniek
>
> ___
> 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

Re: Review Request 119224: Fix Krita speed sensor

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119224/#review62133
---


Hi, Sven!

This patch is effectively an equivalent of the following patch:
http://paste.kde.org/poktyzric

Of course, except that the variable should not be static, but put into 
d->currentDistanceInfo. Your patch just creates one more timer, which is 
excessive, since we already have a timer in KisFreehandToolHelper and which is 
already used for all speed calculations.

The patch doesn't solve the real cause of the speed sensor being broken. The 
speed doesn't work because we should fetch the time data from the XInput/Wintab 
event directly, instead of running a timer in parallel. The trick is that on 
both windows and linux the packets are coming in chunks and Qt's event loop 
processes the whole chunk of packets in one go. So measuring time with a timer 
gives the same time for the whole chunk, which is not what we need.

I'm ok with introducing a limitation you proposed (timeDiff > 5 msec), but the 
second timer is not needed. Everything can be implemented inside 
KisPaintInformation.

- Dmitry Kazakov


On Июль 11, 2014, 3:30 д.п., Sven Langkamp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119224/
> ---
> 
> (Updated Июль 11, 2014, 3:30 д.п.)
> 
> 
> Review request for Calligra, Dmitry Kazakov and Boudewijn Rempt.
> 
> 
> Bugs: 325423
> http://bugs.kde.org/show_bug.cgi?id=325423
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> The speed sensor is currently broken. The problem is that the speed is 
> calculated with the distance and time difference each dab and the previous 
> one. When the space between the dabs becomes to small the calculation breakes 
> and falls back to a constant value.
> 
> The patch fixes the problem by calculating the speed of every event and then 
> interpolating the speed between them. It also makes sure that there a minimum 
> time difference between the measurements.
> 
> 
> Diffs
> -
> 
>   krita/image/brushengine/kis_paint_information.h 9b3be8f 
>   krita/image/brushengine/kis_paint_information.cc 952f51f 
>   krita/ui/tool/kis_painting_information_builder.h 993c25b 
>   krita/ui/tool/kis_painting_information_builder.cpp 6e3d19a 
> 
> Diff: https://git.reviewboard.kde.org/r/119224/diff/
> 
> 
> Testing
> ---
> 
> Tested by painting in Krita and appears to work. Needs further testing to see 
> if it gives the expected results.
> 
> 
> Thanks,
> 
> Sven Langkamp
> 
>

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

Re: Review Request 119244: _C symbol breaks compilation on OpenBSD

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119244/#review62232
---

Ship it!


Hi, Vadim!

Thanks for a nice catch! Can you push the patch into master or we should do it 
on bahalf you you?

- Dmitry Kazakov


On Июль 12, 2014, 11:54 д.п., Vadim Zhukov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119244/
> ---
> 
> (Updated Июль 12, 2014, 11:54 д.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> The C (and therefore C++) standard mandates that symbol names starting by 
> underscore ("_") sign are reserved and should not be used in applications. 
> The kis_painter.cc uses "_C" and this breaks compilation on OpenBSD. The 
> solution is renaming variables involved.
> 
> Please note that I do not have commit rights in KDE repos, so someone else 
> should commit this patch if it gets accepted. Thanks.
> 
> 
> Diffs
> -
> 
>   krita/image/kis_painter.cc 4d40214 
> 
> Diff: https://git.reviewboard.kde.org/r/119244/diff/
> 
> 
> Testing
> ---
> 
> OpenBSD/i386-CURRENT, KDE 4.13.2
> 
> 
> Thanks,
> 
> Vadim Zhukov
> 
>

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

Re: Review Request 119244: _C symbol breaks compilation on OpenBSD

[Dmitry Kazakov]

> On Июль 13, 2014, 8:40 д.п., Dmitry Kazakov wrote:
> > Hi, Vadim!
> > 
> > Thanks for a nice catch! Can you push the patch into master or we should do 
> > it on bahalf you you?

Oh, I read till the end. I'll push it now.


- Dmitry


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119244/#review62232
---


On Июль 12, 2014, 11:54 д.п., Vadim Zhukov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119244/
> ---
> 
> (Updated Июль 12, 2014, 11:54 д.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> The C (and therefore C++) standard mandates that symbol names starting by 
> underscore ("_") sign are reserved and should not be used in applications. 
> The kis_painter.cc uses "_C" and this breaks compilation on OpenBSD. The 
> solution is renaming variables involved.
> 
> Please note that I do not have commit rights in KDE repos, so someone else 
> should commit this patch if it gets accepted. Thanks.
> 
> 
> Diffs
> -
> 
>   krita/image/kis_painter.cc 4d40214 
> 
> Diff: https://git.reviewboard.kde.org/r/119244/diff/
> 
> 
> Testing
> ---
> 
> OpenBSD/i386-CURRENT, KDE 4.13.2
> 
> 
> Thanks,
> 
> Vadim Zhukov
> 
>

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

Review Request 119569: Fixed recognition of the Wacom Stylus serial id

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119569/
---

Review request for Calligra and Boudewijn Rempt.


Repository: calligra


Description
---

This patch does two fixes:

1) Implements fetching of the stylus ID using X11 properties, instead of using 
'libwacomcfg', which has been deprecated long ago (and not shipped with any 
known distributions anymore).

Qt 4.8 still has code for fetching this library dynamically on the fly but 
surely enough it doesn't work (serial is always 0), because the library is 
deprecated. I cannot tell exactly what is the status in Qt5.

2) Removed the event filter from the KoToolManager. Installing this event 
filter purely for calling switchInputDevice() is useless, because 
switchInputDevice() will be called later in the event handlers. So we won't do 
the work twice.


Diffs
-

  krita/ui/input/wintab/kis_tablet_support_x11.cpp 3670380 
  krita/ui/input/wintab/wacom-properties.h PRE-CREATION 
  krita/ui/input/wintab/wacomcfg.h 03528df 
  libs/flake/KoToolManager.h 17b718e 
  libs/flake/KoToolManager.cpp 2990b62 

Diff: https://git.reviewboard.kde.org/r/119569/diff/


Testing
---

Tested in Krita


Thanks,

Dmitry Kazakov

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

Re: Review Request 119569: Fixed recognition of the Wacom Stylus serial id

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119569/
---

(Updated Aug. 4, 2014, 7:35 p.m.)


Status
--

This change has been marked as submitted.


Review request for Calligra and Boudewijn Rempt.


Repository: calligra


Description
---

This patch does two fixes:

1) Implements fetching of the stylus ID using X11 properties, instead of using 
'libwacomcfg', which has been deprecated long ago (and not shipped with any 
known distributions anymore).

Qt 4.8 still has code for fetching this library dynamically on the fly but 
surely enough it doesn't work (serial is always 0), because the library is 
deprecated. I cannot tell exactly what is the status in Qt5.

2) Removed the event filter from the KoToolManager. Installing this event 
filter purely for calling switchInputDevice() is useless, because 
switchInputDevice() will be called later in the event handlers. So we won't do 
the work twice.


Diffs
-

  krita/ui/input/wintab/kis_tablet_support_x11.cpp 3670380 
  krita/ui/input/wintab/wacom-properties.h PRE-CREATION 
  krita/ui/input/wintab/wacomcfg.h 03528df 
  libs/flake/KoToolManager.h 17b718e 
  libs/flake/KoToolManager.cpp 2990b62 

Diff: https://git.reviewboard.kde.org/r/119569/diff/


Testing
---

Tested in Krita


Thanks,

Dmitry Kazakov

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

Re: Review Request 119609: Animation support in Krita

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119609/#review64052
---



krita/ui/kis_doc2.h
<https://git.reviewboard.kde.org/r/119609/#comment44691>

This variable looks suspicious. Do you really need to store any layer here?


- Dmitry Kazakov


On Авг. 8, 2014, 11:02 д.п., Somsubhra Bairi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119609/
> ---
> 
> (Updated Авг. 8, 2014, 11:02 д.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Animation support in Krita.
> This is a full diff of the 'animator-plugin-somsubhra' branch.
> 
> 
> Diffs
> -
> 
>   krita/ui/widgets/kis_animation_selector.h PRE-CREATION 
>   krita/ui/widgets/kis_animation_selector.cpp PRE-CREATION 
>   libs/main/KoDocument.cpp e452edb 
>   krita/ui/kis_onion_skin_loader.h PRE-CREATION 
>   krita/ui/kis_onion_skin_loader.cpp PRE-CREATION 
>   krita/ui/kranim/kis_kranim_loader.h PRE-CREATION 
>   krita/ui/kranim/kis_kranim_loader.cpp PRE-CREATION 
>   krita/ui/kranim/kis_kranim_saver.h PRE-CREATION 
>   krita/ui/kranim/kis_kranim_saver.cpp PRE-CREATION 
>   krita/ui/kranim/kis_kranim_tags.h PRE-CREATION 
>   krita/ui/kranimstore/kis_animation_store.h PRE-CREATION 
>   krita/ui/kranimstore/kis_animation_store.cpp PRE-CREATION 
>   krita/ui/kranimstore/kis_animation_store_writer.h PRE-CREATION 
>   krita/plugins/formats/kranimseq/kranim_sequence.h PRE-CREATION 
>   krita/plugins/formats/kranimseq/kranim_sequence.cpp PRE-CREATION 
>   krita/plugins/formats/kranimseq/kranimseq_export.desktop PRE-CREATION 
>   krita/plugins/formats/kranimseq/sequence_generator.h PRE-CREATION 
>   krita/plugins/formats/kranimseq/sequence_generator.cpp PRE-CREATION 
>   krita/ui/CMakeLists.txt 02a9509 
>   krita/ui/forms/wdganimationselector.ui PRE-CREATION 
>   krita/ui/kis_animation.h PRE-CREATION 
>   krita/ui/kis_animation.cpp PRE-CREATION 
>   krita/ui/kis_animation_doc.h PRE-CREATION 
>   krita/ui/kis_animation_doc.cpp PRE-CREATION 
>   krita/ui/kis_animation_factory.h PRE-CREATION 
>   krita/ui/kis_animation_factory.cpp PRE-CREATION 
>   krita/ui/kis_animation_part.h PRE-CREATION 
>   krita/ui/kis_animation_part.cpp PRE-CREATION 
>   krita/ui/kis_animation_player.h PRE-CREATION 
>   krita/ui/kis_animation_player.cpp PRE-CREATION 
>   krita/ui/kis_animator_aboutdata.h PRE-CREATION 
>   krita/ui/kis_config.h 18a80f4 
>   krita/ui/kis_config.cc 815fe56 
>   krita/ui/kis_doc2.h 5f9a62f 
>   krita/ui/kis_doc2.cc a33a0e5 
>   krita/plugins/extensions/dockers/animator/onionskin_dock.h PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/onionskin_dock.cpp PRE-CREATION 
>   krita/plugins/formats/CMakeLists.txt defea52 
>   krita/plugins/formats/kranimseq/CMakeLists.txt PRE-CREATION 
>   krita/plugins/formats/kranimseq/kis_wdg_options_kranimseq.ui PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/animator_settings_dialog.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/animator_settings_dialog.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_animation_frame.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_animation_frame.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_animation_layer.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_animation_layer.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_animation_layerbox.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_animation_layerbox.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_frame_box.h PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_frame_box.cpp PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_layer_contents.h PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_layer_contents.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_opacity_selector.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_opacity_selector.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_opacity_selector_view.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_opacity_selector_view.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_timeline.h PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_timeline.cpp PRE-

Re: Review Request 119609: Animation support in Krita

[Dmitry Kazakov]

> On Авг. 8, 2014, 11:27 д.п., Dmitry Kazakov wrote:
> > krita/ui/kis_doc2.h, line 187
> > <https://git.reviewboard.kde.org/r/119609/diff/2/?file=302163#file302163line187>
> >
> > This variable looks suspicious. Do you really need to store any layer 
> > here?
> 
> Somsubhra Bairi wrote:
> This can be avoided if we can get hold of the the root layer of the 
> document's image instance. I tried KisImage::rootLayer() and KisImage::root() 
> but it didn't work in my case.

What do you mean by "get hold"? The root layer is always stored in both 
KisImage::root() and KisImage::rootLayer(). They both return the same object by 
via a different pointer type. What is the problem with it?


- Dmitry


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119609/#review64052
---


On Авг. 8, 2014, 11:02 д.п., Somsubhra Bairi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119609/
> ---
> 
> (Updated Авг. 8, 2014, 11:02 д.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Animation support in Krita.
> This is a full diff of the 'animator-plugin-somsubhra' branch.
> 
> 
> Diffs
> -
> 
>   krita/ui/widgets/kis_animation_selector.h PRE-CREATION 
>   krita/ui/widgets/kis_animation_selector.cpp PRE-CREATION 
>   libs/main/KoDocument.cpp e452edb 
>   krita/ui/kis_onion_skin_loader.h PRE-CREATION 
>   krita/ui/kis_onion_skin_loader.cpp PRE-CREATION 
>   krita/ui/kranim/kis_kranim_loader.h PRE-CREATION 
>   krita/ui/kranim/kis_kranim_loader.cpp PRE-CREATION 
>   krita/ui/kranim/kis_kranim_saver.h PRE-CREATION 
>   krita/ui/kranim/kis_kranim_saver.cpp PRE-CREATION 
>   krita/ui/kranim/kis_kranim_tags.h PRE-CREATION 
>   krita/ui/kranimstore/kis_animation_store.h PRE-CREATION 
>   krita/ui/kranimstore/kis_animation_store.cpp PRE-CREATION 
>   krita/ui/kranimstore/kis_animation_store_writer.h PRE-CREATION 
>   krita/plugins/formats/kranimseq/kranim_sequence.h PRE-CREATION 
>   krita/plugins/formats/kranimseq/kranim_sequence.cpp PRE-CREATION 
>   krita/plugins/formats/kranimseq/kranimseq_export.desktop PRE-CREATION 
>   krita/plugins/formats/kranimseq/sequence_generator.h PRE-CREATION 
>   krita/plugins/formats/kranimseq/sequence_generator.cpp PRE-CREATION 
>   krita/ui/CMakeLists.txt 02a9509 
>   krita/ui/forms/wdganimationselector.ui PRE-CREATION 
>   krita/ui/kis_animation.h PRE-CREATION 
>   krita/ui/kis_animation.cpp PRE-CREATION 
>   krita/ui/kis_animation_doc.h PRE-CREATION 
>   krita/ui/kis_animation_doc.cpp PRE-CREATION 
>   krita/ui/kis_animation_factory.h PRE-CREATION 
>   krita/ui/kis_animation_factory.cpp PRE-CREATION 
>   krita/ui/kis_animation_part.h PRE-CREATION 
>   krita/ui/kis_animation_part.cpp PRE-CREATION 
>   krita/ui/kis_animation_player.h PRE-CREATION 
>   krita/ui/kis_animation_player.cpp PRE-CREATION 
>   krita/ui/kis_animator_aboutdata.h PRE-CREATION 
>   krita/ui/kis_config.h 18a80f4 
>   krita/ui/kis_config.cc 815fe56 
>   krita/ui/kis_doc2.h 5f9a62f 
>   krita/ui/kis_doc2.cc a33a0e5 
>   krita/plugins/extensions/dockers/animator/onionskin_dock.h PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/onionskin_dock.cpp PRE-CREATION 
>   krita/plugins/formats/CMakeLists.txt defea52 
>   krita/plugins/formats/kranimseq/CMakeLists.txt PRE-CREATION 
>   krita/plugins/formats/kranimseq/kis_wdg_options_kranimseq.ui PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/animator_settings_dialog.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/animator_settings_dialog.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_animation_frame.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_animation_frame.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_animation_layer.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_animation_layer.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_animation_layerbox.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_animation_layerbox.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_frame_box.h PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_frame_box.cpp PRE-CREATION 
>   krita/plugins/extensions/dockers/animator/kis_layer_contents.h PRE-CREATION 
>   krita/plugins/ext

Re: Review Request 119677: Show the Cursor Pos and FG Color in statusbar

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119677/#review64141
---


Hi, Latte!

Your patch is really cool, but there is one issue that we should fix before we 
can allow it to go to master.

We had the cursor position in the status bar before, but we disabled it due to 
performance issues. The point is, wacom tablet devices have quite a high 
resolution, so the application gets too many mouse move events, and, therefore 
eats too much CPU power if we try to display the coordinate on every event. The 
same applies to displaying current color. If we try to update the color on 
every event, the UI will choke when the user starts color picking with a tablet 
device.

Now we have a canned solution for that. You just need to connect the signal not 
directly to the slot, but using KisSignalCompressor object. This object will 
ensure that the signal is delivered not more often than, say, once in 100ms. 
The user will not see any delay, but the system will not choke with the events.

You can find an example of how KisSignalCompressor will be used in 
KisColorSelector class. You will probably want to use higher delay values, e.g. 
100ms, because you don't need real-time feedback here.

PS:
And just to add to what Sven said about coding style, here is a nice document 
about it:
https://techbase.kde.org/Policies/Kdelibs_Coding_Style

- Dmitry Kazakov


On Авг. 9, 2014, 11:22 д.п., Latte OfCode wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119677/
> ---
> 
> (Updated Авг. 9, 2014, 11:22 д.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Two changes to statusbar: 1) Show cursor location, 2) Show foreground color
> 
> 
> Diffs
> -
> 
>   krita/ui/kis_statusbar.h 5b5c74e 
>   krita/ui/kis_statusbar.cc 7f57007 
> 
> Diff: https://git.reviewboard.kde.org/r/119677/diff/
> 
> 
> Testing
> ---
> 
> Built Krita successfully after making changes. Tested added functionality.
> 
> 
> Thanks,
> 
> Latte OfCode
> 
>

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

Re: Normalizing connections in calligra

[Dmitry Kazakov]

Hi, Jaroslaw!

If it touches KisView2, you'd better wait until Boud merges his MVC branch
into master. We have a Krita-wide freeze for that right now. And Boud will
be back in two weeks.


On Wed, Sep 3, 2014 at 2:55 AM, Jaroslaw Staniek  wrote:

> Hi,
> Are you OK with me pushing signal/slot connection normalizations
> performed this tool for entire calligra master?
> There are 174 files that would be fixed. The result is consistency and
> micro-speed up.
>
> https://qt.gitorious.org/qt/qt/source/util/normalize/README
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
>  Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
>  Qt for Tizen | http://qt-project.org/wiki/Tizen
>  Qt Certified Specialist | http://www.linkedin.com/in/jstaniek
> ___
> 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

Re: Review Request 119183: A HSV color slider docker.

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119183/#review66460
---


There is some weirdness when the sliders has extreem values:

1) Set color to H:300, S:100, L:90, then try to use mouse wheel on any of the 
sliders
2) Mouse Wheel over H set to 360 looks weird :) (minor bug)

- Dmitry Kazakov


On Сен. 13, 2014, 9:04 п.п., Wolthera van Hövell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119183/
> ---
> 
> (Updated Сен. 13, 2014, 9:04 п.п.)
> 
> 
> Review request for Calligra, Dmitry Kazakov and Boudewijn Rempt.
> 
> 
> Bugs: https://bugs.kde.org/show_bug.cgi?id=313787
> 
> http://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=313787
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> I have been working on this https://bugs.kde.org/show_bug.cgi?id=313787.
> 
> This patch adds a color sliders docker to Krita.
> The intention is to eventually get to a docker that can can be modified 
> through the preferences, so one could have only saturation sliders, or two 
> saturations sliders and a value slider.
> This docker is only intended for derived models, where the specific colour 
> selector is for actual colour spaces.
> 
> 
> Diffs
> -
> 
>   krita/plugins/extensions/dockers/CMakeLists.txt f94eb44 
>   
> krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_settings.cpp
>  f171c2e 
>   
> krita/plugins/extensions/dockers/advancedcolorselector/wdg_color_selector_settings.ui
>  dbe9070 
>   krita/plugins/extensions/dockers/colorslider/CMakeLists.txt PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_dock.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_dock.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_input.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_input.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_widget.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_widget.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_hsv_slider.h PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_hsv_slider.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/krita_colorslider.desktop 
> PRE-CREATION 
>   libs/pigment/KoColorConversions.cpp fc7954b 
> 
> Diff: https://git.reviewboard.kde.org/r/119183/diff/
> 
> 
> Testing
> ---
> 
> A lot, no user testing, there's still a handful of open bugs.
> We have 12 sliders, for each of the HSX colour models.
> It compiles, and it doesn't crash.
> * ~~Kocolorsliders wasn't intended for HSX, so we'll need to write a new 
> widget for HSX.~~[done]
> * ~~For now, all 12 sliders show up using kocolor sliders. I have managed to 
> prevent it from zealously updating everything else, so it doesn't break other 
> things.~~ [Thanks to the fix by dmitry on the specific colour selector, this 
> has been fixed]
> * ~~The number-input is broken. Half of the time~~ [fixed, I made it so that 
> it will only change after loosing focus]
> * ~~So is the slider input itself, I suspect this is rounding errors again, 
> and will have to adjust the self-update, like I did for the colour palette.~~ 
> We need to increase the precision of all the algoritms.
> * ~~Config still needs to be put in.[done, however, after the config is 
> changed, it doesn't re-update the docker again, on restart the update takes 
> place.]~~[done]
> * ~~There's still licenses missing~~[done]
> * ~~The code is a bloody mess.~
> * ~~There's a bug in the hsy and hsi code I wrote, but there's also bugs in 
> the qt hsv and hsl code(gray in particular is strange) I'll chase these down 
> with increasing the precision.~~ Fixed.
> * There's some awkwardness between the different colour models updating 
> eachother, leading to slider-dancing. Hopefull this'll be fixed with 
> precision increase.
> * The sliders don't update properly on LUT changes. This also happens in the 
> specific colour selector.
> I want to do these last tw

Re: Review Request 120191: Allow to have more than one zoom widget

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120191/#review66463
---

Ship it!


The patch looks fine to me. Both codewise and how it works in Krita.

- Dmitry Kazakov


On Сен. 14, 2014, 1:02 д.п., Sven Langkamp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120191/
> ---
> 
> (Updated Сен. 14, 2014, 1:02 д.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> The patch splits the zoom widget out of the zoom action and connects with via 
> signals and slots. That allows to have more than one zoom widget.
> 
> 
> Diffs
> -
> 
>   krita/plugins/extensions/dockers/overview/overviewdocker_dock.h e24a5e7 
>   krita/plugins/extensions/dockers/overview/overviewdocker_dock.cpp 1eeec3a 
>   libs/widgets/CMakeLists.txt f825569 
>   libs/widgets/KoZoomAction.h eba88ad 
>   libs/widgets/KoZoomAction.cpp 3035a74 
>   libs/widgets/KoZoomWidget.h PRE-CREATION 
>   libs/widgets/KoZoomWidget.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/120191/diff/
> 
> 
> Testing
> ---
> 
> Tested with an additional zoom widget in the Krita overview docker.
> 
> 
> Thanks,
> 
> Sven Langkamp
> 
>

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

Re: Review Request 119183: A HSV color slider docker.

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119183/#review66476
---


There are a few minor issues:

1) Coding style, which can be fixed using 'astyle' (see a comment below)
2) Saving of booleans into config file is usually done via integers.

When it is fixed, the patch is ok to go to master.


krita/plugins/extensions/dockers/colorslider/kis_color_slider.h
<https://git.reviewboard.kde.org/r/119183/#comment46345>

Better change the docs :)



krita/plugins/extensions/dockers/colorslider/kis_color_slider_dock.cpp
<https://git.reviewboard.kde.org/r/119183/#comment46347>

This break KDE coding style policies:
https://techbase.kde.org/Policies/Library_Code_Policy

Actually you can simplify these blocks of code quite easily, since C++ 
operator == returns bool:

m_SlidersConfigArray[0] = hsvH == "true";

It is also common to save boolean values into KConfigGroup as integer, 
instead of strings, because C++ automatically converts 0,1 <-> false,true.

In such a case your code will look extremely simple:

m_SlidersConfigArray[0] = cfg.readEntry("hsvH", 0);

Until no user has these options as strings, it is safe to change it to 
integers :)



krita/plugins/extensions/dockers/colorslider/kis_color_slider_widget.cpp
<https://git.reviewboard.kde.org/r/119183/#comment46349>

This is also not KDE-style :(

Probably, you could run astyle on your files to get them right.


https://techbase.kde.org/Policies/Kdelibs_Coding_Style#Artistic_Style_.28astyle.29_automatic_code_formatting



krita/plugins/extensions/dockers/colorslider/kis_color_slider_widget.cpp
<https://git.reviewboard.kde.org/r/119183/#comment46348>

The same as previous comment


- Dmitry Kazakov


On Сен. 13, 2014, 9:04 п.п., Wolthera van Hövell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119183/
> ---
> 
> (Updated Сен. 13, 2014, 9:04 п.п.)
> 
> 
> Review request for Calligra, Dmitry Kazakov and Boudewijn Rempt.
> 
> 
> Bugs: https://bugs.kde.org/show_bug.cgi?id=313787
> 
> http://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=313787
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> I have been working on this https://bugs.kde.org/show_bug.cgi?id=313787.
> 
> This patch adds a color sliders docker to Krita.
> The intention is to eventually get to a docker that can can be modified 
> through the preferences, so one could have only saturation sliders, or two 
> saturations sliders and a value slider.
> This docker is only intended for derived models, where the specific colour 
> selector is for actual colour spaces.
> 
> 
> Diffs
> -
> 
>   krita/plugins/extensions/dockers/CMakeLists.txt f94eb44 
>   
> krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_settings.cpp
>  f171c2e 
>   
> krita/plugins/extensions/dockers/advancedcolorselector/wdg_color_selector_settings.ui
>  dbe9070 
>   krita/plugins/extensions/dockers/colorslider/CMakeLists.txt PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_dock.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_dock.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_input.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_input.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_widget.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_widget.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_hsv_slider.h PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_hsv_slider.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/krita_colorslider.desktop 
> PRE-CREATION 
>   libs/pigment/KoColorConversions.cpp fc7954b 
> 
> Diff: https://git.reviewboard.kde.org/r/119183/diff/
> 
> 
> Testing
> ---
> 
> A lot, no user testing, there's still a handful of open bugs.
> We have 12 sliders, for each of the HSX colour models.
> It compiles, and it doesn't crash.
> * ~~Kocolorsliders wasn't intended for HSX, so we&#

Re: Review Request 119183: A HSV color slider docker.

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119183/#review66582
---

Ship it!


Ship It!

- Dmitry Kazakov


On Sept. 15, 2014, 2:27 p.m., Wolthera van Hövell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119183/
> ---
> 
> (Updated Sept. 15, 2014, 2:27 p.m.)
> 
> 
> Review request for Calligra, Dmitry Kazakov and Boudewijn Rempt.
> 
> 
> Bugs: https://bugs.kde.org/show_bug.cgi?id=313787
> 
> http://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=313787
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> I have been working on this https://bugs.kde.org/show_bug.cgi?id=313787.
> 
> This patch adds a color sliders docker to Krita.
> The intention is to eventually get to a docker that can can be modified 
> through the preferences, so one could have only saturation sliders, or two 
> saturations sliders and a value slider.
> This docker is only intended for derived models, where the specific colour 
> selector is for actual colour spaces.
> 
> 
> Diffs
> -
> 
>   krita/plugins/extensions/dockers/CMakeLists.txt f94eb44 
>   
> krita/plugins/extensions/dockers/advancedcolorselector/kis_color_selector_settings.cpp
>  f171c2e 
>   
> krita/plugins/extensions/dockers/advancedcolorselector/wdg_color_selector_settings.ui
>  dbe9070 
>   krita/plugins/extensions/dockers/colorslider/CMakeLists.txt PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_dock.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_dock.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_input.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_input.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_widget.h 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_color_slider_widget.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_hsv_slider.h PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/kis_hsv_slider.cpp 
> PRE-CREATION 
>   krita/plugins/extensions/dockers/colorslider/krita_colorslider.desktop 
> PRE-CREATION 
>   libs/pigment/KoColorConversions.cpp fc7954b 
> 
> Diff: https://git.reviewboard.kde.org/r/119183/diff/
> 
> 
> Testing
> ---
> 
> A lot, no user testing, there's still a handful of open bugs.
> We have 12 sliders, for each of the HSX colour models.
> It compiles, and it doesn't crash.
> * ~~Kocolorsliders wasn't intended for HSX, so we'll need to write a new 
> widget for HSX.~~[done]
> * ~~For now, all 12 sliders show up using kocolor sliders. I have managed to 
> prevent it from zealously updating everything else, so it doesn't break other 
> things.~~ [Thanks to the fix by dmitry on the specific colour selector, this 
> has been fixed]
> * ~~The number-input is broken. Half of the time~~ [fixed, I made it so that 
> it will only change after loosing focus]
> * ~~So is the slider input itself, I suspect this is rounding errors again, 
> and will have to adjust the self-update, like I did for the colour palette.~~ 
> We need to increase the precision of all the algoritms.
> * ~~Config still needs to be put in.[done, however, after the config is 
> changed, it doesn't re-update the docker again, on restart the update takes 
> place.]~~[done]
> * ~~There's still licenses missing~~[done]
> * ~~The code is a bloody mess.~
> * ~~There's a bug in the hsy and hsi code I wrote, but there's also bugs in 
> the qt hsv and hsl code(gray in particular is strange) I'll chase these down 
> with increasing the precision.~~ Fixed.
> * There's some awkwardness between the different colour models updating 
> eachother, leading to slider-dancing. Hopefull this'll be fixed with 
> precision increase.
> * The sliders don't update properly on LUT changes. This also happens in the 
> specific colour selector.
> I want to do these last two in a seperate patch.
> * Made the H and S sliders work when the colour is black, as requested by 
> Sven.
> * Aligned the labels to the right..
> * Couldn't set the labels to align perfectly.
> 
> 
> Thanks,
> 
> Wolthera van Hövell
> 
>

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

Re: Review Request 120610: Fix for Krita Bug 339870

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120610/#review68611
---

Ship it!


The patch is really nice! It fixes quite a subtle rounding bug. I'm ok with 
comming it, but you should fix the Tab<->Space issue to conform KDE code style 
policies first :)

https://techbase.kde.org/Policies/Kdelibs_Coding_Style

- Dmitry Kazakov


On Окт. 17, 2014, 2:53 д.п., Gerald Young wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120610/
> ---
> 
> (Updated Окт. 17, 2014, 2:53 д.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Fixes Krita Bug 339870.
> 
> The issue was two fold. Firstly on krita/ui/tool/kis_tool_freehand.cc didn't 
> respond well to slow dragging motions. The brush size can only increment in 
> integer pixel values, but a slow dragging motion generates increments smaller 
> than one pixel. These small increments get truncated once passed to brush 
> settings and the drag motion is discarded. Solution was to accumulate the 
> drag motion until it is higher than one pixel.
> 
> A second problem was that KisDoubleSliderSpinBox would implicitly convert the 
> provided qreal to an int value. This conversion works like the floor 
> function, for example turning a 0.1 into a 0 value (ok) and turning a -0.1 
> value into a -1 value (not ok). This was the cause of the weird behavior 
> where brush size would decrease even when dragging right slowly. Solution was 
> to use qRound to avoid the implicit conversion.
> 
> 
> Diffs
> -
> 
>   krita/ui/tool/kis_tool_freehand.cc 76a0ce0 
>   krita/ui/widgets/kis_slider_spin_box.cpp f9a7fc0 
> 
> Diff: https://git.reviewboard.kde.org/r/120610/diff/
> 
> 
> Testing
> ---
> 
> Tested doing shift+drag and size increases/decreases normally. Slow 
> shift+dragging also increases/decreases the brush size properly. Tried also 
> at high zoom ratios and also works as expected.
> 
> 
> Thanks,
> 
> Gerald Young
> 
>

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

Re: Review Request 121064: Krita - KisPaintInformation::time should be qreal

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121064/#review70077
---

Ship it!


Looks good to me! :)

- Dmitry Kazakov


On Ноя. 8, 2014, 2:18 п.п., Damien de Lemeny wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121064/
> ---
> 
> (Updated Ноя. 8, 2014, 2:18 п.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Values in KisPaintInformation are interpolated between event's paint info
> for each dab, time should be decimal rather than integer to be correctly
> interpolated on high velocity strokes.
> 
> Note : this patch is not enough to completely fix the speed sensor as 
> KisPaintInformation's timestamps are still garbage.
> 
> 
> Diffs
> -
> 
>   krita/ui/tool/kis_tool_freehand_helper.cpp 26d4ccb 
>   krita/image/kis_distance_information.h 70fa25e 
>   krita/image/kis_distance_information.cpp 1c1c847 
>   krita/image/brushengine/kis_paint_information.cc 264ad43 
>   krita/image/brushengine/kis_paint_information.h 003a6c5 
> 
> Diff: https://git.reviewboard.kde.org/r/121064/diff/
> 
> 
> Testing
> ---
> 
> Compilation OK
> Runtime OK
> 
> Expected results : 
> A speed-bound stroke should have (almost) correct speed information and 
> display changes correlated to speed.
> 
> 
> Thanks,
> 
> Damien de Lemeny
> 
>

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

Re: Review Request 121226: Krita - Clean global origin workaround

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121226/#review70844
---

Ship it!


If the tablet still works correctly, then I'm ok with pushing it into master

- Dmitry Kazakov


On Ноя. 23, 2014, 9:23 п.п., Damien de Lemeny wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121226/
> ---
> 
> (Updated Ноя. 23, 2014, 9:23 п.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> KisToolProxy::forwardEvent had an ugly workaround parameter to get the origin 
> coordinates of the canvas converted to global coordinates. Better have 
> KisToolProxy creating that origin instead of passing it around.
> 
> 
> Diffs
> -
> 
>   krita/ui/canvas/kis_tool_proxy.h 307e627 
>   krita/ui/canvas/kis_tool_proxy.cpp 0545ea0 
>   krita/ui/input/kis_alternate_invocation_action.cpp ce61a84 
>   krita/ui/input/kis_change_primary_setting_action.cpp aeade2c 
>   krita/ui/input/kis_input_manager.cpp 89919dc 
>   krita/ui/input/kis_tool_invocation_action.cpp 33e2640 
> 
> Diff: https://git.reviewboard.kde.org/r/121226/diff/
> 
> 
> Testing
> ---
> 
> Compiles OK
> Primary tool invocation OK
> Alternate tool invocation OK
> Change primary settings OK
> 
> 
> Thanks,
> 
> Damien de Lemeny
> 
>

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

Review Request 121336: Fix vector sapes resolution in Krita

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121336/
---

Review request for Calligra and Boudewijn Rempt.


Bugs: 313600 and 341107
http://bugs.kde.org/show_bug.cgi?id=313600
http://bugs.kde.org/show_bug.cgi?id=341107


Repository: calligra


Description
---

This is a cumulative patch for the work done in krita-chili-kazakov branch in 
git.

The main idea of the changes is that KoUnit returned by the canvas now contains 
proper pt->px conversion coefficient and the main shape widgets can handle it 
properly. They are now connected to the resource manager's signal and update 
the unit on every change.

There is one "not-ideal" point. The shapes can have internal transformations, 
but their size and position member functions do not take it into account. So in 
some of the widgets I had to take this "transformation factor" into account 
using KoUnit's pt->px factor. This looks a bit ugly, but I'm not sure we can do 
anything else here.


Here is the full list of changes.

commit 5efa5b4e9205632e1945d5fb467bc37836a582c4
Author: Dmitry Kazakov 
Date:   Tue Dec 2 14:07:35 2014 +0300

Fix width of the Pencil Tool stroke after changing resolution

There were two things needed:

1) Deselect shapes when a shape-based tool is activated.
   That is not needed when twe creating a new shape and it causes
   the shape stroke widget edit the options of the lastly
   selected stroke, which is not expected.
2) Reset unit on every selection change in KoStrokeConfigWidget.
   Otherwise deselection is not handled properly.

commit ef5e1d2544beb30a027f874f7aedd8add951fedd
Author: Dmitry Kazakov 
Date:   Tue Dec 2 13:05:30 2014 +0300

Fix units in the shadow config docker

1) Added correct unit updates to the widget
2) Moved approxTransformScale() calculation to KoUnit since it
   is too global

commit 38eea366b6477c4fcb5f0b46ced9be4fb9b93c1f
Author: Dmitry Kazakov 
Date:   Fri Nov 28 15:23:30 2014 +0400

Fix a nice infinite loop in KoShadowConfigWidget

How to reproduce:
1) Add a shape in Krita
2) Enable Shadow
3) Zoom canvas with mouse wheel

commit fddc5e9cc648c4d0eceb67b793faa3c0c14b8d62
Author: Dmitry Kazakov 
Date:   Fri Nov 28 15:14:33 2014 +0400

Fix Default tool widgets to show values in real pixels, not points

Now the option widgets use correct KoUnit object to convert their
options in correct user-visible pixels. Some note on the implementation:

1) Affects KoStrokeConfigWidget and DefaultToolWidget
2) The correct conversion value is stored in KoUnit, which is reported
   by KisCanvas2 and retransmitted by KisView2.
3) There is a hack in KoStrokeConfigWidget. KoShapeStroke knows nothing
   about the absoluteTransformation() of the shape, which doesn't stop
   the shape from doing the transformation of the outline (loaded into
   QPainter directly). So we take it into account manually, by adding
   a multiplier into KoUnit.

BUG:313600
BUG:341107


Diffs
-

  krita/ui/kis_view2.cpp aa894e8 
  krita/ui/tool/kis_delegated_tool.h c63c6f9 
  krita/ui/tool/kis_delegated_tool_policies.h PRE-CREATION 
  krita/ui/tool/kis_delegated_tool_policies.cpp PRE-CREATION 
  libs/flake/KoShapeShadow.h ccb3a3f 
  libs/flake/KoShapeShadow.cpp ead0b80 
  libs/odf/KoUnit.h ae26734 
  libs/odf/KoUnit.cpp dc22265 
  libs/widgets/KoShadowConfigWidget.h b3140dd 
  libs/widgets/KoShadowConfigWidget.cpp d08f232 
  libs/widgets/KoStrokeConfigWidget.cpp 445ea9f 
  libs/widgets/KoUnitDoubleSpinBox.cpp ff94913 
  plugins/defaultTools/defaulttool/DefaultToolWidget.cpp 55885d2 
  krita/ui/CMakeLists.txt e28134a 
  krita/ui/canvas/kis_canvas2.cpp 60ade0b 
  krita/ui/flake/kis_shape_controller.h 39ae1eb 
  krita/ui/flake/kis_shape_controller.cpp a0db22d 
  krita/ui/flake/kis_shape_layer.cc c0fe4ac 
  krita/plugins/tools/defaulttools/kis_tool_path.h 36db16a 
  krita/plugins/tools/defaulttools/kis_tool_pencil.h 8a69428 
  krita/plugins/tools/selectiontools/kis_tool_select_path.h 0bb252b 
  krita/plugins/tools/tool_transform2/kis_transform_utils.cpp 9fd7e29 

Diff: https://git.reviewboard.kde.org/r/121336/diff/


Testing
---

Tested in Krita


Thanks,

Dmitry Kazakov

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

Re: Review Request 121336: Fix vector sapes resolution in Krita

[Dmitry Kazakov]

> On Дек. 4, 2014, 11:29 д.п., Camilla Boemann wrote:
> > libs/odf/KoUnit.cpp, line 382
> > <https://git.reviewboard.kde.org/r/121336/diff/1/?file=331818#file331818line382>
> >
> > since you call this at all times in the widget, and the equal operator 
> > checks this value even if type is not PIXEL, then this shouldn't be done if 
> > type is != PIXEL
> > 
> > OR the equal oper should be changed

Thanks for the catch! I have fixed the issue in the branch!


- Dmitry


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121336/#review71339
-------


On Дек. 3, 2014, 10:53 д.п., Dmitry Kazakov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121336/
> ---
> 
> (Updated Дек. 3, 2014, 10:53 д.п.)
> 
> 
> Review request for Calligra and Boudewijn Rempt.
> 
> 
> Bugs: 313600 and 341107
> http://bugs.kde.org/show_bug.cgi?id=313600
> http://bugs.kde.org/show_bug.cgi?id=341107
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This is a cumulative patch for the work done in krita-chili-kazakov branch in 
> git.
> 
> The main idea of the changes is that KoUnit returned by the canvas now 
> contains proper pt->px conversion coefficient and the main shape widgets can 
> handle it properly. They are now connected to the resource manager's signal 
> and update the unit on every change.
> 
> There is one "not-ideal" point. The shapes can have internal transformations, 
> but their size and position member functions do not take it into account. So 
> in some of the widgets I had to take this "transformation factor" into 
> account using KoUnit's pt->px factor. This looks a bit ugly, but I'm not sure 
> we can do anything else here.
> 
> 
> Here is the full list of changes.
> 
> commit 5efa5b4e9205632e1945d5fb467bc37836a582c4
> Author: Dmitry Kazakov 
> Date:   Tue Dec 2 14:07:35 2014 +0300
> 
> Fix width of the Pencil Tool stroke after changing resolution
> 
> There were two things needed:
> 
> 1) Deselect shapes when a shape-based tool is activated.
>That is not needed when twe creating a new shape and it causes
>the shape stroke widget edit the options of the lastly
>selected stroke, which is not expected.
> 2) Reset unit on every selection change in KoStrokeConfigWidget.
>Otherwise deselection is not handled properly.
> 
> commit ef5e1d2544beb30a027f874f7aedd8add951fedd
> Author: Dmitry Kazakov 
> Date:   Tue Dec 2 13:05:30 2014 +0300
> 
> Fix units in the shadow config docker
> 
> 1) Added correct unit updates to the widget
> 2) Moved approxTransformScale() calculation to KoUnit since it
>is too global
> 
> commit 38eea366b6477c4fcb5f0b46ced9be4fb9b93c1f
> Author: Dmitry Kazakov 
> Date:   Fri Nov 28 15:23:30 2014 +0400
> 
> Fix a nice infinite loop in KoShadowConfigWidget
> 
> How to reproduce:
> 1) Add a shape in Krita
> 2) Enable Shadow
> 3) Zoom canvas with mouse wheel
> 
> commit fddc5e9cc648c4d0eceb67b793faa3c0c14b8d62
> Author: Dmitry Kazakov 
> Date:   Fri Nov 28 15:14:33 2014 +0400
> 
> Fix Default tool widgets to show values in real pixels, not points
> 
> Now the option widgets use correct KoUnit object to convert their
> options in correct user-visible pixels. Some note on the implementation:
> 
> 1) Affects KoStrokeConfigWidget and DefaultToolWidget
> 2) The correct conversion value is stored in KoUnit, which is reported
>by KisCanvas2 and retransmitted by KisView2.
> 3) There is a hack in KoStrokeConfigWidget. KoShapeStroke knows nothing
>about the absoluteTransformation() of the shape, which doesn't stop
>the shape from doing the transformation of the outline (loaded into
>QPainter directly). So we take it into account manually, by adding
>a multiplier into KoUnit.
> 
> BUG:313600
> BUG:341107
> 
> 
> Diffs
> -
> 
>   krita/ui/kis_view2.cpp aa894e8 
>   krita/ui/tool/kis_delegated_tool.h c63c6f9 
>   krita/ui/tool/kis_delegated_tool_policies.h PRE-CREATION 
>   krita/ui/tool/kis_delegated_tool_policies.cpp PRE-CREATION 
>   libs/flake/KoShapeShadow.h ccb3a3f 
>   libs/flake/KoShapeShadow.cpp ead0b80 
>   libs/odf/KoUnit.h ae

Re: Review Request 121336: Fix vector sapes resolution in Krita

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121336/
---

(Updated Дек. 5, 2014, 11:47 д.п.)


Status
--

This change has been marked as submitted.


Review request for Calligra and Boudewijn Rempt.


Bugs: 313600 and 341107
http://bugs.kde.org/show_bug.cgi?id=313600
http://bugs.kde.org/show_bug.cgi?id=341107


Repository: calligra


Description
---

This is a cumulative patch for the work done in krita-chili-kazakov branch in 
git.

The main idea of the changes is that KoUnit returned by the canvas now contains 
proper pt->px conversion coefficient and the main shape widgets can handle it 
properly. They are now connected to the resource manager's signal and update 
the unit on every change.

There is one "not-ideal" point. The shapes can have internal transformations, 
but their size and position member functions do not take it into account. So in 
some of the widgets I had to take this "transformation factor" into account 
using KoUnit's pt->px factor. This looks a bit ugly, but I'm not sure we can do 
anything else here.


Here is the full list of changes.

commit 5efa5b4e9205632e1945d5fb467bc37836a582c4
Author: Dmitry Kazakov 
Date:   Tue Dec 2 14:07:35 2014 +0300

Fix width of the Pencil Tool stroke after changing resolution

There were two things needed:

1) Deselect shapes when a shape-based tool is activated.
   That is not needed when twe creating a new shape and it causes
   the shape stroke widget edit the options of the lastly
   selected stroke, which is not expected.
2) Reset unit on every selection change in KoStrokeConfigWidget.
   Otherwise deselection is not handled properly.

commit ef5e1d2544beb30a027f874f7aedd8add951fedd
Author: Dmitry Kazakov 
Date:   Tue Dec 2 13:05:30 2014 +0300

Fix units in the shadow config docker

1) Added correct unit updates to the widget
2) Moved approxTransformScale() calculation to KoUnit since it
   is too global

commit 38eea366b6477c4fcb5f0b46ced9be4fb9b93c1f
Author: Dmitry Kazakov 
Date:   Fri Nov 28 15:23:30 2014 +0400

Fix a nice infinite loop in KoShadowConfigWidget

How to reproduce:
1) Add a shape in Krita
2) Enable Shadow
3) Zoom canvas with mouse wheel

commit fddc5e9cc648c4d0eceb67b793faa3c0c14b8d62
Author: Dmitry Kazakov 
Date:   Fri Nov 28 15:14:33 2014 +0400

Fix Default tool widgets to show values in real pixels, not points

Now the option widgets use correct KoUnit object to convert their
options in correct user-visible pixels. Some note on the implementation:

1) Affects KoStrokeConfigWidget and DefaultToolWidget
2) The correct conversion value is stored in KoUnit, which is reported
   by KisCanvas2 and retransmitted by KisView2.
3) There is a hack in KoStrokeConfigWidget. KoShapeStroke knows nothing
   about the absoluteTransformation() of the shape, which doesn't stop
   the shape from doing the transformation of the outline (loaded into
   QPainter directly). So we take it into account manually, by adding
   a multiplier into KoUnit.

BUG:313600
BUG:341107


Diffs
-

  krita/ui/kis_view2.cpp aa894e8 
  krita/ui/tool/kis_delegated_tool.h c63c6f9 
  krita/ui/tool/kis_delegated_tool_policies.h PRE-CREATION 
  krita/ui/tool/kis_delegated_tool_policies.cpp PRE-CREATION 
  libs/flake/KoShapeShadow.h ccb3a3f 
  libs/flake/KoShapeShadow.cpp ead0b80 
  libs/odf/KoUnit.h ae26734 
  libs/odf/KoUnit.cpp dc22265 
  libs/widgets/KoShadowConfigWidget.h b3140dd 
  libs/widgets/KoShadowConfigWidget.cpp d08f232 
  libs/widgets/KoStrokeConfigWidget.cpp 445ea9f 
  libs/widgets/KoUnitDoubleSpinBox.cpp ff94913 
  plugins/defaultTools/defaulttool/DefaultToolWidget.cpp 55885d2 
  krita/ui/CMakeLists.txt e28134a 
  krita/ui/canvas/kis_canvas2.cpp 60ade0b 
  krita/ui/flake/kis_shape_controller.h 39ae1eb 
  krita/ui/flake/kis_shape_controller.cpp a0db22d 
  krita/ui/flake/kis_shape_layer.cc c0fe4ac 
  krita/plugins/tools/defaulttools/kis_tool_path.h 36db16a 
  krita/plugins/tools/defaulttools/kis_tool_pencil.h 8a69428 
  krita/plugins/tools/selectiontools/kis_tool_select_path.h 0bb252b 
  krita/plugins/tools/tool_transform2/kis_transform_utils.cpp 9fd7e29 

Diff: https://git.reviewboard.kde.org/r/121336/diff/


Testing
---

Tested in Krita


Thanks,

Dmitry Kazakov

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

Review Request 121388: Remove rounding for pixels in KoUnit

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121388/
---

Review request for Calligra.


Repository: calligra


Description
---

Rounding in KoUnit makes it impossible for a user to position a shape 
precisely. 

I'm not sure why this rounding was added but it seems to be a bit inconsistens 
with the rest of the KoUnit codedabe. The rest of the functions like ptToUnit() 
and convertFromUnitToUnit() know nothing about rounding.


Diffs
-

  libs/odf/KoUnit.cpp 191ae0c 
  libs/widgets/KoUnitDoubleSpinBox.cpp 9c8af44 

Diff: https://git.reviewboard.kde.org/r/121388/diff/


Testing
---

Tested in Krita


Thanks,

Dmitry Kazakov

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

Re: Review Request 121388: Remove rounding for pixels in KoUnit

[Dmitry Kazakov]

> On Дек. 8, 2014, 1:32 п.п., Camilla Boemann wrote:
> > as i don't believe anyone but krita uses it i have no objection from global 
> > pov.
> > 
> > 
> > but (in krita) are you sure  dialogs that give fractional pixel values 
> > makes sense to a user?

It is a good point. But it seems like we don't use KoUnitDoubleSpinBox in Krita 
directly. Everywhere we use manually crafted spinbox+dropdown combinations. And 
this control is mostly used in Ko libraries. So this change should be quite 
safe.


- Dmitry


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121388/#review71547
-------


On Дек. 8, 2014, 1:17 п.п., Dmitry Kazakov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121388/
> ---
> 
> (Updated Дек. 8, 2014, 1:17 п.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Rounding in KoUnit makes it impossible for a user to position a shape 
> precisely. 
> 
> I'm not sure why this rounding was added but it seems to be a bit 
> inconsistens with the rest of the KoUnit codedabe. The rest of the functions 
> like ptToUnit() and convertFromUnitToUnit() know nothing about rounding.
> 
> 
> Diffs
> -
> 
>   libs/odf/KoUnit.cpp 191ae0c 
>   libs/widgets/KoUnitDoubleSpinBox.cpp 9c8af44 
> 
> Diff: https://git.reviewboard.kde.org/r/121388/diff/
> 
> 
> Testing
> ---
> 
> Tested in Krita
> 
> 
> Thanks,
> 
> Dmitry Kazakov
> 
>

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

Re: Review Request 121388: Remove rounding for pixels in KoUnit

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121388/
---

(Updated Дек. 8, 2014, 5:08 п.п.)


Status
--

This change has been marked as submitted.


Review request for Calligra.


Repository: calligra


Description
---

Rounding in KoUnit makes it impossible for a user to position a shape 
precisely. 

I'm not sure why this rounding was added but it seems to be a bit inconsistens 
with the rest of the KoUnit codedabe. The rest of the functions like ptToUnit() 
and convertFromUnitToUnit() know nothing about rounding.


Diffs
-

  libs/odf/KoUnit.cpp 191ae0c 
  libs/widgets/KoUnitDoubleSpinBox.cpp 9c8af44 

Diff: https://git.reviewboard.kde.org/r/121388/diff/


Testing
---

Tested in Krita


Thanks,

Dmitry Kazakov

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

Re: Review Request 121572: Bug Fix 331791 wish: Add toggle mode or shortcut for brush snap to assistant

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121572/#review72266
---



krita/plugins/extensions/dockers/defaultdockers/kis_layer_box.cpp
<https://git.reviewboard.kde.org/r/121572/#comment50401>

The accelerator for a second letter was intentional, because otherwise it 
conflicts with "Shear", shich is more logical for 'S' accelerator. You can 
change it for any letter but 'S'.



krita/plugins/tools/defaulttools/kis_tool_brush.cc
<https://git.reviewboard.kde.org/r/121572/#comment50402>

addAction() accepts the 'id' of the action, which will be use later for 
accessing it using krita.rc file or via the code that directly fetches the 
actions from the action collection. This string will never be seen by the user. 
So it should not be translated. Usually it looks like an c-style valid name:

e.g.:

```c++
KAction *increaseBrushSize = new KAction(i18n("Increase Brush Size"), 
collection);
increaseBrushSize->setShortcut(Qt::Key_BracketRight);
collection->addAction("increase_brush_size", increaseBrushSize);
```


- Dmitry Kazakov


On Dec. 18, 2014, 7:11 p.m., Rishabh Saxena wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121572/
> ---
> 
> (Updated Dec. 18, 2014, 7:11 p.m.)
> 
> 
> Review request for Calligra and Boudewijn Rempt.
> 
> 
> Bugs: 331791
> http://bugs.kde.org/show_bug.cgi?id=331791
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Added a keyboard shortcut for toggling assistant.
> 
> 
> Diffs
> -
> 
>   krita/plugins/tools/defaulttools/kis_tool_brush.h 16a6acc 
>   krita/plugins/tools/defaulttools/kis_tool_brush.cc a65f618 
> 
> Diff: https://git.reviewboard.kde.org/r/121572/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rishabh Saxena
> 
>

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

Re: Review Request 121598: Bug fix - 331483 : JJ Add "Flatten Layer" to the RightClick context menu

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121598/#review72328
---


Hi, Rishabh!

Are you sure you want to put the Flatten Layer action into the same group with 
the actions that create new masks? I guess it would be more logical to put them 
into the same group with either Flatten Image or Convert To. You could talk to 
artists to get to find out which way is the most convenient for them.

Another problem is that Flatter Layer action is not getting disabled when a 
mask is selected. Such behavior is quite ok when the action in the man window 
menu, but it might be quite unexpected when a user right-clicks on a mask and 
sees "Flatten Layer", because a mask cannot be flattened. Only it's parent. The 
easiest approach is to disbale action when a non-layer node is selected. You 
can follow an example of "Transparency Mask" action. It is also disabled when a 
maks is selected.

- Dmitry Kazakov


On Dec. 19, 2014, 6:44 p.m., Rishabh Saxena wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121598/
> ---
> 
> (Updated Dec. 19, 2014, 6:44 p.m.)
> 
> 
> Review request for Calligra and Boudewijn Rempt.
> 
> 
> Bugs: 331483
> http://bugs.kde.org/show_bug.cgi?id=331483
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Created a "Flatten layer" option in RightClick context menu using 
> addActiontoMenu() method.
> 
> 
> Diffs
> -
> 
>   krita/plugins/extensions/dockers/defaultdockers/kis_layer_box.cpp 1a8aabf 
>   krita/plugins/tools/defaulttools/kis_tool_brush.h 16a6acc 
>   krita/plugins/tools/defaulttools/kis_tool_brush.cc a65f618 
> 
> Diff: https://git.reviewboard.kde.org/r/121598/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rishabh Saxena
> 
>

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

Re: Review Request 121572: Bug Fix 331791 wish: Add toggle mode or shortcut for brush snap to assistant

[Dmitry Kazakov]

> On Дек. 18, 2014, 7:35 п.п., Dmitry Kazakov wrote:
> > krita/plugins/tools/defaulttools/kis_tool_brush.cc, line 399
> > <https://git.reviewboard.kde.org/r/121572/diff/3/?file=333824#file333824line399>
> >
> > addAction() accepts the 'id' of the action, which will be use later for 
> > accessing it using krita.rc file or via the code that directly fetches the 
> > actions from the action collection. This string will never be seen by the 
> > user. So it should not be translated. Usually it looks like an c-style 
> > valid name:
> > 
> > e.g.:
> > 
> > ```c++
> > KAction *increaseBrushSize = new KAction(i18n("Increase Brush Size"), 
> > collection);
> > increaseBrushSize->setShortcut(Qt::Key_BracketRight);
> > collection->addAction("increase_brush_size", increaseBrushSize);
> > ```

The action ID must not be a translatable string


- Dmitry


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121572/#review72266
---


On Дек. 18, 2014, 7:11 п.п., Rishabh Saxena wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121572/
> ---
> 
> (Updated Дек. 18, 2014, 7:11 п.п.)
> 
> 
> Review request for Calligra and Boudewijn Rempt.
> 
> 
> Bugs: 331791
> http://bugs.kde.org/show_bug.cgi?id=331791
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Added a keyboard shortcut for toggling assistant.
> 
> 
> Diffs
> -
> 
>   krita/plugins/tools/defaulttools/kis_tool_brush.h 16a6acc 
>   krita/plugins/tools/defaulttools/kis_tool_brush.cc a65f618 
> 
> Diff: https://git.reviewboard.kde.org/r/121572/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rishabh Saxena
> 
>

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

Re: Review Request 121598: Bug fix - 331483 : JJ Add "Flatten Layer" to the RightClick context menu

[Dmitry Kazakov]

> On Dec. 23, 2014, 10:14 p.m., Sven Langkamp wrote:
> > Excluding the transparency mask from flatten isn't needed as it would 
> > automatically flatten the parent layer. There are also many other mask type 
> > that are not covered by this.

I would expect this option would be available for layers only, not masks. It 
maight be rather unexpected when a parent is merged when there are many other 
siblings present. Thought excluding Transparency Mask only is not correct 
anyway, yes.


- Dmitry


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121598/#review72475
---


On Dec. 23, 2014, 6:56 p.m., Rishabh Saxena wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121598/
> ---
> 
> (Updated Dec. 23, 2014, 6:56 p.m.)
> 
> 
> Review request for Calligra and Boudewijn Rempt.
> 
> 
> Bugs: 331483
> http://bugs.kde.org/show_bug.cgi?id=331483
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Created a "Flatten layer" option in RightClick context menu using 
> addActiontoMenu() method.
> 
> 
> Diffs
> -
> 
>   krita/plugins/extensions/dockers/defaultdockers/kis_layer_box.cpp 1a8aabf 
>   krita/ui/kis_layer_manager.cc b609f42 
> 
> Diff: https://git.reviewboard.kde.org/r/121598/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rishabh Saxena
> 
>

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

Re: Review Request 121656: Krita - Fix weak shared pointer copy constructor and assignment

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121656/#review72483
---

Ship it!



krita/image/kis_shared_ptr.h
<https://git.reviewboard.kde.org/r/121656/#comment50522>

Coding style



krita/image/kis_shared_ptr.h
<https://git.reviewboard.kde.org/r/121656/#comment50521>

Coding style :(

https://techbase.kde.org/Policies/Kdelibs_Coding_Style


Hi, Stefano!

Your patch is awesome! Especially removed doublechecks for logical operators 
(not sure how we got them here) and pesence of unittests. The only "trouble" is 
coding style of the braces in 'if' statements in the copy constructor. They 
should be present and they should be on the same line as the statement itself. 
You can just fix it and push the patch without another round of review.

- Dmitry Kazakov


On Dec. 24, 2014, 12:34 a.m., Stefano Bonicatti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121656/
> ---
> 
> (Updated Dec. 24, 2014, 12:34 a.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Now is possible to copy and assign an invalid weak pointer to a shared 
> pointer or another weak pointer.
> Cleaned up a couple of redundant checks.
> Added some testcases to test the validity of the change.
> 
> 
> Diffs
> -
> 
>   krita/image/kis_shared_ptr.h 85aee50 
>   krita/image/tests/kis_shared_ptr_test.h 9c9a35f 
>   krita/image/tests/kis_shared_ptr_test.cpp 6f44b1c 
> 
> Diff: https://git.reviewboard.kde.org/r/121656/diff/
> 
> 
> Testing
> ---
> 
> Compiles fine.
> Tests are all passing.
> 
> 
> Thanks,
> 
> Stefano Bonicatti
> 
>

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

Re: Review Request 121733: Fix crash reported in bug 342222

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121733/#review72677
---


Hi, Thorsten!

The patch looks ok except one thing. Are you sure the shape controller is 
deleted somewhere? As far as I understood, the ownership of it is not passed to 
the document resource manager. It just stores a pointer insize QVariant, so it 
seems like the shape controller is leaking :(

- Dmitry Kazakov


On Dec. 29, 2014, 3:59 a.m., Thorsten Zachmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121733/
> ---
> 
> (Updated Dec. 29, 2014, 3:59 a.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Bugs: 34
> http://bugs.kde.org/show_bug.cgi?id=34
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> For shapes that are created in the document a KoShapeController is set. 
> However when loading a shape this is not set as it is not available in the 
> factory. This results in a crash when pasting as there the KoShapeController 
> is needed. Therefore create a KoShapeController which can be set on text 
> shapes during loading. This is done the same in kopageapp and words.
> 
> 
> Diffs
> -
> 
>   krita/ui/KisDocument.cpp 00a1e68 
> 
> Diff: https://git.reviewboard.kde.org/r/121733/diff/
> 
> 
> Testing
> ---
> 
> Opened a .kra file with a text shape and pasted text to it.
> 
> 
> Thanks,
> 
> Thorsten Zachmann
> 
>

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

Re: Review Request 121944: Krita - Fix crash when switching off OpenGL

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121944/#review73837
---

Ship it!


I tested the patch on Windows with AMD and Intel GPUs. Works fine, except that 
I didn't test OCIO support (I don't have it built here).

Looks ok to commit.

- Dmitry Kazakov


On Янв. 12, 2015, 10:59 д.п., Stefano Bonicatti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121944/
> ---
> 
> (Updated Янв. 12, 2015, 10:59 д.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> The wrong context was active when shaders were deleted.
> This also fix the crash when switching scaling mode or anything that deletes 
> a KisOpenGLCanvas2.
> 
> Changed the KisOpenGL API that deal with contexts a bit, now is possible to 
> choose between switching on the shared context or a widget one.
> 
> To avoid overhead switching on a context that is already current, i've added 
> a check to see if the context we are trying to switch to is already current 
> or not (the check doesn't use any gpu command).
> 
> 
> This should make everything still work on all others cards and drivers, 
> though it is better to be tested, so i put it here.
> 
> This patch is now present on branch origin/krita-testing-bonicatti.
> 
> 
> Diffs
> -
> 
>   krita/plugins/extensions/dockers/lut/ocio_display_filter.cpp 4c3b9c7 
>   krita/ui/canvas/kis_canvas2.cpp 22dd4b3 
>   krita/ui/opengl/kis_opengl.h 7f68f6b 
>   krita/ui/opengl/kis_opengl.cpp 1c49f37 
>   krita/ui/opengl/kis_opengl_canvas2.cpp 154ab4f 
>   krita/ui/opengl/kis_opengl_image_textures.cpp 47eaf55 
> 
> Diff: https://git.reviewboard.kde.org/r/121944/diff/
> 
> 
> Testing
> ---
> 
> Tested on Linux on ATI Radeon HD5850 1GB with proprietary drivers (where the 
> issue was present). OpenGL version string: 4.4.12968 Compatibility Profile 
> Context 14.201.1006.1002
> 
> 
> Thanks,
> 
> Stefano Bonicatti
> 
>

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

Re: Review Request 122042: Fix crash after attempt to change alignment in a text field

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122042/#review74071
---


This line has been copied from Qt, so this can't be a fix.

- Dmitry Kazakov


On Янв. 14, 2015, 8:55 д.п., Roman Shtemberko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122042/
> ---
> 
> (Updated Янв. 14, 2015, 8:55 д.п.)
> 
> 
> Review request for Calligra, Adam Pigg and Jarosław Staniek.
> 
> 
> Bugs: 342371
> http://bugs.kde.org/show_bug.cgi?id=342371
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> https://bugs.kde.org/show_bug.cgi?id=342371
> 
> 
> Diffs
> -
> 
>   libs/kundo2/kundo2stack.cpp bf0a6c8 
> 
> Diff: https://git.reviewboard.kde.org/r/122042/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Roman Shtemberko
> 
>

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

Re: KoPathShape saveOdf and loadOdf oddities

[Dmitry Kazakov]

The main question here is:

"What is the meaning of KoShape::absoluteTransformation()?"

It has two answers:

1) It is a transformation that applies *to control points of the shape only*
.

Pseudo code for painting in this case looks like that:

QPainterPath path = shape->absoluteTransformation(...).map(shape->path());
gc.setPen(shape->pen());
gc.drawPath(path);


2) It is a transformation that applies *to the entire shape*.

Pseudo code:

gc.setPen(shape->pen());
gc.setTransform(shape->absoluteTransformation(...));
gc.drawPath(shape->path());


Obviously enough the two options generate two completely different results.
Qt's QGraphicsScene uses the second approach. Which one is supposed to be
in flake? If we answer this question, the solution of the original problem
will be quite simple.




On Sun, Jan 18, 2015 at 2:01 PM, Stefano Bonicatti  wrote:

> 2015-01-18 6:39 GMT+01:00 Thorsten Zachmann :
>
>> Hello Stefano,
>> Seems the change of the transformation was done by Jan to help with
>> fixing the
>> bug https://bugs.kde.org/show_bug.cgi?id=280348. Do you have a patch for
>> which
>> I could run cstester to see if it would break anything.
>
>
> Hello, i spoke with Camilla about the issue, the "proposed" patch in this
> mail is not ok because due to that bug the transformation doesn't have to
> be applied to everything, but only to part of the shape, as it is already
> done.
>
> I did some testing with other shapes in Krita and Inkscape/LibreOffice
> (even though i couldn't import their .odg because Krita has problems with
> them), and clearly the problem presents itself only with path shapes,
> because with the other shapes the matrix is used to transform the entire
> shape.
> So either Krita follows how other vector editors works, and then it
> doesn't permit a layer transformation unless it "rasterize" it as an image,
> or Krita has to subclass KoPathShape to change its behaviour.
>
> In both cases KoPathShape has to enforce that when setting a matrix the
> control points has to be mapped to it, as it happens when handling the
> shape with the correct tools.
> This is because as far as i can tell Calligra want to be faithful to how
> the other vector editors work (and correctly load their shapes) and the
> special use is done "only" by Krita.
>
>
> ___
> 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

Re: Merging all fixes for 2.9

[Dmitry Kazakov]

Rebase will change all the sha1 values. I wouldn't like it. Too many
complications for such a small trouble.

On Thu, Jan 22, 2015 at 9:29 PM, Jaroslaw Staniek  wrote:

> No, revert created new commit, that's the same what happens in 2.9 now »
> blurry history when it happens often.
>
> Solution: git checkout calligra/2.9
> git checkout -b 29fix
> (use rebase -i to remove mistake commits)
> git checkout calligra/2.9
> git merge 29fix
>
> (untested, use git cherry to double check)
>
> PS: I thought from the very beginning that you'd rebase 2.9 on master
> since it is FF. I.e
> just pull -rebase.
>
> On Thursday, 22 January 2015, Inge Wallin  wrote:
> > On Thursday, January 22, 2015 14:34:07 Jaroslaw Staniek wrote:
> >> Good, would it be possible to skip the recent buggy commit
> >> 2c40d8b87db167dd1d77341daabb2ed7837ee46b
> >> ?
> >
> > I don't know how.  Except first merge it, buggy commit and all, and then
> revert
> > that particular commit.
> >
> > But why don't you revert it in 2.9 already?
> >
> > -Inge
> >
> >> On Thursday, 22 January 2015, Inge Wallin  wrote:
> >> > On Thursday, January 22, 2015 12:02:47 Cyrille Berger wrote:
> >> >> On 2015-01-19 22:35, Inge Wallin wrote:
> >> >> > On Monday, January 19, 2015 17:25:33 Inge Wallin wrote:
> >> >> >> On Monday, January 19, 2015 17:26:45 Boudewijn Rempt wrote:
> >> >> >> > If you do, I think it should be an ordinary merge, not a squash.
> >> >> >>
> >> >> >> yes, agree.
> >> >> >
> >> >> > Done.  It went totally without problems.
> >> >> >
> >> >> > I think we should do this every 3-5 days at least so that we don't
> end
> >> >> > up with
> >> >> > a big problem that will be difficult to unwind later.
> >> >>
> >> >> That was the original plan, but nobody had the time to do it until
> now I
> >> >> guess :) And that is also why we "froze" master.
> >> >
> >> > As I mentioned on IRC, I am willing to do this 2-3 time per week.  In
> >>
> >> fact, I
> >>
> >> > was planning to do it again tonight.
> >> >
> >> > -Inge
> >> >
> >> > ___
> >> > 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
> >
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
>
> ___
> 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

Re: Review Request 122284: fixed Bug 342168 - JJ: A way to disable the "on hover" layer thumbnail popup.

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122284/#review74883
---


Hi, Aleksander!

I tested the patch. It works nicely. I have only one concern. Probably, it 
would be better to rename the option to something more specific, like "Hide 
layer thumbnail tooltip" or "Hide layer thumbnail popup" or something else? 
Right now it is a bit difficult to understand what the option means.

In the rest the patch is perfect, especially setntence-casing the checkboxes to 
fit KDE capitalization policy! :)

- Dmitry Kazakov


On Jan. 28, 2015, 4:59 a.m., Aleksander Demko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122284/
> ---
> 
> (Updated Jan. 28, 2015, 4:59 a.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Bugs: 342168
> http://bugs.kde.org/show_bug.cgi?id=342168
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> fixed Bug 342168 - JJ: A way to disable the "on hover" layer thumbnail popup.
> 
> Added a new global setting "Hide various popups", when enabled,
> suppresses all tooltip popups in KisDocumentSelectionDelegate
> 
> 
> Diffs
> -
> 
>   krita/ui/KisDocumentSectionDelegate.cpp a827e06 
>   krita/ui/dialogs/kis_dlg_preferences.cc 1379e8b 
>   krita/ui/forms/wdgdisplaysettings.ui 751ee50 
>   krita/ui/kis_config.h bbb3242 
>   krita/ui/kis_config.cc f67c08d 
> 
> Diff: https://git.reviewboard.kde.org/r/122284/diff/
> 
> 
> Testing
> ---
> 
> Basic developer testing.
> 
> 
> Thanks,
> 
> Aleksander Demko
> 
>

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

Re: Review Request 122284: fixed Bug 342168 - JJ: A way to disable the "on hover" layer thumbnail popup.

[Dmitry Kazakov]

> On Jan. 28, 2015, 9:04 a.m., Boudewijn Rempt wrote:
> > krita/ui/forms/wdgdisplaysettings.ui, line 274
> > 
> >
> > One note: I don't think that changing the string here was necessary (or 
> > correct).

According to KDE policy, checkboxes should be in sentece case, so I guess it 
was at least correct.

https://techbase.kde.org/Projects/Usability/HIG/Capitalization


- Dmitry


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122284/#review74899
---


On Jan. 28, 2015, 7:02 a.m., Aleksander Demko wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122284/
> ---
> 
> (Updated Jan. 28, 2015, 7:02 a.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Bugs: 342168
> http://bugs.kde.org/show_bug.cgi?id=342168
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> fixed Bug 342168 - JJ: A way to disable the "on hover" layer thumbnail popup.
> 
> Added a new global setting "Hide various popups", when enabled,
> suppresses all tooltip popups in KisDocumentSelectionDelegate
> 
> 
> Diffs
> -
> 
>   krita/ui/KisDocumentSectionDelegate.cpp a827e06 
>   krita/ui/dialogs/kis_dlg_preferences.cc 1379e8b 
>   krita/ui/forms/wdgdisplaysettings.ui 751ee50 
>   krita/ui/kis_config.h bbb3242 
>   krita/ui/kis_config.cc f67c08d 
> 
> Diff: https://git.reviewboard.kde.org/r/122284/diff/
> 
> 
> Testing
> ---
> 
> Basic developer testing.
> 
> 
> Thanks,
> 
> Aleksander Demko
> 
>

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

Re: 2.9 final release date

[Dmitry Kazakov]

+1 as well

On Tue, Feb 3, 2015 at 11:59 AM, Jaroslaw Staniek  wrote:

> On 3 February 2015 at 09:56, Boudewijn Rempt  wrote:
> > 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.
>
> +1 here
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
> _______
> 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

Re: Getting to 100 % succedding tests (for 2.9), or, simply dropping them all?

[Dmitry Kazakov]

; (so
> those simply testing one thing while mocking the rest of the system as
> much as
> possible), integration tests and other types of tests.
> And make sure that unit tests take less then seconds to run, so no one is
> stopped from using them as part of their workflow, e.g. before pushing
> their
> latest changes to the central repo. "make all test" should be a normal
> habit.
> And leave running all the longer running tests for the CI, he, that's what
> it
> is for.
> -> task T0: specify/document different test types (Calligra wiki/build
> system)
> -> task T1: go through all the tests and mark those tests which can be
> considered quickly runnable unit tests, integration tests, other tests
>
> Even with that test categorization, there is a number of tests failing
> currently that need fixing. Ideally before the 2.9 release and the port.
> Some
> of them are failing since ages (e.g. diff between
>
> http://build.kde.org/job/calligra_master/Variation=All,label=LINBUILDER/1235/testReport/
> http://build.kde.org/job/calligra_stable/1829/testReport/
> )
> -> task T2: find all the long-time failing tests, disable from build,
> possibly
> tag as JJ bugs to fix them)
> -> task T3: list all the new failing tests and lets fix them by everyone
> ASAP
>
> For fixing problem 1, this is a social problem. People need to be aware of
> the
> tests (guess some might not) and value those tests.
> No idea if future CI systems deployed could enforce rejection of commits
> that
> break tests, but ideally people simply feel responsible for breaking tests,
> like they feel responsible for breaking the normal build.
>
> Personally I see tasks T2 and T3 as something to be done first, best before
> 2.9 release. See me subscribed to making that happen :)
>
> But first, please your thoughts and feedback on this.
>
> Cheers
> Friedrich
> ___
> 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

Re: Getting to 100 % succedding tests (for 2.9), or, simply dropping them all?

[Dmitry Kazakov]

> > There is one important point: *all* the test sets should be compiled when
> > KDE_BUILD_TESTS==on
>
> Where compiled!=run? Makes sense, I agree. The whole idea of CI is to
> cover as
> much as possible, so we do not need to do things manually :)
>

Yes. Build all, but be able to choose what to run. Ideally I should be able
to run two subsets of tests: 1) for integration testing; 2) more
complicated for yearly semi-manual regression-testing.

 > 5) It would also be nice to be able to choose different subtests of one

> > executable to be in different subsets. Though I am not sure whether it is
> > doable.
>
> Could you give an example what you mean here? "executable" is not clear, as
> well as "to be in different subsets"?
>

See e.g. KisNodeTest.

It has two parts. The first consists of "integration" tests, which can be
run very fast:

void testCreation();
void testOrdering();
void testSetDirty();
void testChildNodes();
void testDirtyRegion();

The second consists of stress tests which are brute-force checking thread
safety. They might take up to several minutes to execute and preferably
should be run in semi-manual mode yearly or something like that:

void propertiesStressTest();
void graphStressTest();


>> 2) Consequence of 1): from time to time we should manually check what
>> exactly is wrong with the test. Is it a pixel drift or a real problem.

> Do you happen to have a list of the tests where such external deps
influence
> the result? Or could the list be created from checking for
> checkQImageExternal()?

Everything that uses TestUtil::checkQImageImpl(). It includes almost all
tests written for last couple of years.


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

Re: Getting to 100 % succedding tests (for 2.9), or, simply dropping them all?

[Dmitry Kazakov]

Hi, Friedrich!

calligra_add_unittest
> calligra_add_integrationtest
> calligra_add_stresstest
>

I really like you proposal! Now we need to decide on a set of labels for
these tests and give them some definition/documentation so people could
decide easily, where their test should go. I guess they should be
classified by the importance they have on our code and the timeframe they
should be fixed in. Here are the definitions I could make up:

1) integrationtest --- small and fast unittest that should/can be run
before any commit. Should take a couple of seconds to execute and check
basic functionality of the class/subsystem. If your commit breaks such
test, ideally commit should not be let in, or at least be fixed as soon as
possible. Therefore this type of tests should be very stable (run
successfully on any type of system with any deps installed) and not use
direct PNG image comparison.

2) stresstest --- long running test that is executed on the integration
server (jenkins). Should take a couple of minutes to execute. The main use
case is checking thread safety for structures with concurrent access. Must
also be stable (not use PNG comparison) and if a commit breaks a test, must
be fixed as soon as possible.

3) manualtest --- the tests that should be run and checked before every
release. They might not be stable enough (e.g. use comparison of PNG
images) and give numerous false failures, so they need human attention when
running. If a commit breaks such a unittest, it is recommended to check
what exactly has happened, but it cannot block a commit from integration.


We also have benchmarks in Krita, but they are handled by a different make
target right now:

4) benchmarks --- conform the same requirements as 'manualtest' category.


Probably, we could start some wiki page to document it right from the
beginning?

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

Re: Welcome to KDE e.V., Dmitry!

[Dmitry Kazakov]

Thank you, Jaroslaw, for nice words! :)

On Sat, Feb 21, 2015 at 10:58 AM, Jaroslaw Staniek  wrote:

> I'd like to especially welcome long time Calligra/Krita contributor
> and great colleague Dmitry Kazakov who just joined the KDE e.V.
> non-profit. [1]
> Dmitry, I trust it'll be source of extra satisfaction for you.
>
> [1] https://ev.kde.org
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
> ___
> 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

Bugs in Krita which should be fixed before the release

[Dmitry Kazakov]

Hi, all!

Just wanted to let you know that I'd prefer these bugs being fixed in Krita
before the tarballs are done. I hope I'll manage to fix all of them
tomorrow before afternoon.

1) Trim to selection bug: https://bugs.kde.org/show_bug.cgi?id=344012
2) Fill layers new bug: https://bugs.kde.org/show_bug.cgi?id=344346
3) Ping the Russian translator and commit his (already almost finished
translation) into SVN, so there would be updated Russian language support
in Krita 2.9.

I hope everything will be finished by tomorrow evening and we will be able
to make tarballs smoothly! :)

And I will write here when these tasks are done.



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

[calligra/calligra/2.9] libs/pigment: Change the license of Vc-optimized composite ops from GPL 2 to LGPL 2.1

[Dmitry Kazakov]

Git commit d78fac93164ca4e6588a35d4fef7b7adb8223898 by Dmitry Kazakov.
Committed on 22/02/2015 at 06:18.
Pushed by dkazakov into branch 'calligra/2.9'.

Change the license of Vc-optimized composite ops from GPL 2 to LGPL 2.1

This is a requirement of calligra libs, and I am fully agree with this
change.

Boudewijn Rempt will also support this change.

CCMAIL:calligra-devel@kde.org

M  +12   -11   libs/pigment/KoColorDisplayRendererInterface.cpp
M  +12   -11   libs/pigment/KoColorDisplayRendererInterface.h
M  +12   -11   libs/pigment/compositeops/KoOptimizedCompositeOpFactory.cpp
M  +12   -11   libs/pigment/compositeops/KoOptimizedCompositeOpFactory.h
M  +12   -11   
libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
M  +12   -11   libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.h
M  +12   -11   
libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch_Scalar.cpp
M  +12   -11   libs/pigment/compositeops/KoStreamedMath.h
M  +12   -11   libs/pigment/compositeops/KoVcMultiArchBuildSupport.h

http://commits.kde.org/calligra/d78fac93164ca4e6588a35d4fef7b7adb8223898

diff --git a/libs/pigment/KoColorDisplayRendererInterface.cpp 
b/libs/pigment/KoColorDisplayRendererInterface.cpp
index 7661457..549c76f 100644
--- a/libs/pigment/KoColorDisplayRendererInterface.cpp
+++ b/libs/pigment/KoColorDisplayRendererInterface.cpp
@@ -1,19 +1,20 @@
 /*
  *  Copyright (c) 2014 Dmitry Kazakov 
  *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
  *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
  *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 
USA.
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this library; see the file COPYING.LIB.  If not, write to
+ * the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301, USA.
  */
 
 #include "KoColorDisplayRendererInterface.h"
diff --git a/libs/pigment/KoColorDisplayRendererInterface.h 
b/libs/pigment/KoColorDisplayRendererInterface.h
index 4ffb7c2..a70ede5 100644
--- a/libs/pigment/KoColorDisplayRendererInterface.h
+++ b/libs/pigment/KoColorDisplayRendererInterface.h
@@ -1,19 +1,20 @@
 /*
  *  Copyright (c) 2014 Dmitry Kazakov 
  *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
  *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
  *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 
USA.
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with this library; see the file COPYING.LIB.  If not, write to
+ * the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301, USA.
  */
 
 #ifndef __KO_COLOR_DISPLAY_RENDERER_INTERFACE_H
diff --git a/libs/pigment/compositeops/KoOptimizedCompositeOpFactory.cpp 
b/libs/

Re: Bugs in Krita which should be fixed before the release

[Dmitry Kazakov]

Hi!

>From my three tasks two are completed now: the trim selections and Russian
translations. I cannot fix the fill layers bug right now, because I fell
ill a bit. So from my side there are no release blockers now. Let's release
it! :)

On Mon, Feb 23, 2015 at 4:14 AM, Jaroslaw Staniek  wrote:

> +1
> Yes, we've been acting with this plan in mind. I see many of us are
> working extra hard to meet this deadline; Dmitry's post shows this
> clearly too. Please, there were no risk or issues reported to the list
> so I can only conclude 26 is the deadline.
>
> The problem is not just that 2.9 wouldn't be released one time (which
> would be a pity given there are not known no technical or other
> issues), the problem I see is that no work on 3.0 could really start
> on time, what I promised to contributors I work with. What it does to
> our cadence and what message is sent.
>
> On 22 February 2015 at 20:26, Boudewijn Rempt  wrote:
> > Well, there's already some new stuff in master that couldn't go into 2.9
> > because of strings.
> >
> > But more importantly: we all agreed that the release is the 26th. Not
> next
> > week. I really don't want to delay the release into March!
> >
> >
> > On Sun, 22 Feb 2015, Cyrille Berger wrote:
> >
> >> No need for hurry, the translations are not quiet in place, so I should
> >> probably tag only next week-end. (but if we want, we can reopen master
> this
> >> week).
> >>
> >> On 2015-02-21 20:14, Dmitry Kazakov wrote:
> >>>
> >>> Hi, all!
> >>>
> >>> Just wanted to let you know that I'd prefer these bugs being fixed in
> >>> Krita before the tarballs are done. I hope I'll manage to fix all of
> >>> them tomorrow before afternoon.
> >>>
> >>> 1) Trim to selection bug: https://bugs.kde.org/show_bug.cgi?id=344012
> >>> [1]
> >>> 2) Fill layers new bug: https://bugs.kde.org/show_bug.cgi?id=344346
> >>> [2]
> >>>
> >>> 3) Ping the Russian translator and commit his (already almost finished
> >>> translation) into SVN, so there would be updated Russian language
> >>> support in Krita 2.9.
> >>>
> >>> I hope everything will be finished by tomorrow evening and we will be
> >>> able to make tarballs smoothly! :)
> >>>
> >>> And I will write here when these tasks are done.
> >>>
> >>> --
> >>>
> >>> Dmitry Kazakov
> >>>
> >>> Links:
> >>> --
> >>> [1] https://bugs.kde.org/show_bug.cgi?id=344012
> >>> [2] https://bugs.kde.org/show_bug.cgi?id=344346
> >>>
> >>> ___
> >>> calligra-devel mailing list
> >>> calligra-devel@kde.org
> >>> https://mail.kde.org/mailman/listinfo/calligra-devel
> >>
> >>
> >> --
> >> 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
>
>
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
> ___
> 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

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

[Dmitry Kazakov]

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.

3) #pragma once

To tell you the truth I cannot remember a single case of facing a problem
with include guards for last several years. Why should we bother about any
non-standard compiler extensions then? My emacs scripts handle it quite
perfectly, I am pretty sure that QtCreator can also crack it. I just don't
understand the reasoning. Does MacOS compilers support it well enough?





On Wed, Feb 25, 2015 at 1:18 PM, 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.
>
> Boudewijn
>
> ___
> 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

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)

[Dmitry Kazakov]

Hi!

I looked through the patch and updated the google docs:
https://docs.google.com/document/d/1jhq6oXuXKvTilJhcoS6FVKO7yYRu2yCgBS9ojhc2QRU/edit#

The changes which I believe we must fix before applying it to master:

1) Inlined functions. They are not covered by the KDE style policy, so I
believe we should follow Qt- and KDE- style of handling inlined functions
with the opening brace at the signature line. It applies only to the
functions declared *and* defined inside the class itself.

2) "Wrong alignment of function parameters". See the corresponding topic in
the google docs. Astyle seems to be a bit broken here, because in some
places it applies correctly, and in some not. The units that are always
wrong are constructors.

3) "Indentation of multiline conditionals is wrong". See the corresponding
topic in the google docs. Should be 8 spaces instead of 12.

I think we should commit the patch only after we fix at least these three
issues.

(optional)
4) I really feel we must *not* follow one-line-if-always-with-braces rule.
'if (some_stuff) return 0' is perfectly ok in my opinion. But this is my
opinion only and I cannot block the patch with that. I only search for
support from other developers in this topic.


On Thu, Mar 5, 2015 at 11:05 AM, Boudewijn Rempt  wrote:

> On Thu, 5 Mar 2015, C. Boemann wrote:
>
>  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,
>>
>>
> I would love that as well. This style of initializer lists is the easiest
> to maintain.
>
> Boudewijn
>
> _______
> 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

Re: Review Request 122858: Krita - UI fixes and improvements

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122858/#review77201
---



krita/ui/widgets/kis_filter_selector_widget.cc
<https://git.reviewboard.kde.org/r/122858/#comment53028>

Is this commented-out code intentional? Probably it should go?



krita/ui/widgets/kis_filter_selector_widget.cc
<https://git.reviewboard.kde.org/r/122858/#comment53029>

Should this also be deleted?


- Dmitry Kazakov


On Март 8, 2015, 6:52 п.п., Moritz Molch wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122858/
> ---
> 
> (Updated Март 8, 2015, 6:52 п.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This patch fixes some UI related bugs and improves the usability especially 
> for new / casual users like myself by removing some clutter and bringing in 
> some consistency.
> 
> I detail it modifies:
> 
> * Create filter layer / Filter Mask
>   This fixes the treeview, slightly changes the layout and adds a scrollarea
>   to be usable on smaller screens, changes "Name" label to "Layer Name" to be
>   consistent with the "create fill layer" and "create file layer" widgets,
>   disables the preset buttons when the filter has no configuration
>   
> * Create fill layer
>   Fix resizing of the pattern widget, and removes unnecessary pattern label
>   
> * Remove unnecessary "Tag:" label and set it as the tooltip in 
> TagChooserWidget.
>   By default the entry says "All presets", so the user already knows what it 
> does.
>   This also adds to consistency with most other dropdowns in the interface
>   
> * Removed the statustip from the "Duplicate Layer or Mask" button in the 
> layer docker.
>   This is the only button in krita that has it set and it's annoying to see 
> the statusbar
>   flash each time you hover over that one button. Also the info is already in 
> the tooltip.
> 
> 
> Kind regards,
> Moritz
> 
> 
> Diffs
> -
> 
>   krita/plugins/generators/pattern/wdgpatternoptions.ui f92a7ec 
>   krita/ui/forms/wdgdlggeneratorlayer.ui d80a98d 
>   krita/ui/forms/wdgfilternodecreation.ui c616feb 
>   krita/ui/forms/wdgfilterselector.ui 405722b 
>   krita/ui/forms/wdggenerators.ui e9ffca8 
>   krita/ui/widgets/kis_filter_selector_widget.h 360aa67 
>   krita/ui/widgets/kis_filter_selector_widget.cc a16abd8 
>   libs/widgets/KoTagChooserWidget.cpp a625a1a 
>   krita/plugins/extensions/dockers/defaultdockers/wdglayerbox.ui d38262e 
>   krita/plugins/generators/pattern/kis_wdg_pattern.cpp c75d20c 
> 
> Diff: https://git.reviewboard.kde.org/r/122858/diff/
> 
> 
> Testing
> ---
> 
> Tested on Ubuntu 14.04
> 
> 
> Thanks,
> 
> Moritz Molch
> 
>

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

Re: Review Request 123179: workaround Vc cmake issue

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123179/#review78783
---


Hi, Yue!

Do we need the same fix for krita/image/CMakeLists.txt? It also uses 
build_per_arch macro, so it might also be affected

- Dmitry Kazakov


On March 30, 2015, 7:54 a.m., Yue Liu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123179/
> ---
> 
> (Updated March 30, 2015, 7:54 a.m.)
> 
> 
> Review request for Calligra and Boudewijn Rempt.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Currently building pigment with vc 0.7.4 enabled would fail on systems not 
> putting qt5 headers and kf5 headers in /usr/include. This is because of vc's 
> cmake macro `ko_compile_for_all_implementations_no_scalar`, which I found 
> resulted in this piece in CMake-generated ninja code:
> ```
> build libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o: 
> CUSTOM_COMMAND 
> /home/yue/Dev/calligra/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
>  
> /home/yue/Dev/calligra/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
>  || libs/koplugin/libkoplugin.so libs/pigment/pigmentcms_automoc 
> libs/version/libkoversion.so
>   COMMAND = cd /home/yue/Dev/calligra/build/libs/pigment && /usr/bin/clang++ 
> -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts 
> -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor 
> -Woverloaded-virtual -Werror=return-type -O2 -g -DNDEBUG 
> -Wno-local-type-template-args -Wno-unnamed-type-template-args 
> -ffp-contract=fast -mtune=core2 -fPIC 
> -I/home/yue/Dev/calligra/src/calligra/interfaces 
> -I/home/yue/Dev/calligra/build -I/home/yue/Dev/calligra/src/calligra 
> -I/home/yue/Dev/calligra/src/calligra/libs/version 
> -I/home/yue/Dev/calligra/build/libs/version 
> -I/home/yue/Dev/calligra/src/calligra/libs/koplugin 
> -I/home/yue/Dev/calligra/src/calligra/libs/version 
> -I/home/yue/Dev/calligra/build/libs/version 
> -I/home/yue/Dev/calligra/src/calligra/libs/pigment 
> -I/home/yue/Dev/calligra/src/calligra/libs/pigment/compositeops 
> -I/home/yue/Dev/calligra/src/calligra/libs/pigment/resources -I/usr/include 
> -I/usr/include -I/usr/include/OpenEXR -I/usr/include -mavx -DVC
 _IMPL=AVX -c -oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o 
/home/yue/Dev/calligra/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
>   DESC = Building CXX object KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
> ```
> 
> Which is very different from ninja code generated by CMake's add_library 
> function:
> ```
> build 
> libs/pigment/CMakeFiles/pigmentcms.dir/compositeops/KoOptimizedCompositeOpFactory.cpp.o:
>  CXX_COMPILER 
> /home/yue/Dev/calligra/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactory.cpp
>  || cmake_order_depends_target_pigmentcms
>   DEFINES = -DBOOST_ALL_NO_LIB -DCAN_USE_QTWEBKIT -DKCOREADDONS_LIB 
> -DKGUIADDONS_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0 
> -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB 
> -DQT_USE_FAST_CONCATENATION -DQT_USE_FAST_OPERATOR_PLUS -DQT_WIDGETS_LIB 
> -DQT_XML_LIB -DSHOULD_BUILD_FONT_CONVERSION -D_GNU_SOURCE 
> -D_LARGEFILE64_SOURCE -Dpigmentcms_EXPORTS
>   DEP_FILE = 
> libs/pigment/CMakeFiles/pigmentcms.dir/compositeops/KoOptimizedCompositeOpFactory.cpp.o.d
>   FLAGS = -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align 
> -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef 
> -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -O2 -g -DNDEBUG 
> -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Ilibs/pigment 
> -I/home/yue/Dev/calligra/src/calligra/libs/pigment 
> -I/home/yue/Dev/calligra/src/calligra/interfaces -I. 
> -I/home/yue/Dev/calligra/src/calligra 
> -I/home/yue/Dev/calligra/src/calligra/libs/version -Ilibs/version 
> -I/home/yue/Dev/calligra/src/calligra/libs/koplugin 
> -I/home/yue/Dev/calligra/src/calligra/libs/pigment/compositeops 
> -I/home/yue/Dev/calligra/src/calligra/libs/pigment/resources -Ilibs/koplugin 
> -I/usr/include/OpenEXR -isystem /usr/include/qt -isystem 
> /usr/include/qt/QtCore -isystem /usr/lib/qt/mkspecs/linux-g++ -isystem 
> /usr/include/KF5/KDELibs4Support -isystem 
> /usr/include/KF5/KDELibs4Support/KDE -isystem /usr/include/KF5 -isystem 
> /usr/include/qt/QtWidgets -isystem /usr/include/qt/QtGui -isystem /us

[calligra/krita-psd-rempt] /: Removed explicit memory leak when dealing with gradients

[Dmitry Kazakov]

Git commit 6df0b34f17b742359c197493396e7840f1c5f837 by Dmitry Kazakov.
Committed on 12/04/2015 at 17:46.
Pushed by dkazakov into branch 'krita-psd-rempt'.

Removed explicit memory leak when dealing with gradients

The changes in the patch:

1) Now KoResource has a copy-ctor.

2) KoAbstractGradient and descendants have a clone()
   method to make a copy of the resource.

3) To let KoResourceServer store purely abstract resource types,
   KoResourceServerSimpleContruction utlity-descendant was added.
   It stores the default implementation of createResource() which should
   be overridden in GradientResourceServer later in the hierarchy.

   There was an option to use SFINAE inside KoResourceServer to handle
   this situation for KoAbstractGradient, but the construction is much
   more complicated and not so vastly understood/accepted.

CCMAIL:calligra-devel@kde.org

M  +4-0krita/image/kis_gradient_painter.cc
M  +1-1
krita/plugins/extensions/dockers/tasksetdocker/tasksetdocker_dock.cpp
M  +1-1krita/plugins/extensions/resourcemanager/resourcemanager.cpp
M  +1-1
krita/plugins/filters/layerstyles/kis_asl_layer_style_serializer.cpp
M  +0-5krita/plugins/filters/layerstyles/kis_asl_xml_parser.cpp
M  +1-1krita/ui/kis_paintop_box.cc
M  +3-3krita/ui/kis_resource_server_provider.cpp
M  +1-1krita/ui/kis_resource_server_provider.h
M  +6-0libs/pigment/resources/KoAbstractGradient.cpp
M  +4-1libs/pigment/resources/KoAbstractGradient.h
M  +5-0libs/pigment/resources/KoResource.cpp
M  +3-2libs/pigment/resources/KoResource.h
M  +5-0libs/pigment/resources/KoSegmentGradient.cpp
M  +2-0libs/pigment/resources/KoSegmentGradient.h
M  +5-0libs/pigment/resources/KoStopGradient.cpp
M  +2-0libs/pigment/resources/KoStopGradient.h
M  +15   -1libs/widgets/KoResourceServer.h
M  +2-2libs/widgets/KoResourceServerProvider.cpp

http://commits.kde.org/calligra/6df0b34f17b742359c197493396e7840f1c5f837

diff --git a/krita/image/kis_gradient_painter.cc 
b/krita/image/kis_gradient_painter.cc
index d23b025..0f29367 100644
--- a/krita/image/kis_gradient_painter.cc
+++ b/krita/image/kis_gradient_painter.cc
@@ -60,6 +60,10 @@ public:
 
 virtual ~CachedGradient() {}
 
+KoAbstractGradient* clone() const {
+return new CachedGradient(m_subject, m_max + 1, m_colorSpace);
+}
+
 /**
 * Creates a QGradient from the gradient.
 * The resulting QGradient might differ from original gradient
diff --git 
a/krita/plugins/extensions/dockers/tasksetdocker/tasksetdocker_dock.cpp 
b/krita/plugins/extensions/dockers/tasksetdocker/tasksetdocker_dock.cpp
index e21c8c1..c956f74 100644
--- a/krita/plugins/extensions/dockers/tasksetdocker/tasksetdocker_dock.cpp
+++ b/krita/plugins/extensions/dockers/tasksetdocker/tasksetdocker_dock.cpp
@@ -100,7 +100,7 @@ TasksetDockerDock::TasksetDockerDock( ) : 
QDockWidget(i18n("Task Sets")), m_canv
 chooserButton->setIcon(koIcon("document-multiple"));
 
 KGlobal::mainComponent().dirs()->addResourceType("kis_taskset", "data", 
"krita/taskset/");
-m_rserver = new KoResourceServer("kis_taskset", "*.kts");
+m_rserver = new 
KoResourceServerSimpleConstruction("kis_taskset", "*.kts");
 if (!QFileInfo(m_rserver->saveLocation()).exists()) {
 QDir().mkpath(m_rserver->saveLocation());
 }
diff --git a/krita/plugins/extensions/resourcemanager/resourcemanager.cpp 
b/krita/plugins/extensions/resourcemanager/resourcemanager.cpp
index c274303..7eb81c3 100644
--- a/krita/plugins/extensions/resourcemanager/resourcemanager.cpp
+++ b/krita/plugins/extensions/resourcemanager/resourcemanager.cpp
@@ -54,7 +54,7 @@ ResourceBundleServerProvider::ResourceBundleServerProvider()
 // user-local
 KGlobal::mainComponent().dirs()->addResourceType("kis_resourcebundles", 
"data", "krita/bundles/");
 KGlobal::mainComponent().dirs()->addResourceDir("kis_resourcebundles", 
QDir::homePath() + QString("/.create/bundles"));
-m_resourceBundleServer = new 
KoResourceServer("kis_resourcebundles", "*.bundle");
+m_resourceBundleServer = new 
KoResourceServerSimpleConstruction("kis_resourcebundles", 
"*.bundle");
 if (!QFileInfo(m_resourceBundleServer->saveLocation()).exists()) {
 QDir().mkpath(m_resourceBundleServer->saveLocation());
 }
diff --git 
a/krita/plugins/filters/layerstyles/kis_asl_layer_style_serializer.cpp 
b/krita/plugins/filters/layerstyles/kis_asl_layer_style_serializer.cpp
index 2d0fb4e..132e13a 100644
--- a/krita/plugins/filters/layerstyles/kis_asl_layer_style_serializer.cpp
+++ b/krita/plugins/filters/layerstyles/kis_asl_layer_style_serializer.cpp
@@ -149,7 +149,7 @@ template 
 void cloneAndSetResource(const T *resour

Review Request 123486: Fix a bug when KoResourceItemChooser's current resource was resent on resize

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123486/
---

Review request for Calligra.


Repository: calligra


Description
---

This patch fixes numerous bugs in KoResourceItemChooser

1) Resizing the widged and then hide/show used to reset currently selected 
resource. That caused user's paintop presets and styles being invalidated by 
simply showing the widget on screen. Now this problem has gone, because the 
madoel()->reset() call is done in two stages with first saving the current 
selection and then restoring it when the reset is finished.

2) Now the number of columns is calculated dynamically when the widget is being 
resized. Before the patch there was a weird behaviour: when resizing the widget 
the tiles were **scaled only**, and after the next hide/show the **number of 
columns** would be recalculated. Now both steps are executed simultaneously.

3) The size of the preview splitter in KisPatternChooser is now fixed, so the 
user would see at least something :)


Diffs
-

  libs/widgets/KoResourceModel.cpp 3b2f5e3 
  libs/widgets/KoResourceModel.h 06a7135 
  libs/widgets/KoResourceItemView.cpp e5d9e5a 
  libs/widgets/KoResourceItemView.h 9b712ed 
  libs/widgets/KoResourceItemChooser.cpp 6e5c349 
  libs/widgets/KoResourceItemChooser.h e41bd26 
  krita/ui/widgets/kis_pattern_chooser.cc 9568d3b 

Diff: https://git.reviewboard.kde.org/r/123486/diff/


Testing
---

Tested in Krita only


Thanks,

Dmitry Kazakov

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

Re: Review Request 123486: Fix a bug when KoResourceItemChooser's current resource was resent on resize

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123486/
---

(Updated April 25, 2015, 10:16 a.m.)


Status
--

This change has been marked as submitted.


Review request for Calligra.


Changes
---

Submitted with commit 0616ea1f9bf958bcce5703a1bd65f4bfe11edce3 by Dmitry 
Kazakov to branch calligra/2.9.


Repository: calligra


Description
---

This patch fixes numerous bugs in KoResourceItemChooser

1) Resizing the widged and then hide/show used to reset currently selected 
resource. That caused user's paintop presets and styles being invalidated by 
simply showing the widget on screen. Now this problem has gone, because the 
madoel()->reset() call is done in two stages with first saving the current 
selection and then restoring it when the reset is finished.

2) Now the number of columns is calculated dynamically when the widget is being 
resized. Before the patch there was a weird behaviour: when resizing the widget 
the tiles were **scaled only**, and after the next hide/show the **number of 
columns** would be recalculated. Now both steps are executed simultaneously.

3) The size of the preview splitter in KisPatternChooser is now fixed, so the 
user would see at least something :)


Diffs
-

  libs/widgets/KoResourceModel.cpp 3b2f5e3 
  libs/widgets/KoResourceModel.h 06a7135 
  libs/widgets/KoResourceItemView.cpp e5d9e5a 
  libs/widgets/KoResourceItemView.h 9b712ed 
  libs/widgets/KoResourceItemChooser.cpp 6e5c349 
  libs/widgets/KoResourceItemChooser.h e41bd26 
  krita/ui/widgets/kis_pattern_chooser.cc 9568d3b 

Diff: https://git.reviewboard.kde.org/r/123486/diff/


Testing
---

Tested in Krita only


Thanks,

Dmitry Kazakov

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

Re: 2.9.3 reminder

[Dmitry Kazakov]

Hi,

in Krita we have a really serious bug: PSD files cannot be open. I'm doing
bisecting right now. It would be really nice if we could tag 2.9.4 or
adjust the tag right after the fix, because for many users PSD is a part of
the workflow :(

On Mon, Apr 27, 2015 at 7:40 PM, Jaroslaw Staniek  wrote:

> Thanks everyone, the announcement is ready.
>
> On 20 April 2015 at 12:03, Jaroslaw Staniek  wrote:
> > Hello,
> > A friendly reminder for 2.9.3:
> > - Tagging: April 25th
> > - Release: April 29th
> >
> > https://community.kde.org/Calligra/Schedules/2.9/Release_Plan#2.9.3
> >
> > --
> > regards, Jaroslaw Staniek
> >
> > KDE:
> > : A world-wide network of software engineers, artists, writers,
> translators
> > : and facilitators committed to Free Software development -
> http://kde.org
> > Calligra Suite:
> > : A graphic art and office suite - http://calligra.org
> > Kexi:
> > : A visual database apps builder - http://calligra.org/kexi
> > Qt Certified Specialist:
> > : http://www.linkedin.com/in/jstaniek
>
>
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
> ___
> 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

Re: Cancelled release of Calligra 2.9.3, expect fixes within a week

[Dmitry Kazakov]

HI, Jaroslaw!

Krita PSD support seems to be fixed now, but it needs thorough testing from
users. I feel that everything will be alright by Saturday :)

On Wed, Apr 29, 2015 at 10:57 PM, Jaroslaw Staniek  wrote:

> Hi,
> We have encountered issues with handling of Photoshop (PSD) files in
> Krita. We understand this as an important missing feature so the
> release 2.9.3 has been cancelled and supplementary 2.9.4 release is
> expected in a week. We’re sorry for the inconvenience.
>
> More info: https://www.calligra.org/news/2-9-3-cancelled
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
> ___
> 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

Re: Phabricator instead of reviewboard

[Dmitry Kazakov]

Hi, Boud!

We should create a Calligra project on Phabricator then :)

On Thu, Apr 30, 2015 at 1:18 PM, Boudewijn Rempt  wrote:

> Hey...
>
> We're supposed to be testing phabricator. So I would propose that we
> actually start using phabricator instead of reviewboard.
>
> Please take a look at https://phabricator.kde.org!
>
> Boudewijn
> ___
> 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

Re: Review Request 123833: Krita: Add basic modifier key support to selection tools.

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123833/#review80792
---



krita/ui/input/kis_alternate_invocation_action.cpp (line 45)
<https://git.reviewboard.kde.org/r/123833/#comment55388>

Hi, Michael!

Could you remove "Alternate" word from these strings? It is excessive here. 
It prevents the text from fitting into the list widget. And the user already 
knows that it is related to the Alternale action because they are shown in 
"Alternate" group already.


- Dmitry Kazakov


On May 25, 2015, 1:57 a.m., Michael Abrahams wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123833/
> ---
> 
> (Updated May 25, 2015, 1:57 a.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This refactors polygonal, elliptical, and rectangular selection tools to use 
> a basic selection tool template which unifies previously duplicated code. The 
> template overrides the ability to execute alternate actions, but none of 
> those tools supported alternate actions previously and the ellipse and 
> rectangle were already overriding the modifier keys to begin with. 
> 
> Shift: add to selection
> Alt: subtract from selection
> Shift+Alt: intersect current selection
> Ctrl: replace selection
> 
> Certain key combinations allow users the ability to expose the modifier keys 
> to the base tool, i.e. to make proportional / translated / scaled alterations 
> using ctrl/alt/shift.
> 1) If the user *clicks first and then presses modifier keys*, those modifier 
> keys will only alter the selection method.
> 2) If the user *presses modifier keys first and then clicks*, the selection 
> method is locked in, and subsequent modifier keystrokes will change how the 
> selection is drawn.
> 3) If the underlying tool *never takes modifier keys*, modifier keys will 
> always alter the selection method. 
> 
> These rules can be defined systematically by modifying the template.
> 
> Things to do later: 
> + Basic functionality is implemented in KisToolSelectBase, which covers the 
> outline, contiguous, similar color and path selection tools which inherit 
> from KisToolSelectBase.  A more complete refactoring might define 
> KisToolSelectBase via the selection tool template, but it is not simple for 
> the path selection tool which uses a more complicated delegated design 
> pattern.
> + The tools need new icons (e.g. little plus/minus symbols) to give users 
> visual feedback when they activate the modifiers.
> + The Ctrl key should switch temporarily to the move tool, as in Photoshop.
> + Check idiomatic naming conventions, style, etc.
> 
> 
> Diffs
> -
> 
>   krita/ui/tool/kis_tool_polyline_base.cpp 6071f76 
>   krita/ui/tool/kis_tool_polyline_base.h f681fd8 
>   krita/ui/tool/kis_tool_paint.h 128dce9 
>   krita/ui/tool/kis_tool.h e852311 
>   krita/ui/tool/kis_tool.cc b299b81 
>   krita/ui/input/kis_alternate_invocation_action.cpp 48723bf 
>   krita/ui/input/kis_alternate_invocation_action.h b47c59e 
>   krita/ui/CMakeLists.txt 1caef14 
>   krita/plugins/tools/selectiontools/kis_tool_select_similar.cc b2c51d9 
>   krita/plugins/tools/selectiontools/kis_tool_select_similar.h f701986 
>   krita/plugins/tools/selectiontools/kis_tool_select_rectangular.cc 331c6a4 
>   krita/plugins/tools/selectiontools/kis_tool_select_rectangular.h 5e88766 
>   krita/plugins/tools/selectiontools/kis_tool_select_polygonal.cc 9acca50 
>   krita/plugins/tools/selectiontools/kis_tool_select_polygonal.h feee9cb 
>   krita/plugins/tools/selectiontools/kis_tool_select_path.cc 9f1a65c 
>   krita/plugins/tools/selectiontools/kis_tool_select_path.h a67b584 
>   krita/plugins/tools/selectiontools/kis_tool_select_outline.cc 46cca47 
>   krita/plugins/tools/selectiontools/kis_tool_select_outline.h 4756870 
>   krita/plugins/tools/selectiontools/kis_tool_select_elliptical.cc 999f1a0 
>   krita/plugins/tools/selectiontools/kis_tool_select_elliptical.h 7b2cd2f 
>   krita/plugins/tools/selectiontools/kis_tool_select_contiguous.cc 5bd4d2f 
>   krita/plugins/tools/selectiontools/kis_tool_select_contiguous.h 26310e2 
>   krita/image/kis_selection.h 6376f874 
>   CMakeFiles/2.8.12.1/CMakeDetermineCompilerABI_CXX.bin PRE-CREATION 
>   krita/ui/tool/kis_tool_rectangle_base.h a0b470c 
>   krita/ui/tool/kis_tool_rectangle_base.cpp 8e091d0 
>   krita/ui/tool/kis_tool_select_base.h 500d6dd 
>   krita/ui/tool

Re: Review Request 124257: advancedcolorselector: Fix UI layout

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124257/#review82090
---

Ship it!


Looks ok to me :)

- Dmitry Kazakov


On July 5, 2015, 2:13 a.m., Alexander Potashev wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124257/
> ---
> 
> (Updated July 5, 2015, 2:13 a.m.)
> 
> 
> Review request for Calligra and Scott Petrovic.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> CCMAIL: scottpetro...@gmail.com
> 
> 
> Diffs
> -
> 
>   
> krita/plugins/extensions/dockers/advancedcolorselector/wdg_color_selector_settings.ui
>  b9e2411fb07b2f5516739208612dd32762d72699 
> 
> Diff: https://git.reviewboard.kde.org/r/124257/diff/
> 
> 
> Testing
> ---
> 
> Layout is stretchable.
> 
> 
> Thanks,
> 
> Alexander Potashev
> 
>

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

Re: Review Request 124278: Improve Krita input device switching for Surface Pro 3

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124278/#review82159
---


I would really love it if it were several separate patches. Especially the 
patch with readability changesm which makes review quite complicated. Anyway, 
even after I review this, we need to ask our users to test it on various tablet 
devices, which can behave quite insanely.

- Dmitry Kazakov


On Июль 7, 2015, 6:31 д.п., Michael Abrahams wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124278/
> ---
> 
> (Updated Июль 7, 2015, 6:31 д.п.)
> 
> 
> Review request for Calligra.
> 
> 
> Bugs: 341899
> http://bugs.kde.org/show_bug.cgi?id=341899
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This patch rewrites most of kis_tablet_support_win.cpp to support basic
> use of the eraser key on the Surface Pro 3.  The basic issue is that the
> SP3 eraser button does not register being held until the stylus is
> touched to the screen. A secondary issue is that the eraser button might
> be pressed in the middle of the stroke, disrupting the ordinary
> schedule of press and release events.
> 
> This patch attempts to handle those issues by watching for "inline"
> cursor changes.  If a packet pops up with a different cursor ID, we will
> dispatch a release event and a tool switch signal.  This breaks some
> layers of abstraction but it seems to work.
> 
> The rest of the rewrite mostly focuses on readability, but adds a few
> assorted fixes elsewhere, in particular allowing the current tool to be
> changed by hovering over the dockers (necessary to allow the SP3 to
> set an alternate alternate tool with the eraser button), an addition to
> the x11 tablet code to give the same functionality, a prescaling feature
> for QTabletEvent, preventing multiple instances of the Qt/Wintab dialog,
> and a few typo corrections.
> 
> 
> Diffs
> -
> 
>   krita/ui/input/wintab/kis_screen_size_choice_dialog.cpp 364419b 
>   krita/ui/input/wintab/kis_tablet_support.h 8c1b279 
>   krita/ui/input/wintab/kis_tablet_support_win.cpp 5e5d82f 
>   krita/ui/input/wintab/kis_tablet_support_x11.cpp 0e28671 
>   libs/flake/KoToolManager.cpp 731faed 
> 
> Diff: https://git.reviewboard.kde.org/r/124278/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Michael Abrahams
> 
>

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

[calligra/calligra/2.9] krita/libpsd: Finish proper renaming of the libpsd library

[Dmitry Kazakov]

Git commit 04dac642dab567fafbce117fe536053d403a3159 by Dmitry Kazakov.
Committed on 07/07/2015 at 09:30.
Pushed by dkazakov into branch 'calligra/2.9'.

Finish proper renaming of the libpsd library

When renaming a library, please don't forget to modify the export
header accordingly, because it uses a MAKE_*_LIB macro to distinguish
which library is currently building.

See full renaming checklist here:
https://community.kde.org/Krita/docs/Rename_Library_Checklist

CC:calligra-devel@kde.org

M  +1-1krita/libpsd/asl/kis_asl_callback_object_catcher.h
M  +1-1krita/libpsd/asl/kis_asl_object_catcher.h
M  +1-1krita/libpsd/asl/kis_asl_patterns_writer.h
M  +1-1krita/libpsd/asl/kis_asl_reader.h
M  +5-5krita/libpsd/asl/kis_asl_reader_utils.h
M  +1-1krita/libpsd/asl/kis_asl_writer.h
M  +7-7krita/libpsd/asl/kis_asl_writer_utils.h
M  +1-1krita/libpsd/asl/kis_asl_xml_parser.h
M  +1-1krita/libpsd/asl/kis_asl_xml_writer.h
M  +1-1krita/libpsd/compression.h
M  +5-5krita/libpsd/libkispsd_export.h
M  +10   -10   krita/libpsd/psd.h
M  +1-1krita/libpsd/psd_pattern.h
M  +20   -20   krita/libpsd/psd_utils.h

http://commits.kde.org/calligra/04dac642dab567fafbce117fe536053d403a3159

diff --git a/krita/libpsd/asl/kis_asl_callback_object_catcher.h 
b/krita/libpsd/asl/kis_asl_callback_object_catcher.h
index 33feab4..3ca3407 100644
--- a/krita/libpsd/asl/kis_asl_callback_object_catcher.h
+++ b/krita/libpsd/asl/kis_asl_callback_object_catcher.h
@@ -43,7 +43,7 @@ typedef boost::function 
ASLCallbackGradient;
 typedef boost::function ASLCallbackNewStyle;
 
 
-class LIBKISPSD_EXPORT KisAslCallbackObjectCatcher : public KisAslObjectCatcher
+class KRITAPSD_EXPORT KisAslCallbackObjectCatcher : public KisAslObjectCatcher
 {
 public:
 KisAslCallbackObjectCatcher();
diff --git a/krita/libpsd/asl/kis_asl_object_catcher.h 
b/krita/libpsd/asl/kis_asl_object_catcher.h
index 8506bb9..cca3165 100644
--- a/krita/libpsd/asl/kis_asl_object_catcher.h
+++ b/krita/libpsd/asl/kis_asl_object_catcher.h
@@ -31,7 +31,7 @@ class KoAbstractGradient;
 template class QSharedPointer;
 typedef QSharedPointer KoAbstractGradientSP;
 
-class LIBKISPSD_EXPORT KisAslObjectCatcher
+class KRITAPSD_EXPORT KisAslObjectCatcher
 {
 public:
 KisAslObjectCatcher();
diff --git a/krita/libpsd/asl/kis_asl_patterns_writer.h 
b/krita/libpsd/asl/kis_asl_patterns_writer.h
index a3d7edf..db71a25 100644
--- a/krita/libpsd/asl/kis_asl_patterns_writer.h
+++ b/krita/libpsd/asl/kis_asl_patterns_writer.h
@@ -27,7 +27,7 @@ class QIODevice;
 class KoPattern;
 
 
-class LIBKISPSD_EXPORT KisAslPatternsWriter
+class KRITAPSD_EXPORT KisAslPatternsWriter
 {
 public:
 KisAslPatternsWriter(const QDomDocument &doc, QIODevice *device);
diff --git a/krita/libpsd/asl/kis_asl_reader.h 
b/krita/libpsd/asl/kis_asl_reader.h
index dd00204..47ddada 100644
--- a/krita/libpsd/asl/kis_asl_reader.h
+++ b/krita/libpsd/asl/kis_asl_reader.h
@@ -25,7 +25,7 @@ class QDomDocument;
 class QIODevice;
 
 
-class LIBKISPSD_EXPORT KisAslReader
+class KRITAPSD_EXPORT KisAslReader
 {
 public:
 QDomDocument readFile(QIODevice *device);
diff --git a/krita/libpsd/asl/kis_asl_reader_utils.h 
b/krita/libpsd/asl/kis_asl_reader_utils.h
index 0f2f2b6..7dfc2ef 100644
--- a/krita/libpsd/asl/kis_asl_reader_utils.h
+++ b/krita/libpsd/asl/kis_asl_reader_utils.h
@@ -40,7 +40,7 @@ namespace KisAslReaderUtils {
  * most of the time, based on the offset values written in PSD.
  */
 
-struct LIBKISPSD_EXPORT ASLParseException : public std::runtime_error
+struct KRITAPSD_EXPORT ASLParseException : public std::runtime_error
 {
 ASLParseException(const QString &msg)
 : std::runtime_error(msg.toAscii().data())
@@ -112,10 +112,10 @@ namespace KisAslReaderUtils {
  * - unicode string (length (4 bytes) + null-terminated unicode string (var)
  */
 
-LIBKISPSD_EXPORT QString readFixedString(QIODevice *device);
-LIBKISPSD_EXPORT QString readVarString(QIODevice *device);
-LIBKISPSD_EXPORT QString readPascalString(QIODevice *device);
-LIBKISPSD_EXPORT QString readUnicodeString(QIODevice *device);
+KRITAPSD_EXPORT QString readFixedString(QIODevice *device);
+KRITAPSD_EXPORT QString readVarString(QIODevice *device);
+KRITAPSD_EXPORT QString readPascalString(QIODevice *device);
+KRITAPSD_EXPORT QString readUnicodeString(QIODevice *device);
 
 }
 
diff --git a/krita/libpsd/asl/kis_asl_writer.h 
b/krita/libpsd/asl/kis_asl_writer.h
index 79e3e22..6e1fe7a 100644
--- a/krita/libpsd/asl/kis_asl_writer.h
+++ b/krita/libpsd/asl/kis_asl_writer.h
@@ -25,7 +25,7 @@ class QDomDocument;
 class QIODevice;
 
 
-class LIBKISPSD_EXPORT KisAslWriter
+class KRITAPSD_EXPORT KisAslWriter
 {
 public:
 void writeFile(QIODevice *device, const QDomDocument &doc);
diff --git a/krita/libpsd/asl/kis_asl_writer_utils.h 
b/krita/libpsd/asl/kis_asl_writer_utils.h
index 32eaae9..5df43c9 100644
--- a/krita/libpsd/asl/kis_asl_writer_uti

Re: release blocker

[Dmitry Kazakov]

The blocker is fixed now. I'm going to restart Krita Lime now.

On Thu, Jul 9, 2015 at 9:27 AM, Boudewijn Rempt  wrote:

> Monthly releases are awesome and we're getting fixes and features in
> users' hands much faster now, but there's a price, and that's testing times.
>
> Deevad just caught a bug: https://bugs.kde.org/show_bug.cgi?id=350031 and
> it is a release blocker. I'm not sure yet whether we can fix that with a
> simple revert, or need to hack a fix -- I'm waiting for Dmitry to wake up
> to check that :-(
>
> Boudewijn
> ___
> 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

Re: 2.9.7

[Dmitry Kazakov]

Hi, Jaroslaw!

Boud is still on the vacation and should be back today/tomorrow, so Krita
cannot do Windows builds atm. How about moving a release to the weekend?

E.g.

- Tagging August 7th
- Release August 12th



On Tue, Aug 4, 2015 at 10:23 AM, Jaroslaw Staniek  wrote:

> Hi,
> Are you ready to tag 2.9.7 ? Any blockers? Do you have code to release?
>
> I have a fix for Kexi to release so from this POV releasing ASAP is
> preferred.
>
> @Cyrille are you available these days?
>
> The original plan was:
>
> - Tagging August 1st
> - Release August 5th
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
> ___
> 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

Re: Increasing Calligra minimum CMake version required

[Dmitry Kazakov]

Hi, Stefano!

As far as I can tell, Ubuntu Precise (12.04 LTS) still has 2.8.7 [0], and
it is still officially supported and builds fine in Krita Lime.


[0] - http://packages.ubuntu.com/precise/cmake

On Sun, Aug 16, 2015 at 5:30 PM, 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?
>
>
>
> ___
> 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

Re: Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)

[Dmitry Kazakov]

Hi, Stefano!

Now Dmitry, what are the situations where you really need it? Because it's
> weird that someone else didn't find/write a ready to use solution for it.
>

Emacs has a feature to autocomplete parts of the filename in non-sequential
order if they are split with underscores. I got really accustomed to this
feature. E.g. you can type '_setting___
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

[Dmitry Kazakov]

On Mon, Jan 31, 2011 at 4:27 PM, Lukast dev <> wrote:

>
> boud:
>
...

> 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
>

I'm not sure the latest statement is true. If the branch is merged into
master and then deleted, the history of the branch will still be there. You
will see a "ring" in `gitk --all` interface.

o development branches may not compile sometimes, do we want to see these
commits in master?
o cherry-picking is effectively an equivalent to rebasing, especially when
there are conflicts present.
o cherry-picking and rebasing is not always clean. Example: imagine you did
a merge from master to branch in the middle of the development of the
branch. Rebasing (cherry-picking) of such a branch is not safe.

As for me, i'm almost agree with sebsauer. If you have a small local branch
that will never be published, just rebase it. If you have once published
your branch, you should do no rebasing, cherry-picking or other rewriting of
history.


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

Review Request: Fixed autoscrolling bug in Krita

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100851/
---

Review request for Calligra.


Summary
---

This patch fixes an autoscrolling bug in Krita. It is caused by the differences 
between coordinate systems of Krita and flake. So I've extracted one method 
from KoToolProxy and overridden it in newly created KisToolProxy. This method 
just converts widget coordinates into document coordinates.

The changes in KoToolProxy do not change anything in it, but it would be better 
to test whether the other applications still work fine =)


This addresses bug 265528.
http://bugs.kde.org/show_bug.cgi?id=265528


Diffs
-

  krita/ui/CMakeLists.txt 5b702c5 
  krita/ui/canvas/kis_canvas2.cpp 3e4dc6c 
  krita/ui/canvas/kis_tool_proxy.h PRE-CREATION 
  krita/ui/canvas/kis_tool_proxy.cpp PRE-CREATION 
  libs/flake/KoToolProxy.h c5393f2 
  libs/flake/KoToolProxy.cpp 4f1608e 
  libs/flake/KoToolProxy_p.h 8baf4ac 

Diff: http://git.reviewboard.kde.org/r/100851/diff


Testing
---


Thanks,

Dmitry

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

Re: Sprint

[Dmitry Kazakov]

I'm arriving at 8:55 at Schonefeld. We could meet with someone =)

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

[calligra] /: Revert "Fixed autoscrolling bug in Krita"

[Dmitry Kazakov]

Git commit 044aa71e9fd5374044d2cb9d4baedeebe244cf6c by Dmitry Kazakov.
Committed on 17/04/2011 at 08:00.
Pushed by dkazakov into branch 'master'.

Revert "Fixed autoscrolling bug in Krita"

This reverts commit a1bc54466caf7066db145d8bab989c1d620084b6.

(Breaks Stage as reported by Thorsten Zachmann)

CCMAIL:calligra-devel@kde.org

M  +0-1krita/ui/CMakeLists.txt 
M  +2-2krita/ui/canvas/kis_canvas2.cpp 
D  +0-34   krita/ui/canvas/kis_tool_proxy.cpp 
D  +0-33   krita/ui/canvas/kis_tool_proxy.h 
M  +9-32   libs/flake/KoToolProxy.cpp 
M  +1-5libs/flake/KoToolProxy.h 
M  +1-1libs/flake/KoToolProxy_p.h 

http://commits.kde.org/calligra/044aa71e9fd5374044d2cb9d4baedeebe244cf6c

diff --git a/krita/ui/CMakeLists.txt b/krita/ui/CMakeLists.txt
index fba4d34..c9bc763 100644
--- a/krita/ui/CMakeLists.txt
+++ b/krita/ui/CMakeLists.txt
@@ -20,7 +20,6 @@ set(kritaui_LIB_SRCS
 canvas/kis_canvas_widget_base.cpp 
 canvas/kis_canvas2.cpp
 canvas/kis_canvas_controller.cpp
-canvas/kis_tool_proxy.cpp
 canvas/kis_canvas_decoration.cc
 canvas/kis_coordinates_converter.cpp 
 canvas/kis_grid_manager.cpp 
diff --git a/krita/ui/canvas/kis_canvas2.cpp b/krita/ui/canvas/kis_canvas2.cpp
index ce65d34..3e4dc6c 100644
--- a/krita/ui/canvas/kis_canvas2.cpp
+++ b/krita/ui/canvas/kis_canvas2.cpp
@@ -34,9 +34,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
-#include "kis_tool_proxy.h"
 #include "kis_coordinates_converter.h"
 #include "kis_prescaled_projection.h"
 #include "kis_image.h"
@@ -78,7 +78,7 @@ public:
 , monitorProfile(0)
 , currentCanvasIsOpenGL(false)
 , currentCanvasUsesOpenGLShaders(false)
-, toolProxy(new KisToolProxy(parent))
+, toolProxy(new KoToolProxy(parent))
 , favoriteResourceManager(0)
 , vastScrolling(true) {
 }
diff --git a/krita/ui/canvas/kis_tool_proxy.cpp 
b/krita/ui/canvas/kis_tool_proxy.cpp
deleted file mode 100644
index 17479dd..000
--- a/krita/ui/canvas/kis_tool_proxy.cpp
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- *  Copyright (c) 2011 Dmitry Kazakov 
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 
USA.
- */
-
-#include "kis_tool_proxy.h"
-#include "kis_canvas2.h"
-
-KisToolProxy::KisToolProxy(KoCanvasBase *canvas, QObject *parent)
-: KoToolProxy(canvas, parent)
-{
-}
-
-QPointF KisToolProxy::widgetToDocument(const QPointF &widgetPoint) const
-{
-KisCanvas2 *kritaCanvas = dynamic_cast(canvas());
-Q_ASSERT(kritaCanvas);
-
-return kritaCanvas->coordinatesConverter()->widgetToDocument(widgetPoint);
-}
-
diff --git a/krita/ui/canvas/kis_tool_proxy.h b/krita/ui/canvas/kis_tool_proxy.h
deleted file mode 100644
index d30924b..000
--- a/krita/ui/canvas/kis_tool_proxy.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- *  Copyright (c) 2011 Dmitry Kazakov 
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 
USA.
- */
-
-#ifndef __KIS_TOOL_PROXY_H
-#define __KIS_TOOL_PROXY_H
-
-#include 
-
-class KisToolProxy : public KoToolProxy
-{
-public:
-KisToolProxy(KoCanvasBase *canvas, QObject *parent = 0);
-
-protected:
-QPointF widgetToDocument(const QPointF &widgetPoint) const;
-};
-
-#endif /* __KIS_TOOL_PROXY_H */
diff --git a/libs/flake/KoToolProxy.cpp b/libs/flake/KoToolProxy.cpp
index 8429dd8..4f1608e 100644
--- a/libs/flake/KoToolProxy.cpp
+++ b/libs/flake/KoToolProxy.cpp
@@ -48,27 +48,20 @@ KoToolProxyPrivate::KoToolProxyPrivate(KoToolProxy *p)
 void KoToolProxyPrivate::timeout() //

Proposal for new modifiers/shortcuts system

[Dmitry Kazakov]

Hi!

As we discussed at the last Krita sprint, Krita needs some common system to
manage keyboard shortcuts and modifiers. The problem is, different keyboard
keys should switch tools temporarily and restore the tool when the key is
released. E.g. we need canvas panning, rotation, color picking, brush
adjustments.

I was thinking about the design of this system. And i think it is better to
do it Calligra-wide. That's why I've published its design proposal to
Calligra wiki:

http://community.kde.org/Calligra/Libs/Interactional_Tools

Theoretically, all the other tools may be ported to it in the future, but
this is not mandatory as there are wrappers for old tools left.

So i would really like to hear your opinion about this system. Especially,
about naming of the classes =)


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

Re: Proposal for new modifiers/shortcuts system

[Dmitry Kazakov]

> Why calligra only?  This sounds like it is something that would be
> generally useful to all of KDE.
>

Well, it could be good idea to make it kde-wide, but there are two problems:
1) It is supposed to work with tools right now, so we will have to make it
more abstract somehow
2) It might take much time to implement this abstraction and make it
kde-wide-usable

But we can discuss variants, maybe, there is some optimal work/abstraction
tradeoff =) Do you have any idea?

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

Re: Proposal for new modifiers/shortcuts system

[Dmitry Kazakov]

>
> It looks thorough, and it's a part of calligra that has long needed a bit
> of streamlining. I'm not sure about the details -- one thing that's
> important is that I'm not sure that we actually want to stack tools, like
> paint tool temporarily activates pan tool.
>

I would like to switch strategies, not tools. So UI should not dance. =)


> This is the way it's already implemented currently, and it has a couple of
> disadvantages, most importantly that the tool option widget switches. It's
> also only used for zoom/pan.
>
> I'd say it's better to have these canvas tools implemented as interaction
> strategies every tool can use, and not as separate tools.
>

Yep, excatly!

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

Re: Proposal for new modifiers/shortcuts system

[Dmitry Kazakov]

> If I have understood correctly there two types of shortcuts needed.
> 1. Global shortcuts to change tools
> 2. Local shortcuts to change a tools state
>
> What I think is that the global shortcuts should be handled by the
> toolmanager, as that is exactly the kind of things the toolmanager is
> doing.
> For local shortcuts I am not sure why it is not possible to fold the common
> shortcut/gesture handling into the KoInteractionTool base class? I think we
> should keep the number of involved classes at a minimum, otherwise no one
> can
> understand what is actually happening in our tool system.
> Also from reading your requirement list, I hope that you also looked at
> tools
> that are not krita tools.
>

Well, I think I need to clarify it a bit.

These shortcuts should not switch tools (in technical meaning), ideally.
These shortcuts are used for e.g. Color Picking during painting with the
freehand tool (with Ctrl key), panning (with Space), zooming (with
Ctrl+Alt+Space). So ideally, these shortcuts should just temporarily
activate some strategy, change canvas/settings and return the control to the
main tool. There should be no change in UI happen.

Shift+Drag. We haven't created a good name for this action yet. Currently it
is called "gesture", but that is not good due to a conflict with Qt's
definition of a gesture. So we use such "gesture" for configuring the size
of the brush. The user presses the Shift key and starts a drag on a canvas.
The size of the brush changes respectfully.

Why I want to make a separate KoModifiersManager?
Because there are several layers where we can define a shortcut. There is no
such separation as Local/Global.
1st level. We want all the tools (including calligra tools) to support
canvas rotation, zooming, panning. So we add a modifiers manager to
KoToolProxy (maybe, that is not the best place?) to catch all the events.
2nd level. All the paint tools in Krita should support Color Picking. So we
add a manager to KisToolPaint.
3rd level. KisToolFreehand tool should support Shift+Drag "gesture". So we
add a manager here as well.

There might be many other actions and shortcuts we will add later.




>
> Requirement 1:
>
> For instance shift drag is used to override the snapping. And there are
> probably other places where dragging with a modifier is used. So you will
> have
> a hard time reserving those for common stuff.
>

Well, the snapping doesn't work in Krita correctly now, as far as I remember
=) So we use this "gesture" for about a year.
That is really bad, that we don't have any common place where all these
modifiers are defined. They are done in ad-hoc manner in every tool or
manager.


>
> Requirement 2:
>
> Single global key shortcuts are dangerous. The Ctrl modifier is use a lot,
> and
> the space key is also used at least in the text tools.
>

Ctrl is defined in KisToolFreehand's scope. Space -- it is more difficult.
Maybe, some priorities?


> Requirement 3:
> I do not understand that. Can you elaborate, preferably with an example.
>

It was discussed in Krita list. Sorry for telling it too briefly.
There was an idea: when you press the key, the tool switches to some other
tool. If you release the key instantly, then the tool will be switched
permanently. If you keep holding the key pressed, the tool will be switched
back when you release the key.

Long selection process: you are painting something, press 's' for selection,
tool switches, you paint with selection tool to make a selection, then you
press 'f' for the freehand tool and continue painting.

Fast selection process: you are painting something, press 's' for selection
and keep it pressed, tool switches temporarily, you paint with selection
tool to make a selection, then you just release the 's' key to continue
painting.

This is more like idea, it is not to be implemented first.


Requirement 4:
> A Krita specific requirement, is there a more general example? What is
> canvas
> rotation actually, a tool?
>

Canvas rotation is a mode of a pan tool. It rotates the view of the canvas.
It should be as accessible as panning.



> Requirement 5:
>
> I am not sure i understand what you mean by that. Can you be more specific
> please? I.e. how should a tool be canceled when Esc is bound to another
> action?
>

E.g. you started a stroke (or dragging a shape), then you decided you don't
want to do this, you don't release mouse button, but just press Esc key to
interrupt and undo the action.

I think Ecs shouldn't be bound to any actions, because this is a common way
to interrupt the action in all the applications (except of emacs, of
course). =)

Well, maybe your question means how the manager solves the conflicts. It
doesn't solve them.

Re: Proposal for new modifiers/shortcuts system

[Dmitry Kazakov]

Btw, during these discussions I've found two probable problems in this
design.

1) Modifiers of some tools depend on the current state of the tool. So the
structure of the tool and its modifiers represents a state machine. An
example of it is Default Tool. Solution: the entire KoModifiersManager can
be switched on transitions between states. The only trouble here is to
ensure that the previous manager doesn't have any stroke in progress.

2) KoInteractionToolStrategy interface is not the best choice for full
encapsulation of a tool behavior, because it is created when the stroke is
already started. This has several disadvantages: 1) we cannot request from
the strategy, what shortcuts it needs; 2) we cannot ask it to change the
cursor (!) when the modifier is pressed but the stroke is not started. E.g.
when you press Ctrl in KisToolFreehand, the cursor should change to color
picking tool cursor even before starting actual picking.

I see only three solutions for this:
1) (i guess the best one) Encapsulate all the pre-stroke behavior into
KisInteractionStrategy::Factory subclass and ask about the cursor from it.
Btw, this class do already exist in the design.
2) Add static functions to KoInteractionStrategy (quite weird).
3) Do not use KoInteractionTool, but implement a new one with good
strategies those are not created again on every stroke and have a long
lifetime.

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

Design proposal for the tool actions scheduler for Krita

[Dmitry Kazakov]

Hi, all!

I've finished designing the scheduler part of tool actions project.

If you can't remember what this project was intended for, you can read
motivation from the old article:
http://community.kde.org/Krita/Centralized_Queue_For_Tool_Jobs

Just a short summary of it:
All our tools execute actions inside the main event loop. This causes
several major bugs:
1) The UI blocks while doing anything serious
2) (more important) Qt may initiate recursive events processing from the
inside of the other event handler. In particular this can happen due to
calls to processEvents inside KoProgressUpdater framework. If the user is
quite fast, then two tools can easily start their strokes concurrently (even
on single-threaded machine). This usually leads to a crash.
3) Currently, this is workarounded by explicit locking in the tools. Due to
that all the user actions happened during the node was locked are completely
lost.

And here is the new design itself:

http://community.kde.org/Krita/Strokes_Framework


As usual, all the ideas are welcome! =)

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

Raising the dependency of libffi.so

[Dmitry Kazakov]

Hi!

After I've updated to master i can't run Krita, as it crashes with:

krita: error while loading shared libraries: libffi.so.4: cannot open shared
object file: No such file or directory

Yes, I don't have this library installed, but it used to work a month ago.
It looks like added one dependency. Is it a bug? Or I just should install
it?

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

Re: Review Request: Return support for clone layers of group layers

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101928/#review4650
---


There is one old problem in KisNodeManager (will be revealed by the patch). 
KisNodeManager does not call node->allowAsChild() when a node is moved. Instead 
it calls internal version of allowAsChild() (kis_node_manager.cpp:275). So 
you'll have to fix it as well to allow creation of clones for the group layers.

- Dmitry


On July 12, 2011, 11:37 a.m., Torio Mlshi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101928/
> ---
> 
> (Updated July 12, 2011, 11:37 a.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Summary
> ---
> 
> Also add checking if clone layer could be moved to group layer not causing 
> cyclic behaviour.
> 
> 
> This addresses bug 270753.
> http://bugs.kde.org/show_bug.cgi?id=270753
> 
> 
> Diffs
> -
> 
>   krita/image/kis_clone_layer.h a61590a 
>   krita/image/kis_clone_layer.cpp 7638080 
>   krita/image/kis_group_layer.cc 83bd15b 
>   krita/plugins/extensions/dockers/defaultdockers/kis_layer_box.cpp 921bc53 
>   krita/ui/kis_layer_manager.cc fa68be1 
>   krita/ui/kis_node_manager.h 92ee062 
>   krita/ui/kis_node_manager.cpp 4ed6a9b 
> 
> Diff: http://git.reviewboard.kde.org/r/101928/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Torio
> 
>

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

Review Request: Added an undo stack parameter to KoDocument

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102196/
---

Review request for Calligra.


Summary
---

The clients should be able to choose which type of undo stack they are going to 
use. I've made KUndo2Stack polymorphic in my branch, so now i need to be able 
to create my own undo stack for Krita. We can't use a factory method pattern 
here, because the stack should be created in the constructor.


This addresses bug 277736.
http://bugs.kde.org/show_bug.cgi?id=277736


Diffs
-

  libs/main/KoDocument.h 63e4ebf 
  libs/main/KoDocument.cpp 515911a 

Diff: http://git.reviewboard.kde.org/r/102196/diff


Testing
---


Thanks,

Dmitry

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

Re: 2. Calligra Sprint

[Dmitry Kazakov]

On Thu, Sep 8, 2011 at 8:43 PM, C. Boemann  wrote:

> On Thursday 08 September 2011 18:42:12 Boudewijn Rempt wrote:
> > On Thursday 08 September 2011 Sep, Thorsten Zachmann wrote:
> > > On Thursday, September 08, 2011 16:20:12 Cyrille Berger Skott wrote:
> > > > On Thursday 08 September 2011, Thorsten Zachmann wrote:
> > > > > For everybody how might be able to join the sprint at 11.11. please
> > > > > go to https://sprints.kde.org and add yourself as participant and
> > > > > provide the estimated cost for the travel. Don't estimate any costs
> > > > > for hotel.
> > > >
> > > > I guess we need to be validated to appear on the list ?
> > >
> > > As there is no date set it can only be seen in the all sprints view.
> >
> > This is actually complicated:
> >
> > * You need to go to the all-sprints view
> > * then click on the magnify icon in the last column to select the sprint
> > * then it's possible to add yourself, if you're logged in on your
> > identity.kde.org account.
> That wasn't what cyrille meant
>
> I'm added to the sprint to but because my account is not validated either
> neithe me nor cyrille shows up in the list of participants
>

Your accounts are shown, but only if you click on some switches like "Name",
"Food", "Sponsorship". I guess it is a bug of sprints.kde.org. ;)


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

Re: Review Request: Fix loading/saving clone layers

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102896/#review7400
---


Hi!

It's a really cool idea to use uuids here! I think the patch is very good, but 
i have one small concern. Is it possible to remove old code like 
copyFromName(), setCopyFromName() and findNodeByName()? Probably, map the name 
to the uuid right during the loading in KisKraLoader or KisKraLoadVisitor. Is 
it possible? I think keeping this old code might play a negative role in a 
long-term plan =)

- Dmitry Kazakov


On Oct. 16, 2011, 4:59 p.m., Torio Mlshi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102896/
> ---
> 
> (Updated Oct. 16, 2011, 4:59 p.m.)
> 
> 
> Review request for Calligra and Boudewijn Rempt.
> 
> 
> Description
> ---
> 
> This patch fixes saving and loading of clone layers. It adds uuid to 
> KisBaseNode so that clone layers use it to store information about their 
> targets, making sure to target required layer.
> 
> About compatibility:
> All nodes get uuid on creation. So node will have uuid even if no one is 
> provided in file (which overwrites if present). Clone layers also use old 
> code if no copyfromuuid field. So old files should work fine.
> And new files should also be loaded ok by old versions because no fields are 
> removed and old fields (such as copyfrom) are still valid. Of course, old 
> versions will open new files just as old ones and bug will still present 
> there.
> 
> 
> This addresses bug 283610.
> http://bugs.kde.org/show_bug.cgi?id=283610
> 
> 
> Diffs
> -
> 
>   krita/image/kis_base_node.h 798bb06 
>   krita/image/kis_base_node.cpp cccbee8 
>   krita/image/kis_clone_layer.h 21e766e 
>   krita/image/kis_clone_layer.cpp 050ef5f 
>   krita/ui/kra/kis_kra_load_visitor.h 89bf501 
>   krita/ui/kra/kis_kra_load_visitor.cpp d980ab0 
>   krita/ui/kra/kis_kra_loader.cpp 5d3e5d5 
>   krita/ui/kra/kis_kra_savexml_visitor.cpp ecee329 
>   krita/ui/kra/kis_kra_tags.h a737ae3 
> 
> Diff: http://git.reviewboard.kde.org/r/102896/diff/diff
> 
> 
> Testing
> ---
> 
> Old files worked fine, as expected.
> 
> 
> Thanks,
> 
> Torio Mlshi
> 
>

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

Re: Review Request: Fix loading/saving clone layers

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102896/#review7401
---


Hi!

It's a really cool idea to use uuids here! I think the patch is very good, but 
i have one small concern. Is it possible to remove old code like 
copyFromName(), setCopyFromName() and findNodeByName()? Probably, map the name 
to the uuid right during the loading in KisKraLoader or KisKraLoadVisitor. Is 
it possible? I think keeping this old code might play a negative role in a 
long-term plan =)

- Dmitry Kazakov


On Oct. 16, 2011, 4:59 p.m., Torio Mlshi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102896/
> ---
> 
> (Updated Oct. 16, 2011, 4:59 p.m.)
> 
> 
> Review request for Calligra and Boudewijn Rempt.
> 
> 
> Description
> ---
> 
> This patch fixes saving and loading of clone layers. It adds uuid to 
> KisBaseNode so that clone layers use it to store information about their 
> targets, making sure to target required layer.
> 
> About compatibility:
> All nodes get uuid on creation. So node will have uuid even if no one is 
> provided in file (which overwrites if present). Clone layers also use old 
> code if no copyfromuuid field. So old files should work fine.
> And new files should also be loaded ok by old versions because no fields are 
> removed and old fields (such as copyfrom) are still valid. Of course, old 
> versions will open new files just as old ones and bug will still present 
> there.
> 
> 
> This addresses bug 283610.
> http://bugs.kde.org/show_bug.cgi?id=283610
> 
> 
> Diffs
> -
> 
>   krita/image/kis_base_node.h 798bb06 
>   krita/image/kis_base_node.cpp cccbee8 
>   krita/image/kis_clone_layer.h 21e766e 
>   krita/image/kis_clone_layer.cpp 050ef5f 
>   krita/ui/kra/kis_kra_load_visitor.h 89bf501 
>   krita/ui/kra/kis_kra_load_visitor.cpp d980ab0 
>   krita/ui/kra/kis_kra_loader.cpp 5d3e5d5 
>   krita/ui/kra/kis_kra_savexml_visitor.cpp ecee329 
>   krita/ui/kra/kis_kra_tags.h a737ae3 
> 
> Diff: http://git.reviewboard.kde.org/r/102896/diff/diff
> 
> 
> Testing
> ---
> 
> Old files worked fine, as expected.
> 
> 
> Thanks,
> 
> Torio Mlshi
> 
>

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

Re: Review Request: Fix loading/saving clone layers

[Dmitry Kazakov]

> On Oct. 16, 2011, 6:04 p.m., Dmitry Kazakov wrote:
> > Hi!
> > 
> > It's a really cool idea to use uuids here! I think the patch is very good, 
> > but i have one small concern. Is it possible to remove old code like 
> > copyFromName(), setCopyFromName() and findNodeByName()? Probably, map the 
> > name to the uuid right during the loading in KisKraLoader or 
> > KisKraLoadVisitor. Is it possible? I think keeping this old code might play 
> > a negative role in a long-term plan =)
> 
> Torio Mlshi wrote:
> Hi!
> 
> I guess it is impossible to do this good way because during loading clone 
> layer in KisKraLoader all we know is a target name. We even don't know is it 
> created or still only present in xml. I can imagine some hacks which would 
> allow to know uuid of that node (search for existing node with the same name, 
> if found get uuid from it; if not, write to a map that node with required 
> name should have special uuid), but they would be definetly worse is 
> long-term plan.

Well, then you could leave KisKraLoader as it is but encapsulate the clone 
information into a separate object like:

CloneInfo {
public:
CloneInfo(const QUuid &uuid);
CloneInfo(const QString &name);

KisNodeSP findNode(KisNodeSP rootNode);

private:
QUuid m_uuid;
QString m_name;
};

And store this object in clone layers. This would remove all the duplications 
from the layer's code and remove findNodeByName/ByUuid duplicated cycles from 
the loader. The loader would create clone information from information it has 
in xml. What do you think about this solution? 


- Dmitry


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102896/#review7401
---


On Oct. 16, 2011, 4:59 p.m., Torio Mlshi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102896/
> ---
> 
> (Updated Oct. 16, 2011, 4:59 p.m.)
> 
> 
> Review request for Calligra and Boudewijn Rempt.
> 
> 
> Description
> ---
> 
> This patch fixes saving and loading of clone layers. It adds uuid to 
> KisBaseNode so that clone layers use it to store information about their 
> targets, making sure to target required layer.
> 
> About compatibility:
> All nodes get uuid on creation. So node will have uuid even if no one is 
> provided in file (which overwrites if present). Clone layers also use old 
> code if no copyfromuuid field. So old files should work fine.
> And new files should also be loaded ok by old versions because no fields are 
> removed and old fields (such as copyfrom) are still valid. Of course, old 
> versions will open new files just as old ones and bug will still present 
> there.
> 
> 
> This addresses bug 283610.
> http://bugs.kde.org/show_bug.cgi?id=283610
> 
> 
> Diffs
> -
> 
>   krita/image/kis_base_node.h 798bb06 
>   krita/image/kis_base_node.cpp cccbee8 
>   krita/image/kis_clone_layer.h 21e766e 
>   krita/image/kis_clone_layer.cpp 050ef5f 
>   krita/ui/kra/kis_kra_load_visitor.h 89bf501 
>   krita/ui/kra/kis_kra_load_visitor.cpp d980ab0 
>   krita/ui/kra/kis_kra_loader.cpp 5d3e5d5 
>   krita/ui/kra/kis_kra_savexml_visitor.cpp ecee329 
>   krita/ui/kra/kis_kra_tags.h a737ae3 
> 
> Diff: http://git.reviewboard.kde.org/r/102896/diff/diff
> 
> 
> Testing
> ---
> 
> Old files worked fine, as expected.
> 
> 
> Thanks,
> 
> Torio Mlshi
> 
>

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

Re: Review Request: Fix loading/saving clone layers

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102896/#review7512
---

Ship it!


Great work! =)

- Dmitry Kazakov


On Oct. 20, 2011, 4:17 p.m., Torio Mlshi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102896/
> ---
> 
> (Updated Oct. 20, 2011, 4:17 p.m.)
> 
> 
> Review request for Calligra and Boudewijn Rempt.
> 
> 
> Description
> ---
> 
> This patch fixes saving and loading of clone layers. It adds uuid to 
> KisBaseNode so that clone layers use it to store information about their 
> targets, making sure to target required layer.
> 
> About compatibility:
> All nodes get uuid on creation. So node will have uuid even if no one is 
> provided in file (which overwrites if present). Clone layers also use old 
> code if no copyfromuuid field. So old files should work fine.
> And new files should also be loaded ok by old versions because no fields are 
> removed and old fields (such as copyfrom) are still valid. Of course, old 
> versions will open new files just as old ones and bug will still present 
> there.
> 
> 
> This addresses bug 283610.
> http://bugs.kde.org/show_bug.cgi?id=283610
> 
> 
> Diffs
> -
> 
>   krita/image/CMakeLists.txt d4e4768 
>   krita/image/kis_clone_info.h PRE-CREATION 
>   krita/image/kis_clone_info.cpp PRE-CREATION 
>   krita/image/kis_clone_layer.h 5af727d 
>   krita/image/kis_clone_layer.cpp 8d9188c 
>   krita/ui/kra/kis_kra_load_visitor.h 854f6e3 
>   krita/ui/kra/kis_kra_load_visitor.cpp eb392f6 
>   krita/ui/kra/kis_kra_loader.cpp 58e64cb 
>   krita/ui/kra/kis_kra_savexml_visitor.cpp 17c1365 
> 
> Diff: http://git.reviewboard.kde.org/r/102896/diff/diff
> 
> 
> Testing
> ---
> 
> Old files worked fine, as expected.
> 
> 
> Thanks,
> 
> Torio Mlshi
> 
>

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

Re: Unit tests failures

[Dmitry Kazakov]

On Sun, Oct 30, 2011 at 1:52 PM, Boudewijn Rempt  wrote:

> Strange, I see a krita unittest failure:
>
> Test output
>
> * Start testing of KisProcessingsTest *
> Config: Using QTest library 4.6.2, Qt 4.6.2
> PASS   : KisProcessingsTest::initTestCase()
> QDEBUG : KisProcessingsTest::testCropVisitor() qttest(14955)
> KoGenericRegistry::add: Registry already contains item "LABA"
> QDEBUG : KisProcessingsTest::testCropVisitor() qttest(14955)
> KoGenericRegistry::add: Registry already contains item "RGBA16"
> QDEBUG : KisProcessingsTest::testCropVisitor() qttest(14955)
> KoGenericRegistry::add: Registry already contains item "RGBA"
> QDEBUG : KisProcessingsTest::testCropVisitor() qttest(14955)
> KoGenericRegistry::add: Registry already contains item "GRAYA16HISTO"
> QDEBUG : KisProcessingsTest::testCropVisitor() --- Wrong image:
> "initial_blur1_original.png"
> QDEBUG : KisProcessingsTest::testCropVisitor() --- Wrong image:
> "initial_blur1_projection.png"
> FAIL!  : KisProcessingsTest::testCropVisitor() 'checkLayers(image,
> "initial")' returned FALSE. ()
>   Loc:
> [/home/cyrille/src/calligra/krita/image/tests/kis_processings_test.cpp(59)]
> QDEBUG : KisProcessingsTest::testTransformVisitorScale() --- Wrong image:
> "initial_blur1_original.png"
> QDEBUG : KisProcessingsTest::testTransformVisitorScale() --- Wrong image:
> "initial_blur1_projection.png"
> FAIL!  : KisProcessingsTest::testTransformVisitorScale()
> 'checkLayers(image, "initial")' returned FALSE. ()
>   Loc:
> [/home/cyrille/src/calligra/krita/image/tests/kis_processings_test.cpp(59)]
> QDEBUG : KisProcessingsTest::testTransformVisitorScaleRotate() --- Wrong
> image: "initial_blur1_original.png"
> QDEBUG : KisProcessingsTest::testTransformVisitorScaleRotate() --- Wrong
> image: "initial_blur1_projection.png"
> FAIL!  : KisProcessingsTest::testTransformVisitorScaleRotate()
> 'checkLayers(image, "initial")' returned FALSE. ()
>   Loc:
> [/home/cyrille/src/calligra/krita/image/tests/kis_processings_test.cpp(59)]
> PASS   : KisProcessingsTest::cleanupTestCase()
> Totals: 2 passed, 3 failed, 0 skipped
> * Finished testing of KisProcessingsTest *
> kDebugStream called after destruction (from
> KisMemoryLeakTracker::~KisMemoryLeakTracker() file
> /home/cyrille/src/calligra/krita/image/kis_memory_leak_tracker.cpp line 128)
> No leak detected.
>
>
> But that test has never failed for me locally. Could it be an lcms1 vs
> lcms2 issue?
>

Yes, it compares png's so it is due to lcms. Btw, chuncher has an old
version of Qt.


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

Re: Review Request: Fix crashing when using tools on empty image

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103003/#review7782
---

Ship it!


Thanks for the fix! =)
Just two small things: 
1) I think it would be logical to reset the stroke id right after 
endStroke(m_strokeId) in mouseReleaseEvent() function. Like:
   image->endStroke(m_strokeId);
   m_strokeId.clear();
2) And we are using kde coding style for positioning braces around 'if's ;) [1]


[1] - http://techbase.kde.org/Policies/Kdelibs_Coding_Style

- Dmitry Kazakov


On Oct. 31, 2011, 7:26 p.m., Torio Mlshi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103003/
> ---
> 
> (Updated Oct. 31, 2011, 7:26 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> When image is empty (has no layers), color picker & move tools caused crashes 
> when using. This patch adds checking if currentNode() returns 0. If so, no 
> action is done.
> 
> 
> Diffs
> -
> 
>   krita/plugins/tools/defaulttools/kis_tool_colorpicker.cc 006aa78 
>   krita/plugins/tools/defaulttools/kis_tool_move.cc 1ee0baa 
> 
> Diff: http://git.reviewboard.kde.org/r/103003/diff/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Torio Mlshi
> 
>

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

Re: Review Request: Fix clone layers updating

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103021/#review7845
---


The bug is a really good catch! I didn't even think about it. =)

But the problem is, this very solution will not work, I'm afraid. There is a 
couple of problems.
1) setDirty() and refreshGraphAsync() do different things actually. setDirty() 
updates the node and all its parent nodes (that is the nodes above the dirty 
one). refreshGraphAsync first updates the subgraph of nodes below the dirty 
node, after that all the parent nodes (the work of setDirty()). Specifically 
for this solution, it won't work for moving group layers with children.
2) every setDirty() call adds a separate job to the updater, so calling 
setDirty() for all the parent nodes will add too much excessive work.


As for working solution, atm I cannot tell exactly we can do here, but I have 
the following thoughts:
1) There are already updates for clone layers in KisLayers::setDirty() so there 
is no need for additional method in KisNode.
2) The real problem here is that refreshGraphAsync() does not (and should not) 
call to setDirty(), so the clones are not updated.
3) There is one more problem possible: when the node above the dirty node is 
updated, its setDirty() is not called as well, so the clones of such node (it 
can be an issue for a group and filter layer only) will not be updated.
4) The most sane solution, i think, would be to move the call to 
'm_d->clonesList.setDirty(rect);' from setDirty() into something like 
updateProjection() call. But there are several problems possible like race 
conditions and deadlocks as the latter method is called asynchronously from 
several non-UI threads. I will check whether it is possible, but not earlier 
than Thursday.

- Dmitry Kazakov


On Nov. 1, 2011, 7:25 p.m., Torio Mlshi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103021/
> ---
> 
> (Updated Nov. 1, 2011, 7:25 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> This patch fixes issues, when clone layer wasn't updating despite its 
> original was changed.
> 
> KisNode::setDirty now calls setDirty of parent to let its clones know about 
> update. In MoveStrokeStrategy updating is now implemented via setDirty, so 
> clone layers will know about update.
> 
> 
> Diffs
> -
> 
>   krita/image/kis_node.cpp 52881e7 
>   krita/plugins/tools/defaulttools/strokes/move_stroke_strategy.cpp df8b6da 
> 
> Diff: http://git.reviewboard.kde.org/r/103021/diff/diff
> 
> 
> Testing
> ---
> 
> Normal moving (when no clones) seems to have the same performance. Of course, 
> performance becomes low when many clones are involved.
> 
> Unit tests have same results for me.
> 
> 
> Thanks,
> 
> Torio Mlshi
> 
>

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

Re: hello!

[Dmitry Kazakov]

>
> I would like to contribute to calligra by developing/improving
> applications/softwares. I am good at coding and different programming
> languages. Can i know if there is any project or task suitable for me?
> Hoping for a favorable reply.
>

Hello!

We are always glad to see new developers! I think people will suggest you
several projects in different parts of Calligra. I can tell you about Krita
application. =)

There is a cool project in Krita. Our Flood Fill tool is a bit of slow
currently ;) [1] As far as I remember the algorithm there is quite
straightforward, so, probably, there is some space for optimization
present. There are several directions for investigations:

- use some cool algorithm for filling areas (if there is something better
present)
- investigate with callgrind for speed/memory bottlenecks (I guess memory
access is really a case there)
- try using multithreading for the tool (you will be able to use our new
framework for multithreading of tools: "strokes framework")

This may be quite a challenging and complex task. But you will get much
experience in krita codebase.

Of course, there are many simple tasks you can try to begin with as well.
For example, this one: [2]



[1] - https://bugs.kde.org/show_bug.cgi?id=268212
[2] - https://bugs.kde.org/show_bug.cgi?id=282549


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

Review Request: Fix bug with zero scale of the brush in krita

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103445/
---

Review request for Calligra.


Description
---

When using tablet, the last events coming from it are almost zero, so the 
resulting scale is zero as well. Default mask generator will get crazy if it 
gets zero scale due to division by zero. So we need to check in most of the 
tools whether the scale is zero.


This addresses bug 289145.
http://bugs.kde.org/show_bug.cgi?id=289145


Diffs
-

  krita/plugins/paintops/complexop/kis_complexop.cpp b0742ea 
  krita/plugins/paintops/defaultpaintops/duplicate/kis_duplicateop.cpp 9a2d75a 
  krita/plugins/paintops/deform/kis_deform_paintop.cpp e8c1f51 
  krita/plugins/paintops/hairy/kis_hairy_paintop.cpp b6c2773 
  krita/plugins/paintops/sketch/kis_sketch_paintop.cpp 0a86895 
  krita/plugins/paintops/spray/kis_spray_paintop.cpp 4d8a6f2 

Diff: http://git.reviewboard.kde.org/r/103445/diff/diff


Testing
---


Thanks,

Dmitry Kazakov

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

Review Request: Fixed a tool activation when the current layer is not enabled (KoToolManager)

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104075/
---

Review request for Calligra.


Description
---

Way to reproduce:
1) Open new document
2) Disable a layer with a mouse
3) Enable a layer with a tablet
You will not be able to paint with the tablet.

What actually happened was that a new CanvasData was created, but the previous 
tool could not be activated in the new data, because of an explicit check in 
switchTool. So that we ended up in a state with no tool at all.

This patch brings a bit more consistency there. Now you can always switch the 
tool in the KoToolManager, even when active layer is disabled, but the 
KoToolProxy will get information about the new tool only when the layer gets 
enabled back. This is what the code in currentLayerChanged() and 
toolCanBeUsed() has been doing before. There was inconsistency in 
postSwitchTool(), because it didn't check for the availability of the active 
layer, now it does.


This addresses bug 277047.
http://bugs.kde.org/show_bug.cgi?id=277047


Diffs
-

  libs/flake/KoToolManager.cpp 855d3ea 
  libs/flake/KoToolManager_p.h ca7e0d2 

Diff: http://git.reviewboard.kde.org/r/104075/diff/


Testing
---


Thanks,

Dmitry Kazakov

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

Review Request: Backport 2.4: "Fixed rotation of layers"

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104145/
---

Review request for Calligra.


Description
---

Just merged with the rotation code of the image


http://commits.kde.org/calligra/f80a2ff0fbe5f7a5aee88ad86378a3ffac7ba594


This addresses bug 279772.
http://bugs.kde.org/show_bug.cgi?id=279772


Diffs
-

  krita/image/kis_image.h 07537a1 
  krita/image/kis_image.cc fc505dd 
  krita/plugins/extensions/scripting/kritacore/krs_image.h 6e3fcc5 
  krita/plugins/extensions/scripting/kritacore/krs_image.cpp b88dde0 
  krita/plugins/formats/jpeg/kis_jpeg_converter.cc 7536313 
  krita/ui/kis_image_manager.cc c9376bb 
  krita/ui/kis_layer_manager.cc ee5cdbc 

Diff: http://git.reviewboard.kde.org/r/104145/diff/


Testing
---


Thanks,

Dmitry Kazakov

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

Review Request: Backport 2.4: Fixed Pipe Brush mask generation

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104146/
---

Review request for Calligra.


Description
---

Just removed a check added due to non-obvious naming. The range is guaranteed 
by another check in brushIndex() function.

http://commits.kde.org/calligra/bafbe74c784b0c7da1a693fd86a50dd8ab3f016b


This addresses bug 293828.
http://bugs.kde.org/show_bug.cgi?id=293828


Diffs
-

  krita/plugins/paintops/libbrush/kis_imagepipe_brush.cpp ca1a5cc 

Diff: http://git.reviewboard.kde.org/r/104146/diff/


Testing
---


Thanks,

Dmitry Kazakov

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

Re: Review Request: Backport 2.4: Fixed Pipe Brush mask generation

[Dmitry Kazakov]

> On March 5, 2012, 9:38 a.m., Boudewijn Rempt wrote:
> > The bug isn't solved by this patch, so it's not ready for backporting.

This is a different bug: https://bugs.kde.org/show_bug.cgi?id=295464


- Dmitry


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104146/#review11137
---


On March 3, 2012, 2:46 p.m., Dmitry Kazakov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104146/
> ---
> 
> (Updated March 3, 2012, 2:46 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> Just removed a check added due to non-obvious naming. The range is guaranteed 
> by another check in brushIndex() function.
> 
> http://commits.kde.org/calligra/bafbe74c784b0c7da1a693fd86a50dd8ab3f016b
> 
> 
> This addresses bug 293828.
> http://bugs.kde.org/show_bug.cgi?id=293828
> 
> 
> Diffs
> -
> 
>   krita/plugins/paintops/libbrush/kis_imagepipe_brush.cpp ca1a5cc 
> 
> Diff: http://git.reviewboard.kde.org/r/104146/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dmitry Kazakov
> 
>

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

Re: Review Request: Replace all old-style iterators with NG iterators

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104771/#review13021
---


Well, I would really like if we had resolved the recently found design issues 
of NG iterators before merging it to master.

1) I would prefer fixing the real cause of them (the order of the checks in the 
cycle). But if you insist on limiting the usage scope of iterators to valid 
rects only, then ok.

2) I agree with Cyrille that adding constRawData() might be a good idea, but I 
won't argue on this point.

3) Did you intend to remove the files for with old iterators and accessors? It 
looks like they are still in the tree.


- Dmitry Kazakov


On April 28, 2012, 9:49 a.m., Boudewijn Rempt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104771/
> ---
> 
> (Updated April 28, 2012, 9:49 a.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> We implemented a next generation of iterators in 2010 but never managed to 
> part of Krita to the newer, faster iterators. This patch finishes the 
> porting. Branch testers have confirmed that Krita feels quite a bit smoother 
> and responsive now.
> 
> 
> Diffs
> -
> 
>   krita/benchmarks/CMakeLists.txt c30532c 
>   krita/benchmarks/kis_bcontrast_benchmark.cpp c2768c9 
>   krita/benchmarks/kis_blur_benchmark.cpp e082cdc 
>   krita/benchmarks/kis_floodfill_benchmark.cpp a8100d0 
>   krita/benchmarks/kis_gradient_benchmark.cpp 9dbcb52 
>   krita/benchmarks/kis_hline_iterator_benchmark.cpp 76cfbd0 
>   krita/benchmarks/kis_painter_benchmark.cpp 20229b5 
>   krita/benchmarks/kis_projection_benchmark.cpp 68dba89 
>   krita/benchmarks/kis_random_iterator_benchmark.cpp 08ce0d4 
>   krita/benchmarks/kis_rect_iterator_benchmark.h 89341a5 
>   krita/benchmarks/kis_rect_iterator_benchmark.cpp 134bc61 
>   krita/benchmarks/kis_stroke_benchmark.cpp 6809fd5 
>   krita/benchmarks/kis_vline_iterator_benchmark.cpp 614896d 
>   krita/image/CMakeLists.txt c501a70 
>   krita/image/brushengine/kis_paintop.cc a550249 
>   krita/image/config-tiles.h.cmake cfb1056 
>   krita/image/filter/kis_color_transformation_filter.cc 70d2b8f 
>   krita/image/kis_convolution_painter.cc 318d188 
>   krita/image/kis_convolution_worker.h f8177d5 
>   krita/image/kis_convolution_worker_fft.h 5b4b5ae 
>   krita/image/kis_convolution_worker_spatial.h dd613f8 
>   krita/image/kis_fill_painter.cc f241585 
>   krita/image/kis_gradient_painter.cc b110998 
>   krita/image/kis_histogram.cc 02656b6 
>   krita/image/kis_image.cc d229b31 
>   krita/image/kis_math_toolbox.cpp 1644a0d 
>   krita/image/kis_node_graph_listener.cpp 20fe5c8 
>   krita/image/kis_paint_device.h 1a9b7f8 
>   krita/image/kis_paint_device.cc 6c57e7d 
>   krita/image/kis_painter.h 8ea7949 
>   krita/image/kis_painter.cc acbd275 
>   krita/image/kis_perspectivetransform_worker.cpp 8dd1b47 
>   krita/image/kis_pixel_selection.cpp fd2d18a 
>   krita/image/kis_queues_progress_updater.cpp 24f2164 
>   krita/image/kis_random_sub_accessor.h 2a889db 
>   krita/image/kis_random_sub_accessor.cpp a086840 
>   krita/image/kis_repeat_iterators_pixel.h 30adc86 
>   krita/image/kis_selection.cc b835145 
>   krita/image/kis_strokes_queue.cpp 23a25a4 
>   krita/image/kis_transform_worker.cc 6e70529 
>   krita/image/kis_types.h a7d8a4b 
>   krita/image/kis_warptransform_worker.cc 11ed991 
>   krita/image/tests/CMakeLists.txt 7365a0d 
>   krita/image/tests/kis_iterator_benchmark.cpp cfa1085 
>   krita/image/tests/kis_iterator_test.cpp 2869397 
>   krita/image/tests/kis_iterators_ng_test.cpp e99e23d 
>   krita/image/tests/kis_iterators_pixel_test.h df1c8fe 
>   krita/image/tests/kis_iterators_pixel_test.cpp f2a5c6b 
>   krita/image/tests/kis_paint_layer_test.cpp 948c2db 
>   krita/image/tests/kis_painter_test.cpp aae58fd 
>   krita/image/tests/kis_pixel_selection_test.h a89aa51 
>   krita/image/tests/kis_pixel_selection_test.cpp 542be4e 
>   krita/image/tests/kis_projection_test.cpp cd05a40 
>   krita/image/tests/kis_threaded_applicator_test.cpp 854c35c 
>   krita/image/tests/kis_transaction_test.cpp 2c9eebe 
>   krita/image/tiles3/kis_hline_iterator.h 578d8c9b 
>   krita/image/tiles3/kis_hline_iterator.cpp fcc5bda 
>   krita/image/tiles3/kis_rect_iterator.cpp a2299e1 
>   krita/image/tiles3/kis_vline_iterator.h 23ed461 
>   krita/image/tiles3/kis_vline_iterator.cpp 0855de2 
>   krita/plugins/extensions/colorrange/colorrange.cc 41e11c3 
>   krita/plugins/extensions/c

Re: Review Request: Replace all old-style iterators with NG iterators

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104771/#review13022
---


Well, I would really like if we had resolved the recently found design issues 
of NG iterators before merging it to master.

1) I would prefer fixing the real cause of them (the order of the checks in the 
cycle). But if you insist on limiting the usage scope of iterators to valid 
rects only, then ok.

2) I agree with Cyrille that adding constRawData() might be a good idea, but I 
won't argue on this point.

3) Did you intend to remove the files for with old iterators and accessors? It 
looks like they are still in the tree.


- Dmitry Kazakov


On April 28, 2012, 9:49 a.m., Boudewijn Rempt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104771/
> ---
> 
> (Updated April 28, 2012, 9:49 a.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> We implemented a next generation of iterators in 2010 but never managed to 
> part of Krita to the newer, faster iterators. This patch finishes the 
> porting. Branch testers have confirmed that Krita feels quite a bit smoother 
> and responsive now.
> 
> 
> Diffs
> -
> 
>   krita/benchmarks/CMakeLists.txt c30532c 
>   krita/benchmarks/kis_bcontrast_benchmark.cpp c2768c9 
>   krita/benchmarks/kis_blur_benchmark.cpp e082cdc 
>   krita/benchmarks/kis_floodfill_benchmark.cpp a8100d0 
>   krita/benchmarks/kis_gradient_benchmark.cpp 9dbcb52 
>   krita/benchmarks/kis_hline_iterator_benchmark.cpp 76cfbd0 
>   krita/benchmarks/kis_painter_benchmark.cpp 20229b5 
>   krita/benchmarks/kis_projection_benchmark.cpp 68dba89 
>   krita/benchmarks/kis_random_iterator_benchmark.cpp 08ce0d4 
>   krita/benchmarks/kis_rect_iterator_benchmark.h 89341a5 
>   krita/benchmarks/kis_rect_iterator_benchmark.cpp 134bc61 
>   krita/benchmarks/kis_stroke_benchmark.cpp 6809fd5 
>   krita/benchmarks/kis_vline_iterator_benchmark.cpp 614896d 
>   krita/image/CMakeLists.txt c501a70 
>   krita/image/brushengine/kis_paintop.cc a550249 
>   krita/image/config-tiles.h.cmake cfb1056 
>   krita/image/filter/kis_color_transformation_filter.cc 70d2b8f 
>   krita/image/kis_convolution_painter.cc 318d188 
>   krita/image/kis_convolution_worker.h f8177d5 
>   krita/image/kis_convolution_worker_fft.h 5b4b5ae 
>   krita/image/kis_convolution_worker_spatial.h dd613f8 
>   krita/image/kis_fill_painter.cc f241585 
>   krita/image/kis_gradient_painter.cc b110998 
>   krita/image/kis_histogram.cc 02656b6 
>   krita/image/kis_image.cc d229b31 
>   krita/image/kis_math_toolbox.cpp 1644a0d 
>   krita/image/kis_node_graph_listener.cpp 20fe5c8 
>   krita/image/kis_paint_device.h 1a9b7f8 
>   krita/image/kis_paint_device.cc 6c57e7d 
>   krita/image/kis_painter.h 8ea7949 
>   krita/image/kis_painter.cc acbd275 
>   krita/image/kis_perspectivetransform_worker.cpp 8dd1b47 
>   krita/image/kis_pixel_selection.cpp fd2d18a 
>   krita/image/kis_queues_progress_updater.cpp 24f2164 
>   krita/image/kis_random_sub_accessor.h 2a889db 
>   krita/image/kis_random_sub_accessor.cpp a086840 
>   krita/image/kis_repeat_iterators_pixel.h 30adc86 
>   krita/image/kis_selection.cc b835145 
>   krita/image/kis_strokes_queue.cpp 23a25a4 
>   krita/image/kis_transform_worker.cc 6e70529 
>   krita/image/kis_types.h a7d8a4b 
>   krita/image/kis_warptransform_worker.cc 11ed991 
>   krita/image/tests/CMakeLists.txt 7365a0d 
>   krita/image/tests/kis_iterator_benchmark.cpp cfa1085 
>   krita/image/tests/kis_iterator_test.cpp 2869397 
>   krita/image/tests/kis_iterators_ng_test.cpp e99e23d 
>   krita/image/tests/kis_iterators_pixel_test.h df1c8fe 
>   krita/image/tests/kis_iterators_pixel_test.cpp f2a5c6b 
>   krita/image/tests/kis_paint_layer_test.cpp 948c2db 
>   krita/image/tests/kis_painter_test.cpp aae58fd 
>   krita/image/tests/kis_pixel_selection_test.h a89aa51 
>   krita/image/tests/kis_pixel_selection_test.cpp 542be4e 
>   krita/image/tests/kis_projection_test.cpp cd05a40 
>   krita/image/tests/kis_threaded_applicator_test.cpp 854c35c 
>   krita/image/tests/kis_transaction_test.cpp 2c9eebe 
>   krita/image/tiles3/kis_hline_iterator.h 578d8c9b 
>   krita/image/tiles3/kis_hline_iterator.cpp fcc5bda 
>   krita/image/tiles3/kis_rect_iterator.cpp a2299e1 
>   krita/image/tiles3/kis_vline_iterator.h 23ed461 
>   krita/image/tiles3/kis_vline_iterator.cpp 0855de2 
>   krita/plugins/extensions/colorrange/colorrange.cc 41e11c3 
>   krita/plugins/extensions/c

Need review and testing for 'zoom-pan-testing-kazakov' branch

[Dmitry Kazakov]

Hi!

I've just finished the branch which fixes various zoom/pan bugs in Krita
and adds comprehensive testing for it. It would be really cool if someone
could test it and review before I merge it to master. I send the mail to
calligra list as well, because it touches a couple of classes in
./libs/flake/ as well.

This branch touches KoCanvasControllerWidget, so, theoretically, it may
affect other applications, so it might be necessary to check them for
regressions as well. I checked Karbon and it seems to work fine.

What should be tested in Krita:
1) Usual Zoom and Pan
2) Zoom and Pan in Fullscreen mode
3) Zoom and Pan on rotated canvas
4) Zoom and Pan on mirrored canvas
5) (optional) Zoom and Pan with VastScrolling disabled.

In other applications:
1) There should be no regressions ;)


Thank you in advance!


PS:

Small howto:
The changes are in the branch 'zoom-pan-testing-kazakov'. So to check you
need to switch to it:

git fetch
git checkout origin/zoom-pan-testing-kazakov


To switch back to master:

git checkout master

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

Review Request: The dab cache for Krita

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106724/
---

Review request for Calligra and Lukáš Tvrdý.


Description
---

Hi!

This patch adds caching of the dabs to the paint op system of Krita. Such cache 
makes the execution of the benchmarks up to 2 times faster. Subjectively, the 
real painting becomes much faster, especially with huge brushes.

Of course, such caching makes the painting a bit less precise: we need to 
tolerate subpixel differences to allow the cache to work. Sometimes small 
difference in the size of a dab can also be acceptable. That is why I 
introduced levels of precision. They are graded from 1 to 5: from the fastest 
and less precise to the slowest, but with the best quality. You can see the 
slider in the paintop settings dialog. The ToolTip text explains which features 
of the brush are sacrificed on each precision level.

The texturing and mirroring problems are solved.

My next steps are: make this cache tolerate bug 307588 and port it to other 
brush-based paitops.


Diffs
-

  krita/image/kis_fixed_paint_device.h feeed0b 
  krita/image/kis_fixed_paint_device.cpp 5ef55af 
  krita/image/kis_painter.h 25a11c9 
  krita/image/kis_painter.cc bec3776 
  krita/plugins/paintops/defaultpaintops/brush/kis_brushop.h 1b545ef 
  krita/plugins/paintops/defaultpaintops/brush/kis_brushop.cpp 177fa7e 
  krita/plugins/paintops/defaultpaintops/brush/kis_brushop_settings_widget.cpp 
cbd6667 
  krita/plugins/paintops/libpaintop/CMakeLists.txt bd1b021 
  krita/plugins/paintops/libpaintop/forms/wdgbrushchooser.ui b19828f 
  krita/plugins/paintops/libpaintop/kis_brush_based_paintop_options_widget.h 
734df21 
  krita/plugins/paintops/libpaintop/kis_brush_based_paintop_options_widget.cpp 
51cc2d2 
  krita/plugins/paintops/libpaintop/kis_brush_option_widget.h cf426cb 
  krita/plugins/paintops/libpaintop/kis_brush_option_widget.cpp c0e171e 
  krita/plugins/paintops/libpaintop/kis_brush_selection_widget.h d25729f 
  krita/plugins/paintops/libpaintop/kis_brush_selection_widget.cpp e0bedd8 
  krita/plugins/paintops/libpaintop/kis_dab_cache.h PRE-CREATION 
  krita/plugins/paintops/libpaintop/kis_dab_cache.cpp PRE-CREATION 
  krita/plugins/paintops/libpaintop/kis_precision_option.h PRE-CREATION 
  krita/plugins/paintops/libpaintop/kis_precision_option.cpp PRE-CREATION 
  krita/plugins/paintops/libpaintop/kis_pressure_sharpness_option.h 8281da4 
  krita/plugins/paintops/libpaintop/kis_pressure_sharpness_option.cpp 6157e5e 

Diff: http://git.reviewboard.kde.org/r/106724/diff/


Testing
---


Thanks,

Dmitry Kazakov

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

Re: Review Request: The dab cache for Krita

[Dmitry Kazakov]

> On Oct. 5, 2012, 9:16 a.m., Lukáš Tvrdý wrote:
> > krita/plugins/paintops/defaultpaintops/brush/kis_brushop.cpp, line 187
> > <http://git.reviewboard.kde.org/r/106724/diff/1/?file=88422#file88422line187>
> >
> > Where is this code now?

This is now done in KisDabCache::postProcessDab


> On Oct. 5, 2012, 9:16 a.m., Lukáš Tvrdý wrote:
> > krita/plugins/paintops/libpaintop/kis_dab_cache.h, line 67
> > <http://git.reviewboard.kde.org/r/106724/diff/1/?file=88432#file88432line67>
> >
> > Documentation, please. At least for every public method.

Yeah, I'll do it in the next version of the patch, when the bug 307588 is fixed.


- Dmitry


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106724/#review19953
-----------


On Oct. 4, 2012, 2:30 p.m., Dmitry Kazakov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106724/
> ---
> 
> (Updated Oct. 4, 2012, 2:30 p.m.)
> 
> 
> Review request for Calligra and Lukáš Tvrdý.
> 
> 
> Description
> ---
> 
> Hi!
> 
> This patch adds caching of the dabs to the paint op system of Krita. Such 
> cache makes the execution of the benchmarks up to 2 times faster. 
> Subjectively, the real painting becomes much faster, especially with huge 
> brushes.
> 
> Of course, such caching makes the painting a bit less precise: we need to 
> tolerate subpixel differences to allow the cache to work. Sometimes small 
> difference in the size of a dab can also be acceptable. That is why I 
> introduced levels of precision. They are graded from 1 to 5: from the fastest 
> and less precise to the slowest, but with the best quality. You can see the 
> slider in the paintop settings dialog. The ToolTip text explains which 
> features of the brush are sacrificed on each precision level.
> 
> The texturing and mirroring problems are solved.
> 
> My next steps are: make this cache tolerate bug 307588 and port it to other 
> brush-based paitops.
> 
> 
> Diffs
> -
> 
>   krita/image/kis_fixed_paint_device.h feeed0b 
>   krita/image/kis_fixed_paint_device.cpp 5ef55af 
>   krita/image/kis_painter.h 25a11c9 
>   krita/image/kis_painter.cc bec3776 
>   krita/plugins/paintops/defaultpaintops/brush/kis_brushop.h 1b545ef 
>   krita/plugins/paintops/defaultpaintops/brush/kis_brushop.cpp 177fa7e 
>   
> krita/plugins/paintops/defaultpaintops/brush/kis_brushop_settings_widget.cpp 
> cbd6667 
>   krita/plugins/paintops/libpaintop/CMakeLists.txt bd1b021 
>   krita/plugins/paintops/libpaintop/forms/wdgbrushchooser.ui b19828f 
>   krita/plugins/paintops/libpaintop/kis_brush_based_paintop_options_widget.h 
> 734df21 
>   
> krita/plugins/paintops/libpaintop/kis_brush_based_paintop_options_widget.cpp 
> 51cc2d2 
>   krita/plugins/paintops/libpaintop/kis_brush_option_widget.h cf426cb 
>   krita/plugins/paintops/libpaintop/kis_brush_option_widget.cpp c0e171e 
>   krita/plugins/paintops/libpaintop/kis_brush_selection_widget.h d25729f 
>   krita/plugins/paintops/libpaintop/kis_brush_selection_widget.cpp e0bedd8 
>   krita/plugins/paintops/libpaintop/kis_dab_cache.h PRE-CREATION 
>   krita/plugins/paintops/libpaintop/kis_dab_cache.cpp PRE-CREATION 
>   krita/plugins/paintops/libpaintop/kis_precision_option.h PRE-CREATION 
>   krita/plugins/paintops/libpaintop/kis_precision_option.cpp PRE-CREATION 
>   krita/plugins/paintops/libpaintop/kis_pressure_sharpness_option.h 8281da4 
>   krita/plugins/paintops/libpaintop/kis_pressure_sharpness_option.cpp 6157e5e 
> 
> Diff: http://git.reviewboard.kde.org/r/106724/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dmitry Kazakov
> 
>

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

Review Request: Fixed deactivation of the tools when input device is switched

[Dmitry Kazakov]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107205/
---

Review request for Calligra.


Description
---

Fixed deactivation of the tools when input device is switched

There are lots of things that have to be done when we switch current canvasData 
object. That is why I moved all these actions into switchCanvasData object. The 
old tool first becomes disconnected from the tool manager, then the canvasData 
is switched and a new tool is connected.

This patch fixes several bugs when the tools was not deactivated properly when 
the input device was switched, so their hotkeys were kept activated. More than 
that, this fix is needed to be able to solve bug 298584 properly.


Diffs
-

  libs/flake/KoToolManager.cpp c121d0f 
  libs/flake/KoToolManager_p.h 85985df 

Diff: http://git.reviewboard.kde.org/r/107205/diff/


Testing
---

Tested in Krita and Karbon.


Thanks,

Dmitry Kazakov

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

Need help with reviewing and testing the KoToolManager changes

[Dmitry Kazakov]

Hi!

Some time ago I've done a patch [0] for the KoToolManager, which fixes the
deactivation of tools while switching the input device. This patch is
completely necessary for fixing the bug 298584 in Krita, because otherwise
Krita will not know when to finish the action of the tool.

Alongside with the deactivation, the patch also allows to disconnect the
actions of the previous tool properly and fixes initialization of the
status bar text for the tool. Without this patch, if you work with two
tools (e.g. Text tool and Brush tool) associated to two different devices,
the test in the status bar will be mixed.

One more bug which is fixed by the patch affects all the Calligra
application when they work in Multiple Views mode. If you assign two
different tools to two devices, then create a new view, then when switching
the devices, the tools will be switched in the initial view instead of a
new one. The selection decorations will be shown wrongly as well. This
happens because the canvasData object is not switched properly (the link to
the new KoCanvasControllerWidget is not established). This patch fixes this
bug as well.

Could you please test and/or review this patch so I could merge it to
master and, if possible, to calligra/2.6 ? You can test it either by
directly applying the patch from the reviewboard or by just checking out my
branch: krita-new-move-tool-kazakov

I tested this patch with Krita, Karbon, Flow and Words and found no
regressions.


[0] - https://git.reviewboard.kde.org/r/107205/
[1] - https://bugs.kde.org/show_bug.cgi?id=298584
-- 
Dmitry Kazakov
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

New PACKAGERS_BUILD option for building Calligra

[Dmitry Kazakov]

Hello!

As you may already know right now I am working on making vector
optimizations for Krita work on different CPUs when distributed as a binary
package. To achieve this goal I used some cmake magic (borrowed from Vc
project ;) ) to produce multi-arch builds for the hottest parts of pigment
and Krita. That is a single .cpp file is compiled several times with
different compiller flags; the resulting .o files are put into a single .so
library (libpigmentcms.so) and the choice of the exact version of the code
occurs on the fly when the colorspaces are created.

This approach has several pros and cons and we need a kind of compromise
here, that is why I would like to ask for your opinion:

Pros:
1) We can have prebuild versions for all the architectures supported by Vc
(Amd XMA4 and XOP are not supported by Vc yet), it means we can
redistribute optimized binary version of Krita.

Cons:
1) Currently the code depends on Vc's 'staging' branch, so it can't be put
in master. For now all the changes are kept in
'vector_compositioning_kazakov' branch.
2) I used fat-binary approach for code generation. It means that all the
versions of the code are put into a single binary (libpigmentcms.so) and
therefore are loaded into user's RAM on the start. This is a matter of
excessive 3 MiB of user's RAM (libpigmentcms.so grew 15MiB -> 18MiB [1])
3) If we want the binary to be redistributable, the compiler optimization
for the rest of the code (not hotspots) must be disabled. In the benchmarks
it leads to a slight (~20%) performance degradation on *some* of the tests.
This is actually not much in comparison with the gain we get from using
vector instructions, but still...


In my opinion the mentioned disadvantages are not much serious. The only
concern I have is the size of the binary. The solution for it might be the
use of separate .so libraries for each implementation, but I guess (at
least for now) we can ignore it. 3MiB is not that much.

The problem of the speed degradation, I believe, cannot be (at least
easily) solved without distributing per-architecture compiled kritaimage.so
library. Each instance of this library takes 45MiB. Which leads to
additional 7*45=315MiB in the distribution package. That is not worth it.

Taking all this into account I decided to introduce a new option for the
Calligra build system: PACKAGERS_BUILD.

When the option is ON, the per-architecture builds are activated. The
optimization for all the other parts is disabled. This is exactly what is
needed by packagers.
When the option is OFF, the whole Calligra project is optimized for the
host CPU. No per-arch build are, therefore, done. This option is the best
choice for users who build Calligra themselves.

By default the option is OFF. It means that we need to tell packagers to
activate it. Where should I write about it? Do we have any packager's
manual?

I would appreciate any comments from you about this! :)


[1] - in commit message I told about the growth 11->17MiB. I was wrong
because measured it on the wrong binary.

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