Ask HN: How do you create a cross-platform GUI without using Electron?
111 comments
Is there a particular language that you needed to use or have skills in? That's a very important qualifier.
Python, JavaScript a little of C, and similars
So in Python, you can use Qt but I am not sure how their licensing works. You can give Tkinter a try in Python since it's a "default". Also there's Kivy but I don't have experience in that.
As for Javascript, you can use Electron or React Native but I don't know how far along React Native on the desktop is compared to Electron.
Hope that helps and someone may come along that could speak in more depth on one or more of these packages for your use case.
As for Javascript, you can use Electron or React Native but I don't know how far along React Native on the desktop is compared to Electron.
Hope that helps and someone may come along that could speak in more depth on one or more of these packages for your use case.
QT?
QT https://www.qt.io/ is one option I know of. There might be some Python or Golang libraries?
imgui
There are several options, each with their own pros and cons.
Qt [1]
The main codebase is C++, but bindings are available for Python and several other languages. I have developed and shipped multiple cross-platorm applications using Qt, using both C++ and Python. Documentation and source code examples are readily available.
JUCE [2]
Another C++ framework, with Python bindings. The focus is on music and audio apps, but a cross-platform GUI framework is also part of the library.
Blazor Desktop [3]
I have developed C# web applications using Blazor and WASM and moved them to the desktop easily. Using C# and the Dotnet ecosystem is really interesing and worth looking at.
Flutter for Desktop [4]
Still in beta, but has the support of Google, for better or worse.
JavaFX [5]
A Java cross-platform still under active development. I think it is pretty nice if you like Java.
Red [6]
Let's add an outsider just to keep things interesting!
This github site seems somewhat current about other Electron alternatives as well. [7]
Good luck! You will find there are lots of alternatives out there.
[1] https://www.qt.io/
[2] https://juce.com/
[3] https://visualstudiomagazine.com/articles/2021/02 /17/net-6-preview-1.aspx
[4] https://flutter.dev/desktop
[5] https://openjfx.io/
[6] https://www.red-lang.org/p/about.html
[7] https://github.com/sudhakar3697/electron-alternatives
Qt [1]
The main codebase is C++, but bindings are available for Python and several other languages. I have developed and shipped multiple cross-platorm applications using Qt, using both C++ and Python. Documentation and source code examples are readily available.
JUCE [2]
Another C++ framework, with Python bindings. The focus is on music and audio apps, but a cross-platform GUI framework is also part of the library.
Blazor Desktop [3]
I have developed C# web applications using Blazor and WASM and moved them to the desktop easily. Using C# and the Dotnet ecosystem is really interesing and worth looking at.
Flutter for Desktop [4]
Still in beta, but has the support of Google, for better or worse.
JavaFX [5]
A Java cross-platform still under active development. I think it is pretty nice if you like Java.
Red [6]
Let's add an outsider just to keep things interesting!
This github site seems somewhat current about other Electron alternatives as well. [7]
Good luck! You will find there are lots of alternatives out there.
[1] https://www.qt.io/
[2] https://juce.com/
[3] https://visualstudiomagazine.com/articles/2021/02 /17/net-6-preview-1.aspx
[4] https://flutter.dev/desktop
[5] https://openjfx.io/
[6] https://www.red-lang.org/p/about.html
[7] https://github.com/sudhakar3697/electron-alternatives
Is there a good grid control (ie a data grid) for Blazor? A colleague reviewed the offering from Infragistics and it wasn't anywhere near their WPF data grid control.
There are grid controls from the usual commercial vendors like Radzen and Telerik. I used them briefly during a free trial. It has a funny name, but MudBlazor [1] has been the MIT licensed library I have been using lately. I have been using their Table control, which may be what you are looking for in a data grid. [2] Check it out and see.
[1] https://mudblazor.com/
[2] https://mudblazor.com/components/table#api
[1] https://mudblazor.com/
[2] https://mudblazor.com/components/table#api
Funny, I actually use JUCE for audio and yet it never crossed my mind to use it as a general purpose cross platform UI. Good call!
From https://juce.com/get-juce "JUCE is dual licenced under both the JUCE licence and the GPLv3."
Pricing isn't too bad if you don't want to go the GPL route.
If your funding or revenue is $50k and under, there is no cost, but there is a "Made with JUCE" splash screen.
If your funding or revenue is $500k and under, $800 one time fee and there is no splash screen.
You can pay $2600 once with no revenue or funding limit and no splash screen.
Free for education.
If your funding or revenue is $50k and under, there is no cost, but there is a "Made with JUCE" splash screen.
If your funding or revenue is $500k and under, $800 one time fee and there is no splash screen.
You can pay $2600 once with no revenue or funding limit and no splash screen.
Free for education.
If you have access to Python 3.5 or 3.6, you can use my open source library https://build-system.fman.io to create a Python / Qt app with an installer for all the OSs in minutes. Python 3.7-3.9 is also supported, but only available commercially.
I am really looking forward to the day that I can build cross-platform GUI apps in Red. Based on Rebol, it is a beautiful yet powerful language. They are always looking for more contributors, if anyone is interested.
Here's an example of what it could do on macOS four years ago: https://www.red-lang.org/2017/07/063-macos-gui-backend.html
Edit to add: You can build cross-platform GUI apps in Red now but, while they're very close to the finish line, and making progress every day, there are still a few missing pieces yet to complete on the 1.0 roadmap.
Here's an example of what it could do on macOS four years ago: https://www.red-lang.org/2017/07/063-macos-gui-backend.html
Edit to add: You can build cross-platform GUI apps in Red now but, while they're very close to the finish line, and making progress every day, there are still a few missing pieces yet to complete on the 1.0 roadmap.
any good open source one?
godot: https://godotengine.org/
most of godot UI itself is made with godot engine
I'm thinking of using godot for the GUI on a decently complex Windows application. I'm concerned that Microsoft is no longer interested in desktop applications and I don't want to embark on something that has no long term future.
I'll get shot for suggesting this most places, but I feel like GTK has the most 'native' feel across every operating system. That's not to say that it's easy to get working (setting up proper build targets is going to be your biggest hurdle), but your reward is a stylish and robust UI with proper touchscreen support on Windows/Linux.
> but I feel like GTK has the most 'native' feel across every operating system
That's not true since GTK3, where GTK started to look like GTK regardless of the platform.
That's not true since GTK3, where GTK started to look like GTK regardless of the platform.
I personally think the exact opposite. GTK needs a lot of custom styling to get the "native" style to work, and even then it's kind of lacking.
GTK feels right at home in the GNOME desktop environment (which I use, and like!) but for cross platform I don't really think it feels native at all. As a user, I've had much better native experiences with QT or WxWidgets to be honest (on Windows, at least).
GTK feels right at home in the GNOME desktop environment (which I use, and like!) but for cross platform I don't really think it feels native at all. As a user, I've had much better native experiences with QT or WxWidgets to be honest (on Windows, at least).
GTK doesn't look native in KDE, yet QT looks more native in Gnome.
I recently built one using Fyne for golang. It works well for my case but Fyne is still very new and in development.
http://fyne.io/
http://fyne.io/
Qt/QML is my choice.
It would be really nice if there was a shared widget API that would work for the major operating systems. If most of simple app could work on Windows, OSX, maybe mobile (Android / iOS) and Linux / BSD.
Something that was mostly native for all of them.
Currently the only alternative to Electron that is similar is a program that hosts a local webserver and the local browser is pointed at it, but that's a second class experience.
Something that was mostly native for all of them.
Currently the only alternative to Electron that is similar is a program that hosts a local webserver and the local browser is pointed at it, but that's a second class experience.
I think wxWidgets fills this role pretty nicely. It's what, e.g., Audacity and FileZilla use.
My biggest criticism is more that the widgets library really should already _be_ there, and ideally updated automatically, on a client's system.
Hello World (GUI) shouldn't be a 50MB deliverable. If I'm providing someone with a toaster I shouldn't have to ship a whole mobile home. Nor should that end user need to park 300 mobile homes on their hard disk.
There are other criticisms about wxW in specific linked from the wikipedia page... https://en.wikipedia.org/wiki/WxWidgets#Criticism
Dolphin's is illustrative of the pain involved in using that widget set. https://dolphin-emu.org/blog/2017/06/03/dolphin-progress-rep...
Hello World (GUI) shouldn't be a 50MB deliverable. If I'm providing someone with a toaster I shouldn't have to ship a whole mobile home. Nor should that end user need to park 300 mobile homes on their hard disk.
There are other criticisms about wxW in specific linked from the wikipedia page... https://en.wikipedia.org/wiki/WxWidgets#Criticism
Dolphin's is illustrative of the pain involved in using that widget set. https://dolphin-emu.org/blog/2017/06/03/dolphin-progress-rep...
[deleted]
https://www.fltk.org/ - fast light graphics toolkit
https://nanogui.readthedocs.io/en/latest/ - nanogui
What is the status on the different FLTK versions?
I haven't used this, but it should be mentioned:
https://tauri.studio/
https://tauri.studio/
I'm not the best person to explain or recommend it, but I'll suggest "immediate mode" GUIs partially because I want to hear more about the pros/cons from those more experienced (I haven't ever worked on UIs professionally). It seems these graphics libraries just need some kind of context to draw to, like from OpenGL, and also have a simpler implementation in general. That might make them more portable and smaller, if less native-feeling. I just started looking into egui (a Rust crate) myself.
I love IMGUIs but you have to be careful with the to get them to play nice with the event loop. If you're using it for a game where you're drawing every frame anyways, they're great. But for something that the user might keep running alongside other apps they can be a cpu/memory hog. You can of course only process/redraw when an event happens but that can be easier said than done sometimes.
https://tauri.studio/ - I haven’t used it myself but looks pretty interesting. They say they use existing browser engine shipped with OS and desktop integration layer written in Rust. The claim is that you get an application size under 1MB
Interesting, but say good by to consistency across platforms.
The whole reason electron was created is because using a random unknown browser on the OS has random results.
The whole reason electron was created is because using a random unknown browser on the OS has random results.
Can you share any insight in the cross-os implementation inconsistencies of those browser engines?
Not a front end developer, and I do not know much about it, but I imagine that native engines would be Edge on Windows 10, Safari on iOS and whatever is installed on Linux by default - usually Firefox. From here you would need to figure out the differences between those engines with something like caniuse. Like support for service workers etc.
Used this for a small linux GUI proof-of-concept.
I really liked it. It was awesome to use something I'm familiar with (Next.js) and have it drive the UI. Resulting application was indeed about 1MB after all said and done.
I really liked it. It was awesome to use something I'm familiar with (Next.js) and have it drive the UI. Resulting application was indeed about 1MB after all said and done.
You probably are wasting your time - multi-billion dollar companies have abandoned native desktop development - pretty sure they decided it was just easier and cheaper to maintain. If you are doing this for fun or profit - you need to decide how much your time is worth.
There is also an interesting solution to this problem: use native WebView, so you don't have to pack the whole Chrome with your app. Basically every "electron alternative" with HTML+CSS+JS works this way.
https://github.com/sudhakar3697/electron-alternatives
https://github.com/sudhakar3697/electron-alternatives
You'll have a little bit more testing to do, as the web-views shipped by different OS might not be exactly in sync feature wise, but if your app is really simple it shouldn't be much of a problem.
NodeGui [0] is an option I haven't seen mentioned here yet. It comes in many flavors [1] [2] [3].
[0] https://docs.nodegui.org/
[1] https://react.nodegui.org/
[2] https://vue.nodegui.org/
[3] https://svelte.nodegui.org/
[0] https://docs.nodegui.org/
[1] https://react.nodegui.org/
[2] https://vue.nodegui.org/
[3] https://svelte.nodegui.org/
I personally like wxWidgets:
https://www.wxwidgets.org/
It's open source, the code has always felt reasonably clean to me, and it gives your apps native look and feel.
It's open source, the code has always felt reasonably clean to me, and it gives your apps native look and feel.
I second this choice. It is the only toolkit that looks native in Windows.
And it is ridiculously fast compared to alternatives.
And it is ridiculously fast compared to alternatives.
I'm currently writing a cross-platform toolkit, and I'd like to know what native looks like in Windows. As far as I can tell it's worse than Linux. You have the old Win32 / MFC style widgets, and programs like Notepad++ that use something that looks similar. There's the style that much (but not all) of the Control Panel seems to use (is the name Metro?), but the only application that I've used that uses anything similar to that is the Edge browser. There's also the MS Office style, but that seems like a one-off, except that Explorer seems to use it. I've heard things about WFC, which seems to be deprecated, no idea what it looks like. I really dislike the Windows experience, so I have limited recent experience since I avoid using it as much as possible, but so far every application I've used looks different.
I'd like to know what the "native experience" is supposed to be, but I have no idea which of the numerous Microsoft UI APIs is officially current. So far I've just punted and I'm using macOS shapes and sizing and using the colors from the Metro? style; at least it will look tasteful and not stand out too much color-wise.
I'd like to know what the "native experience" is supposed to be, but I have no idea which of the numerous Microsoft UI APIs is officially current. So far I've just punted and I'm using macOS shapes and sizing and using the colors from the Metro? style; at least it will look tasteful and not stand out too much color-wise.
> You have the old Win32 / MFC style widgets
That's the one. Everything else has never gained enough traction.
That's the one. Everything else has never gained enough traction.
Windows 8 really broke the UI, to support tablets, and the OS has never recovered. :(
Tauri looks promising if you can code Rust
Sciter [1] is kind of a really lightweight electron. It's about 8Mb, cross platform, and you can either run it standalone (like electron) or use it as a library from Rust/D/Python/C#/whatever. You pay for the small size with a lack of compatibility with the existing Javascript ecosystem. Any moderately complex JavaScript library that interacts with the dom will probably use something that Sciter doesn't implement, so you end up reimplementing stuff like graph libraries. On the other hand there are a couple of very useful additional APIs that regular browsers don't have (like SQLite, control over window borders, transparent windows etc).
1: https://sciter.com/
1: https://sciter.com/
https://news.ycombinator.com/item?id=28469498#28475543
> Free and open source: https://www.lazarus-ide.org/index.php
> Other 30+ cross-platform GUI toolkits / frameworks: https://www.slant.co/topics/983/~best-cross-platform-gui-too...
Lazarus has the opposite problem of all the other UI toolkits - relatively awesome UI across all platforms (especially if you're a fan of WinForms) but stuck with only support for Pascal.
> Free and open source: https://www.lazarus-ide.org/index.php
> Other 30+ cross-platform GUI toolkits / frameworks: https://www.slant.co/topics/983/~best-cross-platform-gui-too...
Lazarus has the opposite problem of all the other UI toolkits - relatively awesome UI across all platforms (especially if you're a fan of WinForms) but stuck with only support for Pascal.
I'd highly suggest using Dart and Flutter.
I've probably written GUI apps in C, Java, Ruby, Objective-C, Swift, JavaScript, and probably a couple I forgot about. Dart+Flutter come the closest to being "good" and correct. There's some missing documentation for Desktop development with regards to Flutter + Dart but nothing is totally intractable if you're willing to read through issues. My only caveat is that Google is truly an awful company to depend on for your business; since, they 100% do not give a a single fuck about you unless you're paying them ~$100 million or more a year, or an EXTREMELY high profile client.
I've been getting ready to give Pascal a solid try but I still totally lose my mind when working in Lazarus (like where did the thing I just used go? Ah yes, tiny, free-floating window, of course). I have a feeling Pascal is probably the real diamond in the rough of UI application development these days.
Qt is probably fine but their licensing turns me off from ever using or considering it.
I've probably written GUI apps in C, Java, Ruby, Objective-C, Swift, JavaScript, and probably a couple I forgot about. Dart+Flutter come the closest to being "good" and correct. There's some missing documentation for Desktop development with regards to Flutter + Dart but nothing is totally intractable if you're willing to read through issues. My only caveat is that Google is truly an awful company to depend on for your business; since, they 100% do not give a a single fuck about you unless you're paying them ~$100 million or more a year, or an EXTREMELY high profile client.
I've been getting ready to give Pascal a solid try but I still totally lose my mind when working in Lazarus (like where did the thing I just used go? Ah yes, tiny, free-floating window, of course). I have a feeling Pascal is probably the real diamond in the rough of UI application development these days.
Qt is probably fine but their licensing turns me off from ever using or considering it.
> Qt is probably fine but their licensing turns me off from ever using or considering it.
If I may ask why? They provide GPL and LGPL, and this last one is quite permissive.
See: https://www.qt.io/licensing/open-source-lgpl-obligations
> In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.
If I may ask why? They provide GPL and LGPL, and this last one is quite permissive.
See: https://www.qt.io/licensing/open-source-lgpl-obligations
> In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.
Doesn't Flutter fail point 1: all widgets are custom rendered (OpenGL) things? So integration with the host OS's capabilities may be lacking (e.g. accessibility features).
Qt has been mention a lot, it's confusing all the license deal. I kind of understand that is free of use if it's not embedded.
But flutter looks like a good option.
But flutter looks like a good option.
Delphi, believe it or not. Might even be the most mature and feature-rich of any of the technologies and frameworks mentioned here.
RAD Studio 11 just got released and allows native development for "all platforms" from a single codebase and GUI at the click of a button. [0]
I have ranted about and harshly criticised Embarcadero's misguided product policies as much as the next guy but that doesn't change the fact that Delphi is still the most mature and versatile Rapid (sic) Application Development environment out there, especially if UX and UI are important to you.
And the twenty-year old adage that you can knock out an MVP with a really nice and polished GUI in a Saturday afternoon is now even more true than ever.
In the end, a native binary with a small footprint (easily 1/100th the size of an Electron project) will fall out at the press of the F9 key and that's really something to behold...
The free Delphi community edition [1] might even offer all the features that you need, although I really wish Embarcadero would see the light already and sync its release cycle with the full version.
Delphi might not officially be regarded as hip or cool these days (mostly due to severely and ongoing errant product and community management by the company that makes it) but some great people and brilliant minds are associated with it and compared to the olden days Delphi is now somewhat of a secret underground Swiss army knife that ironically gets used now mainly in big and medium corporations.
I like to think its versatility combined with the fact that it's technically uncool and against the mainstream to do projects in Delphi these days might fit a hacker's (and HN user's) mindset very well...
[0] https://www.embarcadero.com
[1] https://www.embarcadero.com/products/delphi/starter?aldSet=e...
RAD Studio 11 just got released and allows native development for "all platforms" from a single codebase and GUI at the click of a button. [0]
I have ranted about and harshly criticised Embarcadero's misguided product policies as much as the next guy but that doesn't change the fact that Delphi is still the most mature and versatile Rapid (sic) Application Development environment out there, especially if UX and UI are important to you.
And the twenty-year old adage that you can knock out an MVP with a really nice and polished GUI in a Saturday afternoon is now even more true than ever.
In the end, a native binary with a small footprint (easily 1/100th the size of an Electron project) will fall out at the press of the F9 key and that's really something to behold...
The free Delphi community edition [1] might even offer all the features that you need, although I really wish Embarcadero would see the light already and sync its release cycle with the full version.
Delphi might not officially be regarded as hip or cool these days (mostly due to severely and ongoing errant product and community management by the company that makes it) but some great people and brilliant minds are associated with it and compared to the olden days Delphi is now somewhat of a secret underground Swiss army knife that ironically gets used now mainly in big and medium corporations.
I like to think its versatility combined with the fact that it's technically uncool and against the mainstream to do projects in Delphi these days might fit a hacker's (and HN user's) mindset very well...
[0] https://www.embarcadero.com
[1] https://www.embarcadero.com/products/delphi/starter?aldSet=e...
Have you tried Free Pascal with Lazarus[1]? How does it stack up compared to Delphi?
[1] https://www.lazarus-ide.org/
[1] https://www.lazarus-ide.org/
I like Lazarus and I think it's great and important that it exists, especially with Embarcadero refusing to recognise and take seriously the needs of a developer community outside of Fortune 500 orgs (I'm slightly exaggerating but not much).
Lazarus is Free Software, which is awesome, and its feature set is also mature and impressive (I wouldn't have thought that the project also has a 20+ year history already).
I do recommend it highly if you can't get your hands on Delphi, don't want to support Embarcadero's antics, or work with an open-source project anyway. Several major component developers, including the great guys at TMS with their cloud pack and Raspberry Pi components [0] make a ton of awesome components that are available for both Delphi and Lazarus and I can highly recommend them.
If you're operating in the commercial space and have a budget, a bigger team, strong network, database or certain other commercial requirements, you might appreciate the support options and greater choice of 3rd party components which can be installed in Delphi with just a click and that save just so, so much time in getting your product to market.
If you're learning or teaching the language, working in a small team or alone, or require a feature set fully supported by Lazarus or just like free software, I wholeheartedly recommend Lazarus as a great alternative indeed. If you're somehow in the middle, check out the Delphi Community Edition too and just find out what suits you better. I guess it also comes down to what you're used to...
[0] https://www.tmssoftware.com/site/products.asp?t=lcl
Lazarus is Free Software, which is awesome, and its feature set is also mature and impressive (I wouldn't have thought that the project also has a 20+ year history already).
I do recommend it highly if you can't get your hands on Delphi, don't want to support Embarcadero's antics, or work with an open-source project anyway. Several major component developers, including the great guys at TMS with their cloud pack and Raspberry Pi components [0] make a ton of awesome components that are available for both Delphi and Lazarus and I can highly recommend them.
If you're operating in the commercial space and have a budget, a bigger team, strong network, database or certain other commercial requirements, you might appreciate the support options and greater choice of 3rd party components which can be installed in Delphi with just a click and that save just so, so much time in getting your product to market.
If you're learning or teaching the language, working in a small team or alone, or require a feature set fully supported by Lazarus or just like free software, I wholeheartedly recommend Lazarus as a great alternative indeed. If you're somehow in the middle, check out the Delphi Community Edition too and just find out what suits you better. I guess it also comes down to what you're used to...
[0] https://www.tmssoftware.com/site/products.asp?t=lcl
> take seriously the needs of a developer community outside of Fortune 500 orgs
Yeah no kidding. Last year I tried to download the trial of their paid C++ IDE. The licensing tool wouldn't work, and support never returned my emails. People complained in the official forum, no company response their either. I took that to mean "We see you as such a low-value potential customer, we won't lift a finger to get our own demo to work for you".
Yeah no kidding. Last year I tried to download the trial of their paid C++ IDE. The licensing tool wouldn't work, and support never returned my emails. People complained in the official forum, no company response their either. I took that to mean "We see you as such a low-value potential customer, we won't lift a finger to get our own demo to work for you".
Does the community edition work on linux, or compile to linux? The page says:
> Delphi Community Edition is a full featured IDE for building iOS, Android, Windows and macOS apps ...
But looking at the feature matrix for the full product it says:
> deploy to the platforms you need to support and with RAD Studio that includes Windows, macOS, iOS, Android and Linux!
> Delphi Community Edition is a full featured IDE for building iOS, Android, Windows and macOS apps ...
But looking at the feature matrix for the full product it says:
> deploy to the platforms you need to support and with RAD Studio that includes Windows, macOS, iOS, Android and Linux!
https://www.embarcadero.com/products/delphi/product-editions
> Build Linux client / server applications (includes FMX GUI for Linux) The RAD Studio Linux Compiler enables compiling applications to popular Linux platforms. FireMonkey GUI for Linux extends the FireMonkey UI framework to provide full Linux GUI support.
Only offered on Enterprise ($4K) / Architect ($6K) editions.
> Build Linux client / server applications (includes FMX GUI for Linux) The RAD Studio Linux Compiler enables compiling applications to popular Linux platforms. FireMonkey GUI for Linux extends the FireMonkey UI framework to provide full Linux GUI support.
Only offered on Enterprise ($4K) / Architect ($6K) editions.
> The free Delphi community edition
For a moment I was tempted to look into Delphi again, as I have spend many years in that environment. However, I see now its free until you hit USD 5.000 revenue per year. Not 0 USD, not USD 50.000, but only USD 5.000. Yes, that is the Embercadero that I knew. Probably this 'free' edition is canceled next year. Would not be the first time...
Edit: yes, still only runs on Windows
For a moment I was tempted to look into Delphi again, as I have spend many years in that environment. However, I see now its free until you hit USD 5.000 revenue per year. Not 0 USD, not USD 50.000, but only USD 5.000. Yes, that is the Embercadero that I knew. Probably this 'free' edition is canceled next year. Would not be the first time...
Edit: yes, still only runs on Windows
I've successfully built apps with Python and Qt (PyQt6 and PySide6 are both working fine). The overall file size of the resulting folder is about 60-80 MB on Windows, mostly due to all the Qt DLLs/plugins you'll need to ship. By manually deleting non-necessary DLLs, you might save maybe up to 20 MB. Just considering the file size, this might not a huge gain compared to Electron, I suppose?
However, keep in mind that desktop apps have the major disadvantage of figuring out distribution (separately for each platform!!), which includes the following two steps: 1) packaging the application in some format (e.g. an MSI installer for Windows and a Disk Image Bundle for macOS), and 2) distributing that package (including auto-updates). I have written a number of articles about this topic, see https://www.augmentedmind.de/2021/05/30/distributing-windows... and https://www.augmentedmind.de/2021/06/13/distributing-macos-a... . You get rid of all that if you just built a PWA or other kind of web app.
In addition, if you use Python, you also need to choose a "freezing" solution, such as PyInstaller (more details at https://www.augmentedmind.de/2021/05/16/distribute-python-ap... ).
However, keep in mind that desktop apps have the major disadvantage of figuring out distribution (separately for each platform!!), which includes the following two steps: 1) packaging the application in some format (e.g. an MSI installer for Windows and a Disk Image Bundle for macOS), and 2) distributing that package (including auto-updates). I have written a number of articles about this topic, see https://www.augmentedmind.de/2021/05/30/distributing-windows... and https://www.augmentedmind.de/2021/06/13/distributing-macos-a... . You get rid of all that if you just built a PWA or other kind of web app.
In addition, if you use Python, you also need to choose a "freezing" solution, such as PyInstaller (more details at https://www.augmentedmind.de/2021/05/16/distribute-python-ap... ).
I use Delphi with its FireMonkey framework. It targets all major operating systems (Win/Lin/Mac/Droid/iOS) natively. From all the cross-platform frameworks that I've seen in 25+ years of working in the industry Delphi's switching target is the easiest - a simple combobox and kaboom!, you're good to deploy for that OS.
Their roadmap include, in some years I suspect, probably 5, to also target WASM at which point, if Embarcadero is smart enough to lower their ridiculous license pricing to under $300, will become the most powerful tool to write cross-platform applications.
Their roadmap include, in some years I suspect, probably 5, to also target WASM at which point, if Embarcadero is smart enough to lower their ridiculous license pricing to under $300, will become the most powerful tool to write cross-platform applications.
One word: Lazarus.
Cross platform done right (native code, no intepreter, no VM). Both IDE and generated code run native just about everywhere, from small ARM boards to virtual machines, and of course x86. As fast as C, decent sized executables, lots of built in or available libraries and components to do a lot of things, from managing databases to low level access to hardware, graphics, sound, etc. And of course it's 100% FOSS.
My last use case was a few years ago when a friend needed to monitor some security cameras, but they were of different brands and needed either their crappy Android/iOS app or a even more crappy XP-only ActiveX control on Internet Explorer, while he wanted to monitor them from a single screen on a Windows 7 PC. As soon as I discovered the right URL for each one to grab their video feed, I arranged a window container in Lazarus dropping there a bunch of media player components, each one linking to a camera, a few other controls and bingo, he could fire up the application and have the mutiple camera view on a monitor.
If it compiled more modern languages such as Nim, Rust or Crystal it would be perfect, but even by current standards Object Pascal it's still really powerful.
https://www.lazarus-ide.org/
https://wiki.lazarus.freepascal.org/Screenshots
https://wiki.freepascal.org/Projects_using_Free_Pascal
https://www.devstructor.com/index.php?page=tutorials
Cross platform done right (native code, no intepreter, no VM). Both IDE and generated code run native just about everywhere, from small ARM boards to virtual machines, and of course x86. As fast as C, decent sized executables, lots of built in or available libraries and components to do a lot of things, from managing databases to low level access to hardware, graphics, sound, etc. And of course it's 100% FOSS.
My last use case was a few years ago when a friend needed to monitor some security cameras, but they were of different brands and needed either their crappy Android/iOS app or a even more crappy XP-only ActiveX control on Internet Explorer, while he wanted to monitor them from a single screen on a Windows 7 PC. As soon as I discovered the right URL for each one to grab their video feed, I arranged a window container in Lazarus dropping there a bunch of media player components, each one linking to a camera, a few other controls and bingo, he could fire up the application and have the mutiple camera view on a monitor.
If it compiled more modern languages such as Nim, Rust or Crystal it would be perfect, but even by current standards Object Pascal it's still really powerful.
https://www.lazarus-ide.org/
https://wiki.lazarus.freepascal.org/Screenshots
https://wiki.freepascal.org/Projects_using_Free_Pascal
https://www.devstructor.com/index.php?page=tutorials
What's the Lazarus experience like for cross-compiling to other platforms? E.G. how hard is it to build a working result for Windows, OSX and Linux (maybe BSD) from Linux or BSD?
I don't recall having to cross compile, since the IDE itself runs on so many platforms. For not too complex projects, or not resource constrained hardware, importing the project and compiling it directly on the target might be the quickest solution.
Maybe this crosscompiles, I have not tried it yet:
https://wiki.lazarus.freepascal.org/fpcupdeluxe
https://wiki.lazarus.freepascal.org/fpcupdeluxe
For your limited use case, ffmpeg / VLC wrapped in a small .sh or .bat script may have been an option?
VLC can understand ONVIF RTSP and tile the video's into a mosaic
https://www.youtube.com/watch?v=qV-S4LMePVk
https://wiki.videolan.org/VLC_HowTo/Make_a_mosaic/
Id love to try lazarus one day all the same
VLC can understand ONVIF RTSP and tile the video's into a mosaic
https://www.youtube.com/watch?v=qV-S4LMePVk
https://wiki.videolan.org/VLC_HowTo/Make_a_mosaic/
Id love to try lazarus one day all the same
Note for prospect Lazarus users: they use their own widget toolset that looks quite dated and doesn't really feel native, especially outside of Windows.
They don't integrate Qt widgets or other frameworks properly.
They don't integrate Qt widgets or other frameworks properly.
It depends. I've built a lot of these. The best approach is to keep the UI very lightweight and just build it using native controls for each platform. Keep all the application logic in a common library and just rewrite the parts that are interactive. This isn't as much work as it seems, especially if you design it upfront, and there's no other way to get a native feel. There's also some "product management" advantages to this approach, such as building new features first on your smallest platform so you can test/iterate quickly with few users and then moving them to Windows when they are proven. Don't build new features on all three at once, take turns.
If the app has a whole lot of dense UI screens, or if you don't particularly care about it looking nice and feeling platform native, something like Qt or many of the other frameworks suggested here work well, but do be aware that you'll be making it harder to use platform features. For example, on MacOS you wouldn't support the TouchBar and would have some extra complexity to support Metal graphics vs GL (which Qt supports).
You can also do something similar to Electron but much more lightweight using a platform WebView. Then you can have common controls built in a htmlish way, and still have custom and native controls mixed in. One example of an app I worked on that was built this way and worked well was an app to browse/view 100s of video clips, we had a common html-based widget to filter and display search results and thumbnails (which had a bunch of interesting layout requirements) but the video playback itself was in a native panel (it needed to play custom formats so using web for everything wasn't appropriate).
Flutter looks promising but it still feels a little early. Try it out if you're willing to take some risks and maybe bend your thinking a bit. I found it too indirect and felt like I had to give up too much design responsibility to the toolkit when I last tried it but maybe that's an advantage.
If you're thinking about Electron, why not make it a purely web app? Then you'll save yourself lots of hassles distributing and downloading.
Also, for graphically intensive or in-house tools (like a game level editor) i use Dear ImGui, it's very fast to develop and great cross platform support, but I wouldn't ship it to a customer.
If the app has a whole lot of dense UI screens, or if you don't particularly care about it looking nice and feeling platform native, something like Qt or many of the other frameworks suggested here work well, but do be aware that you'll be making it harder to use platform features. For example, on MacOS you wouldn't support the TouchBar and would have some extra complexity to support Metal graphics vs GL (which Qt supports).
You can also do something similar to Electron but much more lightweight using a platform WebView. Then you can have common controls built in a htmlish way, and still have custom and native controls mixed in. One example of an app I worked on that was built this way and worked well was an app to browse/view 100s of video clips, we had a common html-based widget to filter and display search results and thumbnails (which had a bunch of interesting layout requirements) but the video playback itself was in a native panel (it needed to play custom formats so using web for everything wasn't appropriate).
Flutter looks promising but it still feels a little early. Try it out if you're willing to take some risks and maybe bend your thinking a bit. I found it too indirect and felt like I had to give up too much design responsibility to the toolkit when I last tried it but maybe that's an advantage.
If you're thinking about Electron, why not make it a purely web app? Then you'll save yourself lots of hassles distributing and downloading.
Also, for graphically intensive or in-house tools (like a game level editor) i use Dear ImGui, it's very fast to develop and great cross platform support, but I wouldn't ship it to a customer.
There’s also Xamarin. Uses C# and dotnet. You can choose between native widgets and platform-agnostic.
https://dotnet.microsoft.com/apps/xamarin
https://dotnet.microsoft.com/apps/xamarin
We write apps like this in Object Pascal using Lazarus. Think Delphi but open source.
We have a suite of framework-specific developer apps for tasks like packaging deployments, managing common database tasks, onboarding new clients etc. They were written on Linux using Lazarus, then recompiled on MacOS and Windows as required. There are occasionally OS-specific variations for small pieces of these apps, but Object Pascal has inline compiler switches to make this easy to manage.
We have a suite of framework-specific developer apps for tasks like packaging deployments, managing common database tasks, onboarding new clients etc. They were written on Linux using Lazarus, then recompiled on MacOS and Windows as required. There are occasionally OS-specific variations for small pieces of these apps, but Object Pascal has inline compiler switches to make this easy to manage.
In Solvespace we use native GUI on Windows, MacOS, and Linux (GTK). This is probably not what you want to do, as we don't use any GUI widgets - only popup dialogs and menus. Everything in the app itself is rendered using OpenGL. Even our "text window" is drawn using OpenGL and GNU unifont (this is something that really needs to change BTW).
The platform abstraction code is here: https://github.com/solvespace/solvespace/tree/master/src/pla...
There is no other platform specific code anywhere in the app, but like I said above we don't support widgets.
There is also an emscripten port in a branch, but it doesn't want to build recently.
The platform abstraction code is here: https://github.com/solvespace/solvespace/tree/master/src/pla...
There is no other platform specific code anywhere in the app, but like I said above we don't support widgets.
There is also an emscripten port in a branch, but it doesn't want to build recently.
How’s accessibility?
> our "text window" is drawn using OpenGL and GNU unifont (this is something that really needs to change BTW)
What would you change it to? I've implemented a GUI toolkit from scratch a couple times, and text editing was the hardest part by far.
What would you change it to? I've implemented a GUI toolkit from scratch a couple times, and text editing was the hardest part by far.
>> What would you change it to? I've implemented a GUI toolkit from scratch a couple times, and text editing was the hardest part by far.
I have no idea. The biggest problem with it now is that it's not resizable. We could use pango or something to render text at different sizes but that'd be a new dependency.
Also forgot: we do use a platform specific text entry widget.
Also2: when I say "we" I mean the previous maintainer did all the cross platform code. Since then it just works.
I have no idea. The biggest problem with it now is that it's not resizable. We could use pango or something to render text at different sizes but that'd be a new dependency.
Also forgot: we do use a platform specific text entry widget.
Also2: when I say "we" I mean the previous maintainer did all the cross platform code. Since then it just works.
So just for the sake of completeness, maybe, and since Electron seems to be the most popular solution; what about a website? Fairly ubiquitous across all platforms with the help of Chrome, Firefox, and even Safari or Edge. I don’t think should be dismissed as often as is, consider VS Code on Github.com (hit the period key in a repo and the repo’s code is presented with VS Code in a browser — and it supports syncing extensions — though not all, for example).
To me it makes sense from tne perspective of the work being done in HTML, CSS & JS to make an Electron app. Why not start as a website then desktop?
I get there are certain pieces of functionality not suited for a website; but based on the original post’s question and description it seems feasible.
To me it makes sense from tne perspective of the work being done in HTML, CSS & JS to make an Electron app. Why not start as a website then desktop?
I get there are certain pieces of functionality not suited for a website; but based on the original post’s question and description it seems feasible.
I need to read/write to the filesystem, think the app is like a personal document manager. Also will like to associate filetypes with it, and for the most important thing is being able to send notifications and make sure my backend is syncing data all the time
For the record you can do the last two things with a website these days. Still sounds like it won't work for your project, though.
Java and Swing are still a great option.
Ugh, I'd rather have the electron app. I've never seen a Java application that didn't garishly stand out, the widgets do not act at all native, and it's inevitably sluggish. Although, the biggest offenders I've used are Eclipse and IntelliJ IDEA, both of which at least have some excuse. I hate using both, though, and VS Code, which I believe is Electron-based, does not feel sluggish the way the other two do.
It takes a bit of care for java apps to look native. Though no electron apps look native, and they all look pretty garish to me. IDEA can be pretty snappy and the Jetbrains team is pretty good at fixing performance problems.
VSCode is full of C++ to work around Electron's bloat, in fact I am still looking forward to the day at very least gets rebooted in React Native.
Here is an example of an audio workstation software done in a mix of Java and C++,
https://www.bitwig.com/overview/
What most UI/UX projects don't need is programmer art.
Here is an example of an audio workstation software done in a mix of Java and C++,
https://www.bitwig.com/overview/
What most UI/UX projects don't need is programmer art.
Java has a few options...
AWT (Abstract Windowing Toolkit) probably not recommended for new projects
Swing
JavaFX
SWT https://www.eclipse.org/swt/ Unlike the others that draw their own widgets and don't use the OS components SWT uses the native platform controls
AWT (Abstract Windowing Toolkit) probably not recommended for new projects
Swing
JavaFX
SWT https://www.eclipse.org/swt/ Unlike the others that draw their own widgets and don't use the OS components SWT uses the native platform controls
We've test driven UNO at our company
https://platform.uno/
but you really have to stick to the beaten path as some more complex controls are only partly implemented. It's a variation on Xamarin basically.
This thread doesn't inspire confidence. It's mostly small and unproven projects, some maintained by hobbyists.
I think the mess we're in with GUIs is because we've failed to find a way to convey at a very high level what the inputs and outputs of software are. In a utopian world, you'd define what you want the user to see and how the user can interact with the information. Something would then work out how to lay that for you (in a way that makes sense to a human) and construct a GUI using native OS APIs.
Instead, we have only three options that I'm aware of:
* Use a framework that ignores the native APIs, throws away the OS design language and does all the rendering inside
* Build separate applications for each platform
* Use Electron and potentially reuse work you already did on the web version
When looking at it this way, it's easy to see why Electron is popular. Not that I'm a fan of it in any way.
I think what we need is a lot of really smart people to come together to reinvent the presentation layer.
I think the mess we're in with GUIs is because we've failed to find a way to convey at a very high level what the inputs and outputs of software are. In a utopian world, you'd define what you want the user to see and how the user can interact with the information. Something would then work out how to lay that for you (in a way that makes sense to a human) and construct a GUI using native OS APIs.
Instead, we have only three options that I'm aware of:
* Use a framework that ignores the native APIs, throws away the OS design language and does all the rendering inside
* Build separate applications for each platform
* Use Electron and potentially reuse work you already did on the web version
When looking at it this way, it's easy to see why Electron is popular. Not that I'm a fan of it in any way.
I think what we need is a lot of really smart people to come together to reinvent the presentation layer.
I think part of the problem is that different OS chromas have different native widget sizes, and possibly different layouts. If you create a UI for Windows and just switch to the macOS chroma, it will have weird spacing, and I don’t think there’s a general way to fix this. Converting to the iOS chroma is even worse, with checkboxes -> switches, radios -> tables, and the combination of smaller screen + bigger controls.
So the solution for cross-platform apps is to use a non-native chroma which is the same for each OS. But that brings you to Qt or JavaFX or Electron.
So the solution for cross-platform apps is to use a non-native chroma which is the same for each OS. But that brings you to Qt or JavaFX or Electron.
It's often trivial to cross-compile a basic command like program, OS filesystem specifics might be a small issue but there it's generally Windows vs everything else. Building one (mostly shared) codebase for different platforms is fine; or even shipping a script that's run locally.
However the solution to this problem needs:
I'd be happy enough if, across all the major OS today, I could use a pipe or localhost socket to talk to the browser and use it to render a webpage within a basic OS window (ZERO other browser decoration or interactions, still OS decorated). If THAT alone worked on every operating system that would be enough of a basic step for 99% of the CRUD style apps out there. Small extra bonus if a message-passing interface worked between the two.
However the solution to this problem needs:
* To already be installed on every updated OS
* Work, mostly, the same across every OS
* Include the widgets we know from the last 20-30 years.
I'd be happy enough if, across all the major OS today, I could use a pipe or localhost socket to talk to the browser and use it to render a webpage within a basic OS window (ZERO other browser decoration or interactions, still OS decorated). If THAT alone worked on every operating system that would be enough of a basic step for 99% of the CRUD style apps out there. Small extra bonus if a message-passing interface worked between the two.
3 seems like a subset of 1.
libui has bindings for many languages but might be too immature for complex needs https://github.com/andlabs/libui
Is the Eclipse RCP still a reasonable platform? Not as fancy as JavaFX but must be more mature/feature-complete. Similarly for the NetBeans kit.
The trade off is always between cross-platform and native integration. For example, do you want to write an app that feels like a MacOS application? You have to use AppKit to really get that feel, and then it’s not cross platform.
There’s really 3 choices that I see, and have done all of them:
1) just build native UIs for each platform. This is the most time consuming, but the best end result in my opinion. The apps _feel_ the best on each platform
2) make a web app. Electron apps are still web apps.
3) hybrid approach, where part of your logic is shared across different native UIs, let’s say with a C++ / Rust / Java / Kotlin library. This is also a spectrum. Your library can just have common glue / networking code, all the way up to drawing its own graphics before turning a full screen over to the native UI framework.
I guess there’s also 4, which is Flutter, but that’s really just a pre-packaged #3.
If you ask me, web just has the best delivery model, and that trumps everything. Responsive web app plus a native option via Electron is the way to go.
There’s really 3 choices that I see, and have done all of them:
1) just build native UIs for each platform. This is the most time consuming, but the best end result in my opinion. The apps _feel_ the best on each platform
2) make a web app. Electron apps are still web apps.
3) hybrid approach, where part of your logic is shared across different native UIs, let’s say with a C++ / Rust / Java / Kotlin library. This is also a spectrum. Your library can just have common glue / networking code, all the way up to drawing its own graphics before turning a full screen over to the native UI framework.
I guess there’s also 4, which is Flutter, but that’s really just a pre-packaged #3.
If you ask me, web just has the best delivery model, and that trumps everything. Responsive web app plus a native option via Electron is the way to go.
As far as I am aware Qt is the only cross-platform toolkit that has reasonable traction, and it has been successfully used by commercial applications. Other cross-platform applications are either so old that there was no other choice but to write their own toolkits, or they are web browsers where you might as well write your own toolkit since you already have to do much of the work to render the HTML.
Unfortunately, "well-integrated" and "cross-platform" are fairly mutually exclusive, kind of by definition. I'm not sure if the API model for Windows and macOS even have a generalizeable common model. (They might, they might not, I've not investigated, and it would depend on which of the many MS UI APIs you are using)
Unfortunately, "well-integrated" and "cross-platform" are fairly mutually exclusive, kind of by definition. I'm not sure if the API model for Windows and macOS even have a generalizeable common model. (They might, they might not, I've not investigated, and it would depend on which of the many MS UI APIs you are using)
It’s too early to judge but Jetbrains are working on a desktop implementation of Jetpack Compose, the new Android UI framework. It draws to skia like Flutter so also not really “native” if that’s important to you. https://www.jetbrains.com/lp/compose/
I've had decent experiences with Python and Qt5. Windows was historically the painful part, but FBS¹ makes that a lot less painful nowadays. Tk also works reasonably well if you don't need the features and native integration that Qt offers (and I'm pretty sure FBS can handle Tkinter apps just fine).
The .NET ecosystem is another solid choice for cross-platform desktop app development (and nowadays even mobile, too). Avalonia² in particular looks promising, and is probably what I'd try using first should I ever be tasked with developing a desktop app again.
EDIT: Also, since you mentioned it already for Linux, GTK works well enough on Windows and (IIRC) macOS, too.
----
¹: https://build-system.fman.io/
²: https://avaloniaui.net/
The .NET ecosystem is another solid choice for cross-platform desktop app development (and nowadays even mobile, too). Avalonia² in particular looks promising, and is probably what I'd try using first should I ever be tasked with developing a desktop app again.
EDIT: Also, since you mentioned it already for Linux, GTK works well enough on Windows and (IIRC) macOS, too.
----
¹: https://build-system.fman.io/
²: https://avaloniaui.net/
Qt, GTK, SDL, Flutter...
The honest truth is that there is no good alternative here - there are only alternatives that are terrible in their own way.
Electron: Bloat, non-native, highly questionable language
Other cross-platform solutions: Obscure, (most often) non-native, undesirable language constraints, often far behind with regards to UI paradigms
Native UI for each platform with common code: requires deep knowledge of each platform, probably more time consuming than the other alternatives, the seam between common code and platform-specific code is often a source of errors
Fully separated native applications: Likely to produce the highest quality UIs, but requires the most diverse knowledge and time, more difficult to remain consistent across implementations, team size becomes an issue depending on how many platforms are supported
As much as I dislike Electron-applications, it's understandable why they became adopted so widely - the alternatives are just quite simply not great.
Electron: Bloat, non-native, highly questionable language
Other cross-platform solutions: Obscure, (most often) non-native, undesirable language constraints, often far behind with regards to UI paradigms
Native UI for each platform with common code: requires deep knowledge of each platform, probably more time consuming than the other alternatives, the seam between common code and platform-specific code is often a source of errors
Fully separated native applications: Likely to produce the highest quality UIs, but requires the most diverse knowledge and time, more difficult to remain consistent across implementations, team size becomes an issue depending on how many platforms are supported
As much as I dislike Electron-applications, it's understandable why they became adopted so widely - the alternatives are just quite simply not great.
In used to work for a company that modified an opengl c++ game engine to act as a cross platform 2d GUI.
It worked but the amount of effort is not worth it for most organisations.
It worked but the amount of effort is not worth it for most organisations.
I am making a simple image editor for myself to use on Linux, and honestly? After looking at different bindings for Qt and GTK on Go/Rust/Java and looking at other GUI frameworks (all of which are in beta state, it seems) I went back to Java+JavaFX.
There's a decent GUI markup editor (Scene Builder). There's no need to manually connect your handlers from XML markup to code - you can use annotations for that. There's HiDPI scaling that you can override if need be. There are Observable properties that you can bind to each other.
It's nice! Canvas and DrawingContext are a bit of a pain to use for my specific use-case, since it draws straight to buffer with no underlying Image, but I make do for now.
And you can take advantage of jlink to trim your JDK to modest sizes. There are also tools like Graal Native and Liberica Native Image Kit to compile your Java app down to binary, but I haven't toyed with those yet.
The cons are obvious: non-native look (you can try to style it with CSS, but there are no ready-made native looking solutions, I think, only different themes) and JVM startup time.
However, if you're willing to write C++, I'd argue Qt is the best choice right now. I just refuse to touch C/C++ with a ten-foot pole
There's a decent GUI markup editor (Scene Builder). There's no need to manually connect your handlers from XML markup to code - you can use annotations for that. There's HiDPI scaling that you can override if need be. There are Observable properties that you can bind to each other.
It's nice! Canvas and DrawingContext are a bit of a pain to use for my specific use-case, since it draws straight to buffer with no underlying Image, but I make do for now.
And you can take advantage of jlink to trim your JDK to modest sizes. There are also tools like Graal Native and Liberica Native Image Kit to compile your Java app down to binary, but I haven't toyed with those yet.
The cons are obvious: non-native look (you can try to style it with CSS, but there are no ready-made native looking solutions, I think, only different themes) and JVM startup time.
However, if you're willing to write C++, I'd argue Qt is the best choice right now. I just refuse to touch C/C++ with a ten-foot pole
UPD: I checked out Graal Native. It was somewhat painful to make JavaFX work with it, due to reflective nature of the framework (which does not work very well with Java Modules), but I managed to make a native image with Gluon plugin for Maven. And it starts up FAST, I like the result.
[0] - https://docs.gluonhq.com/#_gluonfx_plugin_for_maven
[0] - https://docs.gluonhq.com/#_gluonfx_plugin_for_maven
There's pywebview (https://github.com/r0x0r/pywebview/) which is a Python lib that uses whatever native webview implementation exists. Obviously means some compatibility work between each OS, but gives out very small apps what work very well on the whole. I'm using it on my cross platform email client (https://kanmail.io).
Does anyone really care about the size of the program anyway?
At my work a few years back, we did quite a lot of prototyping using Qt, QML and JavaScript. It can get you surprisingly far for a GUI. It’s probably not the “right” way to do it, and Qts approach to QML is that it’s for UI. It app logic, but it’ll work in a pinch and it’s pretty easy to pickup.
That said, QML and QtPython sound like a really great combo
That said, QML and QtPython sound like a really great combo
I've decided to dust off my somewhat rusty Lazarus, GIT and GitHub skills to build a Lazarus application to follow this thread using the HN API hosted by firebase.
You mentioned getting data to a GUI application using the web, this seemed like an ideal small project that could give you a firmer idea of just how Lazarus might fit your needs.
Notes:
I've never done anything like this (https/json) before but I suspect I'll be done in a day or two. Once it works, I'll then focus on getting it to also run in Ubuntu. I don't have a Macintosh, so that's out.
I've GPL 3.0 licensed it.
I'm not near the MVP yet, but it does manage to fetch the data and count the JSON objects in it for the main body of this thread.
With Debug info, the windows executable is 25 megabytes, without it 3.1 megabytes.
Here's the github link: https://github.com/mikewarot/WatchHN
You mentioned getting data to a GUI application using the web, this seemed like an ideal small project that could give you a firmer idea of just how Lazarus might fit your needs.
Notes:
I've never done anything like this (https/json) before but I suspect I'll be done in a day or two. Once it works, I'll then focus on getting it to also run in Ubuntu. I don't have a Macintosh, so that's out.
I've GPL 3.0 licensed it.
I'm not near the MVP yet, but it does manage to fetch the data and count the JSON objects in it for the main body of this thread.
With Debug info, the windows executable is 25 megabytes, without it 3.1 megabytes.
Here's the github link: https://github.com/mikewarot/WatchHN
Update #1 - there is FAR far more going structure wise in threaded comments than I first realized, but I eventually managed to just read the raw text.
Formatting, adding dates, etc... will be a bit more still.
Formatting, adding dates, etc... will be a bit more still.
Give Sciter a chance.
https://sciter.com/
https://sciter.com/
On the business side, I understand that many people on HN prefer to ship that spend time on technologies discussions.
But if you have the time, and your goal is to do something maintainable, reasonably close the most to the Desktop, and well-integrated to the OS, what tech/stack will you use?
Windows/Linux GTK/MacOS