Slashdot Mirror
KDE Releases Frameworks 5 Tech Preview
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.
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).
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?
Ezekiel 23:20
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.
"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? ;)
Use slow, sloppy javascript (or javascript-like) and HTML to create big, serious-work desktop applications? Sincerely, fuck you.
Religion: The greatest weapon of mass destruction of all time
Pro tip: When someone does something retarded on the internet, don't point and claim responsibility.
What a Kool Desktop Environment.
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
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.
... 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.
When all you have is a hammer, every problem starts to look like a thumb.
Well... You, as any human, have the same flaw: The "8 or 80 rule".
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.
And hell yes, javascript is sloppy. In the sense that lack basic things like well-defined strings, integers, good error control, etc. Sure, you can use it to do usefull things, but only if you can afford the big overhead penalty. This is more or less acceptable on a medium-sized "web application", but absolutely not in a big/complex desktop application.
Religion: The greatest weapon of mass destruction of all time
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, and you're NOT using it as your desktop? Even though that seems to be what you're asking for?
Ezekiel 23:20