Pre-implementation feedback for Qt with Rust

41

I don't agree with this argument, I just presented a list of features that would take you years to get on par with... But ok...

To answer the concerns(I'll give you a link at the end that should address almost all of your concerns):

  1. It comes by default with 3 themes but it is completely themable, you can make it look however you want. Initially they didn't come with any theme, it was later added, so people can have some good options if they don't want to implement the controls themselves.

  2. The controls are bare bones, you can implement them however you want them. Again, it was decided to offer some components to help people develop UIs but you don't have to use them.
    Also, they do support native look. http://doc-snapshots.qt.io/qt5-5.8/qtlabsplatform-index.html - these are thin-wrappers over native menu, menubar, standard dialog... If a native implementation is not available for a platform, it falls back to Qt Widgets. You can implement easily what you mention.

  3. Addressed in point 2

  4. This goes against the last statement that everything is to easy now... Porting code involves additional work. Also, people deprecate bad APIs to replace with better ones. QAction is Very Old, Qt 4 Old, many bad APIs have been deprecated in Qt 5, not only QAction.
    You can still use QAction though, it is just deprecated like QWidget(you don't want to use the CPU when all the UI nowadays uses the GPU and it is more efficient)...

  5. These are coming back

  6. Can't express myself on this one.

This blog post should address most of your concerns: Qt Quick Controls 2.1 and Beyond

42

I see nothing here QWidget Class | Qt Widgets 5.15.16 that indicates that QWidget is deprecated. Is this listed somewhere else?

43

My argument was that "glue together a QML UI and a Rust backend using a thin layer of C++ (possibly already written, like qml-rs)" is a viable enough solution that supporting native Qt UI from Rust is a more valuable first goal.

Would it be a reasonable assumption to conclude that your desktop OS of choice is Windows? It's the only OS I know where people consider "applications carry along their own UI themes" to be acceptable.

Both OSX and X11/Wayland desktop ecosystems (especially the latter) don't look too kindly on "special snowflake" applications distracting the user from the actual content that way. That's one of several reasons Java GUI applications using Swing got such a cold reception on Linux.

Hell. The older of us still remember "the bad old days" when it could take days to find Qt (3.x or earlier) and GTK+ (2.x or earlier) themes that matched.

I have work to get done. When someone says "Good news! You can play around reinventing old widgets the way you always thought they should be", I don't consider it an opportunity.

(I consider it evidence that the GUI toolkit is of insufficient quality to meet my needs. There's a reason toolkits like Tk, FLTK, Fox Toolkit, JavaFX, etc. have next to no market share on X11 desktops and most of that market share is git's use of Tk for the bundled GUIs.)

As much as I'd love Qt to mirror HTML+CSS+JS for ease of slapping together custom widgets, 99% of my desktop app needs are already covered by Qt's C++ API and I'd lose more time reinventing that than I'd gain by easing the remaining 1%.

(Plus, I don't want the stress of taking responsibility for re-creating all of the conditionals to match platform-specific quirks and user-specific config tweaks. It's bad enough that I'm going to have to go diving into GTK+ 2.x to figure out how to monkey-patch PyQt with XDG icon theme lookup outside of KDE or GNOME.)

One of us is misunderstanding and I'm not sure which. I don't see pushbuttons, text-entry fields, scrollbars, treeviews, etc in that list. Can I force it to delegate those to a CPU-drawn QWidget style like QGtkStyle or Plastique for consistency and, if so, how?

Yes. That's why I'm replacing GTK+'s equivalent to QShortcut with QAction when I port my utilities from GTK+ 2 to Qt 5.

It's an elegant, high-level API that lets me provide a unified definition for an action, then expose that single, shared definition in toolbars, menus, pushbuttons, and keyboard shortcuts and let the widget toolkit handle doing each one appropriately for the host platform.

Judging by the post you linked, their inclusion of Action in a "notable missing features" list and linking to QTBUG-50705 suggests that they agree with me there.

I was going to rebut your "QAction is deprecated" claim until I realized that you meant "The entire non-QML widget system is deprecated".

Thanks, but no thanks. I have no problem staying on deprecated platforms until "the new hotness" reinvents the functionality I actually value.

In that case, they fall under the same "Thanks, but I'll wait" answer I give in more detail later.

My point is that, since I'm already primarily using PyQt, the whole reason to want Qt in Rust is so I can get as much compile-time verification of my code as possible. QML callback code (especially as available without paying for the QML compiler) runs counter to that goal.

Even with 2.1, it's just applying QGnomePlatform-esque color schemes to the existing "carry along your own widget theme" system. That's not making it fit in and look native with something like GTK+ or classic Qt widget systems, where users can download and install completely arbitrary CPU-drawn themes.

I understand that, with the QWidget and GTK+ 2.x theming engines doing their drawing on the CPU, that will be a very difficult thing to do, but I'm fully willing to force CPU rendering across my entire desktop and stick to non-QML applications to achieve consistency while I wait for all of my applications to grow a means to GPU-render and then agree on a means for sharing and unifying themes the way QGtkStyle did for CPU rendering.

1 Like
44

It's more of a "We won't add any more features to it, it's in maintenance mode. Please use newer modules that were written to support new display servers, multiple graphics backends, GPU acceleration, multi-screen and HighDPI."
Not deprecated per se, but it is deprecated :slight_smile: (maintenance mode).
I knew that it was mentioned in a blog post, so I searched for it: Qt 5, C++ and Qt Widgets


@ssokolow There is a lot of misinformation and I don't want to touch every point and argue about the details, it seems that it will be just back-and-forth.
45

Trying to convince me that I've misjudged my priorities is indeed a fool's errand, but I'm always willing to have actual misconceptions corrected so I can make better decisions.

In fact, now you've got me a bit concerned. Please do point out the misinformation.

46

The only platform I use as a desktop is GNU/Linux and there is not a single application sharing a theme with one another on my desktop and there hasn't been for years. (Even Firefox and Thunderbird don't really look alike when you use the dev-edition of FF, but all of the other programs I use have their own styling, to be fair, I don't use a lot of GUI though)



Nevertheless, Rust is awesome, it just has hell of a lot of safety and is fast at the same time.

I want to see Rust used in more places, even if it's just for the sake of seeing less programs crash or running them faster.

QML is awesome for rapid development which isn't really what I usually want to do (I like having a stable and maintainable piece of software).
If someone made the whole QtGui stuff available from within Rust I'd be fascinated. I would be able to quickly draft the UI in QML and test things out and then rewrite it into Rust to have a fast and safe codebase.

1 Like
47

A single data point does not a trend make and I can provide some contrast. With the exception of git gui (Tk), FreeMind (Swing), Chromium (Aura), Firefox Developer Edition (XUL), Thunderbird (XUL), and Steam every non-game application I and two other family members (a programmer, an elderly artist, and a gamer going to university for French) installed defaulted to the same color scheme, widget theme, and icon theme:

  • Tk doesn't support sharing Gtk/Qt themes, but PySolFC included a clone of the GTK+ Clearlooks theme I was able to install for git gui.
  • FreeMind is a Swing app, which means it doesn't try to fit in, period. There is a GTK+ widget theme in recent Java versions, but the performance is so terrible that I've stuck with the default Metal theme. It doesn't even try to match the system icon theme and there's no way to change that. Luckily, I only really use it for reading existing FreeMind files, not creating new ones.
  • Chromium takes inspiration from the web pages it displays and doesn't even try to fit into the rest of the desktop but it does aim for a certain minimum level of "don't try too hard to stick out like a sore thumb" in its design.
  • Firefox Developer Edition is enamoured with following Chromium's lead and the "light-on-dark developer tools are the new thing" trend but can be switched to use the regular Firefox "follow the system color scheme" theme with a single click, it mostly follows the GTK+ widget theme (that's why in-page checkbox widgets never seem to be the right height to match a line of text), and the Ubuntu package maintainers patch it to obey the system icon theme where feasible.
  • Thunderbird inherits the pros and cons of Firefox's pre-Australis GUI integration. It follows the GTK+ widget theme and system icon theme. The Ubuntu maintainers seem to have given up on maintaining the patches to force it to follow the system icon theme.
  • The Steam client aims for consistency with the web pages it displays, rather than the OS it runs on. It also gets away with it somewhat more because it's surrounded by games which are proof that it's sometimes better to let an application have its own unique art aesthetic. (I own Lemmings for Windows 3.1 and various other early GUI ports... I bought the DOS version too, so I could have all-custom GUI widgets rather than Windows 3.1 widgets awkwardly mixed into the rest of the Lemmings UI art.)

Of those applications:

  • One is using a language (Java) and GUI toolkit (Swing) that were designed to look consistent across platforms rather than within platforms and never really caught on for Linux GUI development for a variety of technical and political reasons. (Awkward non-native look and feel aside, an example of the technical would be that Swing has had some infamously long-lived compatibility bugs including one where you had to hex-edit a library to change the name of an X extension so it would use a bugless fallback code path.)
  • One is using a niche toolkit (Tk) which essentially predates modern themed GUIs and the addition of its own, non-Qt/Gtk-integrated theming (TTk, short for Themed Tk) is a fairly recent addition.
  • Two are web browsers, heavily influenced by the "Consistency? What consistency?" of the web application world, and the third is derived from a web browser and under-developed these days.
  • One is specifically designed as a way to grant a specific website elevated privileges within the larger desktop, and aims to be consistent within itself.

As for titlebars and window borders, applications have to opt into client-side drawing under X11 and, under Wayland, while GNOME uses client-side drawing, KDE plans to force server-side drawing on applications for consistency. (Though KDE's Visual Design Group did propose a system called Dynamic Window Decorations which would combine the strengths of both approaches using appindicator-like abstraction for embedded widgets.)

48

You know that quite a lot of people are pro-Qt-bindings for Rust and you're (IIRC) the only one against so there's that.

So of your two listed Desktop Environments only one does actually do what you say the "ecosystem" wants which is already only 50%.

Talking about [quote="ssokolow, post:47, topic:7300"]
color scheme, widget theme, and icon theme
[/quote]
awesome or qtile which don't really do much in that direction, or enlightenment (which only has it's own dialogues written with EFL/elementary) which doesn't set any theme in any application either?

We're now down to 20%?

How about applications themselves? You don't want Qt because it doesn't blend in?
I'll give you a single standard application that virtually every GNU/Linux user knows: xterm

I'm totally fine with you saying that there are certain Desktop Environments (not even all DEs) and very few to none Window Managers that enforce their theme onto every application.
I'm not fine with you saying that it's the X11/Wayland ecosystem.

Also, don't you think it's important for an application to be rendered as intended by the one who designed it in the first place?


Now can you please stop flaming and be constructive instead? And saying what's wrong with Qt isn't constructive if the question is how to solve certain problems that an implementation would need to overcome.
49

You really misunderstood my points. I'll reply point-by-point.

When have I ever said I was anti-Qt bindings? I've been saying all along that a lack of bindings to the QWidget API are the main reason my desktop apps are written using Python and PyQt rather than Rust.

The closest viewpoint to being "anti-Qt bindings" that I've expressed is that bindings should focus on the QWidget API because the QML+QtQuick APIs (which aren't the same thing) already have qmlrs but, despite that, the needs QWidget APIs serve aren't being met.

I mentioned GNOME 3 because it (and things derived from it) are the only exception to the rule that X11 desktop environments use server-side decorations. KDE, Xfce, LXDE, LXQt, and every standalone window manager all use server-side decorations.

For Wayland, the general consensus is "Trust us. We'll figure out a way to ensure client-side decorations are consistent and reliable across all applications" but KDE wasn't convinced, so, to ensure that consistency, they're implementing server-side window decorations under Wayland. Because LXQt (the successor to LXDE) will use KWin, LXQt will also get server-side decorations.

(Bear in mind that, aside from being one of the big desktop environments with a significant slice of the Linux desktop user base, KDE is the oldest of the desktop environments still in use. GNOME was implemented as a "We'll make our own desktop environment, with beer and hookers" response to Qt not having a favorable license in the beginning... and it shows. Under the hood, GNOME and GTK+ have always been a sloppy, creaky knock off of the functionality KDE and Qt offered. For example, GnomeVFS took forever to catch up to KIOSlaves's stability and, GTK+ MVC architecture is more primitive than Qt's. I say this as someone who's used and done a fair bit of programming for both.)

...and nobody is shipping Wayland as a production-ready option yet (Fedora 25 will be the first), so I'd argue that X11 users are the more important demographic to judge norms by.

Also, KDE and LXQt, the two Qt-based desktop environments, use QWidget for their desktop applications, not QML. (That's a matter of policy that you'll see on the KDE Community Wiki where they say that QML is for Plasma and KDE Mobile widgets and QWidget it for desktop apps.)

AwesomeWM and QTile are window managers, not desktop environments. As they do not provide widget toolkits, their only theming concern is titlebars and window borders, if applicable... and, if you set AwesomeWM to display window borders (I have used Awesome and written an rc.lua for it), it will still enforce that they're consistent across all applications you apply them to.

As for Enlightenment, I've yet to see any evidence that it's got any significant market share outside of non-desktop UIs like Tizen IVI.

First, every desktop I've used has been patched to indirect things which reference it through x-terminal-emulator on Debian-family distros, which means that none of my family has seen XTerm, receiving, instead, whatever terminal emulator the desktop provides.

That aside, how many non-Debian/Ubuntu/Mint/etc. users even remember that XTerm even has widgets aside from the obvious "terminal widget in a WM-provided frame"? Sure, the font doesn't follow the Qt or GTK theme's font settings, but a terminal with an odd font doesn't look that out of place on the rare occasions it shows up.

I think that, if the one who designed it is that tied to such a specific rendering, they should develop for something like the Nintendo 3DS where they can control the hardware... or at the very least, they should stop trying to hide their leanings and piss off their users with honesty by overriding things like custom fonts for the visually impaired.

There's a reason that, even when not presenting to a client, we UI/UX designers develop our wireframes with sketch-like widgets that distance us from the themed end result. It's so the data and workflow take front and center stage, rather than letting minor stylistic choices distract from that.

Projection much?

The flaws in a library or API are always relevant when you're deciding what to build your application against. QWidget and QML have different strengths and weaknesses. (You wouldn't start a new mobile app using QWidget and you wouldn't try to build a new desktop application for inclusion into KDE using QML.)

It doesn't matter how elegantly you solve problem X if the people who were clamoring for a solution ignore what you wrote because they were asking for a solution to problem Y.

As I said, we already have qmlrs for QML-based UIs and I have yet to hear of any reasons it's so deeply flawed that an effort to build a whole new binding should prioritize QML rather than QWidget, which currently has no usable binding.

50

KDE allows you to run both, server-side and client-side(actually KWayland supports server-side, client-side and no decorations but I talk about KWin here), although it prefers server-side.

@benaryorg I do not recommend you doing this, I don't think there is intent for constructive discussion.

51

Huh. Learn something new every day.

Thanks. :slight_smile:

52

Okay that's definitely true.

And for the rest of the response, you have some good points there.

And I definitely support that statement:

53

Hi everyone, I wanted to ask about the status.

Is anyone working right now on a Qt binding?

54

Yes, I'm working on it right now at https://github.com/rust-qt. The last update added initial signals and slots support. All the most essential parts are already in place, and you already can (kind of) write a working Qt app in Rust. I'm currently fixing some inconvenient things, and once it's done I'll make a post at this forum for public review of API and implementation.

9 Likes
55

@Riateche, are there any possibilities in your library to either mimic a subclassing or attaching custom widget event listeners? Unfortunately this is the blocker for me at the moment.

56

This is something I have solved for my wrapper (which is in very early stages and not for usage yet) the way I solve it is to auto-generate a implementation of a widget type like this (this is the C++ side)

https://github.com/emoon/ui_gen/blob/master/test_bed/src/qt/wrui_qt.cpp#L51-L71

Later on the Rust/FFI side can set a callback on the m_paint and m_paint_user_data So this adds some slight overhead to each class but only a branch check when an event happens so in practice this should be fine. This also allow you to set an event override on a widget without doing subclassing.

So this is an idea that might be useful for (the much more complete) Qt wrapper that @Riateche has done.

57

Frankly I'd be happy even with this approach. An "artificial" QObject wrapper, that allows navigating its eventFilter call to the Rust lambda or fn, and so be then fed to installEventFilter. AFAIK this can cover the majority of the standard event callback cases.

58

That could work but I guess it depends on how ergonomic you want it.

The problem is that you need to construct the Rust/FFI data depending on the event. For example is it a PaintEvent or DropEvent, etc you need to be able to deal with that on the Rust side. I guess if you go fully unsafe and only deal with the FFI types directly that is fine. In my case I always want to the user to have use a Rust interface.

Here are two examples: (related to drag'n'drop of files)

    fn drag_enter(&mut self, event: &DragEnterEvent) {
        println!("Dropping files!");
        event.accept();
    }

    fn drop_files(&mut self, event: &DropEvent) {
        println!("Has some files? {}", event.mime_data().has_urls());
    }

    ...

And setup currently looks like this (self.list is a ListWidget this case)

set_drag_enter_event!(self.list, self, MyApp, MyApp::drag_enter);
set_drop_event!(self.list, self, MyApp, MyApp::drop_files);

But this is of course more complicated to implement in the wrapper

59

Unsafe is fine too - need this for my internal usage, not reexport.
Are these examples from https://github.com/emoon/ui_gen ?

60

Yes the example is here https://github.com/emoon/ui_gen/blob/master/test_bed/src/widgets/src/main.rs (under development and this is my testbed for trying out things) I haven't added anything as readme or anything as it's still quite experimental and my plan is to just expose things that I need and not try to convert everything.