41–50 of 145 posts
Though overall, its not an uncommon issue. I've found myself in the same place multiple times, I've even considered using a lightweight game engine just for their UI features. But next time I run into it, I imagine Flutter will be what I go with
Edit: Just realising you said "native-looking". Not so sure about Flutter for that, I'm not sure such a thing exists.
If you don't actually care about creating platform native UIs, you'll always be creating something that is a second-class design while putting in first-class effort. Why?
Frankly, you're better off just learning the operating system platform native UI programming language and get over yourself if you want to create something that looks like it was actually designed for the OS you're using.
And really, it's immature and insulting to call languages insane. Suck it up, these are peoples' professions here. No one wants to read that.
Personally I like JavaFX. I made something pretty complicated with tkinter and Python. It's not that hard to do but the result looks awful, it doesn't support many features people expect in 2022, and the documentation for using tk in Python is poor. You probably need to refer to the tcl/tk documentation and translate it in your head to apply to Python. As much as people hate Electron, the rendering engine in a web br…
There are some very powerful capabilities in Objective C (like swizzling) that can be of tremendous help when you have some oddball functionality to implement. This would be conceptually very similar to the monkey-patching that folks do with Python. Perhaps this is the sort of thing that makes it not sane to you?
Also java can run on any platform so javafx, etc..
Here is a simple Julia GTK project on GitHub: https://github.com/ordovician/RocketBuilder.jl
Some articles I wrote related to GTK programming with Julia and GTK in general:
- Understanding GTK Layouts: https://itnext.io/understanding-gtk-layouts-13e5a36256fa
- Hiccups Writing GTK3 GUI Code in Julia: https://towardsdev.com/hiccups-writing-gtk3-gui-code-in-juli...
If Julia is not your cup of tea then GTK can be used with Go and Swift as well.
Most cross platform frameworks won't really look 100% native. The only exception I know is wxWidgets, which provides an abstraction layer over the native toolkits. It's written in C++ but there are bindings for Python, Ruby and other languages. But even using this, apps might not feel truly native. There is more to nativeness than looks. It's also about subtle conventions and ways to do things. You only achieve this when you use a native framework and pay a lot of attention to the HIG guidelines of the OS.
My personal (and perhaps a bit unpopular) opinion is that native looking is a bit overrated. And it's mostly macOS users who look for this. Linux and Windows users already get a lot of diversity in their looks and feel because there is no single framework for those OSes.
More important than native looking is to have a GUI that is fast, efficient and accesible. The best option that provides this in a cross platform way is QT. Java Swing and JavaFX are also good options.
The most productive tool to have cross platform GUIs right now is Electron. That's just a fact. And it's the reason why so many modern products are using it. But as we all know, there is a price in efficiency.
There are a bunch of new projects in the works to improve cross platform GUI for modern languages. JetPack Compose Desktop, Flutter, Slint and many more. But these are not yet fully mature.
Personally I like JavaFX. I made something pretty complicated with tkinter and Python. It's not that hard to do but the result looks awful, it doesn't support many features people expect in 2022, and the documentation for using tk in Python is poor. You probably need to refer to the tcl/tk documentation and translate it in your head to apply to Python. As much as people hate Electron, the rendering engine in a web br…
I haven't used it myself (yet), but https://tauri.app/ looks very promising as Electron alternative. It uses the OS's browser so it doesn't have the bundle size issue you describe.
You'll need to ship Microsoft's new Edge runtime thing, which is a separate package. You'll either have to include that giant package in your package or download it on demand, and the latter is very brittle and will fail if MS changes their URLs or you're installing inside a very heavily firewalled (whitelisted) environment. If your product runs in enterprise settings you will get complaints from IT people about how your single installer installs a "hidden" second installer that they don't want, especially since the Edge runtime runs some kind of system service (why?) all the time. You'll have to basically take over maintaining up to date Edge runtimes in your bundles and handling edge cases because Microsoft can't ship software for their own OS. People will complain that if they uninstall your app it does not fully uninstall because it leaves the Edge runtime.
Tauri just works everywhere else but the headaches on Windows defeat the purpose to some extent.
Of course I guess shipping anything for Windows is "welcome to hell." The only way to have a package that installs and runs reliably is to bundle Every. Single. DLL. And. Dependency... or statically link it.
Earlier quoted context omitted.
Ok, so be it. C and C++ are still insane to work with.
It's really not that bad and comments like this just perpetuate the fear to other people who have never touched them.
Heartbleed was reviewed twice by literal OpenSSL experts and security experts who were specifically looking at it to determine whether it was a security vulnerability or not and concluded (incorrectly) it was not. And now it's the poster child for bad software bugs.
It's really hard to write correct software in any language, and time has shown again and again that memory safety is just not something you can hope to do without if you care about security in the slightest.