<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 5, 2015 at 12:07 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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></blockquote><div><br></div><div>Well, I have nothing against extending it :) Though, yes, i twould be better to keep the class as general as possible.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></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.8px">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.8px"> ", 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.8px">So like a "pool" but with fixed size.</span></div></div></blockquote><div><br></div><div>I think we don't need to limit loaded resources. If loaded, it can be kept in memory forever. We just need to avoid loading everything at once on start. Right now, all the loaded resources take about 100MiB right on start of Krita, even when no image is open.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px"></span></div><div><span style="font-size:12.8px">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.8px"><br></span></div></div></blockquote><div><br></div><div>How about collecting all the requirements in one place? I have just created a page on the wiki [0], let's use it for all the requirements we could think of. <br><br></div><div>There is also a page that Ilya Portnov from the Russian Community created with the wishes for the presets infrastructure [1].<br></div><div><br>[0] - <a href="https://community.kde.org/Krita/docs/Requirements_For_The_Resource_Management">https://community.kde.org/Krita/docs/Requirements_For_The_Resource_Management</a><br>[1] - <a href="https://community.kde.org/Krita/docs/Krita_Presets_Wishes">https://community.kde.org/Krita/docs/Krita_Presets_Wishes</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px"></span></div><div><span style="font-size:12.8px">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></blockquote><div><br></div><div>Yes, I'm totally agree with you. And what is more, KisCanvasResourceProvider resulted in being just a convenience wrapper around KoResourceManager, resulting in two different ways of accessing resources, which is a bit ugly :(<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="font-size:12.8px">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.8px">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></blockquote><div><br></div><div>Agree.<br></div><div> </div><br></div>-- <br><div>Dmitry Kazakov</div>
</div></div>