5 ms·

> Something that isn't talked about much in the GUI world (outside of mobile development) is how essential multi-threading is to a great application experience.

> Something that isn't talked about much in the GUI world (outside of mobile development) is how essential multi-threading is to a great application experience. Yes it is. Heavyweight desktop GUI applications like DAWs or CAD or image/video editing are old established technology. > This has the advantage of a project feeling natural to the platform while still allowing for code reuse between platforms Having written cross platform native applications: This is a pain in the ass to do well - and there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet. “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs - how hard can it be they think - then they learn why Qt exists. > It's not too far from the write-once-run-everywhere philosophy of React native, Electron and similar. Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get.

apatheticonion 3y ago
I do have a naive view on native GUI development because I have little real experience in it - I very much appreciate your insight. > “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs I would like to know more about what you mean here; my description of a "virtual UI" that you bind to from the native toolkit is an abstraction to the UI - but it's not an abstraction like Flutter which tries to merge all native widgets into abstracted widgets. My concept still requires you to write multiple native entry points using the UI kits of the target platforms. ` (GTK entry || Cacao entry || Win entry) => Virtual UI => application logic ` The idea is that the virtual UI would be an in-memory representation of the UI (have virtual buttons, labels, etc). It would be the job of the entry to correctly represent/bind to that virtual UI with the relevant presentation tool kit. The output binary would be specialised to the platform/UI kit used in the source entry point. It seems sensible on the surface to decouple the UI from the native presentation as it minimizes the requirements of the native side to constructing the UI and binding to the virtual UI - but I would love to hear your thoughts. I have not tested this architecture outside of web development but I imagine adding new UI targets (like web assembly, QT, etc) would be easier as it wouldn't require any changes to the virtual UI or application logic and would be a matter of creating a new entry point representing the UI for the new target. > then they learn why Qt exists Does QT feel native on MacOS, Windows and Gnome? > Yes it is [talked about] Could be my personal echo chambers talking here - but multithreading is almost never spoken about and/or often intentionally disregarded in modern web/electron applications. It sucks because so many applications are written using Electron or other similar web wrappers. > there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet Not dismissing this, I was more impressed that Rust offers a thread safety guarantee through its ownership model making it interesting from a contributor scalability standpoint. I was thinking that it might make it easier to have more engineers working on a high performance GUI project because it would be significantly harder to break. As an example; I could imagine if a company assigned a team of TypeScript/JavaScript developers with different experience levels onto a GUI project written in something like Go, there would be a lot of thread safety issues and seniors would spend a lot of time combing PRs for thread safety issues. Rust, while perhaps not as simple from a syntax/types/symbols standpoint, offers an interesting development modality for these sorts of projects. I would expect that it would result in a more hands off contributor experience. > Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get. Sorry I wasn't describing Electron as targeting platform native decorations - just that it promises an OS agnostic UI framework (write once run anywhere) at the expense of a diminished native experience and poor performance. My point was that it might be interesting to explore the idea that a multi-entry native toolkit application fulfils the same "write once run 'anywhere'" promise but without the downsides.
unstrategic 3y ago
> Rust isn't some silver bullet Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C. Rust offers more leverage in building ambitious system software. Since you mention Qt, imagine writing all of Qt in x86 assembly, vs. C++. "There's not particular reason this isn't doable." C++ to Rust is a similar jump. No silver bullets; just leverage. Cross-platform toolkits — especially those aiming to abstract over native UI/UX patterns — are an ambitious, if not Sisyphean domain. Qt was about the best we could do in the C++ era, but a new era has dawned.
- fooker 3y ago
  > Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C There are about 3-4 orders of magnitude more large C++ projects developed by large teams compared to Rust projects as of now. This might change in future, but your claim seems a bit premature. In a previous company I worked at, we were forced to rewrite a greenfield project in C++ because it was going too slow with Rust. The team managed to ship the thing in a few months, compared to spending a month getting nowhere with Rust.
- riceart 3y ago
  > Qt was about the best we could do in the C++ era, but a new era has dawned. Based on the way the Rust community has been spinning its wheels for years in getting something even within a light year of feature parity with Qt, if a new era has truly dawned you might need to wait for the next one. > Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C. Rust offers more leverage in building ambitious system software. I like Rust - but this is classic RSF/RIIR copypasta.
  - Ygg2 3y ago
    > getting something even within a light year of feature parity with Qt. Qt is also old as Jesus, and making a cross OS GUI is extremely hard. And you can non-ironically say the same about non-Qt toolkit written in C++. What grandparent probably means something that leverages parallelism and/or GPU acceleration.

