For the last couple of weeks I have been developing two new features that improve the Assistant Tool.
Feature 1: Dynamic editor widget.The editor widget was getting crowded with buttons, so I redesigned it to be dynamic. Now, the user has the option to only enable the buttons they want to appear on the editor widget and it changes size to accommodate. This feature involved some minor code re-factoring which now makes it easier for future button additions.
Feature 2: Assistant duplication. The editor widget now has a duplication button. Simply click and drag to copy and position an assistant.
The editor widget also has a nice drag decoration
This is my first open-source contribution and I’m looking for any feedback you might have on this. I aim to make a merge request in the next few days.
That sounds very good and should be well-situated as a work-saver for many.
I would be interested to know if you have discussed this with @tiar in connection with the development research? After all, this is a topic that is on their agenda, and it would be a shame if two developers work on the same tool without knowing about each other and so work is done twice. Besides, you can split work or do it together, depending on the nature of the work:
One suggestion would be to make the drag-able area more inline with other drag-able are used in krita, I think the toolbar had some sort of two vertical lines. I am not sure about this. I am saying this because currently the gray patch is hard to distinguish as hold and drag area. May be tree dots or some form of sign to make user know that that ares is drag area it would also help to make it a bit wider because sometimes it is hard to click and drag in such narrow area.
I really like the duplicate feature really thanks for adding it.
I first thougt of a drag “handle” when i saw the gray area, but maybe if the gray area is on the top border then it resembles kind of a window title bar and is more evident to everybody what it is used for.
I know it is not the purpose of this feature, but it occurred to me that if the little window code can be abstracted from the assistants, maybe it could be reused in other tools, for example to achieve the requested on-canvas selection button bar. I’m saying that because some refactor work seem to be already done,but i know it’s a lot of work.
Thanks for the feedback! The entire background area of the editor widget is actually drag-gable, I added the grey rectangle as a little handle to use in general, especially if the editor widget is full of buttons. I chose a simple grey rectangle because of the dynamic nature of the editor widget. As the widget grows or shrinks complex decorations don’t really look good unless a complex positioning algorithm computes new positions for the decoration details, such as dots.
That’s interesting. I like the right-positioned rectangle because it feels more accessible to me than if it was above the widget, but I’ll have to get user feedback on that. The issue with making the editor widget it’s own class is that it currently doesn’t exist as one. It’s simply drawn from several data variables using QPainter. It don’t know how much of a rework it would take to introduce some kind of Qt based widget but that sounds like a good potential idea for the future. Thanks for the feedback!
like @Deif_Lou said this can be utilised in on cavas option bars like request for selection tools here - This can be used for Selection action bar feature request
Another feature for this integration would be quick action bar while working on canvas only mode. Some people have asked for a quick action docker which users can populate with tool icons and actions they need frequently and that feature can be enhanced by making a on canvas version which could be made to appear on press of a shortcut.
I know I am going on a tangent here sorry for that but I agree with deif lou that this could be utilized in more places.
That feature sounds awesome! I myself am not familiar enough with the Krita code-base to know exactly what to do, but I imagine such a feature could be implemented as its own plug-in. Then each tool instantiates a data class that defines the look and buttons of the editor widget, which gets uses by an editor widget manager to render and manage interaction for the widget. I’m just spit-balling, again I wouldn’t really know what would be involved.
Oh, I’d get so much use out of the copy feature! And I agree with @raghukamath’s suggestion of the drag handle. The dots seem to be somewhat standard for draggable things. (The current implementation has the dots, but doesn’t look like a handle, so that too took me a while to figure out. )
Awesome work I can remember many a times where the clutter of the assistant editor buttons got in the way. Oh this just fired a side tangent in my brain…
Hi @Arc_Mantis, these changes look really good, thanks! I hope you can get it merged, that’s always tricky
As you have worked on assistants code, did you by any chance noticed the behavior I described here?
I’m aware that this is probably a completely different section of the code but asking just in case. If not, then don’t bother looking into it right now. Thanks.
)
I can remember many a times where the clutter of the assistant editor buttons got in the way. Oh this just fired a side tangent in my brain…