But yeah at least a few of those caveats remain. Although keyboard navigation and font rendering have quite a bit of support.
Comparing this to (something like) WPF, you create XAML files, with either or combination of ViewModels and back-end code to "bind" and can get complicated quickly. I guess the only exception to this is if you have commited to WPF non-stop for many months. However, with IM interfaces, its easy to get going (imo)
It often isn't a secret: https://github.com/ocornut/imgui/wiki/Software-using-dear-im...
[0] https://github.com/tildearrow/furnace
> proper keyboard support
- French Keyboard and Backend SDL2 - Several keys are not checkable with IsKeyDown
- Wrong ImGuiKey keydown indexes reported from Win32 backend for some keys when using UK keyboard with UK keyboard layout
There are also 2 issues with IME:
- Marked Text / SDL_TEXTEDITING Event / IME Composition support
- Backspace handling by text widget in default Windows IME environment.
Same on the Mac: If you want to build a Mac application, your best bet will be AppKit or SwiftUI and using system controls. And when the OS updates your application will either update with it, or need only minor tweaks and a rebuild to look good.
There are exceptions, for very rich dense UI, for UIs that need to be cross-platform, but if you're writing a Windows app, it should look and feel like a Windows app.
Even Microsoft struggles with that.
That’s not exceptional at all. That’s completely normal requirements that are probably in the majority.
Does Microsoft themselves build their apps this way?
You need consistency in the icons, layouts and concepts, but you don't need every widget to look exactly the same on every platform.
With the exception of games try to use the native GUI. It’s the best choice most of the time.
Is your app as large and important as the OS of the device (Chrome/facebook/etc...) you should probably have similar language across devices.
Is your app very large but not that large? (Slack/teams come to mind) I think you can go either way.
If you are smaller than that (hint: you are) then you should comply with the design language of the platform, even if that means somewhat large changes such as moving buttons from the left to the right. The likelihood that users are constantly using your app on a iphone and android is really low.
I’d still like to see them try to match a little, but they’re specialized enough I get that may be a better path.
Chrome? Facebook? Slack? Teams? No.
I’m not saying things need to look like MyFirstWin32App built with VB6 in 20 minutes.
But use the system controls and conventions. Custom colors and layouts can be fine. But if you want to make your own UI toolkit then make your own OS too and leave my computer alone.
No app is more important than the OS, and certainly not Facebook (which has no business being an app in the first place). I made a choice when I got the OS, and I like developers respecting it and not chase the fad of the day with poor approximations of the native widgets (text fields that do not support standard shortcuts, buttons that do not behave as they should, labels that do not support accessibility features, the list could go on). Even huge apps like Photoshop or Office get this wrong everywhere.
I definitely agree on the default (use the native toolkit), but there are no applications big enough to get their own behaviour. Open Source or hobby applications get a pass if the UI is a bit wonky, but that’s about it.
I'm not sure anyone could really answer this question considering how fast Microsoft's various silos pinball between UI conventions. All of them are (I would hope) based on various iterations of their own internal tooling, but looking from Windows 7 to 8, 10, and then 11, you get such stark differences in UI language that you feel like you're looking at competing products.
That being said, I would personally very much prefer apps that are built to mimic the system they are a part of. One of the worst sins of that one, IMO, being iTunes on Windows which has always been and continues to be a flaming dumpster fire for a number of reasons, but most especially it's UI. It is a Mac app that is parked in Windows. It looks like a Mac app, it operates like a Mac app, it's UI conventions are that of the Mac, with the one major difference being they stuffed the window controls in the window in an incredibly slapdash way to account for Windows not having the system bar.
But yeah, for any marketing people here, I have not once nor will I ever give a single molecule of a shit about your brand identity. Make your software good. Ideally make it mesh with the system it's in. I couldn't fucking care less what color everything is.
Gone are the days of my friend accidentally having his volume cranked when he inserted the Red Alert 2 disc, not knowing it would blast out "WARINING! Military Software Detected!"
> Documentation is poor.
The documentation was absolutely maddening.. Half the time the Apple docs referred to a previous version. “Do this thing in XCode” often included screenshots of UIs that don’t exist in the current version of XCode. Examples I found on Stackoverflow or random blogs were usually no longer applicable.
It felt like magic when it worked, all those VStack HStack nestings, but the annoyance of finding my way there made me seriously doubt whether I’d build a big app with SwifUI, especially if I wasn’t working alone.
> It felt like magic when it worked, all those VStack HStack nestings
EDIT
> made me seriously doubt whether I’d build a big app with SwiftUI
Today I was making a list of reasons/excuses for using Material Design on Mac… which I guess would make some people mad, but it might work for an enterprise product.
That said I did do a fair bit of my own theming. The Flutter Material widgets are actually pretty customizable and I'm not a big fan of vanilla Material.
I’m not in a position to give anyone advice, but I’d love to find SwiftUI but cross-platform and usable from anything other than XCode (well maybe not Ed…) and native GUI and a pony.
For my product I need to support Mac, Windows and eventually iOS/iPadOS. For prototypes iOS is enough. I don’t mind learning new languages for this, but ideally there would be some advantage in knowing the language itself. I’ve been looking at lots of frameworks over the past month.
The most tempting thing so far is Flutter, but I have nagging doubts: because it’s not native UI, I worry about that being a no-go for some large customer down the road, and also about alienating power users. I looked at React Native but it’s not very good for desktop yet as far as I could tell (and the demo app from the documentation doesn’t work, which is a bad sign). Which is too bad because I was impressed with Expo, if I just needed phones I’d probably use that. I looked at Avalonia but it has the opposite problem.
Today I’m looking at Tauri for the Nth time: at least I could improve my Rust, and it seems to have momentum. Doing the UI in a web view is kinda sad, though, after trying SwiftUI.
Just building multiple apps is not realistic, I’m a solo dev and want to get this to market in my lifetime, and it only makes sense if I have both Mac and Windows.
Very happy to hear recommendations from people who have done this!
I'm not convinced many users care that much about this though. They spend most of their day using apps that don't use native controls and I think they're all pretty used to it by now.
I prototyped a bunch of different desktop toolkits and I think that today Flutter is by far the most polished and mature. I've had overall a very positive experience using it for my music app:
The threat of Google canceling it is real though. I suppose if that happens I'll switch to Tauri or just give up on Windows and Android and do SwiftUI. My experiences with SwiftUI to this point have not been very positive though.
Kotlin Multiplatform might also be an option at some point but it doesn't seem that close today. Unfortunately it seems like none of the os vendors are making their desktop APIs a priority these days.
Yeah the Google risk... seems like they came out strong in support of Flutter at their last dev conference, but at the same time it does _not_ look like they're using it for their main apps.
And yes I’d feel more confident in Flutter if Google was dogfooding it a lot more.
> If you really want native look and feel then really your only choice is to use the native toolkits.
Do you need to ship any supporting files separately, along with the app?
And is .NET 4.8 or higher already on Windows PCs?
With .NET 9 right around the corner, how far behind the legacy stack is only increases.
.NET > 5 will never be installed out of the box on Windows PCs. The trade offs to that concession however are: cross-platform support, better container support, easier side-by-side installs support ("portable" installs). .NET > 7 can do an admirable job AOT compiling single-file applications. For a GUI app you probably aren't going to easily get that single-file < 40MBs yet today, but it's going to be truly self-contained and generally don't need a lot of specific OSes or things installed at the OS level. Each recent version of .NET has been working to improve its single-file publishing and there may be advances to come.
The blogger sounds like they put up a bunch of arbitrary constraints that in normal circumstances wouldn't even be issues.
In the process it's those arbitrary whimsical choices that reject the very obvious choices along with any happy path.
For example, it's baffling that there are already a few FLOSS forks of Qt out there, but the blogger failed to cover them. If the author likes Qt so much, those would supposedly be the obvious choices. But no.
Once again, you are left out of options if you go out of your way to avoid each and any option.
In that case, any Qt fork would force him to also comply with the GPL, and supply the source code of his project.
The LGPL is working as intended.
What the LGPL requires is that the end user be able to take the source code for the LGPL part, modify it, recompile it, and then replace the functionality in your binary provided by that part with their new part.
Obviously with dynamic linking this is almist trivial, the end user replaces the so or DLL and done.
With normal static linking, it's only a bit harder. If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part.
This is super clever, I love it! Does any software actually do this?
> or distribute object files for recompilation
Do you need to ship it alongside or produce it on request or link to where they can fetch it? It's not like you need to ship source code alongside either for GPL binaries.
Does this also mean that one could put most of the closed source part into a DLL, make a shell executable that is open source and statically link LGPL code into the latter? This then would allow modifications to the LGPL code to be put in just by having the closed source DLL.
I am not a lawyer.
You might even be able to use partial linking (ld -r) to ship a single .o file instead of a bunch of them.
It's not a problem.
Microsoft have utterly screwed the pooch on getting their .NET GUI story straight.
As someone currently involved in switching our app from MFC, I really want to like MFC, but Microsoft's absolutely addled management of the whole thing is making it really difficult.
No one burned with WinRT history since Windows 8, is ever touching WinUI, unless they are Microsoft employees on WinDev, or companies with sunken costs trying to keep their products around.
Compare Microsoft to OpenGL. Boromir says "one does not simply change the OpenGL API..." Microsoft does not have nor ever had OpenGL level of API with their UI frameworks. I guess you could say WPF is maturity in age only but doesn't represent conceptual maturity.
With the differences, you basically throw away all the knowledge of WPF to restart in WinUI, and with poor documentation. The documentation is there, i.e. the "what" but the docs should be primarily "the why and how"; how to map WPF concepts to WinUI3, which is arguably the more critical documentation to provide, and currently pitifully poorly documented.
Doubly so because it would help indicate a measure of feature equivalence; does WinUI 3 currently represent feature equivalence to WPF? Has XAML Behaviors been integrated as a member of the API?
In 1999, I built a completely custom Win32 GUI for a (brandable) chat application - that was the product the company I worked for was selling.
Pure C and C++. It was a 32-bit app, not 64 bits. And we felt bad for it being 250KB single executable (skin included in resource section) and not “150KB or less” as was our initial target. But making it accessible and fully skinnable/themable/l10n/i18n did add quite a bit which we hadn’t realized when thinking 150KB was realistic. But it’s not like we resorted to any crazy tricks; that was just the stripped linker output.
It was still a reasonable download at the dominant dial up internet at the time (28.8Kbps IIRC)
Sure, modern tools add a lot of cruft that you’d have to work hard to reduce, but 40MB. Oh man.
It is perfectly fine to build a 150KB or less executable today. But then OP decided they don't want to write paint functions for custom GUI and insist on finding a library to do so, I guess that's not what you did in 1999, right?
So, because pervasive theming/branding was a hard requirement, and i18n a softer one (every skin has to only support one locale), i had to abandon FLTK. But FLTK did spoil me by providing seamless flicker free double buffering out of the box, which I insisted on implementing in our gui.
For those of you who don’t remember - Win32 flickered badly on almost all screen updates, window resizes, etc — I think that was generally true of most apps until 2010 or so. FLTK was essentially the only GUI toolkit at the time (1999) that had no flicker out of the box.
Given that it’s windows, it might still run today, so it likely is still possible
I still use Winamp, and essentially in its 2.x mode.
Implicit (for me anyway) in the title is that you are talking about vanilla GUI apps. Writing vanilla Windows GUI Apps is trivial and there are a bunch of tools that handle this extremely well. The article covers many of them but chooses to disqualify them for reasons.
Then we have ImGui as the tool of choice, but now this is qualified as only for "simple apps". Really? After all the fuss about constraints not being met? A bit of cognitive dissonance here I think.
More complex functionality things can get difficult but often even these are handled depending on the tools.
For vanilla dev the clear winner in terms of productivity has to be WinForms. Or if you can live with the clunky IDE - Lazarus. (You're allowed to replace with your own favorites.)
The real challenge is not writing GUI apps for windows, but rather is in writing cross platform apps.
I'd add "for free because I'm too cheap to buy a license for a toolkit that does what I want".
fact that you must ship the app Unpackaged is particularly strange.
Well that's the killer right there. I too think it's way too painful to write Windows UI, especially if you want to stay away from Electron (which you should in almost all cases), but refusing to pay money for good software is going to severely hamper your goals in 99% of cases.
Is this really still true though? VS Code and Slack are all quite polished and give me no issues as a user. Not sure what else I'd consider to build something similar.
I mean, you do have the unreasonable bundle size, but other than that you can make really good looking applications using the same tools you can use to make web sites for both desktop and mobile.
I want my disk space for large medias, not for a desktop app
Specifically, the requirement for completely custom GUI styling without writing his own render functions means it’s really a task of selecting easy, customizable GUI libraries rather than generic GUI work.
The requirements to be self-contained executables and under a 40MB limit also rule out a lot of options. The author admits that Qt could have met these requirements but the open-source licensing part wasn’t compatible with his goals and he didn’t want to pay for a license.
If you relax the requirements to tolerate some dependencies, allow larger download sizes, or to simply use built-in Windows GUI controls the situation is very different.
For writing a lightweight, completely custom GUI with no external dependencies and permissive licensing I could have guessed ImGui would be the answer before I started reading.