I am very sad to report that once again a new beta release manage to break the shortcuts . This happens again and again after new beta releases (and sometimes not just only beta...).

I am trying the third beta for 3.1 in Kubuntu 16.04 (krita-3.0.92-x86_64.appimage) and to my (not really) surprise, once again I can't use my custom shortcuts, because they are "ambiguous" and collide with default shortcuts that refuse to be changed no matter what. I have had this in one of the previous releases and even posted in one of the various (recurring) bug reports on this problem.

This bug is really a show stopper for me because I can't use krita in any productive way without the shortcuts, which forces me to big distracting movements (I have a big screen) to click menus and icons and many times swapping the stylus by the mouse because going through menus with the stylus is painful and clumsy. I assume that I do not need to explain to any artist why the shorcuts are absolutely fundamental and show stoppers when broken. Why to release any version (beta or not) when this is broken no matter what fancy features previews are there to impress people?

The question I have is: why this is a recurrent bug? Why this is not considered a "must really work" requirement before even thinking in any release? Or: Is this something related to the way Linux appimage is working or is built? Is this some kind of path or environment issue of the appimage thing, since it is mounted im /tmp/.mountsomething instead of the "normal" directories? Or is it something related to KDE/Kubuntu/Ubuntu only?

I have to add, that the current stable version krita-3.0.1.1-x86_64.appimage was already a pain because it also broke the shortcuts although in a different way: it just lost them, and I had to create them again one by one. I did not create bug report because this troubles with shortcuts seem to be "normal" in every release.

IMHO, It seems to me that there is far too much focus in new features versus fixing the really annoying things "paper cuts" that are silent (sometimes loud) killers to any project. This is the only explanation from what it looks like, sorry but I hope you prove me wrong. This is so frustrating because it really seems to mimic a sad path that projects like LibreOffice (just to mention one) have taken over several years, where what matters more is the eye candy (sometimes of questionable usefulness, I am sorry to say) versus the solid usability that characterizes some proprietary mainstream software that should be replaced by Krita. And all my respect to those of you guys who work so hard to kill bugs, but there are bugs and ...recurring bugs. Perhaps there is so much pressure on the devs to come up with fancy features and not to spend so much time in bugs? I use to work in a miserable company where Marketing was doing exactly that. That is suicidal.

New features are great, but never at the cost of overlooking the fundamental usability and user experience, please! This is what is killing LIbreOffice since its beginning, making it look still very amateurish to my sadness and frustration, and keeps people going back to MS Office.

Sorry guys for these not so exciting comments, but I like so much Krita and have been (and will continue to try to) replacing the infamous proprietary software since long time now, aiming to producing 100% of my stuff with Krita. So don't get me wrong, Krita is my favorite production software ever and I can't thank you enough for making it possible.

I haven't fully read your posts yet, but here's a quick response:

The question I have is: why this is a recurrent bug? Why this is not considered a "must really work" requirement before even thinking in any release? Or: Is this something related to the way Linux appimage is working or is built? Is this some kind of path or environment issue of the appimage thing, since it is mounted im /tmp/.mountsomething instead of the "normal" directories? Or is it something related to KDE/Kubuntu/Ubuntu only?

Nobody reported the bug up until this one: https://bugs.kde.org/show_bug.cgi?id=372198 (7th of november). We cannot fix bugs that aren't reported. And our big problem with the 3.1 release, and especially WHY it hasn't been released fully yet is that we KNOW we're not receiving enough bugreports about the beta(we know this, because there have been, what, 5 bug reports about the 10~ new features?). We were going to release it once we fixed a bug that we do know exists and is a huge problem, namely Krita not saving properly in certain situations and we have been doing huge rewrites to fix that.

And please note that these reports NEED to go to bugs.kde.org, there's only a handful of people working on Krita, and we cannot track reports on the forum, so if you report a bug on the forum, we might respond but it is going to get lost.


Edit: having fully read your post:

