Am I the only one that finds it weird that a document like this, that basically shouldn't care about layout, and is very unlikely to be printed by anyone (except maybe the author himself), would be distributed as a .pdf?
A Better Qt Because of Open Source and KDE
51–60 of 125 posts
Re: A Better Qt Because of Open Source and KDE
#52Earlier quoted context omitted.
That might be why honestly. https://dlang.org/phobos/etc_c_sqlite3.html For anybody's reference, it also has zlib, and an ODBC library.
Is there a page on how to use it? Thanks for the link!
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...
Re: A Better Qt Because of Open Source and KDE
#53> In case The Qt Company would ever attempt to close down Open Source Qt, the foundation is entitled to publish Qt under the BSD license. This notable legal guarantee strengthens Qt. It creates trust among developers, contributors and customers. Woah, I had no idea about this. I wonder what kind of new changes would take place if Qt were BSD licensed, such as languages like D embedding it as a solution for UIs as par…
Qt is massive , I doubt small communities would rush to integrate it and make it their job to maintain it all... I doubt anyone in OSS communities is seriously deterred from using Qt because of the LGPL. It’s just a very big and very complex project that requires a lot of manpower to “tame”.
Already happened: https://www.copperspice.com
Re: A Better Qt Because of Open Source and KDE
#54Re: A Better Qt Because of Open Source and KDE
#55The behavior of the Qt company lately is a bit troubling.
First, the core can be licensed under Commercial or LGPL licensing. This let's non-paying developers use the core in commercial software. This policy was established to ensure trust with the community during one of the many company transitions. For all new modules, Qt evades that requirement by licensing under Commercial or GPL. I have mixed feelings on this.
Second and more importantly, they have started sending aggressive audit letters to customers. I guess that makes sense from a bean-counter point of view where you poke the customer and try to get them to buy more licenses either because the customer actually needs the licenses, or because the customer is afraid to let any dev work without paying protection money. This is a huge pain in the neck for me as a paying customer. They even sent the aggressive audit letter to an old license we have that had not been renewed (or used) in around a decade.
I'll definitely be rethinking my relationship as a customer when the next renewal comes up.
Re: A Better Qt Because of Open Source and KDE
#56Earlier quoted context omitted.
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…
That more seems like there's a hole in the market for a better gui.
Re: A Better Qt Because of Open Source and KDE
#57The behavior of the Qt company lately is a bit troubling. First, the core can be licensed under Commercial or LGPL licensing. This let's non-paying developers use the core in commercial software. This policy was established to ensure trust with the community during one of the many company transitions. For all new modules, Qt evades that requirement by licensing under Commercial or GPL. I have mixed feelings on this.…
> commercial software
I think (could be wrong) you meant to imply closed-source, as one can have commercial open-source software.
I’m not a huge fan of them using GPL for their newer modules, either, like charts. It seemed a bit unnecessary other than driving those who don’t like/can’t use the GPL license into a dev subscription.
Re: A Better Qt Because of Open Source and KDE
#58A better Qt already exists. It's called Electron.
Irony: Electron is based on Blink. Blink is derived from WebKit. WebKit is derived from KDE's KHTML. KHTML was written against Qt APIs, and many of the original KHTML authors overlap the set of Qt authors. Electron is a competitor Qt begat. :-)
Re: A Better Qt Because of Open Source and KDE
#59Earlier quoted context omitted.
Is there a page on how to use it? Thanks for the link!
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.
Re: A Better Qt Because of Open Source and KDE
#60Earlier quoted context omitted.
That more seems like there's a hole in the market for a better gui.
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...