<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>