1. we totally fix bugs :c - This is particularly a list of 'for which version did bugs get reported and how many of those are fixed'. In reality, for example, the 2.9.7 release had over 150 bugfixes from all over the board. We try to list the list of fixes in our release notes, but we're not sure if this is the right way to go either, because having a list of fixes can also mean that people don't actually read the text, and the text is pretty important

2. We cannot find all the bugs by ourselves. That's why we make beta releases. But these bugs definitely need to be reported at bugs.kde.org, because otherwise we cannot track them, or even refer other people to them so that we know whether a bug is common. I recommend you add your comment to the bugreport I mentioned above so that we can immediately tell that it happens to multiple people.

3. Adding your own observation to a bugreport is really really useful in general, as it also saves time during triaging the bugs. This is needed, because a lot of the bugs we do get tend to be support questions instead of bugs(which SHOULD go to the forum), and driver bugs, such as OpenGL and tablet bugs where we spent ages trying to figure out what combination of which elements is causing the bug and whether workarounds 0 to 5 work or not and why. On top of the bugtracker, we also handle the forum, g+, reddit, tumblr, facebook and answer people's questions there, so any bit of help is super-valuable to us.

@TheraHedwig,
Thanks a lot for prompt and detailed reply.

Once again, I can't stress enough my appreciation and respect for all your hard work and dedication.

Nobody reported the bug up until this one: https://bugs.kde.org/show_bug.cgi?id=372198 (7th of november). We cannot fix bugs that aren't reported.

I really respect and suffer from the problem of lack of feedback from users. Unfortunately, I could never agree that what I am complaining about would be the case.

This is a very quick and dirty search (I have limited time, could not be exhaustive here):
Bug 352205 - shortcut ctrl+w cannot be reassigned from default action ()
Bug 348033 - Krita randomly decides mirroring view shortcut is ambiguous (old but related)
Bug 361911 - Overriding hotkeys won't work (conflict of new hotkey with old one)
Bug 372198 - Shortcuts reset to default

So, this hardly can be considered "Nobody reported the bug up until this one". Note that I am not attacking your comment, I am not here to attack, I'm a friend. I just appreciate how overwhelming is to go through so much when none of us I believe really has the time we would love to have to dedicate to be thorough. So please this is not about who makes better reading or argumentation and I won't feed a discussion on microscopic analysis of how related those bugs are: we could find good lawyers that would disagree. So, to the point:

In all of those (and I believe I have seen older ones, from the likes of 2012 or so), although with different titles, when we read through (I know, not easy, very time consuming, for me too), it always is there: "The key sequence 'foo' is ambigous..." and there is no way to make it work. This, and/or missing/overriden shorcut configurations. It all depends how people sees it and writes it. Sometimes someone is concerned with <ctrl><w> because he uses that, but I am not because I don't ever use it. So he writes it from that point of view. Last night I was having a miserable time with mirroring the view with my <ctrl><m>, and my lasso (outline) selection <ctrl><l> so I could write a bug with that perspective in my own words.

Then point is: isn't there all basically the same thing? I don't mean the same line of code: I mean, the same usability trouble. That's the point. We could make a semantics discussion about whether we are talking about some kind of collision with KDE 'over sensitive' shortcuts in some case and some kind of krita thing in other cases, but the truth is that none of that matters for the user: he wants to use the shortcuts, he wants to configure his shortcuts as he does with Manga Studio, Photoshop, Painter, Blender, Gimp, Inkscape, whatever, and he can't: whether that's Windows code, Ubuntu's guilt, keyboard driver, Adobe's or Corel's bugs, ... it goes to the same: One and only one problem: you cannot use shortcuts in this program, period. That's my point: shortcuts in those programs actually do work.

With all that said, all your considerations about users feeback in proper way and proper place (bug report vs. forum, vs. other) are absolutely true and of huge importance. I have to recognize that myself, in first place could be doing more into helping to detect these and whatever issues, and reporting them properly, as I know very well you could not guess bugs. However, sadly all these is very time consuming and not always one has the time for going through finding in which of the existing open, confirmed or not, bugs one should post, if at all, or open a new bug, when there are multiple of them, inconclusive, even from long ago.

