https://bugs.kde.org/show_bug.cgi?id=523170
--- Comment #4 from [email protected] --- (In reply to Nate Graham from comment #2) > not "aaaaaa everything about this whole feature is broken everywhere!" Well, my point was that the bug is, that this class of problems is even possible. As for the “aaaah” aspect: Yes, you are right, but sometimes it’s just a bit much for a mere human. I was almost pulling my hairs. Please excuse the humanness. > As depressing as it sounds, this will require someone to go and investigate > every single case where the problem with mnemonics (that's the name for this > feature) occurs, and identify why it's occurring. Yes, every single one. I have to strongly disagree there, because that is not what a programmer would do. We don’t do large lists of { if … then … else }. We do formulas. An if possible, already fix it in the language design and compiler. We change the general pattern at one exact place. This is why I said: We need to make this class of bugs impossible in the first place. The bug is, that one can code and build and release code with non-explicit (automatic) mnemonics. So: Whatever (e.g. QML engine or Qt, I don’t know the innards well) function it is that reads in what the caption and mnemonic should be at compile/build time, should: 1. Fail with an error if no mnemonic is given (or it is whitespace). 2. Check the mnemonic against the mnemonics of all other elements in whatever list type is turned into a menu or form or the like, and if two collide, fail with a descriptive error. Then each developer is automatically reminded to fix it on the next build, because they very likely just forgot or didn’t know. (I was not very nice about them in my previous statements. I retract that.) > - Mnemonic letters not set in the UI strings, so Qt has to determine them > automatically, and it gets them wrong The technique of reading the mnemonic from the caption string via e.g. an ampersand (&) in front of it was never a good idea IMHO. Not only do people forget to escape a real ampersand, but it leaves no trace of an idea of it being a requirement. In hypertext markup terms: The tag should have a required attribute for the mnemonic, and the markup should be invalid if it is missing. But with what we have now, it’s probably best to just treat a caption string without an ampersand in it as an error. (And space cannot be the mnemonic, so accidental non-escaped "bla & blah” for example, can be caught.) > then fix it. Some potential sources of the problem could be: > - Mnemonic letters not set in the UI strings, so Qt has to determine them > automatically, and it gets them right, but then the set of content changes in > a dynamic UI, so the mnemonics change too The best design I found for truly dynamic menus (e.g. based on user input, like sessions in Kate), is to either have no mnemonics on them at all (That works just as quickly if the choices are ≤8 and [Home]/[End] work.), or to force mnemonics on creation there too. (E.g. when saving a session in Kate, just have the dialog show and error and not let you OK/save until a mnemonic is in there.) > - Mnemonic handling in a particular focus scope is broken due to multiple UI > elements setting the sane one Yes, that is why usually in UIs, mnemonics only work for the current narrowest context, and not the entire window, unless they are explicitly set. That was even the case in Delphi already, if I remember correctly. So only the current sub-menu. Or only the current panel.Which can only break if it is dynamic, like mentioned above. E.g. for system settings, if you are in the sidebar (= it is in focus), only the mnemonics for that list would work. But if you hold Alt, others elsewhere may be (visibly and noticeably) offered too. At least that is how it should Sadly, it isn’t. (systemsettings is fully unusable with only the keyboard. So is the emojiter (the Plasma emoji selector).) > - Mnemonic handling in QtQuick is immature and needs upstream improvements in > Qt Qt is ancient though, and I’m actually surprised it doesn’t already do all of that, because it certainly isn’t the worst of toolkits. :-) > So you see, this is not really a bug report, but rather the very first step > of a massive project. Let’s not start seeing it like that. Let’s not make it that. It will be a major hassle and nobody is willing to deal with it then. We can instead just see it as truly just one small code change that it is. In the code that runs to verify the caption strings. Then it will pop out its head wherever it is needed, without going through all the effort. KDE already is at least a 1000 times as big as it needs to be for the functionality it has. That is IMHO the origin of problems like this. I tried to get into KDE coding, but gave up when I saw that 99.9% of it was boilerplate and bureaucracy. And while QtQuick is comparatively nice… As a former WebDev (doing web apps in 1998, and AJAX two years before the API existed [using Object tags]), I literally stopped doing things like that because I found the “web dev” style of coding is *already* several steps away from good and towards insanity. ;) > But based on my experience, a project of this size and level of complexity > only gets done if it's driven from start to finish by a passionate person who > really really cares about the topic. Exactly! That’s what our open-source communities are all about. Which is why that way of seeing it, is just sentencing it to death. :) (In game design you would say that the joy comes from the effort being worth it for the reward. (And fun = joy + [useful] surprises.)) > As you may have intuited, passion for mnemonics has waned in recent years, > which perhaps explains the poor state you're seeing. Personally I use the > keyboard all the time, but I prefer to use what used to be called > accelerators — keyboard shortcuts like Ctrl+P, Ctrl+V, and so on. Mnemonics are just accelerators too, though. They don’t have a Ctrl/Alt/whatever key, exactly because they are accelerators for the current context only, and the Ctrl key exists to break out of that context (or make the focus even tighter in certain designs). (And Meta and Super break out even further. While Alt technically wasn’t the same as Meta, but meant like how we think of “alternate fire” in a shooter game. An alternate choice, more like a second Shift key. At least that is what I figured out over the years. :) > So I think if a project of this magnitude is to be completed, probably the > person to do it is you! > Are you interested in working on this? I tried. Trying to alter the code is usually the first thing I do. But frankly, after looking into KDE, even years ago: It is light years away from the level of emergence that is my minimum requirement nowadays. (Emergence = power * simplicity. E.g. Lego or Minecraft have very high emergence. And Plan 9 does too.) So for me, I have to first learn how all of Plasma/QtQuick/KDE/Qt works first, and the time of it being worth the effort are long gone. For somebody who’s already fully in it though, it would probably be a quick one-hour thing. (An evening, with testing.) And since then, I moved on to coding an entirely new userspace compatible with modified Linux and maybe Hurd, based on a persistent declarative (causal/semantic) object hypergraph that describes a static block universe with an arbitrary number of “time dimensions”. So basically Plan 9 on hyperdrive, fused with ideas from superdeterminism and neurology. :) (Yes, without explaining it, it’s word salad from Star Trek. ^^ But each of these words has years of thinking behind it.) So in a way, yes, I am already working on it. But maybe not the way you would have liked. :)) Until then, maybe somebody who’s already diving into KDE’s code daily, is willing to do the little-effort fix I suggested. (In a way that doesn’t upset anyone.) If not, and there is no other quick solution, we may aswell close this bug “RESOLVED: NOT WORTH IT”. XD But hey, … I tried. I’m the one who always says: Even if one offered money, it’s a good thing nobody can be forced. :) -- You are receiving this mail because: You are watching all bug changes.
