Added Mnemonic Support #1689
Added Mnemonic Support #1689
Conversation
|
I appreciate the effort. But I'm afraid it's not that simple. First, Rufus is translated in more than 35 languages, and I don't want only English users to be able to guess the right combination of letter (Since, for instance, French will display DEMARRER for START button, and you can't underline an Second, Rufus is already pretty much using the whole gammut of Alt-key combinations for cheat modes. For instance Alt-S is mapped to the cheat mode that disables the size limit check. So you can't just go around and replace that. And yes, we can talk about the design decision to use Alt and not Ctrl for cheat modes, but that's not something I am planning to change until the next major redesign. A proper implementation of #1688 will require some application redesign as well as translator involvement, which is the reason why I have deferred it. So while I genuinely appreciate the effort you put into this Pull Request, I'm afraid I have to reject it. |
|
I remember from my MFC days that the mnemonics could easily be set on any letter of the text on a button by simply adding an ampersand (&) in front of it. All the rest was handled through the framework. Something similar could be used to make this "translation-friendly"... |
|
Adding an ampersand, a la MFC, is precisely what this pull request attempted to do, but it was rejected because it is far from being that simple. You can't just add ampersand in I can therefore only reiterate that: a proper implementation of #1688 will require some application redesign as well as translator involvement, which is the reason it's being deferred. |
|
It is understandable but at the same time regrettable that status quo is chosen over accessibility.
While it serves no big purpose discussing thing after the fact (aside from someone who wants to make this design decision in the future seeing this and double thinking it), the power of hindsight does show that using Alt for cheat modes wasn't exactly the best decision. I'm not aware of any application off the top of my head that uses Alt alone for keyboard shortcuts, and Controlling something does make a bit more sense in the context of cheat codes. As far as I'm aware, Alt is used either for navigation (mnemonics or Alt alone to focus menubar) or to use the Alternative behaviour of a Ctrl shortcut.
Above pedantry aside, I don't see why this couldn't be done. Unless the process of actually changing the shortcuts would be difficult, the cheat modes are displayed in the FAQ (as opposed to in the app), so it is reasonable to expect someone to check the FAQ (or changelog) to see why they no longer work once the change happens (especially considering that most cheat modes are offered on a "you're on your own" basis). |
|
Switching from Alt to Ctrl is not the main holdback or even a major holdback. What is the holdback is that there is a combination of issues that need to get sorted, the major one being that the shortcuts should try to make sense in most languages. Using Alt-S for And then there's trying to handle conflicting mnemonics and so on. When you're only dealing with an application in one language, mnemonics are easy. When you're dealing with 35 languages, and you don't want to make one language more "equal" than the others, not so much... So, and this has to be the 3rd time I have to reiterate this: "a proper implementation of #1688 will require some application redesign as well as translator involvement, which is the reason it's being deferred". Trying to simplify the issue as a mere redesign or even a mere switch of Alt to Ctrl for cheat mode is doing a major disservice to what it actually entails at the programming level, and why it's not gonna happen that fast. Then again, and especially since I've started to release Open Source software, I have long come to terms with the old adage that "Anything that you don't have to do yourself always looks deceptively easy"... |
I don't really see why that's a major issue. I don't know the intricacies of what Rufus uses for GUI, so I don't know how it'll work for that, but for something like Windows Forms (yeah, not the greatest example, I know) the way to make this shortcut is to add I really don't see why there is such a big point made out of "Pornire doesn't contain S so Alt+S won't make sense in Romanian" when nobody asked these shortcuts to be hardcoded. In the same way that Rufus isn't hardcoded in a single language, I don't see why these shortcuts would have to be. Whoever writes translations could be asked to decide what letter makes most sense for a certain action and maybe even mark it like in WinForms with an ampersand. After that, yes, it's always easier when describing it theoretically and not actually doing the work, but what I'd do if I would have to manually implement this is look through the translated strings of actionable controls like buttons and, if those strings contain an ampersand, set up the keyboard shortcut.
As for conflicting mnemonics, it would probably be a translating error if they exist? If I were to manually implement handling of that instead of trusting the translations, I'd have a boolean array corresponding to each letter and not make the shortcut binding if it was bound already (perhaps with some logging in order to observe that this happens and correct it).
It is constantly mentioned that a redesign would be needed, but when reasons for that need are brought up, solutions seem to be found. Maybe the solutions proposed are inadequate, but (and it may be my fault here) I haven't seen them criticized as such. As for translator involvement, that's a given. But would adding support for a new langauge involve a redesign? If not, why would adding support for this would from that point of view? |
Exactly as I said: "Anything that you don't have to do yourself always looks deceptively easy"... Rufus is not using Windows Forms. It's actually not using any UI framework (so much so that we're doing our control positioning manually, in order for it to work at all scales, per https://github.com/pbatard/rufus/blob/master/src/ui.c#L233-L249), and the simplistic solution proposed above (of modfying the
Yes, a redesign will happen, so that I can solve multiple issues at once, including this one, and thus make a MUCH better use of my time than trying to solve them individually. The plan is to switch to XAML eventually, and whatever Microsoft will decide to provide as an XAML compatible platform for win32, so it makes little sense at this stage not to use that redesign to solve memonic, dark theme, commandline support and other issues that revolve around UI. Please bear in mind that with my time not being unlimited (or free) I will always be looking for ways to minimize the amount I need to invest on a solution, when by the simple act of waiting for some more favourable conditions to happen, I can achieve a better solution at a lesser cost. But please feel free to tell me again how stuff that you don't have the full insight into and won't have to implement yourself should actually be simple to add, and not be considered a waste of time if a planned UI redesign, not that far down the line, is expected to render much of that effort obsolete. |
That I could tell, especially since it's written in C, not C#. I merely gave an example of an approach and how I would manually do it myself, given that I was unaware of the constraints imposed by the custom translation framework.
The tone feels rather condescending, especially at the end where it probably is so on purpose. Switching to an entirely new architecture for the GUI will certainly provide a fresh canvas to better and more easily and efficiently implement planned new features on. Had I been aware that that's what the planned redesign entails, I would have agreed that it's best to wait from the beginning. Redesign can also mean still keeping what there is, shuffling UI around and refactoring some code while keeping the same base.
Given that a couple of months ago you've told me in #1688 that the redesign "may be years away", excuse me for looking for potential ways to implement this sooner than in a couple of years. |
Why? What's the urgency here? Can you explain how not having mnemonics is greatly impairing the ability of the vast majority of users to carry out the expected operations in Rufus? I am treating this, like dark theme, as a "nice to have but low priority feature", because, the way I see it, outside of a few people who are adamant that this should happen tomorrow because they would like Rufus to be something it was never designed to be (a sysadmin/power-user friendly tool), my time is still better invested in features and bugfixes that will help the majority of users. And I am far from being done with what I have lined up there in that respect. And yes, at this stage, I do anticipate the redesign (and therefore my adding the mnemonic feature) to be years away, which is a timeframe I am absolutely happy with, because it should give me enough time to work through more important stuff and planify this feature (so that I can combine it with a translation update for instance). If you are unhappy with that, I will kindly ask that you fork your own version and perform the work that you are expecting to happen on short/medium notice there. Or should I remind you that you got the application entirely for free and that, no matter how much you would like me to drop everything else I have planned, I still do not owe you any feature within a timeframe that you may consider agreeable. |
If we develop features that will only help the vast majority of users, accessibility wouldn't be a thing because people with disabilities aren't the vast majority of people. I can understand if that's the focus that you take with your own time, but I will also express the potential flaws I see in this focus if I am allowed to (potential flaws which you can rightfully ignore).
I don't really see how this is a sysadmin/power-user feature. A sysadmin/power-user would rather have command line rather than mnemonics, as mnemonic provide comparatively little improvement over moving the mouse. As I mentioned in #1688, mnemonics will provide a big improvement for people navigating the UI using Narrator, as they will have a quick way to invoke the main actions rather than listen to the Narrator describing the entire program until they can tell they focused the right button.
If you're getting this annoyed at people making requests when the application is free, you can make Rufus a paid application and/or turn off issues on GitHub. Leaving aside a little of the same aggressiveness you direct at me, I really don't understand why you get this offended. What audacity I have to suggest a feature and potential ways to obtain it early. Do you expect me instead to instead say "Here's something that would be nice, please don't add it for the next 10 years"? You've left open a forum for users to send you feedback. Why do you get so passive aggressive when users make use of it? If you don't want to hear from people regarding a certain topic, just lock it. But you're really treating this as if I'm about to hold you at gunpoint to do what I want, when I merely make the case of why it would be nice to have it and even (naively) try to provide my (basic and primitive) insight on how this could be achieved. You've only mentioned stuff like "a redesign is needed". I came and said why I don't think that might be the case. Because after all, it's not needed. It would be way harder to implement the feature now and it would be misguided allocation of personal time considering the future redesign, but it would certainly be possible. You never said "this will take a long, I am working on other stuff now, once a redesign is here it'll be easier to do and I'll handle it then", which would have clarified everything up. You just said "it's not possible before redesign". This message is going on for too long and it will probably be another waste of your oh, so precious time. But I still recommend to not view everyone as "I want you to do free work for me" when they're suggesting (not demanding) stuff, and, essentially, I recommend not being a passive aggressive mean spirited person, which is what it feels like you are given the way you respond. Ultimately, I suggest features hoping you will want to add them. If you say "it can't be done", I'll try to look into why. If you say "it needs this", I'll try to convince myself and ask "does it really?". If you say "I don't want to do it for now", I'll accept it since it's your time and work that you're putting in, not mine. If you even say "I want to do this, but it'll be much easier after the redesign", I'll even be happy that you agree with me on the feature instead of writing long messages and arguing. Please try and consider that. |
Because you are implicitly suggesting that I am doing a bad job and didn't think this through. Half your messages are "It shouldn't take that long to do it", so, yeah, you shouldn't really be coloured surprised if I'm getting annoyed at your repeated poking into this. You think I am aggressive? Please try to read your comments from my perspective, thank you. Especially, every time I try to explain why it's going to take longer than you think it will, you're seem to be getting angry and reply "well you should have said that first", which really leaves me with no choice but to assume that you clearly did not believe my statement that this isn't that quick a job. You started questioning the Alt vs Ctrl thing, promoting it as if it was the major hold up. Then you started questioning the amount of work that would be needed to make translated mnemonic work. Then you started questioning the need for the UI redesign. In short, you are rejecting every single point I am providing you on why I want to delay this feature as if I was spewing bullshit, and now you are getting "offended" that I am reacting negatively to your implicitly calling me a liar? This issue tracker is open for feedback yes. But it does not exist for me to get berated by individuals who are not ready to accept that my developer's time is not infinite, or that I can't drop what I'm doing on a whim to grant their wishes, or that I can't waste said time going through a bullet point list of which elements a requested feature requires to be completed and how much time each of these point is expected to take, especially when most users, such as the 2 I replied to before you you jumped in and started to question my statement as well as the time it should ultimately take to add this feature, are not trying to imply that the developer of an application is just lying... And you are still going on implicitly suggesting that I am not being truthful on the reasons why this will take time to add, with your "If you say "I don't want to do it for now", I'll accept it", as if it was just a matter of me not wanting to do it, rather than, as I explained, a matter of not making sense to invest work that will be rendered mostly obsolete the minute we switch UI framework (which is the exact same reason why I have stopped spending time working on dark mode, even though I was already half way there and sunk quite a bit of work into it already). If you want to convince yourself that I'm just dismissing or delaying features just because I don't want to do them, and that there's also no reason why I should be annoyed by your continuing questioning (dismissing) of the way I have logically decided to approach how and when a feature should be added, feel free to proceed. But at this stage, I'm going to have to ask you to please do that on your own, as I am both banning you and locking this thread, as there's only so much patience I have with people who are trying to pretend it is their right to sling thinly concealed abuse at a developer. |
Optimized application for mnemonics. Users can now press ALT followed by the first letter of the button they wish to press. WinAPI automatically adds an underline under the first letter of all buttons when you press ALT.
Changed IDC_SELECT from "SELECT" to "BROWSE", for better clarity and also so that all the buttons are accessible through mnemonics.
Inspired by issue #1688