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.

Comments

Great work

[Anonymous Coward]

Laying the groundwork for another 15 years.

Ideal dependency graph (DAG)

[ustolemyname]

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:Ideal dependency graph (DAG)

[K. S. Kyosuke]

That dependency graph is beautiful.

Agreed, I'm now kompletely konvinced of their eventual success.

Re:Ideal dependency graph (DAG)

[Anonymous Coward]

"Agreed, I'm now kompletely konvinced of their eventual sucksess."
There - ficksed it for ya...

Re:Ideal dependency graph (DAG)

[mounthood]

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.

Backwardness of KDE continues

[Anonymous Coward]

KDE tried to copy Windows XP (it should have aspired OSX GUI) and went nowhere for the last 15 years. GNOME alike disaster.

Who develops GUI in a compiled environment anymore? KDE, "Frameworks 5 is the result of almost three years of work", instead a few months script coding.

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.

 

Re:Backwardness of KDE continues

[K. S. Kyosuke]

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:Backwardness of KDE continues

[darkHanzz]

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:Backwardness of KDE continues

[stilborne]

"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

[TheDarkMaster]

Use slow, sloppy javascript (or javascript-like) and HTML to create big, serious-work desktop applications? Sincerely, fuck you.

Re:Backwardness of KDE continues

[spitzak]

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:Backwardness of KDE continues

[Anonymous Coward]

WebKit and JavaScript engine

Right. Because every GUI app should allocate half a gig just to start.

Re: Backwardness of KDE continues

[techprophet]

More or less

Re:Backwardness of KDE continues

[Anonymous Coward]

Oh, welcome to the 21st century! I believe you'll love our new JavaScript engines.

Re:Backwardness of KDE continues

[infinitelink]

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 designs precisely for accessibility: with each one being modularized, documented, and made ready to be called by any other app it means KDE is becoming more and more unix-like while also empowering less and less knowledgeable people without as much commitment of time to write and port and leverage applications and code.

I mean, though we all hate it, look at the explosion of apps and developments that took place when people realized they could use the COM object of IE and other Windows' parts in application, avoiding reimplementation and getting on to useful work: it does mean I'm still stuck--after years--with IE security/cert errors while using my work applications despite it pulling data over secured channels, yet my company's engineers did not have to rewrite a ton of functionality and then build a program to maintain the code.

KDE seems to be thinking far ahead: even if/when KDE the desktop becomes useless, its code should live-on: imagine Microsoft converting all its code into a set of plugins for its development frameworks: still assembled and offered as the Windows desktop and widely available as such a program, but useable for any other. I'm not even a programmer (I started in high school, got zapped for cancer, lost a lot of memory) and I think this rocks: it's open thinking, "hey use our stuff for whatever you need--we'll even make it really easy for you!" If only companies did this with their offerings. (Ask a giant like Oracle or Cisco some time about "hey we'd just like to use these functions rather than entire-system-sold"and see what happens.)

As for Javascript-like scripting...Javascript isn't sloppy: Javascript has a whole lot that Java and other serious languages lack. Javascript has advantages and disadvantages just as they do. And Javascript may or may not be written sloppily: with work like this, you can drop-in your own replacement if KDE provides a set of scripts that suck: one of the ideals for information in computing is the ability to transform the State of a system at will with a few lines of input or set of codes, and work like this only work to advance us nearer.

Re:Backwardness of KDE continues

[TheDarkMaster]

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.

Re:Backwardness of KDE continues

[Anonymous Coward]

OP here, you separate the lightweight GUI part from the computational demanding stuff, as I wrote. The point is, most KDE apps suck big time, and the entire GUI is clumsy, when talking to developers they say it's hard to code "easy to use" . . . why? Because they compile verbose C++ sources and huge complicate libraries only a few people can take advantage of, and those are terrible user interface designers - to do the most trivial things. There isn't a single KDE app which convinces me, none. GNOME is a bit better, but the simplicity there is pushed too far (too hard to add "Expert" setup).

> Use slow, sloppy javascript (or javascript-like) and HTML to create big, serious-work desktop applications?

My reply: Google Docs.

> Sincerely, fuck you.

Very good argument.

Re:Backwardness of KDE continues

[xfizik]

Something has to run your beautiful JavaScript and this something is written in C++, is immensely complex and often buggy. Might as well skip this intermediary and write your application directly in C++ using Qt. P.S. If you "are not even a programmer", I don't see how you have enough expertise to make such broad conclusions about programming subjects.

Re:Backwardness of KDE continues

[Anonymous Coward]

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 takes years to come up something "heading in the direction" I just outlined. This is an example where Open Source does not work: it is slow (taking years, not months) and still behind for years what otherwise is state-of-the-art. I ran Linux & FreeBSD with KDE for years, until I was fed up, and after years tried it (KDE & GNOME) again and saw essentially no progress at all, but new refactored libraries doing the same things still as bad as years before: a complete waste of manpower and innovative focus.

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. Is this so hard to convey to KDE/GNOME developers?

