yes giving an exact number is not really possible, people come and go, I’m just a volunteer since less than a year, but a few GSoC students already make quite a difference to krita, and the bulk of code currently comes from those full time core developers, although lately there’s been an increase of contributions.
But I doubt anymore would write articles like “The top 30 Blender developers 2016” about krita yet.
https://www.openhub.net/p/krita has some statistics. The contributor peak in 2011, though, was because Krita was part of KOffice back then, Nokia funded a lot of development.
Something similar can be seen in https://github.com/KDE/krita/graphs/contributors, where many of the top contributors were working on KOffice, not Krita directly.
@wojtryb Thanks!
Yes, not at this stage definitely 
.
Oh ok that explains a bit.
Thanks for the info!
Unfortunately, Breeze is a Qt plugin that depends on KDE which in turn depends on Qt, which means it’s not practical to ship it with appimages, and I’m not even sure it can be compiled for other platforms than Linux.
If you mean Breeze depends on Plasma, that’s just not true. There are even already KDE apps that ship Breeze for the Windows versions. I don’t use many AppImages, but I wouldn’t be surprised if Kdenlive used Breeze in its AppImages. Krita is made with Qt, so why is requiring Qt a problem?
Breeze (at least as it comes from the repo) depends on KDE framework libs like KF5Package and KF5I18n, and those in turn depend on Qt5.
If you build Krita with a Qt version that is not your system wide version, and you want the Breeze style plugin, you can’t build it with your system KF5 libs because of the Qt version mismatch, so you end up having to compile and bundle the KF5 libs too…
Seems like KF5 supports Windows too, but basically it adds the same rat-tail of dependencies, and so far nobody had the patience to set this all up…any volunters? 
Before I go on, are you involved in the packaging of Krita’s AppImages and Windows builds? If so, perhaps you should ask Kate, Kdenlive and KDevelop devs about their experience with using Breeze?
I don’t think the problems you describe are real in this context. Krita already uses KF5 and Qt; did you forget (CMakeLists.txt · master · Graphics / Krita · GitLab)?. You don’t need to bundle all of KF5 to use KF5 libraries (it sounds like you’re implying this), which is the whole point of KF5. What you describe sounds like a problem kde-libs would have had if we were still using it.
So use a proper build environment? This is a solved problem.
Is there some kind of miscommunication happening here?
Most digital painting software use dockers and panels for tools. Someone mentioned Krita with Pie Menu like Blender. I think a problem would be that Pie Menus are very good for keyboard and mouse control and not so much for keyboard and tablet. However, if one or few Pie Menus could be used as quick access tool when working in Canvas Mode, it could be very helpful. It will be what the KanvasBuddy add-on is trying to accomplish.
I have a small screen and I generally paint in Canvas Mode. So I have to frequently tab out to access Layers and other dockers. KanvasBuddy helps with some of those issues, but a native tool for a sort of Quick Access Hub would be cool.
I tried making some mockups.
The thread is going on well and is lively for sure. The discussion is interesting. This is a good place for brainstorming and coming up with ideas and checking out how people think of that idea.
I would suggest our members to make separate thread for each idea if it shapes well and is now ready for development. For example if the idea of making dockers collapsible into small icons in the tool bar is good enough and ready for development, then it would good to make a separate post in the develop category to pursue that idea. Similarly if the idea of pie menu is matured enough and is ready then make separate thread for it.
All I am saying is that use this thread to brainstorm and pursue individual ideas and improvement in separate thread so that this thread does not go off tangent become difficult for people to follow it.
Having said that please continue the discussion when in doubt about new thread , we mods and admins are here to help. We will branch the thread into appropriate individual threads 
No I’m not, I’ve just been told that the increase in complexity is hard to justify.
I’d be happy to hear otherwise, but from my observations automated builds take a fair share of attention already, and upgrading all the external (okay KDE is not 3rd party in that sense) libs is not something you do in an afternoon anymore. Even if you don’t run into such fun as finding out a dozen places insist in a specific Python version…
That’s a good idea to do. We would have to figure out which ideas are ready to develop…would that work through a poll, or is it easier to have general consensus in the chat?
I don’t think I’m able to move posts to new threads, so mods would have to help with that.
At the moment, the main ideas I’m seeing are:
Would that be appropriate, or can these be simplified/ added upon?
(I believe the General UI ideas could probably remain as this topic)
Awesome mockups! The effort gone into making these is very appreciated!
My only input would be to consider how this could be paired with the current brush palette menu (the one accessed through Right click of the canvas), there are some similarities with Colour Selector, zoom etc.
It would be good to see if these existing features can be upgraded, unless the upgrade solves a different problem, which might imply a separate feature in that case.
Cheers!
Yes, I was mostly thinking along the lines of replacing and upgrading the Right Click popup into a Pie Menu. And I guess, the right click popup menu was trying to be quick access for canvas only mode because it has buttons to show brush size, opacity etc. when already they are present in the tool bar.
Personally, I use the pop-up menu a lot for color picking and brush selection. Although, not so much for zooming, magnifying or rotating. I have seen some discussions about people not preferring the right click popup for color picking. In regular mode, right click pup-up is already duplicating functions easily accessible from dockers. In Canvas mode, the pop-up menu is not extensive enough to completely rely on.
One downside of replacing the current pop-up menu with pie menu would be that it would increase the amount of clicks for some functions from one click to two. But also, it would add more functionality.
Also, always on top and collapsible dockers could also solve the same problem. But I am partial to pie menus because they look cool. 
It’s interesting how these things coincide… I was discussing something like this pie menu with my father (of all people 
), and he remembered an idea of a pie menu similar to yours; the generic options displayed first, before more specialised options could be accessed with 1-2 more clicks. He emphasised that there should only need to be 3 maximum clicks needed in any interface, to access the option you want.
I searched up ‘Radial Menu’ on Google, and this concept by Howard Moen came up.
In terms of implementation, this would be hard to pull of successfully. But I think the idea of clicking one option to provide second options in the circle, would be quite interesting.
In relation to dockers, I feel they will always remain a part of Krita, and the sheer variety of them allows large customisation to user preferences. But it would still be a nice idea to have the right click menu complement the dockers, instead of duplicate them.
(I never use the right click menu specifically for this reason.)
Edit: @tiar any more info on the .svg icons?
I also made a mockup of @oliver’s idea to have icons horizontally across the Dockers:
Opinions? I think it does allow more room for the canvas, which is good 
.
Cheers
It’s possibly the first time I really begin to like this mockup. Great work! Love the horizontal icons.
How about saving even more space:
About RMB popup: I don’t really like changing the usage so much, making it a huge pie menu that does everything, but needs a lot of movement and clicking. As the popup may need some redesign too (probably a new thread would be needed), I would like it to still be a tool where you can get to most basic things in krita at once - color, brushes, brush settings.
Pie menus for me would be more useful as separate tools, with icons instead of text whenever possible - one pie menu for brushes (the same tag as with right click (where you can select a tag), but without need to click - just press a button and make a slight move with your stylus, and release a button). Another menu for most used tools (freehand, transform, move, select) or types of tools (different for selections, painting tools etc).
For me it makes sense that at RMB you have all the essentials, and with some keyboard inputs you get to separate pie menus. (just like now, though less keyboard inputs would be needed as you have multiple things on one key)
But I love @Anurag_Ekka proposition of color selector in a circle without a gray border. If “show color selector (shift+i)” could look like that circle, with this space for recent colors, it would be truly amazing!
Thanks! I agree with you about the existing RMB popup; there can only be so many additions to a menu before it gets cluttered and confusing.
Icons would work well in pie menus, but definitely would need associated text, perhaps simple words.
Separate menus for brushes (RMB probably) and tools would be great! And upon looking at the Shift + I colour selector, I agree that the border would be better designed.
Here’s a modified docker layout based on your proposal:
Cheers
that is all good and all but you have some restrictions there. Tab can contain Widgets.
However Docker widgets which is those that are there need a header for when they are taken from the UI and become floating. That is why the current Dockers have a name reduncancy. I think a icon tab and name header to be the best option.
So, are you saying the icon should go above the name header? Or is the idea that the icon needs to remain separate from the header?
Cheers
So just yesterday I was working in canvas only mode like I often do and as often I thought: “Wouldn’t it be great if I could keep just the layers docker visible.” And then I remembered this topic and the initially proposed floating semi transparent dockers. I’m normaly not a fan but this was one use case were I could find them usefull.
Another feedback from me to this thread is that. It is better to make gradual changes. The change should not be so radical and huge that the old users who are accustomed will get upset. Nobody likes to relearn things. Having said that if we have set a goal then we can work towards that goal gradually.
Another important factor is to garner attention of developers who will implement and help us code this change. Also we should check if the mocks we are doing are possible to do with current Qt offerings without adding considerable developer time.