I hope that explains better what do I mean when I ask: why this is a recurrent bug? It hardly looks as if every time since years someone complains about "ambiguous shortcut" is always something totally new and unknown. So I have to ask: how many complaints are necessary to raise the visibility of something like this? The fact that people doesn't complain more, doesn't mean that they are not having trouble: it means, that complaining is inherently difficult because you need to know how to do it without getting a very defensive response or none at all (EDIT: attention: In general, in life; NOT from you guys).

But there is more to that difficulty: When one sees that there already is an open bug, either you go ahead and post "me too" or assume "ok, those guys now know, they'll look into it", because we don't have the time. Or, yet, worse:

The last time I was seriously preparing a detailed bug report, I found myself fighting a yet new bug that prevented me to reporting bugs in KDE. This was so infuriating, that then I saw that I was buried in an spiral of nonsense trying to understand what to do to accomplish anything useful without dedicating many hours of investigation to report at least two very bad bugs. Time is not infinite, so I quit, and limited myself to post in one existing bug report, almost randomly chosen, among those similar to my issue.

If you are curious about my unrelated KDE issue, it went about these lines:

Code: Select all

QObject::connect: No such slot KBugReport::_k_appChanged(int)
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

Not nice, for someone without the time to these things and the wish to help. So, sorry, I'm done with the KBugReport thing, so I am limited to just post comments there and here.

I have posted a couple of comments in some existing bug reports. Otherwise, I hope this is helpful in any way. I just hope that someone can connect the dots between of all those complaints --more than enough, IMHO-- and investigate the pattern.

Many thanks and all my appreciation for your attention.

Probably it is seen as a new bug because people don't remember the old bug? That is the case for most people on the project. We're sadly human beings

What also might be related is that we rewrote the shortcut code several times. The person who last did it disappeared. We do not have anyone who can work on this at the moment. Probably, it was presumed to be fixed, and we just have too few people working on the project to verify it was fixed last time.

We're just really understaffed, even with volunteers. And as long as we are, I can only tell you that this will continue happening. New features are the only way we can keep funding our little existing staff. (Though, the vector stuff should finally fix or incredibly, equally buggy vector tools, so it's efficient in some sense)

Anyway, thanks for replying to the bugreports, it helps a lot!

All of you guys have earned, since many years, a huge capital of respect, admiration and gratitude, from so many of us, your loyal user base. That is not said often enough, as it should, really. When I read such an honest and transparent answer, I can't do anything less than feeling privileged for being able to enjoy your work and simultaneously "fight" for it getting ever more and more outstanding, which is anyway exactly what you guys are obviously dedicated to.

I think there are few important takeaways from this thread:

1. We, users, have to do everything we can to give you guys (developers) useful, meaningful feedback in the most efficient, effective way. Developers cannot fix bugs they are not aware of and properly, timely informed.

2. We, users also -- and unfortunately -- have difficulties to accomplish the previous need, because:

2.1 The bug report system is sometimes intimidating and/or simply doesn't work (e.g. KBugReport is broken), and/or involves too many requisites and/or is too time consuming.
2.2 Effective/efficient technical language is not the most common skill among non-developer users, and even among some of them.
2.3 When there are multiple bug reports already open on similar/identical/related issue, it is very difficult for the user to decide the best course of action: Not to take any action because it's already been taking care? Comment in some/all of them? Open a new report instead? Under which title? wouldn't duplicated/triplicated reports with different wording make it more difficult for developers to focus? or: is it better to just say "me too" in some thread? But what if this thread is not the one that somebody is already looking into? and so on.
2.4 Creating a bug report about something that may not be a bug, or is already closed in other context, or somehow is not well explained or understood, could damage your reputation or ridicule yourself.
2.5 Some users believe that there are always other people taking care of everything, or that others that are experiencing the issue will anyway complain so "why should I do it too?".