Re:Backwardness of KDE continues

[Anonymous Coward]

> staying in one programming language keeps things simple.

Are you sure? If it were so, why do most KDE apps look like they were written by people who never use their own programs (non-intuitive typical programmer like but not user oriented)?

Re:Backwardness of KDE continues

[Anonymous Coward]

> 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)

> 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 /.?

You people here laugh about the IE disaster (css/js/html compliance or the lack thereof) of Microsoft, but look at KDE first, and tell me that 15 years brought this kind of GUI, a copy of Windows XP, in the year 2014?

> P.S. If you "are not even a programmer", I don't see how you have enough expertise to make such broad conclusions about programming subjects.

People like you are coding Qt/Gtk with technology 10 years old, with the X11 concept in mind (it was once great, but it's time to let it go, and with it all the libraries which relate to it); I programmed apps with X11 when Gtk was wishful thinking, and one had to allocate colors before doing anything else.

Re:Backwardness of KDE continues

[Sri Ramkrishna]

What do you think GNOME Shell is?

Re:Backwardness of KDE continues

[Sri Ramkrishna]

We'll be off of X in a year completely.

Re:Backwardness of KDE continues

[K. S. Kyosuke]

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?

Re:Backwardness of KDE continues

[Sudline]

That is what Microsoft want to do with the Modern UI in Windows 8.

Re:Backwardness of KDE continues

[Anonymous Coward]

Ha!

Re:Backwardness of KDE continues

[Barsteward]

i fucking hate browser based apps so i don't want all shit in (css/html/js). You write all your software for the browser so you have a vested interest. KDE/GNOME are going the correct way as far as I'm concerned as the work flow thru web pages is shit.

Re:Backwardness of KDE continues

[Barsteward]

"why do most KDE apps look like they were written by people who never use their own programs" - i'd say the same for browser based apps

Re:Backwardness of KDE continues

[Barsteward]

"The point is, most KDE apps suck big time, and the entire GUI is clumsy," more fucking crap vapourware arguments

Re:Backwardness of KDE continues

[Anonymous Coward]

Vapourware? KDE, indeed. 15 years fiddling around and still not delivering. If KDE were so great, why hardly one uses it?

Re:Backwardness of KDE continues

[Anonymous Coward]

You are missing the point like most of the KDE/Qt developers here, the GUI is script based, the actual computational work you can do in C++ or whatever. You have an event loop and handle the GUI events, whatever needs to be done you delegate underneath. By no means you define the GUI in a compiled manner - the results are ugly, non-intuitive frontends, because nobody improves it because it's terrible complicate (I was told so by KDE developers). Most of you are operating based on outdated and backward GUI concepts - and so most KDE apps look bad, yet the functionality behind carries a lot of thought, the presentation nulls all the fine work behind: nobody uses the app, hardly any significant numbers of KDE at all, even worse, KDE failure adds significantly to Linux failure on the desktop. This is why I rant, because this backwardness has impact for the entire Linux desktop failure.

Re:Backwardness of KDE continues

[umafuckit]

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 much desktop plasmoid selection and plenty of them don't work properly or at all.

As I recall, when KDE 4 was first announced there were a lot of grand statements about reinventing the desktop, etc, etc. But never any specific details about how this was to be done. Obviously they didn't know either. From my perspective, it seemed that the whole KDE 4 thing was a badly thought through refactoring exercise that led to years of regression and yielded only cosmetic tweaks (some of which are also regressions). I really want to like it, but the UI needs streamlining and the whole thing needs to be better documented and better presented.

Re:Backwardness of KDE continues

[DuckDodgers]

C++ is incredibly powerful and incredibly necessary, but it's so much harder to use well than Java, Javascript, Python, etc.... that the smart thing to do is restrict your C++ to the smallest possible subset of your application you need it to manage.

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, but the EmacsLisp interpreter itself is written in C. They could write the whole editor in C and leave EmacsLisp strictly for user scripting, but it made more sense to restrict the C code because it's harder to get it to work properly than EmacsLisp.

Re:Backwardness of KDE continues

[xfizik]

> 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 any other desktop - not Mac, not Windows, and certainly not Gnome of any kind. Although, I do (have to) use Windows at work, I installed KDE for Windows and use some of its apps (e.g. Kate, Kwrite) as replacements for whatever is available on Windows.

People like you are coding Qt/Gtk with technology 10 years old, with the X11 concept in mind (it was once great, but it's time to let it go, and with it all the libraries which relate to it); I programmed apps with X11 when Gtk was wishful thinking, and one had to allocate colors before doing anything else.

OK, I get it - you're a dinosaur programming-wise, and you can't even comprehend that things evolve, that programming in Qt is not the same it was 10-15 years ago (or whenever you last wrote your hello world program).

Re:Backwardness of KDE continues

[xfizik]

You have to understand that C++ is not intended for average programmers. Yes, it's harder, but people fluent in C++ are usually very good developers. For everybody else there are bindings in scripting languages. You don't expect novice programmers to work on KDE's core, do you? And C++ is not required for writing plasmoids or some simple apps.

Re:Backwardness of KDE continues

[DuckDodgers]

Even with excellent developers, it's better to restrict your use of harder tools to where their use is necessary. All other things being equal, smaller codebases are easier to maintain and easier to audit for security flaws.

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 twenty and is often less than ten, and that's not even counting Mozilla's asm.js project. For an awful lot of applications, that performance hit is worthwhile.

Re:Backwardness of KDE continues

[xfizik]

I don't argue with that, but one has to be realistic. There is a perfect way of writing perfect software in a perfect world and there is present reality where you have a number of developers proficient with certain tools (languages) that have particular interests in doing things their in a certain way. This is especially important in the open source community - when you are not paid to do something, you don't have to do it if it is not fun. Suppose, the KDE team (and I'm just guessing) has a number of really good C++ developers which are not as good with JavaScript, which is not so uncommon. Should they write stuff in JS? Probably not. On the other hand, using Qt gives them "scripting" for no cost - you can do C++, you can do QtQuick, you can do QML - whichever you are most comfortable with.
To summarize, in practice you have to get things done with the resources you have at your disposal - if you have a bunch of C++ developers, naturally you'll be getting a lot of things done in C++, but in the case of KDE you always have your options provided by Qt.

Re:Backwardness of KDE continues

[DuckDodgers]

Excellent point, definitely. I agree. But I will note that I haven't attended any open source software enthusiast gatherings, yet. It's on my to-do list. The lone KDE developer I did meet was a big fan of C++ and Javascript, so he could switch back and forth easily. Take that as a statistical sampling of one. :)

Re:Backwardness of KDE continues

[Anonymous Coward]

Google Docs suck ass

GNOME kills KDE

[Anonymous Coward]

I'm Honton and I'd like to point you to this thread.

http://phoronix.com/forums/showthread.php?84448-Gnome-kills-KDE

Re:GNOME kills KDE

[ustolemyname]

Pro tip: When someone does something retarded on the internet, don't point and claim responsibility.

Re:GNOME kills KDE

[Barsteward]

Nice one.. +1. its the old "best be thought a fool rather than opening mouth (or typing) to prove it"

The real summary about KDE Framework 5...

[Parker Lewis]

... is the idea of load as few as possible libraries to run a KDE application in a non KDE environment.

Re:The real summary about KDE Framework 5...

[Tough Love]

... 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

[hduff]

What a Kool Desktop Environment.

Re:All I can say is

[MrBoring]

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 interfaces. I don't care if it looks like Windows with enhancements. Sue me for liking some things about Windows. At least they were consistent. I like that release after release, the same Window D command brings me to the desktop (I don't know about Win 8).

Coming up with new "skins", tabs just irritates me. What I really want is a windowing system that's fast, and doesn't get in my way. When I tell it to go to the desktop, I want it NOW, and not spend time thrashing the hard drive trying to get to it. Same thing with the run command. Really, I don't need all these things as a user. Dammit stop it already. If you're working on KDE trying to change everything again for the 15th time in hopes that the world will all switch over to Linux and your own flavor of windowing manager, just give up. Let it be. Use your developer talents on something that really improves computing for people. Make the computer do something it hasn't before.

Oh, and whatever you do, stop trying to make it slower and more complicated. Did anyone ever hear of that simplicity concept? Bear in mind, this does not have to be run like an IBM product. You do not need to rewrite all your widgets in some bastard dujour's Javascript library on top of some javascript engine which then dynamically compiles the widget into something native only to be displayed 10 minutes later. Honestly, if you ran software from 10-15 years ago, much of it would be faster on today's machines.

In case you're wondering, I run Ubuntu at home and use Windows at work. I just try to make everything come as close to the old "Start Me Up" Windows paradigm. Yes, it's old. But so was the song even when Bill Gates used it for Win 95. Just because something is old does not mean it should be replaced. There should be a reason, and, unless this is for the sake of art, that reason should be practical or at least logical.

I still want to continue using Linux along with a decent window manager, though mostly for the command line capabilities. I just don't want to learn something new unless it's going to give me more time away from the computer.

Re:JavaScript or C++

[Anonymous Coward]

It is getting competitive Google Docs vs MS Office!

Re:Learn JavaScript

[Anonymous Coward]

Or H1-B will outcompete you in JavaScript/node.js then!

Which KDE SC Version?

[Anonymous Coward]

Kontact and KMail are very stable since 4.10 here. Which Distro?