[HN Gopher] Leaving The Qt Company
       ___________________________________________________________________
        
       Leaving The Qt Company
        
       Author : TonyTrapp
       Score  : 140 points
       Date   : 2022-05-18 12:32 UTC (10 hours ago)
        
 (HTM) web link (lists.qt-project.org)
 (TXT) w3m dump (lists.qt-project.org)
        
       | muxneo wrote:
       | I learned this amazing C++ based GUI framework called "QT" (cute
       | :)) in 2003. At that time it was owned by Trolltech. I developed
       | UI for a Digital Cinema system which was used to project movies
       | in theaters. Amazing framework to work with and lots of good doc
       | for developers.
        
         | kiawe_fire wrote:
         | That sounds like a fascinating thing on its own. Any chance
         | you've written about that experience somewhere? If you ever
         | did, I'd love to read it.
        
           | muxneo wrote:
           | Now that I look back, I should have written about those good
           | old days. Here are few press releases about the product
           | https://www.dcinematoday.com/dc/pr?newsID=74
           | https://www.dcinematoday.com/dc/pr?newsID=247
           | 
           | I wish there were screenshots of the UI. I did lot of
           | customization of many UI componentents like slider, ListView
           | and much much more.
        
       | Rochus wrote:
       | Just went over the comments and am once again amazed that none of
       | the comments goes into the referenced message; most people
       | discuss something else, or ask questions that are answered in the
       | referenced message; but hardly anyone seems to care that the most
       | important technical head of the company is leaving, or why just
       | now (that he is leaving at this time seems rather coincidental
       | according to the text, and why leaving a well paid, secure
       | position for a startup, at his age?).
        
         | digisign wrote:
         | People move on for all sorts of reasons. He's probably well off
         | after a long career, so I don't see the point of the ageism at
         | the end of your post.
        
           | Rochus wrote:
           | If you don't understand the problem, you probably belong to a
           | younger generation. In older years, you change jobs only when
           | it's unavoidable. In informatics, it is already very
           | difficult to find a job from the age of 45. So there must be
           | important reasons. If he simply wanted to retire, he would
           | hardly have mentioned the startup.
        
         | zepearl wrote:
         | > _anyone seems to care that the most important technical head
         | of the company is leaving_
         | 
         | To me the message didn't sound like a manifest but more like an
         | info (to make the change smooth)?
         | 
         | Therefore I guess that people that know QT just don't care
         | about speculating about that (why now/before/later, who cares)
         | - of course this info will be remembered if in the future
         | problems arise.
        
           | Rochus wrote:
           | There has been quite a bit of controversy over the direction
           | of Qt. I've been working with Qt for more than twenty years
           | and find the news pretty amazing, as no doubt do many others.
           | With Qt 6, the company has entered similar waters as the
           | developers of Wayland: building something with a lot of
           | effort, that is functionally only marginally different from
           | the established technology, but significantly less mature.
        
             | zepearl wrote:
             | Thx - I used only Qt3 and for a short time Qt4.
             | 
             | I liked the dual-license approach, but apparently it's not
             | as "pure" as I thought was?
        
               | Rochus wrote:
               | Qt4 is/was much better than Qt3; and Nokia made it
               | available to everyone under LGPL which was sensational;
               | Qt5 mostly improved modularity and platform abstraction;
               | after the Nokia aera, Qt has given itself a bit of an
               | orientation log, adding features in all sorts of
               | directions that didn't necessarily add to the core
               | proposition, but increased complexity and development
               | effort, without adequate value in my view.
        
               | zepearl wrote:
               | Thanks! Interesting :)
        
       | hoseja wrote:
       | It's been weird to not see much discussion about this abomination
       | that Qt put out recently: https://www.qt.io/blog/is-open-source-
       | really-free
        
         | simplehuman wrote:
         | Probably why he is leaving
        
         | ChrisLomont wrote:
         | What is an abomination? It lines up well with my experience
         | using both Qt and open source and also using both in projects.
         | Certainly issues 2,3,4 cause problems for any project wanting
         | to integrate open source into commercial work. And 1 seems on
         | par with experience. For all points they cite decent sources.
        
           | cpitman wrote:
           | It's wrong in so many ways:
           | 
           | 1. Just because something is open source, doesn't mean you
           | cannot get support for it. There are plenty of companies that
           | offer support for open source software, and yes, this costs
           | money. But the general rule of thumb is that $1 of open
           | source support replaces $10 of proprietary revenue.
           | 
           | 2. All software has licenses, even from proprietary vendors.
           | But proprietary licenses have no standards, each and every
           | one should be reviewed before acceptance. And they can also
           | change at the drop of a hat and _you have no recourse_.
           | Having a standard set of licenses, and a community that could
           | support a fork are both value unique to open source.
           | 
           | 3. Reviewing compliance is a thing with or without actually
           | using open source software. Even if you say "we don't use
           | open source software", that doesn't actually stop anyone from
           | doing some copy-posta of code from some website.
        
             | ChrisLomont wrote:
             | None of these make the article wrong.
             | 
             | 1. You can get support sometimes - the question is at what
             | price and at what quality and at what timeliness. Open
             | source is no cure here.
             | 
             | A quick test: I googled "support for scipy" and found zero
             | places I can buy fixes or support in the many pages I
             | clicked through. I googled "support for Mathematica" and
             | top hit (and the entire first page) were all support.
             | 
             | Try the same thing for any open source project, and the
             | comparable commercial product, and tell me which seems to
             | have more support available.
             | 
             | >general rule of thumb is that $1 of open source support
             | replaces $10 of proprietary revenue.
             | 
             | That "rule of thumb" doesn't show up in a google search
             | except for your comment. I'm not even sure what it's
             | supposed to mean. Clarify?
             | 
             | 2. "But proprietary licenses have no standards": every
             | single proprietary license I've bought or been on the group
             | deciding what to license has been nearly trivial - usually
             | you buy an outright license to use as you will (and no open
             | source gotchas to worry about what code touches what), or
             | has been some tiered revenue/sales thing, all trivial to
             | navigate. They are much easier than all but an open source
             | "use for anything at will" license. And they don't trigger
             | a host of legal issues. And there are dozens of open source
             | licenses in common use, each with a host of legal issues to
             | work out. This is why legal depts on every project I've
             | needed to integrate must oversee each item we want to
             | integrate, but not on buying licenses from proprietary
             | vendors.
             | 
             | 3. Proprietary code is backed by a vendor you can sue when
             | you get sued, especially if they claimed compliance they
             | did not meet. This provides legal protection when using
             | their products. Open source has none of this, so all risk
             | is on you, and you have to price this in.
             | 
             | All these factors have costs to development, risks to
             | legal. Try integrating some open source into pacemaker code
             | and see how much trouble and cost that is from legal,
             | compared to buying proprietary, certified, components. Or
             | car software (not dash entertainment, but driving critical
             | stuff). Or infrastructure code like power line stuff,
             | safety stuff, etc.
             | 
             | I like open source, and use it for lots of playing around,
             | and where applicable. But it's a nightmare for a
             | significant amount of work outside the HN popular web apps
             | and social media startups. Most software development is not
             | in these spaces.
        
           | detaro wrote:
           | It's (unsurprisingly) extremely biased towards "buy from us",
           | presenting only upsides of commercial licensing and
           | downplaying them on the open-source side. The comments are
           | good starting point for why their representation of what you
           | get when you buy are ... optimistic.
        
         | rglullis wrote:
         | How is that wrong?!
         | 
         | Basically what they are saying is that "there is more to look
         | than just sticker price. It's not just because the software is
         | open source that TCO is lower."
        
           | stjohnswarts wrote:
           | It's not and it's not a blog that is hostile to open source
           | like it's being pawned as. It's just saying there is a
           | cost/tradeoffs just like any other way of doing software.
           | Some OSS advocates won't hear any of that. They just hear
           | insults to their favorite project.
        
         | pjmlp wrote:
         | Yeah, because Gtk shows how to do it better. /s
        
           | shrimp_emoji wrote:
           | The Gtk faction were always the more idealistic FOSS purists
           | (which is partly why Gnome is sadly the default on so many
           | distros). ;p
        
             | ahartmetz wrote:
             | Except that, back in the day, a much touted advantage of
             | GTK+ was its LGPL licensing, making it more suitable for
             | writing proprietary software. That was basically Red Hat
             | speaking, which has always been the strongest backer of
             | GTK+ and Gnome.
        
       | kramerger wrote:
       | Maybe it's time for another toolkit to step up and replace Qt?
       | 
       | Maybe something that uses modern C++ all the way. Such as the
       | serenityOS UI library?
        
         | nullcipher wrote:
         | Slint is coming along nicely - https://github.com/slint-
         | ui/slint
        
       | raydev wrote:
       | Unrelated to the content of the email:
       | 
       | Can we please get a better UI for mailing lists? The text is too
       | small for me to comfortably read, so I used Chrome's zoom
       | feature. But once I zoom in, the text wrapping is completely
       | static so I'm forced to scroll horizontally.
       | 
       | Is there a more accessible way to read content on mailing lists?
        
         | digisign wrote:
         | It is responsive on my Firefox. Basic HTML has always been
         | responsive, except when folks break it, on accident or on
         | purpose.
        
       | jeffrallen wrote:
       | I worked on a project using Qt for several years. It was okish,
       | certainly a useful cross platform addition to C++ code. But it
       | was so big and so opinionated... I mean come on: C++ has strings,
       | what business do you have adding your own magical strings?
       | 
       | It was certainly part of what made me hate programming and then
       | wake up out of my stupor to find Go and learn to love programming
       | again.
       | 
       | Bye bye Qt and C++, never going to touch you again if I can
       | possibly help it.
        
         | jcelerier wrote:
         | > I mean come on: C++ has strings, what business do you have
         | adding your own magical strings?
         | 
         | C++'s std::string is Qt's QByteArray though, not QString which
         | represents an actual Unicode string.
        
         | brnt wrote:
         | I love Qt for Python, but in the process of a port to C++ my
         | main wish is modern C++ bindings.
        
       | mschuster91 wrote:
       | To make that mess readable: `pre { width: 50%; white-space: pre-
       | wrap; margin: 0 auto 0; }`
       | 
       | I hate pipermail with a passion, it's 2022 and still it's a
       | hassle to read mailing list posts...
        
         | eql5 wrote:
         | Or read it from here (quoted in a response):
         | 
         | https://lists.qt-project.org/pipermail/development/2022-May/...
        
         | blumomo wrote:
         | or enable your browser's reader mode, i.e. firefox:
         | https://support.mozilla.org/en-US/kb/firefox-reader-view-clu...
        
       | colesantiago wrote:
       | Who please?
        
         | bluGill wrote:
         | The main guy behind QT, while not the first on the project, he
         | has been the main vision behind all the technical parts for 25
         | years. He wrote the engine that we now know as webkit and
         | chrome.
        
           | fullstop wrote:
           | He was also a major contributor to KHTML, which was adopted
           | by WebKit, and subsequently Blink. It's the roots of both
           | Safari and Chromium.
           | 
           | His influence is monumental.
        
             | meijer wrote:
             | I wonder if he himself uses Firefox. That would be a nice
             | irony.
        
               | bluGill wrote:
               | Considering what happened to khtml in the last 15 years
               | I'd use firefox myself. Come to think of it I actually
               | did get one patch into khtml back in the day (exactly
               | one, don't read too much into this), and I now use
               | firefox. I keep thinking I should resurrect the khtml
               | project so we get a good open source engine again -
               | (firefox is more than an engine), but realistically it
               | needs more love than once part time person can give it.
        
         | [deleted]
        
         | emddudley wrote:
         | "Lars Knoll is The Qt Company CTO and Qt Project Chief
         | Maintainer. He has been working on Qt for more than 13 years
         | starting as a software engineer to later leading the global Qt
         | engineering team in Nokia before the Digia acquisition in
         | October 2012."
         | 
         | From https://www.qt.io/blog/author/lars-knoll
        
           | coldtea wrote:
           | It probably means: "more than 13 years BEFORE the 2012
           | accusation". Because I already knew Lars Knoll as involved
           | with QT back in 2000 (except if he was just working on the
           | KDE side then).
        
             | kstrauser wrote:
             | ("Acquisition", not "accusation".)
        
             | rayiner wrote:
             | I remember the kerfuffle about QT licensing and KDE. Back
             | then I used KDE and dismissed the concerns. It's been odd
             | and unfortunate to see those concerns having been at least
             | partially founded.
        
         | bartvk wrote:
         | I feel you're trying to say something with your short comment.
         | 
         | In the Wikipedia entry on The QT Company, he is (still)
         | mentioned as the current CTO.
         | 
         | https://en.wikipedia.org/wiki/The_Qt_Company
        
       | markus_zhang wrote:
       | One question for GUI folks. Comparing to the classic RAD tools
       | such as VB and Delphi, does QT match the efficiency and easy-to-
       | use? Appreciate any insight.
        
         | lionkor wrote:
         | I used both Embarcadero Delphi and Qt extensively, and I prefer
         | Qt due to their nice IDE integration with lots of other tools,
         | like valgrind, clangd, gdb, etc., and simply a faster, snappier
         | experience. And its unapologetically cross platform.
        
           | markus_zhang wrote:
           | Thanks. Yeah that's a valid point. Sadly Delphi is way out of
           | main stream these days.
        
         | marcodiego wrote:
         | I had just superficial experience with each of these tools,
         | which I think is more adequate to answer your question since VB
         | and Delphi are very productive for people who have little
         | experience.
         | 
         | QT and Qt Creator is more evolved than both (I don't know
         | recent Delphi versions, but still think so). In Delphi (not
         | sure about VB) you can do Text1.Caption := "Hello World". In QT
         | Creator (last time I tried), you have to create some code to
         | connect the signals to slots and still call a method to achieve
         | the same thing. It was a bit more work but, easy, clear
         | intuitive, well documented and has advantages when implementing
         | more advanced features in a more generic way. I'd choose QT
         | over both others today even for beginners and even disregarding
         | licenses.
        
           | markus_zhang wrote:
           | Thanks! Good to know that QT manages to bring back or enhance
           | the experience.
        
       | throwaway2037 wrote:
       | Somewhat unrelated: When I open the link, the lines of text are
       | _super_ long and do not wrap in a standard desktop browser. Am I
       | doing something wrong? Or: Is there a trick to force wrap the
       | text in a browser?
        
         | gunapologist99 wrote:
         | It's because this is literally the only style specified in the
         | page:                  <style type="text/css">            pre {
         | white-space: pre-wrap;       /* css-2.1, curent FF, Opera,
         | Safari */                }        </style>
         | 
         | Perhaps it's to make sure code snippets are correctly aligned,
         | but a link to a wrapping version would be very useful, or
         | perhaps just letting very long lines wrap in a narrow browser
         | window, because the current model means that you have to scroll
         | horizontally as you read every single line, even on a very wide
         | screen.
        
           | kevincox wrote:
           | pre-wrap should allow wrapping. And adding white-space: pre-
           | wrap explicitly to the pre fixes it for me. So maybe that
           | isn't applying for some reason.
           | 
           | Edit: Ah, the problem appears to be that a Content-Security-
           | Policy blocks it.
           | 
           | > Content Security Policy: The page's settings blocked the
           | loading of a resource at inline ("default-src").
        
         | blumomo wrote:
         | Enable the reader mode of your browser for his page. Firefox
         | has it [0] and other browsers surely, too.
         | 
         | [0] https://support.mozilla.org/en-US/kb/firefox-reader-view-
         | clu...
        
           | markstos wrote:
           | It still doesn't wrap in Safari mobile's reader mode
        
         | [deleted]
        
       | anderspitman wrote:
       | I only recently became aware that Qt is actively trying to pull
       | away from open source[0].
       | 
       | I understand that people do things for reasons, but this
       | situation looks pretty sad to me.
       | 
       | [0]: https://mail.kde.org/pipermail/kde-
       | community/2020q2/006098.h...
        
         | Nokinside wrote:
         | QT has retreated to what is the absolute minimum it has legally
         | to do. They can't pull away any more. QT and KDE have legally
         | binding agreement.
         | 
         | >All software changes in Qt will still be available at as Open
         | Source as required by our contract - maybe with a delay of 12
         | months if the company decides to part ways with the
         | communities.
         | 
         | It's hassle to maintain LPGL version with 12 month lag for
         | sure.
        
           | anderspitman wrote:
           | I'm more concerned about the show of intent than the specific
           | actions up to this point.
           | 
           | What if they decide to put all the docs behind a paywall? And
           | if they can't because of licensing reasons, what if they just
           | stop paying people to update the docs and make a new version
           | of the docs without licensing restrictions?
           | 
           | There are a lot of ways this can get worse.
           | 
           | Licensing protection isn't a silver bullet. If the
           | organization becomes hostile, it only guarantees you the
           | ability to fork. While that's huge, it's of limited utility
           | if the project is too big to fork. See Chromium. I think Qt
           | may be too big to fork.
        
             | gmueckl wrote:
             | The Qt Company itself isn't bound by licenses on the
             | code/documentation, but by a separate contract with the KDE
             | Free Qt Foundation [1]. This document is publicly available
             | and treats the documentation pretty much equal to the code
             | itself.
             | 
             | Qt is effin' huge, but it is also at the core of a big and
             | diverse ecosystem. There are many, many users across
             | various industries, including big players and there are
             | companies that offer consulting and development services
             | specifically around Qt. If the Qt Company was to piss
             | enough of these users off, they could easily join forces to
             | create an economically feasible fork. The real trick would
             | be avoiding competing forks, I think.
             | 
             | [1]
             | https://kde.org/community/whatiskde/kdefreeqtfoundation/
        
         | ttybird2 wrote:
         | They also started blocking people with Russian IP Adresses from
         | downloading it. https://forum.qt.io/topic/134724/unlock-qt-in-
         | russia
        
       | lewisjoe wrote:
       | Qt is an amazing piece of tech that got many things right.
       | 
       | 1. Performance that matches native speeds
       | 
       | 2. Single codebase for multiple platforms (without relying on web
       | technologies)
       | 
       | 3. Not limited with a single language (has bindings to all major
       | languages)
       | 
       | 4. The core is written in a performant language (C++)
       | 
       | But recent developments in UI programming is sidelining
       | frameworks like Qt with some really good innovations.
       | 
       | - Like React/React-native ecosystem pioneered the component based
       | declarations of UI elements.
       | 
       | - Flutter pushed it to all platforms with Skia as the rendering
       | engine
       | 
       | - Jetpack Compose is pushing it with a better language (Kotlin)
       | 
       | - State management had matured a lot with redux style immutable
       | stores
       | 
       | The irony is even with all these recent developments there isn't
       | a single UI framework that took the best parts of older
       | frameworks like Qt and combined it with the recent ideas from
       | Flutter and Jetpack-compose!
       | 
       | If it did it all, the multi-platform support is handicapped.
       | Either the native strategy becomes an afterthought or the Web
       | becomes an afterthought, hurting accessibility, etc.
       | 
       | We still have a long way to go in cross-platform UI frameworks :)
        
         | bsnal wrote:
         | 1. Qt is much faster than other UI technologies, but it's far
         | from being as performant as native solutions are.
         | 
         | 2. You will need a big amount of hacks to make your project
         | work on different platforms. Especially if you do something
         | fancy.
         | 
         | Not to mention serious licencing issues.
        
           | SemanticStrengh wrote:
           | > Qt is much faster than other UI technologies, but it's far
           | from being as performant as native solutions are.
           | 
           | What does it feels like to spit random beliefs out of your
           | hat and state them as truth? Native doesn't even mean
           | anything, there really is something wrong going on on the
           | mental models people have when talking about GUIs. IIRC QT
           | use GDI+ on Windows for drawing 2D GUIs, which is mostly CPU
           | based. And its shows in many tasks, see e.g. the strokePoly40
           | https://blend2d.com/performance.html Chromium use Skia and
           | gecko use webrender, those are much much much faster on
           | average. In fact the web has more FPS than native libraries
           | in general.
        
             | bsnal wrote:
             | You conveniently forget about the DOM, for example
        
               | SemanticStrengh wrote:
               | I'm not seeing why the DOM would necessarily makes
               | rendering slower. See e.g. this comparison showing react
               | web being faster and more energy efficient than react-
               | native. https://ionicframework.com/blog/ionic-vs-react-
               | native-perfor... It's true that pathological DOM dynamism
               | might incur some cache/layout invalidations, however if
               | that were to be an issue (which is very rare and
               | profiling is easy), you could mostly eliminate the
               | problem with a few lines of
               | https://developer.mozilla.org/en-US/docs/Web/CSS/contain
        
           | dal wrote:
           | I think they have a very reasonable licensing model being GPL
           | and Free Software.
        
           | joezydeco wrote:
           | Licensing has gotten much worse, so much so that my current
           | firm is sticking with our Qt5 contract and will not negotiate
           | to Qt6. So we're hitting the end of the road with Qt in the
           | next few years.
           | 
           | On top of that, priorities are just different now. I spent an
           | afternoon chasing down why QtCore has incomplete or missing
           | methods for handling JSON documents (TLDR: "won't fix"), but
           | I get a constant stream of marketing email promoting their
           | new in-app advertising structure. And now there's a speech
           | recognition engine?
           | 
           | I'm just done with it all. Guess I need to learn React.
        
             | marcosdumay wrote:
             | From my point of view, there's a reasonable chance that the
             | entire world sticks with LGPL Qt5.
        
             | bsnal wrote:
             | This is my experience as well. Core bugs keep pilling up
             | for years at an alarming rate while they focus on adding
             | new functionality that most developers don't need.
             | 
             | Their bad licencing made sense back in the day. But they
             | now face strong competition and instead of moving to a more
             | open licence system, they seem to be doubling down. They
             | don't seem to understand that not only they aren't the only
             | framework in town anymore, they are currently worse than
             | much better licenced systems.
        
           | shrimp_emoji wrote:
           | Can you expand on this?
           | 
           | > _You will need a big amount of hacks to make your project
           | work on different platforms. Especially if you do something
           | fancy._
           | 
           | Having done Windows-Linux Qt, I haven't noticed needing
           | "hacks" (unless you count the hacks necessary to build
           | anything on Windows at all cuz the OS wasn't meant for
           | programming ;p).
           | 
           | The fanciest thing I've done is theming (light, dark, etc.),
           | which Qt doesn't seem to support natively, and which is
           | difficult to do sanely without some "hacking".
           | 
           | > _Not to mention serious licencing issues._
           | 
           | What issues? Is it just that it's LGPL, or what?
        
             | bsnal wrote:
             | I said "if you do something fancy". For example custom
             | widgets with qpainter, etc
             | 
             | Light/dark theming should be easy with stylesheets.
        
         | orangepurple wrote:
         | Give it a few years and Flutter/Skia will be Killed By
         | Google(tm) https://killedbygoogle.com/
        
           | sounds wrote:
           | Skia is the compositing/rendering engine for Chrome.
           | 
           | I doubt Chrome will stop using Skia, though Google can always
           | do something akin to a fork or name-change that will break
           | all existing apps.
           | 
           | Highly doubtful that will happen.
        
         | heavyset_go wrote:
         | QML and QtQuick are actually declarative and reactive in ways
         | that React isn't, and I find them much more pleasant to use
         | than React, especially when it comes to separation of concerns.
         | They've existed for quite some time, too.
        
         | Kelteseth wrote:
         | QML is Qts innovation. The declarative way to write a UI is
         | unmatched IMHO when comparing to Unreal, Godot or the Web.
         | Still, QML has a _lot_ of other little problems like bad
         | tooling (no autoreload, unusable designer) and often broken
         | type system where you can assign invalid properties, and it
         | will silently fail.
        
           | joezydeco wrote:
           | If by "silently fail" you mean "entire segments of your UI
           | disappearing" then yes.
        
           | mariusmg wrote:
           | >QML is Qts innovation. The declarative way to write a UI is
           | unmatched when comparing to...the Web
           | 
           | What? Isn't HTML the daddy of declarative languages for UI ?
        
             | dahfizz wrote:
             | > Isn't HTML the daddy of declarative languages for UI ?
             | 
             | Not really. HTML is a way to create documents. It's closer
             | to latex than QML. HTML + CSS + JS is used to create UIs,
             | but it definitely does not match the capabilities of
             | something like QML.
        
               | mariusmg wrote:
               | - JS is not needed to create UIs.
               | 
               | - CSS is used for styling, it is important but is not
               | required.
               | 
               | Don't get me wrong, i think QML and XAML are cool and
               | all, but HTML did this a long time ago.
        
           | enqk wrote:
           | It's also not truly declarative since you can observe
           | ordering (and therefore your app may silently depend on
           | imperative execution)
           | 
           | There's also performance issues with large amount of code,
           | and last I checked, Qml doesn't really mix well with the
           | traditional Qt widget and protocols (i.e. sometimes things
           | are reimplemted in Qml under similar names, but with
           | different behaviors)
        
           | eql5 wrote:
           | Autoreload can be added quite easily, like in this Lisp
           | binding, which has an example where even single file
           | autoreload works, both on desktop and mobile, simultaneously:
           | 
           | https://gitlab.com/eql/lqml
           | 
           | https://gitlab.com/eql/lqml/-/tree/master/examples/advanced-.
           | ..
        
           | nyanpasu64 wrote:
           | QML on the desktop is highly buggy. The menu bar doesn't
           | close when you click on other windows (even after 10 years),
           | it took a decade to create a half-decent Qt Quick Controls 2
           | file dialog, there were multiple tab order bugs where
           | pressing Tab hung the app (in Qt Widgets it would instead
           | highlight the wrong widget when you pressed Tab then Shift-
           | Tab) and one of them was fixed after several years mere weeks
           | ago (https://bugreports.qt.io/browse/QTBUG-87190), mouse
           | scrolling (Flickable) works differently from Widgets (and
           | scrolling twice quickly can travel 4 times the distance as
           | scrolling once), on Android it drops frames even on a fairly
           | high-end phone (Pixel 4a) and interactions feels uncanny-
           | valley... I'm under the impression that you're almost not
           | meant to use Qt Quick Controls 2, since KDE created their own
           | Item hierarchy, rejecting Qt's own Flickable altogether.
        
         | Matl wrote:
         | I'd add treating the KDE community with contempt to the
         | negative side of your list. KDE did a lot to breathe life into
         | Qt and that seems to have been forgotten.
        
           | digisign wrote:
           | I'm not familiar with the contempt angle of Qt?
        
             | nyanpasu64 wrote:
             | There were rumors that Qt wanted to take the project
             | proprietary. They didn't go through with those plans, but
             | right now they are delaying all patch releases of Qt5 by 12
             | months, forcing KDE to maintain their own set of backported
             | patches
             | )https://invent.kde.org/qt/qt/qtbase/-/tree/kde/5.15), and
             | rebase on top of Qt 5.15.3 and .4 etc. every so often,
             | until KDE eventually ports to Qt 6.
        
         | HelloNurse wrote:
         | What do you mean by "component based declarations of UI
         | elements"? Declarative specification of UI widgets (e.g. XUL)
         | is much older than web-based component frameworks like React.
         | Component orientation in UI frameworks is even more
         | traditional, and far older than Qt.
         | 
         | What "recent ideas" do you find in Jetpack Composer, Flutter
         | and React Native that Qt lacks? These tools let you write apps
         | with a nice user interface for Android exactly like Qt;
         | supporting Kotlin, Dart, Javascript etc. besides C++ and
         | various Qt language bindings is useful, but not necessarily
         | superior.
        
           | mosdl wrote:
           | Even React wasn't the first web framework to do this, Dojo
           | for example did this way back as well.
        
         | jjtheblunt wrote:
         | > Like React/React-native ecosystem pioneered the component
         | based declarations of UI elements.
         | 
         | why don't you consider NeXTSTEP from 1988 on to the present day
         | in macOS UIKit?
        
         | simion314 wrote:
         | -Like React/React-native ecosystem pioneered the component
         | based declarations of UI elements.
         | 
         | What do you mean? Qt,WPF, Flex was doing UI with an XML syntax
         | language before React existed, some people prefered doing
         | things by hand instead of rag and drop back then too. The
         | "components" were named Controls or Widgets and the Web still
         | is a inferior pile of shit because in this old tooljits when
         | you needed say a custom DataGrid widget you extended the
         | existing one and where in Web you start from Zero with
         | divs,inputs and buttons.
        
           | lucideer wrote:
           | There's a common misconception that JSX is XML - that's very
           | excusable as the syntax is based on XML, but it's not the
           | case and you should look into JSX in more depth if you think
           | it is.
           | 
           | However, what's less excusable is thinking React components
           | are somehow equivalent to XML: React components are a lot
           | more than bits of JSX (components very often don't contain
           | any JSX, it's an optional syntax extension, not a fundamental
           | part).
           | 
           | There's very little in common between React components and
           | the XML definitions used by Qt,
           | 
           | > _UI with an XML syntax language_
           | 
           | If you're interested in learning a bit about how React works,
           | I'll start you off with this: React doesn't really do UI
           | directly at all. It isn't layout-aware, layout is handled by
           | the rendering target: e.g. DOM+CSS for the ReactDOM rendering
           | lib, HTML+CSS for the ReactDOMServer rendering lib, UIKit for
           | the RN iOS rendering lib, etc.
        
             | nightski wrote:
             | I think the point was that they were declarative and
             | retained mode systems and existed long before react. I'm
             | deeply familiar with React and systems such as WPF/QT and I
             | can see the comparison.
        
               | lucideer wrote:
               | > _I think the point was that they were declarative ..._
               | 
               | > _I 'm deeply familiar with React_
               | 
               | I'm not trying to be snarky here but... React is not
               | declarative.
               | 
               | Though it's good you highlighted that as that is
               | essentially the fundamental difference here: WPF/QT are
               | declarative, CSS is declarative, UIKit is (mostly?)
               | declarative, HTML is declarative(-ish). React components
               | aren't.
        
               | nightski wrote:
               | I have to disagree. You produce a data structure
               | representing the UI. That's basically the definition of
               | declarative. Just because you can build that dynamically
               | doesn't mean it is not declarative. You could always
               | build up XML dynamically as well.
               | 
               | It's a far cry from an immediate mode API where you are
               | making draw calls.
        
             | HelloNurse wrote:
             | Another fun fact about React (at least React Native): there
             | are basically two separate "engines" for class-based and
             | function-based components, with subtle differences.
        
             | simion314 wrote:
             | I know what React and JSX were 6 years ago, I understand
             | now it much more complex, I even done React components
             | without JSX and use the React.Div functions to render
             | components.
             | 
             | I liked this about react, you create a render function and
             | render your stuff. It is miles of head or the angular
             | horrible architecture but the Web needs basic components
             | implemented naively that developers can extend and not
             | start every time from Zero with divs and other basic stuff.
        
           | lewisjoe wrote:
           | I think you are confusing XML style UI declarations with
           | composable-components-based UI declarations.
           | 
           | To cut the explanation short, the former means while initial
           | UI state was declarative (with XML), runtime mutations of UI
           | were mostly imperative with a binding turing complete
           | language.
           | 
           | The recent Component based model of composing UI - the
           | runtime mutations of the elements are expressed as state
           | updates inside the UI declarations itself(and declarations
           | are usually done with a turing complete language)
        
             | jcelerier wrote:
             | > The recent Component based model of composing UI - the
             | runtime mutations of the elements are expressed as state
             | updates inside the UI declarations itself(and declarations
             | are usually done with a turing complete language)
             | 
             | is pretty much how Qt does it with QML (released in 2011),
             | except that instead of requiring explicit function calls,
             | the variables are themselves reactive so that:
             | Button { text: "foo" + counter.value }
             | 
             | updates automatically whenever "value" changes. See e.g.
             | https://www.qt.io/product/qt6/qml-book (or a small TodoMVC
             | example I did at somepoint to see some actual code:
             | https://github.com/jcelerier/TodoMVC-
             | QML/blob/master/Main.qm... )
        
             | simion314 wrote:
             | you think bindings are super cool like bind the hidden
             | state of soemthing to some variable then Flex did it before
             | React and probably was not the first.
             | 
             | Compos ability for me means I can make a big component by
             | combining smaller ones, what does it mean to you?
             | 
             | Extensibility is the important part, you can get a DataGrid
             | and add 10 lines of code to add some feature to it and you
             | inherit everything from the base component, you get it all:
             | the performance, the events, the accessibility. In web I
             | only see shitty implementation that fail in different ways,
             | even the YouTube search + dropdown input fails sometimes
             | and remains open until you reload the page, a ton of Google
             | "geniuses" can't implement a shitty component with all
             | their languages and frameworks.
             | 
             | I personally like about react the functional part of it and
             | not the JSX part, that is sugar syntax, though when doing
             | complex stuff the functional part brke and you had no
             | choice then get your hands dirty and find workarounds and
             | do ugly stuff.
        
           | tabtab wrote:
           | What's sorely needed is an open state-ful GUI markup language
           | that targets CRUD and data, something HTML/DOM still sucks
           | bigly at. We wouldn't need language binding libraries if we
           | could issue XML to give us all the common and loved GUI
           | idioms like tabs, drop-down menus, data grids, pop-up
           | windows, tool-bars, combo-boxes, etc. (That HTML5 deprecated
           | frames and iframes is a shame. Anti-Kudos to the 5'ers. Fire
           | those b@stards!)
           | 
           | Most business work is still done with mice. Everybody thought
           | fingered mobile would displace mouse-oriented UI's, but that
           | was a _bad_ prediction. Let 's do open-source GUI's right
           | this time. (Could QML be reworked to XML and made open-
           | source?)
        
             | simion314 wrote:
             | I have no idea why browsers maker don't look at what
             | Desktop and Mobile GUI frameworks provide and implement
             | same functionality, like give us a ListView or GridView
             | that is implemented to be efficient and you don't have to
             | use pagination as a workaround.
        
             | nyanpasu64 wrote:
             | Qt has data grids built in, but QAbstractItemModel is a
             | nightmare to implement and interface with (https://www.redd
             | it.com/r/QtFramework/comments/rx0c8e//hrfvyz..., https://do
             | cs.google.com/document/d/1__bldg9SwENN2d6LyiX0wwX5...). I
             | think some of the incidental complexity could be fixed, and
             | the implementation could definitely be simplified by
             | removing dragging between widgets (which requires the
             | model's backing data store be built around adding and
             | removing items, rather than merely reordering them), but I
             | feel it's inherently difficult to communicate changes to
             | data to the QAbstractItemView in the form of individual
             | insert/delete/move operations. I haven't explored the JS
             | world's approaches to UI diffing or lazy-loaded data grids
             | though.
        
         | [deleted]
        
         | nsonha wrote:
         | Single code base for multiple platforms is not impressive these
         | days, you can do it in many frameworks. The key thing seems to
         | be 1. written in C++ (hence performant) and 2. Has a
         | declarative language (QML).
         | 
         | 1 is no longer an advantage since C++ is no longer a desirable
         | language for UI engineers, largely because UI went from desktop
         | to mobile and web which created an opportunity to disrupt the
         | status quo
         | 
         | 2 is no longer trendy either as functional programming becomes
         | more popular. People realized they can be declarative in real
         | programming languages and don't have to turn UI into a bunch of
         | config files.
        
       | Nokinside wrote:
       | QT Company (QTCOM.HE) has been an amazing investment. From
       | 2016-NOW +1800% (TSLA +1600%).
        
         | pavlov wrote:
         | It's an amazing example of how Nokia mismanaged their assets
         | and sold them away for a song.
         | 
         | Nokia bought Qt in 2008 for $150M. (The original name of the
         | company was Trolltech.)
         | 
         | Sold it in 2012 for only $5M.
         | 
         | Ten years later, Qt Group is worth about $2 billion today,
         | having reached as high as $5 billion last year.
         | 
         | How do you first lose 97% of the value of an asset, then watch
         | on the sidelines as it goes up 1000x? Nokia's management was
         | both incompetent and incomprehensibly negligent in handling
         | shareholder value when they let this asset go for 5 million. Of
         | course these managers were selling Qt for almost-nothing to
         | their good friends in Finland, while the bill was paid by
         | Nokia's global shareholders... This kind of borderline theft is
         | easier to pull off in a small country, even one that pretends
         | to be the least corrupt in the world.
        
       | simplehuman wrote:
       | Curious where he is going next. Anyone on the inside know?
        
         | bluGill wrote:
         | He said some sort of startup, but didn't say what one or what
         | they are doing.
        
           | meijer wrote:
           | Haavard Nord, one of the Trolltech founders, has a startup
           | named "Conclude".
        
       | joezydeco wrote:
       | I hate these emails, and LinkedIn is guilty of this too.
       | 
       | 200 lines of how wonderful the company was and all the great
       | people and all the great accomplishments and yadda yadda... and
       | one cryptic line about why he's actually quitting.
       | 
       | And the "I want to try something new" line is _always_ a cover
       | for something else.
        
         | stjohnswarts wrote:
         | Isn't it possible that he's tired of c++ and Qt after 25 years?
         | I mean he's starting a new startup so he probably can't reveal
         | what that is, but it's obviously something he's excited about.
         | Hell after 2 or 3 years at company I'm ready to finish up
         | whatever I'm working and move on to somewhere else.
        
         | [deleted]
        
         | xedrac wrote:
         | In the case of Lars, this may actually be true. Imagine working
         | on the same project since the year 2000. I'd want to try
         | something new too.
        
           | joezydeco wrote:
           | Lars wrote Webkit in the middle of Qt development. Surely he
           | could find out-of-band time and headspace to tinker with
           | different technologies if he wanted to.
           | 
           | To me, leaving completely signals something else.
        
         | thijsvandien wrote:
         | At least they're not going to "spend more time with family".
        
       ___________________________________________________________________
       (page generated 2022-05-18 23:02 UTC)