Preset widgets refactoring

[Dmitry Kazakov]

Hi, Stefano!

Yeah, the code in the PaintOpBox is rather messy. And yes, we use widgets
as a data model for paintop presets. That is not too nice, and I also had
to spend a bit of time because of it when doing LoD switches.

If I were your I would not try to follow the order of calls by
KisPaintopBox, but just started from a blank page:

1) Cut off external interfaces and define them strictly. E.g. though
"widgets as a data model" is not a beautiful solution, it can be used
without much changes E.g. KisPaintOpSettingsWidget has quite a usable
read/write interface, which can be reused.

2) After you decided what you are going to reuse, you can easily combine
them in some new class/classes. You can use UML for graphical
representation of it. I usually go to creately.com and do UML drafts there.

We can organize a skype session next week if you like :)


On Thu, Sep 3, 2015 at 5:21 PM, Stefano Bonicatti <smjert at gmail.com> wrote:

> Ah, i get why there's this coupling then.
> I also realized some things like, preset settings that store a reference
> to the option widget. I didn't look then what it does with it, but it looks
> suspicious to me, i would actually expect that the option widget reads and
> does things to the settings, not the opposite.
>
> Anyway i'm using an etherpad ->
> https://notes.kde.org/p/preset-widget-refactoring to make an "analysis"
> of all the classes (and especially parts of them involved with presets),
> noting down also comments and things i think about how to change some of
> the code etc.
> Currently it's in his infancy because i did it yesterday very late..
> I've found that i cannot remember things day by day otherwise (since i
> started working :P), was used to keep everything into my mind eheh.
>
> So anyway if you want to know "what" i'm doing you could keep an eye
> there. No promises about crazy stuff written there (kidding :P).
>
>
> 2015-09-03 10:47 GMT+02:00 Boudewijn Rempt <boud at valdyas.org>:
>
>>
>> On Sun, 30 Aug 2015, Stefano Bonicatti wrote:
>>
>> So in the end, as i said, back to the drawing board, listing all the
>>> classes involved, what they are supposed
>>> to do and have to do, drawing the interactions and unravel them since
>>> there are a lot of things that have to be
>>> streamlined and should have a somewhat fixed order of execution
>>> (especially needed with GUI interaction).
>>> I think that the bigger refactoring cannot be avoided.
>>>
>>
>> I do agree with that... The thing is, a preset is two things at the
>> moments: it's a loadable,
>> savable, editable aggregate of brush settings, but it's _also_ the
>> current state of the active
>> brush engine. And that gets changed through all the controls the user has
>> over current opacity,
>> current brush size and so on.
>>
>> Then there is the widget/data model confusion. We have this all over
>> Calligra, actually, where
>> around 2006 we decided to to couple the gui for a plugin with its data
>> model. You find that in tools, in filters, in brush engines.
>>
>>
>> Boudewijn
>> _______________________________________________
>> Krita mailing list
>> kimageshop at kde.org
>> https://mail.kde.org/mailman/listinfo/kimageshop
>>
>
>
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20150904/9f8a5841/attachment-0001.html>