61–70 of 577 posts
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/
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 cr…
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...
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.
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.
Earlier quoted context omitted.
Totally agree with this. I’ll get shot for this one but I write most of my GUIs in Excel these days.
Do you mean Visual Basic for Applications? How are you creating a GUI in Excel?
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…
> 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 baffli…
In that case, any Qt fork would force him to also comply with the GPL, and supply the source code of his project.
Earlier quoted context omitted.
> 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 baffli…
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.
It's not a problem.
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.
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.
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 cr…
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.
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.
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.
[flagged]
