[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: Refactoring of the brush editor
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2015-06-01 12:03:49
Message-ID: alpine.LNX.2.00.1506011402560.14850 () calcifer ! valdyas ! org
[Download RAW message or body]

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


[Attachment #3 (text/plain)]

_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread]