gzdoom in ubuntu : customize key control

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!

Re: gzdoom in ubuntu : customize key control

Postby Graf Zahl » Mon Apr 15, 2019 1:51 am

dpJudas wrote:Because I don't think interfacing X11 is particular tricky (done it before). The biggest catch are the window manager hints, which I admit is a PITA, but on the other hand once you've paid your taxes for Linux desktop WM hell, you no longer have to rely on distros updating SDL for Vulkan support, for example. Essentially the same reason I prefer my own solution on Windows and macOS - the cost of writing the platform binding is one-time early on, but the benefits of not having the abstraction lib between you and your platform is worth it in the long run.


I generally agree, as long as it concerns such thick abstraction layers as SDL which make it very hard to work around its shortcomings. That's why I mentioned GLFW which is a very thin layer - it only abstracts the window management but does it in a way that it's still possible to get around it.

I find it a bit puzzling that almost every other port out there settled on SDL and constantly has to deal with some problems by using such a Linux-centric library on Windows. SDL 1.x was particularly problematic if you just happen to use a non-standard keyboard layout. I have no idea what the SDL guys have been doing but they somehow managed to change the system setting in a way that it got Windows to activate its language changer in the status bar. Back in the early days when I was still working on a PrBoom derivate one of the first things I did was to get rid of SDL because it constantly stood in the way of doing things right.


dpJudas wrote:Edit: Sorry for the harsh words, but I completely agree with Linus Torvalds when he commented on "Why Linux Failed On the Desktop".


Nice video. It sums up the problem I have with Linux mostly. One directly applies to GZDoom: On Windows and macOS it's a trivial matter to get a string, give it to the system along with a font and a size and retrieve a perfectly usable graphic for the text. On Linux - no such luck. The system has no facilities and with third party libraries we are again at the mercy of those users who are unwilling to install the needed libraries for whatever reason - be it that their distro of choice does not provide the needed version or they have some irrational antipathy towards one of the dependencies and what not. Fortunately I am not directly involved with this at work but my colleague who is responsible for our software's Linux deployments can tell endless stories about this stuff and how much wasted work it costs. In the end it's just cheaper to equip all working desktops with Windows and forget about this support nightmare.


dpJudas wrote: I get why people feel you need an abstraction library just to target that platform, but I don't think that applies anywhere else. What got me commenting in the first place was Graf talking about using one of those abstraction libs for Windows. That I feel is a bad idea when there's already a perfectly working solution in place. I'm sure those are fine libs but I don't think any of them does it better than the direct GZDoom code built for Win32 today.


It all depends. Yes, we have our own Windows backend, our own macOS backend and our own SDL backend.
What if we needed an Android backend - or an iOS backend - or a backend for the next hot thing that comes along in 5 years.
While they 'work' they also cause work. Fortunately not much but it's there. So if there was a practical way to fold it all into one piece of code and offload the backend maintenance to the maintainers of a third party library *WITHOUT compromising our own product* it'd be worth it. Sadly it's here where SDL is a less than optimal solution.
Just as a recent example, until recently the entire Windows backend had no clue about Unicode, it was using the ANSI API for everything and many parts were hard coded to assume 8 bit characters. It was a non-trivial amount of work to change this.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: gzdoom in ubuntu : customize key control

Postby dpJudas » Mon Apr 15, 2019 9:47 am

Chris wrote:Sure, but given the number of applications that rely on SDL/similar, if it's a desired feature it won't be ignored. If you can't update your code to supply new hints for a new feature, you likely couldn't update your code to access the new feature directly either. So with the former, you may or may not get an automatic improvement with a library update, and with the latter, you definitely won't.

I think you misunderstood what I meant. I am talking about the situation where the new feature relies on information not exposed by the SDL abstraction. For example if the new Best Practice (god I hate that phrase) is to use Vulkan over OpenGL, or DirectWrite over GDI's font classes, there's no way SDL can close that bridge for you. SDL can only help you each time someone comes up with a new incompatible sound daemon implementation or whatever idiotic "lets just drop the backward compatibility" move they might do next. It cannot magically improve things unless its own abstraction is actually superset of what its wrapping. It is the law of leaky abstractions.

