# Improving Krita's Existing UX **URL:** \ **Category:** Artists Feedback & Testing\ **Created:** [November 9, 2022, 7:30pm UTC](https://krita-artists.org/t/improving-kritas-existing-ux/51381 "2022-11-09T19:30:37Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Kapyia](https://krita-artists.org/user_avatar/krita-artists.org/kapyia/32/2687_2.png) [@Kapyia](https://krita-artists.org/u/Kapyia)\ **Post date:** [November 9, 2022, 7:30pm UTC](https://krita-artists.org/t/improving-kritas-existing-ux/51381/1 "2022-11-09T19:30:37Z")
# Introduction This is a wishlist of UX improvements that I’d like to see implemented. These are UX “papercuts” I’ve come over time while using Krita as well as while browsing this community site. So to be clear: This is _NOT_ meant to be about bugs that are in need of patching or improving performance where Krita is slow. This is _NOT_ meant to be about huge overhauls or shiny new features that I’m missing from other software. This is a matter of touching up and solidifying Krita’s _existing_ UX and improving new users’ first impressions. It needs to be said that I don’t use every feature of Krita in my workflow and my workflow doesn’t encompass everything that Krita has to offer. I’ve tried asking other artists who use Krita that I know personally and added their suggestions to my list if I hadn’t already. It is also possible that I might have overlooked something or that something on my list has actually been fixed over the time of me adding to it. Additionally, I’m not overly familiar with the inner workings of Krita and don’t know how big or small these requests might actually be considered. I’m also well aware that manpower is a limited resource and I have full respect that sporadic UX polish can’t always be given priority. # The List ## Miscellaneous ### Canvas Input Settings on a per-tool basis - When using the _Photoshop Compatible_ configurations the _Activate Line Tool_ canvas input is set to ‘Shift + Left Button’. The problem here is that it clashes with a lot of other shortcuts. For example, the “Shift-mouseclick” shortcut to end a line specified by the polygon/-line tools, and the shortcut to make selections additive. I generally try to avoid requesting more configurability since it tends to add a bunch of complexity, but i believe there is a need to be able to control which tools these kinds of invocations does/doesn’t apply to. - Side note: Canvas Input Settings seem to be in need of polish in general. For example it’s not always clear what an input will do or affect once invoked. This issue is worsened by the fact that the documentation page for Canvas Inputs is barebones for something that’s arguably key to using Krita effectively. - Disclaimer: I am aware that the Canvas Input system is a bit of a beast within the code (perhaps another indicator that some refinement is needed). This is not a small request even on a surface level but probably even large once you take this fact into consideration. ### Unify color/source sampling for Clone brushes - Right now the way you choose a new source with Clone brushes is (from what I can tell) hard coded to be Ctrl + Left click. This works for Krita’s default shortcuts where the Color Sampler Tool is quickly accessed with the Ctrl key. But if you change that canvas input setting things get confusing. I would make sense for Clone brushes to treat their source as their colour and in turn use the same shortcut as invoking the Color Sampler. ### “Restore Defaults” button for Onion Skins - A friend who works with animation in Krita has brought up that he misses a way to quickly restore the vertical sliders in the _Onion Skins_ docker to their original values. A ‘Restore Defaults’ button would be helpful here as it gets tedious to ### Horizontal Mode for the Brush Presets Docker ![Brush Preset Docker](https://krita-artists.org/uploads/default/original/3X/3/1/3180bcae247b950e5fe6e30baffb196f72b37b19.png) - If you make the Brush Presets docker very short but wide it becomes difficult to scroll through with a tablet pen as the scroll bar. It would be useful if the docker at certain dimensions could switch scrolling direction from scrolling vertically to horizontally. That way you could have your Brush Presets docker horizontally along the top or bottom of the screen while also being able to scroll through the preset list with precision. - A bonus to this horizontal layout would be if the buttons and dropdowns around the list widget would rearrange to be on a single row above the list ### Missing features for working with wider colour ranges - I’ve been told by a friend that the _Specific Color Selector_ is currently lacking some capabilities to work with colours of higher bit-depths. When the 16-bit and 32-bit floating point modes are used the docker only allows the user to work with a granularity of 1% which is even less precision than the 8-bit mode allows for. - The same friend misses being able to adjust candela-per-square-meter (cd/m²) in other colour selectors than the _Small Colour Selector_ docker when working with HDR colour (missing it from the _Specific Color Selector_ to be specific). - There’s also a request to be able to adjust cd/m² even on non-HDR monitors. One suggestion would be to have a checkbox in the _Color Management_ settings to enable HDR settings even if no HDR display is being detected. Brighter-than-white colours can still be useful even if a display cannot directly output them. For example: when the layer blend mode is set to _Multiply_, colours brighter than white can be used to lighten layers underneath or blend across brightening and darkening on the same _Multiply_ layer. ### Tools Menu Redundancy ![Plugins Menu](https://krita-artists.org/uploads/default/original/3X/0/d/0d502a189971630ee744f7c02ee5564f0757cd76.png) - The _Tools_ menu on Krita’s main menu bar only has one entry: _Scripts_. It seems to me it would be better to turn the _Tools_ menu into _Plugins_ (or _Scripts_) instead and skip an unnecessary menuing step. Furthermore there’s an argument to be made about confusing the _Tools menu_ and the _Tools Docker_. - By having a _Plugins_ menu you could also extract the _Python Plugins_ section from Krita’s configuration dialog and make it into its own dialog. This would then be accessed from the top of the _Plugins_ menu as _Manage Python plugins…_. - This raises a question if plugin dockers would be placed under this new _Plugins_ tab or remain under the regular docker menu. There’s valid arguments for both in my opinion and perhaps a matter of personal preference. My suggestion would be to have _Scripts_ and _Dockers_ submenus under this _Plugins_ menu so it is clear they aren’t entirely native to Krita and managed as python plugins. ### Improving Subwindows ![Views Menu](https://krita-artists.org/uploads/default/original/3X/6/5/65e6f315eedfa1a796f8046846fcc74ec275d5f9.png) - One thing that would enhance the experience of using subwindows/views is thumbnails for each view in the _Window_ menu. Useful in cases where two documents have a similar name or you have multiple views of the same document for soft-proofing purposes. It would also hopefully reduce the need for including the entire file path in the menu entry. ![Pin Subwindow](https://krita-artists.org/uploads/default/original/3X/2/3/23d74e9acd22a05ce8c8b6250b57e4c26b76de49.png) - A ‘Pin’ (📌) icon on the title bar of subwindows would be useful to make the option to have them stay on top more discoverable. Hopefully this is within the possibilities of the default Qt subwindow system. ### Docker Menu Categories ![Docker Categories Merged](https://krita-artists.org/uploads/default/original/3X/e/6/e61b4c138fd1af9af79366fb901c294f8b325083.png) - The _Dockers_ menu is getting pretty lengthy and I believe it’s time to start organizing it into categories based on the kinds of utility or workflow they are intended to facilitate. My suggestions would be _Animation_, _Color Pickers_, _Document_(Layers, Comics Manager, Undo History…), _Layout_ (Overview, Grids and Guides, Compositions…) and _Resources_ (Brush Presets, LUTs, Gamut Masks…). There could be a _Basic_ category for dockers like the _Toolbox_, _Tool Options_ and the _Touch Docker_, but I believe they might benefit from remaining _above_ the categories in the dockers menu. - As an addition to the point above regarding plugin dockers: One idea would be to have a _Plugins_ category that third-party dockers would default to. I also think it would be beneficial if entries for dockers that are python plugins were decorated with the python logo as an icon. It would signal to users that they can be managed as python plugins. ### Improving Krita’s Configurable Toolbars ![Toolbars](https://krita-artists.org/uploads/default/original/3X/5/6/56eff9f0f01abee8ccdc4431c543414a18822224.png) - Krita has fully configurable toolbars but the feature is suffering from a bit of neglect. First off, users can’t easily create additional toolbars to add to the list of existing ones. That is to say, there aren’t any toolbar resource files that can be imported and/or exported. - The toolbar configuration dialog could do with some love as well: - The names of the toolbars in the configuration dialog lists them with weird internal names as opposed to the names they have in the _Toolbars Shown_ menu. - Reconsider the use of icons as it makes for an inconsistency between list entries (and affects entry spacing). - The _Current actions_ list doesn’t really warrant a search filter. - Organize the actions into categories similar to the list of properties in the brush preset editor. - Clean up the list of available actions. You could afford to blacklist entries like _About KDE_, _Themes_, and probably _Switch Application Language…_ as these are unlikely to be actions a user wants quick access to. Other actions like _Smooth_ or _Adjust_ are in need of a renaming or a description, but putting them in relevant categories would help as well. And as a final little addition, please capitalize the _—separator—_ entry, or rename it into just _Separator_. - The arrow buttons to move actions around are charmingly old school but it might be worth considering replacing these with instructions to drag and drop the actions instead. In this case you would probably want a clickable ‘X’ on the right end of each action currently in the selected toolbar, in order to remove them. ## The Toolbox ### Dynamic Brush Tool and Brush Smoothing ![Brush Smoothing](https://krita-artists.org/uploads/default/original/3X/9/3/932577ae137e31da420be9aac2e96507a0ed3cd7.png) - Turn the _Dynamic Brush Tool_ into a smoothing mode for the regular _Freehand Brush Tool_. I can’t see any reason for there to be a separate brush tool when the only apparent difference is that the former offers an additional mode of brush smoothing. - I also want to suggest extending the brush smoothing feature by offering preset levels of strength for brush smoothing. Not only is this helpful to artists who are just starting to use the feature and are still figuring out what’s comfortable to them, but it also serves as a way of resetting the smoothing settings to a default/working state. The options for the _Dynamic Brush Tool_ in particular are fully open to be set to a virtually unusable configuration with no obvious way for a user to reset them. It’s also helpful to users who are transferring from other software that only does brush smoothing strength this way. - I’ve also seen users suggest to let brush presets have their own respective smoothing settings. The most obvious use case would be when artists want plenty of smoothing while inking a sketch, but little-to-no smoothing when adding colours underneath the inked drawing. I support this suggestion but would argue that streamlining the brush smoothing feature should come before hooking it up to more parts of Krita. ### Polyline Tool and Polygon Tool ![Polyline](https://krita-artists.org/uploads/default/original/3X/8/3/83faecb6aba28efa2ce2dbdddcf339ef7d4a56c5.png) - I believe a simple checkbox in the tool options to toggle _Connect ends automatically_ should suffice. An additional option would be to give the tool a right-click menu with an entry for _End line and connect ends_. And a big plus would be to add a Canvas Input shortcut like “Ctrl + Shift + Left Mouse Button: Ends the line and connects the ends”. ### Similar Colour Selection Tool and Contiguous Selection Tool - Like to the point above, its case where two tools are identical except for one minor difference in functionality. They both serve the purpose to select pixels of similar colours with the difference being that one tool only creates a contiguous selection while the other is free to select from the entire canvas area. Much like the _Polyline Tool_ and _Polygon Tool_ this difference should be possible to handle with a single checkbox in the _Tool Options_ docker. ### Shape Brush Engine and Freehand Path Tool - While not entirely similar in purpose there is an argument to be made about the _Freehand Path_ tool being able to fill the same role as the _Shape_ brush engine. It’s currently teetering on the border of redundancy with the only real caveat being that it’s not immediately obvious that the _Freehand Path_ tool can be used this way. Even so I’d like to propose extending the _Freehand Path_ tool with the features of the _Shape_ engine (while working on raster layers) and take its place. ## Text Tool Disclaimer: I’m aware of Wolthera’s work on Krita’s text handling capabilities (hugely appreciated!). I’m also aware that there is high demand for on-canvas text editing that will have to come sometime after Wolthera’s work is finalized. I fully respect that a pretty major rework of the Text Tool is going to take its time. But since we don’t have any good timeframe for this rework it would be greatly appreciated if some of the current problems could be remedied in the meantime. ### Don’t preview the look of text in the text field of the Edit Text window. - This causes problems if the text colour is set to one similar to that of the UI background, or if the size is set to a very large or small size. The text you’re editing becomes hard to read, and text size or automatic line breaks aren’t 1:1 with the text on the canvas. The text editor only needs a plain text field using the same text as the UI. Leave the richness for the actual canvas. - This would be further helped with a ‘Preview’ checkbox similar to what exists in Filters and Layer Styles. ### Fit text inside borders - Sometimes you have a shape in an image like a text box or a speech bubble that you want to fit text inside of. In these cases it would be very helpful if you could draw a text field that doesn’t change size to fit the text. ### Don’t automatically switch to the Select Shapes Tool after finishing editing text - I’m not sure why Krita would do something like this. I think it’s a weird assumption that a user always wants to move their text around every time they’re done editing it. Maybe the user is editing a comic page, correcting spelling mistakes or grammatical errors, changing text colour for better readability, changing font sizes, etc. - One idea would be to utilize Canvas Input shortcuts to allow the user to quickly access the Select Shapes Tool if the user so desires. ### Use the Tool Options docker to edit text properties - It would be handy to be able to click on a text object and quickly adjust its properties via the fields in the Tool Options docker. ## Brush Preset Editor Disclaimer: Once again a part of Krita that I know is being heavily reworked under the hood (Lager back-end by Dmitry. Again, many thanks!). Consider these suggestions as being intended for _after_ that work has been finalized. ### Inconsistent spacing ![Brush Editor](https://krita-artists.org/uploads/default/original/3X/8/9/894d95e4113f9906f354c2760874d79dfd06bcc0.png) ![Brush Editor Comparson](https://krita-artists.org/uploads/default/original/3X/d/1/d13dd5e67cabd2ce68a051e9b29919e057792372.png) - The _Brush Preset Editor_ has several inconsistencies in the spacings/margins of the UI. Not only does it make for a less polished look but this also means there’s space that could be better utilized or just saved. For example: open the Editor and select any brush from the Pixel Engine. Select the _Spacing_ option in the list of properties. - Notice how the two checkboxes up top, the _Endable Pen Settings_ checkbox, and the list of options for pen pressure don’t align vertically along the left side. - The ends of the _Strength_ slider-spinbox, the Y-axis spinbox for the pressure curve, and the _Curves calculation mode_ dropdown menu don’t align along the right side. - The brush presets list, the brush properties section, and the scratchpad, don’t align horizontally along the top. - The bottom row of brush settings (_Eraser switch size_, _Eraser switch opacity_, etc.) don’t align vertically with the list of brush properties along the left. - And so on… - Other notable UI inconsistencies includes: - Some slider-spinboxes have their title inside the widget, others have them outside. A good example are the two slider-spinbox at the top when you edit the _Sharpness_ property. - The _Fade_ sliders in the _Brush tip_ property has a random title and frame that the other properties don’t. - The UI for the _Opacity_ and _Flow_ properties are virtually identical but switching between them you notice some odd shifting around and resizing. - Generated brush tips are displayed on top of a (non-functioning) button instead of a widget like the stroke preview. Why? - Some brush presets properties have unique settings (Like _Scatter_ having checkboxes for _Scatter amount_) at the top of the layout. I feel like they’re better suited to place in the empty space below the settings curve to avoid the UI shifting around when going through different brush properties. ### Disable (or hide) options that don’t apply to the current brush ![Disabled Brush Settings](https://krita-artists.org/uploads/default/original/3X/e/b/ebf16ae63884e86022db59d2258460d05457ff67.png) - If the setting isn’t applicable it may as well be disabled to clearly indicate that it doesn’t apply. To address why a setting isn’t available you would probably want a label of some kind telling the user what’s blocking it. Additionally, you could set the tooltip of that setting to be the same text as the label. - Examples that I’ve been able to find: - _Flow_ when using _Build-up_ Painting Mode - _Softness_ pressure settings when not using a _Default_ or _Soft_ generated tip (alternatively, enable it for the other types of brush tips) - _Strength_ when _Pattern_ is unchecked. ### Unify Fade/Softness in the Brush Settings - Generated square brush tips in _Soft_ or _Gaussian_ mode are always extremely soft, especially in _Soft_ mode. - The softness curve for square tips in _Soft_ mode is broken. The generated tip just disappears when the value towards the right is increased. Not at all consistent with how the same curve works for circular tips. ### ‘Spikes’ setting for automatically generated _Square_ brushes is broken - Default mode: Doesn’t work at all for any numbers beside 2 and 4. I think there might be a mistake with the generated tip always being mirrored. The top and bottom are also clipped if there are more than 4 spikes and the ratio is 0,30 or higher. - Soft mode: Currently difficult to analyze because the generated tip is always overly soft. - Gaussian mode: Works fine except for a 3 spiked shape where corners never meet. ### Polygon Brush Tip ![Polygon Brushes](https://krita-artists.org/uploads/default/original/3X/6/d/6d784bb8df49d98769f73a13d48b2a764f88bee9.png) - Semi-related to the problematic spike parameter for generated brush tips. I’d like to ask the developers what their thoughts are on having a type of brush tip that generates a polygon with a variable number of vertices. This would be an alternative to how the current square tips tries to emulate polygons through rotating, duplicating, and mirroring. - This could potentially be used to do away with choosing between a _Circle_ and _Square_ brush tip altogether. The user would instead use a slider with a range from e.g. 3-13 to choose the number of vertices/sides for their brush tip. Setting the slider to 13 would change the shown value to _Circle_ and generate a perfect circle the way Krita currently does. I don’t know if this would cause any conflicts with the different mask types though. ### Text Brush Tips - Not actually an issue, I’m just hard pressed to find any actual use cases for this and would like to challenge its existence. Is there actually any widespread use of it today or is it a relic of Kritas past where the text tool wasn’t as usable as it is today? - The only case I can imagine this being truly useful is if someone finds a specific glyph from a niche font that they want to use as a brush tip. I feel like this could be facilitated as an import option (“Import from font…”) rather than a separate tab in the brush editor. ### Weirdly placed buttons ![Rename Brush](https://krita-artists.org/uploads/default/original/3X/0/4/0465f83c0d849b6734147822a51b4e9effdf4e26.png) - The “Rename the brush preset”-button isn’t locked in place in the UI but instead centered between the brush preset name and the _Save New Brush Preset…_ button. I can understand wanting to facilitate a longer brush preset name but then I’d suggest placing it to the left of the brush preset name instead. - I’m willing to argue that the “Reload the brush preset”-button doesn’t belong to the right of the brush engine name. It’s much better to pair with the two buttons on the right as they also pertain to the values of the preset. Furthermore, I suggest adding a warning dialog for when the user clicks the button with unsaved changes (note: only the button in the brush editor). This would help avoid some unfortunate misclicks while editing a brush. ### Click Icon to Edit ![Edit Icon](https://krita-artists.org/uploads/default/original/3X/5/8/58bcae6a8e9f248eb44ea2d96f0866e62016477a.png) - It’s not very clear that you can edit a brush presets icon by opening the .kpp file in Krita. Clicking the brush preset icon in the top left should allow you to open the icon of the current brush preset as a document. Trying to edit the icon of an unsaved preset should probably open a dialog that tells the user they need to save the current preset before editing the icon and give them the options to _Save New Brush Preset_, _Overwrite Brush Preset_, or _Cancel_. ### Remove the Scratchpad - Over time Krita has made the scratchpad in the _Brush Preset Editor_ less and less useful. Firstly, editing the icons by opening the .kpp file in Krita has (as far as I know) always been the most useful option to make a good icon. Second, the _Save a New Brush Preset_ dialog has been extended with various ways for users to make a quick and effective preset icon. And with a recent update it was made possible to detach the brush window from the toolbar and make it a separate dialog. This lets you test your new brush directly on the canvas and how it feels to paint with directly on an image, as opposed to painting on perfect white. This means that there’s already better ways to make an icon, and there’s a better way to test the feel of your custom brush. That’s why I would like to suggest that the scratchpad in the brush editor should be removed entirely. - (Implied here is that I would like Krita to commit to making the _full_ brush editor into a separate dialog.) # Finishing Words This is what I’ve got for now. Thank you to everyone who makes Krita and this community possible, and kudos to those who get through the entirety of this almost 4000 words long post. If you have something you’d like to add to this list I’m open to listen to other people’s suggestions. I might repost this list in the future with changes and additions depending on what the future holds for us. Just try to remember: the idea is not to suggest explicitly new features, but rather to look at what Krita already offers and think “how can this be done in an easier and/or clearer way?”. In the words of Antoine de Saint-Exupery: > _A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away._ As always, consider visiting [https://fund.krita.org/](https://fund.krita.org/) and putting a few dollars towards the continued development of a first-class digital painting software for everyone ❤ ---
**Author:** ![sooz](https://krita-artists.org/user_avatar/krita-artists.org/sooz/32/93244_2.png) [@sooz](https://krita-artists.org/u/sooz)\ **Post date:** [November 9, 2022, 8:54pm UTC](https://krita-artists.org/t/improving-kritas-existing-ux/51381/2 "2022-11-09T20:54:12Z")
> [@Kapyia](#): > > I might repost this list in the future You’ve put a lot of time and effort into this post. It would be a shame if your points didn’t get the consideration they deserve. Instead of thinking about reposting a wishlist, please consider making posts that deal with one single issue or idea. This allows the community and the devs to match your thoughtful insights with comments of their own. ---
**Author:** ![wolthera](https://krita-artists.org/user_avatar/krita-artists.org/wolthera/32/236085_2.png) [@wolthera](https://krita-artists.org/u/wolthera)\ **Post date:** [November 9, 2022, 9:06pm UTC](https://krita-artists.org/t/improving-kritas-existing-ux/51381/3 "2022-11-09T21:06:02Z")
I can’t give coherent feedback to all elements, but for the two topics that are my specialty: 1. The text tool. All of the stuff you want requires my text work 😃 2. HDR colorpicker stuff: this is something we want to do, but the core problem is that all the color pickers would need to be ported to opengl first, and we’re not sure how exactly we want to do that because that interrelates with the qt 6 port that we’re not sure when we want to do that. ---
**Author:** ![TheTwo](https://krita-artists.org/user_avatar/krita-artists.org/thetwo/32/32836_2.png) [@TheTwo](https://krita-artists.org/u/TheTwo)\ **Post date:** [November 9, 2022, 10:11pm UTC](https://krita-artists.org/t/improving-kritas-existing-ux/51381/4 "2022-11-09T22:11:31Z")
> [@Kapyia](#): > > ### Polyline Tool and Polygon Tool To be honest, I think these two tools can be deleted completely. Bezier curves can completely replace them, can’t it? ---
**Author:** ![Kapyia](https://krita-artists.org/user_avatar/krita-artists.org/kapyia/32/2687_2.png) [@Kapyia](https://krita-artists.org/u/Kapyia)\ **Post date:** [November 9, 2022, 11:25pm UTC](https://krita-artists.org/t/improving-kritas-existing-ux/51381/5 "2022-11-09T23:25:03Z")
This is an interesting point. You’re definitely not wrong, but there’s also some real weight to the tool differences here. The _Polyline Tool_ is assures completely straight lines (useful when outlining inorganic shapes) whereas the _Bezier Curve Tool_ let’s you draw curved paths. When using less precise inputs like pen or touch it’s really easy to accidentally give the lines produced by the _Bezier Curve Tool_ slight curvature even with a quick tap with a pen. You could condense it down to another checkbox in the tool options for “Draw curved paths”, but because there’s a notable difference it’s more difficult to tell if this will have a negative impact on the UX or not. Some people have also requested being able to toggle between freehand and polygonal selection on the fly with a shortcut. I know why this is desirable but I would be hesitant to merge the two different tools into one without a good plan for how to communicate to a user how to effectively switch between the two modes. ---
**Author:** ![raghukamath](https://krita-artists.org/user_avatar/krita-artists.org/raghukamath/32/59144_2.png) [@raghukamath](https://krita-artists.org/u/raghukamath)\ **Post date:** [November 10, 2022, 3:08pm UTC](https://krita-artists.org/t/improving-kritas-existing-ux/51381/6 "2022-11-10T15:08:27Z")
> [@Kapyia](#): > > The _Dockers_ menu is getting pretty lengthy and I believe it’s time to start organizing it into categories based on the kinds of utility or workflow they are intended to facilitate. My suggestions would be _Animation_, _Color Pickers_, _Document_(Layers, Comics Manager, Undo History…), _Layout_ (Overview, Grids and Guides, Compositions…) and _Resources_ (Brush Presets, LUTs, Gamut Masks…). There could be a _Basic_ category for dockers like the _Toolbox_, _Tool Options_ and the _Touch Docker_, but I believe they might benefit from remaining _above_ the categories in the dockers menu. This is a good suggestion, I would suggest moving the docker menu into the window main menu as it pertains to the window or interface. > [@Kapyia](#): > > The Toolbox There is another feedback and suggestion thread by @kaichi1342 about consolidating toolbox items here > [@Some observation of the Toolbar, \[Rethinking, Consolidating, Rearranging Tools for better discoverability\]](https://krita-artists.org/t/some-observation-of-the-toolbar-rethinking-consolidating-rearranging-tools-for-better-discoverability/50552): > > Preface: Yesterday while I was doing my write up for feature request of Angle Snapping being extended to other tools I realize some tools seems redundant or an alternate function of the other, and some can be help its discoverability by putting it as an alternate mode of another tool. This is not UI redesign Feedback, but more of usage feedback [not really a feature request]; 1. Make Dynamic Brush Tool as a mode of Brush Tool Reasoning: Why move it to be under Brush tool? Current Dynam… ---
**Author:** ![Michelist](https://krita-artists.org/user_avatar/krita-artists.org/michelist/32/65826_2.png) [@Michelist](https://krita-artists.org/u/Michelist)\ **Post date:** [November 10, 2022, 3:45pm UTC](https://krita-artists.org/t/improving-kritas-existing-ux/51381/7 "2022-11-10T15:45:44Z")
> [@raghukamath](#): > > I would suggest moving the docker menu into the window main menu as it pertains to the window or interface. There is a plugin from @LunarKreatures / LainFenrir, posted on GitHub, that does exactly this. > **[GitHub - LainFenrir/krita-resource-docker-menus: krita plugin. Adds 2 new...](https://github.com/LainFenrir/krita-resource-docker-menus)** > > krita plugin. Adds 2 new menus to krita for dockers and resources - GitHub - LainFenrir/krita-resource-docker-menus: krita plugin. Adds 2 new menus to krita for dockers and resources Michelist ---
**Author:** ![kaichi1342](https://krita-artists.org/user_avatar/krita-artists.org/kaichi1342/32/8174_2.png) [@kaichi1342](https://krita-artists.org/u/kaichi1342)\ **Post date:** [November 10, 2022, 3:57pm UTC](https://krita-artists.org/t/improving-kritas-existing-ux/51381/8 "2022-11-10T15:57:39Z")
On toolbox items yep, Imade an observation thread about that too. The polygon tips would be nice. Thank you for going over it. I would be happy if you drop by my thread and give your opinion regarding re arranging items in the toolbox itself. 🙂 ---
**Author:** ![SchrodingerCat](https://krita-artists.org/user_avatar/krita-artists.org/schrodingercat/32/137932_2.png) [@SchrodingerCat](https://krita-artists.org/u/SchrodingerCat)\ **Post date:** [November 10, 2022, 9:33pm UTC](https://krita-artists.org/t/improving-kritas-existing-ux/51381/9 "2022-11-10T21:33:08Z")
There are several plugins that enhance Krita’s interface, but I think the idea of this is to have it implemented natively so that users don’t have to rely on third parties to improve their Krita experience.