A Better Qt Because of Open Source and KDE • Hacker News Board

Re: A Better Qt Because of Open Source and KDE

#121

Post by dev-il » Wed, Dec 11, 2019, 7:23 PM UTC

Rochus wrote: post #90

ori_b wrote: post #53

Earlier quoted context omitted.

Already happened: https://www.copperspice.com

Thanks for the hint. Didn't know it. As it seems it is no longer Qt. They once started with Qt (don't know which version) but they have "completely diverged" as they say. The goal is not to have a free Qt but to have "Extensive use of modern C++ functionality" (with all these buzzwords). Not even shure if their containers are still implicitly shared. Will even though continue to have a look at it.

> don't know which version

apparently, they forked from Qt 4.8 and QML is disabled in Copperspice. Ref:

https://www.copperspice.com/docs/cs_overview/timeline.html#t...

https://news.ycombinator.com/item?id=9685022

https://forum.copperspice.com/viewtopic.php?f=11&t=1152

Re: A Better Qt Because of Open Source and KDE

#122

Post by dev-il » Wed, Dec 11, 2019, 8:35 PM UTC

Nokinside wrote: post #115

dev-il wrote: post #109

Earlier quoted context omitted.

It just so happens that the biggest part of my work is in embedded. And while it's obvious that QTCOM is trying to establish itself in that domain… this here is merely wishful thinking: > Your TV, car, Television, have Qt in them no, actually neither has. And let's face it: while QTCOM does have clients in those domains… it doesn't have any huge share in either. Most use simpler lower-level graphical libs. Apart from…

You realize that Qt is dual licensed? If you work in embedded like me, you already know that we make actual money. Nobody cares about license cost of Qt. It's quite low compared to everything else. We don't use LGPLv3 in Qt. We buy commercial license.

> You realize that Qt is dual licensed

what part of the thread did you not read? We've covered that already: the other option is the closed commercial license which since the switch from Nokia to QTCOM has become exorbitantly expensive

> Nobody cares about license cost of Qt (…) We don't use LGPLv3 in Qt. We buy commercial license.

You sound like you work in Qt Marketing, not in embedded.

> It's quite low compared to everything else

That's rather ridiculous. Most alternatives cost zero.

Re: A Better Qt Because of Open Source and KDE

#123

Post by comex » Thu, Dec 12, 2019, 2:25 AM UTC

jlarcombe wrote: post #105

comex wrote: post #49

Earlier quoted context omitted.

What’s the need? For better or worse, app bundles tend to be huge these days; there’s no obstacle to embedding a few megabytes’ worth of GUI libraries in your app bundle, or just statically linking them into your executable. Heck, a lot of apps embed a 120MB+ Electron framework; that’s pushing it, but Qt is “only” I’d love to see better cross-platform desktop apps. But I think the missing piece is for someone to writ…

I hear this quite a lot and am always curious to know which bits of the QWidget hierarchy are insufficiently native on the Mac - I've run in to many problems with Qt on the Mac over the years but that hasn't really been one, though our current app doesn't really use native-looking widgets anyway. As for QWidget being semi-deprecated, this is not the case. They made some noises in that direction around the time Qt 5 w…

For instance:

- Text fields are not backed by native NSTextViews, so automatic substitutions, spell checking, and the options you usually have in the right-click/Edit menu are all missing.

- Pop-up menus (but not top-menu-bar menus) are also custom, and the appearance and animations are way off. And there are some discrepancies in behavior:

a. Suppose you right-click and hold (which opens the right-click menu in a mode where you select menu items by releasing instead of clicking), then release while over a menu item that's either disabled or a submenu. With native menus, the menu gets dismissed; with Qt menus, it stays open. Sounds incredibly minor, right? But it's something I grew to subconsciously rely on, over years of using macOS. When I started using a Qt app, I kept instinctively trying to dismiss menus that way and getting frustrated when they stayed open.

b. If the mouse cursor leaves the menu area, native menus stop highlighting any item, while Qt menus keep highlighting whichever item was last highlighted. In the press-and-hold mode, this makes it seem like releasing the button might choose that item; it actually dismisses the menu, same as with native menus, but it's confusing.

Re: A Better Qt Because of Open Source and KDE

#124

Post by int_19h » Fri, Dec 13, 2019, 8:11 PM UTC

KozmoNau7 wrote: post #27

shmerl wrote: post #3

It would be good for KDE to get stronger backing, but I've heard RedHat avoids backing KDE and focuses on Gnome, due to aversion¹ to contributor agreements², is that correct in that case? 1. https://opensource.com/article/19/2/cla-problems 2. https://www.qt.io/legal-contribution-agreement-qt

I recommend the KDE neon distro to every Linux-curious person I meet. It's the latest and greatest KDE on top of an Ubuntu base, and it's by far the best desktop distro I have tried in my ~20 years of using Linux on the desktop.

How well does it integrate with non-Qt apps in terms of look and feel these days? Stuff like LibreOffice and Firefox, but also really any random Gtk app.

Re: A Better Qt Because of Open Source and KDE

#125

Post by int_19h » Fri, Dec 13, 2019, 8:14 PM UTC

laxd wrote: post #19

neilsimp1 wrote: post #7

Earlier quoted context omitted.

I'll bite. Define "better" here.

Not a fan of electron at all. But I think it points out the direction for the future of gui. There's a whole generation of new languages (rust, go, dart, D, ...) that wants to get into the gui-space and finding QT and GTK problematic. QT is known for "using every C++ feature", making it less than ideal for bindings. GTK is not very cross platform I think, and is criticized for beeing gnome-centric. Both toolkits are…

Qt seems to be quite deliberately written in a super/subset of C++ that looks a great deal like Java with smart pointers. Which, coincidentally, also makes it possible to provide language projections without having to manually adapt each and every class.