I think such libraries makes sense for stuff that's "unimportant" for you app. Things at the edges where you don't really care if you have the best implementation possible for the platform or not. However, for games I think the display and input handling is quite central to the product.

But more seriously, if it's a feature that a lot of applications need, they can't ignore it.

Never underestimate the power of unwilling developers and managers in key positions. Yes, eventually it will cause them to hurt as they lose users, but celebrating Qt will eventually pay for their unwillingness to serve their customers aren't worth much when you literally built a decade of UI on top of that abstraction library. You will go down with them.

If so, it sounds like a serious bug that would be affecting not only those Doom source ports, but everything else that uses SDL for similar functionality, and should be a high priority for them to fix.

The keyword here is should. What if their active developers mostly reside on Linux? What if most of them only care about OpenGL based Linux games? They might not be retro gamers.

Firefox had a bug where keyboard input would be lost whenever a Flash component was rendered on a page. It had this bug for over 3 years. Every single user affected on Windows. High numbers is no guarantee for them prioritizing something if the manager at Mozilla happens to be one of those people that only use the mouse. ;)

It's obviously not a problem with the platform's capabilities since Wine is using all the same facilities a native game could (in a less-than-efficient manner, even), but the developers of such games simply don't have the time or financial incentive to make their Linux-specific code as good as it could be.

They opted for not caring for the quality. You're right that if you don't care about Linux then using SDL at least give *some* support. That doesn't mean it is better than an actively maintained backend.

Anyway, we probably won't get to agreement here because we have different trust in 3rd party developers. That's essentially what it boils down to. You expect them to provide a good service, and I expect them not to. :D
dpJudas
 
 
 
Joined: 28 May 2016

Re: gzdoom in ubuntu : customize key control

Postby dpJudas » Mon Apr 15, 2019 10:01 am

Graf Zahl wrote:It all depends. Yes, we have our own Windows backend, our own macOS backend and our own SDL backend.
What if we needed an Android backend - or an iOS backend - or a backend for the next hot thing that comes along in 5 years.

For Android and iOS the big problem isn't calling their CreateWindow equivalent - its supporting their graphics API and chips. Also since those platforms are sandboxed the real work here is figuring out how to deal with packaging as it is so different. Their input UI also uses a completely different principle (touch vs keyboard+mouse), which once again no abstraction library can fix for you.

As for what comes in 5 years, this falls into the You Won't Need It category. With no knowledge of that potential future platform, or the future of your abstraction library of choice, you can't know if can be supported by a trivial recompile. It certainly wasn't the case when the mobile platforms emerged. You have some chance it will magically work thanks to the wrapper lib, but I'd say you won the jackpot if that is the case.

While they 'work' they also cause work. Fortunately not much but it's there. So if there was a practical way to fold it all into one piece of code and offload the backend maintenance to the maintainers of a third party library *WITHOUT compromising our own product* it'd be worth it. Sadly it's here where SDL is a less than optimal solution.

If you don't like the maintenance burden and want to get rid of it, sure, who am I to stop you. Just remember not to blame the user or his hardware if a user shows up that now can't do XYZ thanks to the wrapper lib not having included that problem in its abstraction.

Just as a recent example, until recently the entire Windows backend had no clue about Unicode, it was using the ANSI API for everything and many parts were hard coded to assume 8 bit characters. It was a non-trivial amount of work to change this.

That's more an artifact of the early ZDoom developers not knowing the platform. Even Windows 95 supported the Unicode API. If they had used a wrapper lib back then it too would have used 8-bit and have just about as good an idea about it as the C locale functions (some true character set horror right there).
dpJudas
 
 
 
Joined: 28 May 2016

Previous

Return to Bugs

Who is online

Users browsing this forum: No registered users and 1 guest