The reliance on a phone seems terrible, I would never install a banking application unless sufficiently threatened. I prefer our (Czech) more-or-less direct bank transfers, for which I don't need to leave my web browser.
It should also be noted that in general, Xlib can do a lot more than XCB with a /lot/ less effort and bugs, and has an actual documentation, tutorials, books.
Xlib certainly is quirky, in particular around error handling, though.
People just expect things to be integrated. Even Wi-Fi is, although it's probably typically an M.2 card. I have a <2000 computer that had both integrated audio and video, and it's kind-of become a norm.
Integrated sound cards are way more susceptive to interference, though, and the quality suffers a bit. They're merely good enough.
Also, people generally seem to use USB sound cards, as it removes even more room for interference (though my ASUS Xonar Essence STX sounds great already, unlike the integrated solution that transfers power rail and other noise).
> You actually want autolayout, so that different languages only need translations and otherwise don't need almost any extra work.
What kind of extra work DO they need? I can only think of RTL layouts but I don't remember whether win32 "dialogs" loaded from resources automatically mirror the layout for RTL languages.
> Linux has, I think, proved, that fixed window sizes are needless.
Desktop Linux is an unfixable dumpster fire UX-wise. Don't even get me started.
A serious problem with many open-source GUIs, but especially those on Linux, is that they're built backwards: you first write the code, then build the UI. Your UI ends up being shaped by the underlying implementation of the thing it controls. When in reality you want to do it the other way around: you'd formulate user requirements ("they need to be able to do X and Y"), you'd think through all possible scenarios that the UI must accommodate, you'd make a rough outline of what a UI satisfying all these requirements would look like, and only THEN would you start actually writing any code.
> These damn animations man... they're so fluid and springy and easy to use in SwiftUI, that it lures you into adding them everywhere.
The constant animations are what makes me dread and despise working with Apple software. Each time something moves for no good reason whatsoever, I die inside a little. Every few seconds.
> [...] the same animation was driving me nuts because I was switching spaces so often, that the animation was slowing me down
Exactly. Props to the author for making them possible to turn off. The operating system at large still has _tons_ of them that you can't get rid of, but it's the thought that counts.
> Reacting to keyboard events is still something I do outside of SwiftUI
SwiftUI is a nice idea in principle, what with being reactive, but I found that I cannot achieve anything worthwhile without piercing down into the lower layer of AppKit. And then I asked myself why do this clownery in the first place.
Ultimately, trying to learn Apple frameworks has made me love GTK+, because it's so beautiful and elegant in comparison (disregarding that it's currently deeply broken on macOS).
> SwiftUI is a nice idea in principle, what with being reactive
I want to like reactive, but between its inherent properties, how SwiftUI does it, and the fact I'm having to use VIPER as the architecture for the project…
…I don't like it, but I also don't know exactly where the issue is. And "not knowing where the real problem is" means I also can't add any productive suggestions for how to improve matters, to the very obvious annoyance of the iOS lead.
> I'm having to use VIPER as the architecture for the project…
This is your problem. VIPER is just a huge amount of worthless bureaucratic toil. It’s only useful if your only option to scale development is putting as many warm bodies in seats as possible and need to enforce mediocrity to keep things from going off the rails. It’s not great in general and particularly bad for SwiftUI.
This 100x. A VIPER codebase I inherited for some client work a few years ago was perhaps the most cumbersome and tedious codebase I’ve ever had to work with. Needless to say they missed their launch window and market opportunity.
This is one thing I like about Android. In developer settings you can make every UI animation twice as fast or even turn them off entirely. It's the first thing I do on every device I use.
I think animations are fine and even good as long as they're communicating something to the user (not just done for flare) and perhaps more critically, are non-blocking (e.g. the UI is still functional during the animation) which makes the ability to toggle off animations less necessary.
Switching spaces on macOS is one of the best examples of easy improvements. There's info being communicated (where the user is being swept away to, where the destination desktop sits in relation to the current one) but it should probably be sped up by at least 40% and not block user interaction so if there's a focused textfield at the destination desktop, the user can start typing mid-transition and no text will be lost.
Yeah, UI animations can be good. The vast majority are bad, and even the good ones are almost always too long. That's why it's nice to have a setting for them. Those macOS animations you mentioned have no settings to make them faster and they are infuriating.
On phones I usually speed animations up rather than turning them off entirely. But on the Pixel Watch the animations are so gratuitous and add so much friction to my use of the watch that I turn them off entirely.
I haven't tried a Pixel Watch, but on phones I find Android animations generally kind of awkward. They too often feel like they don't fully connect with what they're animating, if that makes sense, and the curves they're on are often odd. I could definitely see the appeal in turning them off.
What are your favorite parts of gtk+? I'm working on my own UI framework and trying to borrow myfavorite parts of the lot of them. Gtk+4 seems to have some decent stuff, but I've only dabbled with it and worked more with old school QT. I always liked the signals a / slots myself.
The Asciidoctor flavour of AsciiDoc doesn't have a specification. There is only a working group. The parsers are a mess composed of regular expressions.
There are in effect two different versions of AsciiDoc, because Asciidoctor people have appropriated the name while making their own changes to it and marking what they dislike as deprecated.
AsciiDoc cannot express all of DocBook, for example figures with multiple images.
While I despise Markdown, there isn't all that much to be a fanboy of. Just the syntax is overall saner.
Ah, DocBook //imageobjectco with something like calspair as well. I've been wanting it badly, but there's zero movement in the Asciidoctor group to try and tackle that beast.
With all due respect, and speaking as an amateur programmer, when it comes to lightweight markup, is there a better way to write a parser besides regular expressions? I suppose it's how the semantics are abstracted.
Asciidoc does get you conditionals and transclusion in the core spec, without needing to resort to extensions. This is what brought me over. That and the XML interoperability.
The Eclipse WG isn't published yet, but, in my opinion, it's a more stable surface to build on than the "many worlds" of Markdown.
Every time someone shows me a cool markdown trick, it requires me to pull something down from github and `npm-install` (or equivalent). But, well, that's kind of the point, isn't it? Markdown's ease of implementation allows a degree of glorious hackery that's just not possible otherwise. While Asciidoctor's great albatross - and its great asset - is Ruby . . which inevitably involves Opal at some point.
I think the most free-minded large models might be the Groks, but just slightly, as they have different biases. In sum, there's strength in diversity.