Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Better Qt Because of Open Source and KDE

olafsw.de

Post reply on HN
Print view View original

101–110 of 125 posts

Re: A Better Qt Because of Open Source and KDE

#101

Post by Rochus »

Kelteseth wrote: post #100
Rochus wrote: post #98

Earlier quoted context omitted.

Are you aware of Dart and Flutter? I also used Qt on Android and iOS once. Won't do it again. A lot of linking, deployment and licensing issues to use something where by the end of the day I have to take care myself that it meets the platform look and feel. QML/Qt Quick was a nice idea when Nokia and others wanted to establish a common mobile platform based on the Qt framework. Today for scripting/mobile UX focussed…

Yes I am aware of the alternatives. Still having used a ton of UI libraries (Unity/Unreal/Godot/C#/QtWidgets/Flutter and web development) I would still choose QML by a landslide. My project ScreenPlay [1] (Cross plattform animated wallpaper and desktop widgets) is written 100% in QML and C++. I use the build in Material Design on desktop which works really nice with fancy animations. At work I develop a cross platfor…

Interesting. How did you solve the LGPL licencing issue? Did you have to pay a commercial licence and pay royalties to The Company?

EDIT: ok I see, your project is AGPL. But that just moves the issues to your clients; how do they solve the issue?

Re: A Better Qt Because of Open Source and KDE

#102

Post by giancarlostoro »

7thaccount wrote: post #59
giancarlostoro wrote: post #52

Earlier quoted context omitted.

Unfortunately I do not have any handy resources. I would look at some of the SQLite implementations you saw to confirm if they are just using the builtin SQLite. This seems to be mapping to SQLite code itsef instead of a more higher level driver. Edit: Did find this topic on the D forums: https://forum.dlang.org/thread/sqrkjhzafvrycgdrzlxq@forum.dl...

I found that too awhile back. Compare that with even other obscure languages like Nim and you'll see why it makes me hesitate. I really want to like D, but it is missing support for a few things I reach for often. Chicken and the egg problem.

Yeah I heard you, this is also why sometimes I just go and use Go. I think D is perfectly nice in regards to the language itself, but it could use some polish and a few minor additions.

I love that with Go I can do systems application development (think web, mail, etc). I wish D would just have a built-in web module / package. Vibe.d is nice and all, but built-in is better.

Re: A Better Qt Because of Open Source and KDE

#103

Post by Kelteseth »

Rochus wrote: post #101
Kelteseth wrote: post #100

Earlier quoted context omitted.

Yes I am aware of the alternatives. Still having used a ton of UI libraries (Unity/Unreal/Godot/C#/QtWidgets/Flutter and web development) I would still choose QML by a landslide. My project ScreenPlay [1] (Cross plattform animated wallpaper and desktop widgets) is written 100% in QML and C++. I use the build in Material Design on desktop which works really nice with fancy animations. At work I develop a cross platfor…

Interesting. How did you solve the LGPL licencing issue? Did you have to pay a commercial licence and pay royalties to The Company? EDIT: ok I see, your project is AGPL. But that just moves the issues to your clients; how do they solve the issue?

When distributing qt on android you can simply write an guide on how to decompile the apk, replace the qt .so and compile it again. I haven't done it yet so I'm not 100% sure about this. Also you could simply install ministro for this. https://doc.qt.io/qtcreator/creator-deploying-android.html

Re: A Better Qt Because of Open Source and KDE

#104

Post by de_watcher »

dev-il wrote: post #74

Sadly, I fear Digia (and its owned spin-off, the Qt Company) will be the death of Qt: Unlike Nokia, which bought Qt and opened it to a more liberal license (LGPLv2.1) because it saw it as a strategic platform basis to attract developers to its platform (that is, until the MS shill Elop was injected as Nokia's CEO and destroyed the company… and sold Qt off)… … unlike Nokia, the Digia-owned "Qt Company" (now publicly t…

Switched QtQuick 3D from LGPL to GPL?

Is that the regular license FUD or what? I don't see which 3D module you're talking about.

Re: A Better Qt Because of Open Source and KDE

#105

Post by jlarcombe »

comex wrote: post #49
mjevans wrote: post #33

Earlier quoted context omitted.

I'd like the pain-point parties (Apple, Microsoft) to just ship open-source linkable libraries of somekind in their app stores. If OSX, Windows, and the mobile stores carried a common framework developers could target it would become a defacto UI standard since you could finally develop a cross-platform app that used 'native widgets' (at least a library that might already be installed) for every given platform, and w…

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 was being developed but I think they thought better of it, so it's alive and well and still being developed.

Re: A Better Qt Because of Open Source and KDE

#106

Post by api »

pjmlp wrote: post #66
api wrote: post #63

Earlier quoted context omitted.

Its weird what people and businesses will and will not support. Businesses will shovel loads of money into SaaS and cloud hosting without blinking, but support a programming tool? Never! Another hundred Office users and 50 more AWS VMs? No problem. People will spend $10 on a coffee but would never spend $5 to support a project that saves them hundreds or thousands of hours of work. They'll spend $15/month to host a s…

Exactly, that is why you can only have nice tools when working for big corps. FOSS made it fashionable to want to be paid for work, while refusing to pay for the work of others, and in the process using clunky tools. Naturally upstream cannot pay bills from PR and eventually moves on.

I wouldn't take it that far, but IMHO the free (as in beer) part needs to be questioned at least when it comes to for-profit commercial uses of software.

I'd like software to be free and open source for people and academic or non-profit uses, but I would like it if corporations for their use if they are using them in certain ways. Particularly problematic is the use of FOSS to power closed SaaS.

ZeroTier (of which I am the founder) just adopted the BSL toward this end, but the BSL isn't perfect. I think a better sort of license and maybe one more compatible with traditional FOSS needs to be developed. I'm chatting with a few people.

Re: A Better Qt Because of Open Source and KDE

#107

Post by pjmlp »

lmm wrote: post #79
pjmlp wrote: post #14

Earlier quoted context omitted.

It all goes back to the early days of Gtk vs KDE, when Qt still had non-GPL compatible license. Red-Hat is the biggest employer of Gtk/GNOME devs, so... SuSE and Mandrake were historical the biggest ones that cared about KDE.

Right, but surely it's time to reconsider that. Qt has "caught up" on licensing, whereas to my eyes at least Gtk is still behind in terms of developer usability.

Agreed.

Re: A Better Qt Because of Open Source and KDE

#108

Post by ocornut »

dfox wrote: post #60
billsix wrote: post #56

Earlier quoted context omitted.

https://github.com/ocornut/imgui

There is essentially no way to implement modern (ie. what any user expects since Windows 95) UI toolkit as an immediate mode thing. It is not only about drawing stuff on screen and handling mostly mouse events. There are things like keyboard shortcuts, keyboard navigation, clipboard/cutbuffers/selections, automation and accessibility hooks...

I'm not sure I understand why you think there is no way to do that with an API designed in IMGUI style? IMGUI is a style of exposing UI API. There's no reason this can't be made with a IM-style UI.

You are comparing apple and oranges when comparing the feature set of a small UI system made by 1 person-ish vs something like Qt benefiting from decades of experiences and hundreds of devs.

Re: A Better Qt Because of Open Source and KDE

#109

Post by dev-il »

Nokinside wrote: post #99
dev-il wrote: post #89

Earlier quoted context omitted.

> Qt use is increasing and it shows in the number of buying customers. As if that was of any relevance to the question whether many Qt developers are switching. Given that commercial licenses are only used by a very small minority of the professional developers using Qt (most using open source Qt), themselves only a subset of all developers using Qt… the fact that that small minority is currently increasing while rem…

Your QT losing users is still unsubstantiated. Developers stop using Qt for good technical reasons in projects that don't require the unique features of Qt. Qt's strength is being multiplatform. It works in embedded and realtime operating systems. It's not even useful for scrape by contract workers who do better with free web framework/UI stuff. Your TV, car, Television, have Qt in them. Its in medical devices and in…

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 that, you'll notice that those are Domains that account for a small minority of embedded… and a very unrepresentative one in that TVs, cars and TVs, unlike most of the embedded market, are stuff that are built by big corporations. So yeah, QTCOM seems to just focus on those big fish only now, as opposed to Nokia's strategy. As for industrial automation: don't make me laugh. Qt is totally irrelevant there.

And yes, licensing problems ARE a good reason which is a sore point, ESPECIALLY in embedded (where in most use cases you can't just dynamically link for LGPLv3 like on a desktop but have the whole mess of the build chain and update management if you are to let the user replace the Qt version).

Re: A Better Qt Because of Open Source and KDE

#110

Post by secretsatan »

Rochus wrote: post #98
Kelteseth wrote: post #97

Earlier quoted context omitted.

Nope as a QML developer 5.14 is bare minimum because of the many changes like proper 4k scaling support, Splitview, Table support, way better Android build, usable Qt3d and many quality of life improvements.

Are you aware of Dart and Flutter? I also used Qt on Android and iOS once. Won't do it again. A lot of linking, deployment and licensing issues to use something where by the end of the day I have to take care myself that it meets the platform look and feel. QML/Qt Quick was a nice idea when Nokia and others wanted to establish a common mobile platform based on the Qt framework. Today for scripting/mobile UX focussed…

We're working on a cross platform mobile app rn and we're using QT because "everyone else in the company is using it". It might be good for desktop, but I've found it to be nothing less than frustrating, it reinvents the wheel for mobile, and doesn't do it very well. It's still missing many features, we still have to keep going back to native views to implement things because QT just can't do certain things. We've lost developers because they want to work with mobile technologies and QT seems like 10 steps back. Swift and Kotlin address many issues of cpp, we don't have access to the wide amount of mobile libraries. We replace things with cpp libraries never compiled for ARM that ends up with incredible amounts of code that would take a few lines in native. Every library we add brings more headaches. And then we have desktop developers diving in and designing everything like it's desktop, button and menus too small, scaling the view to fit different device sizes. ugh
Post reply on HN