3. Developers have it very difficult to get a consolidated picture of issues and bugs because multiple and disparate sources of information (forum, bug tracking system, chats, facebook, email, own experience, etc.) and inconsistent / insufficient details or poor communication skills of reporters. Not all users get that right or appreciate it.

Looking through all these, there is no easy answer. I think all vectors could be improved, though. I believe that good, techically savvy bug reports must be encouraged. BUT: I also think that it is very important that non-developers and non-technical people be encouraged to report issues, using a simple vehicle like the forum.

I know this is more difficult for developers, because now you also have to read through "normal prose" instead of very succinct and to the point report. But if you really want more feedback, even if it's not so perfect, then you should allow and encourage people who are non technical, to write their complaints in e.g. a forum if they are not comfortable with the bug report. This is the only way to increase the amount (though perhaps at the cost of technical quality) of information and feedback.

When you are small, you cannot afford to take a very formal approach, a bureaucratic/arrogant attitude and say to your users: "You don't know how to complain, then we won't listen to you: follow the procedure, or go to hell" That's what a big corporation or the government does. Try to complain to e.g. your Tax Office, France Telecom or Deutsche Telekom about anything without following their bureaucracy. Are they sad that your complain/feedback didn't go through? ... But: are you Deutsche Telekom or a government agency ?

I cannot think of any magical way of increasing the developers headcount, but I am sure that the more reliable the product becomes, the more popular it will be and the more likely new users and new developers could join.

I appreciate that newer and fancier features seem to be the only way to keep the funding, but I also think that a software with recurring fundamental bugs is simultaneously risking not being considered "serious" or at least with potential to compete with others, thus loosing (or not getting more) users, then loosing/not attracting funding. That's a deadly trap.

From my side, I will try my best to be more helpful, even if it is just posting comments in bug reports or whatever else I can do.

Many thanks again for your very honest and courageous words.

Using the forums only for the bugtracking process will actually, in all likelyhood increase the amount of lost bugs. This is on the basis that we lose the ability to track the operating system, confirmed status, duplicate status, which bugs are new, attachments, which version, email capabilities, and so forth.

Secondly, the prime reason why we will not adopt this process, is that it will kill us due to the increase of work it brings. I am not sure why you acknowledge that we work hard and then propose that the solution is that we work harder. I am in any case disagreeing with this, as I am positive that it will cause me to burn out, and damage my physical health.

I am not sure what would make the notion, "we're stretched thin, problems like these are inevitable due that", acceptable, but I am afraid that we will not be able to become any nicer or deliver a better product if we don't get a little bit of help in form of going through the motions of protocol.

All I can do is ask around what is up with the kde bugreporter thingy. I've never used it myself so wasn't aware it had any issues.

Well, you definitely got me at

I am positive that it will cause me to burn out, and damage my physical health.

and I am forced to say that no, by no means! Nothing that anyone could ever suggest here (including me) should ever push any one of you in such direction. No software or project of any kind would ever justify that, and I most certainly have to say: no, I do not want you or any dev to work any harder and I am sorry if what I said does imply that (it actually seems to ). That would not be solution for anything and would be plain cruel and stupid. I know what a burn out is and I would never ever wish that even to a fierce enemy if would ever have one (hope not!). Let alone to people I care for, like you guys.

What I am trying to do is to generate some brainstorming and honest exchange of ideas of what could be done to improve the identified obstacles. As engineer and creative person, I operate very much like that, constantly brainstorming, including the stupidest ideas, which is very useful because it helps me to rule them out and refine my thoughts. Dropping bad ideas is actually extremely cool. So no burning anything or anyone, period. We want quite the opposite!

Now, moving on:

I have been thinking a lot in what can be done to improve things, is just my way. I have this idea that --once again-- may or may not prove idiotic, or at least already tried and rejected for whatever reasons. In any case, it will be helpful to describe it. Since this thread is about a specific issue with the shortcuts bugs, I will open a new thread with my proposal, for the sake of not mixing many topics in this particular thread.