WinUI – The modern native UI platform of Windows
microsoft.github.io
microsoft.github.io
From a developer point of view that last point is very important. If your native app is not going to look or feel any different than an app built using Web technologies why limit your customer base to Windows users?
Sure, native apps are better at reducing resource consumption but if your app offers significant functionality users won’t mind if it uses some extra memory. This is the reason Microsoft’s own Teams and VS Code products were built using Web technology.
Another issue from a technical pov is that XAML, MVVM and 2-way data binding are outdated. MVVM introduced 2-way data binding to the world. Since then every JavaScript framework copied 2-way data binding including EmberJS and Angular. Today we know 2-way data binding is gimmicky and makes programs hard to debug. This is the reason React uses unidirectional data flow.
Not for me. I ended up just following the old way - on change handler to handle the changes in the form. It eliminated lot of issues/bugs.
"It is easy to end up in a state where you can't yourself explain how data flows through it. Even though both Angular and Ember have events and data bindings, data bindings feels so cool that people started tunneling events through data bindings. People are abusing two way data bindings to express something that is fundamentally an event. Ember 2.0 is moving away from two way data bindings as the primary method of communication to events. We added too much sugar around two-way data bindings and that led people to use two-way data bindings as an event bus."
It makes sense for simple apps that are mainly rendering and outputting information/data.
Writing a React that handles even simple forms is however a trip back to the early days of web, where you gotta handle your own DOM events. I'm unclear when repeating the same DOM handlers all over the place became "easier to debug"
https://github.com/Shopify/quilt/blob/master/packages/react-...
Uh no we don't. I've spoken to a lot of engineers who curse redux and the entire ecosystem around it. The reality is, 99% of apps don't need that kind of craziness. "time travel debugging" is a meme. I'm tired of it being highlighted as some insane victory. Over what exactly?
Information density took a huge hit in the later Windows versions and I find it incredibly frustrating to use. The first thing I always have to do is figure out how to open the old version of control panel so I can actually accomplish something.
Glad to know I'm not alone in these thoughts, thought maybe I was just being stubborn in adopting the new style.
Can you show me some "absolutely awesome" examples of Flat UI? Our sense of beauty and aesthetics comes from the physical world, which contains gradients, shadows, dimensions and so on. Simple geometric shapes can be elegant, but I haven't seen examples of Flat UI that is awesome as well as doesn't suffer from usability issues.
Is there any software more sophisticated than 'a 3x5 card with a pencil' which uses this user interface paradigm? I think any paradigm, no matter how confusing or clumsy, is sufficient for that case.
Two problems: (1) It takes a real and complex design effort, and (2) it's nearly guaranteed to be at odds with the "clean look" aesthetics.
I think it's the minimalist aesthetics that caused the fad of flat design and unidentifiable controls. It strives to make a page / form visually simple, thus hiding its real richness and the irreducible complexity stemming from it. In a misguided attempt to avoid cognitive overload it turns UIs into impenetrable puzzles.
There is a fundamental tension between "clean and simple" and "rich and comfortable". It's much easier to sell "clean and simple" and pretend that it's "intuitive" and does not take any learning. But once you've bought that, and want the power features, they are either not there at all, or are very well hidden ("have you tried triple-drag this to the right?").
Ideally there would be a switch between "beginner mode" and "pro mode", but there's little incentive form the market, because people are just used to put up with the limitations.
Since then, details were improved, but the overall concept has never felt natural or appealing for me. It always feels like something I have to work against. (And I usually do appreciate reasonable white space, distinctive typography, and clear geometry.)
BTW, It specifically mentions that WinUI supports React Native for Windows.
But I agree that having in native apps the UI patterns people are used to seeing in webapps is simpler for the majority of users.
UWP XAML emphasizes OneTime binding more than OneWay/TwoWay when you use the new static bindings (using x:Bind rather than Binding), it's been a source of frustration for some people coming from WPF
My guess is there was probably one design committee that decided that things needed to look different, because the "future is now", we can't remind people of older versions of windows because visually that isn't progress, and we can't be reminiscent of the "bad old days" when things crashed often.
Then after that committee makes it's decree, everybody who has control over their own little gui fiefdom each decides "nah.. that looks terrible and we aren't going to be cohesive, so lets do our own thing over here."
And so, everything looks and acts a little different. Since not everybody got on board with the change, the original committee digs in their heels and says, "Well it obviously doesn't work because not everybody is on board with OUR design."
It used to be that we could change the colors and themes of our UIs, in this case all of the way down to the OS level. Nowadays it's a major feature for a bit of software to introduce "dark" mode.
This "look-and-feel-as-branding" philosophy has now entered parts of the Linux community, as evidenced in this public letter to the GNOME community titled "Please don't theme our apps" asking Linux distributions to not apply custom themes to GNOME applications (https://stopthemingmy.app).
Personally I'm a major proponent of native GUI applications conforming to their platform's UI standards, and I'm also a proponent of users being able to theme their environments. In my opinion the purpose of personal computing is to empower the user. Users should be able to control their work environments and their workflows as they see fit. Unfortunately I feel that this philosophy of user empowerment has been slowly challenged, where the user experience is being controlled.
Often people don't want to maintain an old code path. Sometimes people get into that line of thinking without clear understanding of just how many people like what the old code path is doing for them and why. Sometimes they also over-estimate the maintenance cost of the old thing.
In the case of win8, there was a strong drive for "we're doing a tablet now", very little intuition about how their thing was going to be received in the market, and the company culture and talent pool was already markedly different from the one that produced their 1990s greatest hits, so it's not like they were automatically going to reproduce prior success.
Also notable that in vista and win7, turning on the classic look disables dwm.exe, the compositing engine, and some GPU-based optimizations.
The problem with Microsoft is that they “simply have no taste.”
Windows has always had their Windowish / Microsoftish smell to its design. Much like Linux, You could spot a linux desktop from 100 miles away. And everyone thought these were simple you could just copy it. Turns out there are trillions of small details that make it all coherent and beautiful.
You can say that about Apple today too. After all, in iOS7 they copied the Flat UI from Microsoft, including thin fonts, and buttons that don't look like buttons and so on. Although more recently they have removed thin fonts in their designs.
I know it feels a little harsh, but Jony without Steve is a Designer without Product Manager. Steve Jobs is great being an Editor and Product Executive.
I cant help but think Jony knew he was getting burn out without Steve. And he wanted to get those last design to be perfect before he left.
Windows and all the Linux desktop environments that copied Windows have so much more functionality than the brain-dead macOS that can't even get basic features like window management right.
Imagine thinking an OS that won't let you easily maximize or snap application windows is any good?
What's so difficult about clicking the green button (maximizing) or holding it (snapping)?
1. Open two apps, at least one of which supporting fullscreen.
2. Open three windows in the app that supports fullscreen.
3. Fullscreen one window.
4. Cmd-tab to the other app.
5. Cmd-tab back to the previous app.
If your window from step 3 was maximized (filling the screen in the same desktop space), you would return to that window, but instead you are now looking at some completely random other window that you were not interacting with at all.
For people who cmd-tab (and cmd-`) frequently to switch between apps, this is super jarring and not at all what we intended to do.
And I'm reminded by other posters that they changed it to full screening (which is also not maximizing), complete with a disorienting animation, ugh. Pretty happy being Mac free again.
It's supposed to be "smart", in a sense that it gives you the largest window size that it considers usable. But that's too subjective an assessment to enable it by default, and even more so to not make it configurable at all.
Still, that's a common reaction from people who use Windows. I've used both Mac and Windows on a near-daily basis for the past ~30 years. Both have spent roughly equal amounts of time as my dominant platform. My observation is that maximising is such a default behaviour on Windows that most apps seem to be developed with that mode of operation in mind. Whereas Mac apps tend to be developed without that assumption. This in turn influences how people use apps on these respective platforms.
I have a smaller vertical monitor next to my main monitor which I full-screen my code editor. It looked weird at first but nothing beats having oodles of vertical space, enough to convey entire blocks of code at a time. And even though it's a verticalised widescreen monitor and a comfortably large font, I still have enough width for almost 150 columns of monospaced text—plenty for my personal coding style.
Full-screening code editors on a large horizontal widescreen monitor tends to have no tangible benefit other than to conceal clutter behind a bunch of useless whitespace.
I run VSCode maximized on a 27" monitor, and the editor field is just about wide enough for 150 columns, with all this other stuff.
(Sadly my code editor of choice doesn't offer that feature.)
Annoyingly, even at 1440p, the code window gets crowded, if I'm using both the file browser and builtin database client. Luckily you can double-click the tab for the file you're on and everything tucks away nicely.
Though I did grow up obsessing over Windows, so you're right about that.
And for the record, having to hold option to maximize is bullshit. I rarely use fullscreen mode.
Dude, you're missing out. I love using a four-finger swipe on the magic trackpad to quickly jump my side monitor between various spaces: my full screen code editor, a space with two web browser windows (typically showing monitoring tools), and a black screen.
> even at 1440p, the code window gets crowded
I loathe customisation, preferring everything to be as generic and standard as possible, but one thing I have done for my own sanity is assign F16–F19 to hiding and showing sidebars in all the various apps which have them. Typically F16 for left bars, F18 for bottom bars, F19 for right bars.
I know the shortcuts on mac and I don't even use them. alt+tab on Windows and Command-Up on mac are the habits I've been able to remember
Think of it like Cmd-Tab for your side monitor.
The window management on macos is light years ahead of anything on Windows. Ever try to deal with full screen windows on either platform? The macos approach is a breeze where fullscreen windows get their own virtual desktop and window chorme, titlebar, dock, etc are managed by the OS consistently. Switching between fullscreen windows and regular windows is sane.
Meanwhile, the Windows approach to fullscreen windows is to just draw a borderless window on top of everything. A stupid approach that some linux desktops decided to copy for some reason.
> Imagine thinking an OS that won't let you easily maximize or snap application windows is any good?
Macos lets you maximize windows easily. Double Click on the titlebar works in most applications. Clicking on the maximize button makes any window a seamless fullscreen window in ways I wish a linux desktop could.
Yeah, snapping might not be baked into the OS. But there are 3rd party apps available for this so it is not that big of an issue.
The reason the macOS pushes full screen by default is because their idiotic UI design takes up way too much vertical space with the useless Dock that isn't even half as useful as the Taskbar, and the awful, ever-present global top menu bar.
Honestly, I don't full screen anything on Windows or Linux unless it's a movie that I'm watching, because I don't need to.
Three-finger swipe up. Click on the desktop most to the right.
So it's true. Mac users really are delusional.
Using macOS and its ecosystem was the most dictatorial and opinionated experience I've ever had.
Another advantage of the menu bar is, that you can always see which shortcut belongs to which action, because most items have a shortcut displayed next to them. On Linux and windows it is trial and error, or looking them up online.
Also it makes the windows look a lot less cluttered.
Shortcuts for menu items are normally shown in menus on Windows and Linux, right-aligned next to the label. For Windows, it's part of the platform UI design guidelines, and if you're using standard APIs to define your UI, any item with a shortcut assigned will render appropriately.
It might seem like an issue if you are coming from a tiling window management environment, but over time it becomes quite familiar and intuitive to use because of all the parallels with the physical world and how we interact with physical objects. I have tried the tiling window manager route, and it's more clumsy than anything imo.
You could design a VR environment that lets you walk around your virtual house, open your virtual front door, walk down your virtual driveway to your virtual mailbox, pull out virtual envelopes and open your virtual mail, but you'd just be replicating all the old real world cruft that doesn't matter to achieve your goal. What you really want is just to read some text in an email.
I had an older professor in college who still read and replied to all of his email via terminal, and he was multiples faster than those of use that used Gmail, but I remember thinking I'd never devote the time to learn to do things this way when the way I'm used to works just fine.
Apple has done a tremendous amount to make technology more approachable, and in doing so has brought millions into the digital age, but I do think the pendulum has swung a bit too far - a monitor isn't a desk, it's a monitor. Too much value is placed on "intuitiveness" these days, and while those real-world parallels might feel nice to interact with, there's a time to disavow ourselves of them to take full-advantage of what the technology can be.
Or after making it a three-key shortcut to take a fucking screenshot.
> "nah.. that looks terrible and we aren't going to be cohesive, so lets do our own thing over here."
I wish this were the case. Instead all Microsoft products have switched to the ugly Flat UI, including Word, PowerPoint, Excel, etc.
It's just that some idiot manager came up with the "unified experience" idea and shoved that shit onto desktop Windows without any time for polish.
Ironically I think pretty much anyone's first experience with metro was Windows 8 on PC, which was such a disaster that people wouldn't even give Windows phone a try because it had the same UI that they learned to hate. Not to say this is the reason Windows Phone failed, but probably one of the many factors.
has there been research done on whether these difficulties occur in all age groups? Because I can easily see this being an artifact of tradition.
People who don't use a lot of analog devices may be confused by a skeuomorphic interface, and may appreciate the simplicity of a flat design.
Here's what tobiasandtobias had to say about that in their blog:
Even 'digital natives' live in the physical world. We start learning how it works before we ever touch a computer, and even the most dedicated nerd spends more time interacting with physical objects than with digital interfaces. It doesn't take additional learning to know that an object casting a shadow on another is in front of that other, for example. Failing to leverage that existing knowledge is tantamount to shutting down whole swathes of users' brains.
(The blog is no longer online unfortunately.)
Every time I read of some new amazing framework like WinUI or SwiftWUI or whateverUI, I always stop and wonder: will applications written with this thing today ever run unaltered in 10+ years from now?
Microsoft has been doing an amazing job in these past 30+ years in keeping things working: stuff written on Windows 95 can still run without any particular issue on Windows 10. Sure, there's a bit of "cheating" here and there to keep the compatibility working but the bottom line is: there's retrocompatibility.
As an example: if a developer wants to use Win32 to write something on Windows, it's still possible and it _IS_ still supported, with APIs that basically didn't change for like... ever?
Apple seems to be on the far side of the spectrum: they have amazing technologies but - as a developer - I always feel I have an immense work to do just to keep up and allow my code to keep working as it used to.
So, the question for the community here is: how can we balance the "sugary" to make things as accessible and sustainable as possible with the "stability"?
At least that's been my experience: Plenty of OS X apps abandoned after each major update.
I don't have a single app that was abandoned. BBEdit, 1Password, Little Snitch, MailMate, Tweetbot, Typinator, Rocket, and many more are all still updated when need be. Key note is "need", stable apps do not need constant yearly updates.
In addition, you can say the same thing about Windows. Metro, UWP and previous attempts didn't go anywhere either, their MS Store is pretty much a flop. (Granted, MAS as well).
Linux...it's not bad but there are issues with various UI frameworks, stores, etc. GTK/QT, Flatpak, snap, etc.
Also, the original Overdrive Mac app. I believe they still don't have a replacement Mac app.
The official ReadItLater app, the service is now called Pocket btw.
That Caffeine app to prevent the laptop from sleeping.
iTunes
Adobe Fuse
Google Picasa
Some minor aspects of Dragthing can be replaced with Siracusa’s app Switchglass.
As for Overdrive, does Libby work on the Mac?
And since most of my pro audio apps also stopped working on OS X and the USB dongle works the same with Windows and Mac, I myself also abandoned OS X for productive work.
I wonder the same usually, but less when it's a fairly large/established framework from MS, exactly because of having Win32/COM/... in mind; they are known for many things but less for suddenly dropping backwards compatibility. We have 10+ years old WPF code which still does the same as it used to do and builds with the last IDE as it did with the first we used it on, and it doesn't look like it's going to stop functioning soon. But yes, it's not quite 30+, so only time will tell..
Data/Telemetry
This project collects usage data and sends
it to Microsoft to help improve our products
and services. See the privacy statement for
more details.
For more information on telemetry implementation
see the developer guide.
And I know you can opt out but I've done that and still seen dotnet make network requests on runs. Maybe it's essential for the functionality but I'm having a hard time trusting a company that puts telemetry in their SDK.
Which opens the question: Who else is doing this? I know JetBrains has some telemetry in their IDEs (although like I said IDEs are more justified I think and I haven't tested their opt-out). choosenim also recently asked me if I wanted to report anonymous usage data. What about npm? The Rust stuff? How much hidden telemetry is there inside developer tooling and what can we do against it?
It would be neat if there was some sort of database for this. Kinda like what Exodus Privacy[1] is doing for Android apps.
And when someone creates an open source product with this clause in the README right up front along with the option to opt-out, people get peeved about it?
I can understand if the norm is to NOT collect data. But since the world doesn't seem to work that way, despite what some techies would want (since all this tracking has been created by techies anyway), I think it's time to grow up and face the real world for what it is - avoid where we can, adapt in our own ways where we cannot. And try and not get peeved.
But apart from that, even if the world was really on fire in terms of privacy, it would still not be an excuse to shrug everything off and "give up already". You wouldn't sign off your rights and shut up just because everyone else does, right?
I agree, harassing developers for including telemetry in their programs is absolutely disgusting and not the right way to push privacy. And usually the best response to terms you don't like is to just not agree to them and not use the app.
But in this case, I think it's a bit far-fetched: The dotnet SDK (for instance) is not overly complex (as in: the CLI; crash reports are a different topic), has a nice public GitHub repo and is only used by developers who, if they don't like something, probably know how to file an issue on said GitHub repo. So why does it need telemetry? I don't know what's going on in the dotnet team and maybe there's a good reason behind this choice but from my POV it just seems like it's unnecessarily shutting people who disagree with it out of .NET. And I think this is kind of an injustice to .NET as well (since - and I can not stress this enough - it is really good!)
Alright, </rant>. I'm not angry but "popular apps" (let's just call it that) have largely become a minefield for me, so I just avoid most of them. It's kinda sad that developer tooling is now also shifting in that direction.
Similarly, NodeJS/NPM, LLVM (clang, lldb), GNU (gcc, ld, gdb, glibc), Java (OpenJDK), etc... none of them have any telemetry as far as I know. If they do have some, google isn't being helpful at finding out about it.
Even if disabled by default you get popups asking for turning it on.
Without feedback you can’t grow.
As another answer said: (for now) this is targeted at the enterprise.
Note to UI designers: nostalgia doesn't necessarily mean "good". I can be nostalgic for my grandmother's cabbage soup, doesn't mean I want a daily banquet of the stuff.
You think Microsoft would have learned that "modern" has the stench of death.
For instance, making changes in Settings feels... flat... I can't tell if something is loading or if my system is hanging or if nothing happened! I really don't like it.
The most intuitive setup, imho, is to apply the change immediately, but also materialize some sort of UNDO button to revert back.
(just have a good undo option)
Windows itself is an offender in that regard - e.g. the setting to select when updates are (and aren't) installed is a modal dialog that itself requires confirmation. And on top of that, it has two time pickers, each of which has separate scrolling columns for hours and minutes, but then you also have to press the "Confirm" button to actually apply changes after you scroll. And if you just click away to get back to the dialog, it 1) doesn't prompt to save changes, and 2) doesn't apply them.
In database terms, do you prefer explicit transactions or autocommit? For things that really matter, I want an explicit commit step.
- Apply changed immediately. - Provide indication that the change was applied (maybe pop a checkmark our for a second or two) - Provide an undo that at least revertes to the state when the dialog was opened, but ideally even be able to recent to snapshots from before previous changes. (So that if you close the dialog then decide you don't like it you can go back).
COMMIT is useful in databases because you have made a "permanent" change and for atomicity reasons. If you make undo effective and there is no concurrent access it is unnecessary.
My 3 applications are written in Qt/C++. Hopefully it is going to shield me from this, as it has from the previous changes.
They're still supported though, right? (WinForms, WPF, UWP.)
You can look at their community toolkit preview here if you just want to see some code: https://github.com/microsoft/Xaml-Controls-Gallery/tree/winu...
Even then, we won't know for a while as most devs aren't likely to switch on day one since it will have to be justified from current working stable codebase.
All of the screenshots are lowish resolution. In the second screenshot, the spacing on the icons is funny (more bottom margin than top). Blue on dark gray is hard to read, even for someone with young eyes like me (I cannot imagine my parents enjoying looking at that). In the first screenshot, the code isn't syntax highlighted (I also think the font is not monospace, which is just appalling).
Anyway. I installed it and just at the start i notice something i really dislike: they slide a panel of text and the sliding is slow (in terms of sliding speed, not performance) and done in a subpixel manner, making all the text blurry and unreadable until the sliding finishes.
Also i noticed a bug in the "AutomationProperties" demo (second one) - if i use the wheel to change the size (no indication about being able to do that btw, unlike spinboxes in Win32) and i also have the "page" scrolled, both the page is scrolled and the value is changes.
In general scrolling seems to be broken - if i use the wheel to scroll, the page scrolls normally until a code block with a horizontal scrollbar enters into view at which point scrolling only scrolls the code view horizontally. Now i might be wrong but i do not think the mouse wheel should scroll a widget horizontally (this is what the horizontal wheel scrolling - that is wheel tilting - is for) and even if it does, it should only be done when the widget is not inside a scrollable container. Because as it is right now, i have to move my pointer to a "safe" area outside the code box to keep scrolling the page. Also regardless of horizontal or vertical scrolling, IMO if you reach the end of the scrolled area in a widget that is itself inside a scrolling area, then the outer widget should continue scrolling.
Finally on scrolling, the scrollbars do not seem to respect the shift+scroll behavior (normally clicking on the tray above/below the scrollbar thumb moves a page up/down, but if you shift+click it moves the thumb at the position you clicked like middle clicking in most X11 toolkits - however this doesn't happen in the demo).
Another thing (not a bug), i mentioned above that there isn't any indicator like a Win32 spinbox, but in the NumberBox demo there is a spinbox - and if you focus it, the spin buttons become enormous wasting almost half of the spinbox's editable area. Also - and this is a bug - if you click just left of the spin buttons before they become enormous, the big ones appear and then disappear immediately and the spinbox loses focus.
Funny enough, this is the "compact" configuration for the spinbox, although i guess it makes sense since the "inline" one (the alternative configuration) is even bigger. But at least it doesn't change size nor loses focus arbitrarily. Ideally it should be the "compact" one without changing size or focus unless you used touch input. Windows can differentiate between mouse and touch input, why doesn't Microsoft take advantage of this?
Another mouse wheel issue, now with the RadialGradientBrush sample (i'm testing those in succession)... the sliders do not respond to mouse wheel events meaning i can't change them with the wheel. However i'm not sure if it s the slider not understanding the wheel events or something else because the wheel behavior is weird in the panel there: if i click somewhere in the page outside of any panel (e.g. at the "Paints an area... blahblah" text at the top) and use the wheel over the MappingMode combo box, the values in the box change. But if instead of the MappingMode combo box i use the wheel over the SpreadMethod (that is, i click on the text at the top and then use the wheel over the SpreadMethod as the immediate next thing), then the page scrolls. However if i click on the SpreadMethod combo box and then use the wheel on it, the values in the combo box change (as expected) instead of scrolling. Note that i didn't have to click the MappingMode combo box for it to use the wheel. Also the slider does not change with the wheel regardless of me clicking it or not.
Another visual glitch, in the TabView demo: if you close the tabs and they remaining tabs do not fill the TabView line, the tabs line doesn't fill the entire width but gets shrunk to seemlingly random sizes. Note that if you close all but one tab but then you create a new one, the tabs line does fill the entire width. Also, if you close all tabs and open a new tab, none of the tabs are active and the content area remains empty. This might be intentional, but i doubt it since you can't "select no tabs".
Another bit of weirdness, with the TeachingTip demo: clicking the "Show Teaching Tip" button shows that teaching tip (i guess this is the new name for tooltip?) normally, but if you try to close it, it doesn't respond to mouse events (click, hover, anything) if it is at the area at the top of the window where the titlebar would be (and also that area doesn't seem to respect the system settings for its size - i have changed the setting in the registry to use a smaller area because i find the default titlebar size huge, but this demo ignores that setting). This means that i can only click the "X" button to close it from the middle and below. Even more weird, there is a small patch of pixels at the top left side of the button that accept mouse input... perhaps there is a hardcoded area at the top right of the window in case a window has all titlebar buttons visible (minimize, maximize, close and context help)?
A minor visual issue, the "three-state" AppBarToggleButton uses a background color shade to indicate its state. However the third state (neither checked nor unchecked) looks 99% the same on my PC where i use a gray "accent". Using an image editor i see the checked state uses an RGB value of 63, 63, 63 and the in-between state uses an RGB value of 57, 57, 57. On my PC they practically look the same.
At this point i lost interest, pretty much every single demo has some issues (except the AppBarButton, but if you can't even get a single rectangle to respond to clicks i'm not sure why you'd even bother working on UIs). I noticed a glitch in the menu bar demo (e.g. if i scroll the page and press space, the file menu opens... outside of the window) but i do not feel like investigating more or trying anything else.
Yeah, sure, i guess this demo did its job perfectly fine: it showed me why i'm good with sticking with Win32 :-P
My comapny blocks the Microsoft Store, so we would not be able to explore it. And I guess we are not the only ones.
As for the framework itself, it seems needlessly complicated to get started. The XAML based frameworks use a whole different paradigm from web development or classical RAD tools.
And it's hard to take Microsoft UI frameworks seriously when they hardly use them outside of the core Windows apps. VS Code, Teams, even the VS installer are all Electron apps.
that's the problem. How can you have faith in their frameworks if they don't use them themselves?
I used to use Ion3 on a tiny Fujitsu Lifebook P1510D to divide the screen into quadrants containing things like a terminal (mostly used for IRC), Pidgin, a browser, and whatever videos I might be watching.
I guess it makes sense if you have a bunch of apps you're predominantly reading from instead of interacting with but in my experience those are predominantly terminal UIs anyways.
If I'm on a machine without a tiling wm I generally using everything maximized and alt-tab like you say. But that's still usually an extra click after opening an application.
I also love tmux, but I have a coworker that doesn't see the point.
So, having options is nice. I want to be able to work the way I want. I also want you and my coworker to be able to work your way.
I've never really given it a fair shot.
You must be a C++ programmer [1].
[1] https://stackoverflow.com/questions/25224958/dereference-a-p...
Of which as a desktop app developer it is harder and more complicated to test.
I have to test if my GUI app works properly before someone on whatever Linux distro complains that it doesn't work on either of their GNOME, KDE, Xfce, Cinnamon, LXDE or Mate setup or worse yet, if the problem is found deeper in the distro stack which could be the user's incompatible configuration or if it is the distro itself.
Windows and macOS have a default desktop environment and windowing manager that I can test against which is very predictable and stable unlike the complexity of the Linux desktop stack and its distros.
Seriously, for a normal, user-facing app, all you should care about is at the level of the framework you used.
I see. So you're saying it's the "app developers" fault when a Linux user changes any system component of the Linux desktop stack i.e. display manager or desktop environment and the app fails to start or crashes because it only runs on GNOME, KDE or its X11 or Wayland-specific. It is actually an entire distro problem. When someone decides to make the switch to full blown Wayland or some other configuration, all bets and guarantees are off on stability and they start finding alternatives for other apps because the apps they tried don't work on their setup. [0] There's a reason why they say "UNSUPPORTED".
For example, Firefox couldn't start on SwayWM and the number of issues and combinations of people not running it on their distro setup was mounting. [1]. Such issues are easy to test on Windows and macOS but very difficult in Linux distros, resorting to trail through the whole desktop stack to find the issue as demonstrated in this ticket [2]. Such issues like this still exist in many Linux apps not just Firefox.
> Seriously, for a normal, user-facing app, all you should care about is at the level of the framework you used.
Like I said, no guarantees are made if the user ends up changing system components or old frameworks and the app crashes on their setup when it is specifically made to work on a default install of XYZ distro. The point is that the freedom to mix and match subsystem components makes it complicated to test your app or trace a bug which could at worst be a regression in one part of a Linux subsystem component, which is why some see it as a blessing and a curse here.
[0] https://www.swalladge.net/archives/2019/10/14/are-we-wayland...
Basically if you don't try to be super fancy you make it other people's problem if your app crashes.
1. You compare dev version of linux compositor to stable versions of the other OSes
If the app fails to start or crashes when it runs under one WM or another, then following happens:
- app is using something/talking to something/assumes something in a way it is not supposed to -> bug in the app
- the WM or compositor doesn't take some message or poking in a way it is supposed to take -> bug in the WM or compositor.
The example you posted is sway, during the time it was in development. I stress again, it was in development, it was not supposed to be bug-free, and no distro shipped it. Applications do crash under dev version of macOS and Windows too; you just don't see that because the respective bug trackers are not public, and the respective dev builds of the os are not very public either. In Linux, you have access, but then you have to break something, with the implicit understanding that when that happens, you get to keep the broken pieces.
Nobody sane would consider that supporting development versions of any package on any OS is something you are supposed to do.
Related: Switching to Wayland is mostly non-issue. If your app previously used X11, it will continue run using X11 under Xwayland. If anything, the Wayland developers made it too seamless. Unlike Apple, which made XDarwin eye-sore, so the users would be aware and demand updates.
2. You compare different layers in the stacks
In Windows, you have to use MS provided UI toolkit (whether Win32 or UWP, doesn't matter). In macOS, you have to use Cocoa. Neither of these vendors would allow you to talk directly to their respective compositor, no way around it.
In Linux, just because you can - everything is transparent - doesn't mean you should. If you want to play at the same level as you do on Windows/macOS, use it at the same level: use a toolkit, that will abstract the same things for you, as the vendor supplied frameworks on the other OSes do. Gtk, Qt, Electron, doesn't matter, they do the heavy lifting for you. Do not talk to compositor directly - then you do not even have to care, whether it is X11 or Wayland, the toolkit will arrange it for you.
By inserting yourself on the different level in the stack, you assume on yourself solving all the problems that are being solved there. If you want add your workload, you are welcome, but then be honest at least to yourself and admit, that it is easily avoidable self-inflicted pain.
---
I understand, that there is no system-wide SDK with a given ABI, and that can be frustrating sometimes. I understand, that ABIs that distributions provide are semi-stable. There are solutions for that:
1. Pick a distribution you will support. Blackmagic supports RHEL/CentOS, nothing else. GoG supports Ubuntu. If it runs anywhere else, cool, but you are on your own. Similarly, you can even support several of them, but when someone decides to do X, where X breaks other apps, he is on his own. When the user is competent of breaking something on his own, surely he is competent of fixing it too. You don't support users who hex-edited their system libraries in Windows either.
2. Use flatpak. You choose the runtime, you choose when your app switches to newer runtime. Most runtimes have defined support periods and document, what can change during that support period (i.e. freedesktop one allows for security updates and updated OpenGL drivers). This has the advantage, that nobody is going to try using their self-compiled libraries as a replacement for the runtime-supplied ones.
I'll take "reasons it still isn't the year of the Linux Desktop" for $1000 Alex.
For GoG, they run very well everywhere; they just explicitly support Ubuntu.
The point was, that WMs are not even a factor in the support matrix. They either manage windows or don't, but your app doesn't care, it just paints its window. How the user places it on the screen is his problem.
When there are problems, I think it's equally useful to consider them as logistical and social problems among community members (developers, distro maintainers, package maintainers, and end users) in managing that shared control and responsibility. Some examples:
• End users who are used to navigating the alternative world of mostly-uniform platforms may not understand that not everything is up to the developer, which can misdirect their frustrations (and their bug reports).
• By the same token, advanced users and smalltime contributors form a crucial layer of these ecosystems wherever they are healthy, by not only running up against integration issues themselves so that they can be identified, but by figuring out how and where to report them and how to mediate information between the authors of applications and people who work to integrate them into their operating systems (distros). Developers who want wide support are faced with the task of seeking or building those relationships somehow (or just rolling the dice).
• Developers of new pieces of software may find themselves faced with a social bootstrapping problem: they need people using their software, or at least excited about it, in order to generate the interest in their software required to get someone working on integrating it with a particular distro.
• Users who change out major system components in a distro (like the init system or the display server) take on (or create a need for) a new role in doing so: they become integrators of the system just like that advanced layer of users I mentioned, or distro maintainers. A clearer understanding of that might ease a lot of frustration for users and developers about things ‘not working’. (This is reflected in Gentoo's self-description as a ‘meta-distribution’.)
I'd like to see more of this acknowledged explicitly, maybe by two official standards of support: original development target and explicitly co-supported. A lot of F/OSS projects sort of already do this by pointing to the program's inclusion in various distro repositories on their official pages, sometimes with a word of warning about especially experimental cases (i.e., packaged but not co-supported).
Supporting more distros will always require more work from developers, but such work doesn't always have to be intensive development work. It can just be a working relationship between a developer and a motivated user of some distro who the developer agrees is more or less competent to figure out the technical boundaries of integration problems and work with them in a reasonable way to solve them equitably. I know it _can_ happen because I see it play out all the time when it comes to packaging software for my favorite Linux distro¹, which because of the distro's weirdness can require some hints or even minor source code changes from application developers. When the motivations are communicated clearly, application developers are often willing to incorporate minor compatibility changes for the sake of some boutique distro's compatibility, with very little fuss.
Idk what really can be done to communicate this to users, or how to better manage the sort of clusters of related configurations that exist on meta-distros like Arch or Gentoo, but both seem in principle doable to me.
—
One of the things I appreciate about the Unix ecosystem is the wide amount of choice of window managers and the broad support for themability. This means that users are less affected in Linux by current design fads. For example, the reason we have MATE and Cinnamon is because some people didn't like the changes made in GNOME 3. Now there are at least four well-supported GTK-based desktops: GNOME, XFCE, MATE, and Cinnamon.
If Apple or Microsoft makes a UI change and I don't like it, I generally have to grin and bear it unless I switch platforms. If KDE, GNOME, Windowmaker, or another desktop environment/window manager makes a UI change that I don't like, then there are a lot of options I have to change things to my liking. That's the power of the Unix desktop ecosystem.
I tried Windows 10 with WSL 2 for a few months, but the experience is far from being good. WSL is slow and the new Windows terminal needs a lot of polish.
Windows 10 it self is a subpar experience. The UI in general is a mess, all from explorer to control panel and settings. You often find windows and text that look awful on high dpi displays. And I'm not talking about third party apps, I'm talking about Windows itself and some MS apps like Skype. Windows also is not as responsive as I would like. Hitting the windows key to quickly open an app, which is the most repeated action by me, is sluggish.
The only reason I was using Windows was because my Thinkpad had issues with the microphone and speakers on Linux, but now that Fedora 32 is out with a new kernel, hardware works like a charm, so good byE Windows!
Writing something in Win32 will ensure it will run in 10 years from now and chances are it'll also run 20 years from now. As a user you have a very high chance of finding applications that work regardless of when they were made. As a developer you can focus on your tasks without wasting time to "upgrade" to the latest fad (Microsoft does release new toolkits, but the old stuff keep working and Win32 is the stablest of them all). And your knowledge will still be perfectly valid, no need to waste time learning how to do the exact same stuff in a different way.
Writing something in Gtk3 (the current stable one) will ensure... well, once Gtk4 is stable, Gtk3 will be deprecated and the one to avoid. Qt can't even remain stable in the long term if they wanted (though they do not seem to want to - after all Qt is middleware targeted to application developers, not a platform component regardless if KDE pretends that it is) because of C++. As a user you are limited in the applications you can find and have to keep around all sorts of different toolkits - which wouldn't be that great of an issue (hard disk space is cheap) if those toolkits were still supported and compiled. Except the only distribution i'm aware that provides -say- Gtk1 is Slackware and Qt4 is already on its way out by most distributions. Gtk2 will soon follow (and perhaps some distributions will already have it dropped). As a developer you have to chase after the brokenness that Gtk and Qt developers introduce (though TBF Qt seems a bit better here, probably because they are getting paid by selling Qt licenses and they cant annoy the developers using Qt too much) and waste time "keeping up" just so that your existing application will keep working.
Above X there aren't any stable UI APIs (unless you count Athena but that hasn't received any updates since the 80s - even the updates 3rd parties made during the 90s to improve its look a bit never became part of the "official" distribution). And people want to get rid of X's stability too with Wayland.
https://www.qt.io/blog/2018/05/24/porting-from-qt-1-0
> So, what did we learn? It did not take that much effort to port tutorial 14 from Qt 1.0 to Qt 5.11. It probably took me longer to write this blog post.
Qt 1 was released in 1995, Qt 5 has been released in 2012 (and did not break ABI / API since then). I think it's not unreasonable to spend a few days every 7 years to update your app to the new Qt major version... especially when the hardware evolves and you have to update to follow that anyways (touch screens, hidpi, permission requesting).
An application written in 1995 against the Qt1 API will not work on Qt5 because both the API and the ABI has been broken. A user who wants to run such an application (not necessarily released in 1995, Qt1 was in use into the very early 2000s, even though Qt2 was already out) is not able to do so. A developer who wants to modify such an application has to become familiar with both Qt1 and Qt5.
In contrast an application written in 1995 that uses Win32 will run out of the box in Windows 10 without any changes. A user can run such an application perfectly fine (and personally i have several applications like that that i'm using) and a developer who wants to work with the code will be able to focus on the application itself (since chances are he already learned Win32 at the past if he worked in any other Win32 program). As an example, some time ago Microsoft released the source code of File Manager which dates back to ~1990 - i was able to navigate that code easily and added the ability to filter a window's contents using multiple wildcards.
(note that in both cases i am assuming the applications do not do anything stupid that happened to work at the time but doesn't work nowadays)
An application may not even be maintained any more. Or it may be maintained but the user(s) might dislike the changes (e.g. i like Paint Shop Pro 7, released in 2000, but i never liked the UI overhaul that PSP8 got and nowadays after Corel bought the software they have severely... well... gimped it :-P - similarly i do not like the changes introduced in Blender 2.8 so i stick with 2.79 and i know a very talented artist who still uses Photoshop 5 - not CS5, plain 5).
Those few days are also very optimistic and really depend a lot on the software in question. AFAIK Lazarus, for example, took ages to update form Qt4 to Qt5 (same story, but much worse due to all the breakage Gtk introduced, with Gtk3 which still isn't really usable). And as i wrote above, most of the time, they are a waste of time. Adding support for touch screens and hidpi (not sure what you have in mind with permission requesting, so i ignore that) doesn't require breaking your API nor your ABI.
EDIT: BTW, it isn't impossible to have Windows-like backwards compatibility on Linux, here is a screenshot[0] from a toolkit i used to work on at the past showing the same binary working in both 32bit Red Hat from 1997 and 64bit Debian from 2017 - essentially 20 years of backwards binary compatibility (the colors are off because i didn't bother to implement indexed color support). It is just that the toolkit maintainers do not care, but it is perfectly possible to do that if you care.
Maybe art stuff is kinda special here?
On the ‘disk space is cheap’ side of things, packaging strategies like those of Nix and Guix can go a long way toward solving the human-level problem here; I can install packages that have long been removed from NixOS on current NixOS systems just by pointing to the old copies of the package definitions. That means that if I want a Qt3 application and Qt3 has been removed, I can install it just by pointing my package manager to a copy of the package definitions from way back when that application and its toolkit dependencies were still included. App containerization stuff like Flatpak also seems like another good way to mitigate this issue without committing distros to eternal maintenance of each major version of each GUI toolkit.
What do you think? Is the future for backwards compatibility of end-user applications on Linux brighter than its past despite the persistence of the API-and ABI-level churn problem?
For example your old program doesn't receive new features through the shared libraries it uses - a simple example i gave elsewhere was old Windows applications receiving the ability to input emoji in recent updates to Windows 10 even though emoji wasn't a thing (outside Japan at least) when most of them were written.
It also doesn't solve the issue at all from the developer's side. A developer who comes later to an application still has to find old development libraries and make sure they work on his modern system and/or update all the code (perhaps without even knowing how the original program worked). And developers who maintain an application still have to waste time and resources in keeping up (see Xfce as an example).
FLOSS doesn't really solve this - if anything your average (big) distro repository is full of programs using several different "versions" of toolkits and other APIs. At "best" (from the distro maintainers perspective, not necessarily form the users' perspective) the distro drops applications. It does help with having the potential of fixing things, but that is all that there is to it - the actual effort (and thus time) needed largely depends on how much things have broken.
As a personal example, a few years ago i decided to try one of the very first web browsers made, MidasWWW. I downloaded the code and tried to compile it. But of course it didn't compile out of the box, having the source wasn't much of a help here. Now, i am a bit persistent, so i decided to fix it and after a while i ended up with this:
https://i.imgur.com/W37vhBW.png
This is an example of what i mentioned in my comments here: the browser was written in Motif and Motif has generally been API and ABI stable over the years (it'd be nice if its theming support was improved - without breaking backwards compatibility of course - as i think that would make it more popular among developers) so i didn't had to do almost anything. But at the same time MidasWWW was written in some old Unix workstation that had a modified version of Motif which was incompatible with the mainline Motif - the result is the panel at the top being inside the content area instead of on top of it. I didn't knew about that, i actually realized after i made that shot :-P and i couldn't fix it because i am not really familiar with Motif and especially not familiar with the modified version that the workstation used - but i'd need to at least know something from both to figure out what changes i need to make.
And see, that was just a little breaking incompatibility between versions. Having access to the source and Motif being backwards compatible helped to get it compiling, but didn't help with having it work properly because there was a breaking change somewhere in between. And since the original developers aren't around, it was up to me alone to figure things out - to do it properly, i'd have to spend considerable time. Time that i didn't want to bother spending, so i didn't :-P
I'm sorry but your definition of "works fine" is likely very uncommon. Old applications won't even have @2x pixmaps which leads to everything being a blurry upscaled mess.
If it were that easy we wouldn't be getting regular requests to port MFC applications to Qt at the company I work at ;)
Old applications will certainly not support "@2x pixmaps" (though many do support hidpi monitors if you use the "Override high DPI scaling behavior" to let the application do it - however the majority do not, which is why this isn't the default) but despite being blurred they'll still work (and that is assuming you are using a hidpi monitor, in practice nowadays hidpi monitors are still a very tiny minority so chances are you wont even notice it). Though FWIW i personally do not use hidpi monitors and one of the reasons is that (the other is that i play games a lot and i do not feel the slightly higher crispiness is worth the massively reduced performance).
However breaking the ABI wont work at all, blurry or not.
(also note that Windows 10 will not use bilinear filtering for integer scaling so in -e.g.- 4K monitors running at 200% scaling you shouldn't get blurriness)
https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dp...
https://devblogs.microsoft.com/cppblog/mfc-applications-now-... (Unfortunately the images are still broken after the blog migration)
If it's a high-DPI screen, then it will be upscaled to look the same as it did on the old low-res screen, so it's not any worse than it has been before. It's only a "blurry mess" when contrasted to an app with high-res text and graphics, making use of that new screen.
So it won't magically become a high-DPI app, of course, but it will still run perfectly fine, if your baseline is "runs the same as it always did". High-DPI support is a new feature, so it stands to reason that it requires app to be updated.
For example my laptop has a 1080p monitor - not exactly hidpi, but the monitor is small enough for Windows to suggest a 150% scale. But this makes anything that doesn't support scaling look blurry (and also break several games, but that is another matter) so i prefer to use 100% even though it makes things a bit harder to see.
This, so much.
And they will likely work on Linux and macOS through Wine, too!
Sadly the Wine GUI controls, while they work, always felt off to me and have multiple minor issues. But at least they work. I think a big reason is that despite libwine being usable as a general purpose toolkit for (ELF) Linux application, it never saw much use as that so these issues were never paid much attention.
It would be great if someone could provide a new renderer based on Vulkan, for instance.
By the way, Vulkan is "supported" on macOS thorough MoltenVK which is provided by Khronos under a permissive license (although they don't develop it).
I guess the other chunk of this is the development model seems to prevent that sort of fragmentation within these larger products. The broader app ecosystem is a separate story, and I realize that's most of what you're bothered by, but having that core system be consistently modern is a big thing on its own. And to get there it seems like you kind of have to sacrifice one for the other.
And IMO if anything, the reason you get all those different behaviors is exactly because things break. If Gtk3 was backwards compatible with Gtk2 (in a fantasy world where the Gtk developers did learn from the mistakes of Gtk1 to Gtk2 breakage and designed their Gtk2 APIs to avoid it in the future) then all Gtk2 applications would gain, if not all, then at least some of the new functionality in Gtk3. Programs that were abandoned would still get some of the new stuff while programs that are under development would be able to keep using whatever they are using and upgrade in their own pace only the minor differences that were needed for the new functionality.
Yet I would much rather use the "old" style Control Panel than the new Settings page.
(btw, just in case... you did click "More details" at the bottom left side, right? Otherwise it looks more barebones than the Windows 3.1 task manager :-P)
In the same time, Task Manager has gained nice charts, it's begun to display stats on network and disk as well as CPU usage, and it's gained a simplified view that my mother can use to close a crashing program. I've been spectacularly impressed with the task manager changes - simultaneously making it easy for low skill users and adding advances features making it unnecessary for me to install Process Explorer on every machine I use.
The thing the GP highlights though, shows it's never really "gradual."
Just by being observant, you can pretty much date the last time any particular component of Windows was touched. Windows 10 has dialogs, controls, UI themes, HIG sensibilities from all of Windows 3, 95, 98, XP, Vista, 8, and 10 mixed together. It feels very haphazard.
this has been going on for about 8 years with no end in sight. I wouldn't call that gradual.
This might be of questionable value to "real" developers but the business value of this type of power is immense and gets things done that would be unaffordable to do today.
The lesson is to not jump onto the new fancy thing, as Microsoft might just drop it in a year or two, and it will all have been wasted effort.
Just use good old and tested. Or portable (e.g. wx).
What Microsoft should do is snapshot a recent revision of CSS and make that the basis for the style and layout of XML or JSON-based structured documents, and then extend it where appropriate. Like it or not, eventually all layout systems are all going to become alike in the end (be it a desktop GUI system, web-page HTML+CSS, WPF/Jupiter/XAML, Qt, Apple's constraint-based layout system, etc) - it feels like a waste of resources to build yet another layout system (or in this case: trying to squeeze more life out of XAML and whatever WPF's latest descendant is called). Remember that using CSS does not mean having to use a web-browser engine, or using JavaScript, or even HTML - CSS was designed from the start to be agnostic to the types of documents and environments it's used in.
I don't see how HTML/CSS does anything any better, XAML is verbose, but the tooling takes care of most of it.
>I don't see how HTML/CSS does anything any better, XAML is verbose, but the tooling takes care of most of it.
CSS's modules for layout are far more advanced than WPF/XAML/WinUI. Never-mind the more brain-dead aspects of WPF/XAML/UWP like `<border>`, WinUI only has <Canvas> (absolutely positioned elements), <StackPanel> (similar to CSS's flex-box, or normal block layout), and <Grid> (which is much closer to HTML <table> than CSS `display: grid;` in terms of capabilities) - all other layout systems have to be done by hand - which requires a deep understanding of WPF/XAML's layout system internals - and who wants to invest the time in that when there's still uncertainty about the supported lifespan of WinUI?
I've noticed that Microsoft only commits to supporting a UI framework when at least one of their major products relies on it (which explains why WinJS became irrelevant, _fast_, while MFC and WPF are clearly here to stay (I note that Microsoft has only one major product relying on WPF: Visual Studio - literally everything else uses some non-public UI platform like DirectUI (Office) or MFC.
It’s a far cry from the Longhorn demos of 2003 that showed the entire Windows UI been made with WPF, and Explorer itself hosting third-party applications’ WPF components.
Take the calculator application included with Windows 10. It takes time to load. Earlier it was instantaneous. It takes up way more screen real estate too. Maybe the new design helped them to make this app easier to use on touch devices, but from my perspective, in all other respects it is going backwards.
And yeah it's ridiculous that we have incredible CPUs compared to what I started with yet simple apps take way more time to load with no benefit for me (argueably even looking worse). But that's the state of things and I don't see it changing - well, maybe the next calculator will be in Electron.
i dare you to find your sound device's control panel in win10
I wonder why UI designers stopped trying to leverage this principle.
Seriously can you do a Visual Studio or Photoshop UI with this?
I hate the fisher price mode for the control panels on Win10 (which I guess is made using WinUI). It’s so much wasteful of space and half the options are missing. I wish there was a button to get rid of these entirely.
The macOS UI is still fine for me though.
It's irritating, why can't they keep things simple?
macOS still looks good on my 1440x900 2013 MacBook Air, and I like how the Cinnamon desktop looks on my ThinkPad T430; I use Linux Mint on that ThinkPad now.
(I've damaged my original 1600x900 TN panel and the quoted price for material was more than the third-party IPS, even without the work. The third party panel is much nicer).
Also related: macOS was originally optimized for 72 dpi; retina at @2x is 144 dpi. Windows (and also Linux DEs) optimized for 96 dpi, 200% is 192 dpi - which is much bigger jump and they look atrocious if the display is in the 140-180 dpi range. That's why macOS can look nice at ~WQHD displays that MBPs ship with, and Windows laptops needs at least 3200x1600 look nice at 200%.
Open up Task Manager and go to Details tab and show the column Threads (right click on column header and pick Select columns).
choco install oldcalc
However the person I was replying to has a 20 year old app. I'm going to guess they still have users on Windows 8, 7, maybe even Vista and XP. Using the WinUI API, even a bit of it, will leave those users in the lurch.
Can anyone offer any insight on this? If memory serves, WPF is backed by DirectX. How can they hope to beat that performance? Performance improvements over its MVVM? Modern UI toolkits tend to add high-level abstractions and degrade performance (e.g. by relying on web technologies), rather than enhance it.
In the framework layer, typical UI updates are faster because the WinUI data binding system uses code-generation rather than the reflection-like runtime binding system that WPF has.
WinUI also includes the rather incredible Windows.UI.Composition API’s, with things like ExpressionAnimation that enable lots of cool animations (like parallax, sticky header, or cursor-relative) at a stable 60 FPS.
Disclosure: I work at Microsoft on the Windows team.
> code-generation rather than the reflection-like runtime binding system that WPF has
That's a good move. If a convenient abstraction can be implemented in a way that 'compiles out', it ideally should be implemented that way. Does this enable more compile-time checks?
It also adds the ability to bind to functions, which can eliminate a lot of ViewModel boilerplate for computed properties.
> Can anyone offer any insight on this?
Unmatched doesn't mean good or bad, it just means it's not the same, and implies it's good.
If it were a real claim, they would have some numbers and an example of old vs new or new vs web or compare it to Android UI or something else known to be bad. And then we could pick apart the code examples and have a good time.
I was told, oh, you are an idiot, you need to be using XAML / WPF etc etc. I tried - the stuff looks works, much more complicated to develop and does LESS!
Even Visual Basic (remember that?) made GUI development trivial I thought compared to these new improved approaches.
Just found these links, 2nd one especially looks interesting.
https://blog.stevensanderson.com/2019/11/01/exploring-lighte...
https://blog.stevensanderson.com/2019/11/18/2019-11-18-webwi...
Not cool putting adverts on your Github pages like that
The reason is because humans have two eyes, which give us the ability to distinguish depth easily (meaning low cognitive load - our brains are optimized to process this).
In a UI, whenever there are more that two dimensions, depth should be shown (simulated, technically) because with our two eyes we cannot discern depth easily on a flat surface.
Obviously you can go overboard. For instance, in HN, flat makes sense. But in a windowing system, shadows(1) are essential to show depth. Otherwise it increases the cognitive load required to distinguish between the foreground and background.
(1) - you could use blurring (or other techniques) as well, I'm just using shadow as a simple example.
A little bit later this is confirmed when the show you hello world (https://docs.microsoft.com/en-us/windows/uwp/get-started/cre...) which instantly creates a mess of json, xml and c# for you so you don't realize how ridiculously complicated it all is.
For reference, here's hello world with GTK (https://developer.gnome.org/gtk-tutorial/stable/c39.html), a single c file and single line instruction to compile it. Here's one for Qt (https://doc.qt.io/archives/3.3/tutorial1-01.html). Show me a WinUI equivalent of those 2 pages and I'll be more impressed than I am by a slick marketing page.
>Fortunately, the charging one has been solved now that we've all standardized on mini-USB. Or is it micro-USB? Shit.
Between this, MSIX, containerization, etc the fat app landscape could be pretty good. Too bad all my vendors who are still releasing fat apps will never modernize and all the new vendors are web-only.
Microsoft is just making UWP similar to what Google is making with AndroidX, detaching the technology from the OS version.
Frozen is usually a good thing.
> Microsoft is just making UWP similar to what Google is making with AndroidX, detaching the technology from the OS version.
... and from users also. Will they get a lawsuit from Google for copying their UI as they got from Apple ? I think not because the UI is so bad that they will be ashamed to go to court with something like this.
What did Microsoft copied from Android?!?
If anything, Material 1.0 is heavily based on Metro.
It is also hard to get bug fixes without updates.
When Vista emerged as Longhorn's reboot, all the low level .NET stuff was redone in COM.
Since then all new APIs have been to large extent based on COM.
And what many seems to not yet put on their brain, UWP is the new COM.
Looking forward how Windows will look like now that it was officially communicated that Windows 10X is also coming to desktops and laptps, with its sandbox model for 100% of all userspace.
For a case study of interest for newer APIs, see also Windows RT.
Some people are still running critical business on Windows XP, yet the world moves on.
So Win32 was there, ISVs just were not allowed to recompile their apps for the ARM target. They were expected to port them to Modern API. Which of course, they didn't.
...separated off in a virtual machine connected over RDP. That's the plan in Windows X at least: https://www.youtube.com/watch?v=ztrmrIlgbIc
They say that the VM and the remote desktop connection are "optimized" but also that UWP/Modern apps will be faster and better for battery life, so it doesn't sound like a great future for win32.
And honestly, I'm a bit tired of the arbitrary computing distinctions between what gets to be a real computer and what doesn't.
What else did you want them to do? Continue adding features to long deprecated APIs?
Yes. It isn't like deprecating APIs is forced on them by some otherworldly power, they decide to do that and they can also decide to not do that. They are in full control of their technology, they can do whatever they want.
This picture summarizes it well - https://github.com/microsoft/microsoft-ui-xaml/raw/master/do...
So intead of a screwdriver, a wrench or a hex key you have now a hammer.
So essentially, it is not a new UI. Just a new version of an old one.
(consider e.g. WinForms was also ported from .NET Framework to .NET Core. That is also not counted here ;))
The UWP has everything except a GUI.
> So essentially, it is not a UI.
fixed itl
> (consider e.g. WinForms was also ported from .NET Framework to .NET Core. That is also not counted here ;))
So everyday a new framework. How many days will pass until UWP will be obsolete ?
And there're tons of more missing features like that. Did anyone try that UI with just a keyboard?
- they share one tech for their browser and UI
- they rip the benefit of their work (and the community work) on electron
- it opens the door to sharing one instance (or at least main libs) between different apps using this engine, solving the 'electron spawn one engine per app' problem
Also, I find the UWP monochrome UI style extremely confusing and difficult to use. I don't know why it is to different from the Office 2019 UI, which I find usable.
I'm going to stick my fingers in my ears and keep trudging along with Win32, because it will never die. Trying to kill it would be the monumentally dumb, and I don't think Microsoft is that brain-dead.
I can't tell if you're joking or not, but this seems very sensible to me, because it could offer great performance, and it's easy to create bindings from almost any language to C.
> WinUI 3 is the next version of the WinUI framework, shipping later this year.
There's no publication date on the page. That makes it very difficult to know the year that's being referred to. Is it this year, or some past year?
It's like Microsoft documentation team doesn't have developer mindset in mind.
The article listed several languages but omitted F#. So I also wonder about the F# story for WinUI.
In 1995, Marc Andreesen said "Netscape will soon reduce Windows to a poorly debugged set of device drivers", but I guess that turned out to be Google instead.
"Fragmentation is Why Linux Hasn’t Succeeded on Desktop: Linus Torvalds"
Developers flocking to WSL in 6..5..4..
Linux dead in 3..2..1..
> Developers flocking to WSL in 6..5..4.. Maybe some, sure.
> Linux dead in 3..2..1.. What? Linux on the server won't see any change. Linux on the desktop, maybe, but I doubt most people using Linux on the desktop are going to even consider switching because Windows has a new UI framework.
The only big advantage that I see is one UI framework for Windows and multiple different ones for Linux.
Oh God please no. I don't need or want every application wrapped in a browser engine.
> Oh God please no. I don't need or want every application wrapped in a browser engine.
Why not ? Dont't you like those funny little creatures called worms ?
Remember Visual Basic ?
Also I don`t get the hate against C++/CLI and C++/CX.
Apparently everyone else is allowed to have language extensions on their C and C++ compilers, only Microsoft not.
C++/CX on the other hand only exists because Windows Runtime Components, while based on COM, is still a superset with new features that couldn’t be supported with C++98 and MSVC lacked the necessary C++11/17 features to implement it without needing compiler extensions.
Syntax highlighting and Intellisense being absent for MIDL 3 does indeed cause annoyance, however.
Actually my only complaint is the downgrade in tooling experience in name of some ISO purity that I don't care about, and other compiler vendors also do anyway.
For the time being I don't plan to adopt C++/WinRT until the tooling experience catches up with C++/CX.
Anyway it has been replaced by C++17 compliant C++/WinRT library.