I have been involved with Vala in it’s early day and some hardcore GObject/C users never quite liked the C code that Vala generated although it was perfectly valid and exposed a very clean C header to interface with it.
I think that Vala is a really great tool for building applications that make use of Glib/GObject. For example Gtk applications, but also GStreamer and DBus applications.
If you aren't developing a DAW, a browser, or some other performance critical GUI app, you're moving to Electron and other layout engine solutions. And who should blame you, people don't want to fiddle with GTK_Window_Context_Handler* gtk_wdw_ctx_hdlr_ptr = Init_GTK_Window_Context_Handler(Window_Context* w_ctx); just to make a damn app.
Even if Vala drops in to save us all from noodling with Window Context Rocket Ship Handlers, layout engines are more portable solutions. The decline of WPF and Winforms is proof of this.
A lot of the color fiddling etc. that web apps due is due to
1.) Graphic designers having no other way to go, now that print is dead
2.) Corporate Identity (which is of lower priority than platform identity)
3.) Selling stuff (not needed as much with desktop apps)
And since most folks end up supporting the web as a first class platform you have to BYOD there anyway. Nobody is out there making a JS framework to emulate WinForms.
Not everything has to or can be be cross-platform, not everything has to be web-visible. And I'd argue that serving the same view to everyone is quite often a bad idea. (Heck, in the web-case, it's not even just the view)
I would like to know the honest answer to that question, actually.
wpf is still heavily used in industry so that isnt very convincing to me
That’s why I mention performance critical
> wpf is still heavily used in industry
But is anything new being made with wpf? Because that’s why I left that area.
windows shop still reach for it heavily in "boring" industry in my experience.
there is a difference between performance critical and sloppy of course. most people default to heavy crap cuz its good enough, or a good fit sometimes, i get that
and this is coming from someone who had to use wpf for software where it ended up too slow in all rendering paths despite MS "trust us bro" and had to render using directx directly. not super uncommon but we were paying the price early (.net fw 3, fuzy wpf text, vibrating layouts, the good days)
No, that‘s very common. I‘m peripherally involved in such a greenfield project, too. And my employer is (very) slowly switching existing WinForms applications to WPF. It‘s the new thing.
(I know that there are a handful newer MS GUI frameworks, but for us it‘s new)
they are both too new
Couldn’t be happier.
a) being able to deploy same codebase on web and desktop
b) reusing the vast selection of libraries for web
c) tapping the large amount of trained developers.
Sciter fails on a) and b), because it doesn't support even such a basic and widely used feature as CSS flex (they have something similar, but incompatible).
Even c) is very debatable.
Binary sizes are currently around ~12mb which isn't as good as Sciter but is quite a bit better than Electron.
Desktop UI and Web UI models are so different that in reality you cannot use the same codebase on 100% in both targets.
Web UI uses traditional Web's "endless tape" model where only width is known. This does not really work on desktop where width and height are finite. See this Sciter based app https://notes.sciter.com/ as an example.
> reusing the vast selection of libraries for web
If you do need this then you can use Sciter's WebView that is a <frame> backed by system browser:
https://sciter.com/wp-content/uploads/2022/04/sciter-webview...
> If you do need this then you can use Sciter's WebView that is a <frame> backed by system browser:
iframes are very constrained in what you can do, if you’re targeting the web from the start you get the full power of using those libraries beyond the bounds of a single frame.
I develop an Electron app and the CSS is 100% same on both web and desktop. It's not a "web page", it's an app, which doesn't use the "endless tape" model.
> If you do need this then you can use Sciter's WebView that is a <frame> backed by system browser:
At that point it seems easier to just use something like Tauri which uses the system browser for all rendering.
> In almost 10 years, Sciter UI engine has become the secret weapon of success for some of the most prominent antivirus products on the market: Norton Antivirus and Internet Security, Comodo Internet Security, ESET Antivirus, BitDefender Antivirus, and others. The use of HTML/CSS has allowed their UI to stay in touch with modern GUI trends throughout all these years, and will continue to well into the future.
Made me laugh a bit, I usually find antivirus softwares out of touch with good design and really impractical due to that.
But I was unable to find information about how to set up my repo and build process with GTK vendored into the project. All tutorials said that I should just install GTK libraries with my system package manager, but that was not a satisfactory answer for me.
After some hours fiddling around stackoverflow, adding flags to my GCC invocation and being unable to solve the problem, I just gave up.
Flutter Desktop seems like a compelling alternative to GTK these days.
Qt is old, and cool.
Sad news for ya, flutter just wraps GDK (from GTK) on Linux. It also, last time I checked, was limited to a single application window.
How about input events? How about vsync synchronization? How about monitor information? How about clipboard? How about drag'n'drop?
GDK does an awful lot of lifting for Just here.
Another thing I would like to avoid is the philosophy of "the application binary doesn't come with its dependencies bundled, the user should install them using the system package manager". Unfortunately, many frameworks have this philosophy but, apparently, Flutter doesn't.
In general, Qt acknowledges the differences between desktop styles and tries to match them, while Gtk doesn't seem to care about any style or interaction model other than its own.
Now that Ardour has switched are there still any DAWs using GTK?
From https://ardour.org/whatsnew.html# :
> From a project-level perspective, perhaps the most important change is that we have moved the source code of our GUI toolkit (GTK v2) into the Ardour source tree.
Look around, it’s a bloated, buggy world. Calendar apps aren’t being carefully engineered by European computer scientists.
>Electron apps tend to be poorly designed
How so, are you saying because they use Electron they’re inherently poorly designed?
I’m not the original commenter, but Electron apps are regularly poorly designed and lacking quality. I won’t say it’s inherent to Electron, but it’s largely due to the fact that the standard controls offered by browser engines are incredibly rudimentary. They are still catered primarily to forms and simple interactivity in a document.
Rich interactivity requires you build your own or find some third-party package, whereas at this point most desktop UI toolkits have 20-30 years of development and refinement behind them.
Panels and panes are resizable and collapsible; you can have multiple free-floating, smoothly resizing windows; collections/tables will efficiently reuse cells to avoid tanking performance on long or infinitely scrolling lists.
All of this stuff is possible with Electron I’m sure, but the platform doesn’t offer it for the taking, so most don’t bother. And when they do, it’s less refined than what we had in desktop apps in 2005.
Do people care? Evidently not. I do though.
I haven't used qml a lot but I wonder if gtk has an equivalent to that too. What am I missing about gtk here? Like, where does GTK beat qt?
Secondly would be the license, while they're both LGPL these days, that wasn't always the case, and the current Qt company is highly hostile to open source.
It's a constant chase not worth any developers time.
They backtracked a bit on that but they'll still replace GTK4 with GTK5 at some point, probably deprecating context menus or whatever else this time. Clowns.
And Java Swing was there from the beginning, still perfectly usable, and is widely used in industrial applications.
Reason being that the Rust bindings are fairly ergonomic regarding the GTK OO system, plus Rust has a great ecosystem.
Relm4 in special is pretty great
https://relm4.org/book/stable/
edit: here is some earlier blog post from 2016 https://blogs.gnome.org/despinosa/2016/11/01/rust-and-vala/ but I think there were others since then