KDE Releases Frameworks 5 Tech Preview 51
KDE Community writes "The KDE Community is proud to announce a Tech Preview of KDE Frameworks 5. Frameworks 5 is the result of almost three years of work to plan, modularize, review and port the set of libraries previously known as KDElibs or KDE Platform 4 into a set of Qt Addons with well-defined dependencies and abilities, ready for Qt 5. This gives the Qt ecosystem a powerful set of drop-in libraries providing additional functionality for a wide variety of tasks and platforms, based on over 15 years of KDE experience in building applications. Today, all the Frameworks are available in Tech Preview mode; a final release is planned for the first half of 2014. Some Tech Preview addons (notably KArchive and Threadweaver) are more mature than others at this time."
Check out that dependency graph.
Ideal dependency graph (DAG) (Score:3)
That dependency graph is beautiful.
I wish gcc had a --fno-circular-dependencies flag to force that on a codebase (much like go does in the language spec).
Re: (Score:3)
That dependency graph is beautiful.
Agreed, I'm now kompletely konvinced of their eventual success.
Re: (Score:2)
Unfortunately Go doesn't have any modular/plugin system (other than source.) The FFI is better now with C++, and I'm sure we'll get dynamic loading eventually. The whole KDE framework is predicated on shared libs, services and plugins. I like Go but making a platform like KDE in Go would be impossible.
Re:Backwardness of KDE continues (Score:4, Insightful)
To make an analogy, cars didn't exactly put railways out of business. Good luck trying to convince companies like Autodesk to port their humongous applications for specialists to radically different environments just because a /. AC wants them to.
True innovation would be to provide a script-based approach to most of the GUI stuff, e.g. nodejs/browser API - essentially drop the entire QT/GTK mess (you had your chance, and failed), and replace it with WebKit and JavaScript engine, and then provide native code layer to provide an interface for computational demanding stuff.
Also, did you notice that that Qt QML and Qt Quick are already heading in the direction you've just outlined?
Re: (Score:1)
OP here, will take a look on QML and Quick as you mentioned, didn't know about it, yes, perhaps I am not up-to-date of what's going on in KDE, I just look at the results after 15 years fiddling around and copying a bad "Windows" concept (yes, Microsoft's Windows).
I wonder why so much manpower are wasted into Qt/GTK and those apps using it when, when we essentially could have WebKit render all controls (css/html/js) and connect with some solid computational C++/C libraries to do the real work. And why it tak
Re: (Score:3)
The only thing which truly works for me is the Debian/Ubuntu package system, and so I use it for server applications, but for desktop: NO. And I write most of my software now for browser (html5/js/webgl) and do the heavy lifting on a server: multi-platform via browser layer.
So, let me get this straight...you're heavily HTML5-desktop-apps-oriented, you're developing them yourself, you're using the one Linux distro that natively supports HTML5 apps on its desktop [ubuntu.com], and you're NOT using it as your desktop? Even though that seems to be what you're asking for?
Re: (Score:2)
Re: (Score:3)
and then provide native code layer to provide an interface for computational demanding stuff.
Well, they are moving in that direction with QML. For many apps, a native UI makes perfect sense. Not only if the UI is very demanding, but also when the UI is very simple: staying in one programming language keeps things simple.
Re: (Score:2)
Re:Backwardness of KDE continues (Score:5, Informative)
"True innovation would be to provide a script-based approach to most of the GUI stuff, e.g. nodejs/browser API .. and then provide native code layer"
We started working on exactly that ~5 years ago and the result is QML2 and Plasma (two separate things, but they work wonderfully together). As the node.js project founder said when he saw QML for the first time: "Wow, it's HTML5 done right."
So KDE is truly innovative, you're just too uninformed to have known and ~5 years too late to the suggestion table. (I'm not entirely sure how the /. smarminess works, but I gave it my best try with that last sentence .. did I succeed? ;)
Re: Backwardness of KDE continues (Score:2)
Re:Backwardness of KDE continues (Score:5, Informative)
Re: (Score:1)
Use slow, sloppy javascript (or javascript-like) and HTML to create big, serious-work desktop applications? Sincerely, fuck you.
Figures from a guy with "Religion is the greatest weapon of mass destruction of all time" as his signature. Frankly not surprising that someone who uses "religion" in the all-popularly vague manner and attributes it to all evil then goes on to be unappreciative:
Obviously there are a lot of potential (potential--repeat, potential) advantages and disadvantages to their approach. Of course, the work being done here means KDE is not so much simply a Desktop anymore rather than a giant set of resources design
Re: (Score:3)
Read again, you put a very big response for... well, nothing. The VERY BIG problem with using internet tech (javascript, HTML, DOM, etc etc) to do local desktop things is ridiculously simple:
Performance. Memory usage, CPU cycles, the usual. You can do a vmware-like thing on Javascript? Sure, why not? But... Will be fast or will have low memory usage? Hell no. And he will need a browser, more memory and more CPU time needed to do the job
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Yes, this is why KDE has been so successful?! KDE is the worst example of GUI/Desktop for Linux. I used it for years, I upgraded constantly, the greetings screen got animated, nice icons, but the functionality, the overall user experience sucked - and I kept silent, because I wanted it to succeed, as Open Source advocate - until the failure could no longer be denied: 15 years for coming up with this non-sense and announced at /.?
In my experience this is, unfortunately, basically true. I was a big fan of KDE back in the 3.x days (even donated money). Then KDE 4 happened in 2008. I've only just got back onto the bandwagon. In other words, it's taken over 5 years before it got to the stage when I felt I could use it again. TBH, there are still issues with it. Little things like the slow animations in the The K-menu and the top right desktop menu are quite annoying. The nepomuk stuff kills performance and needs disabling. There's not
Re: (Score:1)
> Something has to run your beautiful JavaScript and this something is written in C++, is immensely complex and often buggy.
What is buggy, anything written in C++, like KDE or only JavaScript? (When you make up arguments, think them through first)
JavaScript engines are buggy, HTML rendering is buggy, browsers are buggy, software in general is buggy. Just because you decide to write stuff in JS won't isolate you from bugs in other parts of your system.
> Might as well skip this intermediary and write your application directly in C++ using Qt.
Yes, this is why KDE has been so successful?! KDE is the worst example of GUI/Desktop for Linux. I used it for years, I upgraded constantly, the greetings screen got animated, nice icons, but the functionality, the overall user experience sucked - and I kept silent, because I wanted it to succeed, as Open Source advocate - until the failure could no longer be denied: 15 years for coming up with this non-sense and announced at /.?
KDE hasn't failed - lots of people use it, it's one of the major Linux (and BSD etc) Desktop Environments. I personally love KDE. I liked KDE3, not so much KDE 4.0 (released too early), but starting with KDE 4.1 it's been a smooth sailing - it's fast, configurable and very nice looking. I wouldn't take
Re: (Score:2)
That's how Firefox works - the core engine is C++, and that of course includes the Javascript interpreter, but the UI is then done with Javascript and XML, to keep the C++ as small as possible. Likewise the EmacsLisp in Emacs does all of the heavy lifting,
Re: (Score:1)
Re: (Score:2)
But further, we're in an incredible Javascript performance war. Ten years ago well-written Javascript was routinely over a hundred times slower and a hundred times less memory efficient than well-written C or C++. Today, the difference in speed or memory is rarely a factor of twent
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Re:Backwardness of KDE continues (Score:4, Interesting)
Your "script-based approach" eventually calls something. Ie if your script has "put a movie here" it does not magically work without a *lot* of code that deals with actually getting a movie from where it is stored, converting it's storage into a form that your eyes can see, and placing it on the screen with proper sync. This stuff does not magically exist because you have a "script-based approach". This sounds a lot like it is providing these things.
Writing Qt apps is getting pretty close to scripting, and in many cases you are running parsers and interpreters. Often this will reduce code size and thus increase speed over C++. Also lots of Qt is written in Python. I don't know much about it but I think QtQuick is pretty much another interpreter and they are planning on moving everything to it.
Re: (Score:2)
Re: (Score:3)
Pro tip: When someone does something retarded on the internet, don't point and claim responsibility.
Re: (Score:2)
The real summary about KDE Framework 5... (Score:1)
Re:The real summary about KDE Framework 5... (Score:4, Informative)
... is the idea of load as few as possible libraries to run a KDE application in a non KDE environment.
No, that's not it. The purpose is to break useful functionality out of KDE and make it available to QT developers in general without requiring KDE itself. The benefit to KDE is, it prepares the ground for migration to QT 5, cleans things up, and enables the possibility of contributions to the framework components by non-KDE developers. Or in other words, whatever is good for QT it good for KDE.
All I can say is (Score:4)
What a Kool Desktop Environment.
Re: (Score:2)
I admire the attempt at consistency with the K everywhere. Well, sort of. The commentary below doesn't apply to necessarily to this specific release or grouping of work. I also concede that it's time spent and in some cases money. Further, I admit that many will actually like it.
I'm probably not one of them. I order regular coffee and have it black. I don't get the Frappe/Crape or whatever stuff gets put in.
But really, I'm getting older. I don't want to learn someone's new paradigm for user interface