[HN Gopher] Are we GUI Yet? The state of building user interface...
___________________________________________________________________
Are we GUI Yet? The state of building user interfaces in Rust
Author : belter
Score : 186 points
Date : 2021-07-09 10:45 UTC (12 hours ago)
(HTM) web link (www.areweguiyet.com)
(TXT) w3m dump (www.areweguiyet.com)
| [deleted]
| deaddabe wrote:
| This website seems like it was not updated since August 2020,
| from the list of pending pull-requests:
| https://github.com/areweguiyet/areweguiyet/pulls
| YorickPeterse wrote:
| I recently looked into this for a while (best I can do is this
| Twitter thread about it:
| https://twitter.com/YorickPeterse/status/1412417105329365004), as
| I wanted to see how feasible it would be to write a GUI text
| editor in Rust.
|
| My conclusion is basically "there's nothing viable". _If_ you are
| OK with basically limiting yourself to Linux/BSD, the GTK
| bindings are good. However, for a text editor you'll likely need
| a custom text widget (the GTK ones aren't very good), and that's
| where things (with basically any GUI toolkit) get tricky.
|
| There are a few libraries providing Qt bindings for Rust, but
| they either focus on QML, are only infrequently maintained (e.g.
| Ritual), or seem to focus more on exposing Rust to C++; not the
| other way around.
|
| egui looked really interesting, and the immediate mode GUI
| pattern is really nice to write. Sadly, it's still in the very
| early stages, and most notably is lacking support for displaying
| text with different colors/styles.
|
| The rest isn't really worth mentioning I think, at least when
| wanting to write a text editor. They basically all suffer from
| the same issues, such as:
|
| - It not being clear if the library will still exist 2 years from
| now
|
| - Poor support for Unicode (especially Emoji)
|
| - No support for assistive technologies
|
| - Poor support for flexible text rendering (e.g. multiple colors
| and styles)
|
| - Little to no documentation
|
| For a while I thought about just using Electron, or maybe Sciter
| (that would at least need fewer resources). Technology wise I
| think HTML makes sense, as it's very flexible (e.g. many GUI
| toolkits struggle the moment you want to mix text and e.g. images
| in the same widget) and quite easy to work with. Sadly, Electron
| is a fat pig and the last thing I want to do is write Javascript
| in my spare time. Sciter is proprietary, and you can't distribute
| the binaries yourself (from what I understand). That basically
| means your project is dead on arrival, at least if you intend to
| open source it.
|
| So for now I shelved my idea. Maybe in a year I'll take another
| look :)
| amelius wrote:
| > My conclusion is basically "there's nothing viable".
|
| How is this possible given that the Rust language was created
| to write the rendering engine of Firefox?
| YorickPeterse wrote:
| I don't think it was created for Firefox, as Rust (in various
| forms) has been around for over 10 years at this point I
| think.
|
| Setting that aside, Servo and Firefox both implement the UI
| side of things from scratch I think. I think from a browser
| perspective that makes sense: you're already writing a
| rendering engine, so you may as well also use it for your
| browser UI.
| pseudalopex wrote:
| Firefox in various forms has been around for nearly 20
| years.
|
| Rust was Graydon Hoare's personal project. But I don't
| think Mozilla funded it for no reason.
| phendrenad2 wrote:
| Probably the best way to go is to write native GUIs for each OS.
| That means win32 on Windows, Cocoa on MacOS, and X11 on Linux.
| win32 and X11 are just C APIs, so those are easy. On Linux you'll
| need a widget toolkit, such as GTK or Qt or WxWidgets (or many,
| many more!). MacOS is a bit more complex (the native APIs are
| exposed as Objective-C APIs), so you'll probably want to wrap
| your app in an XCode project with all of the GUI built in XCode.
| nly wrote:
| X11 isn't a GUI framework and is already legacy (Wayland)
| Klonoar wrote:
| Eh, re: macOS, I have an effort to make it possible without
| basically using the foundation crates:
| https://rymc.io/blog/2021/cacao-rs-macos-ios-rust/
|
| There's other projects that wrap the varying frameworks so I
| don't think macOS is as bad as it used to be, but I foresee it
| still being confusing due to missing docs on Apples side...
| zamalek wrote:
| There's a lot of custom rendered stuff there. The problem with
| that is, without a lot of work, custom GUIs are completely opaque
| to screen readers and other accessibility tools.
| mwcampbell wrote:
| I've started working on this. I'm not really ready to loudly
| announce this yet, but you can check out my plan and what
| little code I have so far (really just data structure
| definitions) here:
|
| https://github.com/AccessKit/accesskit
|
| Edit: I'll be spending next week working on a prototype, so I'm
| confident that I'll soon have something real to show.
| danShumway wrote:
| Very interested to see where this goes, particularly if
| you're the person working on it.
| zxzax wrote:
| Great news, I remember you talking about this before so I'm
| glad to hear this was started.
| raphlinus wrote:
| Really looking forward to seeing where this goes! A good,
| cross-platform abstraction for accessibility could make a big
| difference for a lot of people. Certainly I agree that
| accessibility is one of the major differences between a toy
| UI toolkit (of which there are many) and a real one (of which
| there are none yet in Rust).
| hawski wrote:
| I would like to see an cross-platform accessibility library,
| that would branch out to become a cross-platform widget
| toolkit, than the usual "we render widgets ourselves and
| accessibility is not even planned yet".
| edflsafoiewq wrote:
| And often just regular IME.
| dvfjsdhgfv wrote:
| Plus they always feel a bit off.
| cunthorpe wrote:
| They don't _feel_ off, they _are_ off.
|
| But with the popularization of apps, webapps and Electron
| everyone is accustomed to custom UIs for every app. Does the
| Spotify app feel Mac-like? Barely. Does it need to be? Not
| anymore.
|
| I think that as long as we don't see badly-drawn UIs and
| "ugly styles" (like Java apps' gradient buttons) we're good
| nowadays (given that someone actually designed the UI)
| denimnerd42 wrote:
| I disagree on this "not anymore" part also. For example the
| Discord app is cool and hip or whatever but it feels
| totally off and the UX is totally foreign on Windows. It's
| one reason other than the fact it's not free like mumble
| that I've never really become an active user on the
| platform. Just feels awkward to use kind of like Steam
| does.
| kaba0 wrote:
| Hyperbole, but what exactly feels native on Windows out
| of the like 3+ frameworks?
| AnIdiotOnTheNet wrote:
| > They don't feel off, they are off. But with the
| popularization of apps, webapps and Electron everyone is
| accustomed to custom UIs for every app.
|
| Congratulations everyone! We're so shitty at our jobs that
| we've once again lowered everyone's expectations!
| lights0123 wrote:
| It's more than just looks: Electron exactly replicates how
| the OS handles scrolling and text input, while custom
| frameworks often don't. Lacking macOS's scrolling velocity
| or being unable to add accents to letters in a text input
| gives the app a different behavior, which is distracting
| and feels bad.
| pseudalopex wrote:
| Electron gets things wrong too. macOS Services don't work
| in Electron apps for example. And arrow keys don't work
| right in menus on Windows and Linux.
| andrekandre wrote:
| spellcheck (right-click choose spelling menu item) in
| text fields also dont work which is super annoying
| nightski wrote:
| Unless the app takes over those right? Which happens all
| the time on the web.
| machello13 wrote:
| > Does it need to be? Not anymore.
|
| I disagree. The fact that most users don't explicitly care
| is irrelevant -- platform conventions are important. They
| teach a user how to use a new app without having to poke
| around. Users can drag and drop from one app to another and
| it just works.
|
| I certainly see the argument that for many companies, it's
| simply too expensive to write native apps for every
| platform. But I don't think we need to pretend that non-
| native apps aren't worse -- they're just economical and
| generally, even at their best, just _okay_.
| cunthorpe wrote:
| Generally I prefer an app that exists to an app that
| doesn't exist. Companies that can afford multiple teams
| are still going the multi-platform way and those who
| can't, still do it. At the end of the day, you can choose
| the best app available.
|
| I too would like every app to be a 2MB Swift app, but
| those are rare for a reason.
| machello13 wrote:
| Right, it sounds like we're on the same page. My point is
| that those apps are _worse_. They're just also cheaper to
| build.
| afavour wrote:
| I think that ship has already sailed with the prevalence
| of the web. Users are already very used to learning a new
| UI for a new app, their online bank doesn't work like
| Gmail does, nor does Netflix, etc. etc.
|
| Sometimes it feels like OS UI is literally just window
| dressing these days.
| pseudalopex wrote:
| Being common doesn't mean it's good.
| munificent wrote:
| _> The fact that most users don 't explicitly care is
| irrelevant -- platform conventions are important. They
| teach a user how to use a new app without having to poke
| around._
|
| I agree that's important. But I think it's much less
| important these days now that operating system developers
| seem happy to churn their platform's UX every couple of
| years too. The days when you could read the Apple Human
| Interface Guidelines and understand how all Mac apps
| would behave for the next decade are long gone,
| unfortunately.
|
| For reasons I don't totally understand, the platform
| vendors are themselves constantly invalidating the
| information in users' heads, so there's simply less in
| there for application developers to build on anyway.
| machello13 wrote:
| > For reasons I don't totally understand, the platform
| vendors are themselves constantly invalidating the
| information in users' heads, so there's simply less in
| there for application developers to build on anyway.
|
| To be honest, I'm not sure this is true. macOS has had
| pretty much 1 major redesign in recent memory (Big Sur),
| and even that is mostly a visual update -- functionality
| is all still there and works the same. Toolbar buttons
| are still toolbar buttons, you can still drag and drop
| them around, etc etc. In practice, the amount that
| actually "churned" is pretty small.
| mwcampbell wrote:
| > operating system developers seem happy to churn their
| platform's UX every couple of years too
|
| Since the top-level comment in this subthread is about
| accessibility, I should mention that the churn is
| especially bad for blind people using screen readers.
| That's why I'm apprehensive about Windows 11.
|
| When Windows 10 came out, I was the developer of a third-
| party screen reader. I did what I could to deal with the
| platform churn, in the limited time that I could give to
| it. But I was happy that no critical applications (even
| Office) were following where the Windows team was trying
| to go with the platform; once you started up your
| applications, your PC basically worked the same as before
| -- even more or less the same as Windows 7.
|
| Then I joined the Windows accessibility team at
| Microsoft. I suspect that if there had been any
| significant UI churn in Windows while I was there, the
| cognitive dissonance that I felt during that time would
| have been stronger. Perhaps I could have done some good
| for the experience of using Windows 11 with a screen
| reader if I had stayed, but then again, an individual
| developer in an org that big usually doesn't have a lot
| of power. Anyway, I had my reasons for leaving, and I'm
| glad to be free to share my honest opinions on Windows
| again (within the bounds of my NDA).
| adamnemecek wrote:
| I'm involved with this nanovg Rust clone called femtovg
| https://github.com/femtovg/femtovg. It's not a GUI framework but
| I and several other people are using it for building GUI
| frameworks. Join the discord https://discord.gg/V69VdVu.
|
| I have recently added wgpu backend that for now lived in my fork
| https://github.com/adamnemecek/femtovg
| jeffreyrogers wrote:
| I've done professional GUI programming and there are really only
| three options that make sense:
|
| 1. Write the GUI natively per platform. This is best from a UX
| perspective but is expensive and you probably need different
| developers working on different platforms. Other downside is that
| really advanced functionality is harder to implement and
| sometimes the performance of native APIs is poor and hard to
| improve (Apple has this problem frequently).
|
| 2. Use a cross-platform framework like Qt (Electron would also go
| here). This is the most cost-effective solution, but generally
| does not feel like a native app, which may or may not be a
| problem.
|
| 3. Use a custom GUI framework.[0] Probably the most expensive
| option and hard to hire developers for, but can be warranted for
| complex applications like CAD tools, games, etc.
|
| The problem with Rust GUI libraries is that they can't really
| target 1 or 3 so they need to target option 2. But the big
| players there are Qt and Electron. Qt is popular because it works
| well, is proven, and has a lot of financial backing. If you don't
| need something super complicated a decent Qt developer can get it
| working quickly. Electron is popular because there are tons of
| web developers and they can be productive quickly.
|
| Rust attracts a lot of hobbyists who are talented and have good
| ideas, but I don't think they have the staying power (or
| financial ability) to provide something that competes with Qt and
| Electron. I'm sure it can be done in theory but I don't see it
| happening in practice anytime soon.
|
| [0]: By custom I mean tailored for the type of application you
| are making, e.g. what a lot of game devs do for their internal
| tools.
| Razengan wrote:
| > _sometimes the performance of native APIs is poor and hard to
| improve (Apple has this problem frequently)._
|
| Compared to the alternatives (especially Electron, where you
| oddly forgot to mention this), the performance from native
| Apple APIs is often the best you can get.
|
| Have you looked at stuff like TextKit 2 etc.?
| jeffreyrogers wrote:
| I like Apple a lot, it is the most pleasant platform to
| develop for IMO, but performance depends a lot on what you're
| doing and how much they've optimized it.
| jcelerier wrote:
| > 1. Write the GUI natively per platform. This is best from a
| UX perspective but is expensive and you probably need different
| developers working on different platforms. Other downside is
| that really advanced functionality is harder to implement and
| sometimes the performance of native APIs is poor and hard to
| improve (Apple has this problem frequently).
|
| That really depends on the software though. I develop a media
| software and my users are adamant that they want the exact same
| look&feel across the three main desktop platforms (to the point
| that I had to use freetype everywhere for font rendering -
| thankfully easy with Qt). Also had the same case for a customer
| at a previous job - I remember comparing screenshots across
| macOS and Windows until they matched in a pixel-perfect way.
|
| On the other hand, if you're writing, say, a productivity app,
| calendar, notes manager, most likely it is better for it to fit
| to each platform.
|
| Although I personally also prefer to use the same apps across
| platforms, e.g. my main combo no matter whether I'm on Linux /
| macOS / Win32 is Zim for note-taking, Strawberry for music, Qt
| Creator for IDE, Seafile for data exchange, Telegram and
| ripcord for chat, Krita for image manipulation, Darktable for
| raw photo processing, Digikam for photo collection management ;
| DaVinci Resolve for video editing.
|
| With the exception of Zim and Darktable which are GTK, all the
| others are Qt-based.
| Wowfunhappy wrote:
| > I develop a media software and my users are adamant that
| they want the exact same look&feel across the three main
| desktop platforms
|
| Are these _end-users_ , or just the person in charge? I find
| it hard to believe that the actual users of the software
| would care about this.
| jcelerier wrote:
| end-users. It's very important for them to have the
| software be exactly the same no matter the platform, as
| it's somewhat common to start a work on e.g. a mac as a
| first draft and finish it on a windows or linux machine
| where the production actually runs.
| freedomben wrote:
| > media software
|
| If this is editing audio or video, I can 100% believe that.
| Anything with complex controls that a user has to learn, or
| keyboard shortcuts, it really matters to end users.
|
| I worked on a Qt app quite a few years ago and that wasn't
| a media app but it was a complex GUI. Our end users also
| wanted the exact experience regardless of platform.
|
| On a related note, if you need a rich UI I totally
| recommend using Qt on the frontend and the backend. Qt
| isn't just UI libs. There are a bunch of super useful
| server-side libraries as well that you can use. We used
| protobufs and had unbelievable performance on the front end
| and backend. It was a beauty to behold.
| elsjaako wrote:
| It's funny you mention media software. GTK was originally
| written as a toolkit for GIMP (It stood for GIMP Tool Kit).
| kodablah wrote:
| > Electron is popular because there are tons of web developers
| and they can be productive quickly.
|
| It's also popular because a browser engine as a lot features
| that are otherwise difficult to get (e.g. bandwidth-estimated
| multiplexed video streaming).
| throwaway894345 wrote:
| Also accessibility and bulletproof text rendering and input
| handling and layout and a million other things that are a lot
| more involved than people think. I say this with great
| sadness as someone who wishes Electron wasn't the most
| practical solution at the moment.
| throwaway894345 wrote:
| > Use a custom GUI framework.[0] Probably the most expensive
| option and hard to hire developers for, but can be warranted
| for complex applications like CAD tools, games, etc
|
| This will also suck for users because things like focus,
| keyboard shortcuts, accessibility, non-English text rendering,
| etc will probably not work as expected if at all. It turns out
| there's a lot that goes into GUI that most of us take for
| granted.
| bradrn wrote:
| Wrt option (2), what do you think of other libraries like
| wxWidgets or GTK+? At least on Windows, the latter certainly
| doesn't feel at all 'nice to use' (admittedly a subjective
| criterion), but I find I quite like programs made with
| wxWidgets.
| xiaomai wrote:
| GTK+ on Rust is a thing that is seeing a lot of active work
| (see https://gtk-rs.org/). I think some of the core gnome
| stuff has even moved over to rust at this point (like
| libsrvg).
| nonbirithm wrote:
| I have used wxlua in the past and it's a seriously underrated
| feat of engineering in my opinion. It would be great if there
| were somehow a wrapper for wxwidgets that plays well with
| Rust, fingers crossed.
| jeffreyrogers wrote:
| I've never used them, but they seem similar to Qt. For
| whatever reason Qt seems to be the most popular in commercial
| products.
| asddubs wrote:
| wxwidgets is unique in that it translates to native gui
| widgets (when available)
| gregwebs wrote:
| Why does Rust need to compete with QT? Most programming
| languages have QT bindings. Similarly, different languages
| could work with Electron through compile to JS/WASM.
| k__ wrote:
| Tauri seems like the only viable Electron alternative right
| now, and it's written in Rust.
| native_samples wrote:
| That's a stretch.
|
| The most viable competitor to Electron other than Qt are the
| Java GUI toolkits. There are several but the two main ones
| are Swing (old, mature, not gonna win any prettiness awards
| but it gets the job done well enough in IntelliJ), and JavaFX
| (pretty darn good but people forget about it).
|
| I've shipped apps using JavaFX before. It was quite a
| pleasant experience and I'd do it again in a heartbeat.
| tomnipotent wrote:
| IntelliJ is great example of Swing, which also extends into
| its plugin ecosystem.
| adrusi wrote:
| It's not very clear from their docs, but it looks like tauri
| is mostly a way to launch a system WebView from rust and
| communicate with it via message passing. Doesn't really seem
| like a GUI toolkit for rust, since all the GUI stuff is going
| to be done in JS.
| xtagon wrote:
| The same can be said of Electron.
| YorickPeterse wrote:
| The difference is that Electron guarantees you're always
| using a known version/engine. With Tauri, you'd be using
| whatever is installed, and that engine may behave
| different from what you are used to.
|
| So basically you get all the drawbacks of developing for
| different web browsers, without really any of the
| benefits a cross-platform GUI gives you.
| wila wrote:
| Just like building for the web then? In that scenario you
| also do not know what version the browser is (or even
| what kind of browser).
|
| An advantage would be that the browser gets security
| patches by the OS.
| imbnwa wrote:
| Is this really a problem now that IE11 is finally being
| deprecated? You basically have Blink/Gecko/Webkit which
| is no different from regular web dev
| jokethrowaway wrote:
| Does it use less RAM because it's shared with the system
| browser? I sure as hell avoid all the Electron based apps
| because of their memory consumption.
|
| Cross-browser compatibility is not too bad these days.
| YorickPeterse wrote:
| I did some testing using webview
| (https://github.com/Boscop/web-view) which is used by
| Tauri if I'm not mistaken. On Linux this uses webkitgtk,
| and it used a total of around 100 MB. That's not that
| good, but certainly better compared to Electron.
| jokethrowaway wrote:
| Conrod is targeting 3 and it does a decent job at that
|
| https://www.youtube.com/watch?v=_ZXLCVibI8c
|
| Themes are something they would like to implement and once they
| have themes they could do native looking themes like Qt (which
| are perfectly reasonable, I'm generally very happy as a user
| with Qt applications across all platforms)
|
| I agree with you there is not yet an audience big enough to
| justify a Qt written for Rust, but who knows, maybe something
| will change in the next years.
|
| That said, when I had to do something like this, I used Qt with
| Rust, just because I couldn't justify the time investment of
| reimplementing a native looking theme on top of Conrod.
| gfxgirl wrote:
| Electron is popular because it gets the job done quickly. I can
| start a new Electron app in 10-20 minutes and build it across
| Linux/Mac/Windows in moments. There's almost no setup needed
| except node which is easy to install locally (nvm, nvm-
| windows). Most other solutions require installing large tool
| chains manually first and lots of pre-reqs and being familiar
| with those tool chains. On Electron I just "git clone proj &&
| cd prog && npm i && npm run build && num run dist" and an
| installer/msi/dmg/AppImage pops out.
|
| I'm fully capable of writing a native app or using Qt but for a
| large number of apps my clients won't notice a difference and I
| can be finished faster with Electron so I use Electron.
|
| I even use to just provide a GUI shell over running command
| line tools. Sure it's "bloated" by some definition of bloated
| but I get the job done so much quicker and 99% of the cross
| platform issues disappear.
| michaellee8 wrote:
| The third option is basically Flutter. Maybe Rust guys would
| like to do some Flutter bridge?
| lenkite wrote:
| A pretty amazing interop library at https://thlorenz.com/rid-
| site/
| forrestthewoods wrote:
| Good post.
|
| However I think you need to differentiate between GUI for
| internal tools and customer facing products.
|
| Dear ImGui is pretty damn stellar for internal tools. Nigh
| unbeatable along certain axes. Rust has a couple of Dear ImGui
| inspired libraries. I think for tools and editors Rust is
| getting close to being perfectly viable.
|
| For customer facing GUI I largely agree with your assessment.
| xbar wrote:
| Is anyone interested in curating a collection of TUI components
| in Rust?
| celeritascelery wrote:
| One I am excited for is Druid. Is is worked on by some of the
| same people that the xi editor, and they really understand
| responsive design and good font rendering.
|
| The backend is Piet, which are platform native crates. And then
| Druid abstracts over those backends. This lets you write GUI code
| once and then use native API's and features.
|
| https://github.com/linebender/druid
|
| https://github.com/linebender/piet
| raphlinus wrote:
| Thanks! To clarify, the platform abstractions are both in piet,
| which is 2D drawing, and also in druid-shell, which contains a
| wide range of other things, including menus, copy-paste, and a
| good start on IME.
|
| I've written lots about Druid. I haven't really chimed in much
| in this thread, as a lot of the discussion is frankly not that
| relevant to what we're trying to do. We are currently _not_
| focused on making a good out-of-the-box developer experience,
| which is what most people here seem to be looking for. Rather,
| we 're systematically exploring what it takes to make a good
| next-generation UI toolkit, and building a knowledge community
| around that. It turns out there's quite a bit to that, much
| more than building a toy UI toolkit.
| grumblenum wrote:
| Has this actually changed since 2017?
| grayrest wrote:
| There are a lot more options but nothing that's clearly
| winning. The first projects I'd check for building a GUI today
| are Microsoft exposing the Windows UI toolkit and the
| Rust+Flutter integration. I know that the GTK crowd were
| engaged with the Rust core team years ago but I don't know if
| anything came from that.
|
| I'm still on the DOM-as-the-main-platform train (since 2001, I
| believe in the Mozilla vision) so I haven't been tracking the
| details that carefully.
| pjmlp wrote:
| Microsoft's ongoing efforts for WinUI seem to be missing.
|
| https://github.com/microsoft/microsoft-ui-xaml/issues/2488
|
| As mentioned on the thread, the current samples are at
| https://github.com/microsoft/windows-rs
| Zababa wrote:
| There's an open issue for them
| https://github.com/areweguiyet/areweguiyet/issues/62
| pjmlp wrote:
| Thanks.
| ginko wrote:
| That doesn't seem very useful if it's Windows only.
| qwerty456127 wrote:
| I have switched half back to Windows (after a decade of 100%
| Linux) recently just because I finally accepted there is no
| way of making GUI apps as a single developer nearly as easy
| and pleasant as WinForms with VisualStudio. The result is
| virtually Windows-only (it can run on Mono but there are some
| quirks) but it feels worth that sacrifice.
| Blaiz0r wrote:
| Thats' a shame, and definitely something that the Linux
| ecosystem needs to address.
| mumblemumble wrote:
| Linus recently said something that left me thinking that
| Linux on the desktop has much deeper problems that need
| to be addressed before it's worth even thinking about the
| fine details of GUI toolkits.
|
| https://www.youtube.com/watch?v=Pzl1B7nB9Kc
| rodelrod wrote:
| > Linus recently said
|
| At DebConf 2014
| mumblemumble wrote:
| Ha. That's what I get for looking at the video posting
| date and assuming it means anything.
| pengaru wrote:
| To be fair, 2014 _is_ recent in Debian time.
| AnIdiotOnTheNet wrote:
| True, but it isn't like the things he talks about have
| changed significantly since then.
| qwerty456127 wrote:
| Yet Linux worked perfectly for me and many people/offices
| I migrated to it (they didn't need any Windows-only apps)
| during the recent decade. Since about half that time
| Windows and Mac users don't even have to learn anything -
| everything is familiar (today users of Ubuntu should
| better learn GNOME3 workspaces though but that's not
| necessary).
|
| So I really have zero idea of what problems might he
| mean. The only problems there are no native Photoshop and
| Visual Studio. There was also a problem with games but
| apparently it's not the case any more.
| pjmlp wrote:
| I lost any hope when GNOME developers decided to kill
| Glade and started suggesting that developers should code
| raw .ui files directly.
|
| https://blogs.gnome.org/christopherdavis/2020/11/19/glade
| -no...
|
| Thankfully KDE is still around, but many seem to not
| appreciate the UI design tooling provided by Qt, because
| $$$$.
|
| So I rather waste my time on Earth on platforms that
| value good UI/UX tooling.
| zxzax wrote:
| Please don't assume bad faith. Glade was not "killed,"
| there are technical reasons why Glade cannot be used for
| GTK4 (I can give more detail if you want). There is
| currently a new tool being developed by a Glade
| maintainer, catch this guadec talk later this month if
| you want to know more:
| https://events.gnome.org/event/9/contributions/191/
|
| Nobody is particularly happy about having to edit the XML
| directly but it's the best option right now until the new
| tools stabilize.
| mumblemumble wrote:
| I think that this might speak to the deeper problem that
| a lot of people have experienced with GTK: stability. The
| project isn't a huge well-funded company with lots of
| vendor-lock in like Microsoft is; it can't afford to be
| rethinking how the GUI toolkit should work every few
| years like Microsoft does. (Or continuing to support and
| maintain all the old no-longer-favored GUI frameworks
| like Microsoft does.)
|
| It's great that GTK4 has decided to commit to API
| stability, but, at this point, it may be too little, too
| late as far as the project's reputation among many
| developers is concerned. Having to lose a venerable tool
| like Glade to get to the API-stable version doesn't
| exactly take the edge off.
| zxzax wrote:
| I've posted about this before, but if you want GTK and
| you believe API stability is the most important thing
| then you should just use GTK3. The API there is frozen.
| I'm not sure what "reputation" you're referring to but if
| GTK does not meet your needs, and Qt (or something else)
| does, then I think that's great for you, you should just
| use that.
| entropy1111 wrote:
| GNOME being slow and not having basic features like
| thumbnails in the file picker after almost 18 years was
| often attributed, by their maintainers, to be caused by
| GTK3 limitations. Even now Glade still needs a lot of
| "volunteering" to be production ready for GTK3. I don't
| use GTK anymore, this is my opinion after reading a lot
| about it and seeing recommendations like "if you need
| documentation just read existing code", "why is Glade
| missing X or Y? just copy some XML node, just edit the
| XML and pray".
|
| Anyway who cares, maybe GTK4 is good and new GTK threads
| will not be full of people talking about how bad it was.
| But why not move the tools together with the rest? I
| know, it's open source, lack of maintainers, but I
| wouldn't dare to declare my toolkit stable until basic
| tools work. Qt is also guilty of doing that in some ways
| but at least the previous version is still production
| ready and they move really fast.
|
| I don't know I'll ever get over my irrational anger about
| how they handle(d) GTK.
| badsectoracula wrote:
| > if you want GTK and you believe API stability is the
| most important thing then you should just use GTK3. The
| API there is frozen
|
| That is certainly not a solution, you just postpone the
| problem.
|
| The real solution would be the Gtk4 to be 100% backwards
| compatible at both the API and ABI level with Gtk3 and
| similarly with Gtk5, Gtk6, etc.
|
| Otherwise you're just subscribing to wasting your time -
| it might be now or it might be 5 years from now, it
| doesn't matter however as it _will_ happen unless the Gtk
| developers finally decide to stop breaking their library
| every few years.
|
| (of course don't get me wrong, it is their library and
| they can do whatever they please with it, they are giving
| it for free and they are not beholden to anyone - however
| that doesn't mean others like to have their code broken
| and waste time that they could use to improve their
| applications instead)
| mumblemumble wrote:
| Alternatively GTK3 could get a higher level of ongoing
| support. That was what I was alluding to when I
| referenced Microsoft. For example, WinForms has
| technically been superseded for ages now, but, while it's
| not necessarily getting any big new features, WinForms
| apps still look decent on newer versions of Windows,
| benefit from things like updates to the common dialog
| boxes, and continue to be well-supported in new versions
| of the developer tools. So one doesn't necessarily have
| to have a lot of anxiety about leaving an old WinForms
| app on WinForms. With GTK3, on the other hand, I would
| guess that it's going to get the absolute bare minimum of
| love, and probably become a liability rather sooner than
| I might like, because the project simply doesn't have the
| resources to maintain a higher level of support.
|
| And yeah, you're right, the GTK team isn't beholden to
| anyone. But... GUI code is expensive to write and
| expensive to maintain. So a GUI toolkit can have an
| outsize impact on the health of projects that use it.
| There's value in talking about things like this publicly,
| so that anyone who's shopping for a GUI toolkit can have
| a better understanding of what they might be getting
| into.
| badsectoracula wrote:
| Ideally they could have done that with Gtk2 which would
| continue on to Gtk3 and Gtk4 without breaking backwards
| compatibility.
|
| Of course yes, the next best thing wrt. backwards
| compatibility is at least not breaking what works - but
| IMO that is a waste of time for both the Gtk developers
| (sure, it'd be self inflicted, but still) who would need
| to support two (or three or four or however many times
| they decide to break their own APIs) libraries that do
| essentially the same thing in different ways, _and_ for
| the developers who at the end of the day will most likely
| need to move on to the next version at some point to gain
| access to new features that they may need - so they 'll
| spend that porting time anyway.
|
| > And yeah, you're right, the GTK team isn't beholden to
| anyone. But... GUI code is expensive to write and
| expensive to maintain. So a GUI toolkit can have an
| outsize impact on the health of projects that use it.
| There's value in talking about things like this publicly,
| so that anyone who's shopping for a GUI toolkit can have
| a better understanding of what they might be getting
| into.
|
| Indeed and this is why i mention my issues with backwards
| compatibility whenever i see it being relevant.
|
| I do believe the Gtk developers are free to do whatever
| they want as they are not beholden to my -or anyone
| else's- wishes for stability, especially when they give
| out such an otherwise high quality library for free.
| However that is from their perspective.
|
| From the library users' (that is the developers who use
| the library) perspective however there are additional
| issues, like all the time you spent learning the library
| (breaking the API invalidates your own knowledge which is
| something that is also important - unless you plan to
| somehow live forever it makes sense to want to avoid this
| sort of "knowledge churn" :-P) and writing the code that
| uses it (important especially for framework-style
| libraries like Gtk that put their tendrils everywhere in
| your application). And even if someone believes (wrongly,
| IMO) that commercial developers can afford all that time,
| it still is an issue with FLOSS since the vast majority
| of which is developed during its developers' free time:
| that time would have better been used to improve the
| applications instead of keeping up with their
| dependencies' breakage (e.g. XFCE or... Gimp :-P).
|
| And of course from the end users' perspective it also
| means that even if the developers decide to drop a
| program, they can keep using it for a long time without
| having to worry about the libraries their program depends
| on getting stale (since they are linked dynamically), not
| supporting new features (like, e.g. Wayland - AFAIK Gtk2
| apps do not support it natively and chances are if a new
| display server is made Gtk3 apps wont support it either)
| or having unfixable security issues (for the applications
| where that makes sense at least).
|
| But yeah, Gtk developers - or any library developers - do
| not need to care about all of that nor they have to
| really. As you wrote, it is the developers who decide or
| not to use a library that care about such things mostly.
|
| Sadly at last on Linux there aren't that many choices: of
| the "mainstream" toolkits only Gtk and Qt exist. Gtk is,
| well, Gtk and Qt cannot provide "perfect" ABI
| compatibility even if they wanted to because of C++
| (there are some hacks that could be made but i am not
| aware of any project doing such a thing - i think only
| Haiku does something similar with proxy libraries that
| forward the GCC C++ 2.95 calls to modern GCC C++ calls
| for BeOS compatibility). But Qt is also a different
| beast, they are a middleware company with different
| priorities, the people that pay money on it (and thus
| affect these priorities) do not care much about providing
| a stable platform and can affort to waste time on
| upgrades. From other toolkits there is also Motif but
| that fell out of favor and got opensourced way too late
| to make much of a difference - its API/ABI _is_ stable
| though and has been stable for decades, but that means
| nothing when barely anyone uses it or develops for it.
|
| Personally i use Lazarus and LCL. LCL uses a variety of
| backends, kinda like wxWidgets, but unlike wxWidgets it
| doesn't break its API. This pushes the issue of keeping
| up to date to the LCL developers (who could have spent
| their time in fixing LCL's other issues - of which are
| many - instead) but that is how things are.
|
| I think Java and SWT might be another stable solution for
| a native UI, AFAIK this never broke backwards
| compatibility either... or at least it never did back
| when i looked into it several years ago. Looking at some
| examples in their site, several of them seem to be
| somewhat old so it probably is stable (isn't it great how
| when you do not break your API left and right you get to
| also get time to build better documentation that you
| don't have to invalidate it after a while?)
| jcelerier wrote:
| > Qt cannot provide "perfect" ABI compatibility even if
| they wanted to because of C++
|
| That does not really matter in practice though. I ship a
| Qt app as AppImage, it works fine from CentOS 7 to the
| very latest ArchLinux. I just ship libc++ along with it -
| which is the same that I have to do in Windows anyways.
| badsectoracula wrote:
| Of course it matters in practice since we're talking
| about dynamic linking that applications can link against
| the OS-provided libraries so that they can keep gaining
| new features and bug fixes.
|
| A trivial example on Windows would be how Win32
| applications get to use the Win+; emoji popup even if
| they were made before Windows even got that feature, or
| how even classic VB applications can be made to run in
| HiDPI mode by ticking a shortcut checkbox despite being
| written decades before HiDPI was even a thing (assuming
| they use twip instead of pixel coordinates at least).
|
| Or on Linux, how some old games made for it need their
| bundled SDL removed so that the games can use the system-
| provided version because the old version tried to use OSS
| or whatever was common at the time the game as written
| and the new version can use ALSA or even Pulse that
| didn't even exist in older times. And i remember reading
| on twitter about some distros planning to provide the
| SDL1-to-SDL2 wrapper as an option instead of the real
| SDL1 because it provides better compatibility with some
| modern window managers... and Wayland (that SDL1 doesn't
| support at all but the API doesn't really make a
| difference and could work perfectly fine with Wayland).
|
| > which is the same that I have to do in Windows anyways.
|
| Windows comes with WAY more functionality out of the box
| so that applications do not have to rely as much in their
| own libraries and can rely on the OS to provide and keep
| functionality up to date. Of course applications can
| ignore that, but they just do not get those new features
| and fixes.
|
| The recent Visual C++ runtimes not being part of Windows
| is a baffling and really stupid decision though. I am
| certain it has more to do with internal politics and
| feuds between WinDiv and DevDiv than something practical.
| pjmlp wrote:
| Thanks for the link, I will watch it when the opportunity
| comes.
|
| However it is like the sibling comments mention, this
| hasn't been properly managed as message to the UI/UX
| community.
|
| So when someone used to Forms, WPF/Blend, Qt Designer,
| Interface Builder, Delphi, C++ Builder, Swift UI,
| Flutter, JetPack Composer,... sees blogs and tutorials
| where .ui files are written by hand and direct use of
| GtkBuilder is praised, eventually all interest is gone.
|
| Anyway, thanks for the link and for jumping in
| zxzax wrote:
| That blog is just one developer's opinion, not an
| official statement. Although I will say I share the
| opinion, Glade messes up my ui files and I can't
| recommend using it if you want to use any newer widgets.
| It has always had those problems, but now with GTK4 it's
| no longer really worth it to try to work around them.
|
| Also, Glade is not really even used by GNOME designers
| that much, what they do is make mockups in some other
| tool (usually Inkscape) and then have the developers
| implement it. I don't know about other GTK based
| desktops, though I think some Elementary developers are
| working on this: https://github.com/akiraux/Akira
| shock wrote:
| > Nobody is particularly happy about having to edit the
| XML directly but it's the best option right now until the
| new tools stabilize.
|
| You are proving GP's point for him:
|
| > So I rather waste my time on Earth on platforms that
| value good UI/UX tooling.
|
| The fact that that Glade was deprecated without a
| replacement being ready means exactly that GNOME does not
| "value good UI/UX tooling".
| freedomben wrote:
| > _The fact that that Glade was deprecated without a
| replacement being ready means exactly that GNOME does not
| "value good UI/UX tooling"._
|
| That's a false dichotomy. It could be (and I believe is)
| that things are a tradeoff. They obviously value good
| tooling (what developer doesn't? and look at the docs),
| but they value other things too and had to make a
| decision. With limited resources you can't do it all.
| zxzax wrote:
| What you've said is really not correct, at all. For one,
| Glade is not deprecated in the sense that it doesn't work
| any more, it still works okay with GTK3, however it has a
| number of limitations that may make it difficult to use
| (which it always had, nothing has changed here). Two, a
| replacement is being worked on, I'm really not sure what
| your criticism is besides "go faster" which, I'm sure we
| all wish we could write code faster and have it work
| perfectly and do everything the first time, but that's
| not realistic.
|
| Edit: Just to be clear here, in my opinion the new tools
| will likely end up being a large improvement on Glade.
| Glade is a pretty old application that by design does a
| number of weird things that don't match current best
| practices, you can see some of them if you read the blog
| post that was posted above.
| criddell wrote:
| I used to think so too. Around 2005 I finally accepted
| that Linux on the desktop is what it is and not much will
| change.
| ZeroCool2u wrote:
| Flutter desktop works shockingly well on Linux desktop in
| my experience. It's AOT compiled to native byte code, so
| it's pretty fast. I think the main weakness would be 3D
| applications, but I can't say for certain.
| interlocutor wrote:
| And why is it better than Web technologies? Even if you
| don't want a server involved you can still make a desktop
| app using Web technologies.
| mumblemumble wrote:
| Compared to WinUI, I wouldn't exactly call web
| technologies' developer experience pleasant.
|
| This was pre WinUI, but a while back I worked at a shop
| that simultaneously maintained Web-based and WPF versions
| of an app. The Web version required 3 dedicated
| developers to maintain. The WPF version needed about half
| of one person's time, and had more features.
|
| I would say that the main thing favoring tools like
| Electron is entry costs. There are lots and lots of
| people who know who to do front-end Web development, and
| you can do a good job of supporting all platforms using
| free tools. Even if you grant me for the sake of argument
| that native GUIs cost less in the long run, there aren't
| a whole lot of people who have experience doing them
| these days, even fewer who have experience on more than
| one platform. Going that route also requires you to shell
| out for Macs and probably also Visual Studio.
| pjmlp wrote:
| If it isn't a PWA, or integration with 3rd party, I
| rather not make my users suffer.
| criddell wrote:
| In another thread somebody mentioned accessibility
| issues. Web technologies are still embarrassingly bad at
| this compared to native toolkits.
|
| The other reason is that you care about resource usage.
| Web apps use more battery, bandwidth, and CPU.
| tasogare wrote:
| You wouldn't ask the question if you had developed both
| GUI apps on MS stack with VS and web apps: the MS dev
| experience is very good, while the web one is meh at
| best. C# vs JS, XAML vs HTML+CSS (debatable), desktop
| application model vs web one, VS vs whatever else, there
| is a lot of strong arguments in favor of the MS stack in
| that case.
|
| Microsoft is trying to port some of this magic with
| Blazor, with is quite liked from what I read here and
| there.
| interlocutor wrote:
| It is C# vs Typescript. Modern JavaScript is a very good
| language, and when enhanced with TypeScript's static
| types, it is every bit as good as C#.
|
| XAML and MVVM is all about two-way data binding. JS
| frameworks copied it at first. But now it is widely
| recognized that 2-way data binding is a bad idea.
|
| You can use for Web development too.
| sgift wrote:
| The developer experience of web technologies is after all
| this time still far worse than all the desktop libs I've
| tried. It is even worse than Swing (for those who don't
| know: That's Javas GUI technology. From the 90s). Add to
| that the horrible RAM usage, the general jankiness and
| ... thanks, but no thanks.
| gedy wrote:
| > It is even worse than Swing (for those who don't know:
| That's Javas GUI technology. From the 90s).
|
| As someone who loved Swing and used to hate JavaScript,
| that's really nonsense if you actually want to be a UI
| developer (and not just some side afterthought).
|
| State management and the custom capabilities when you
| need them are amazing. I wasted a lot of my time writing
| tons of Swing code. Sorry, but the modern front end
| experience is much more enjoyable and productive. If you
| want "native widgets" I get the complaint, but most
| platforms seem to be less interested in consistent
| experiences these days.
| kaba0 wrote:
| > State management and the custom capabilities when you
| need them are amazing
|
| JS devs just rediscovered MVC with some added
| immutability and that's all. Hardly more productive.
| Also, I don't see your point on custom capabilities -
| please add a slight modification to the date picker
| widget. Oh, you have to reimplement the whole thing with
| some insane number of divs, while you can trivially
| override certain parts of it in most desktop libs.
| publicola1990 wrote:
| Dependency management is simple for Swing. In can mostly
| be assumed that it is available and works. How many
| dependencies will an Electron /Webstack based app have?
| pjmlp wrote:
| Plus there are frameworks like JGoodies and everyone
| should look at Filthy Rich Clients book.
|
| The biggest issue with Swing is just bad defaults. Except
| for NeWS, Sun wasn't really into the desktop business.
| criddell wrote:
| I really like JetBrains IDEs and I think they are based
| on Swing.
|
| Although I haven't used it for more than a decade, I
| still have some fondness for Java. I like Workflowy but
| am not crazy about it being in the browser. I
| contemplated writing my own outliner and Java + Swing is
| one combination I'm thinking about.
| badsectoracula wrote:
| > nearly as easy and pleasant as WinForms with VisualStudio
|
| Check out Lazarus: http://lazarus-ide.org
|
| It is _WAY_ easier than WinForms. WinForms ' VS
| "integration" feels as if they started with what Delphi 1
| could do back in 1995 or so, implemented most of it and
| then decided that is enough.
|
| Lazarus' GUI tools are way above and beyond anything
| WinForms can do and the underlying LCL is crossplatform
| using native widgets wherever possible with backends for
| Win32, Gtk1/Gtk2/Gtk3 (though Gtk2 might be the best ATM),
| Qt4/Qt5, Cocoa and a few others (Carbon, fpGUI and some
| Amiga toolkit).
|
| Here is a video from 3 years ago where i make a simple
| sliding image puzzle game under Linux using it:
|
| https://www.youtube.com/watch?v=s_01Xhd2EJM
|
| Also here is another video from 6 years ago where i make a
| 2D tilemap editor in Windows:
|
| https://www.youtube.com/watch?v=_3JgeIUo1X0
|
| And another video from ~10 years ago making a doodle app:
|
| https://www.youtube.com/watch?v=nZuddi3zR_0
| qwerty456127 wrote:
| Lazarus is way too vingage programming language (not
| nearly as handy as C# 5.0) and the IDE's editor isn't
| nearly as intelligent as that of VisualStudio (let alone
| with ReSharper). But it indeed seems the only of the kind
| truly cross-platform. The only close-enough alternative I
| found on Linux was QtDesigner+Python but it still wasn't
| that convenient.
| naavis wrote:
| A lot of Windows users would probably disagree.
| mumblemumble wrote:
| One of the tags you can select is WinUI. Another is MacOS. So
| they clearly thought platform-specific UI might be usful to
| someone. It may not scratch your itch, but that doesn't mean
| it's useless.
|
| For my part, I'd argue that, if you care about inclusiveness,
| you should probably favor either Electron or some other
| option that builds on the Web stack, or writing a separate
| native front-end for every platform. The problem with all the
| cross-platform toolkits is that they have accessibility
| problems.
| pjmlp wrote:
| Targeting 90% of the desktop consumers and non-iPad Tablet
| owners (Android tablets are being overshadowed by 2-1) seems
| pretty useful business opportunity to me.
| bruce343434 wrote:
| > 90%
|
| more like 76%:
|
| https://www.statista.com/statistics/218089/global-market-
| sha...
|
| Can't be bothered to verify the tablet claim but that's
| probably wrong as well.
| kitd wrote:
| 76% versus 16% for the next highest.
|
| Is it really worth the argument?
|
| ed: https://gs.statcounter.com/os-market-
| share/desktop/worldwide...
| jen20 wrote:
| Market share != profit share when it comes to app
| ecosystems.
| pkphilip wrote:
| That depends entirely on the region you are targeting.
| There are parts of the world where the IOS users are
| around 3% (eg. India)
| Zababa wrote:
| And usually 100% if you're in a big company/typical
| corporate environment. Not everyone targets the whole
| market, and lots of companies are windows-only, for
| better or for worse.
| [deleted]
| swiftcoder wrote:
| That may be true for the market as a whole, but tech
| companies tend to be very MacBook-centric. Windows tends
| to be used by some managers and a handful of
| graphics/games engineers. Or the cut-rate contractors
| they won't spend on for MacBooks.
| pjmlp wrote:
| US-tech companies, and comparable countries.
| pjmlp wrote:
| Lets assume your numbers are the right ones, 76% is no
| business to throw out of the window (pun intended).
|
| Plus there are these other toys called HoloLens and XBox.
| mastax wrote:
| Related tangent:
|
| I just spent a few hours evaluating WinUI 3 for a new project.
| There's currently no way to hook into the app exit event. Want
| to flush your SQLite store before you exit? Tough.
| pjmlp wrote:
| Sure there is.
|
| It is all a matter of using either UWP or Win32, regarding
| which API to use.
|
| Win32 use WM_CLOSE
|
| https://docs.microsoft.com/en-us/windows/win32/winmsg/wm-
| clo...
|
| UWP use Application.Suspending
|
| https://docs.microsoft.com/en-
| us/uwp/api/windows.ui.xaml.app...
| thrower123 wrote:
| I'm not sanguine about this actually having any staying power
| before they get distracted or have another internal coup and it
| goes in the dustbin with all the other UI schemes they've
| rolled out and then abandoned over the past decade.
|
| I would put my money on WinForms being ported to Linux first...
| rvz wrote:
| So still not ready yet and is still not mature or production
| ready either.
|
| Until there is a mature library that is able to compete with
| Electron or Qt then I'm afraid that Rust is not a sensible choice
| for serious cross-platform GUI development at this time.
|
| Like I said before [0] With these libraries, All you get is a
| mixture of unmaintained or unstable bindings that may break when
| the GUI library that it is using changes its API.
|
| No thanks and no deal.
|
| To Downvoters: So you are telling me that you can confidently
| recommend to any engineering shop to develop a very complex GUI
| app with either of these unstable libraries faster in Rust than
| one who uses JS/TS with Electron?
|
| Even though I hate Electron, I can see why it is always chosen.
| Rust for GUI development? I don't think so, especially if you
| have a short time to release something complex and used by
| thousands into production.
|
| [0] https://news.ycombinator.com/item?id=24537300
| ElijahLynn wrote:
| I didn't downvote you but I can see why some may downvote you
| and it would just come down to "how" you said it, not
| necessarily the substance. It is all about delivery and that
| can be improved to be a bit more friendly. There are a lot of
| people working on this, it seems, and the tone that I felt from
| your comment was "pfttt, still not good enough". So that is why
| I _think_ you got down voted, but I don't know for sure.
| mathw wrote:
| The GTK bindings are being used pretty heavily by a few GNOME
| projects now, so I would expect them to continue to get the
| maintenance effort.
|
| It's a heck of a lot easier to bind to an existing GUI library
| than writing the equivalent of GTK from scratch. But all
| languages have this problem, and most of them don't have
| Microsoft's ability to generate multiple different and
| incompatible GUI toolkits to suit the fashion of them time.
| pjmlp wrote:
| Since they decided to kill Glade, it kind of lost the appeal
| to anyone that actually does UI/UX.
| kaba0 wrote:
| As others have already mentioned in the thread, they didn't
| kill it, it is just not compatible with GTK4 out of the
| window. But a similar program for that is being done.
| wiz21c wrote:
| yep. Harsh judgement but true judgement. Now there's rust-qt
| but I dunno how good it is.
| Popegaf wrote:
| It uses a lot of unsafe rust code. Here an example
| https://github.com/rust-
| qt/examples/blob/master/widgets/basi...
|
| I'm not sure what's the advantage of using unsafe code
| everywhere in Rust compared to just using C/C++. The syntax?
| nonbirithm wrote:
| Even for unsafe code Rust was designed to be more ergonomic
| than C (like pointer arithmetic operations). That said a
| safe wrapper would be preferred to unsafe everywhere.
| cdirkx wrote:
| Being part of a bigger Rust project? The GUI is just one
| component after all.
| Communitivity wrote:
| Tauri competes with Electron, and is a viable alternative.
| There are milestones they haven't hit yet (
| https://tauri.studio/en/?hn ), but many of the features needed
| are there already.
| MrBuddyCasino wrote:
| Downvotes on HN happen because something you said pisses of
| certain people, not just because something you said is wrong.
|
| That said, I think you're right, and I don't see what makes
| Rust particularly suitable for UI work. I'd just do the UI part
| in web tech.
| the_duke wrote:
| It's unfortunate, but I agree with you regarding native Rust
| libraries.
|
| There is a reason why we don't have options in this domain,
| apart from Qt, Gtk (with lot's of caveats) and more recently
| flutter.
|
| Building a cross platform native UI toolkit is an immense
| amount of work.
|
| It took Google a long time to turn Flutter into a decent option
| just for Android and iOS, and the newer desktop integrations
| are still very rough after years of work.
|
| All for Rust implementations are not at all viable for
| professional usage, and won't get there without major corporate
| backing.
|
| That said, the gtk bindings are in a good shape and very
| usable.
| Popegaf wrote:
| Are there startups that still write desktop GUI applications?
| Maybe I'm just not informed, but most just seem to be an
| instance of chrome (aka electron) written to directly call a
| website or reuse the web application locally.
|
| If I'm not wrong and something doesn't change, we'll find
| ourselves surrounded by electron apps on our desktops.
| brainless wrote:
| I just opened this today, what a nice coincidence to see it here.
| I want to create a cross-platform app to show some information on
| a Git repository. I do not have many UI widgets, it is just a
| visualization in a way. I also want to continue learning Rust. So
| I want to create this in Rust, but I am not sure if that means my
| project will take many many months. I thought of desktop web-app
| too, using Tauri (1), if this effort is too much.
|
| 1. https://github.com/tauri-apps/tauri
| wdb wrote:
| The cross platform frameworks are most of the time a disappoint
| for at least one part of your users as it does a bad job at
| mimicking typical OS interactions.
| kitsunesoba wrote:
| Or in some cases, they don't even try to mimic native widgets.
| By far the most common example I come across is text fields,
| which in most cross platform UI toolkits aren't even half as
| functional as their Cocoa/AppKit counterparts. It's incredibly
| frustrating for things like text navigation key shortcuts to
| work in the majority of your day to day apps, only to have the
| habits and muscle memory run into a brick wall when you need to
| use some cross platform app. Lowest common denominator UI is
| just... ugh.
| Hackbraten wrote:
| For completeness, there's also some work-in-progress that aims to
| provide safe AppKit and UIKit bindings:
| https://news.ycombinator.com/item?id=23035078
| Klonoar wrote:
| I actually have a PR open to add this to the site, but I have
| no clue who maintains the effort. :(
|
| Recently pushed out a 0.2.1, and did a mini write up here for
| anyone interested: https://rymc.io/blog/2021/cacao-rs-macos-
| ios-rust/
| Hackbraten wrote:
| Thank you for your hard work!
| Klonoar wrote:
| Heh, thanks. It's more of a passion project - I find that
| dealing with AppKit is sometimes a lost art, and I'd like
| to see a cross-platform GUI toolkit in Rust, so I figure
| this is the best way for me to contribute currently.
|
| I maintain that someone (or a team) needs to just take
| winsafe/cacao/gtk-rs, slap a declarative layer on top, and
| do the bare minimum set of controls with hooks for users to
| do custom things.
| Communitivity wrote:
| Edit: Ok, I was wrong. I thought Tauri was also being used as a
| platform for Rust development, not just Javascipt. Also, it's not
| buried..just not highlighted. First comment of the day did not
| get off to a good start.
|
| What surprised me was that Tauri was buried and not mentioned as
| a viable Electron replacement. I think we will eventually get to
| the point where native OS UI is a Web UI, with the OS UI running
| on a special virtual interface for security. I have seen Web-
| based UIs that are every bit as nuanced, complex, and well-
| designed as native UIs. Two bits are not quite there yet though.
| First, performance of Web UI has improved amazingly, but until we
| do have native support integrated into the OS it's going to be a
| step behind. Second, as already mentioned, accessibility must be
| accounted for.
| jagged-chisel wrote:
| Buried? It's right there on the page, alphabetized like
| everything else.
| anthk wrote:
| >performance of Web UI has improved amazingly
|
| You didn't live with the computers' UI from the 90's and 00's,
| right? It looks so.
| kaba0 wrote:
| It is ridiculously fast for what it does. There's another
| question that it does plenty of unnecessary computations for
| the end-goal and is probably not a good basis for.. well
| anything to be honest. It is not good at layouting, nor
| interactions.
| the_duke wrote:
| Tauri is written in Rust, but it's a Electron alternative, with
| user code written in Javascript. It deserves a curtious
| mention, but it's not really relevant to a Rust UI development.
|
| (Sure, you can write UIs via WASM now, but that's equally true
| for Electron)
| smoldesu wrote:
| I've written a few small, personal tools in GTK-rs[0], and it's
| GUI-enough for me. I love how quick it is to whip up apps, and
| how well it supports tools like Glade to build more complex apps.
|
| [0] gtk-rs.org/
| cloudhead wrote:
| For Rx[0] I built a custom GUI using opengl and Luminance[1]. I'm
| very happy with the results and would do it again if I had the
| chance. I'm a Linux user, and there is no acceptable GUI
| framework to may taste on Linux, so this was the only option
| that:
|
| * Has minimal dependencies
|
| * Looks and works the same on all platforms
|
| * Performs well and gives me the control I need
|
| [0]: https://rx.cloudhead.io/
|
| [1]: https://github.com/phaazon/luminance-rs
| jagged-chisel wrote:
| the luminance-examples links under 'Other crates' in your
| README.md give 404
| themaxdavitt wrote:
| Not affiliated with the project but I just created an issue
| for this: https://github.com/phaazon/luminance-rs/issues/527
| imvetri wrote:
| GUI is plattform independent. Code is plattform dependent.
|
| Have a single language to build UIs, target it to multi
| plattform.
| thomascgalvin wrote:
| > GUI is plattform independent.
|
| It really isn't, at least if you want to meet the expectations
| of the users of each platform you're targeting.
|
| It's easy to say "I want a button that says '[Click Me]'." It's
| less easy to say what the pixels representing that button look
| like in a platform-agnostic way. Are the corners rounded? What
| kind of bevel does it have? What sort of visual indication is
| there when you mouse over?
|
| And then there's stuff like layout. Does your form have the
| buttons ordered `[OK] [Cancel]` or `[Cancel] [OK]`? Because
| there are platforms that do both, and if you get it wrong, your
| user will mis-click because of muscle memory.
|
| And what do you do when one platform supports a widget natively
| that you don't? Or when the APIs for a "common" widget diverge
| wildly? Windows Explorer and MacOS Finder serve the same
| general purpose, but they aren't identical, either from the
| user's perspective, or from the API perspective.
|
| Java's Swing probably comes closer to "cross platform GUI" than
| any other package, but it's far, far from perfect, and it
| solves a lot of these problems by not trying to mimic the
| underlying OS. Yes, there are themes that get close, but
| generally, when you're using a Java desktop program, you _know_
| you 're using a Java desktop program.
|
| A lot of very smart people have tried to create "a single
| language to build UIs," and "target it to multi platform." It
| isn't as trivial as you make it seem.
| sam0x17 wrote:
| No linux tag _mumble mumble_
|
| Note: I know there is a GTK tag, but not everything is GTK
| ogoffart wrote:
| Shameless plug to the Rust GUI framework I'm working on: SixtyFPS
|
| https://sixtyfps.io
|
| https://github.com/sixtyfpsui/sixtyfps
| celeritascelery wrote:
| This looks really cool! I like the notion of 60fps, meaning
| "this framework won't give you a bloated GUI"
___________________________________________________________________
(page generated 2021-07-09 23:01 UTC)