--===============8913512230816027771== Content-Type: multipart/alternative; boundary=089e0158c73e39edd2051ee8e5bf --089e0158c73e39edd2051ee8e5bf Content-Type: text/plain; charset=UTF-8 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 : > 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 > 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 : >> >>> >>> 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@kde.org >>> https://mail.kde.org/mailman/listinfo/kimageshop >>> >> >> >> _______________________________________________ >> Krita mailing list >> kimageshop@kde.org >> https://mail.kde.org/mailman/listinfo/kimageshop >> >> > > > -- > Dmitry Kazakov > > _______________________________________________ > Krita mailing list > kimageshop@kde.org > https://mail.kde.org/mailman/listinfo/kimageshop > > --089e0158c73e39edd2051ee8e5bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Dmitry.
My main issue here is that while i can thi= nk of things all these widgets should do/be able to do, i don't know al= l of them, also i can't figure, without an analysis, what need to acces= s a preset/do something with preset data.
So i currently started = from the KisPaintOpBox because it is the one that basically controls all th= e others (directly or indirectly) and is the one that actually sets the pre= set in the resource provider.
Moreover again this is to have a li= st 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 unfortunate= ly not having the whole figure now, i'm sure i'm not able to do som= ething that will cover all the functionality needed.

2015-09-04 8:58 GMT+02:00 D= mitry Kazakov <dimula73@gmail.com>:
Hi, Stefano!

Yeah, the code in the PaintOpBox is rather messy. And yes, we use widge= ts as a data model for paintop presets. That is not too nice, and I also ha= d 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 KisPaintop= Box, but just started from a blank page:

1) Cut off external i= nterfaces and define them strictly. E.g. though "widgets as a data mod= el" 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 reu= se, 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, St= efano Bonicatti <smjert@gmail.com> wrote:
Ah, i get why there's this coupling the= n.
I also realized some things like, preset settings that store a refer= ence 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 ->=C2=A0https://notes.kde.o= rg/p/preset-widget-refactoring to make an "analysis" of all t= he classes (and especially parts of them involved with presets), noting dow= n 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 ve= ry late..
I've found that i cannot remember things day by day= otherwise (since i started working :P), was used to keep everything into m= y mind eheh.

So anyway if you want to know "w= hat" i'm doing you could keep an eye there. No promises about craz= y stuff written there (kidding :P).


2015-09-03 10:47 GMT= +02:00 Boudewijn Rempt <boud@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 classe= s 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 curr= ent state of the active
brush engine. And that gets changed through all the controls the user has o= ver current opacity,
current brush size and so on.

Then there is the widget/data model confusion. We have this all over Callig= ra, actually, where
around 2006 we decided to to couple the gui for a plugin with its data mode= l. You find that in tools, in filters, in brush engines.


Boudewijn
_______________________________________________
Krita mailing list
kimageshop@kde.org<= /a>
https://mail.kde.org/mailman/listinfo/kimageshop=


_______________________________________________
Krita mailing list
kimageshop@kde.org<= /a>
https://mail.kde.org/mailman/listinfo/kimageshop=




--
Dmitry Kazakov

_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop=


--089e0158c73e39edd2051ee8e5bf-- --===============8913512230816027771== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KS3JpdGEgbWFp bGluZyBsaXN0CmtpbWFnZXNob3BAa2RlLm9yZwpodHRwczovL21haWwua2RlLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2tpbWFnZXNob3AK --===============8913512230816027771==--