apatheticonion 3y ago

I do have a naive view on native GUI development because I have little real experience in it - I very much appreciate your insight. > “Abstracting” away the native GUI/UX seems to be a common pitfall for junior devs I would like to know more about what you mean here; my description of a "virtual UI" that you bind to from the native toolkit is an abstraction to the UI - but it's not an abstraction like Flutter which tries to merge all native widgets into abstracted widgets. My concept still requires you to write multiple native entry points using the UI kits of the target platforms. ` (GTK entry || Cacao entry || Win entry) => Virtual UI => application logic ` The idea is that the virtual UI would be an in-memory representation of the UI (have virtual buttons, labels, etc). It would be the job of the entry to correctly represent/bind to that virtual UI with the relevant presentation tool kit. The output binary would be specialised to the platform/UI kit used in the source entry point. It seems sensible on the surface to decouple the UI from the native presentation as it minimizes the requirements of the native side to constructing the UI and binding to the virtual UI - but I would love to hear your thoughts. I have not tested this architecture outside of web development but I imagine adding new UI targets (like web assembly, QT, etc) would be easier as it wouldn't require any changes to the virtual UI or application logic and would be a matter of creating a new entry point representing the UI for the new target. > then they learn why Qt exists Does QT feel native on MacOS, Windows and Gnome? > Yes it is [talked about] Could be my personal echo chambers talking here - but multithreading is almost never spoken about and/or often intentionally disregarded in modern web/electron applications. It sucks because so many applications are written using Electron or other similar web wrappers. > there isn’t a particular reason this hasn’t been doable in C/C++ since forever - Rust isn’t some silver bullet Not dismissing this, I was more impressed that Rust offers a thread safety guarantee through its ownership model making it interesting from a contributor scalability standpoint. I was thinking that it might make it easier to have more engineers working on a high performance GUI project because it would be significantly harder to break. As an example; I could imagine if a company assigned a team of TypeScript/JavaScript developers with different experience levels onto a GUI project written in something like Go, there would be a lot of thread safety issues and seniors would spend a lot of time combing PRs for thread safety issues. Rust, while perhaps not as simple from a syntax/types/symbols standpoint, offers an interesting development modality for these sorts of projects. I would expect that it would result in a more hands off contributor experience. > Electron is about as far removed from the philosophy of targeting platform native toolkits as one can get. Sorry I wasn't describing Electron as targeting platform native decorations - just that it promises an OS agnostic UI framework (write once run anywhere) at the expense of a diminished native experience and poor performance. My point was that it might be interesting to explore the idea that a multi-entry native toolkit application fulfils the same "write once run 'anywhere'" promise but without the downsides.

unstrategic 3y ago

> Rust isn't some silver bullet Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C. Rust offers more leverage in building ambitious system software. Since you mention Qt, imagine writing all of Qt in x86 assembly, vs. C++. "There's not particular reason this isn't doable." C++ to Rust is a similar jump. No silver bullets; just leverage. Cross-platform toolkits — especially those aiming to abstract over native UI/UX patterns — are an ambitious, if not Sisyphean domain. Qt was about the best we could do in the C++ era, but a new era has dawned.

fooker 3y ago
> Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C There are about 3-4 orders of magnitude more large C++ projects developed by large teams compared to Rust projects as of now. This might change in future, but your claim seems a bit premature. In a previous company I worked at, we were forced to rewrite a greenfield project in C++ because it was going too slow with Rust. The team managed to ship the thing in a few months, compared to spending a month getting nowhere with Rust.
riceart 3y ago
> Qt was about the best we could do in the C++ era, but a new era has dawned. Based on the way the Rust community has been spinning its wheels for years in getting something even within a light year of feature parity with Qt, if a new era has truly dawned you might need to wait for the next one. > Rust codebases extend in size and scale to larger teams fundamentally better than C++ / C. Rust offers more leverage in building ambitious system software. I like Rust - but this is classic RSF/RIIR copypasta.
- Ygg2 3y ago
  > getting something even within a light year of feature parity with Qt. Qt is also old as Jesus, and making a cross OS GUI is extremely hard. And you can non-ironically say the same about non-Qt toolkit written in C++. What grandparent probably means something that leverages parallelism and/or GPU acceleration.