An update on input

Posted Oct 13, 2016 5:41 UTC (Thu) by bronson (subscriber, #4806)
In reply to: An update on input by prometheanfire
Parent article: An update on input

And gtk and qt apps will always feel uncannily different.

An update on input

Posted Oct 13, 2016 13:30 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

Or fork! The libinput people also want to disallow arbitrary soft-button remapping, so I'm going to have to run a patched version locally anyway.

An update on input

Posted Oct 13, 2016 14:18 UTC (Thu) by raven667 (subscriber, #5198) [Link] (5 responses)

That's just a consequence we have to accept due to there not being a single "official" toolkit that can define what "correct" behavior is for the platform. Mucking up drivers to try and work around this fundamental fact is probably not good software engineering, if the toolkits want to be different, let them be different.

An update on input

Posted Oct 13, 2016 19:17 UTC (Thu) by hmh (subscriber, #3838) [Link] (4 responses)

That leads to an extremely horrible user experience. It is quite normal to have applications built on several toolkits in use at the same time.

An update on input

Posted Oct 13, 2016 21:27 UTC (Thu) by raven667 (subscriber, #5198) [Link]

Those toolkits already provide different user experience, they aren't horrible, they are just different from one another, as they should be. If the toolkit makers want to get together and form a consensus and standard for behavior, they are free to do so, many of the best standards on the *nix desktop have come through toolkit cooperation, and some of the worst behavior has come from the toolkits and the underlying environment fighting one another to provide their own idea of forced "consistency", breaking each other, breaking on upgrade with crazy workarounds built on workarounds that make your head explode.

An update on input

Posted Oct 15, 2016 23:04 UTC (Sat) by flussence (guest, #85566) [Link] (2 responses)

Getting toolkits to cooperate to achieve consistency hasn't been a problem before. Everyone agreed GTK2 was the way to go: QT3, Qt 4, Qt 5, wxWidgets, Firefox and Chromium all support it to varying degrees.

For a lot of people that's been Good Enough. The problem now is that GTK2 is a fish out of water in the Wayland/libinput world, and there's no good replacement to hold the ecosystem together.

The *bare minimum* requirements for something to fill GTK2's shoes here are that it uses the C ABI (so that everyone can use it) and doesn't break downstream users every other week (so that everyone will *want* to use it). EFL is, AFAIK, the only thing that technically fits the bill there. I've heard it's no fun to write for though.

I hope some consensus happens on avoiding this problem while there's still room to maneuver. Right now it's looking like the future of Linux desktop apps is jQuery and Bootstrap, with all the subtle horror that entails.

An update on input

Posted Oct 16, 2016 2:38 UTC (Sun) by bronson (subscriber, #4806) [Link] (1 responses)

> Right now it's looking like the future of Linux desktop apps is jQuery and Bootstrap

This is horrifyingly true. Electron-based apps have really been picking up steam lately.

Gotta admit, I'm a fan of the Atom editor... but c'mon, 4 second boot and 500+ MB resident for a Slack or WhatsApp client?

An update on input

Posted Oct 16, 2016 4:06 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

Atom is the new Emacs. Perhaps it should start doing unexec...