Dev here who also happens to support Linux, and while Linux has its own challenges (whoever came up with the libevdev API, should not allowed to come up with any other API’s), I think it’s good to support Linux natively regardless. GNOME devs however should stop forcing their UX ideas onto others sometimes even outside of Linux. One of them when I was asking about how to I make the Alt key on Windows to stop it trying to open the nonexistent menu bar, then they told me to “just add one”. I’m developing games, not just desktop apps, where the alt key isn’t expected to open a menu bar. I then got told that it’s “expected behavior” (Hungarian here, I’d like to expect that both alt keys are for accessing a second set of gliphs, and one of them isn’t a dedicated “menu key”), and that games like Unreal Tournament “did it already” (that one used the escape key for menus).
I used to have this view but I’ve come around: change can be painful but it’s also necessary. It’s like a wildfire: it’s destructive but it allows for new growth and it’s a sign of a healthy, sustainable ecosystem. Suppressing change isn’t healthy.
Do I think that every change from Gnome is a winner? Nope but I do think they’re doing their best to move in the right direction, as they see it. And for that, I’ll keep using Gnome and I wish them good luck.
Agreed. I use GNOME on one system and KDE on another, and I think it’s good to have a group that’s very opinionated since consistent systems are much easier to support and more intuitive for new users. I don’t think GNOME itself is ideal, but I do think the ideas they’re pushing are worth discussing.
That said, there’s a reason I’m not all-in on GNOME.
The original Unreal Tournament (or UT’99, or whatever) is also one of the very few modern-ish full screen games that had a drop down menu bar like you’d expect on a typical Windows application. The other one I can think of off the top of my head is ZSNES, although in that case they rolled their own solution. Not least of which because the original ZSNES was a DOS program (with huge chunks of it written in x86 assembly!) so they kind of didn’t have a choice.
If I remember right UT’99 actually did use Windows style accelerator keys in its menus, i.e. hold down Alt and press a letter to perform an action, which might just make all this malarkey peripherally relevant.
One of them when I was asking about how to I make the Alt key on Windows to stop it trying to open the nonexistent menu bar, then they told me to “just add one”.
FYI - if you haven’t figured this out already (and useful info for other Win32 devs), simply block WM_SYSCOMMAND in your WndProc of your app if the pressed key is SC_KEYMENU.
I’ve done this for a game mod I’m developing (it didn’t have windowed mode originally) and I specifically blocked it only during active gameplay. Otherwise (e.g. during menus) it can be pretty useful to keep active.
Dev here who also happens to support Linux, and while Linux has its own challenges (whoever came up with the libevdev API, should not allowed to come up with any other API’s), I think it’s good to support Linux natively regardless. GNOME devs however should stop forcing their UX ideas onto others sometimes even outside of Linux. One of them when I was asking about how to I make the Alt key on Windows to stop it trying to open the nonexistent menu bar, then they told me to “just add one”. I’m developing games, not just desktop apps, where the alt key isn’t expected to open a menu bar. I then got told that it’s “expected behavior” (Hungarian here, I’d like to expect that both alt keys are for accessing a second set of gliphs, and one of them isn’t a dedicated “menu key”), and that games like Unreal Tournament “did it already” (that one used the escape key for menus).
And then break them with every major release
deleted by creator
I used to have this view but I’ve come around: change can be painful but it’s also necessary. It’s like a wildfire: it’s destructive but it allows for new growth and it’s a sign of a healthy, sustainable ecosystem. Suppressing change isn’t healthy.
Do I think that every change from Gnome is a winner? Nope but I do think they’re doing their best to move in the right direction, as they see it. And for that, I’ll keep using Gnome and I wish them good luck.
Agreed. I use GNOME on one system and KDE on another, and I think it’s good to have a group that’s very opinionated since consistent systems are much easier to support and more intuitive for new users. I don’t think GNOME itself is ideal, but I do think the ideas they’re pushing are worth discussing.
That said, there’s a reason I’m not all-in on GNOME.
Interesting. The only thing i knew is: the escape key is really important for Unreal Tournament.
The original Unreal Tournament (or UT’99, or whatever) is also one of the very few modern-ish full screen games that had a drop down menu bar like you’d expect on a typical Windows application. The other one I can think of off the top of my head is ZSNES, although in that case they rolled their own solution. Not least of which because the original ZSNES was a DOS program (with huge chunks of it written in x86 assembly!) so they kind of didn’t have a choice.
If I remember right UT’99 actually did use Windows style accelerator keys in its menus, i.e. hold down Alt and press a letter to perform an action, which might just make all this malarkey peripherally relevant.
FYI - if you haven’t figured this out already (and useful info for other Win32 devs), simply block WM_SYSCOMMAND in your WndProc of your app if the pressed key is SC_KEYMENU.
I’ve done this for a game mod I’m developing (it didn’t have windowed mode originally) and I specifically blocked it only during active gameplay. Otherwise (e.g. during menus) it can be pretty useful to keep active.