[HN Gopher] CXX-Qt: Safe Rust bindings for Qt
___________________________________________________________________
CXX-Qt: Safe Rust bindings for Qt
Author : jcelerier
Score : 147 points
Date : 2022-03-02 10:18 UTC (12 hours ago)
(HTM) web link (www.kdab.com)
(TXT) w3m dump (www.kdab.com)
| csnover wrote:
| It is great to see how many people want to bring Qt support to
| Rust and are trying to do so, and I hope that these folks
| succeed, but it's wearisome to me how each person/group creates a
| _new_ project instead of working with others who are already in
| this problem space. Of the half-dozen or so[0] existing attempts
| so far to create Qt bindings to Rust, none of them have actually
| succeeded, either because they tried to start from scratch
| _again_ and then abandoned the attempt midway, or because they
| are limited to QML. Ritual[1] is the only crate I've seen that
| attempts to actually expose the whole Qt API, but it's pretty
| awful to use, incomplete, and dead.
|
| Rust doesn't need _more_ Qt crates. It needs _one_ Qt crate that
| is complete and works well. (Or, ideally, a native Rust cross-
| platform GUI crate that works as well as Qt, but that's an even
| longer and harder task.)
|
| [0] https://lib.rs/keywords/qt
|
| [1] https://github.com/rust-qt/ritual
| brnt wrote:
| Quite frankly, I'd love to have some idiomatic C++14/17/20
| bindings for Qt.
|
| The official Qt for Python binding fits in very well with the
| language and style I think, but when using it in C++, I have to
| mix wildly different styles and me no likely.
| pjmlp wrote:
| I think they accept pull requests.
| isomel wrote:
| Qt is already idiomatic C++17. Isn't it?
| brnt wrote:
| You're joking right?
| mockery wrote:
| It's totally reasonable to lament duplicated effort, but it's
| worth pointing out that this particular attempt is from a
| company[0] whose business is Qt consulting - so it's easy to
| imagine that they might succeed (due to expertise, size, and
| motivation) where others have not.
|
| The post also explains why they started from scratch vs.
| existing approaches - I'm not qualified to evaluate the claims,
| but I think they deserve some credit for explicitly talking
| through their reasons.
|
| [0] https://www.kdab.com/
| ogoffart wrote:
| The thing is that Qt is a C++ toolkit written in C++ and meant
| to be used from C++ with its C++ API.
|
| Especially if we want to use QtWidgets, the API surface is
| _huge_. There are a bunch of bindings with different language,
| but even the ones that are officially supported like PySide
| will still be second class citizen and awkward to use.
|
| Automated binding generation will never give you idiomatic API
| in whatever language. And if you want an idiomatic library that
| wraps Qt, it's going to take a huge amount of work.
|
| Which is why I think restricting to QML makes sense because
| that's a much smaller API surface. That was the ambition behind
| my previous crate that exposes QML to rust:
| https://github.com/woboq/qmetaobject-rs/
|
| But now I've moved on to another GUI project: Slint
| https://github.com/slint-ui/slint It is implemented in Rust,
| but from the start aim to expose its API to several programming
| languages so bindings can be made idiomatic in almost every
| programming languages.
| longstation wrote:
| In case anyone is interested, Slint used to be called
| SixtyFPS. It's created by a few ex-QT employees.
| gbin wrote:
| Small tip: put a working example when you advertise such an API
| with a screenshot as a bonus. As a developer I want to see if the
| bindings feel natural and maybe try it right away. Here both the
| article and the GitHub readme lack this.
| melony wrote:
| And screenshots!
| marcosdumay wrote:
| Although I agree that screenshots will attract some people,
| it's Qt. The look and feel won't be any different from any
| other Qt application (or better, it will be completely
| dependent on theming, so the pictures won't even reflect what
| you get.)
| Kelteseth wrote:
| There is an example folder https://github.com/KDAB/cxx-
| qt/tree/main/examples
| detaro wrote:
| And the start of the "book" also explains an example:
| https://kdab.github.io/cxx-qt/book/getting-started/2-our-
| fir... Fully agreed that should be more obvious though.
| simlevesque wrote:
| The first comment says specifically "screenshot" but the
| links you and the person you replied to mentionned both
| have no screenshot.
|
| We want screenshots. Images of the end product GUI.
| detaro wrote:
| It' says "a working example" - which we referenced. With
| "a screenshot as a bonus". And a screenshot is pretty
| pointless for a binding library, since it doesn't impact
| what the GUI looks like, so it's not surprising a simple
| example to show the code doesn't have one.
|
| EDIT: i.e. after looking at the QML, from quick glance
| it'll render two lines of text and two buttons in QML
| default styling. What do you gain from that?
| hda111 wrote:
| Can this dynamically link to Qt to circumvent the GPL?
| orra wrote:
| Dynamic linking doesn't circumvent copyright law, so it doesn't
| circumvent copyleft.
| Macha wrote:
| To some extent the intent of the author matters, and in their
| "Just buy a license" pitch[1], the Qt company implicitly
| threatens lawsuits for GPL violations _if_ you use the open
| source version and fail to provide an adequate means to
| switch out the linked binaries. So the people who could
| enforce a copyright claim are drawing that distinction, which
| means it does matter here. In addition, they mix licenses
| between GPL and LGPL, so failing to take proper care means
| you could be relying on a GPL module and think you're ok by
| complying with the LGPL.
|
| [1]: https://www.qt.io/licensing/open-source-lgpl-obligations
| isomel wrote:
| It's like asking "do you accept bitcoin to circumvent tax
| law"
|
| First of all, bitcoin does not circonvent tax law. (And
| linking does not circonvent GPL)
| orra wrote:
| You can meet a major LGPL requirement by dynamically
| linking your dependencies _or_ by providing object files
| that the user can statically relink. Neither is
| circumventing the LGPL, however.
|
| I take your point the Qt company wants (L)GPL licensing to
| sound scary, so they can sell licenses.
| oever wrote:
| Qt is LGPL 3.0. Dynamically linking from close source is
| allowed.
| Macha wrote:
| Some of QT is LGPL, other parts are GPL.
|
| The question about dynamic linking is valid, since Rust's
| build system, Cargo, produces a static binary by default.
| ogoffart wrote:
| Cargo links all the rust code together in a static binary,
| but the C/C++ libraries can be linked dynamically, and in
| the case of something like Qt, most certainly are.
|
| Since most important part of Qt are LGPL, you can use this
| crate and other Qt binding crates to develop proprietary
| applications.
|
| (Only if you wish to use one of the few parts that are
| "only" GPL, then you need to release the final product and
| all its parts under the GPL, or acquire a Qt license)
| dotancohen wrote:
| Interesting to see the dual MIT-Apache license approach. I'm less
| familiar with Apache, but what does it offer that MIT doesn't? Is
| it just to allow downstream projects and forks to choose which of
| the two licenses they prefer? If so then the GPL is curiously
| missing.
| detaro wrote:
| Apache license has some language around patent grants that some
| people want and other people don't like (e.g. apache isn't
| compatible with GPLv2, some of the BSDs reject it, ... and some
| people just think its too complicated). Thus offering both
| makes both sides happy is my guess.
| Rochus wrote:
| Whatever license the binding has, open-source Qt is only
| available under LGPL or GPL.
| epage wrote:
| Rust uses it and so has become a default license for Rust
| crates. See https://rust-lang.github.io/api-
| guidelines/necessities.html#...
| dotancohen wrote:
| I see, interesting. Thank you for bringing this to my
| attention.
| the__alchemist wrote:
| This sounds awesome! Rust seems like it should be a good fit for
| native applications (Nice language+tools, and fast), but its lack
| of robust GUI tools limits this. This should help, if it works
| well.
| zozbot234 wrote:
| An idiomatic binding to wxWidgets would be a great alternative
| to Electron-like solutions for multi-platform GUI. AIUI,
| there's already a wxC project (i.e. a pure C foreign interface
| for wx, needed to support other bindings) and a Rust binding
| could be built on that.
| nu11ptr wrote:
| Is wxC maintained? I didn't think it was. I always thought a
| more interesting approach would be like the one wxPython
| uses. They effectively walk the object tree generated by
| Doxygen docs and do code generation from it. Not sure how
| viable it would be to do this with Cxx directly or if it
| would be better to generate a C based API from it AND a Rust
| wrapper. The latter has the advantage that multiple languages
| could write bindings against this C based API (like wxC), but
| since generated, less maintenance.
| smasher164 wrote:
| I don't think wxC is supported anymore. Its SourceForge (lol)
| page lists 2013-04-15 as the last time it was updated. I
| believe with all the nice tooling that's popped up in the C++
| space over the last decade (e.g. libclang, cxx) could allow
| bindings to be created more easily/sustainably. Someone has
| to do it though :)
| isomel wrote:
| There are already plenty of GUI solutions for rust. All with a
| diverse level of polishing and convenience.
| wongarsu wrote:
| There are plenty of GUI solutions that are robust enough for
| an embedded GUI or some WebAssembly stuff. For native
| (desktop) applications the rust ecosystem still has a long
| way to go.
| the__alchemist wrote:
| Yea - `embedded-graphics` is nice for embedded primatives
| and text.
| nu11ptr wrote:
| AFAIK, the only complete desktop GUI option for Rust that is
| viable for large, professional apps is gtk-rs. There are many
| promising up and coming GUIs for hobby projects, but none
| I've seen are robust enough (yet) to support all needed
| widgets of a pro app.
| Macha wrote:
| Accessibility support is the big killer for many of them,
| though even GTK has issues with that on Mac OS, so Qt would
| be a big win.
|
| Or I guess you could put a Rust wasm app into electron also
| and have accessibility support that way. Has to be one that
| uses a real DOM and not just renders to a canvas or WebGL
| though.
| ogoffart wrote:
| I think you can go quite far with Qt/QML and the
| qmetaobject crate. For example
| https://github.com/gyroflow/gyroflow
| nu11ptr wrote:
| Ahh...very cool, thx. Didn't realize it was that capable
| and was not aware of this "demo". I will check it out as
| I need to write a GUI soon (and would prefer to use
| Rust).
| rapsey wrote:
| A diverse level of incompleteness you mean. Nothing
| comparable to Qt exists.
| isomel wrote:
| Exactly. But there are already bindings to Qt in different
| states. Let's see if this one bring anything.
| jokethrowaway wrote:
| Great to see official support, albeit I never understood the move
| to QML and the existing Qt bindings are enough. I don't really
| need anything more than QWidgets.
| oever wrote:
| Like the more mature <https://invent.kde.org/sdk/rust-qt-binding-
| generator> this project avoids binding existing C++ code, but
| makes rust code available to C++/QML projects.
| sho_hn wrote:
| Being familiar with your project I'm curious how this new one
| differentiates itself (other than being built on cxx).
| oever wrote:
| RQBG is not changing a lot any more because for me it works
| fine and some people are using it. There's currently one
| patch in the works, but other than that it's stable.
| Initially, I blogged quite a bit and put effort into good
| demo applications. But no feature requests or patches were
| forthcoming. Which is fine by me. The project was meant to be
| simple and stay simple.
|
| This project takes the same approach. It is aimed to put Rust
| at the core (business logic) of the application and code the
| UI in C++ or QML. This way you sidestep the enormous work of
| writing bindings for the Qt libraries.
|
| Here's a talk on the idea. <https://archive.fosdem.org/2018/s
| chedule/event/rust_qt_bindi...>
|
| KDAB hires some of the best Qt coders, so this effort by them
| might get more traction. Using macros and annotations like
| Oliviers project is nice. When RQBG started procedural macros
| were not attractive yet.
|
| This new project is on Microsoft GitHub which means I won't
| be contributing. I prefer to work on projects that are self-
| hosted by communities like KDE, GNOME, Debian instead of
| being locked on a closed platform of a competitor.
| mamcx wrote:
| ncmncm wrote:
| This looks like what we usually call a "heavyweight mapping",
| distinguished from the usually preferred "lightweight mapping".
|
| There are sound reasons to prefer the latter. When it is
| lightweight enough, the mapping is intuitive and obvious, so the
| original documentation mostly suffices, modulo some release
| notes. If something doesn't work right, is is very likely your
| code, not the mapping, at fault. Anything omitted from the
| mapping is easy to add, compatibly.
|
| The promise of a heavyweight mapping is always that you won't
| need to understand the thing mapped, that the mapping itself will
| (1) be fully documented, and (2) work. Neither is ever wholly
| true. As a result, you need to understand both libraries, and
| also the (lightweight) mapping between them, and work around all
| the bugs and infelicities in all three -- mostly without help,
| because nobody else understands all that any better than you do.
| When something doesn't work, you have to determine if it is your
| code, the mapping library, or the thing mapped that is at fault.
|
| Lightweight mappings are always ugly. You end up with your own,
| custom, heavier mapping, but just to the parts you are actually
| using, and that you actually understand. It is tempting to fill
| that out and publish it, which is the actual origin of all the
| mappings you find published. Resist.
| pizza234 wrote:
| Interesting. Based on my understanding, it seems that they solve
| the biggest hurdle in cleanly implementing Qt bindings - the lack
| of inheritance - by using macros.
|
| On a small project of mine, macros were also my choice for
| working around lack of inheritance; I wonder how this scale on
| large(r) projects, including this one.
| gefhfffh wrote:
| The Rust Windows API provides a cast method to jump through the
| inheritance hierarchy.
|
| Previously, additionally, all base class methods were generated
| for derived classes (structs). This was removed due to high
| compile times
|
| https://github.com/microsoft/windows-rs
| bagavi wrote:
| Do you plan to support rust integration with pyqt?
| fullstop wrote:
| I've had fantastic luck using pyqt5 in the past, but it kind of
| bothers me that both pyqt and pyside both exist. They look
| nearly identical, and I never know if I'm using something which
| will eventually be dead.
| nicoco wrote:
| Fancy lasagna? Try qtpy!
|
| https://github.com/spyder-ide/qtpy
| brnt wrote:
| Pyside2, or Qt for Python, is now a Qt project, and can be
| expected to stick around for a long time.
| lordofgibbons wrote:
| Sorry if off-topic but I've seen many attempts at Qt bindings
| from Go and Rust. It seems all GUI libraries are more than 15
| years old - except flutter, which is currently alpha quality on
| desktop.
|
| As someone who has never implemented a native GUI library, what
| makes them so difficult to implement that we see so almost no
| language-native ones? Is it a matter of it not being monetizable,
| or something else?
| ahartmetz wrote:
| There is a lot of stuff there. When I think of Qt, and omitting
| things like QString and QIODevice / QNetwork: Text rendering,
| list / grid / tree views, painting primitives and not-so-
| primitives (e.g. dashed lines), input including multitouch,
| custom styling, accessibility, many miscellaneous widgets,
| timers and events, integration with native environment,
| printing - and a ton of customization points for everything.
| wuschelhase wrote:
| It is an enormous effort (read investment) to get to a point of
| detail, where such a library becomes usable to a wide audience.
|
| Consider a simple text input: In some languages (e.g. 'syllable
| based' korean Hangul) you have to compose multiple keystrokes
| to get to a complex letter. While you type, the last and as
| well as the second-to-last complex-characters might still
| 'trade' consonants and vowels among each other.
|
| Now layer in more Dimensions, such as validating that input or
| line-wrapping, elision and many more.
|
| To my mind, only few libraries got to this level of detail
| without breaking apart on complexity. It requires high
| maintainer stamina or massive investments.
| sho_hn wrote:
| Most of your input example is nowadays typically handled by
| code outside the GUI toolkits themselves (such as the IME,
| the text shaping and the font stack), although the general
| "the GUI devil is in the details" thrust is right.
| [deleted]
| api wrote:
| A high quality desktop GUI library is close to a game engine in
| terms of difficulty. You have to support a vast array of
| languages, accessibility, input paradigms, flexible layout,
| different screen resolutions and DPIs, styling, and so on. It's
| a massive undertaking.
| badsectoracula wrote:
| Considering that some game engines tend to have their own GUI
| toolkits (e.g. UE4's Slate for example), you can say that it
| is more difficult to make a game engine than a GUI toolkit
| :-P.
| api wrote:
| Game engine toolkits usually don't have to support
| accessibility, right-to-left languages, full Unicode, and
| many other things that mature application UIs need.
| sho_hn wrote:
| I'd say making a comprehensive 2D GUI toolkit is actually
| more complex and difficult than making a 3D game engine -
| even one that includes a rudimentary 2D GUI toolkit.
| There's an enormous long tail to 2D.
|
| My current work is exactly at the place where those tech
| universes overlap and integrate.
| mwcampbell wrote:
| Is the long tail you're talking about more in 2D
| rendering itself, or in accommodating the great diversity
| of the humans using the UI, e.g. accessibility and
| internationalization?
| sho_hn wrote:
| Rendering does have a lot of interesting 2D-specific
| problems too that 3D engines don't optimize for (Raph
| Levien's blog has great stuff on this), but what the 3D
| engines lack is often more related to UI layout, input
| (e.g. sophisticated focus handling), advanced text
| (editing, layout, shaping).
|
| Unity's probably been investing the most into a more
| complete 2D toolkit (which is their third or fourth
| generation of 2D UI toolkit bundled with the engine)
| lately. Among the FOSS game engine projects Bevy has made
| strong 2D suitable for UI an explicit goal. But that one
| true converged contender is still not even on the horizon
| yet, IMHO.
| jonathanstrange wrote:
| The hardest is to make multiline text input and rich text
| support. None of the smaller, home-brown GUIs gets this right.
| You basically have to write a complete editor that supports all
| languages, including Japanese, Chinese, Arabic, etc. Even
| native operating system text input widgets have been plagued
| with problems. Generally, there are tons of edge cases and
| special input considerations to consider in a GUI, e.g. DPI
| scaling, accessibility, right-to-left languages and unusual
| unicode glyph handling (composed glyphs), scrolling behavior &
| mouse handling, platform-dependent layout issues (HI
| guidelines), escape characters in file paths and unusual file
| systems, and so on and so forth.
|
| It's quite possible to make a good GUI, just lots of mundane
| small issues to deal with, and it's overall a massive
| undertaking. It requires at least an extremely good knowledge
| of how different languages deal with text and input it.
| sharikous wrote:
| Can't you just link HarfBuzz for that?
| jcelerier wrote:
| Harfbuzz partly comes from Qt's codebase IIRC
| mwcampbell wrote:
| harfbuzz is for text rendering, not editing. Of course, the
| former is a prerequisite for the latter, but text editing
| has plenty of its own complexity.
| beowulfey wrote:
| Rust has a number of burgeoning GUI libraries. Some of them are
| further developed than others. I think the difficulty is just
| the complexity of the work. It takes a lot of effort to make a
| complete, functional library, and many of these are largely the
| work of one to a few people (probably in their spare time)!
|
| https://www.areweguiyet.com/
|
| The secret, I suspect, is probably "money".
| badsectoracula wrote:
| Beyond the "this is too hard" responses (which from personal
| experience working on GUIs and toolkits for decades i think are
| overblown), it is also that a GUI toolkit -or any other library
| really- written in a niche language will only be usable for
| that niche language's audience but a GUI toolkit -or any other
| library- written in a language that can be used by other
| languages with almost zero friction, is way more likely to be
| used.
|
| And people tend to use what they see other people using, thus
| repeating the cycle.
|
| So you see these 15 year old libraries being used because other
| people are using these 15 year old libraries because they are
| written in languages that can be (relatively) easily be wrapped
| (both C and C++ wrapping can be done automatically and there
| are many tools for that - largely because this is something a
| ton of people want to do, so again, it feeds back to the cycle
| of things being popular because they are popular).
|
| But there are lots of new toolkits being made, you can even
| find a submission for a new one in Hacker News almost every
| month (though the responses are pretty much the same in all of
| them :-P).
| nu11ptr wrote:
| Assuming you are talking about Qt/wxWidgets, and I don't
| think they are easy to create bindings for due to being
| written in C++. I think they have been used because they
| represent the largest, most complete crossplatform codebases
| representing the traditional desktop GUI using either native
| widgets, or in Qt's case "simulated" native looking widgets.
|
| In contrast, GTK is written in C AFAIK, and anytime a new
| language springs up the very first thing you generally see is
| a GTK wrapper. I have always suspected this is because C is
| far easier to wrap since most languages have a well defined C
| FFI, but typically lack a C++ one (due to lack of std ABI)
| thus Qt/wxWidgets bindings typically lag GTK.
| Macha wrote:
| C is also a relatively simple procedural language which
| constrains the APIs that e.g. GTK can offer. This makes
| working with GTK in its native platform uglier than Qt, but
| does mean alternative bindings can build their own more
| ergonomic abstractions on top of it.
|
| Qt on the other hand is very much a C++ OOP style, so if
| there's an impedance mismatch representing that in your
| language, as is the case for Rust, C or Go, then it gets
| much harder to do. The C++ bindings do present difficulty
| of course, but you can see from e.g. PyQT that if the
| pattern works in your language it's one that can be
| overcome.
| nu11ptr wrote:
| This a good point, and I agree that C++ made sense at the
| time as it is much richer for creating a GUI. I've never
| tried to use GTK C GObject interface, but I've seen some
| snippets and it looked nasty to me. However, in
| hindsight, it at least makes it fairly easy to create
| bindings for and I suspect many (most?) don't use the GTK
| C API but some other language bindings, so it turned out
| to make a lot of sense I think.
| tialaramex wrote:
| And there are other choices Qt makes that are unfriendly
| for, say, Rust too, QString is defined in terms of UTF-16
| code units, which was probably a pragmatic choice when Qt
| was younger, but inconvenient today since of course Rust
| can't necessarily be confident this is actually Unicode
| (I tried but was unsuccessful in figuring out what CXX-Qt
| does about that) and on non-Windows systems Rust doesn't
| have a built-in representation for this "a bunch of
| UTF-16 code units" pseudo string, yet on Windows you
| probably do want that structure because it is what other
| Windows stuff expects such as the File APIs...
| Macha wrote:
| Although Windows has gone backwards on that a little with
| the current recommendation being to use the *A APIs with
| a UTF-8 code page: https://docs.microsoft.com/en-
| us/windows/apps/design/globali...
| badsectoracula wrote:
| There are tools to create bindings for C and C++, like SWIG
| you can see some examples in [0], e.g. the wxWidgets
| bindings for Python. AFAIK for Gtk bindings can be
| generated using gobject introspection handling most (if not
| all) of the mundane bits.
|
| [0] http://www.swig.org/projects.html
| nu11ptr wrote:
| I'm aware and have used SWIG. It is amazing, but a) it
| doesn't support all languages b) it still takes a lot of
| work to create C++ bindings. This is primarily due to the
| complexity of C++ APIs vs. relative simplicity of a
| C-based API as another poster commented, not any
| shortcoming of SWIG.
|
| So yes, there are tools, my point is it is still much
| easier to wrap a C based API because you can often just
| use your language FFI, not an external toolset.
| mwcampbell wrote:
| > from personal experience working on GUIs and toolkits for
| decades i think are overblown)
|
| Accessibility and internationalization _are_ really hard
| though, right?
|
| I'm finally doing something about the accessibility issue:
| https://github.com/AccessKit/accesskit Still have a long way
| to go though.
| badsectoracula wrote:
| They can be among the harder parts of a toolkit (though it
| also depends on the toolkit's scope - can't really compare
| something like Qt that has a very large scope going even
| outside GUIs with something like imgui, which only provides
| the most barebones GUI functionality) yes, but i think the
| "hardness" exists not in how hard they are to have that
| functionality but in most people not even thinking about
| these things.
| jacobr1 wrote:
| Also note that Qt, while having a legacy of its prior
| versions, has seen significant investments keep it up to
| date. You aren't using an "old" library, you are using a
| modern library in its latest incarnation.
| jcelerier wrote:
| Qt5's qtbase module is over 2 million LOC, and doesn't even
| cover QML, QtQuick, etc.
|
| Just having proper abstractions over each platform[1]'s:
|
| - windowing
|
| - KB/mouse/tablet/touch input
|
| - raster painting
|
| - 3D APIs (Vk, D3D, GL, Metal...)
|
| - text layout and rendering
|
| - support for accessibility APIs
|
| + things such as generic data models for tables and trees,
| etc... is already an immense amount of work, and you haven't
| even started drawing a single button yet.
|
| * https://github.com/qt/qtbase/tree/dev/src/plugins/platforms
| MaxBarraclough wrote:
| A few more for the list:
|
| * Internationalisation
|
| * Concurrency, parallelism, and perhaps async (probably less
| of an issue with modern C++, but Qt still has plenty on offer
| here [0])
|
| * Integration with various platform-specific build tools and
| IDEs
|
| [0] https://doc.qt.io/qt-5/threads-technologies.html
| badsectoracula wrote:
| You do not need to replicate all features of Qt to make a GUI
| toolkit, especially since Qt tends to have a ton of stuff
| outside GUIs _and_ actually has two "widgets" approaches
| (classic widgets and QML). For example the 3D API stuff are
| pointless beyond context creation, unless you use only that
| 3D API (instead of underlying window system functionality) to
| put stuff on screen.
|
| Qt also recreates a ton of features found in C++ and if we're
| considering a new language, chances are the language itself
| has features that make Qt's unnecessary.
| jcelerier wrote:
| Which features are you talking about ? Even in c++23 there
| isn't yet a way to replicate moc, rcc, uic with the same
| ergonomy for the end user and the same efficiency.
| badsectoracula wrote:
| I mean things like containers though in the context of a
| new language chances are the language itself may provide
| functionality that makes moc unnecessary.
|
| Also you certainly do not need something like moc to make
| a GUI library, which comes back to what i originally
| wrote in that you do not need to replicate Qt to have a
| GUI library.
| ogoffart wrote:
| "containers" was not in the list.
|
| There sure is some overlap with what Qt offers that most
| language offers (Containers, Networking, Database,
| threading, ...). But purely in the context of making a UI
| library, there is still a huge amount of things that Qt
| offers that needs to be replicated.
| badsectoracula wrote:
| The post i replied to was about how big Qt is, which
| includes containers, etc. That the specific examples
| given did not contain "containers" isn't relevant since
| they are part of the "2 million LOC" mentioned.
|
| Yes, you need to implement similar functionality, like
| abstracting the window system, input handling, text, etc
| but you do not need to replicate what Qt does to have a
| GUI toolkit.
|
| Qt is very complex and Qt is (among others) a GUI library
| but Qt being complex doesn't mean that GUI libraries have
| to be complex.
| rob74 wrote:
| ...but, as others have noted, even if you want to only
| support the "core" features that most people would take
| for granted for a GUI (cross-platform, all the "usual"
| widgets including complicated ones such as RichEdit,
| ListView, TreeView, text with Unicode support and
| subpixel rendering etc. etc.) it's already a massive
| undertaking.
| badsectoracula wrote:
| That is another issue, yes, it is not trivial (though it
| isn't like making a browser or even a game engine -
| especially since game engines nowadays tend to have their
| own GUI toolkits :-P) but my point was that you do not
| need to replicate what Qt does to have a useful and
| usable library.
| jerf wrote:
| Correct. You don't have to replicate anywhere _near_ what
| Qt has to make a useful toolkit.
|
| However, here is your experience with almost every other
| toolkit: Download it, compile it, build a couple test
| screens with it, maybe even build a couple of your
| production screens with it, then the inevitable disaster:
| You have some requirement, and you need a calendar that can
| highlight certain dates, or that gives you mouseevents on
| each individual date, or allows Jewish as well as Gregorian
| calendars, or that allows you to add things between the
| month name and the month days other than what the widget
| already puts there, or that... etc., for any of dozens of
| specialized requirements. And then you bounce off the
| toolkit and tell people in online discussions that you
| really enjoyed working with it, it was nice that it was so
| simple, and it has a lot of promise and you hope the
| developers keep working on it, but it wasn't suitable for
| your needs and Qt had exactly the widget you needed or at
| least the widget you needed had the plugin points you
| needed to do your job.
|
| (In the meantime, the project stalls and dies because
| nobody else is using it either, but all for _different_
| reasons.)
|
| And you hadn't even gotten a tenth of your dialogs started.
|
| Another common one is, as people say, trying to add a rich
| text dialog and getting hit hard by bugs, counterintuitive
| behaviors, internationalization issues, etc.
|
| Nobody uses all of what Qt offers. I can't even imagine
| what it would look like for a program to use literally
| everything it has. Even a full office suite would be
| pressed to do that. But everybody uses lots of different
| things. Put 10 Qt GUI users together and they'll use very
| different subsets beyond the bare basics like layouts and
| simple buttons.
|
| Simply to write a _binding_ to a GUI toolkit, ignoring all
| the other aspects of Qt, is itself a major project. There
| 's been more than one Python project for it, and it is a
| _project_ , generally more than one person could hope to
| do. To write a full toolkit that won't give people the
| experience above is _enormous_.
|
| And that is why it is important to select your language
| carefully if you're writing a GUI-heavy project. You can't
| just pick up your favorite language and casually expect
| every widget you need to be available. Even if you
| nominally have "a binding to Qt" in your language, in my
| experience it's important to still double check that the
| binding to the widget(s) you _need_ actually work, because
| anything beyond those bare basic layout, buttons, and
| bindings to simple widgets everybody uses is still quite
| possibly broken, or incompletely bound so it can 't
| actually be used (which means nobody can have ever even
| tried this widget), or straight-up missing, or it's present
| but there's no way to correctly subclass something then
| make the bound widget use your subclass (in the foreign
| language) correctly, or _something_.
|
| Nor can you just bide your time and hope a toolkit appears.
| They're _enormous_ projects, even just to get one to the
| point that most developers don 't generally hit a vital bit
| of missing functionality, let alone to get one full of all
| the features someone could reasonably want.
| badsectoracula wrote:
| Sorry but my experience with Qt has been neutral to
| negative. I can go and write a textwall about all the
| issues Qt has and personal experiences i had with it
| myself, but they're not really relevant here. Your
| message is basically "people stick with Qt because people
| stick with Qt so that is the safe bet" (aka "nobody was
| fired for buying IBM"). Which sure, it is true and a big
| reason why you do not see other toolkits much, but this
| doesn't really have to do with what i wrote.
| IshKebab wrote:
| They're just really enormous libraries with a ton of tiny
| details you have to get right. Same reason there are so few
| good FOSS CAD programs or word processors. Tons of work.
| bluGill wrote:
| Legacy code. I've been doing QT for 10 years, I only heard of
| rust about 3 years ago, but the hype (particularly memory
| safety) has got me very interested. If I can take some existing
| C++ that is due for major surgery for other reasons and write
| it in rust I'm interested.
|
| We know from experience that rewriting our entire system from
| scratch will take 5 years and cost $150million: I won't even
| attempt to convince management of that. Our current C++ should
| be good for 25 years as just C++. if we maintain it well (the
| major surgery mentioned above) it can last indefinitely.
| However replacing the current QT GUI is not on the table, it
| already has our themes. Maybe someday in the future it will be
| on the table if there is better one and it can work well (look
| at feel) with out current QT GUI, but for today we don't
| complain about QT.
| fulafel wrote:
| There's a lot of requirements creep, the bar is high, since the
| estabilished stacks have had decades to build up their feature
| sets. Complexity multipliers include accessibility, cross-
| platform, gpu acceleration, complexities of text in the modern
| world (unicode, fancy rendering like subpixel aa, fonts,
| bidi...), programming language bindings, memory/lifetime
| management in presence of different mutually incompatible PL
| memory management models, native code hostile mobile platforms,
| etc. Leave any of those out and you start halving your
| potential users for each feature.
|
| (For more specialised, niche gui toolkits the answer is that
| they're out there, but you've never heard of them because they
| don't enjoy the network effects that a wider user base gets the
| big toolkits)
| ogoffart wrote:
| I wonder what problems from the list apply to another existing
| and more mature solution: https://github.com/woboq/qmetaobject-
| rs/
| detaro wrote:
| Given that the last commit is by someone with the same username
| as you, wouldn't you know better than random HN commenters?
| ogoffart wrote:
| Well, that's the thing. In my (biased) opinion, that crates
| doesn't have any of the problem mentioned.
|
| - The qmetaobject crate tries to be idiomatic rust and to be
| used without any C++
|
| - As far as the user is concerned, there shouldn't be any
| call involving C++
|
| - It does follow the Rust multi-threading guarantees
|
| - The License is the same as CXX-Qt
|
| - It does support plugins:
| https://github.com/woboq/qmetaobject-
| rs/tree/master/examples...
|
| - It uses code generation via macro
| detaro wrote:
| so say that, instead of playing this fake "oh I don't know
| and have nothing to do with it, can anyone help" game. Know
| your audience. It's HN, mentioning your alternative is
| accepted here as long as you're fair and honest about it,
| especially since this isn't even a Show HN.
___________________________________________________________________
(page generated 2022-03-02 23:01 UTC)