<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 5, 2015 at 11:07 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I get what are you both saying but KisAcyclicSignalConnector, from what i can see, is done to connect to base Qt signals, while i was more thinking of using custom signals (as it is doing right now), which can send pointers through signal. So if i have to use that i need to extend it. <div><div><br></div><div>Then though, boud: are you basically suggesting to rethink the whole resource management?</div></div><div>Because i know the interaction requirements for the widgets and presets (and well also the tag should be easy), but i don't know how all the rest is done.</div><div>You might have to expand a bit what's your idea because for instance "<span style="font-size:12.8000001907349px">ranging from us having to load all resources on startup to present them in the selector widgets (which takes lots of memory)</span><span style="font-size:12.8000001907349px"> ", do you mean that you think about a widget that just shows name and icons for the preset but it actually loads each preset on the fly when they are selected and then they are kept in memory, forever or unloaded again when some number of loaded preset is reached?<br></span></div><div><span style="font-size:12.8000001907349px">So like a "pool" but with fixed size.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">i find it a bit difficult doing it just "on paper" without knowing all the requirements and without seeing what the current code does, so that i know, when i tear everything apart, what functionality i need to restore, plus all the widgets that needs specific interaction/notices (as in KisPaintOpBox).</span><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">And about the central class, KisCanvasResourceProvider, yes it's central but it's not exactly what i had in mind (well nothing says that the way i was thinking is the way to go, but want to explain where i see a difference from what i was saying and what you both said): the provider right now is pretty dumb, more than a manager that decides things, is just something that does what other tell it to do.</span></div><div><span style="font-size:12.8000001907349px">It just stores resources and then emit the canvasResourceChanged signal to inform others that something has changed.</span></div><div><span style="font-size:12.8000001907349px">Currently it's KisPaintOpBox that actually behaves like the class i was thinking about (its setCurrentPaintOp does a lot of work and "decisions"), except that it's a widget which imho shouldn't do all that work.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">So i'm not obviously saying that KisCanvasResourceProvider has to be reworked, especially since it's used by several other classes, but we need to move the logic from the widgets and especially from KisPaintOpBox in another class, then yes the provider can be the reference for that class, for the current paintop preset instead of having a personal management of that.</span></div></div>
</blockquote></div><br></div><div class="gmail_extra">The requirements are evolving all the time. Originally the preset could not be selected at all and would just write the setting in the brush setting. Then presets could be selected. Then we added another docker, another strip, favorite presets and resource bundle manager and tagging system. There are some widgets that have to be synced and some that don't.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In any case you will at some place have some code that has to prevent cyclic updates just due to the way Qt handles table views. At some point you have decided on a case by case base if a certain widget is synced to the globally selected preset e.g. if you have some sort manager where you don't want. </div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-size:12.8000001907349px">KisCanvasResourceProvider is the class that in the central managing the resources so the preset should be coordinated there, maybe make a sub manager class there. </span><span style="font-size:12.8000001907349px">I would keep the KoResourceItemChooser as it is.</span></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>