[HN Gopher] Writing GUI apps for Windows is painful
___________________________________________________________________
Writing GUI apps for Windows is painful
Author : wild_pointer
Score : 439 points
Date : 2024-06-30 18:53 UTC (1 days ago)
(HTM) web link (tulach.cc)
(TXT) w3m dump (tulach.cc)
| api wrote:
| Writing GUI apps is painful period, and it's become more so not
| less in the last two decades.
|
| Go back in an emulator some time and try Visual Studio or even
| old Borland from the 1990s. Point, click, add code, set style,
| and the result was not bad at all. The whole UI looked consistent
| too with uniform controls, shortcuts, etc.
|
| Today UI apps use 100X more memory, are slower, and are harder to
| use with little to show for it in terms of improved
| functionality. The whole desktop is a disaster of conflicting
| designs and accessibility or uniformity are practically gone.
|
| Mobile is kind of shocking too. Here was a chance to dump cruft
| from desktop and do things better but the result really is just
| as much of a pain in the arse if not more. Consistency is a
| little better but the developer experience is awful and of course
| unlike desktop you really can't develop on the actual device.
| That adds another layer of shit.
| Aurornis wrote:
| > Today UI apps use 100X more memory,
|
| Larger memory footprints aren't just from the GUI. There is a
| lot more functionality to deal with everywhere. Just handling
| modern security, encryption, and certificate checking stack can
| take up more space than entire executables from the early 90s.
|
| I also have literally 100X more RAM now.
|
| > are slower,
|
| Im fairly certain everyone who says this has simply forgotten
| how slow mechanical hard drives were. I occasionally have to
| pull out a very old laptop, hope that it still boots, and do
| something on it. Everything is so painfully slow in ways I
| forgot about. It's refreshing to return to my modern PC.
|
| > and are harder to use with little to show for it in terms of
| improved functionality.
|
| If you don't think modern apps have more functionality, I don't
| know what to tell you.
| beart wrote:
| > Im fairly certain everyone who says this has simply
| forgotten how slow mechanical hard drives were.
|
| Absolutely, but I would go even further with this. I can't
| prove it, but I would bet a lot of money that Windows 10+ has
| made using a spinning disk even slower. I would guess
| optimizations around disk access were entirely different in
| the XP era compared to now, when it is assumed everyone has
| an SSD.
|
| Anyway, I had an old laptop that ran like absolutely dog
| shit. I put an SSD into it and it magically became usable
| again.
| Closi wrote:
| I assume OP means slower on like-for-like hardware, rather
| than slower when run on a PC from the 90s, but to be fair the
| WinForms/WPF component of old GUI's was very fast even on
| legacy hardware.
| kirubakaran wrote:
| Your profile doesn't list your email, so I'm posting
| here... is this the paper you were looking for?
| https://depts.washington.edu/acelab/proj/dollar/index.html
| Your original post for context:
| https://news.ycombinator.com/item?id=26152600
| Closi wrote:
| It was!! That's absolutely amazing, what a surprise after
| all these years :)
|
| Many thanks for hunting me down in some comments!
| kirubakaran wrote:
| Awesome, I'm so happy to hear that!
| wiseowise wrote:
| > There is a lot more functionality to deal with everywhere.
| Just handling modern security, encryption, and certificate
| checking stack can take up more space than entire executables
| from the early 90s.
|
| What does this have to do with bloated GUIs?
|
| > Im fairly certain everyone who says this has simply
| forgotten how slow mechanical hard drives were. I
| occasionally have to pull out a very old laptop, hope that it
| still boots, and do something on it. Everything is so
| painfully slow in ways I forgot about. It's refreshing to
| return to my modern PC.
|
| I remember 98/XP running circles on mechanical harddrives
| compared to modern PCs on ultra fast SSDs. The fact that
| despite thousand times faster hardware we have _slower_
| performance is disgusting.
|
| > If you don't think modern apps have more functionality, I
| don't know what to tell you.
|
| Care to provide an example what modern applications have that
| older ones lack? Except for always--on connection and
| artificial bullshit imposed by modern OSs.
| MrMember wrote:
| Say what you will about VB6 but it was stupid simple to get GUI
| apps up and running.
| lylejantzi3rd wrote:
| It was stupid simple to get _simple_ GUI apps up and running.
| More complicated apps were impossible. But, I think that 's
| exactly what's missing in the Desktop GUI market right now.
| Webapps are incredibly easy to start apps with. You only need
| to know a few things and you can pick up the rest later as
| your app gets more complex. Modern desktop GUI systems are
| incredibly complicated, in comparison, just to open the
| window, let alone put text on the screen.
| api wrote:
| Later versions of Visual Studio with custom controls and
| other abstractions made fairly complex GUIs entirely doable
| and still pretty fast to build.
|
| Then they shit canned everything for Xaml around the same
| time the whole industry abandoned any kind of WYSIWYG or
| rapid development technology.
| popcalc wrote:
| >As a fellow European, I do not have air conditioning.
|
| Is anything stopping the author from buying a heat pump?
| tjoff wrote:
| Usually, living in an apartment.
| bpfrh wrote:
| Depending on if he lives in a apartment some country/cities
| have laws against doing any work in the appartment that impacts
| the outside without permission from the house owner.
|
| E.g. you can buy a heatpump but you can't drill the hole in the
| outer wall.
|
| In germany and austria most if not all windows also either open
| fully to one side or basically bend inwards so you can't
| install the ac units you install directly into the windows[1].
|
| [1]https://external-
| content.duckduckgo.com/iu/?u=https%3A%2F%2F...
|
| edit: qualified the law statement
| mdorazio wrote:
| Are portable AC units not available in Europe? They are
| inefficient but can sit inside next to the window and only
| require that you partially block off a window opening.
| gibsonpil wrote:
| I don't know what landlords are like in European countries,
| but some landlords in America forbid people from connecting
| any kind of AC exhaust port to a window.
| bpfrh wrote:
| It's funny that in this case the law now protects you.
|
| Generally anything you do indoor that falls under normal
| usage(painting walls, hanging furniture with big
| screws,etc.) is ok without approval, at least in my
| country/city(austria) and the land lord can't deny any of
| this and is not even required to be notified.
|
| As you would have an open window and a not so noise
| machine running this would be ok, but energy efficiency
| is quite bad and you lose the benefits of the thermal
| insulation of your building.
| ranger_danger wrote:
| Can you name one place where this is an enforceable rule?
| throwaway2037 wrote:
| Yeah, the GP comment is classic HN. Wildly vague, with no
| supporting evidence. The planning rules in the US are
| _fractally_ complex compared to "Europe".
| asmor wrote:
| Power isn't cheap, and inefficient is an understatement. In
| the heatwave last week in Germany I managed to get ours to
| cool a tiny bedroom from 30 to maybe 26 degrees Celsius.
|
| Doesn't help that in new construction outer walls are
| usually very well insulated, and inner walls and floors
| aren't (by design; 70% of total heating cost is evenly
| split too), so you're working against your neighbors too.
| We have some stupidly complex building standards often
| driven by industry lobbying (which also makes building
| expensive), but installing a mini split hasn't made it on
| the list.
| bpfrh wrote:
| They are but not as efficient and so most people don't
| bother(that I know of).
| Ciantic wrote:
| Works just fine, I have 8000 BTU and it cools a living
| room very efficiently. I need it about one or two weeks
| per year in Finland. I can't imagine anybody working from
| home without one, even as north as Finland. Although we
| Finns are probably least used to heat so even 27 celsius
| is unbearable.
|
| The only thing one needs is a window-sized cardboard with
| a round hole and blanket if your target room has no door.
| I just looked at prices and 10000BTU seemed to be ~350
| euros.
| Paradigma11 wrote:
| I bought a portable split system for 2400 EUR. Works
| pretty well since I have shutters and a balcony, I put
| the external part outside the window, pull down the
| shutters and seal the lower part of the window around the
| pipe with some stuff. Doesn't use lots of power if I cool
| to 26C. Well, today we had 34C outside, so it had to work
| a lot.
| throwaway2037 wrote:
| 2400 EUR? Cripes, that is expensive. Do you mind to share
| the model?
| Paradigma11 wrote:
| Sure thing:
| https://www.amazon.de/-/en/gp/product/B07YZ5XT92/ Maybe
| it was a bit less, 2200 with shipping. I do have a top
| floor apartment looking south, so I get a constant 30C+
| in summer, without any cooling at night.
| coolgoose wrote:
| They are available
| whstl wrote:
| They definitely exist, and are very cheap. I got one for
| 200, gave away to a friend when I moved out of an attic
| apartment. They have a window-attachment accessory that
| makes it easy to attach to those European windows.
|
| The real reason most of us don't have AC is because it's
| hot for a very short period. Last year it definitely wasn't
| too hot for me to warrant having one. This year so far, it
| was, for a week: we had about 30degC (86degF) last week,
| but next week my mobile phone promises it's gonna be 20degC
| (68degF) maximum, which does not need AC. Maybe that will
| change, though.
| ranger_danger wrote:
| Swamp coolers are cheap and don't need a window or drain.
| gibsonpil wrote:
| It can be hard to justify the cost of installing and
| maintaining any form of household cooling in colder areas of
| Europe. Additionally a lot of apartment buildings don't have
| them, and most landlords probably wouldn't appreciate a tenant
| installing one without permission. Evidently heatwaves are
| becoming common enough now that most people should probably
| keep a window AC unit ready in case of emergencies though.
| cladopa wrote:
| As an European from Spain, in south European countries air
| conditioners are essential(Greece, Spain, South Italy, South
| Spain, inner Portugal). But in other countries or places it is
| not really necessary(north of Spain, France, UK, Germany).
|
| Some days of Summer it is hot there, and they are not prepared
| for that like people of the South of Italy or Spain, and there
| is chaos.
|
| It is like when it snows heavily in Madrid:
| https://en.wikipedia.org/wiki/Storm_Filomena In places like
| Austria or Switzerland it would be routine. They are prepared
| and it would be not a big deal, but in Madrid it stopped
| everything for two weeks.
| userbinator wrote:
| He also says it's 32C, which is slightly less than 90F.
|
| Interestingly, some people would describe that temperature as
| only "warm". I recently watched a video of a machinist working
| in his shop (southern US) saying that it was 94 and "a little
| warm".
| kosolam wrote:
| How about gtk?
| talldayo wrote:
| I love GTK, but compiling it on non-native platforms is
| torture. If you're lucky enough to get a build environment
| working, compilation can take hours just to yield a horribly
| buggy and slow GUI.
|
| I really wish GTK worked better cross-platform, but I mostly
| use it for Linux-only stuff. It's not humane to make Windows
| and Mac users suffer through it, unfortunately.
| ho_schi wrote:
| _MSYS2_. And copy over prebuilt dependencies. And while we
| say _C++_ , I suggest always to use _Meson_ as build tool.
| Which allows you to use WrapDB (built in dependency-manager)
| aside from available native libraries and own local sources.
|
| MSYS2: https://www.msys2.org
|
| Meson: https://mesonbuild.com
|
| The problem about Windows is, that Microsoft adds new APIs
| repeatingly and doesn't care much about the previous ones.
| While on Linux we've Gtk1, Gtk2, Gtk3 and Gtk4.
|
| And while people _complain_ about deprecations and changes
| they actually mean ,,API changes require work to use the new
| major. But these people keep maintaining it. And provide
| upgrade paths to enhanced versions? I'm in!".
|
| HiDPI, Wayland, new Widgets, new renderers and a scene-graph.
|
| PS: If you need to keep it small and simple and address
| professional (power) users I suggest a TUI with the venerable
| _ncurses_. Or _notcurses_.
|
| Notcurses: https://github.com/dankamongmen/notcurses.
|
| Demo of Ncurses (For the lulz):
| https://www.youtube.com/watch?v=dcjkezf1ARY
| tored wrote:
| Tested Geany Editor on Windows the other day, it uses GTK,
| great editor but horribly slow on Windows, just scrolling a
| small file (less than 100 lines) was sluggish.
| redox99 wrote:
| GTK programs look very out of place in Windows.
| markasoftware wrote:
| More accurately:
|
| + "portable" (single exe with no automatic unzipping of dlls or
| anything)
|
| + commercial and unwilling to redistribute compiled object files
| (which together with the "portable" requirement, means no LGPL)
|
| + dark mode
|
| Windows GUI apps is painful. Drop any one of these requirements
| and there are good established options.
|
| Specifically I think most "portable" applications use win32
| because, usually, portable => small, simple application where
| functionality is more important than dark mode or other styling
| ability.
| CyberDildonics wrote:
| Anyone can compile a static binary with FLTK and have the
| binary size start under 100KB.
| criddell wrote:
| You can do that with straight win32 as well. Steve Gibson has
| a bunch of utilities and most of them are pretty tiny. His
| DNS Benchmark is one of the larger utilities at 169k.
| CyberDildonics wrote:
| I like win32 and you can get a lot smaller with win32, but
| there are a lot of things missing. FLTK has a lot of
| components, component layouts, fonts, file system stuff,
| networking, audio, an openGL context, image loading and
| it's cross platform.
| throwaway2037 wrote:
| I'm confused. What is "missing" from Win32? To be clear,
| I count _all_ base DLLs included with Windows a "Win32".
| One thing I can think of from your list: component
| layouts. Resizable windows with component layout is awful
| in Win32.
| triedthat wrote:
| I've used FLTK for an application. It relies heavily on
| opaque pointers and convention. The compiler will not help
| you out if you mess up.
|
| https://github.com/gammasoft71/Examples_FLTK/blob/c6f630eaa3.
| ..
| moal wrote:
| You can use dynamic_cast instead of reinterpret_cast. If
| the pointer isn't correct it would return null. A better
| solution is to subclass the widget, store a function
| pointer for the callback which takes the same class instead
| of an Fl_Widget, and call that in the callback:
| https://github.com/MoAlyousef/FLMH This uses a
| std::function for the captures but you can use a function
| pointer as well.
| fuzztester wrote:
| Or with Lazarus, I've tested it a year or so back. Under
| 50KB, IIRC, for a CLI Hello world app, though, not a GUI one.
| Similar size with a D app.
| chipdart wrote:
| > Windows GUI apps is painful. Drop any one of these
| requirements and there are good established options.
|
| The "portable" one is not a hard requirement. It's a whimsical
| self-imposed constraint, which makes as much sense as
| complaining that you can't stand on your right foot on
| Tuesdays. All installer toolkits released in over two decades
| support deploying arbitrary components. Is this not a solved
| problem?
|
| WinUI3 supports dark mode/theming out of the box along with
| fully customizable styling. It's as free as it gets. It's also
| Microsoft's official GUI framework for Windows. But the blogger
| rejects it because... Because what?
| dfox wrote:
| Well I remember one project where having the app small and
| portable or at least self-contained was a hard requirement.
| It involved an embedded device (ridiculously complex and
| over-engineered embedded device) that used customized USB
| flash sticks for user authentication, data transfer and
| firmware updates and configuration. The partitioning scheme
| of the update/configuration scheme meant that I had only
| about 16MB of free space on the windows-visible partition for
| a Windows GUI configuration application for the thing.
|
| Originally I started writing it in MFC, but MFC is not
| exactly good match for something so trivial and all the
| abstractions meant for document-based applications were
| mostly in the way and I ended up doing it in Lazarus.
| pjmlp wrote:
| And those COM errors that just kill the process, bypassing
| C++, and .NET exception mechanisms? lovely!
|
| No designer, manualy editing IDL files for XAML C++ bindings,
| without any kind of syntax highlighting or code completion,
| manually merging generated C++ code, even more lovely.
|
| Using a Webview wrapping Bing Maps, instead of the native UWP
| map control, even better.
| temac wrote:
| "Portable" i could see a few use cases. No MSIL and only
| native code, however...
| ranger_danger wrote:
| nuklear solves all of these for me, plus it's plain C
| Q6T46nT668w6i3m wrote:
| Apple and Microsoft underinvest in their widget toolkits. It's
| especially damning for Apple since they spend the money to write
| numerous custom widgets (e.g., the widgets in their professional
| apps like Final Cut Pro and Logic Pro) but don't upstream. Nobody
| is inspired by yet another implementation of button or tab
| widgets.
| somenameforme wrote:
| No idea about Apple, but I'd strongly disagree for Microsoft.
| In one way of speaking, they invest too much. WinUI3, like the
| article mentions has such a sordid history. It started as WPF,
| and WPF was (is) awesome. It's simple, clean, runs on a bunch
| of different platforms, doesn't have a zillion dependencies,
| has a great community, and is just all around pleasant to work
| with.
|
| So naturally Microsoft decided to completely scrap it, replace
| it with a far less functioning successor, flop, and then repeat
| this process over and over til we get where we are today after
| WPF->UWP->WinUI2->WinUI3. And WinUI3 has also already been
| completely abandoned. Contrary to this article, it still
| doesn't even have a visual designer. The amount of time,
| energy, and money Microsoft has spent with all of these
| successors is going to be remarkable, just to keep throwing
| everything away and restarting.
|
| Oh and while all of this was happening they've also been
| developing Xamarin, MAUI, and more that also all do pretty much
| the same thing - in completely incompatible ways, with a
| similar general trend of having the attention span, focus, and
| overall quality of a 13 year old ADHD boy, in a Japanese
| arcade, after 7 shots of espresso. This just isn't the sort of
| thing you could do without just completely absurd budgets and
| minimal concern about actually making something great. If they
| had instead just stuck to perpetually refining WPF, UI
| development on Windows would be a utopia today, and they
| probably would have saved an immense amount of money, or at
| least manhours.
| cjbgkagh wrote:
| A lot of the best people left MS. People forget that MS was
| so completely dominant that it attracted a lot of talented
| people who wanted to do big things. Since then the
| competition from the FANG companies have brain drained them,
| not helped by MS insistence on paying less than their peers,
| sure there is no state income tax but the company shouldn't
| be trying to capture all of that difference.
|
| The net effect is that not only are they not capable of
| building things as well as they used to, they can't even
| maintain what they already have. And how would anyone go
| about fixing such a culture. I think that's a big part of why
| MS has been so generous to OpenAI while also keeping them at
| arms length.
|
| Inertia is incredibly powerful and big companies can remain
| successful for long after their technical competence
| dissipates.
| temac wrote:
| Also, iirc there is no Windows department anymore at MS.
| Hard to make a great platform in these conditions.
| WorldMaker wrote:
| > And WinUI3 has also already been completely abandoned.
|
| I'm not sure where you got that impression, but WinUI3 is in
| almost all of Microsoft's software at this point. Admittedly
| a huge amount of it is embedded inside React Native, but
| WinUI3 seems to be the UI toolkit that has won and is still
| going strong. They announced a bunch of WinUI3 enhancements
| at BUILD even.
|
| (One such announcement is a coming standard control for the
| sort of custom Windows Title Bar with a search box and
| branded logo and extra buttons that has become common in
| every first-party application from the Microsoft Store app to
| all of Office and many other places.)
|
| > Contrary to this article, it still doesn't even have a
| visual designer.
|
| Huh? Visual Studio has a visual designer for the WinUI 3
| flavor of XAML. If you don't want to write XAML to back your
| UI they probably will never support a Visual Designer for you
| (ie, C# UI seems neat and maybe a bit more "functional
| programming", but I'd rather use XAML just to have the Visual
| Designer at least). Last I checked the XAML designer works
| just fine even in C++ projects targeting WinUI 3.
| somenameforme wrote:
| Visual Studio's designer really does not support WinUI 3.
| Try it! Hot reload also doesn't work worth anything.
| There's an ongoing issue/discussion on Github here [1] from
| 2021. There's also loads of fundamental issues like various
| controls causing replicable crashes with drag and drop, the
| community calls are disappearing, and more.
|
| [1] - https://github.com/microsoft/microsoft-ui-
| xaml/issues/5917
| WorldMaker wrote:
| Sure, it is definitely very buggy, but the point is that
| it still exists and is useful to some extent. I was
| refuting the claim that there is *no* visual editor, not
| the claim that the visual editor we do have is maybe
| deficient and buggy.
|
| Relatedly, I still think it is something of a shame that
| (Expression) Blend didn't survive to the modern era. A
| designer-focused XAML design tool that doesn't need a
| full Visual Studio install (nor the same sort of
| expensive VS license) and feels more like Firefly or
| Figma or whatever other designer-focused tool is current
| en vogue would be really handy in a lot of situations.
|
| I don't think it is the only reason that designers tend
| to prefer HTML (and thus we use Electron or similar to
| placate the designers that think that "just copy and
| paste it from the design tool" works "well") over XAML,
| but it certainly doesn't help that there isn't a "XAML
| Figma" and it's a shame on multiple levels that Microsoft
| recognized that threat early on, built a solution, then
| got confused why they built it, confusingly merged it
| into Visual Studio licenses and installs, which lead to
| its sadly inevitable death just a few years before it
| would have been very helpful to have to send to some
| designers and stop getting HTML-only mockups.
| jwells89 wrote:
| While Apple could stand to improve some aspects of their UI
| toolkits (and you're right that private widgets have long been
| a frustration), I'd say they're in an entirely different plane
| in existence relative to Microsoft in this regard.
|
| The most solid of their toolkits is far and away UIKit on iOS.
| It's got almost all of the best parts of AppKit with over a
| decade of thoughtful tweaks, polish, and QoL improvements.
| AppKit has become a bit more neglected since iOS stole the
| title of favorite child from macOS but is still quite solid.
| Both have an extensive set of highly capable stock widgets and
| with both, you can write just about anything imaginable pretty
| easily without importing a single third-party library. Neither
| locks you into a WYSIWYG editor or hand-editing XML and are
| pure-code-friendly, particularly since the addition of
| autolayout anchors.
|
| SwiftUI is finally getting to the point where it's not so green
| and is becoming a more practical choice. Though it wasn't a
| headliner, this recent WWDC brought a number of long called-for
| improvements.
|
| By contrast, WinUI lacks such fundamental basics as a
| tableview/datagrid, meaning you're going to be rolling your own
| or importing third-party widgets much more frequently. While
| you're not as locked into XML layouts and resources as one
| would be with Android Framework with it, it's not as friendly
| to pure code. It's also decidedly mobile-esque relative to
| AppKit (likely owing to its UWP heritage) which might be a
| problem if the goal is to build a true desktop-class app.
| eschaton wrote:
| UIKit is actually nearly 20 years old and AppKit is getting
| close to 40...
| marcellus23 wrote:
| I'm not sure what point you're trying to make.
| cjk2 wrote:
| The painful bit is C++. I did a fair bit of that going back to
| MFC. Knocking stuff out in C# with WPF and WinForms was quite
| nice in comparison. I haven't found anything nicer.
| 7thaccount wrote:
| C# with WPF or WinForms only seems nice in comparison to other
| relatively painful tools IMO.
|
| The old RAD graphical tools and newer ones like Rebol (that are
| now dated) show just what is possible. Mathematica is also
| pretty powerful and doesn't require a ton of code.
| cjk2 wrote:
| Totally agree with this.
|
| I'll get shot for this one but I write most of my GUIs in
| Excel these days.
| mordechai9000 wrote:
| Do you mean Visual Basic for Applications? How are you
| creating a GUI in Excel?
| hnthrowaway0328 wrote:
| I think there is a thing called Microsoft Office
| development kit or some other name that allows C# and
| other .Net programs to manipulate Office apps. Not sure
| if it's what the author meant, though.
| mordechai9000 wrote:
| Oh, I have used OLE (or some iteration thereof) to drive
| Excel from Python. That was a long time ago, but it
| sounds similar. I wasn't really doing GUI, though - I was
| using code to build spreadsheets from data files.
| cjk2 wrote:
| I had something I wrote in the 90s I wasn't proud of that
| was a word macro that read Excel sheets for a list of
| instructions and used those to compose documents and
| print them. I feel sick thinking about it.
| Gibbon1 wrote:
| Reminds me of Moe on the Simpsons saying I've done things
| I'm not proud of. And the things I am proud of are
| disgusting.
|
| You should be proud like that.
| jmkni wrote:
| I remember using Office Interop back in the day
|
| Less useful these days as we use open formats, ie doc is
| propriatery, docx is open
| cjk2 wrote:
| Mostly just locking fields. I don't do anything
| procedural. It's usually calculators, stats and modelling
| stuff.
| chipdart wrote:
| > The painful bit is C++. I did a fair bit of that going back
| to MFC.
|
| I'm sorry but referring to MFC while referring C++ is a
| telltale sign you don't really have any meaningful experience
| in the field. Developing GUI apps for Windows is a breeze with
| frameworks like Qt. You only suffer if you're a masochist, but
| the rest of us prefer to pick things that make sense.
| cjk2 wrote:
| I have a lot of experience, in the real world, which is
| somewhat less ideal than "just use Qt - it's a breeze".
|
| How do you manage a 15 million LOC desktop app originating
| from the late 90s which contains chunks of win32 native, ATL,
| MFC, custom GDI+ wrappers all sorts?
|
| Aye you fuck off and work somewhere else that's what you do.
| Which is why it's still written in win32 native, ATL, MFC,
| custom GDI+ wrappers.
|
| They paid two companies to come in and rewrite it, first in
| Qt which was a complete failure. Then in Electron etc, which
| was also a failure.
| torginus wrote:
| Ooh I remember having a 'Windows API fundamentals' elective at
| college. I wrote an app with a couple buttons, menu and
| scrollable text area, but not much in terms of functionality, in
| pure C, that was all around well-behaved. It was more than a
| thousand lines.
| Aurornis wrote:
| This is a good overview of some of the options, but the author's
| specific requirements push it in a specific direction that
| eliminates a lot of options.
|
| 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.
| chipdart wrote:
| > This is a good overview of some of the options, but the
| author's specific requirements push it in a specific direction
| that eliminates a lot of options.
|
| 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.
| Shorel wrote:
| Isn't the issue with Qt exactly what the GPL intended?
|
| In that case, any Qt fork would force him to also comply with
| the GPL, and supply the source code of his project.
| chipdart wrote:
| CopperSpice is LGPL, not GPL.
|
| It's not a problem.
| alok-g wrote:
| Hmm. How could that be when it's based on Qt?
| Liquid_Fire wrote:
| Qt is also available under the LGPL. There is no license
| advantage to using CopperSpice. I'm not sure what GP is
| referring to.
| alok-g wrote:
| Some parts of Qt are GPL only.
| Liquid_Fire wrote:
| True, but they are optional and are not the parts you
| need to create a GUI as per the requirements in the OP. I
| assume CopperSpice does not include these components.
| deutschepost wrote:
| LGPL. Which eliminates his requirement for a single
| executable. With LGPL you are only allowed to link
| dynamically.
| jjmarr wrote:
| The goal of this is so that end-users can modify or
| update Qt, the LGPL licensed component.
|
| The LGPL is working as intended.
| deutschepost wrote:
| Yes. But the article states that they don't care about
| that. They just want a single executable.
| EasyMark wrote:
| I never understood the need for a single executable on
| windows when folders, zip files, and 100% free installers
| exist if you don't like zip files. Also nearly all of the
| gui kits he's shooting down have ways to build custom
| components if that's what you want to do.
| ranger_danger wrote:
| No need for an installer when it's just one file you can
| run anywhere. And folders/zips are way too hard for the
| average user. Ask me how I know. My partner gave up an
| entire game platform because it was delivered as a .7z
| file they could not figure out.
| riffraff wrote:
| But a .7z requires a custom expander, .zip is natively
| supported by windows, isn't it?
| Kwpolska wrote:
| .7z recently got native support.
| josefx wrote:
| None of these help you if you are dealing with users that
| move executables for convenient access or think updating
| the sofware just involves dragging and dropping the new
| executable into the existing installation folder.
| Customer support had countless stories like that.
| TheCoelacanth wrote:
| Then pay for a license or make the object files available
| to users who want to relink the app.
| singpolyma3 wrote:
| Not true at all. The LGPL does not specify anything about
| mode of linking or anything like that.
|
| 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.
| Wowfunhappy wrote:
| > 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?
| jcelerier wrote:
| Yes. For instance some Cisco app on iOS that uses
| gstreamer (LGPL) does exactly this.
| bla3 wrote:
| The linked post does mention that:
|
| > or distribute object files for recompilation
| leni536 wrote:
| > 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.
|
| 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.
| alok-g wrote:
| Cool!
|
| 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.
| cesarb wrote:
| > If you ship alongside your binary a bundle of eg .o
| files
|
| You might even be able to use partial linking (ld -r) to
| ship a single .o file instead of a bunch of them.
| elpocko wrote:
| Dear ImGui is for development/debug tools, not an UI for the
| end-user. It's great for small projects as long as you don't
| care about accessibility, or proper keyboard support, or
| adherence to standard UI conventions, or support for devices
| without GPUs, proper font rendering, etc. ...
| bun_terminator wrote:
| imgui offers incredible development speed. And I've used it
| many times with great success. It's unorthodox yes (and
| there's a long-open bug I won't talk about again) but it's
| dear to my heart. It's like MFC on steroids: You don't have
| to leave C++.
|
| But yeah at least a few of those caveats remain. Although
| keyboard navigation and font rendering have quite a bit of
| support.
| fuzztester wrote:
| Due to what reasons does imgui offer incredible development
| speed?
| bun_terminator wrote:
| Because adding a text is just a imgui::text("abc")
| function call. And a button is just an
| if(imgui::button("click me")) do_something() statement.
| There is no other language involved, no markup, no gui
| editor. Just direct code and highly hackable to make this
| extend to unexpected lengths.
| fuzztester wrote:
| Thanks, got it.
| userbinator wrote:
| It's also suited to games, where "non standard" UI is
| expected and part of the experience.
| delta_p_delta_x wrote:
| Most games _don 't_ use ImGUI, though. Like the parent
| commenter said, it's useful for debugging, but the actual
| in-game UI--HUD, inventory, map, etc--is usually rendered
| by yet another middleware framework like Scaleform, or
| something that the engine provides (Unreal or Unity).
| spookie wrote:
| Nuklear is sometimes used. Anyhow, I do know of some game
| engines created and used by a (very large) game studio
| that uses ImGUI. I won't say anything else though :)
| NekkoDroid wrote:
| > I do know of some game engines created and used by a
| (very large) game studio that uses ImGUI.
|
| It often isn't a secret:
| https://github.com/ocornut/imgui/wiki/Software-using-
| dear-im...
| summerlight wrote:
| This is true. There is a reason why Scaleform made its
| way to become a popular gaming UI framework even though
| many of its weakness. The most important focus in game UI
| framework should be on tools and pipelines for
| artists/designers and this is usually not up to
| engineering decisions. I won't say that using ImGUI for
| game is impossible, but there might be lots of tooling
| works ahead for production game development.
| ranger_danger wrote:
| ImHex uses it for the entire UI
| artyn wrote:
| There is also furnace[0] and mmlgui[1]. Which are recently
| developed programs that people have been using to create
| chiptune music for retro video game consoles. Including
| being used by Yuzo Koshiro[2].
|
| [0] https://github.com/tildearrow/furnace
|
| [1] https://github.com/superctr/mmlgui
|
| [2] https://x.com/yuzokoshiro/status/1800554520256360794
| oblio wrote:
| And that's a dev/debug tool, just as explained by OP.
| throwaway2037 wrote:
| > proper keyboard support
|
| Specifically, what does this mean?
| TJSomething wrote:
| I currently see two international keyboard issues:
|
| - 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.
| throwaway2037 wrote:
| Excellent reply. I did not consider international
| keyboards when I writing my reply. And gaming companies
| are _definitely_ targeting international markets in 2024!
| eschaton wrote:
| If instead of insisting on custom UI styling the author just
| used the system UI, they could probably build a pretty
| straightforward Windows application. It's the scourge of "brand
| identity" that has people thinking graphical applications are
| hard.
|
| 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.
| barrkel wrote:
| This indeed. Custom UI widgets for Windows apps are really
| not necessary most of the time, and fitting in with the
| system theme is all you ought to aim for, most of the time.
|
| 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.
| therein wrote:
| > and fitting in with the system theme is all you ought to
| aim for, most of the time
|
| Even Microsoft struggles with that.
| pc86 wrote:
| Only because they change the system theme every 45
| minutes.
| ToucanLoucan wrote:
| Seriously, someone needs to reign in their UI department.
| No more refreshes until you actually _finish one._
| klabb3 wrote:
| > There are exceptions, for very rich dense UI, for UIs
| that need to be cross-platform
|
| 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?
| wongarsu wrote:
| Most applications would be fine with a button on Windows
| looking like a Windows button, a button on Mac looking
| like a Mac button, a button on Android looking like a
| Material Design button and a button on iPhone looking
| like a UIKit button.
|
| You need consistency in the icons, layouts and concepts,
| but you don't need every widget to look exactly the same
| on every platform.
| MBCook wrote:
| Right. I want your app to have consistency with the
| platform I'm using. Not between all platforms.
|
| With the exception of games try to use the native GUI.
| It's the best choice most of the time.
| flyingpenguin wrote:
| Depends on the app size also.
|
| 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.
| MBCook wrote:
| I disagree. I think the only apps where a custom UI make
| sense are games and I'm willing to accept highly
| specialized business apps that have their own
| conventions. Thinks like Blender, AutoCad, Logic, etc.
|
| 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.
| ToucanLoucan wrote:
| > Does Microsoft themselves build their apps this way?
|
| 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.
| threatofrain wrote:
| Or if you're making games. All games seem to cherish a
| unique look even starting from the game menu or title
| screen.
| Arrath wrote:
| I, for one, miss customized installers. We've kind of
| lost out on those what with the move to digital
| distribution.
|
| 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!"
| cageface wrote:
| My experience with SwiftUI on the Mac is that it still needs
| a lot of work. Documentation is poor. Performance can be bad
| if you do things in a straightforward way. Supporting older
| versions of the OS is quite painful etc.
| throwaway2037 wrote:
| > Documentation is poor.
|
| This is the first I heard about SwiftUI. Maybe I am mixed
| up and docs are excellent for Swift, but _not_ SwiftUI?
| cageface wrote:
| Yes. Two different things. The SwiftUI docs are mostly
| just listings of functions and not much explanation of
| how to use them.
| superb_dev wrote:
| Plus, half of the official examples are given to you as a
| full Xcode project that you must download and import
| biztos wrote:
| I recently built a small app using SwiftUI. It was my
| first, and pretty simple.
|
| 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.
| throwaway2037 wrote:
| Thanks for the follow-up. These types of anec-data are
| the best part of HN. > It felt like
| magic when it worked, all those VStack HStack nestings
|
| I know the feeling from Qt. I think Gtk and many other
| GUI toolkits use the equivalent of VStack and HStack to
| make resizable GUIs. Some GUI toolkits try to avoid this
| problem by using a grid layout, but it is more rare.
|
| EDIT > made me seriously doubt whether
| I'd build a big app with SwiftUI
|
| From your experience, what GUI toolkit would you prefer?
| And, it would help to know what is your target UI
| platform.
| cageface wrote:
| I've had overall very positive experiences with Flutter.
| If I wasn't concerned about Google's long term commitment
| to it I'd use it for everything.
| biztos wrote:
| Did you do cross-platform and if so, did you use the same
| UI style for everything?
|
| 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.
| cageface wrote:
| Yes cross platform and the same style. I don't think this
| matters much to users today. They're used to it.
|
| 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.
|
| https://plastaq.com/minimoon
| biztos wrote:
| I don't have much app experience, I'm mostly a back-end
| guy trying to build some prototypes and (hopefully) one
| product.
|
| 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!
| cageface wrote:
| If you really want native look and feel then really your
| only choice is to use the native toolkits.
|
| 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:
|
| https://plastaq.com/minimoon
|
| 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.
| biztos wrote:
| Thanks, I will have a look at that. Serendipitously, I'm
| in the market for a new music player!
|
| 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.
| cageface wrote:
| Please let me know if you have any feedback or
| suggestions for the player.
|
| And yes I'd feel more confident in Flutter if Google was
| dogfooding it a lot more.
| mst wrote:
| Without expressing an opinion on Flutter as such, it's
| worth remembering that Google is a big enough
| organisation that even -some- internal apps being built
| using it is quite a commitment, and it not having spread
| further internally could easily be a social or political
| rather than a technical issue.
| bobajeff wrote:
| Documentation remains the number one reason I personally
| don't make Android apps and why electron/web apps are the
| way to go for most GUI apps these days.
| cageface wrote:
| Unfortunately it doesn't seem like having good, bug free,
| modern and well documented desktop APIs is a priority for
| anyone anymore.
| vintagedave wrote:
| He should have used C++Builder. Native Windows widgets (so
| you get, eg, IME support) but it can theme them. And comes
| with dark themes!
|
| Edit: and fully static linking. Might be a meg or so.
| dokka wrote:
| Yeah, I can confirm that writing windows GUI apps is not at all
| painful for me. I still use Windows Forms in .NET 4.8 and my
| executables are < 1mb, Visual Studio's form designer is very
| easy to use, you can subclass all the .NET UI controls and
| customize them however you want. There's always been
| accessibility and even support for high DPI.
| fuzztester wrote:
| >I still use Windows Forms in .NET 4.8 and my executables are
| < 1mb
|
| Do you need to ship any supporting files separately, along
| with the app?
|
| And is .NET 4.8 or higher already on Windows PCs?
| throwaway2037 wrote:
| .NET 4.8 is default in Win10/11 now.
| EnigmaFlare wrote:
| A nice thing about .Net Framework 4.8 is that they finally
| finished it! No more update treadmill and dicking around
| dealing with what versions are installed or how to
| configure your application to use whatever different
| versions. Just target that and forget about it.
| WorldMaker wrote:
| .NET 4.8 is the _last_ .NET to be bundled with Windows. It
| 's a legacy stack, but it exists on every Windows >= 10 so
| it is a legacy stack that makes deployables easy (just
| assume it is installed). (.NET 4.8 is the new VB6.)
|
| 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.
| EasyMark wrote:
| If you're on windows and want a "standard" guy, either use the
| .net GUI or Qt , if you want completely custom and willing to
| do the work use QML or ImGui (or variant like eGUI)
| smackeyacky wrote:
| Which particular .NET Gui? There is a collection of them:
| MAUI, WPF, Blazor Hybrid, WinUI.
|
| Microsoft have utterly screwed the pooch on getting their
| .NET GUI story straight.
| jen20 wrote:
| Probably Windows.Forms unless there's a REALLY good reason
| to do anything else.
| ivm wrote:
| WinUI 3 is the default for Windows-only applications
| LordDragonfang wrote:
| Except it's still missing a lot of controls, further
| development and bug fixes are practically at a
| standstill, and despite what TFA says, there is _no_
| visual designer support (which is a dealbreaker for many
| multidisciplinary teams).
|
| 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.
| pjmlp wrote:
| Nah, it is so bad, that on BUILD 2024, they have brought
| back first level status to WPF.
|
| 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.
| CrimsonCape wrote:
| Win UI 3 is the worst kind of improvement because there's
| arbitrary equivalence between WPF concepts and WinUI
| concepts, not a 1:1 equivalence. WPF as the mature stable
| model should be gospel; you don't re-write the gospel.
| Yet Microsoft feels they should re-write this gospel
| because... it aligns with the vision (???). Both use
| XAML, but the concept of DataContext is substantially
| changed, the concept of bindings is substantially
| changed, etc. Why make every XAML attribute ever-so-
| slightly different? Are those changes really an
| improvement? A lexical improvement? A performance
| improvement? Or just baggage and overhead to learn?
|
| 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?
| wvenable wrote:
| In my opinion, WPF is the logical choice. Still.
| alkonaut wrote:
| Don't forget Avalonia. Looks like it's going to be the
| sensible WPF version.
| wkat4242 wrote:
| Qt makes such amazing apps. I love KDE and the apps they
| spawned like Kate, KDEnlive, Krita.. It's no wonder their apps
| are so popular on Linux and windows alike. Unlike GTK apps even
| though it does have bindings for Windows.
| rty32 wrote:
| Agree. "Single executable" combined with "less than 40mb" is
| just looking for trouble for what the author is trying to do.
| If you want to do win32, go ahead and give up styling.
| Otherwise, make compromises. I think many of these are
| excellent choices chosen by many programs that I use, it's the
| author's stringent requirements and unrealistic expectations
| that is holding back.
| beagle3 wrote:
| This comment makes me feel like I live on a different planet.
|
| 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.
| rfoo wrote:
| > 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?
| beagle3 wrote:
| I actually used FLTK for the first iteration; The theming
| support it had at the time was not sufficient, though,
| and the i18n story non existent (that was before even
| 1.0, versions were still labeled by dates).
|
| 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.
| ClumsyPilot wrote:
| > In 1999, I built a completely custom Win32 GUI for a
| (brandable) chat application
|
| Given that it's windows, it might still run today, so it
| likely is still possible
| alok-g wrote:
| Winamp comes to mind as a counter example.
| hermitdev wrote:
| IMO, every media player since Winamp 2.x has been largely a
| step _backwards_ in pretty much every metric one could put
| forth. It was light-weight, using minimal CPU & RAM. It was
| skinable. It was reliable. It had great plugin support. I
| don't recall it leaking memory, either. I basically had it
| set to auto run on login on my PC. I never closed it.
| Didn't need to. I had _only_ 32MB of RAM on that computer.
| alok-g wrote:
| +1.
|
| I still use Winamp, and essentially in its 2.x mode.
| abareplace wrote:
| My app is around 500 KB (not megabytes) and it supports dark
| mode (see https://www.abareplace.com/). So this is definitely
| possible without using Electron or bloated GUI libraries.
| jocoda wrote:
| Title is "Writing GUI apps for windows is painful", and then
| the author slaps on a bunch of bullshit constraints but
| pretends to be covering the general case. Sorry dude, if you
| want to do that then change the title to something appropriate
| like "Writing small, custom styled GUI apps for windows is
| painful". Otherwise this is bait and switch.
|
| 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.
| cratermoon wrote:
| "Writing small, custom styled GUI apps for windows is
| painful"
|
| I'd add "for free because I'm too cheap to buy a license for
| a toolkit that does what I want".
| ClumsyPilot wrote:
| Agreed, this is a bit like writing 'developing iPhone app is
| painful' but not using anny officially supported tooling.
|
| fact that you must ship the app _Unpackaged_ is particularly
| strange.
| daemin wrote:
| Are you saying without an installer, or unpackaged as in
| without a package identity ala
| https://learn.microsoft.com/en-us/windows/apps/get-
| started/i... ?
| pc86 wrote:
| > _he didn 't want to pay for a license_
|
| 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.
| throw__away7391 wrote:
| > stay away from Electron
|
| 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.
| naitgacem wrote:
| I might understand polished, but no issues sounds odd. What
| about the abysmal performance? Also most folks building
| things do not have the resources that Microsoft has, so I
| believe VSCode is not a good represantative of most
| Electron software.
| PaulHoule wrote:
| I've gone through the same process of evaluating x-platform
| alternatives and I can now understand why Electron is so
| popular.
|
| 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.
| mst wrote:
| I've been eyeing https://neutralino.js.org/ since if I'm
| going to make the app render right on browsers then relying
| on the same code via webviews likely isn't (much) more
| portability effort.
| slaymaker1907 wrote:
| 40MB seems like a weird requirement. If it's under 1GB, I don't
| think most people really care any more about executable size.
| Memory usage is still relevant, but 1GB is going to be less
| than 1% of disk usage for almost everyone.
| dgellow wrote:
| 1GB for each app accumulates really quickly. 40MB is really
| low, but I wouldn't be happy with 1GB per app personally.
| Anything below 500-600MB is fine.
|
| I want my disk space for large medias, not for a desktop app
| grahar64 wrote:
| Not an expert, but could you use something like
| https://enigmaprotector.com/en/aboutvb.html to virtualize a file
| system to create a portable exe. Not sure if the size would
| exceed your specs.
| mjevans wrote:
| Windows (MS) and OSX (Apple) need to agree on a GUI
| interoperability API. Either hammer something out, or adopt
| one/more of the OSS GUI framework specifications from QT and GTK.
|
| It MUST be open spec. It MUST be free for all/any to implement.
| It MUST either be included or be in the primary vendor (MS,
| Apple, distro) software center.
|
| A simple Hello World, click OK to exit the program application
| should be able to be cross-compiled for any platform, and the
| resulting binary MUST NOT require including / embedding DLL /
| library hell like everything today does. It SHOULD be a small
| entirely dynamic program; possibly a few hundred kilobytes at
| most but even that seems too large. After all, it would mostly be
| the basic boilerplate of setting up memory, calling the system
| library loader, and linking in the shared libraries.
| nasretdinov wrote:
| I think OpenStep actually had something like this in mind and
| had a Windows implementation too. It's apparently even used in
| Apple Windows apps like Safari, but of course it must not be
| complete enough to be able to fully replace native Windows API,
| and the incentive isn't there either.
| linguae wrote:
| There was an implementation of OpenStep for Windows named
| OpenStep Enterprise:
|
| https://forum.winworldpc.com/discussion/11422/openstep-
| for-w...
|
| It even survived Apple's purchase of NeXT, where the OpenStep
| API was renamed Yellow Box. There was a port of Yellow Box to
| Windows:
|
| https://www.betaarchive.com/forum/viewtopic.php?t=29049
|
| In both OpenStep Enterprise and Yellow Box for Windows, while
| the UI elements still have some NeXT-isms, it's not terribly
| out of place, either.
|
| However, this got scrapped sometime when Apple abandoned
| Rhapsody (which had PowerPC and x86 versions) in favor of Mac
| OS X (which was originally only available for PowerPC until
| the Intel switch in 2006, though Apple maintained an x86
| version internally during the PowerPC years). During the
| transition from Rhapsody to Mac OS X, Yellow Box was renamed
| Cocoa.
| WillAdams wrote:
| The impetus here is that Adobe had initially promised a
| free, then low-cost license for Display PostScript --- when
| that was pulled, Apple had to come up with an alternative
| --- that and the fact that all the major app vendors
| announced that they weren't willing to do top--to-bottom
| re-writes using the NeXT frameworks (there was even a rumor
| that "Yellow Box" was named for the sake of Bill Gates'
| comment, "Develop for NeXTstep? I'll piss on it.")
|
| So, Apple, led by Mike Paquette and many other talented
| folks from NeXT created Quartz (nee Display PDF) and Carbon
| and instead of a consistent environment with a single API,
| we got an assemblage of technologies which had a Calculator
| app written in Java which took _forever_ to load, a Finder
| written in Carbon instead of Workplace.app, and icons
| cluttering the desktop and a Sidebar instead of a Shelf,
| and a bunch of Carbon apps.
| criddell wrote:
| > need to agree on a GUI interoperability
|
| I hope they don't. I like that the different platforms I use
| feel and look different. In fact, I wish there was more
| variety. I wish there were still Atari, and Amiga, and BeOS,
| Tandy, and all the other interesting platforms competing for
| users with different ideas of how computers should work.
| linguae wrote:
| I wonder how possible it is to design a cross-platform GUI
| framework that not only uses the native UI widgets of each
| underlying platform, but also respects each platform's human
| interface guidelines. I'd imagine this would be very hard
| work, especially the part about respecting each platform's
| HIG, but the increased power of AI tools could potentially
| make this task easier. Such a framework could potentially be
| an appealing alternative to Electron for making cross-
| platform applications, with the benefit of conformity to each
| platform's HIG.
| swatcoder wrote:
| There have been many frameworks that offered this and some
| still do. But it comes at the direct expense of design
| discipline, branding, and user experience optimization --
| all of which have been elevetated to high concern over the
| 15 years or so.
|
| Cross-platform "Native look and feel" currently works for
| some no-nonsense professional utitlies and hobby tools, but
| mostly makes software that's hard to sell, document, or
| support.
|
| Most have just opted for common widget libraries instead,
| and frameworks have stepped up by providing rich libraries
| of such widgets and prioritizing features for customizing
| or complementing them even further.
| criddell wrote:
| I've been thinking more lately about a library which
| defines an interface for GUI elements, and then leaves
| implementing that up to you. Something like MVC (or some
| other design pattern) where the view part is an interface
| definition.
| torstenvl wrote:
| wxWidgets does this pretty well, e.g., wxSingleChoiceDialog
| has "OK" "Cancel" on Windows but "Cancel" "OK" on
| Linux/GTK.
| torstenvl wrote:
| This exists. It's called wxWidgets. It's an API shim over
| native components plus some convenience classes for abstracting
| out OS-specific functionality. It's LGPL with static linking
| exception, so no DLL hell.
|
| I'm not quite sure what you mean by open spec, but it's just an
| API not a protocol, and uhhhh....
| https://caselaw.findlaw.com/court/us-supreme-court/18-956.ht...
| mjevans wrote:
| The library exists, BUT it is NOT shipped natively and NOT
| (AFAIK) something which trying to run a random downloaded
| utility app will trigger the system library loader prompting
| for the 'common wxWidgets runtime, for free, codesigned by
| Microsoft' download and install from the store to run the
| app.
| torstenvl wrote:
| Your previous post said
|
| > _the resulting binary MUST NOT require including /
| embedding DLL / library hell like everything today does_
|
| If there's no DLL required then why does it matter if the
| DLL is automatically downloaded from the Microsoft store?
| DLLs are not useful for statically linked binaries.
| userbinator wrote:
| That's called WINE. ;-)
|
| Win32 Hello World messagebox is a few hundred bytes.
| cxr wrote:
| > Windows (MS) and OSX (Apple) need to agree on a GUI
| interoperability API. Either hammer something out, or adopt
| one/more of the OSS GUI framework specifications from QT and
| GTK.
|
| I've been saying for a while now that the open source world
| would have benefited if more effort than what went into GNUStep
| had been focused on copying Cocoa to the point that it rather
| than GTK or Qt had been the toolkit of choice for the Linux
| Desktop. Especially when there was a major infusion of interest
| circa 2010 of folks adopting the MacBook Pro as the developer
| machine of choice.
|
| I think it's still doable. And I mean down to looks, too, and
| not just API feel. Aqua from the same time period (Snow Leopard
| through Mountain Lion era) is the closest thing I can think of
| to timeless visual design.
|
| It's true that if everyone just made Cocoa apps that looked
| like they were created with Mac OS in mind it would look out of
| place on Windows and elsewhere, but (a) it would still look
| rather good, and (b) it would not look any _more_ out of place
| than anything else, including Electron and even lots of
| "native" apps, due to the proliferation of toolkits described
| in the article not to mention the Gnome identity crisis that
| has only just recently begun to get reigned in--mostly by
| following Mac OS cues and being more consistent than before.
| It's just a shame that it stops at the surface level and
| doesn't carry over into the actual APIs. Plus those cues are
| from the post-flattening of UI.
| mjevans wrote:
| If _anything_ is going to get copied by Linux as is... it 'll
| be Win32 API so mono / C# stuff can bind directly to that,
| and Mac/OSX will be even more isolated.
|
| For something to be portable everywhere it'll have to be an
| industry standard that the existing industry buys into.
| Androth wrote:
| they don't need to do this and likely don't care to. web ui
| exists. microsoft doesn't even care about native anymore. they
| are focusing on .net maui cross platform/web (with blazor)
| stuff and AI.
|
| the days of snappy portable applications are over. unless you
| want to stick with win32. and nothing wrong with that. in
| win32, you have the tools to create any look and feel you want.
| the author just doesn't care put in the time to do that and
| wants something pre-built while conforming to his demands.
| mattgreenrocks wrote:
| Unfortunately, if you are insisting on a single exe file, then
| you have to be way more flexible on your requirements than the
| author is. There's a reason that practically every Windows
| program has an installer. It's stupid and a waste of time but
| also probably more of a waste of time to try to be the exception
| to this rule.
|
| Frankly I don't see why C# targeting an old (3.5?) .NET framework
| version wouldn't work for the author. There seems to be a
| tendency to fixate on how things should be vs where we are now.
| C++ native GUI dev is not a mainstay like it used to be.
| throwaway2037 wrote:
| I agree with the sentiment of your post.
|
| Real question: Is a single exe not possible when targeting .NET
| Framework 3.5? Or is the problem that the _sum_ of their silly
| requirements makes it impossible?
| mattgreenrocks wrote:
| It should be quite possible to target .NET 3.5 and hit all
| the other requirements, except native C++. They hinted at
| this and then started talking about C++/CLI. If there's ever
| a tool of last resort, that is it.
| magicalhippo wrote:
| Writing GUI apps for Windows _in_ _C++_ is painful
|
| There, fixed it for ya.
|
| There are solutions if you're not hell-bent on using C++, be it
| .Net, Lazarus (FreePascal) or Delphi. We're using Delphi at work
| and for the most part it's super simple and easy.
| nurettin wrote:
| Delphi comes with so many db drivers, a data layer that will
| let you do crud, and an app store that using it feels like
| cheating. Especially with devexpress controls.
| chipdart wrote:
| > Writing GUI apps for Windows in C++ is painful
|
| I don't think so. Qt makes this a trivial problem, and WinUI3
| supports C++ as a first class citizen.
|
| I'd argue that desktop development for Windows was never as
| good as it is right now.
| magicalhippo wrote:
| I've used Qt a lot. Unless something very drastic has
| happened last 5-6 years it's not in the same league as say
| Delphi.
|
| But fair enough, it's quite good. If I had to write a C++ UI
| application, it'd be on my shortlist.
| dgfitz wrote:
| Writing a gui in Qt is so simple anytime someone like the GP
| says "writing a gui in c++ is hard" obviously hasn't tried.
| rubymamis wrote:
| Indeed, QML and C++ together are the best mix out there for
| GUI development. I've written my block editor completely
| using Qt C++ & QML: https://www.get-plume.com/ and it was a
| breeze.
| Androth wrote:
| lazarus is great, but the GUI library it comes with has the
| same issues that the author is concerned about... try changing
| the theme colors to a dark theme... you end up with something
| looking like crap with all the other controls using standard
| colors.
| beart wrote:
| Writing GUI apps is painful everywhere, and has been for years.
|
| I remember the half-baked transition from Windows Forms to WPF,
| which was then taken-over by the Windows Phone initiative, which
| was also extremely painful and half-baked.
|
| There's a reason electron is so popular, despite all the
| complaints about it as a platform. Don't blame the electron devs,
| blame Microsoft for completely failing to support their own
| platform. That lack of long-term support and consistency extends
| to a ton of areas in the Windows world, not just GUI development.
| jb1991 wrote:
| > Writing GUI apps is painful everywhere, and has been for
| years.
|
| Disagree. GUI development on Apple platforms using either UIKit
| or Appkit is something I've always found expressive, simple,
| and fun. SwiftUI is a different beast, but to say it's painful
| everywhere is not accurate.
| bowsamic wrote:
| > Writing GUI apps is painful everywhere, and has been for
| years.
|
| I think UIKit and SwiftUI (and to a lesser extent Appkit) are
| great
| webworker wrote:
| Oddly AppKit seems to be one of the most stable desktop
| frameworks I have worked with. They've made breaking changes,
| sure, but they haven't been rewriting, and rewriting, and
| rewriting the same stuff for the last decade and a half.
|
| The situation on Windows these days feels like... cognitive
| dissonance. If given a Windows app assignment today, I'd pick
| WinForms if less complicated, WPF if a larger project.
| Dwedit wrote:
| Windows Forms (C#) is basically a continuation of Visual Basic,
| it's not very painful at all. The only painful bits are when
| you need to lock a bitmap and deal with raw pointers, and you
| need to use the "unsafe" keyword.
| shortrounddev2 wrote:
| To me, Windows Forms is where MS should have stayed. I don't
| want XAML to compile to C# code, and I don't want to be
| forced into using their MVVM system. I just want to be able
| to put boxes on the screen and fill them with text, then
| handle user interactions with callbacks. Basically, vanilla
| javascript but in C#
| glzone1 wrote:
| The lack of windows support for windows GUI's on windows is
| mind blowing. I remember absolutely whipping up Visual Basic
| line of business apps using the form designer in Visual Studio
| and data bound controls etc. If you wanted more there was MFC
| (with MTL developed by some insiders I guess at microsoft)
|
| The absolute insanity of going to WPF (wasn't data binding via
| reflection -> these apps got horribly sluggish!) then to UWP
| (monster controls for touch I guess?) is honestly mind blowing.
| The emphasis on Universal Windows Platform as "the future" of
| app development is absurd. Every time the design language
| behind this infects another settings app in windows we LOSE
| functionality! Can you even have more than one settings window
| open anymore with the new and improved UWP?
|
| Then there is WinUI? Then there is MAUI? THen there is blazor
| on the desktop?
|
| Has Microsoft confused you yet? They've confused me. Each of
| these introduced as the best thing since sliced bread, and back
| with tooling with broken forms designers and more.
| akira2501 wrote:
| > The emphasis on Universal Windows Platform as "the future"
| of app development is absurd.
|
| Remember when Microsoft honestly thought they had a shot at
| making a mobile platform to compete with Android and Apple?
| shortrounddev2 wrote:
| Say what you will about their chances of succeeding, but
| the Windows phone is the best phone I ever owned
| kmeisthax wrote:
| The problem with all of these technologies is that they were
| invented by different divisions of Microsoft to do different
| things. That, and Microsoft chasing the Next Big Thing.
|
| What we consider to be "Win32 apps" are built with a
| framework in USER.dll, which is half reimplementation of the
| classic MacOS Toolbox API and half a pure-C object oriented
| class system. It's been here since the beginning, and is the
| lowest common denominator for getting anything on screen.
| _Every other toolkit_ eventually opens a USER window,
| attaches the appropriate window class and wndprocs to it, and
| then yields CPU control to an event loop that, among other
| things, contains a Windows USER message pump.
|
| USER, being an object-oriented, pure-C[0] API, is infamously
| verbose to work with. The "200 line Hello World" example
| everyone passed around back in the 90s is specifically that
| verbose because of all the bookkeeping you have to do for
| USER's sake. It is possible to build USER apps that work
| well, but it puts a lot of onus on the programmer. Even
| things like high-DPI support[1] or resizable windows are a
| pain in the ass because they all have to be implemented
| manually.
|
| Microsoft's original answer for "USER is too hard" was to
| adopt Visual Basic or MFC as you mentioned. AFAIK .NET
| WinForms was also a wrapper around USER. This is why Windows
| had a cohesive visual appearance all the way through to
| Windows 7, because everything was just developer-friendly
| wrappers around common controls. Even third-party widget
| toolkits could incorporate those controls as subwindows as
| needed[2].
|
| The problem with USER is that it was built for multiple
| windows and applications that render (using the CPU!) to a
| shared surface representing the final visible image. Modern
| toolkits instead have multiple separate surfaces and draw on
| them as needed before presenting a final image to a
| compositor that then mixes other windows together to get a
| final image. Windows Vista onward has the compositor, but the
| UI toolkits also need to be surface-aware instead of chucking
| a bunch of subwindows at DWM at the last minute.
|
| WPF is the first attempt at a modern UI toolkit. Relative to
| USER resources are replaced with XAML and window classes
| replaced with... well, actual language classes. Except it was
| developed by the DevTools division (aka DevDiv), and only ran
| on .NET with managed code. If you had a native application or
| just didn't want to pay the cost of having a CLR VM, tough.
|
| Then the iPhone launched. And the iPad launched. The thing
| is, good tablet UI _needs_ GPU-acceleration up and down the
| stack, so Microsoft shat themselves, gave the Windows
| division (aka WinDiv) the keys to the castle, and they
| completely rewrote WPF in C++ with some fancy language
| projections. That became "Metro" in Windows 8, then "Modern
| UI" after a trademark dispute. Microsoft wanted Windows 8 to
| be a tablet OS, damn it, with full-screen only apps and no
| third-party app distribution.
|
| And then most people just bought Surface tablets, opened the
| Desktop "app", and used the same USER apps they were used to,
| complaining about the Start Screen along the way. So
| Microsoft pivoted back to a normal desktop with Modern UI
| apps, which are now called UWP apps, and there's a whole
| bunch of new glue APIs to let you stick XAML subwindows
| inside of USER or just use UWP outside of AppX packages,
| which is what Windows 8 should have done, and now everything
| is just a mess. WinUI 3 is just an upgrade to the XAML
| library that UWP apps use, but it sounds like Yet Another
| Toolkit. MAUI is some kind of meta-toolkit like the old AWT
| on Java.
|
| At some level, I can explain this, but it's not reasonable.
| There is no "native" UI toolkit or consistent look-and-feel
| on Windows anymore. I suspect this, more than anything else,
| is the reason why Windows killed Aero blur-behind everywhere,
| and why Electron apps are so damned popular now. HTML and CSS
| are almost as old as USER, but with consistent engineering
| support and developer experience.
|
| USER is an enhanced clone of the MacOS API, so it's natural
| to see what Apple did when confronted with the same problems.
| MacOS didn't have an object system _at all_ , you just threw
| a bunch of controls onto a list and the system rendered them.
| That (along with user mode applications) was actually one of
| the reasons why they bought NeXT. OSX's AppKit toolkit
| shipped with compatibility bridges for Toolbox apps, but it
| was still about as advanced as USER was when it came to GPU
| usage, given that it was built around the same era as
| Windows, just for beefier hardware.
|
| So what did Apple do? They made AppKit speak layers. They
| wrote a whole new compositing system called CoreAnimation to
| do in-process compositing, with all the common controls
| knowing how to manage it and layer-unaware third-party
| controls just doing whatever made sense. And this itself was
| a trojan horse for UIKit: the compositing library had been
| written to support a touch tablet demo that was later rolled
| into the Purple project to produce the iPhone. Y'know, the
| thing that actually kicked Microsoft's ass so much they
| decided to fracture their development ecosystem into 40
| different UI toolkits with confusing names. In comparison, on
| modern macOS the big split comes from SwiftUI and Catalyst,
| but those are both wrappers around AppKit controls rather
| than ground-up rewrites of UI toolkits nobody dares touch.
|
| [0] Or possibly Pascal, given the MacOS heritage
|
| [1] The correct way to do high-DPI is for the windowing
| toolkit to work exclusively in virtual coordinates. Physical
| device coordinates and their derivatives should be converted
| away from at the earliest possible convenience and converted
| back into as late as possible. At a minimum, no user-facing
| APIs should use physical coordinates.
|
| USER does not do this, even though there's an option to make
| it do this, which has worked wonders on every non-DPI-aware
| app I've thrown at it.
|
| [2] Or, alternatively, implement their own. My favorite story
| about this is Internet Explorer, which ships with it's own
| implementations of common controls specifically just so that
| HTML form elements don't have to hold an HWND each and can
| share the parent window.
| glzone1 wrote:
| The mess this made showed up everywhere.
|
| AppX packages got a bad rep as well for a couple of
| reasons. Lots of new footguns when dealing with them or
| trying to remove them for imaging / mass deployment
| scenarios.
|
| The first introduction to AppX was often a metric load of
| crap on the machine - see below for a sample of the type of
| AppX stuff that was the first introduction to AppX for some
| folks which were often low effort marketing type stuff.
|
| Get Skype: Get-AppxPackage -allusers skypeapp | Remove-
| AppxPackage Get-AppxPackage -allusers zunemusic | Remove-
| AppxPackage Get-AppxPackage -allusers maps | Remove-
| AppxPackage Get-AppxPackage -allusers solitairecollection |
| Remove-AppxPackage Get-AppxPackage -allusers bingfinance |
| Remove-AppxPackage Get-AppxPackage -allusers zunevideo |
| Remove-AppxPackage Get-AppxPackage -allusers bingnews |
| Remove-AppxPackage Get-AppxPackage -allusers people |
| Remove-AppxPackage Get-AppxPackage -allusers windowsphone |
| Remove-AppxPackage Get-AppxPackage -allusers bingsports |
| Remove-AppxPackage Get-AppxPackage -allusers messaging |
| Remove-AppxPackage Get-AppxPackage -allusers connect |
| Remove-AppxPackage Get-AppxPackage -allusers contactsupport
| | Remove-AppxPackage Get-AppxPackage -allusers feedbackhub
| | Remove-AppxPackage etc...
| cageface wrote:
| Flutter is actually quite nice and works well on desktop too.
| If Google continues to develop it I could see it becoming the
| first choice for a lot of developers.
| jcaguilar wrote:
| This reminded me of The Cherno's Walnut library:
|
| https://youtu.be/-NJDxf4XwlQ
| armchair_expert wrote:
| First of all, this is an immediate rendering library which is a
| very inefficient way of rendering the UI for any application
| that is not a videogame. You are rendering the UI 60 times a
| second, regardless of whether something changed or not. Most UI
| frameworks only update when something changes.
|
| Secondly, there are things in GUI frameworks that most people
| don't think about, such as accessibility. Windows has a builtin
| accessibility API where apps can declare the objects being
| shown on the screen, so that screen readers can interact with
| the application. I'm pretty sure this guys framework doesn't
| have that.
| rovingeye wrote:
| Win32 + WebView2
| tored wrote:
| Probably the best option for the author, bit surprised that
| this was not listed as option, especially since he considered
| writing HTML/CSS for Sciter.
| pan69 wrote:
| The solution you end up with will be a compromise on your
| requirements. E.g. if you can compromise on the 40MB size
| requirement then Electron should be a good fit to cover all your
| other requirements.
|
| Microsoft has developed VSCode with Electron.
|
| https://www.electronjs.org/
| chipdart wrote:
| > if you can compromise on the 40MB size requirement then
| Electron should be a good fit to cover all your other
| requirements.
|
| Microsoft also supports React Native, which is arguably way
| better than any webview-based approach.
| pjmlp wrote:
| Unfortunely it is built on top of WinUI 3, with all the warts
| it entails.
|
| Mostly because since they killed C++/CX, there is no UI
| tooling story for doing XAML C++, without having to deal with
| IDL COM like mess in Visual Studio, only worse in WinRT case.
| canistel wrote:
| Native widgets which used to be wxWidgets' strong point, is now
| its Achilles heel? It is saddening, but the world moves on I
| guess.
|
| Sadly the same applies to Lazarus/LCL too. Not only that, I had a
| nasty surprise recently when Fedora Budgie did not install GTK2
| by default.
|
| Win32 era was fun, for development and for reversing. But alas...
| ogoffart wrote:
| I'm working on a GUI toolkit that should match the requirements:
| Slint - https://slint.dev Can be compiled statically in a single
| .exe that is smaller than 40M. Has a license that allow
| proprietary on desktop for free. Has dark/light styles. Even
| comes with a (work in progress) drag and drop WYSISYG editor.
| IshKebab wrote:
| > Can be compiled statically in a single .exe that is smaller
| than 40M.
|
| That's... quite a high bar. Last I checked even a QML app was
| only like 20 MB. Why so big?
| ogoffart wrote:
| 40MB was the criteria coming from the article. But it's much
| smaller than that. I don't have the exact number in mind. I'd
| say much less than 20MB.
| StarterPro wrote:
| I'm going through the documentation right now, and I'm a bit
| confused. How would I integrate it to use for the WInforms UI?
| CyberDildonics wrote:
| Where did the idea come from that starting with a 40MB exe is
| small? That's completely outrageous. You could embed all of
| python, tk, fltk, wxwidgets and pyqt and still not be close to
| 40MB.
|
| FLTK static binaries start at 100KB, win32 binaries can start
| at 1KB, Juce is about 2MB.
|
| Using GLFW or SDL for an openGL window then using IMGUI would
| start at a few hundred kilobytes.
|
| What are you doing in there that makes your binaries 100x times
| as big and why would this be a selling point?
| utensil4778 wrote:
| Man, as a C# dev, I'd kill for a single exe output. The
| binary being _only_ 40MB is an absolute fantasy.
|
| We have a project at work, it's nothing crazy, mostly
| shuffling data from one pipe to another, maybe a few thousand
| lines of code. A true standalone build including dotnet is
| over 180MB. The build that relies on the system dotnet
| install is still over 50MB. It's not even a GUI, it's a
| background service.
|
| Things on Windows have a bad habit of enormous binary bloat,
| I'm not sure why. I don't _think_ the problem is near as bad
| on Linux in general, but I don 't have enough experience with
| linux dev to really say
| neonsunset wrote:
| This has been solved since .NET 6/7 and the results should
| pleasantly surprise you:
|
| - https://learn.microsoft.com/en-
| us/dotnet/core/deploying/sing...
|
| - https://learn.microsoft.com/en-
| us/dotnet/core/deploying/trim...
|
| Alternatively, you could try the following first (use .NET
| 8 SDK): dotnet publish -o out
| -p:PublishSingleFile=true -p:PublishTrimmed=true
|
| Also, I just tried worker template (it includes generic
| host, DI, logger, etc.) and it's only 5 MiB when AOT
| compiled on macOS: dotnet new worker
| --aot dotnet publish -o out
|
| Will likely take less on Windows and Linux.
| wordofx wrote:
| You already have that as a .net dev.
|
| I deploy my asp.net site to Linux by building it as a self
| contained single file. Deploy services. Have a couple of
| WPF apps both self contained single file.
|
| They all end up around 43-85mb. The services are smaller
| when trimming is applied at around 30mb.
|
| Not a single project has ended up over 100mb but I can see
| that happening if you have a ton of nuget packages.
| leapingdog wrote:
| I don't know for certain but expect it comes from comparing
| solutions with those based on virtual machines like Java's.
| The requirements in the original article look like a
| corporate wish list.
| davidhyde wrote:
| OP said less than 40MB. You can build Slint binaries
| targeting embedded devices. So a few hundred KB for a small
| application. Still arguably too much space but gui frameworks
| like slint use a domain specific language that generates more
| verbose code than what a human would typically write.
| Probably in the interests of being generic.
| fuzztester wrote:
| Wasn't it mentioned in an HN post or comment somewhat recently
| (like a few weeks ago)? I think I saw it then, and checked out
| the site and a few demos at the time.
| hoten wrote:
| I've been evaluating GUI frameworks for rewriting the editor of
| a cross platform (Mac Windows Linux and web) game editor I
| maintain, and this looks worth a shot, thanks for sharing here!
|
| I want to move away from the ancient allegro GUI we use, and so
| far have evaluated ImGui, RmlUi, and Qt, but so far not totally
| sold on anything.
| user_7832 wrote:
| Thanks for the link, slint looks really interesting. As someone
| who's never made a GUI app would you consider it an "easy" task
| to make one using slink? Also I didn't see any results when
| searching the documentation for titlebar, is there any way to
| theme or change it using slink? TIA!
| alkonaut wrote:
| While it's a bit cumbersome, he doesn't really point out any
| major flaw with the WinForms/WPF ideas, other than of course
| requiring two stacks. He says he wants native code and wouldn't
| want any C# visible but doesn't explain why. Fear of reverse
| engineering? UI code rarely contains anything secret.
|
| Also the single exe deployment, while convenient at times, is
| perhaps not worth the hassle in this scenario. Using a packager
| like Velopack (squirrel) makes it a single exe to distribute and
| as an added bonus makes it self updating. That it has two or more
| files on disk when installed seems like a good tradeoff.
|
| Windows is the worst platform to develop desktop apps for, apart
| from all the others.
| chipdart wrote:
| > While it's a bit cumbersome, he doesn't really point out any
| major flaw with the WinForms/WPF ideas, other than of course
| requiring two stacks. He says he wants native code and wouldn't
| want any C# visible but doesn't explain why. Fear of reverse
| engineering? UI code rarely contains anything secret.
|
| What I find the most mind-numbing thing about the blog post is
| the way WinUI3 was excluded. WinUI3 looks like an exact match
| for the blogger's most critical requirements, specially the
| customization thing, and there is absolutely no better way to
| target Windows than Microsoft's official GUI offering, but
| somehow that one is rejected? Absurd.
| mike_hearn wrote:
| Some of the issue is he has outdated understanding of AppX
| packages (MSIX). You can use all of Win32 from an MSIX
| package, and all of WinRT, and WinUI3 etc. It's actually the
| other way around: there are some Win32 APIs that only work if
| your app is packaged.
| pjmlp wrote:
| Anyone that has used WinUI since its inception, knows that
| the best for our sanity is to avoid it at all costs.
|
| It is still years away to provide feature parity with
| UWP/WinUI 2.0, let alone the Windows Forms, WPF capabilites
| and Visual Studio tooling.
|
| Using it from C++ is only for ATL / VisuaL C++ 6.0 die hards.
| smileybarry wrote:
| WinUI3 is a can of worms that's becoming palatable only with
| .NET 8 (and soon 9). In a normal configuration, you _have_ to
| bring 500MB of dependencies with you, or ask the user to
| install a redistributable. You also need the user to install
| .NET 8, or bring said 0.5GB with you.
|
| WinUI3 can be used in unpackaged apps (I.e.: not appx) but
| has a few random caveats that just don't work; random APIs
| that have a footnote of "oh this doesn't work in unpackaged
| apps" or "works in unpackaged apps but only in .NET Preview
| something-something".
|
| .NET 8 fixes a lot of this by adding AOT compilation and
| single-binary releases, but it's still fairly large. .NET 9
| then improves culling of unused framework code from your
| published file, and also adds WPF -> WinUI3 theming support.
|
| Source: my repeated attempts to rewrite our product's UI in
| WinUI3 (from WPF on .NET Framework 3.5) several times.
| neonsunset wrote:
| What kind of build settings lead to 500 MiB binaries? I
| struggle to imagine something that could make the toolchain
| to emit such a large binary save for select degenerate
| cases of runaway generic specialization when you AOT
| compile an SDK that combines LINQ with 2102718201 enum
| types, all of which get their own set of generic
| instantiations for every internal iterator within LINQ -
| that's a known issue that is fixed by enabling identical
| method folding in ILC, the worst offender used to be Kiota
| OpenAPI generator causing this, but thanks to tireless work
| by Filip Navara that was fixed there.
|
| In general, there are quite a few knobs for configuring how
| exactly you would like to have your application published.
| This is also an area of active improvement with each new
| release as you noted. It is very worth it to look into
| further build configuration nonetheless. If you still face
| an issue with "this surely shouldn't take this much space",
| it might be a good idea to submit it to either
| https://github.com/dotnet/runtime or to the repo of the GUI
| framework depending on where you think the fault lies -
| without feedback it's difficult to know if there is an area
| that needs improvement or a known improvement opportunity
| that has demand.
| smileybarry wrote:
| It's just because the WinUI3 libraries and/or .NET Core
| runtime take that much. Mostly WinUI3 IIRC.
|
| And that's when you use "selfcontained mode" rather than
| AOT publishing, now with AOT it's considerably better.
| neonsunset wrote:
| Self-contained/single-file mode is compatible with
| trimming and benefits from the work done to improve AOT
| story. As AOT binaries get smaller and ILLink's analysis
| gets smarter, the single-file trimmed binaries will see a
| part of such improvements.
|
| The issue is that many GUI frameworks are not AOT-
| incompatible per se but rather trim-incompatible as they
| rely on reflection that is done in a way that is totally
| opaque to ILLink save for rooting everything.
|
| You can try the following publish option anyway, and in
| many instances it "just works" (assuming .NET 8 SDK):
| dotnet publish -o out -p:PublishSingleFile=true
| -p:PublishTrimmed=true
|
| Note: trimming was introduced in .NET 6, and NativeAOT
| was initially introduced in 7, so it had seen quite a bit
| of work to mature and improve by the time 8 shipped.
| pjmlp wrote:
| If only UWP had a AOT compilation story for .NET code
| that could be re-used for WinUI 3.0....
|
| And then there is the whole C# / C++ interop between
| CsWinRT and C++/WinRT.
| pjc50 wrote:
| WinUI3 itself.
|
| If you want to be "normal", or at least follow the
| Microsoft semi blessed path, and make an appx, that does
| not include WinUI3. The user installs it, and in the
| process pulls down WinUI3 (also an appx) if it is not
| already installed. It's only if you really insist on
| "self-contained" that this problem arises.
|
| I say semi-blessed because of course Microsoft aren't
| really committed to WinUI3 and barely any of their own
| apps use it.
| pjmlp wrote:
| You should browse the set of WinUI related repos, YouTube
| community calls and Developer Connection, feedback is
| something they aren't short of.
| whywhywhywhy wrote:
| I don't understand why Microsoft puts it on the user/dev to
| make sure their own dependencies and "VC redistributables"
| are installed.
|
| Like shouldn't Windows 11 just either have that already or
| pull it down as needed as it's an official MS library.
|
| Feel I always hit a roadblock when setting up a new PC
| where one of the things needs that but the dev didn't
| provide it and I have to get it myself. Which feels weird
| when it's an official MS thing from their official dev
| tools.
| HumblyTossed wrote:
| > Like shouldn't Windows 11 just either have that already
| or pull it down as needed as it's an official MS library.
|
| In this day and age of everything always connected, some
| things still aren't always connected.
| estebank wrote:
| The app manifest could state "I need this runtime
| installed". The OS can know whether it is already
| installed or not. The OS also knows whether it is
| internet connected or not. If a runtime that isn't
| installed is needed and internet connectivity isn't
| available, the OS could state that, with information
| about how to procure the runtime manually.
|
| That would stop people that have copied thr application
| from a pendrive in an air gapped system, that's true. One
| could make the case that someone meeting all of those
| requirements for would be technically minded enough to
| figure it out.
|
| This wouldn't help developers who want to distribute a
| small application that won't ever require a download, but
| would be an improvement for anyone already distributing
| .Net applications over the web.
| WorldMaker wrote:
| Microsoft's solution to DLL hell was installing lots of
| DLLs side-by-side. The problem with WinUI and VC
| redistributables is that we've now got a combinatorial
| explosion of them and teaching an installer to know and
| understand the complex network of dependencies is a lot
| of work.
|
| Microsoft's intended solution to this was to write one
| last Installer platform to try to rule them all. That's
| where AppX and MSIX installers came from. Unfortunately
| for us all, that Installer platform was synonymous with
| the Windows Store/Microsoft Store for just long enough
| that everyone assumes that is all that AppX/MSIX were
| intended to be. Today MSIX supports everything you want
| to do in a Win32 application, _plus_ all the Dependency
| Fu of getting a WinUI application correctly installed.
| Just about the only left that you can 't install directly
| in an MSIX is kernel-level drivers and even then there
| are options depending on your hardware vendor
| relationship with Microsoft.
|
| The article dismisses MSIX packaging out of hand, but
| given it is still referred to as AppX packaging in the
| article, the author might not be aware of how much MSIX
| packaging has advanced in a bunch of years and still
| makes some assumptions of MSIX limitations based on early
| Store-intended AppX restrictions.
| vunderba wrote:
| Agreed. I had the exact same question.
|
| From the article: _" The issue is that with bundling the .dll,
| it would still mean it being extracted somewhere and writing
| additional code for the P/Invoke to work, and C++/CLI gets
| compiled to .NET IL code, in other words, you can open the
| resulting app in dnSpy and see the C++ code translated to C#
| equivalent (which is not what I want, I want native code)."_
|
| I don't understand what the author is talking about. When they
| say the C++ code will be translated to the equivalent c#,
| that's not how interop works at all... the native C++ DLL is
| not somehow made magically more vulnerable to reverse
| engineering because you can p/invoke to it.
| delta_p_delta_x wrote:
| > I don't understand what the author is talking about. When
| they say the C++ code will be translated to the equivalent
| c#, that's not how interop works at all... the native C++ DLL
| is not somehow made magically more vulnerable to reverse
| engineering because you can p/invoke to it.
|
| I don't think the author is talking about interop here, but
| rather the fact that GUI front-end code written in C++/CLI
| still ends up being managed rather than compiled to native
| code. I suppose the author insists on the front-end
| executable being nothing but a PE x86-64 binary without any
| runtime/GC embedded in it, pure native code.
| alkonaut wrote:
| That insistence isn't motivated in the post in any way,
| which makes it a really weird and arbitrary requirement.
| smileybarry wrote:
| C++/CLI is managed code, it's basically C++ compiled into
| .NET IL.
|
| If you're writing C++ code running on .NET / .NET Framework,
| you're basically writing masochistic C#.
| alkonaut wrote:
| But why even use C++ for the front end if it's going to be
| .NET? Managed C++ is mostly useful as a shim, not as a
| platform language. It's not really an alternative to C# on
| the .NET runtime but just some C++ extensions for interop
| with it.
|
| If you make a WPF/WinForms frontend then _that_ should be
| the exe entry point, and that would likely be managed. Then
| your business logic would be the auxiliary DLL (which can
| be embedded into the managed exe). There could be a layer
| of C++ /CLI between these to layers (C# front end and
| native backend) because it would make the interop a bit
| easier than having to do C-style interop.
| smileybarry wrote:
| > But why even use C++ for the front end if it's going to
| be .NET?
|
| Because the author of the article wanted to use C++, I
| don't know why. That's why I called it "masochistic C#".
| pjmlp wrote:
| Actually I find it much easier to write C++/CLI, than
| getting right all P/Invoke marshaling, specially if COM is
| also part of the picture.
|
| Also C++/CLI can also generate native code when specific
| code patters are used, that is why there are some compiler
| flags to disable it, and such assemblies are considered
| unsafe.
| TheDudeMan wrote:
| Same here. People are confused because the author gave two
| options: 1. Bundle the .dll as a resource
| into the app and make it extract it to some temporary folder,
| then use P/Invoke and call the compiled .dll from within the
| C#/.NET app. 2. Use C++/CLI.
|
| And then a single "problem" paragraph that didn't make it
| clear which problems go with which approach.
| slackr wrote:
| Tried Decker?
| pugworthy wrote:
| It strikes me that having the C++ requirement is part of what
| makes this difficult. I'd like to have seen some reasoning why
| not to just use C#. Seems like it could have made some things
| easier, especially given the author's praise of XAML and
| acceptance of Visual Studio.
|
| I'm not saying C# is better than C++, but just that choosing one
| over the other does have an impact.
| chipdart wrote:
| > It strikes me that having the C++ requirement is part of what
| makes this difficult.
|
| It doesn't.
|
| In fact, it makes the problem even easier to solve due to the
| options that are already on the table. Virtually all .NET-based
| frameworks support C++ besides C#, specially WinUI3.
| pjmlp wrote:
| WinUI support for C++ is a travel back to the days of writing
| COM in Visual C++ 6.0 with ATL, only for a special bread of
| developers.
| theanonymousone wrote:
| Writing GUI apps is painful, and being probably the most
| thankless area in Software engineering doesn't help either.
| anthk wrote:
| Lazarus and Free Pascal might work here.
| Androth wrote:
| it won't. at least not with the color theme requirements. and
| if you don't care about those, you might as well use win32
| controls.
| markus_zhang wrote:
| I'm teaching myself the Win32 API for a future RE project,
| thinking that knowing it helps with the reverse engineering
| effort. I have just achieved creating a window, loading a text
| file and printing it on the main window. Scrollbars are there but
| don't work yet.
|
| It actually take s a lot of work. The boilerplate code is OK but
| I never realized that showing strings on Windows is such a PIA. I
| have deep respect for anyone who wrote Windows GUI apps back in
| the late 80s -> early 90s before RAD is a thing.
|
| As a side note. I recently got a book about WinG game programming
| on Windows 3.X/95. I remember back in the day the game Fury3, a
| fascinating 3d flight shooter game, was developed in WinG. It
| could be an interesting archeology project to develop something
| serious with WinG, the predecessor of DirectX.
| bonzini wrote:
| IIRC WinG was basically a way to set up a GDI device context
| that corresponded to a frame buffer, so you could take your DOS
| SuperVGA code and run it under Windows, only redoing sound and
| input. It's been almost 30 years though. :)
| markus_zhang wrote:
| Yeah that's probably what it was back in the day. I recalled
| games run pretty slowly on Windows before WinG came out.
| Fury3 looked pretty slick, even in today.
| Jare wrote:
| That's what it was, mostly.
|
| You could do pretty decent games using GDI as long as you
| just wanted to blit some sprites and were very much adhering
| to what GDI would give you. If I remember correctly, all the
| examples in the "GameSDK sampler CD-ROM" (the original name
| of DirectX 1.0) were in fact not done with GameSDK or even
| with WinG, but straight GDI.
| bonzini wrote:
| I think it was better and easier to set up a DIB, treat it
| as a double buffer of sorts and only use GDI to BitBlt it
| to screen.
|
| Don't ask me how you do that, though it probably would not
| take me too much to page that stuff back into my brain by
| looking at the Microsoft Win32 manuals. Maybe
| CreateDIBSection? I still remember my kernel32.dll, but not
| GDI or User.
|
| Anyway, what WinG did (and all it did) was speeding up the
| blitting part.
| markus_zhang wrote:
| I don't know much about the performance, but I guess non-
| action games should be fine?
| userbinator wrote:
| _I have just achieved creating a window, loading a text file
| and printing it on the main window. Scrollbars are there but
| don 't work yet._
|
| You could just use the standard Edit control for that. If you
| really want to do it manually, which I have done, it's less
| than ~300 lines of code for the whole app (including working
| scrollbars). The binary is less than 4k.
|
| _but I never realized that showing strings on Windows is such
| a PIA._
|
| Are ExtTextOut and related functions all that hard to use? How
| much simpler do you think it could be?
| markus_zhang wrote:
| Thanks, I don't know about that yet, so it's going to be
| while.
|
| For the string it's mostly the wchar and char stuffs. I think
| I'm getting a hang of it.
| qingcharles wrote:
| I'm amazed Fury3 worked under WinG. I used WinG for some simple
| 2D games, but I don't think I would have tried texture-mapped
| 3D!
|
| We wrote this game on DirectX 1.0. It was a pig because the
| game was designed to be all 2D sprites, but early in the
| project it became clear there wasn't enough RAM, so I wrote a
| 3D engine that integrated with the 2D backgrounds. The video
| cards of the day didn't like that shit, and there was no
| acceleration at the time.
|
| https://www.youtube.com/watch?v=9UOYps_3eM0
|
| All the DirectX code itself felt sluggish as games were coming
| from highly optimized bare-metal C/x86 to running on a multi-
| tasking OS through an API that was written in (probably) pretty
| unoptimized C++.
| markus_zhang wrote:
| Wow that looks pretty slick. Now I know why early Windows
| don't have competitive games and why things like WinG and
| DirectX are pretty big. I think Carmack did not jump on the
| DirectX wagon until much later.
| pjmlp wrote:
| Yes, he and Id pushing miniGL are pretty much why Glide
| lost and everyone was into MS-DOS and OpenGL graphics for a
| while.
|
| However by DirectX 10, he was also not happy with OpenGL
| mess, and changed his mind on DirectX.
|
| https://www.bit-tech.net/news/gaming/pc/carmack-directx-
| bett...
| pjc50 wrote:
| > I have just achieved creating a window, loading a text file
| and printing it on the main window. Scrollbars are there but
| don't work yet.
|
| > It actually take s a lot of work. The boilerplate code is OK
| but I never realized that showing strings on Windows is such a
| PIA. I have deep respect for anyone who wrote Windows GUI apps
| back in the late 80s -> early 90s before RAD is a thing.
|
| The late 90s experience with VBA and the Visual Studio designer
| is, on the other hand, _really good_. As was the proprietary
| Borland Delphi experience.
|
| You could do worse than try building an MFC app in VS to get
| something working and then reverse engineer the details out of
| that. Strings are not a pain provided you remember -DUNICODE
| and use wchar for everything (and the related functions).
| pjmlp wrote:
| That book is worth gold from Windows game development
| archeology point of view, it is quite hard to find anything
| related to WinG online.
| markus_zhang wrote:
| It's called "Dungeons of Discovery". The book includes a CD
| with resources to build a mini yet full blobber game. The CD
| also contains WinG.dll conveniently.
| abareplace wrote:
| Check out the Scrollbars series from Raymond Chen:
|
| https://devblogs.microsoft.com/oldnewthing/20030731-00/?p=43...
|
| https://github.com/mity/old-new-win32api?tab=readme-ov-file#...
| JodieBenitez wrote:
| I don't do a lot of desktop apps but for simple GUI apps I've
| been using Python and Pywebview, with packaging left to
| Pyinstaller. The main reason is that I get to reuse the
| python/javascript/css libs that I know, and it's easily portable.
| I'm sure a native app uses less memory and cpu but frankly what I
| get with this combination is not _that_ resource hungry. In fact,
| anytime something goes south it 's my fault for using poor algos.
| Also, there are tons of great GUI libs and web components.
| blep-arsh wrote:
| I was going to suggest embedding the native WebView ActiveX
| control (which I did in the past with great success) but it
| turns out the WebView has been updated and wants end users to
| download and install the Chromium-based runtime library
| nowadays.
| philipwhiuk wrote:
| There's a reason a lot of stuff is Electron.
| c-smile wrote:
| As of Sciter and "antialiasing" issues mentioned in the
| article...
|
| Author did not enable high-DPI support in his/her application. As
| simply as that...
|
| Either in Visual Studio : https://sciter.com/wp-
| content/uploads/2024/06/high-dpi-aware...
|
| Or by including proper manifest: https://gitlab.com/sciter-
| engine/sciter-js-sdk/-/blob/main/d...
|
| That actually is explained in "Hello C++" tutorial:
| https://sciter.com/hello-cpp-tutorial/
| mathverse wrote:
| Sciter desperately needs an evangelist who can reply and help
| people with their problems and just in general provide support
| and work on the ecosystem. I think from what I remember from
| indiehackers you are not there yet to be able to afford it but
| we desperately need that.
|
| Even paying pravic to keep the libraries for different
| languages up to date would be of great help.
| c-smile wrote:
| Sciter's support forum is pretty active :
| https://sciter.com/forums/
|
| Mr. Yuri (Pravic) has his own agenda these days. As far as I
| know creation of Go, Rust and Python backends for Sciter was
| a method for him to determine best frontend technology for
| his organization.
|
| If someone wants to take care about Go, Rust and Python
| wrappers - let me know.
| mathverse wrote:
| Ultimately as a user / customer I dont care who maintains
| the bindings I need to use to achieve my goal.
| c-smile wrote:
| 1. These wrappers are Open Source.
|
| 2. I do not have customers that requested either one of
| these wrappers.
|
| 3. Customers that do use one of wrappers, as AdGuard for
| example, maintain their own version of Sciter/Go:
| https://github.com/AdguardTeam/go-sciter
| mathverse wrote:
| What kind of license do I need to buy for the bindings to
| be updated?
| c-smile wrote:
| As with any other Open Source project - contact its
| author and discuss with him/her.
| pests wrote:
| Might end up being yourself.
| skrrtww wrote:
| What are the issues the author alludes to about AppX packages
| sucking? Looks like the new Fluent stuff wants you to use those.
| Curious to know what pain points exist there.
| ceeam wrote:
| Who's going to tell him about C++ Builder (Embarcadero)?
| RachelF wrote:
| No one wants to talk about it or Delphi anymore.
|
| Programmers are just as fashion-concious as the Milan catwalk
| designers.
| boznz wrote:
| This. But flares are still waiting to come back in this case.
| To get my foot in the door writing windows GUI programs I
| often have to obfuscate the fact I am using Delphi (don't
| ask, don't tell) or work with clients without big IT
| departments.
|
| Disclaimer - No clients were ever injured during this
| experiment.
| ak39 wrote:
| Same
| wiseowise wrote:
| Wouldn't that be excluded due to cost?
| gavinhoward wrote:
| I have ideas about writing a GUI framework [1], but why in the
| world would I spend the time to make it up to the author's
| standards unless someone was paying me?
|
| GUIs are a lot of work. People should be more willing to pay for
| work like that. Wanting everything free is one reason Big Tech
| has so much control.
|
| [1]: https://gavinhoward.com/2024/05/a-new-architecture-for-a-
| gui...
| IshKebab wrote:
| Frankly Qt is the only sane option. Just give up on the "single
| static exe" requirement. Your users will have to unzip a zip.
| Hardly a big deal. Certainly not worth switching your entire
| stack to something vastly inferior for.
| userbinator wrote:
| _Problem: It is extremely hard to stylize native Win32 controls._
|
| That's not a problem, it's a feature. I am absolutely bloody sick
| of apps that go out of their way to reinvent the standard UI
| controls in perplexing ways and behave unexpectedly. Following
| the system UI preferences is what you should do, and it irritates
| your users if you don't.
|
| _There is a "hidden" dark mode for Win32 controls used by
| Windows File Explorer that you can activate, but it covers only
| some of the controls and still doesn't look good._
|
| Don't do that. If you use the regular Win32 controls then they
| will automatically get the styling the user has set.
|
| I've been writing Win32 apps for close to 30 years now. It's sad
| to see the regression in UIs over the years.
| crazygringo wrote:
| As a non-Windows user, I'm confused, maybe you can clarify:
|
| > _If you use the regular Win32 controls then they will
| automatically get the styling the user has set._
|
| Does that mean they'll get dark mode if the system is in dark
| mode?
|
| In which case I don't understand what the author is complaining
| about. Sounds like dark mode would be working as intended.
|
| They want "easy styling" but I took that to mean things like
| icons, some colors, etc. Not totally replacing what buttons
| look like. I agree -- being consistent with the OS is a good
| thing.
| userbinator wrote:
| They'll get dark, light, rainbow, whatever the user has set.
|
| This was a feature since at least Windows 3:
|
| https://news.ycombinator.com/item?id=25871787
| Rohansi wrote:
| I don't think this actually reflects the new light/dark
| mode people are referring to here. It will most likely
| always be the default theme - light.
|
| Also changing those old themes has a good chance to "break"
| any (poorly made) apps doing their own themes. You could
| change some colors in the palette and parts of the UI could
| end up being difficult or impossible to read. Happens if
| the app uses a combination of palette controlled colors and
| custom colors.
| mrpippy wrote:
| Correct. For Win32 apps, the only official support for
| dark mode is some WinRT APIs to tell if it's enabled, so
| you can "adjust your application's painting and rendering
| code to use a Dark mode color set"
|
| https://learn.microsoft.com/en-
| us/windows/apps/desktop/moder...
| ack_complete wrote:
| > Also changing those old themes has a good chance to
| "break" any (poorly made) apps doing their own themes.
|
| They already do this. COLOR_3DFACE has gotten brighter
| with each successive version of Windows and in Windows 11
| is #F0F0F0. I've had to fix UIs that became unreadable as
| a result.
| jenscow wrote:
| Those colour settings are not aware of Windows 11's "Dark
| mode"
| userbinator wrote:
| Not surprising. Typical "modern" Microsoft. Reinventing
| things poorly is so common these days.
| abareplace wrote:
| No, they won't get dark mode and this is the biggest problem
| for Win32 UIs now. If Microsoft would make dark mode
| available for classic Win32 apps, it would meet all
| requirements of the original poster.
| EvanAnderson wrote:
| > That's not a problem, it's a feature.
|
| 1000 times this. I want software I'm running to look like the
| rest of the OS (and every other application) and respect my OS-
| level UI preferences.
|
| In the case of Win32 using the OS primitive controls mean that
| your application gets tons of accessibility and preference
| features "for free" (albeit Microsoft has done a good job in
| later Windows releases of removing the functionality to set
| some of these preferences).
|
| There is no value add in making your app UI look bespoke. All
| the labor you're putting into that work is labor that could be
| better spent on functionality, features, and optimization. When
| I see an overly "precious" UI on Windows (owner-drawn controls,
| animations, fades, etc) I immediately question the ability of
| the developer to prioritize.
| jenadine wrote:
| You seem to be in the minority with that thought.
|
| The evidence is that most apps nowadays comes with their own
| style, often packed in a HTML frontend.
|
| Users are used of websites which all have their own designs,
| and don't seem to mind if all apps have different look and
| feel.
| userbinator wrote:
| Most users have just developed a learned helplessness. It
| doesn't mean they don't like it.
| surfingdino wrote:
| Devs that learned web frontend dev are not familiar with OS
| GUI guidelines. When I tell them Apple used to publish GUI
| guidelines for Mac application developers they stare at me
| in disbelief.
| analog31 wrote:
| Most users are unaware that there are UI standards, and
| have no basis for comparison. They use Google to help them
| figure out how to use apps, and take hand-written notes on
| how to find the things that they need. Once they figure out
| the functions in an UI that they need, they just pray that
| it doesn't change. The average user experience is horrific.
| zigzag312 wrote:
| > I want software I'm running to look like the rest of the OS
|
| This is an impossible task on Windows, as it has multiple,
| inconsistent UIs by itself.
| EvanAnderson wrote:
| I want the apps I run on Windows to look like other Win32
| apps. I want them to use native Windows controls.
|
| All the UI "enhancements" in Windows 8 and subsequent
| versions are garbage and irritate me just as much as any
| other non-Win32 native UI.
| ricopags wrote:
| Never coded a GUI app but speaking of regressions:
|
| As a heavy windows KB user, losing the ability to alt+letter
| all the things to /quickly/ navigate windows apps is incredibly
| frustrating.
|
| I've read that Mac OS envy infiltrated the WinUI time and while
| some may prefer the aesthetics, on Windows 11 apps like mspaint
| I can no longer navigate anywhere near as quickly.
|
| From milliseconds to multiple seconds.
|
| I'm incensed at this change personally, and I feel totally
| confused by it from the perspective of MS. In the era of AI and
| automation, slower screen draw times will make a significant
| impact to performance and energy use. I hope someone like Mark
| Russinovich, Kevin Scott, or Satya Nadella will notice and
| change course.
| hobs wrote:
| It's funny that you mentioned apple because their system
| shortcuts are integrated as hell and they even let you map
| them in the OS -> App level, way better than anything MS has
| ever shipped.
| jwells89 wrote:
| Yep, among other things both Apple-unique and emacs-esque
| text navigation shortcuts are in every native textfield
| across all apps and anything that's a menu item in any app
| can have its shortcut key rebound in System Settings
| without any extra work on the part of third-party devs.
|
| It's one of the reasons why longtime Mac users are
| disinclined towards non-native apps. Most don't bother to
| reproduce these behaviors, and so when you as a user go to
| reach for these features that you have muscle memory for
| and they're not there, it's like hitting a brick wall in
| the middle of your workflow and makes the app in question
| feel basic and unrefined.
| Hamuko wrote:
| Annoyingly enough you don't really all keyboard shortcuts
| out of the box even if you build natively. If you create
| a Button(role:
| .destructive).keyboardShortcut(.defaultAction) in a
| SwiftUI dialog, you don't get Cmd+D as the shortcut even
| though Finder (and I think other apps too) uses Cmd+D as
| the keyboard shortcut for destructive confirmation
| dialogs. Thankfully at least a Button without destructive
| role will get Enter as its keyboard shortcut in the same
| context.
| jwells89 wrote:
| Yeah for now I keep most of my usage of SwiftUI
| restricted to non-Mac platforms. On macOS it's fine for
| smaller bits like collectionview cells but has a number
| of rough edges for more major use cases.
| hobs wrote:
| Don't forget you can type any of those menu items in the
| help dialog and it will not only tell you where it is,
| and not only let you activate it, it will helpfully show
| you the deeply nested set of submenus required to
| activate it.
|
| Oh and of course those shortcuts are activateable by
| other applications to simplify app integration.
| ricopags wrote:
| It's never been better than what MS had and if you think so
| you've never used the MS way as I do.
|
| Alt+underlined letter with no menus opens opens whichever
| menu maps to that letter
|
| After which any [unique, as they mostly are] underlined
| letter activates the press for that menu item.
|
| There is no equivalent to the speed of this in OSX, even
| with third party software.
|
| Very very happy to be proven wrong on this
| Dwedit wrote:
| At least you can hex-edit or resource-edit the Alt+Letter
| back into a standard windows button or menu that's missing an
| accelerator key. Just add the missing &.
| vel0city wrote:
| I'm confused by your alt key navigation in paint. I just
| opened paint and it still supports alt+key to do things in
| Paint.
| ricopags wrote:
| No it doesn't. Alt+space bring up the window system menu to
| restore/maximize/close?
|
| Alt+f, a to save as?
|
| Negative.
| vel0city wrote:
| Alt, f, a, p, saves as PNG, or j for jpeg, or o for
| other. Its changed slightly, but it is there.
|
| Alt+space is still a shortcut, but it was repurposed.
|
| You didn't "los[e] the ability to alt+letter all the
| things", they just slightly changed some of them.
| serial_dev wrote:
| As a mobile dev, it _should_ be the same for mobile apps?
|
| If you are on iOS, you could just use what Apple gives you with
| very little customizations. The app would feel right, dark
| mode, font sizes, screen traders, etc. accessibility would
| "just work" 98% of the time, the app would be fast.
|
| On Android, things are a tad bit more complicated, but it still
| applies that the closer you are to the OS, the better things
| work out of the box.
|
| But for some reason, companies, their designers, product
| owners, developers want to get creative, use their brand but
| eventually they always run out of time to implement things
| properly, so apps are slow, user's font scale settings are not
| respected, dark mode is a feature, and the app doesn't feel
| like part of the same phone / OS.
| MaxBarraclough wrote:
| They also often want to use web technologies and/or cross-
| platform GUI toolkits, to avoid reimplementing their UIs.
| eschaton wrote:
| And all because they fundamentally believe that their
| development time and expense is worth way more than their
| customer's time and expense.
| skydhash wrote:
| I strongly believe that the amount of ironing they have to
| do for that crossplatform toolkit takes more time than just
| going with a common core and different UI shells.
| Sakos wrote:
| It's even worse.
|
| > Those were only a few options that I considered. After a very
| long time trying out all sorts of different libraries and at
| one point even writing my own MFC styles, I figured out that
| for simple apps there is simply nothing better suited than Dear
| ImGui.
|
| They decided to go with the option that deviates the most from
| the standard Windows UI, where there are no native controls at
| all, and it's a nightmare for accessibility (see
| https://github.com/ocornut/imgui/issues/4122). I use it for
| prototyping privately, but I'd never make anything I want to
| release into the world with it.
| TheChaplain wrote:
| Life was good with Windows 2000, GTK2 and MacOS9, styling was
| clear and had purpose. GTK and MacOS even had extensive Human
| Interface Guide documentation.
| withinrafael wrote:
| The problem with this hands off approach is that Microsoft has
| not updated its base controls and does not provide some
| capabilities out of the box. It instead only offers modern
| controls via its Win UI 3 framework, which is squarely designed
| for C#.
| troupo wrote:
| I don't know what the situation is right now, but for the
| longest time ever standard win32 controls where even less
| useful and more anemic than even the standard web controls.
| There was always a disparity between what the OS gave you and
| what the actual good controls MS Office team would think of
| (until ribbon, but the original ribbon actually did have a lot
| of thought put into it).
| leapingdog wrote:
| I agree with you.
|
| > Easy styling, including dark mode
|
| I wonder if this requirement has been imposed from above.
|
| When the web was taking off I received designs from the UI
| architect in the form of VB6 applications. Windows was the
| dominant platform at the time. Never mind it made no sense in
| the context of more fluid HTML layouts. This was before CSS.
|
| Since then the web has probably trained the holders of the
| reins that they can violate user interface norms everywhere.
| neonsunset wrote:
| The author would have been served extremely well by AvaloniaUI
| with NativeAOT target if they were willing to drop their
| assumptions regarding C# that are no longer true. (I wonder how
| well Uno Platform fares in comparison? It targets native controls
| first and foremost but is supposedly NativeAOT compatible too)
| achr2 wrote:
| A second recommendation for Avalonia. It deserves the acclaim.
| Kuraj wrote:
| Uno is closer to a full stack rather than front-end in
| comparison with Avalonia.
| jll29 wrote:
| The amount of bloat everywhere today is simply disgusting; just
| because my group server has 1 TB of RAM isn't a justification for
| letting a "hello world" app grow to more than 50 kB, GUI or not.
|
| Yes, productivity is more important than squeezing out the last
| bit nowadays, but that the poster couldn't get his 40 MB limit
| satisfied shames the whole software industry. He should get a
| simple (i.e., half a dozen menus, dialogs, windows) GUI app done
| in 400 kB (it was possible in the past).
| dmitrygr wrote:
| "Stylized"
|
| Let me stop you right there. No.
|
| Leave the OS to style controls how it does, for consistency.
| There is no reason to be inconsistent. This is not 1994 and
| you're not writing a warez keygen
| Kuraj wrote:
| Styling functionality doesn't have to imply introducing a new
| look and feel, it might just be needed for extensibility.
| fleabitdev wrote:
| Unlike Windows, Apple and Android have managed to publish modern
| UI libraries for their own platforms - but in both cases, this
| involved migrating the whole platform to a new programming
| language (Swift and Kotlin, respectively). If I remember right,
| C# also has a few features which were only added to make Windows
| Forms and WPF more ergonomic.
|
| I'm starting to suspect that general-purpose languages just
| aren't flexible enough to keep up with changing fashions in UI
| development. Whenever somebody comes up with a new UI paradigm,
| you're not going to be able to take full advantage of it until
| somebody designs a new programming language with that paradigm in
| mind.
|
| If so, this might explain why the Windows team keeps pushing new
| desktop UI libraries, only to abandon them within a few years -
| they just don't have the willingness or resources to migrate away
| from C# and C++, and so the quality of their UI libraries is
| stuck in 2006.
| mike_hearn wrote:
| The issue is the React paradigm, which is a bit questionable to
| begin with. It's a sort of fake OOP in a trenchcoat pretending
| to be something else, whilst abusing the language in ways that
| requires compiler plugins. My experiences with Compose and
| SwiftUI have been ... not that great. I kinda wish people would
| just have kept investing in their OOP toolkits.
| fleabitdev wrote:
| You're right that reactive UI is a poor fit for most
| languages (especially JavaScript!), but I think the problem
| is more general than that.
|
| Good UI architecture needs some convenient and efficient way
| to propagate state changes between different parts of the UI
| framework [0]. This requirement sits in an awkward place,
| halfway between imperative programming and functional
| programming. It just isn't in the day-to-day vocabulary of
| any mainstream language, not even modern imperative languages
| which have a bit of functional programming mixed in.
|
| I don't think OOP is any better at fulfilling this
| requirement. Being able to offload half of your program into
| a visual editor is nice, but it's cold comfort if the other
| half of your program ends up being a tangled mess of
| callbacks and data binding.
|
| [0]:
| https://raphlinus.github.io/ui/druid/2019/11/22/reactive-
| ui....
| skydhash wrote:
| We already have a solution for most UI presented in this
| paper [1]. Functional programming let you represent the
| solution in a much nicer way after you've hidden the
| oop/imperative machinery away. But it's a complete package
| where the declarative part is only the shell. The UI part
| of any application should be considered as an external
| module, (like the data access layer) and the code
| architecture should reflect this. In an extreme way, if you
| can't create a telnet interface to you GUI software, that
| means your interface is already too coupled to the rest of
| the code.
|
| [1]: https://dl.acm.org/doi/10.1145/62402.62404
| wiseowise wrote:
| Kotlin wasn't designed with Compose in mind. They shoehorned it
| via compiler plugin.
| pjmlp wrote:
| The explanation is easy, the usual WinDev versus DevDiv
| politics.
| synergy20 wrote:
| write a cross platform GUI is even more painful.
|
| It's pretty much either paying for Qt or use the bloated
| Electron.js. Looks like the latter won the market.
|
| I failed to see other practical options, flutter was an option,
| but its strength is not on desktop so far.
| duckywise wrote:
| What was your problems when using Flutter for desktop? For me,
| it's the lack of multi-window support. There's a community
| solution but it's a bit lacking because it spawns another
| engine while the upcoming official solution uses single engine.
|
| I personally use it for my desktop apps (cross-platform) and
| building UI for it is a breeze. Though I forked someone's
| window styling plugin because it's missing some features I
| need. A native dev would've done better than me but if it works
| it works I guess.
|
| If I had to satisfy the requirement in the post though, I'd use
| enigma protector with to make the app folder into a standalone
| exe and with compression enabled to make it smaller.
| symisc_devel wrote:
| Open source GUI libraries are lacking behind the gate locked,
| closed ones like Adobe. Even Macromedia UI back in the days 20
| years ago looks way more appealing and polished than the current
| open source offering. The only polished open source UI in my
| opinion is Blender but apparently they have their own rendering
| engine built from scratch just like Adobe.
| lowleveldesign wrote:
| Apps developed for the modern (open-source) version of .NET may
| be compiled to a native code (NativeAOT). Some time ago, I tried
| AOT on a simple WinForms project and it worked. Unfortunately,
| functions using COM APIs are not yet supported (as they rely on
| reflection). There is an ongoing effort to fix this problem:
| https://github.com/dotnet/winforms/issues/4649
| neonsunset wrote:
| COM interop now works on NAOT with source generated COM
| wrappers: https://learn.microsoft.com/en-
| us/dotnet/standard/native-int...
|
| (it's unfortunate the milestone is set to future in the linked
| issue though, which includes the light-up for the feature
| above)
| Const-me wrote:
| For requirements like that, I typically write WPF C# frontend,
| combined with C++ backend. Compared to ImGui, in WPF you'll get a
| GUI designer, styling which allows easy dark mode, data bindings,
| data templates, animations, IDE support like live visual tree
| inspector, accessibility support, and more.
|
| If you use the legacy .NET 4 framework, the .NET runtime will
| come pre-installed on modern Windows. If you compile your C++ DLL
| with static C runtime, your C++ DLL won't have any dependencies
| apart from OS components like kernel32.dll.
|
| If you insist on having a single EXE you'll need to bundle it and
| extract, but the additional code for the P/Invoke to work is like
| 4 lines of that code, call LoadLibraryW from kernel32.dll early
| on startup, before using any stuff with [DllImport] from that
| DLL.
|
| I do not recommend C++ CLI. Write normal C++ which compiles into
| native code without any weird metadata. You can use C APIs, or
| COM interop with ATL, or check this library of mine
| https://github.com/Const-me/ComLightInterop/
|
| If you start with this approach (as opposed to refactoring a C++
| app you already have) you'll find out that you need substantially
| less C++ than you expected. Essentially, C++ is only required for
| 2 things: CPU-bound number crunching, and code which consumes
| large C or C++ libraries (Windows SDK is huge and pieces like D3D
| or MediaFoundation require C++). It's much easier to do
| everything else in C#, as the language and especially the
| standard library are just better.
| glzone1 wrote:
| WPF has been superseded (supposedly) by UWP / WinGUI / MAUI /
| Blazor?
| Const-me wrote:
| UWP was designed primarily for Windows phones, usability on
| desktops suffers. And it requires windows store, you can't
| just ship an installer .exe
|
| WinUI seems to be copy-pasted from UWP, same usability issues
| on desktops. Unlike UWP, it's a mess in terms of software
| quality. Also the runtime is huge, I think the size in MB
| even exceeds Electron.
|
| About MAUI, it seems Microsoft decided to make an abstraction
| over native controls. It's been tried for decades and it
| always results in the same suboptimal result because these
| GUI frameworks implement the least common denominator of
| available UX. In addition to that, on Windows that thing uses
| WinUI3 backend, see the previous paragraph.
|
| I don't know anything about Blazor, but it seems that thing
| is for web apps?
| pjmlp wrote:
| MAUI is basically Xamarin.Forms, rebranded and rewritten,
| thus forcing the whole Xamarin community to rewrite their
| stuff, or go elsewhere.
|
| Miguel de Icaza is pretty sour on this, and quite likely
| one of the reasons he is now fully into Apple ecosystem and
| Swift.
|
| Blazor started with being only a WebAssembly based
| framework, then they decided to put everthing on ASP.NET
| under Blazor umbrella, and are now pushing Blazor into
| everything that has a Webview, including the stupid idea of
| Hybrid Blazor in MAUI, basically Electron in .NET.
| glzone1 wrote:
| Blazor is interesting. They are biting off an absolutely
| metric done of stuff. I will say their development style
| -> social media etc seems good which might help drive
| some buyin. They have public roadmaps. The outcomes still
| pretty rough ("Could not reconnect to the server") when
| falling off the happy path. So it still had a bit of that
| "in theory" development style that in terms of use annoys
| developers.
| pjmlp wrote:
| Nope, the GUI story is so bad, that at BUILD 2024, WPF was
| made again an official Windows GUI framework for .NET devs,
| see BUILD 2024 sessions regarding Windows programming.
| glzone1 wrote:
| Haha.. That is too funny - I haven't been following this
| closely anymore. It's honestly wild. Does WPF still do data
| binding by reflection? I can usually "feel" a WPF app if
| I'm doing a lot of data work.
|
| I remember when WinForms (which I thought was fine!) was
| killed. Why they just didn't continue to build on that I
| don't know (yes, I've heard the explanations, the
| importance of things like having XML (barf) in the
| framework).
|
| How can you not be absolutely kicking butt on your own
| platform with a great story especially because they
| absolutely HAD a great story both at entry level LOB and
| advanced LOB.
| Kwpolska wrote:
| WinForms is still actively developed (although it wasn't
| always).
|
| I prefer XML to manually placing controls in a window and
| clicking around a designer GUI at all times. XML is
| trivially editable by hand, WinForms auto-generated C#
| isn't.
| pjmlp wrote:
| Supposedly is being worked on for making it more Native
| AOT friendly.
|
| How we got into this mess? WinDev and DevDiv politcs.
|
| After the Longhorn debacle, its technologies landed on
| DevDiv, like WCF and WPF.
|
| Sinofsky and friends never were that keen in having .NET
| coming into their turf, it is no surprise that Hilo
| sample for Windows 7, then praises COM and C++ for
| Windows applications[0][1].
|
| Then coming in this path, WinRT came to be, with roots as
| how .NET was being designed, before Microsoft decided to
| pivot it as another Java like technology[2].
|
| A bunch of folks in WinDev, weren't happy with C++/CX, so
| they united to replace it with C++/WinRT, because
| extensions, when clang and GCC are full of extensions,
| promised to give back a C++/CX like developer experience
| in 2017[3], never delivered, went to have fun with
| Rust/WinRT.
|
| Now C++/WinRT is in maintenance mode[4], and Rust/WinRT
| never took off, and is now Rust/windows-rs[5].
|
| As paying customer, impacted by those childish attitudes,
| I would have had the whole team fired.
|
| Finally, check the amount of bugs and complaints on their
| respective repos,
|
| https://github.com/microsoft/microsoft-ui-xaml
| https://github.com/microsoft/WindowsAppSDK
| https://github.com/microsoft/cppwinrt/
|
| And then compare with Project Reunion vision from 2021,
| and where we are three years later
|
| https://blogs.windows.com/windowsdeveloper/2021/03/29/ann
| oun...
|
| Mainly because along the way, as if those changes weren't
| enough, they also decided to reboot their initial
| approach with Project Reunion, WinAppSDK took another
| route, and here we are.
|
| This is only a short overview of how WinRT went down
| since Windows 8, thus only those that never advocated for
| it, can honestly suggest WinUI, as they lack the
| background of how chaotic it all is.
|
| [0] - https://devblogs.microsoft.com/cppblog/announcing-
| hilo/ [1] - https://learn.microsoft.com/en-us/previous-
| versions/msdn10/f... [2] -
| https://arstechnica.com/features/2012/10/windows-8-and-
| winrt... [3] -
| https://www.youtube.com/watch?v=7TdpWB_vRZM&t=2983s [4] -
| https://github.com/microsoft/cppwinrt/issues/1289#issueco
| mme... [5] - https://github.com/microsoft/windows-rs
| glzone1 wrote:
| This at least explains what from the outside looks like
| total insanity.
|
| What's been confusing is they've been chasing all sorts
| of things (phones / tablets / web development) so clearly
| had money to burn, but couldn't deliver a basic solution
| for their own platform.
|
| Clean simple line of business apps (ie, datagrid /
| listviews needs to work etc with bigger excel type
| datasets) + maybe RemoteApps or some other remoting
| option for SAAS type deployment would have been a nice
| option to have for plenty of folks.
|
| For a lot of use cases the modern solutions are both
| worse to develop for AND are slower / buggier - so you
| get little for the effort
| gardaani wrote:
| WPF seems to be one of the preferred native UI platforms:
|
| "Microsoft will refresh WPF with new Windows 11 theming and
| hyphen-based ligatures support for Microsoft .NET 9 and will
| continue to invest in WPF as one of the two preferred native
| user interface platforms on Windows."
|
| The other preferred native UI platform seems to be WinUI 3:
| "WinUI 3 joins Windows Presentation Foundation (WPF) as the
| two recommended native UI platforms for developers."
|
| https://news.microsoft.com/build-2024-book-of-news/
|
| I don't know about MAUI / Blazor.
| kumarvvr wrote:
| I have been trying to learn WPF for a long time, but have
| drifted into web apps.
|
| Can you point me to any good resources to be able to make
| complex multi window apps in it?
|
| I have good experience in Windoes forms and am well versed in
| c# and dotnet.
| garaetjjte wrote:
| >The issue is that with bundling the .dll, it would still mean it
| being extracted somewhere
|
| Hmm, this got me thinking about stuffing native code into CLR
| image. If you would just include additional executable code
| sections into PE, would loader map them normally? Or presence of
| IMAGE_DIRECTORY_ENTRY_COMHEADER would stop it from mapping native
| code? If so, maybe you could remove that header and manually do
| pre-XP style initialization, by calling _CorExeMain from imported
| mscoree.dll. Though you would need to somehow trick it into
| locating COMHEADER that we removed.
|
| Or maybe I'm overthinking this and MS already supports that?
| https://learn.microsoft.com/en-us/cpp/dotnet/mixed-native-an...
| anothername12 wrote:
| Also check out IUP. It's lovely to work with and uses native
| controls. https://www.tecgraf.puc-rio.br/iup/
| Dwedit wrote:
| WX Widgets still exists.
| thefz wrote:
| Nope, not at all. Winforms is still actively maintained and
| sports native advanced features like MVVM and async support. And
| winforms is not even the only option.
|
| I disagree with the entire aeticle.
| fassssst wrote:
| Just use WinUI 3. Opting into MSIX packaging no longer requires
| an App Container sandbox.
|
| More info here: https://learn.microsoft.com/en-
| us/windows/msix/desktop/deskt...
|
| Full disclosure: I work at Microsoft.
| withinrafael wrote:
| runFullTrust apps are still subject to file system and registry
| redirection as well as various capability checks. Running fully
| unencumbered requires restricted capabilities that only
| Microsoft can approve.
| mike_hearn wrote:
| You can opt out of those with manifest metadata. Capabilities
| aren't enforced if you distribute out of the app store.
| withinrafael wrote:
| The OS will enforce them at installation/launch time
| regardless of distribution method.
| mike_hearn wrote:
| Yes but what I mean is you can declare any capabilities
| you want, nothing prevents you just asking for whatever
| you need except Store review.
| jenscow wrote:
| you can turn some of that crap off:
| https://learn.microsoft.com/en-
| us/uwp/schemas/appxpackage/ua...
| withinrafael wrote:
| Note the warning on the page.
|
| > This element requires the unvirtualizedResources
| restricted capability.
|
| And if you click through the restricted capability link:
|
| > If your app declares any restricted capabilities, then
| you must provide info during the app submission process in
| order to be approved to publish your app to the Microsoft
| Store.
| jenscow wrote:
| For >1 minute incremental compile times? No thanks.
| zerr wrote:
| Where's the GUI designer?
| pjmlp wrote:
| WinUI 3 XAML C++ is a joke, versus the old C++/CX tooling in
| Visual Studio.
|
| Editing IDL files without any kind of Visual Studio tooling,
| manually merging generated C++ code, no designer.
| djbusby wrote:
| I don't see any mention of WinAmp yet. That app really whipped
| the llamas ass when it came to styling. And was super easy to
| create custom skins.
|
| I'm all-on-board with look like the OS/platform but also, here's
| and example of custom styling done well.
| asveikau wrote:
| > It would require me to write a custom paint function for every
| single control, which would take so much time I could raise a
| family in the meantime
|
| This is a weird comment that shows the philosophy of old school
| win32 has not clicked for them. The key element in win32 is the
| wndproc. Most controls ask their parent what color they should be
| via a window message.
|
| If you find this inconvenient, wrapping that in a small library
| to remove boiler plate is not a big deal.
| ack_complete wrote:
| > Most controls ask their parent what color they should be via
| a window message.
|
| There are a LARGE number of areas where this is not provided,
| such as the text color of a disabled control or the checkbox
| area of a checkbox control. Even for the cases where such
| customization points were provided, many of them were broken
| when theming was added in Windows XP and in comctl32.dll
| version 6 in Vista, which ignores some of them in favor of
| theme colors or images. Menu colors, for example, are ignored
| when theming is enabled.
|
| The result is that if you want something approaching a
| reasonable dark theme with Win32 stock controls, you will often
| need to resort to full owner-drawing of the controls. This is
| not a minor task.
| MikeTV wrote:
| Do you happen to have links to any good
| documentation/articles on this topic? I'm working on what
| amounts to a dark theme for Win32 controls and largely making
| it up as I go along, relying on tidbits and off-hand mentions
| from defunct blogs.
| ack_complete wrote:
| Afraid not, had to piece together a lot of it myself. There
| are lots of examples available for various components of
| varying quality -- you'll find some code examples that
| don't work well with high DPI or all of the sub-modes of a
| control.
|
| Some controls like buttons, list boxes, list views are
| reasonably well behaved, especially when theming is turned
| off. Combo boxes and toolbars are more temperamental. Check
| boxes, scroll bars, menus, and message boxes require a lot
| of custom painting work.
| MikeTV wrote:
| Would you mind sending me an email (address in profile)?
| I'd love to pick your brain about some of the trickier
| ones I'm running into.
| adzm wrote:
| Check out my win32 dark mode menu bar in case it comes in
| handy.
|
| Also I know far far too much about the internals of classic
| win32 rendering if you have questions
|
| https://github.com/adzm/win32-custom-menubar-aero-theme
| davee wrote:
| I have a reasonably complete implementation of dark mode in
| my open source application, Explorer++. It uses the
| standard Win32 controls and applies a variety of strategies
| to get something that looks more-or-less cohesive when dark
| mode is enabled. ThemeManager.cpp[0] contains the bulk of
| the functionality. It could be useful as a reference for
| how you might create a dark version of a standard Win32
| control.
|
| [0] https://github.com/derceg/explorerplusplus/blob/4bad3ab
| 95d87...
| wiseowise wrote:
| Did someone suggest Flutter yet?
| ZoomZoomZoom wrote:
| > uses native Win32 components and offers no styling options
|
| It's a feature.
|
| Custom styling should be considered a hostile pattern in most
| cases, except in highly specialized software with workflows
| dependent on prior user experience, such as DAWs.
| ozim wrote:
| Yes full agreement from me.
|
| I think loads of energy is wasted in development because
| someone wants custom stuff like buttons or input boxes without
| real reason where off the shelf GUI would work and would be
| much cheaper.
| zigzag312 wrote:
| > Custom styling should be considered a hostile pattern in most
| cases
|
| Why? Almost every website has custom styling and yet it doesn't
| seem to inhibit users from using them.
|
| Good UI/UX patterns seems to be universal. As consistency is
| part of good UI/UX there are things that should be consistent
| with the underlying platform. But consistency with the platform
| is not equally important for all things. For some things, like
| window management, it's much more crucial, that it is for other
| things, like roundness of buttons.
|
| > except in highly specialized software with workflows
| dependent on prior user experience, such as DAWs
|
| It's not just about prior user experience. If a custom control
| enhances UX for a specialized task, it has a good reason to
| break some of the consistency. All specialized software (DAWs,
| graphics applications, IDEs etc.) have such features. Limiting
| themselves to just native components would lead to a suboptimal
| user experience.
| bux93 wrote:
| How would you know inconsistency among websites isn't
| inhibiting users from using them? There's not a Web A and Web
| B to do A/B testing on.
|
| Roundness of buttons? Buttons shouldn't be round in the first
| place. Back in the day, they were these rectangular things
| with a shadow and a highlight. You could instantly things you
| can and cannot click on. Now, it's anyone's guess. Do people
| click on the wrong stuff? Do people fail to discover
| functionality because it's hidden in plain sight? Of course
| they do!
|
| Is there a place for custom components, yes, but not to the
| extent that every website out there is styling their buttons,
| and that even Windows itself is hiding scroll bars.
| zigzag312 wrote:
| There's a lot of A/B testing going on on the web.
|
| > Buttons shouldn't be round in the first place.
|
| Is there any data available to back this up?
|
| Modern UIs are not perfect by any means, but from what I
| remember, those old UIs were not great either... even worse
| in terms of UX on average.
|
| While consistency is important, placing it above all else,
| leads to suboptimal UX and bland UIs. How many times did
| you hear people raving about how great is the UI of an app
| build with a generic form builder?
| eXpl0it3r wrote:
| What about a simple dark mode, that even the OS provides
| options for?
| banish-m4 wrote:
| A. If a gun were placed to your head and you had to write a
| native Windows app, what stack would you use?
|
| B. And, if you had to write a cross platform app, which framework
| would you use?
| bruce343434 wrote:
| A. imgui and SDL2
|
| B. imgui and SDL2
| banish-m4 wrote:
| That's not what I asked...
| tored wrote:
| A. PureBasic
|
| B. PureBasic
| qw wrote:
| If money was not an issue, I'd probably try Delphi for both A
| and B, which can create native cross platform apps.
|
| If not, I'd try Lazarus for A and Kotlin compose for B A:
| Lazarus or Delphi (if money was not an issue)
|
| B: Kotlin compose or Delphi (
| bloblaw wrote:
| I presume we are talking about GUI programs:
|
| A. Delphi --- easy choice (or C++ Builder if I had to use C++)
| B. Also Delphi --- it supports macOS (arm64 + x64), Linux, and
| Windows
|
| If I have to write a CLI app, I'm probably picking Go or Rust.
| petabyt wrote:
| libui libui
| firebot wrote:
| There's tools to pack dependencies into a single executable, that
| then extracts those dependencies, as necessary, upon execution.
| the__alchemist wrote:
| I've been using EGUI to write GUI programs. Works nicely and runs
| on both Linux and Windows without notable differences. (I haven't
| tried Mac, but it presumably will work there as well without
| changes). Small binaries (a few Mb), and can integrate with maps,
| 3D rendering etc.
| ModernMech wrote:
| Yes it also works on MacOS, and web as well.
| hermitcrab wrote:
| >Alternatively, you can buy a commercial [Qt] license for several
| thousand dollars.
|
| There is a small business option that is cheaper. But probably
| still not appropriate for this project.
| avsteele wrote:
| I tried to write a windows App recently (maybe to put in the
| windows store). I gave up when ...
|
| - Tried to wade through the mess of different frameworks. Some
| are abandoned, they all have different feature sets etc...
|
| - I found that I could not have anything other than FullTrust
| (all permissions) if my app wanted to use the/live in the system
| tray.
|
| - You can't set the size of the window to match the content. You
| can set a size, sort of, but the min is 500x500 AND it will
| remember what the user's last size was so if they e.g. maximize
| it will be the next time its opened regardless of the program
| settings. In order to do this simple thing I would have to write
| it as a WPF app with a installer (which as of 2023 can go on the
| Windows Store)
| cryptica wrote:
| One thing I learned about the software industry is that a lot of
| the tools we use are objectively horrible, but it doesn't matter
| because somehow big tech manages to shove it in our faces anyway.
|
| Also, the inverse that really good software tools often don't see
| the light of day is also true. It really doesn't matter if some
| tool is good or bad for adoption. What matters is; does it have
| the backing of big tech? It shows that tech media is completely
| monopolized.
| johnea wrote:
| Qt is the hero
| Lariscus wrote:
| I have a very low opinion of developers who decry having to pay
| for a commercial licence for otherwise LGPL licensed software
| libraries. They expect to be paid for their work, and ensure that
| by creating closed source software. That's fair enough. Yet, the
| devs that solved the actually difficult parts of creating a UI
| library have to be utter saints who freely bestow a gift of code
| upon the world.
| kelnos wrote:
| Agreed. Also didn't get why he felt complying with the terms of
| the LGPL for a statically-linked .exe would be so much of a
| problem. Just put the object files and build script in a zip
| file, and upload it to the same webserver where you plan to put
| the program. Add a line in the "About" dialog (or whatever)
| pointing to it. Done.
| eptcyka wrote:
| Whilst I don't understand the users who are hell bent on
| having a single-executable work, if you have users who are
| hell bent on using but a single executable, you have to meet
| them where they're at.
| jnhzubh wrote:
| In my experience Windows users don't care about the
| statically linked part
|
| What they care about is having an executable and not
| needing a zip with dlls
|
| And that is trivially achievable by bundling the dlls into
| the exe file
| mavamaarten wrote:
| Also trivially achievable by making an installer instead
| of shipping separate files. People are really used to
| that pattern.
| madduci wrote:
| Exactly this.
|
| Qt is amazing, so if your requirements are so strict in terms
| of space and you know/like Qt, investing in the license, or
| make the product open source, shouldn't be an issue here.
| hsn915 wrote:
| I think his complaint is not that he has to pay money per se,
| but having to pay several thousand dollars. That's a bit much
| for an independent developer.
| Lariscus wrote:
| I have little sympathy for that kind of argument, imagine a
| carpenter complaining that they have to buy wood and nails.
| Besides, a Qt license for small businesses is nowhere near
| thousands of dollars. Only in software development do we
| expect quality tools to be given to us free of charge with no
| strings attached.
| daemin wrote:
| Qt for Application Development Professional (ADP) is 3460
| EUR/Year.
|
| If you're making something which you sell for $50 or so
| you'd need 100 sales per year to just pay for the
| development environment. That also assumes that it took you
| less than a year to make said product.
| Lariscus wrote:
| 'Qt for Application Development Enterprise - Small
| Business (ADE-SB)' is $499.
| daemin wrote:
| You're right. I didn't see the Small Business tab when I
| was quickly looking through it.
|
| Still ends up being a blocker when you're not sure how
| many copies of the product you'll sell.
| Lariscus wrote:
| I guess that is just one of the many risks you have to
| take if your trying to build a business. A couple of
| hundred dollars in licensing fees are not going to sink
| your product. For a side project that you don't expect to
| make any money it might be too much, but in that case you
| could just as well open source the project.
| pantulis wrote:
| > but in that case you could just as well open source the
| project.
|
| Which doesn't necessarily mean you cannot get paid for
| it.
| CSSer wrote:
| It's also worth considering that the value of this
| license is very likely not a net loss even if your
| initial product doesn't work out.
| hsn915 wrote:
| Your take is very weird.
|
| He's shopping around. When something is out of his budget
| it's natural to not buy.
| dvngnt_ wrote:
| wood makes sense to pay for. wood doesn't grow on trees.
| software works a bit differently though it should also be
| paid for
| daemin wrote:
| It's especially hard when the application you're building
| isn't yet proven. As there's no guarantee that it will get
| any sales, let alone enough to cover the Commercial Qt
| expenses.
| jnhzubh wrote:
| You do not have to pay before your first sale.
|
| And $500 is laughable small compared to developer salary.
| If it saves you half a day of work, you are covered
| hermitdev wrote:
| There is a huge gulf between saving a half a day of work
| versus _having_ $500 to spend on a tool that would save
| you that half day of work.
| zer0zzz wrote:
| No, it makes perfect sense to complain about paid software
| libraries because it inevitably makes getting to them a huge
| pain in the ass and that causes folks who just want to easily
| give the library a try every reason to go try something else.
| Then as a result the ecosystem of apps using sad framework
| begins to stagnate.
| shrimp_emoji wrote:
| Writing anything for Windows is painful. Writing it on Windows is
| even painfuler.
| bonestamp2 wrote:
| > Writing the GUI part of the program should not take more time
| than the actual functionality
|
| I don't understand why this is a rule. I mean, I don't know what
| the author is trying to build, but in general the GUI is the part
| that the users spends all of their time interacting with. I don't
| see why it would be a problem if a little more time was spent
| there.
| mshekow wrote:
| I agree.
|
| Also, in my experience, writing UI code is usually more(!) work
| than writing the functionality underneath, because
|
| a) styling / layouting has to be learnt from scratch (e.g.
| because of a proprietary language, e.g. QML or QWidgets for Qt)
|
| b) you have to take care of every frikkin' single user
| interaction (which becomes worse the more dynamic and custom
| your UI is), and building proper accessibility is also no walk
| in the park
| shortrounddev2 wrote:
| It's a real engineer's way of looking at UI, as a necessary
| evil to have the user use the "real" part of the software
| bonestamp2 wrote:
| I work on several enterprise apps that are .NET but the GUI is a
| webcontainer with a web app. Unless there is something
| particularly high performance happening in the GUI, this works
| really well for several reasons:
|
| 1. We can update the gui without the user installing an update.
|
| 2. Lots of great web ui libraries, designers, and developers to
| make it look great.
|
| 3. Relatively lightweight
| squarefoot wrote:
| "Writing GUI apps for Windows is painful"
|
| Until you discover Delphi/Lazarus.
| pjmlp wrote:
| And C++ Builder as well.
| squarefoot wrote:
| Yes of course. Extending the Lazarus ecosystem to support
| more languages would be a killer feature.
| cookiengineer wrote:
| Some day I wish for someone to rebuild Lazarus with go and
| yaegi.
|
| Then I would never use anything else ever again.
|
| Lazarus' UI component library is beyond amazing, and growing up
| with it as a teenager made me realize how bad everything else
| is in comparison.
| syngrog66 wrote:
| ah, the intersection of 2 anti-patterns: GUIs and MS Windows. lol
| hgs3 wrote:
| > It would require me to write a custom paint function for every
| single control, which would take so much time I could raise a
| family in the meantime.
|
| Implementing a custom paint routine _is_ how you do theming in
| many UI toolkits. I get the impression the author is looking for
| a toolkit with _declarative_ theming, like CSS.
| smittywerben wrote:
| Microsoft: Here are cool windows for Windows.
|
| Microsoft: Oh, yeah, to use it, you'll need to deploy it with the
| Microsoft Store.
| airstrike wrote:
| Shoutout to the Rust library `iced` which is cross-platform,
| amazing, and can do anything you need it to at blazing fast speed
| and low memory footprint: https://github.com/iced-rs/iced
| fuzztester wrote:
| Did they try JUCE?
| wolpoli wrote:
| > The result should be a single .exe file with no or minimal
| dependencies and a size of less than 40MB
|
| Computers come with a modern browser now. Instead of a .exe file,
| could it be, let's say, a single .html file with inlined
| image/css/javascript?
| athanagor2 wrote:
| Yeah I thought of this too. Wrapping this with Tauri should not
| be too hard, and quite space-efficient
| wudangmonk wrote:
| So much time spent on creating many different web frameworks to
| try and replicate the snapiness of native applications when the
| solution was to make native applications use web-tech so that
| both are equally slow. Mission accomplished! Genius!.
| pjmlp wrote:
| You just redicovered HTML applications from Internet Explorer
| 5.
|
| Greetings from 1999.
|
| https://www.developer.com/guides/ie5s-html-applications/
| xbar wrote:
| For someone who demands so much of other people's open source,
| the author is quite unwilling to open source their solution.
| throwaway2037 wrote:
| Reading many of these comments makes me realise that the whole
| premise is flawed. I "vote" to rename this blog post as:
| > Writing GUI apps for Windows is painful when requirements are
| unrealistic
|
| They should try to target .NET Framework 3.5 using WinForms. That
| is my best suggestion, as all recent versions of Windows will
| have this installed (at least).
| taspeotis wrote:
| .NET since 6 (I think) can be published as a self contained app
| with the runtime included.
|
| It immediately adds some size to the output but you can
| mitigate it with AOT and trimming.
| AmateurAlert wrote:
| AOT is currently only available in CLI apps. It's expected
| for WinUI 3 apps using WASDK v1.6 closer to the end of the
| year.
| taspeotis wrote:
| Oops, I googled it and you're right.
| neonsunset wrote:
| Not limited to CLI (even at release in .NET 7 it was
| possible to use it with ASP.NET Core with limitations and
| there were custom templates to make it work with some GUI
| framework I think, and MonoGame already worked partially),
| certainly not in .NET 8. I'm not sure about WinUI 3 itself,
| but _a lot_ of things today are AOT compatible.
|
| And naturally single-file + trimmed works almost
| everywhere, in some situations requiring to add attribute
| annotations for un-analyzable reflection usage patterns.
| pjc50 wrote:
| "Single file" has the annoying property that it unpacks
| all your assemblies at runtime and dumps them in a
| temporary directory. There's no good reason it couldn't
| byte-load them directly out of the executable instead.
| neonsunset wrote:
| Do you mean IncludeNativeLibrariesForSelfExtract
| attribute? This is a related but still separate feature.
| If you mean the managed assembles, then it works
| differently:
|
| "Only managed DLLs are bundled with the app into a single
| executable. When the app starts, the managed DLLs are
| extracted and loaded in memory, avoiding the extraction
| to a folder. With this approach, the managed binaries are
| embedded in the single file bundle, but the native
| binaries of the core runtime itself are separate files."
|
| https://learn.microsoft.com/en-
| us/dotnet/core/deploying/sing...
|
| For """embedding""" native dependencies into the binary
| without self-extract, you can't really do that, the
| closest alternative is statically linking them into AOT
| compilation instead (but that gets tricky with large
| dependencies).
| MarkSweep wrote:
| Windows Forms is also making some progress on being fully
| AOT compatible:
|
| https://github.com/dotnet/winforms/issues/4649
| ack_complete wrote:
| .NET Framework 3.5 is no longer installed by default starting
| with Windows 10.
| alkonaut wrote:
| No go for net 4.6 which is installed on every currently
| supported Windows version back to the original Win10 released
| almost a decade ago.
|
| There are still people running Win 7 but I wouldn't worry about
| that group having a streamlined experience. With 4.6 they can
| still install the runtime manually.
| brnt wrote:
| Why 4.6 and not 4.8? (I assume you mean .Net Framework and
| not .Net.)
| scruple wrote:
| Anyone reading this thread will surely roll their eyes and
| move on to a different solution. Event the people who
| recommend this stuff to others get confused about what the
| fuck is even happening in the .NET ecosystem.
| bux93 wrote:
| The requirements are not just unrealistic, but, you know,
| wrong?
|
| > It is extremely hard to stylize native Win32 controls.
|
| Yes, it should be! I know Microsoft is errant in its ways
| itself, but controls should not be custom, they should be
| standard.
| dkersten wrote:
| Dear ImGui is nice but beyond basic styling, it's not exactly
| quick and easy to style. It also lacks any kind of accessibility
| features, which is fine when you're making tools for games or
| similar (ie highly visual tools), but if you're making anything
| meant for a wider audience, you really should use something with
| solid accessibility support so stuff like screen readers work.
| ChicagoDave wrote:
| Wouldn't Electron solve this problem?
|
| Build a web app and use Google V8 with your c++ code.
| cerrorism wrote:
| I would like to show my appreciation to the author of this blog,
| although a lot of comments here show otherwise, as the
| restrictions the author has involved here are considered as
| "unrealistic" or "unreasonable".
|
| Whenever an article is trying to compare several options, it is
| very important to know beforehand what the author is trying to
| achieve, and what the restrictions are. And in this blog, the
| author has clearly stated that the restrictions are to develop a
| GUI within 40MB and should be easy styling. No one should judge
| the author for the restrictions, as it may be from the author's
| specific needs, or directly come from the client's requirements.
| The clear restrictions are also very helpful for readers like me
| to understand the trade-offs the author has made, which is not
| something that I have to do myself, but I can definitely learn
| from the author's experience. If I am in a similar situation, or
| even with different restrictions and need to make a different
| trade-off, the author's experience can still be very helpful for
| me.
|
| Just want to call out that it is not a fair ask for a blog post
| to exhaustively compare all the options, as it is very time-
| consuming for even a paying job. We learnt the specific
| restrictions that the author is facing to, and we learnt the
| author's experience with the options that the author has tried.
| That is already a lot of value that the author has provided to
| us, and I would like to thank the author for that.
| graynk wrote:
| Writing GUI apps for anything is painful, if we're being honest.
| To this day I haven't seen a single good GUI framework for any of
| the platforms that I've tried. Flutter feels nice though
| gyomu wrote:
| UIKit has a few frustrating details, but overall it stands tall
| above the competition.
|
| For a long time the main downside was that you had to deal with
| Objective C, which is a turnoff for some people.
|
| Swift solved all this, and writing UIKit in Swift is mostly a
| joy. Sadly now SwiftUI is the new shiny thing, and it's a major
| downgrade in most dimensions save for a few.
|
| A cross platform framework that reuses UIKit conventions and
| supports all modern languages (C++/Rust/Go/Python/Nim) would be
| the dream.
| dusted wrote:
| "Problem: It is extremely hard to stylize native Win32 controls."
| No. Don't style them. Let the users settings dictate how your app
| looks. This is the correct way.
| bambax wrote:
| LuaRT (https://luart.org/) came up here a couple of months ago;
| would it meet the requirements?
| JourneyJourney wrote:
| This looks quite promising! I love LUA simplicity and I've
| always wondered if I could built commercial-grade desktop apps
| with it. So far I only considered something like LOVE, but
| LuaRT could be a good alternative.
| boffinAudio wrote:
| I just write GUI's in tkinter (python), build a single .exe with
| nuitka, and interface with generalized application functionality
| either as a .dll or python module ..
|
| tkinter may not be the sexiest way to do things, but its
| definitely productive in terms of the code-compile-distribute
| methodology, and it is very easy to wire up to a generalized
| 'daemon'-style abstraction, where the app logic is implemented as
| a daemon, sent application commands over a well-greased socket.
|
| With this architecture, I no longer care that its Windows
| underneath - this is just another platform target - and can
| easily use either MacOS or Linux as the development environment,
| needing only to test on Windows, ultimately.
|
| Anything beyond the sphere offered by tkinter is just less
| appealing. If I have to start treating a platform target in any
| kind of 'special' way, I just lose interest in that target, as a
| whole - however, from a UI perspective, Windows tkinter support
| hasn't been that bad, and generally keeps up fine.
|
| (Disclaimer: if I really need performance, I also use the JUCE
| framework for my needs - even though its an audio-centric
| framework, you can build GUI apps with it just as well, and its
| also a cross-platform way to do things in pure C++ ..)
| neonsunset wrote:
| Oh god, seeing TkInter applications, and inevitably, having to
| fix them particularly on macOS just fills me with rage. Whoever
| reads this - do not use TkInter.
| daemin wrote:
| Like the author I too did an evaluation of various UI frameworks,
| though I ended up settling on WTL (Win32 with some ATL). I might
| switch away from it and make my own Win32 wrapper in time but for
| now it works well enough and writing custom controls that feel
| like standard controls is relatively easy. If you handle the
| drawing correctly it is also one of the fastest and snappiest
| systems around.
|
| I had the exact same issues with WinUI3, where each time I
| compiled and wanted to run the application I had to install it
| into Windows, with its own start menu entry and registry entries
| and all that stuff. Really inconvenient and not worth it unless
| you like and desire that "new app" look of the Settings etc.
|
| Qt wasn't too bad but you still had to do a similar install step
| within CMake to make the necessary Qt DLLs available to your
| application to run it. It's also not the fastest system around
| for UI.
| rubymamis wrote:
| Why do you think Qt isn't fast? Qt apps can be VERY fast. My
| block editor[1], written in Qt C++ and QML is 4x faster than
| Bike - a native macOS app - that is already very efficient and
| performant.
|
| [1] https://www.get-plume.com/
| boxed wrote:
| This was a big reason I switched to the mac many years ago. I was
| a win32 programmer professionally, but I was more productive on
| mac after a week or so of hobby fiddling around.
|
| There is simply no contest. MacOS 10.0 was far superior as an
| environment to develop desktop apps when released, than Microsoft
| Windows is today with any toolkit you might want to choose.
| okasaki wrote:
| > Problem: When linking dynamically, there are a myriad of
| different .dlls required to run the app, totaling over 40MB.
|
| Is 40MB a lot nowadays? Eg the argocd cli is 155MB, and that's
| just a relatively simple cli app that as far as I know just calls
| a remote api.
|
| Welcome to bloatworld I guess.
| mmargerum wrote:
| Delphi is the superlative windows desktop development tool. It
| does support styling and just about anything else you would want.
| There is a free alternative in Lazarus but I don't know if it
| supports styling
| robertlagrant wrote:
| Tauri[0] is another HTML/CSS/JS-converter that generates small
| binaries by relying on the presence of WebView. Works pretty
| well.
|
| [0] https://tauri.app
| gchokov wrote:
| It was a breeze, back in the RAD / Delphi days..
| p0w3n3d wrote:
| I've been a strong lover of Qt, but I've just undestood that one
| cannot statically link it. Tbh it's never been the case in my
| situation, usually writing in PySide bindings which will never
| link dll/so libraries, however in certain situations this would
| get really expensive, if static linking would be required.
| I am writing this article while it's 32degC inside my room.
|
| It took a horrendous heat to make a programmer find the best GUI
| library, but it was worth it! 500KB for imgui? Seriously? I
| remember Inno Setup creator saying that we was compiling his
| 'boot' application (to reduce size, because it was glued as a
| prefix to a zip file) in Delphi 2...
| donatj wrote:
| > Writing the GUI part of the program should not take more time
| than the actual functionality
|
| Oh man, I wish. No such tool exists. Adding a GUI to anything
| almost always at minimum triples the complexity.
| renegat0x0 wrote:
| The requirements are strict.
|
| For myself I rarely write app. Most often I self-host programs.
| GUI is managed by a browser.
| openrisk wrote:
| One would think that after three decades of the windows metaphor
| and billions of man-hours writing such applications, writing GUI
| apps (for any platform) would be a much more pleasant experience?
|
| One could imagine a framework that would absorb all this
| historical know-how and turn GUI app development into a zero
| marginal cost exercise (fast, functional, cheap and maybe even
| pleasant) but who would push for this and why?
|
| Maybe its a case of somebody not learning a lesson when their
| economic interest depends on not learning it?The overview of
| existing frameworks (including browser/webview based) suggests
| there is a sort of stagnating stalemate that feels sub-par but
| probably works just fine for those who have any leverage over the
| status-quo.
| shortrounddev2 wrote:
| There is a UI framework which is fast, functional, cheap, and
| (depending on your personality) pleasant: the web browser.
|
| HTML and CSS are go-to strategies not just because the web is
| the target platform for probably most if not almost all user
| interfacing software these days, but because HTML and CSS are
| _very_ forgiving. Native UI frameworks are written by software
| engineers who demand type safety and XAML-like features which
| convert declarative syntax into imperative /object-oriented C#.
| The truth is that the vast majority of people who work on user
| interfaces are not the kinds of software engineers who enjoy
| this; HTML's model of creating arbitrary blobs of flexible dom
| nodes (and then using javascript to handle user interactions)
| is a lot more pleasant than getting compilation error after
| compilation error in XAML and having to google how the hell you
| display a set of items in a ListBox, only to have to filter
| through 4 or 5 different slight variations in the proper types
| between WinUI 3, WPF, UWP, and Maui.
|
| Native desktop software will never beat web browsers as long as
| you're forced into using the framework's model for structuring
| your data and code. 13 year olds learn HTML, CSS, and
| Javascript, that should be the target for usability with native
| UI frameworks
| openrisk wrote:
| There is certainly a strong case for the web platform as an
| all-weather gui platform but on actual mobile and desktops of
| here and now it is not a no-brainer choice. Its document
| oriented nature fits some use cases better than others. Not
| to mention that with the near exclusive focus on
| (incompatible) javascript frameworks it is not exactly clear
| even what "html" means...
| shortrounddev2 wrote:
| It seems to have become the no-brainer choice. Lots of
| mobile apps just load html views, and probably most desktop
| apps I see these days are just electron apps. You can
| reason about the best use case for HTML vs XAML vs Swift,
| but it seems that the speed of development time and the
| insane amount of community support out there has made the
| web the clear winner
| skydhash wrote:
| And the quality of software has gone downhill. HTML and
| CSS can be RAD, but they rely on millions of line of code
| in the browser engine while having subpar models for gui
| layouts and custom widgets. And building a native app is
| not that necessarily complex, it's just different.
| shortrounddev2 wrote:
| The market prioritizes speed of development and cost of
| labor over runtime efficiency. Thus, until native app
| frameworks become easy and fast to develop for, we will
| continue to see everything turn into a web app
| HumblyTossed wrote:
| On the rare occasion I find myself needing to write a windows
| gui, I just use winforms. I don't have to muck about with XML
| nonsense and it just works.
| mrcsharp wrote:
| I don't see Avalonia[1] mentioned here. Maybe that would work? It
| has AOT support too so should help with distribution and file
| size.
|
| [1] https://www.avaloniaui.net/
| jerf wrote:
| When people ask "why isn't there an awesome native widget set for
| my favorite language?" I have often said that GUIs are way, way,
| _way_ harder than you think. It 's easy to create a toolkit for
| your exact use case, but to create a toolkit that fits _everyone
| 's_ use cases to some degree is vastly, vastly larger than merely
| creating a programming language and a reasonable standard
| library. Vastly.
|
| This is a great example of why. A small set of reasonable
| requirements and already almost all the options on what is
| probably the best-endowed OS for toolkits are almost all
| disqualified, and what did fit was an odd solution that won't
| work for a lot of other use cases. It isn't that these are
| unreasonable requests per se, it is that this is how this space
| works. _Everybody_ has weird requirements of some sort, pretty
| much all the time, and getting even _reasonable_ coverage is a
| huge, huge project.
| dgellow wrote:
| WPF is still a perfectly viable solution
|
| > The issue is that with bundling the .dll, it would still mean
| it being extracted somewhere and writing additional code for the
| P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in
| other words, you can open the resulting app in dnSpy and see the
| C++ code translated to C# equivalent (which is not what I want, I
| want native code).
|
| I don't understand how that makes WPF a non-viable solution. The
| author seems to have pretty strong feeling that it should
| absolutely be native code, but it's not clear why
| scherlock wrote:
| Yeah, I've done custom skinned apps in WPF that were deployed
| via zip file. Unzip and run the exe. Worked fine and even did
| p/invoke. Either they are ignorant about MS windows development
| or just a fanciful idea about how it should work.
| warvair wrote:
| Just use Godot (https://godotengine.org).
| speedypete wrote:
| Pay for a professional tool and get RAD Studio (C++Builder/Delphi
| combo) from Embarcadero.
| https://www.embarcadero.com/products/rad-studio
| jacinabox wrote:
| Actually a lot of people are saying that Linux is the best
| platform for developing GUIs.
| Andrex wrote:
| Every OS/environment should have a GNOME Builder equivalent.
| account42 wrote:
| > Writing the GUI part of the program should not take more time
| than the actual functionality
|
| That's rarely a reasonable expectation. Good usability _is_ hard
| work.
|
| > I figured out that for simple apps there is simply nothing
| better suited than Dear ImGui.
|
| If you hate your users, sure. For anything more than a toy please
| use a real GUI framework.
| ropejumper wrote:
| > If you hate your users, sure. For anything more than a toy
| please use a real GUI framework.
|
| Do you have any actual real criticism?
| marcellus23 wrote:
| Dear ImGui's own readme recommends against using it for user-
| facing UIs. One showstopper is the lack of accessibility
| support.
| Log_out_ wrote:
| Don't ,don't say that,every time you say that windows gains
| another guiframework that precents fixes to winforms,the only one
| they support..
| FactKnower69 wrote:
| >WinUI
|
| >modern Windows components
|
| I swear to God if I ever downloaded a piece of open source
| software from GitHub, opened it, and saw the deformed Windows 8
| Metro UI gawping back at me, I would do everything in my power to
| wipe the blighted individual responsible from the face of the
| fucking Earth
| ramesh31 wrote:
| > Writing the GUI part of the program should not take more time
| than the actual functionality
|
| I can't stand this mentality. The GUI _is_ your functionality.
| The rest as far as the user is concerned may as well be pixies
| and fairy dust. Treating UI as an afterthought is why we 've
| ended up with so much nightmarish crap these days.
| bigmattystyles wrote:
| I'm a fan of a self hosted web service bound only to localhost,
| then you serve a HTML with all the bells and whistles from that
| web service. I think they used to call it OWIN. I guess the major
| downside is that you might get a localhost cert warning if you
| don't install a self-signed cert and a root cert in the PC's cert
| store (which yes, yikes)
| pshirshov wrote:
| I had a similar struggle. I needed a truly cross-platform
| (Windows, Linux/Wayland, Mac, iOS, Android) GUI toolkit with rich
| controls library and reasonable theming. In fact, the only good
| option is QT and it's very hard to be productive with C++, it
| still lacks even basic features, like type deconstruction and
| ADTs/GADTs with exhaustiveness checks. QT bindings for other
| languages aren't mature enough.
|
| Apart from QT, there is Avalonia, which is full of bugs. Linux
| support is remarkably bad.
|
| Also there is Kotlin/Compose Multiplatform. It lacks good
| documentation, advanced controls and still full of bugs.
|
| I was unable to find any good controls library for JS/TS, even
| paid ones (like Telerik and others) are pretty messy. So,
| Electron, Capacitor, React Native - they all assume a non-trivial
| effort to be put into even a very basic app.
|
| Flutter feels extremely immature, and the strange popularity of
| global singletons makes it extremely hard to navigate even small
| codebases.
| kergonath wrote:
| Are there serious issues with wxwidgets? When I was looking for
| this sort of things it was unglamorous, but had decent bindings
| with several languages and looked decent enough. I agree with
| your assessment of the other alternatives.
| pshirshov wrote:
| If I go with C++, I'll take QT, which has lot more extensive
| controls library and in fact allows me to be more productive
| than wxw.
|
| Unfortunately, the main productivity limiter is C++ and
| that's something I really want to avoid. I've been writing
| C++ professionally for about 8 years so I think I can make
| such statements.
| demondemidi wrote:
| Electron = nontrivial effort? What is so hard about Electron?
| The boilerplate is a snap, compared to Qt/Win32 boilerplate.
| Where do you fall down?
| pshirshov wrote:
| You need something else to run your electron app on mobiles.
| Ok, you take Capacitor, fine. Probably you'll take React (or
| something else) to manage your state. Great. You still need
| some UI toolkit. Literally all of them, even the paid ones,
| are pretty basic and dumb. So, most likely you'll have to
| make your UIs pretty basic and dumb, or reinvent the world
| and/or dig through tons of half-baked libraries which
| deprecate faster than you manage to integrate them.
|
| Modern QT (with QML) has very low amount of the boilerplate,
| all the 7guis examples can be implemented with 20-80 LoCs and
| will run on all the platforms, although despite all the
| modernization efforts, C++ still feels dated and it's nearly
| impossible to be productive with it. The main issues are:
| lack of pattern-matching with type deconstruction, lack of
| ADTs/GADTs, lack of closed hierarchies, lack of
| exhaustiveness checks, lack of closed type hierarchy (no
| top/bottom), lack of typeclasses, lack of first-class
| functions (yes, while there is some syntactic sugar, it's
| just a sugar, e.g. you can't return two different lambdas
| depending on the template parameter from one template
| function).
| gopher_space wrote:
| After doing a "Hello World" window for every feasible GUI
| toolkit I'm starting to think I should be looking for reasons I
| can't just use Godot.
| demondemidi wrote:
| As someone who spent most of the early 1990's writing Win32 apps,
| it doesn't seem like much has changed! MFC has always been a pain
| to use, especially coming from X and Motif.. even Athena widgets
| were better than MFC.
|
| I've used QT in the past decade for MWL (Mac/Win/Lin) and it is a
| bit clunky compared to the graphical fluidity of Electron. We
| just need a solid effort to make Electron smaller. Granted, one
| can build smaller variants, but even 100 MB is far too large.
| pregnenolone wrote:
| I've had a good experience with JavaFX and I even managed to AOT
| compile two faily complex applications of mine. My advice would
| just be to stay away from FXML. Also use jlink to build a
| stripped down JRE for your application and package it with
| jpackage.
___________________________________________________________________
(page generated 2024-07-01 23:02 UTC)