Refactoring of the brush editor

[Boudewijn Rempt]

On Mon, 1 Jun 2015, Stefano Bonicatti wrote:

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

I don't mind that, but it might be tricky to open a dialog from a popup 
widget.

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

Go ahead, and we'll see whether it works :-)

Boudewijn