>GTK 3 and QML (Qt5) would like to target the same space as web applications. It doesn't make sense. Applications which are written with a web UI in mind will translate very poorly on the desktop, and the opposite is also true.
QML is not targeting the same space as web applications. Its a more flexible and dynamic way of creating user interfaces. Its designed so you can create UIs for kiosks, infotainment systems, mobile applications, games, and desktops all with one toolkit. QML has components specifically for desktop development that have the same look as your traditional forms based widgets.
> The "big buttons" are that size because people have all sorts of accessibility needs different from your own
What accessibility needs are you targeting when you make the buttons and titlebars bigger? Why did this change drop suddenly? Was there a cry from the majority of your users that the widgets are too small to use with desktop inputs?
Usually when there are accessibility issues you add options to deal with that, you don't change everything for a relatively tiny percentage of your user base. Would you make all your widgets have max contrast and double the font size by default because it improves accessibility for the visually impaired?
> Usually when there are accessibility issues you add options to deal with that, you don't change everything for a relatively tiny percentage of your user base. Would you make all your widgets have max contrast and double the font size by default because it improves accessibility for the visually impaired?
There are way more types of impairments than visually impaired. We do have high contrast themes to help with a subset of visual impairment. (Even visual impairment is a wide-spectrum).
Many of us may not particularly like touch screens, but an incredible number of computers that run Linux/BSD these days have touch screens. Things should work out of the box for these computers whether or not you want one.
So we can make arbitrary guesses at what the "majority" is but the reality is we have a lot of hardware that we should support. Getting real statistics about users in F/OSS is difficult due to the high overlap of people interested in personal privacy. So we try to make as informed of decisions as we can.
Additionally, more computer users than you might image have various difficulties in using the computer. Even if its not a majority, say one in ten, is still a large number of users.
Count yourself lucky that you don't have an impairment (right now). It is common that people have an impairment at some point in time (RSI, broken arm, etc).
I certainly agree that HiDPI is often way too large today (again due to the need for compositor integration), and I also agree we should have a condensed mode. However, I'd probably argue to implement a condensed mode on top of an effective 1.5x scaling (3/2) rather than yet another option in the toolkit/themes.
Why are you lecturing me on visual impairment and disabilities? At no point did I claim you ignore that user base.
>Many of us may not particularly like touch screens, but an incredible number of computers that run Linux/BSD these days have touch screens. Things should work out of the box for these computers whether or not you want one.
Okay so after all that we get to the root of the issue. Instead of a good traditional desktop experience, you want to provide a mediocre desktop/touch hybrid experience. Instead of doing one thing well, the aim is to do multiple things poorly.
I am trying to not come off as lecturing. My apologies if it was interpreted as such. You were making claims and I'm simply trying to provide examples of how other peoples computing experience might not match your own.
> Okay so after all that we get to the root of the issue. Instead of a good traditional desktop experience, you want to provide a mediocre desktop/touch hybrid experience. Instead of doing one thing well, the aim is to do multiple things poorly.
No need to get disparaging here. Clearly we don't want to provide a "mediocre" experience, nor do I think we do.
I also don't agree that supporting touch is some sort of hybrid experience these days. We aren't trying to be a mobile platform. We aren't trying to be a phone platform. Peoples traditional desktops (including many home workstations) have touch. These are real desktops bought by real people who get real work done.
I work with a lot of people who have desktops. I have two. I haven't seen anyone use a traditional desktop with touch. No one. Not once. My girlfriend is a 2d artist and she uses a wacom tablet for digital painting in photoshop. That's it.
I always disliked the huge buttons that come by default with some desktop environments, and I'm amazed the argument is "people use touch". As far as I and everyone around me is concerned, no they don't.
If it's an accessibility issue, it should be an optional solution for those who need it, not the default.
Don't normally comment online as I find it a lot of work (it's taken me about 5 hours to put together this pretty badly written response), but while there's a GTK dev here on topic I don't want to miss the opportunity.
> There are way more types of impairments than visually impaired.
Thankfully I have perfect eyesight, however I am very dyslexic. I have problems with spelling, but Google's search spell checker and voice recognition have made huge differences to me in that respect over the last year or two.
But relevant to GTK - I have a terrible short term memory. A goldfish like short term memory. I can barely remember a sentence when switching between windows, 5 numbers is a challenge (no distractions please) and remembering how another programmer abbreviated a variable's name is a huge distraction.
I can't organise IRL or digitally. When I'm programming terminal windows just keep piling up, because I can't remember what terminals are doing what (is that sitting at a prompt or is it watching a folder with inotify?). I could click through the open terminals and disrupt my chain of thought and forget what I'm doing or I could just open another terminal, keep working and do a closing session every so often.
So onto how GTK is making my life harder: by making widgets more accessible to people with impaired vision/touch screens they've made them bigger. I can now fit less on screen and I have to remember more. I have to move between windows more and I have to scroll more. This really is making my life much harder, I'm honestly getting lost on my desktop because I can't remember shit and I'm constantly having to switch windows - because there just isn't room any more for two side by side windows on 720p.
And it really never used to be this way. Compare Gnome Terminal with xterm. Yes gnome terminal is better, for instance you can turn off bold fonts (Myself and many other dyslexics have problems with bold and especially italics) and have a nice GUI for changing the settings. But it's visually huge. I'm pretty sure (unfortunately not checked at all, I use XFCE - because it's smaller on screen) with the default font settings you've got just about enough space to tile 120 columns of Gedit and a 80 columns of Gnome Terminal - but not something you'd actually write code with, by the time you've got Sublime's side bar open you're going to have to shrink the fonts. And find a window manager theme with smaller borders. And find a reduced size widget theme (these often don't shrink out much whitespace). And after that somehow you'll still feel cramped, maybe it's because everything has been unnaturally shrunk.
And, really ranting now, the web is the same, I'm starting to quite regularly zoom out on websites to make them more navigable, I'm getting lost scrolling between the massive headings and huge white spaces. I can't find the damn menu buttons and by the time I've found them I've forgotten why I wanted them and have to mentally backtrack (What am I doing? Why? So why was I reading this? What was the bit that sparked something? Oh yeah! Right, back to the menu! Where did that menu go again?...).
Going to the terminal example again if I want to tile my XFCE Terminal and a Digital Ocean tutorial I've to zoom Digital Ocean to 90%. And Digital Ocean are efficient with screen space.
I'm currently using a 720p 13" laptop display and I think my next laptop is going to have to have a 1080p screen, just so I can fit whatever I'm working on. I'll then have to override the DPI settings of course and generally have a broken display setup. I'm looking to buy hardware and run a nonstandard setup to solve the accessibility problems that GTK has introduced for me when solving accessibility problems.
As an analogy to the situation (on bad days) I feel it's like GTK/Gnome is running around shouting "EVERYTHING MUST HAVE WHEEL CHAIR RAMPS! NO STAIRS! ACCESSIBILITY HAS SPOKEN!" ignoring that sloped surfaces can be difficult/painful for those with hypermobility syndrome. And when it's brought up "I'm able bodied but my knees are getting sore" (AKA "your widgets are too big I'm clicking around too much") the response is that it's accessibility and wanting something different is denying wheel chair users. But this response is missing that an able bodied person is having problems (they're being annoyed by it because it's causing them difficulty) and if an able bodied person is having problems then there is almost certainly someone less able who is having even greater problems.
As in able bodied people are complaining your widgets are too big because they're finding they have a higher cognitive load because they're having to switch windows more often. The reduction in general accessibility (higher cognitive load) is traded to enable specific use cases and it's considered ok. In testing you able bodied people say "this is barely harder" and your specific use case say "this is great". But what's missing that there are other people with other disabilities you never tested - we don't speak out because there's not many of us and frankly it's not very easy, both to speak out and to make a meaningful contribution to something as complex as UI ergonomics.
Basically what I'm saying is, yes it is good to have options for disabled users. But forcing the default is not a good idea and you might find you're causing problems. The default route into buildings with access ramps is still normally a set of stairs.
For example I could request that bold and italic fonts not be used anywhere in a UI, for me this would be great, but for able bodied users this would be a step backwards and reduce accessibility (the UI can't highlight important text for instance). Able users would complain, and it would be a mild "oh I liked it when the top command put the total memory in bold, it made it pop out a bit" to which GTK would correctly say "but dyslexics find this approach much easier" but this conversation misses that there is another category of people with poor eyesight who find the bold emphasis really helps them find the important details in the UI. But because GTK has made removing bold and italic default (in the name of accessibility) the user with poor eyesight has no options to turn that back on, and the community is already galvanised against allowing bold, because they did a UI study and it helped dyslexics.
> Count yourself lucky that you don't have an impairment (right now).
Worst of all is if the "but dyslexics find this much easier" statement has accusatory undertones of ableism (Despite my quote I don't feel audidude has done this). That might lead to the poor eyesight user to agonizingly craft a response over 5 hours that tries not to offend anyone in the galvanised community, because they don't have dyslexia and don't understand the difficulties faced, maybe they really are being ableist. Alternatively, and much more likely, they'll just keep quiet and GTK will carry on oblivious, making life worse for them.
Now I have got to thank GTK for being really good with having highlightable text in dialog boxes so I can copy and paste into Google. Also after spending a lot of my childhood in Learning Support classes I have to thank GTK for all the hard work they're putting into accessibility, it isn't sexy, it annoys people but it's damn important (even when I think it's going wrong and sometimes makes me wish I worked in construction).
Thank you so much for writing this post. I know it must have taken quite a bit of time to put together. I don't think all the reasons about the choices we've made were necessarily accurate, but the post is so valuable on it's own it's not worth nitpicking.
I'm sorry that things have been getting harder for you. I'll share this information when we have our summer meet-up face to face to discuss the next years work.
I can't know for sure without studying (maybe you'd be interesting in doing a study with us?) but I'd think if we can get the additional scaling factors into libmutter (the compositor layer for GNOME) that you'd have more precise control over the sizing that would work for you.
That was a pleasure to read, and sheds a different shade of light on the matter of accessibility. Definitely is going to make me think twice when designing a webpage or application.
Thanks for the writeup :)
Account breaches are so god damn annoying. That coupled with the stupid rules for coming up with passwords (only 6-8 characters, a-z,A-Z,0-9 allowed!) makes it really frustrating to keep track of and manage passwords for sites like this.
Hurry up and solve the user identification problem, HN.
I know a local bank that limits password lengths to exactly 7, and the contents of the passwords to ONLY DIGITS. I can't imagine how many users are going to just use their phone number.
Even though it won't happen I sincerely hope this latest round of unintended upgrades causes some severe and costly issues for end users. Microsoft deserves nothing but hate and backlash for trying to push Windows 10 with these incredibly scummy tactics.
If it was truly worth upgrading, they wouldn't need to trick and goad people with 'Free for a limited time!' and dark UI patterns.
I want to be able to do some basic stuff quickly without having to search for what I need to copy and paste into the CLI or read a bunch of docs. The gui should make things like converting between formats, cropping, stitching, etc straightforward.
Eschewing the traditional application architecture has made for both a terrible development experience and poor quality applications in general. The application lifecycle is convoluted with even the Android developers joking about how confusing it is. Everything about the model has made it far more difficult to port existing software to, and native development for me personally has been an absolute nightmare. No clean exit strategy for applications, half the methods in the lifecycle don't even get called, etc. I can't imagine the completely naive and oblivious thought process that led to the mess they created. Good thing Android is backed by Google though, so no matter how terrible it is it'll still be popular.
I agree. Android architecture is a mess. Activity life cycling is actually impossible. There are certain actions the OS takes that will cause crashes no matter how well architected the app is.
My main quibble with Android is that since everything is tied to the activities it is impossible to build an MVC style app. You are better off using the NDK or an engine. Then you can build your software correctly.
Do you mind expanding on some of your statements? Especially:
> Activity life cycling is actually impossible. There are certain actions the OS takes that will cause crashes no matter how well architected the app is.
I work on a very popular app in Latin America. That means we get to experience every single edge case in the eco system. My favorite quirk has been that for some reason I will never understand when an app goes into a full screen ad it can make your main activity eligible for GC. That means that you don't get any of your Activity life cycle events. Just a lone finalize and your app is gone. Then when the video ad is done you get a truly spectacular crash!
Sadly, I have a half dozen different ways activities have found to explode themselves. It makes me sad!
Sounds like the video ad is a new activity? Since it's full screen, your main activity is no longer visible so you should be seeing onPause and onStop fire. Are you saying you don't see them?
Also, I'd imagine video ads are also quite memory intensive, so if a low-RAM device is playing one I wouldn't be surprised if Android has to kill some processes (like your activity that was sent to the background) to make space.
Perhaps you should look into what these video ads are doing and what sort of resources they eat up?
I use the NDK a lot because you can kind of ignore the Android nonsense and structure your code properly. My approach is to have it build out the main activity then fire out into my app code. That code is beautifully MVC and for the most part ignores Activities, Fragments and Intents. For me it was faster to develop in than Android Java because I wasn't so strongly tied to the view code.
I can pull open inkscape and make an okay logo for an application in a few hours and have it meet all the criteria listed in that article. Its an icon. You aren't moving heaven and earth, you're just pulling verts around until you make something that people can click on to launch your app. I'm going to repeat an earlier comment I made on this because I've really come to hate the design/UI/UX 'image' in the last few years.
>Design is getting so pretentious and haughty. The icon design evolution video, the article littered with artistic buzzwords, all this song and dance for a circle in a squircle over a gradient. And the Layout, Hyperloop and Boomerang symbols are arguably even more useless and confusing than before.
Qt is basically unrivaled in this space in my opinion. If you really control your hardware and software, it seems like its easier for you to just comply with the LGPL requirements. You can find some other vendors for similar software with Google but they aren't as 'attractive' and 'responsive'. That being said I think IVI systems will start looking at web rendering soon if they haven't already. If the LGPL is a show stopper for you, you can always give CEF a shot to see if its fast enough (though I've always been confused about CEF because I thought it used WebKit which was LGPL)
Also depending on how complex your UI is going to be you can always take the crazy route and roll your own. If your scope is very specific and limited, it wouldn't be that bad.
Based on some quick research building CEF for the imx6 doesn't look trivial. Do you know of any devices (for sale) that do use Qt under the LGPL? Or in your experience does everyone get the commercial license?
