Slash Boxes

SoylentNews is people

posted by Fnord666 on Thursday January 07 2021, @01:21AM   Printer-friendly
from the shooting-yourself-in-the-foot dept.

Open-source contributors say they'll pull out of Qt as LTS release goes commercial-only:

The Qt Company has followed up on its plan to make long-term support releases commercial-only by closing the source for 5.15 today, earning protests from open-source contributors who say that the 6.0 release, which remains open, is not yet usable.

[...] Yesterday senior VP Tuukka Turunen posted: "With Qt 6.0.0 released and the first patch release (Qt 6.0.1) coming soon, it is time to enter the commercial-only LTS phase for Qt 5.15 LTS. All the existing 5.15 branches remain publicly visible, but they are closed for new commits (and cherry-picks)... closing happens tomorrow, 5th January 2021.

"After this the cherry-picks go to another repository that will be available only for the commercial license holders... first commercial-only Qt 5.15.3 LTS patch release is planned to be released in February."

[...] The problem is that these releases are in effect no longer maintained. If there is a security issue, or a fix needed to support some change in one of the target operating systems, open-source users will not get that fix other than in the not-ready version 6.0.

Open-source contributor Thiago Macieira, an Intel software architect, said of the decision: "That means I will not be participating in the development of those fixes, commenting on what's appropriate or not, reviewing backports, or bug reports."

"Tend to agree," said Konstantin Ritt, another developer. "If there is a decision to close 5.15 sources, there'll be no more work from external/unpaid contributors."

Turunen responded that: "This is well understandable and expected. The Qt Company is prepared to handle the Qt 5.15 LTS phase work."

Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by chromas on Friday January 08 2021, @02:47AM (1 child)

    by chromas (34) Subscriber Badge on Friday January 08 2021, @02:47AM (#1096817) Journal

    Remember KDE4 affair?

    The only thing I remember is they ported KDE to Qt4 (KDE 3.80) then threw away all their effort to start all over, making the desktop a Windows Vista-style widget soup featuring retarded technologieses like Strigi and Akonadi (which is still broken even today). I don't blame Qt for that. Perhaps the abused became the abuser.


    Well there's this [].

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 4, Informative) by tangomargarine on Friday January 08 2021, @06:45AM

    by tangomargarine (667) on Friday January 08 2021, @06:45AM (#1096916)

    Just going to drop this bit here

    An interesting topic is layouts. A layout (except for box layout which is actually a widget for some reason) is a definition of a collection of GUI elements written in some forsaken language. You create those files, put widget definitions inside them, compile with custom compiler (edje_cc) and use the resulting file. This leads to some problems, unknown to the sane world. For example, a layout is immutable. You make it, you stick with it. That immutability is pretty far reaching. If you place an image in a layout, you not only cannot move the image widget anywhere, but you also cannot do anything with the image data itself. The author recognized this can be a problem, especially when all competing libraries offer dynamic modification of widget layouts. An obvious solution would be making layouts dynamic, but it’s not the EFL way. Instead you can add a pseudo-element to the layout called SWALLOW (given the previous error messages, I suspect the author designed EFL while watching Redtube). This SWALLOW can them be substituted by a real widget. Therefore, if you want your layout to be truly dynamic, make a bunch of SWALLOWs in the layout which makes it extremely readable. The compiler is also worthy of noting. It always returns exit code 0, even when it fails. Have fun designing a build system with EFL in mind. This is especially entertaining when you have a previously compiled version of a layout – it gets silently used and you’re left with hours of debugging why is nothing changing on screen.

    In typical lovecraftian C fashion, EFL disregards any notion of memory ownership. It frees some data you pour into it, and it doesn’t free other. Which is which? You’ll only know when your process crashes on double free. Or when your memory fills up. Or never.

    One example of this memory mismanagement is a thing called a Genlist. It in essence is a list widget with some items. It has a special “feature” – it deletes items when they go out of view and allocates memory for them when they get into view. Make a quick swipe on such list on your mobile device and you can actually hear your RAM scream in agony.

    Those times when you're not sure whether you should laugh or cry

    "Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"