Preset widgets refactoring

Stefano Bonicatti smjert at gmail.com
Sun Jul 5 14:57:56 UTC 2015


>
>
> 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. I would keep the KoResourceItemChooser as it is.
>
> Well i will still have to modify it because currently it doesn't give
enough flexibility to be composed with other classes/widgets, as with the
case of the relayout: it chooses not to inform through signals that a new
resource has been selected, so you end up having only a visual selection of
the resource (while having no choice on what it should actually select).

Also the distinction between UI and NonUI call paths it's pretty important
(KoResourceItemChooser::activate can be called due to a call to
setCurrentResource/setCurrentItem, or due to an actual input from the
chooser UI).
In this case while the call paths comes from setCurrentResource, the
activate function shouldn't be called, otherwise classes handling the
resourceSelected signal will think that another resource is selected and
unnecessary work to check if it's a valid selection has to be done.

Modifications on how it deals with slotBeforeResourcesLayoutReset and
slotAfterResourcesLayoutReset() have to be done too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20150705/d8a66c7d/attachment.html>


More information about the kimageshop mailing list