Announcement

Collapse
No announcement yet.

KWinFT Projects Hit Beta Ahead Of Stable Releases Aligned With KDE Plasma 5.20

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    bug77
    Senior Member

  • bug77
    replied
    Originally posted by angrypie View Post

    Did you just ignore a legitimate concern to make a stupid, unfunny joke? Qt is very much in power to lock KDE out whenever they want. Might be just a matter of time.
    How would Qt do that with the source code readily available and GPL licensed?

    Leave a comment:

  • angrypie
    Senior Member

  • angrypie
    replied
    Originally posted by JackLilhammers View Post

    Yeah, sure, that makes perfect sense.
    But why stopping at Kde? There are many other projects that need True Freedom™!
    Let's rewrite everything written in Qt with a better and truly free toolkit!
    Do you have any suggestions?
    Did you just ignore a legitimate concern to make a stupid, unfunny joke? Qt is very much in power to lock KDE out whenever they want. Might be just a matter of time.

    Leave a comment:

  • JackLilhammers
    Senior Member

  • JackLilhammers
    replied
    I tried to use it because it's interesting, but Qt seems easier and cleaner.
    Also CopperSpice has no python bindings

    Leave a comment:

  • Mario Junior
    Senior Member

  • Mario Junior
    replied
    KDE developers BTFO!

    Leave a comment:

  • d4ddi0
    Phoronix Member

  • d4ddi0
    replied
    Originally posted by JackLilhammers View Post

    Yeah, sure, that makes perfect sense.
    But why stopping at Kde? There are many other projects that need True Freedom™!
    Let's rewrite everything written in Qt with a better and truly free toolkit!
    Do you have any suggestions?
    https://www.copperspice.com/
    https://www.copperspice.com/docs/cs_.../timeline.html

    Leave a comment:

  • JackLilhammers
    Senior Member

  • JackLilhammers
    replied
    Originally posted by Alexmitter View Post

    De-cute-ing should be the main focus for KDE in their next version. The more they depend on Qt, the easier is it for the greedy Qt company to pressurize them into making changes to this already very weak contract that are purely in the favour of the Qt company.


    But the actual sad story is that the GPL failed to protect freedom here. It relies too heavy on the idea that a re-licensing is nearly impossible if multiple people own the code in one project. But as the Qt company only accepts contributions if the owner gives full rights to the Qt company, and the KDE people being fully happy with that creates the situation where the Qt company is not just able to re-license community contributed code under their greedy proprietary license but also be in the position that it can stop releasing GPL versions. KDE e.v. could then re-license what was GPL to whatever they like but would be cut off from all the progress made after that.

    It was a bad idea to stick with Qt after the 4 years of them refusing to even consider the GPL. Back then would have been the best chance to switch to a FLOSS and better tool kit what would be harder but is still 100% necessary today.
    Yeah, sure, that makes perfect sense.
    But why stopping at Kde? There are many other projects that need True Freedom™!
    Let's rewrite everything written in Qt with a better and truly free toolkit!
    Do you have any suggestions?

    Leave a comment:

  • Alexmitter
    Senior Member

  • Alexmitter
    replied
    Originally posted by 144Hz View Post
    tildearrow
    Senior Member
    tildearrow I’m cheering any de-cute effort.
    De-cute-ing should be the main focus for KDE in their next version. The more they depend on Qt, the easier is it for the greedy Qt company to pressurize them into making changes to this already very weak contract that are purely in the favour of the Qt company.


    But the actual sad story is that the GPL failed to protect freedom here. It relies too heavy on the idea that a re-licensing is nearly impossible if multiple people own the code in one project. But as the Qt company only accepts contributions if the owner gives full rights to the Qt company, and the KDE people being fully happy with that creates the situation where the Qt company is not just able to re-license community contributed code under their greedy proprietary license but also be in the position that it can stop releasing GPL versions. KDE e.v. could then re-license what was GPL to whatever they like but would be cut off from all the progress made after that.

    It was a bad idea to stick with Qt after the 4 years of them refusing to even consider the GPL. Back then would have been the best chance to switch to a FLOSS and better tool kit what would be harder but is still 100% necessary today.

    Leave a comment:

  • carewolf
    Senior Member

  • carewolf
    replied
    Originally posted by shmerl View Post

    I think it branched out in too many places. And when it's trying to reinvent the wheel from libstdc++ - that's not good. And I'm not convinced that it's actually better. It's using rather ancient approach to code design. Modern C++ is far ahead already.
    Branched out? It is where it started! It is older than C++98, back then there was no reliable standard library, they were different between every platforms, so a cross platform toolkit's job was to offer a consistent alternative. As time goes by more and and more can be let go, though there are still key difference that still make some Qt classes very useful even with standard alternatives. Especially QString is not an std::string replacement and can't be replaced by it, QByteArray is the std::string equivalent. The container classes are mostly just copy-on-write versions of the standard library classes these days, I think in Qt6 QMap just wraps an std::map with CoW semantics and superior Qt syntax.

    Besides the standard library is way too primitive for a GUI toolkit. The majority of Qt has no standard library equivalents.

    Leave a comment:

  • miabrahams
    Phoronix Member

  • miabrahams
    replied
    Impressed by romang's drive to tackle this. Curious to try it out sometime!

    Leave a comment:

  • JackLilhammers
    Senior Member

  • JackLilhammers
    replied
    Originally posted by shmerl View Post

    I think it branched out in too many places. And when it's trying to reinvent the wheel from libstdc++ - that's not good. And I'm not convinced that it's actually better. It's using rather ancient approach to code design. Modern C++ is far ahead already.

    Either way, for high level language I'd go with Rust over C++ if there is a choice and I'd go for libstdc++ over Qt analogs otherwise.
    I agree that reimplementing libstdc++ is not the best of ideas, but Qt is old and when it came out C++ was way different.
    I mean, Qt is older than boost and just 1 year younger than STL.
    Qt 6 will be based on C++17, so hopefully much stuff will use more modern C++.

    I don't know KWin's code, so I can't say if it would be better off in pure C++. I think it really depends on the specific case

    Leave a comment:

Working...
X