Preset widgets refactoring

[Stefano Bonicatti]

Hey Dmitry.
My main issue here is that while i can think of things all these widgets
should do/be able to do, i don't know all of them, also i can't figure,
without an analysis, what need to access a preset/do something with preset
data.
So i currently started from the KisPaintOpBox because it is the one that
basically controls all the others (directly or indirectly) and is the one
that actually sets the preset in the resource provider.
Moreover again this is to have a list of what "actions" are needed and i
have to support.

What you suggest seems to be an even bigger refactor, as in.. really
rethink from the start what each widget should do, but unfortunately not
having the whole figure now, i'm sure i'm not able to do something that
will cover all the functionality needed.

2015-09-04 8:58 GMT+02:00 Dmitry Kazakov <dimula73 at gmail.com>:

> 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
>
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20150904/85192bca/attachment.html>