Refactoring of the brush editor
Stefano Bonicatti
smjert at gmail.com
Mon Jun 1 10:34:18 UTC 2015
Hello, while i was trying to fix a crash in the brush editor, some other
issues arised, so slangkamp that was helping me suggested that a
refactoring was needed to fix all the problems cleanly.
Here is the proposal:
Remove the Stamp and Clipboard tabs (namely KisCustomBrushWidget and
KisClipboardBrushWidget) as tabs and make them openable as dialogs through
two buttons in the Predefined tab (i was thinking on the opposite side of
import and delete resource?).
When the dialog is closed (provided that the user didn't cancel the
operation) a new predefined tip is created.
So this also means removing all the "Use as tip" and "Add to predefined
tips" buttons.
Why:
Both tabs have an ability to create a temporary brush that is automatically
shown in the Predefined tab.
This brush is created the first time when switching to the tab, but after
that, if we delete it from the Predefined tab, it's not created until we
hit "Use as tip" button or switch its Style.
If we don't do one of the action above the brush outline will remain the
same, but it will draw the first tip in the Predefined tab as a fallback.
Clipboard tab has a similar behaviour except that it doesn't have "Use as
tip" button, so the only way to force a new brush is to copy something
again, then it has the same behaviour when not recreating the brush.
Another oddity this generates is that both tabs has the ability to create a
predefined tip by cloning the temporary brush, this means that after
"playing" a bit with the Stamp and Clipboard tips and then adding for both
a predefined one, the user will find 4 new tips in the Predefined tab.
Moreover when creating a preset with one of these two tabs active, the tip
is not reloaded when the preset is selected, but it works only if in the
Predefined tab, when creating the preset, their tip was selected.
Finally to understand which brush is currently being used is quite
difficult currently, between the internal widget brushes that get shared
through the temporary ones, but then cloned when they are added as
predefined tip. The fact that when doing some actions the brush/tip
selected in the brush chooser is used but sometimes it is used the one that
is returned by the KisBrushSelectionWidget (the parent of all the tabs) and
sometimes by a totally external class that searches through the resource
server.
Given that seeing and being able to delete those temporary brushes is a bit
ugly, the initial idea was to hide those temp brushes by providing a
ProxyModel for the brush chooser (which internally uses a
KoResourceItemChooser), but again slangkamp suggested something cleaner.
So basically all of this should show how "everything" revolves around the
Predefined tab and how beneficial should be to force to have the user add
the tip to the Predefined tab, by using the dialog, if he wants to use that
brush tip, instead of having something "half" automatic that sometimes
fails, in a non very clear way.
For the other two tabs, Auto and Text, there's no issue, they don't need to
create any tip in the Predefined to work.
What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20150601/d4c63ff9/attachment.html>
More information about the kimageshop
mailing list