<div class="gmail_quote">On Fri, Jan 15, 2010 at 11:43 PM, <a href="mailto:LukasT.dev@gmail.com">LukasT.dev@gmail.com</a> <span dir="ltr">&lt;<a href="mailto:lukast.dev@gmail.com">lukast.dev@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Monday 30 November 2009 08:10:11 Boudewijn Rempt wrote:<br>
&gt; We had a discussion this Sunday on what to do with the problem that paintop<br>
&gt; settings and their widgets are so very closely tied together. We came to<br>
&gt;  the following redesign (which I&#39;ll also put on the wiki, but I cannot<br>
&gt;  reach that at the moment):<br>
<br>
</div>Is that on the wiki? I could not find it.<br>
<div class="im"><br>
&gt; We had an idea toremove the KisPaintOpSettings class and put the paintop<br>
&gt; options and custom options directly inside the paintop. But I&#39;m not sure<br>
&gt;  how that works if we look at the flow when selecting a preset and starting<br>
&gt;  to paint:<br>
<br>
</div>So we will drop KisPaintOpSettings?<br></blockquote><div><br>I got a bit away from dropping them at the moment. For now the paintIncremental and paintOutline functionality is still in the settings.<br>The erase paintop doesn&#39;t have both and the setting class isn&#39;t much more than a dummy in case some paintOutline gets added.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So far I port the paintop like this<br>
<br>
I have:<br>
<br>
o KisPaintOpOption (e.g. KisSprayShapeOption)<br>
<br>
contains GUI elements usually in UI file  + signals in code,<br>
sometimes some logic like prescaling QImage for the spray paintop according<br>
particle size<br>
<br>
every GUI element is connected to sigSettingChanged() so that the settings are<br>
updated and it also triggers update of the preview of the brush<br>
<br>
if you forget to call the signal, the paintop does not know about the change<br>
in GUI because now paintops does not access widgets but settings<br>
<br>
o KisPaintOpSettings<br>
<br>
contains paintOutlineRect and paintOutline, basiclly it draws the outline of<br>
the brush (paintOutline) and returns the area to be restored on the canvas<br>
from the previous position of the brush outline (paintOutlineRect)<br>
<br>
it used to have also changePaintOpSize method which is called by Shift-drag<br>
on-canvas size changing but that is moved now to KisPaintOpOptionsWidget<br></blockquote><div><br>I moved changePaintOpSize to the widget because it changed the widgets and that way it could be easier to share it between the paintops.<br>
All brush based paintops could use the same option widget and could use the same resize code (still todo)<br><br>For paintOutline that would be possible too so that all brush based paintops would use the same outline drawing code, but that would drag in some dependency at the moment. After your planned QPainterPath refactoring we could look at it again.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Every GUI element value is accessed through code like this<br>
getInt(&quot;Spray/diameter&quot;)<br>
<br>
My paintops have access just to this KisPaintOpSettings object.<br>
<br>
Questions:<br>
1. Paintops will have access to the KisPaintOpOption? What is the design idea?<br></blockquote><div><br>Originally my plan was to remove the remove that access. For practical reasons there is still a dependency for the use in paintOutline and changePaintOpSize, as it&#39;s the best way to access the widgets from the tool. It wouldn&#39;t be needed in paintOutline if it reads the setting, but it turned that it too slow in case you change the paintop size on canvas so it&#39;s still reading from the widget directly. For the properties itself the widgets shouldn&#39;t be used.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Problems:<br>
* It is very frustrating job to port my paintops as I have many options in<br>
GUI. It is easy to make mistake because of the code like<br>
getInt(&quot;Spray/diaemter&quot;) compiles fine, but it has mistake (it suppose to be<br>
diameter). Is there any nice way to fprint the KisPaintOpSettings?<br></blockquote><div><br>I know it&#39;s a bit frustrating with all those settings, but for the presets to work everythings must be serializable.<br>The settings have a method dump() that outputs all properties. To avoid mistakes you can either define some strings and use these instead of hardcoding the strings or write a unittest that check the roundtrip of all properties.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* I wanted to return QImage in the settings object because spray uses<br>
QImage.But there isn&#39;t method getQImage(&quot;Spray/imageBrush&quot;) or something like<br>
this.<br></blockquote><div><br>You can still put the QImage as a member in the sprayop settings. Everythings that isn&#39;t a property won&#39;t be saved automatically, so you have to do the saving code yourself. For a QImage the filename of the source file could be added as property additionally to the QImage.<br>
<br>Another possibility would be to use a pattern from the pattern server instead of QImage. That way you only have to store the id of the pattern and the paintop could fetch it from the server.<br><br>There is also the possibility that the image can&#39;t be loaded from disk when the preset is loaded, because it might be removed or something like that. For that I added a method canPaint() to KisPaintOp that can check if the settings are read correctly and block painting in case e.g. the image is missing.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I looked at the KisBrushOp code and it has access to class KisBrushOption. I<br>
will do that somehow similar, is that ok? PaintOp will have access to Options?<br></blockquote><div><br>It&#39;s ok for use in paintOutline for now. In almost all other cases it shouldn&#39;t be used.<br></div></div>