[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] 

Configure | About | News | Add a list | Sponsored by KoreLogic