[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Preset widgets refactoring
From: Stefano Bonicatti <smjert () gmail ! com>
Date: 2015-09-04 9:54:50
Message-ID: CAGMAV48pyLjrEPrBNt66jducX-G7M9Ev33z7GQ-o6vbAYOO-hw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@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@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@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
>
>
[Attachment #5 (text/html)]
<div dir="ltr">Hey Dmitry.<div>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.</div><div>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.</div><div>Moreover again \
this is to have a list of what "actions" are needed and i have to \
support.</div><div><br></div><div>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.</div></div><div \
class="gmail_extra"><br><div class="gmail_quote">2015-09-04 8:58 GMT+02:00 Dmitry \
Kazakov <span dir="ltr"><<a href="mailto:dimula73@gmail.com" \
target="_blank">dimula73@gmail.com</a>></span>:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
dir="ltr"><div><div><div><div><div>Hi, Stefano!<br><br></div>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.<br><br></div>If I were your I would not try to follow the \
order of calls by KisPaintopBox, but just started from a blank page:<br><br></div>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.<br><br></div>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 <a href="http://creately.com" target="_blank">creately.com</a> \
and do UML drafts there.<br><br></div>We can organize a skype session next week if \
you like :)<br><div><div><div><br></div></div></div></div><div \
class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Sep 3, \
2015 at 5:21 PM, Stefano Bonicatti <span dir="ltr"><<a \
href="mailto:smjert@gmail.com" target="_blank">smjert@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div dir="ltr">Ah, i get why there's this coupling \
then.<div>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.</div><div><br></div><div>Anyway i'm \
using an etherpad -> <a href="https://notes.kde.org/p/preset-widget-refactoring" \
target="_blank">https://notes.kde.org/p/preset-widget-refactoring</a> 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.</div><div>Currently it's in his infancy because i did it yesterday \
very late..</div><div>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.</div><div><br></div><div>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).</div><div><br></div></div><div><div><div class="gmail_extra"><br><div \
class="gmail_quote">2015-09-03 10:47 GMT+02:00 Boudewijn Rempt <span dir="ltr"><<a \
href="mailto:boud@valdyas.org" \
target="_blank">boud@valdyas.org</a>></span>:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br> On \
Sun, 30 Aug 2015, Stefano Bonicatti wrote:<br> <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> So in the end, as i said, back to the drawing board, listing \
all the classes involved, what they are supposed<br> to do and have to do, drawing \
the interactions and unravel them since there are a lot of things that have to be<br> \
streamlined and should have a somewhat fixed order of execution (especially needed \
with GUI interaction).<br> I think that the bigger refactoring cannot be avoided.<br>
</blockquote>
<br></span>
I do agree with that... The thing is, a preset is two things at the moments: it's \
a loadable,<br> savable, editable aggregate of brush settings, but it's _also_ \
the current state of the active<br> brush engine. And that gets changed through all \
the controls the user has over current opacity,<br> current brush size and so on.<br>
<br>
Then there is the widget/data model confusion. We have this all over Calligra, \
actually, where<br> 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.<div><div><br> <br>
Boudewijn<br>
_______________________________________________<br>
Krita mailing list<br>
<a href="mailto:kimageshop@kde.org" target="_blank">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" rel="noreferrer" \
target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br> \
</div></div></blockquote></div><br></div> \
</div></div><br>_______________________________________________<br> Krita mailing \
list<br> <a href="mailto:kimageshop@kde.org" \
target="_blank">kimageshop@kde.org</a><br> <a \
href="https://mail.kde.org/mailman/listinfo/kimageshop" rel="noreferrer" \
target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br> \
<br></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font \
color="#888888">-- <br><div>Dmitry Kazakov</div> </font></span></div>
<br>_______________________________________________<br>
Krita mailing list<br>
<a href="mailto:kimageshop@kde.org">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" rel="noreferrer" \
target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br> \
<br></blockquote></div><br></div>
[Attachment #6 (text/plain)]
_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic