Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

jrepin wrote in with a link to an article about the steps being taken toward a Qt5 based KDE 5 and Plasma Workspaces 2. From the article: "KDE's Next Generation user interfaces will run on top of Qt5. On Linux, they will run atop Wayland or Xorg as display server. The user interfaces move away from widget-based X11 rendering to OpenGL. Monolithic libraries are being split up, inter-dependencies removed, and portability and dependencies cut by stronger modularization. For users, this means higher quality graphics, more organic user interfaces and availability of applications on a wider range of devices. Developers will find an extensive archive of high-quality, libraries and solutions on top of Qt."

Yeah, I think this is a fair question. I like having the pretty widgets on my desktop machine, but when I want a graphical interface on a server it has to be XFCE - everything else is too heavyweight to run well over a remote protocol like VNC or XRDP (which I understand just wraps VNC, but I didn't do a deep exploration of how it works).

I know it would be potentially a lot more work, but it would be easier if KDE and GNOME and Ubuntu Unity had a fallback 2D mode that was friendly for remote viewers.

K Desktop Environment. Servers really aren't their primary target. Also what can't you do for your server via a Bash login or other remote management protocol for a minuscule fraction of resources? What really requires a full on GUI desktop environment on your server? There might be some niche need for it, sure, but mostly I tend to think you're doing something wrong.

When I started at this job we ran everything off Windows Servers, and our admins had learned to use Windows Server back before Microsoft had anything like PowerShell, so they were expert clickmonkeys that only occasionally resorted to cmd.exe.

I tried to sell them on Linux without X as a superior replacement, but I couldn't get any interest from the rest of the team. I set up a Linux server with XFCE and XRDP, the program menu in the bottom left, the clock in the bottom right, a taskbar, icons on the d

I know it has Windows binaries. We were using it on Windows first, and once I could show them that it's effectively identical on Linux it was easy to make the switch.

At a big company with lots of resources, we could just take the Windows team and send them to training with the edict "adapt to the changes or be replaced". But this is a very small company, and just as importantly these people are pleasant to work with and intelligent. Even if I had the resources and authority to steamroll changes in plac

KDE 4.0 was missing a lot of expected 3.5 features, but a lot of the bad reputation it received were from terrible Kubuntu packages. The Kubuntu maintainers admitted they didn't understand the new build process or what they were doing. Canonical pushed it way too early and pushed crappy packages, but KDE took the blame. Early KDE builds on openSUSE, Arch, Fedora, etc. didn't have the same problems.

And honestly, I think only a year later (KDE 4.2) they had a great desktop for everyone.

The shift from KDE 3 to 4 (and Qt 3 to 4) meant a massive rewrite, and having to reinvent most of their core features.

KDE 5 sounds more like an evolution than revolution, so it should be smoother this time around.

This is pretty much on the mark, though it wasn't just the Kubuntu/Ubuntu camp that screwed up their KDE migration. KDE 4.0 and 4.1 were clearly alpha releases, neither stable nor feature complete. They weren't mean to be, they were developer previews. Yet many distributions migrated overnight without any thought to how that would affect the users. Kubuntu certainly made the mistake, Fedora did too. I think the SUSE developers were among the few to offer both the 3.5 and 4.x desktops side by side during the

I care that it is much harder to configure. I care that the taskbar didn't work as well as 3.5 until I finally gave up and went back to Windows. Remember Kaskbar? Square Icons with a preview of the window. Exactly like Windows 7 before Windows 7. I'm positive that MS stole it from KDE. Could I figure out how to replicate it in KDE for the first couple of years? Nope. Finally give up? Yup. And have you ever looked at the bug reports on the auto-hide panels? Ugh, especially with dual monitor.

So should I use the one that isn't stable or the one that isn't found (404)?

I am more than leery or using extensions as part of my core _anything_. Gnome Tweak means you don't have it. KDE plasmoids on kde-look means you don't have it. And this is an example of why, the software you gave a link to no longer exists.

I love that people are arguing that KDE 4 is missing a "core feature" that was actually a third-party add-on for KDE 3, but at the same time argue that installing a plasmoid means the feature doesn't really exist.

KDE 4 was designed to be extendable, and supports multiple methods of easily installing plasmoids. Installing content from the internet into KDE 4 was a core underlying technology since 2008.

If I still ran Linux, was on KDE 4.2 and trusted extensions maybe this would have minimized the pain. However, as I pointed out that this was far from my only gripe about KDE 4. I don't really want the Windows 7 Taskbar, I want Kasbar (which was included in base so please lets drop that entire it was 3rd party crap please). I dislike AutoHide, I liked the arrows or the option where it would drop behind the active window and reshow when the mouse was thrown in the corner. I liked the window decorations and o

KDE 4.0 was missing a lot of expected 3.5 features, but a lot of the bad reputation it received were from terrible Kubuntu packages.

KDE 4.10 is still missing a lot of expected 3.5 features. I'm sure it's much closer to feature parity now (I'm assuming you can finally manage your system-level wireless connections in KDE, maybe fonts in KOffice even use decent kerning), but go back to KDE 3.5 and just look at the printing system. Seriously, just look at all of the things you can do to a printed document. Now look at the KDE4 one. Maybe KDE5 will fix this...

I made it until at least 4.3 and probably 4.4 before I gave up and went back to Windows. And this is from someone who hadn't used Windows in 4 years. KDE 4.2 was didn't hold a candle to KDE 3.5 for me.

I made it until at least 4.3 and probably 4.4 before I gave up and went back to Windows. And this is from someone who hadn't used Windows in 4 years. KDE 4.2 was didn't hold a candle to KDE 3.5 for me.

I stuck with 3.5.10 until 4.4 on some systems and 4.5 on others. But I haven't looked back.

Honestly, I looked at 4.0 through 4.3 from time to time but kept seeing that they were not production ready, and KDE themselves didn't call them production ready either - especially 4.0 and 4.1.

I was using Mandriva at the time and I can assure the early KDE 4 releases were just as unusable. I can't see how it was the fault of the Kubuntu maintiners, KDE 4.0-4.2 was half-baked, alpha quality software, full stop.

Luckily it's improved out of sight since then, but it's a worry that the KDE developers still don't acknowledge their mistake in releasing those early versions as releases, and not alphas or betas. I really hope they don't make the same mistake with KDE5.

If that means that developers are more free to break with conventional UI's and come up with their own "innovative" controls and other UI interfaces, I don't want that - that sounds like when Flash designers started going wild on the web and each Flash web site had its own UI elements and the users had to figure out that flipping a virtual switch on one website was implemented as shooting an arrow into a target on another website and on another website you had to click the virtual LED light that was actually a button (but you don't know it's an active UI element until you discover that it's clickable).

it's supposed to mean that the interfaces spring up from genuine need for functionality at a certain place, not from some UI nazi deciding that all file dialogs shall be purple and have ability for previewing web pages.

An organic user interface means that the mouse is furry and the keyboard moans when you hit the "right" key, and when X is booted you'll be presented with the "operating system host" which is a Blender rendered ent that only take entish spoken commands (like Unity); the system will turn itself off at 8pm to sleep untilsunrise, and often not be responsive when there are other virtual events requiring system resources, like floods and firestorms.

KDE devs: Please do not screw up Kmail more than it already is. In fact, please put serious thought into restoring the good old filesystem-based folder database and just do away with that horrible Akonadi mistake that is dog slow, when it works at all. Running critical apps on top of a full blown database may look like a good idea on a Presenter slide, but in reality it is just cruel and unusual punishment.

I know this isn't strticly related to Qt5, but just try to keep it in mind ok? Thxbai.

Man, I totally agree with you. I've used Kmail since KDE2 and despite its flaws, I generally liked it better than the alternatives (and I've tried many). It's always annoyed me that while there are several GTK email clients, the KDE desktop really only has kmail, and they royally screwed the pooch with all this akonadi crap.

I don't think that the database is the problem. The problem is that Akonadi is about as decent, code- and design-wise, as aRts was. Long on promise, short on delivery -- designed and implemented by people who demonstrably don't have enough software engineering experience. College kids may be bright and hard working, but that's no substitute for a certain amount of experience and understanding of the engineering side of things. Just look at this software engineering "recommendation" [kde.org] to give the idea what's w

It's certainly part of the problem. The database may be fast, but it isn't anywhere near as fast as the underlying filesystem. And you are right, the basic design flaws are compounded by very obvious inexperience at designing and developing multitasking applications.

Huh? The database isn't there just to store data. It offers indexing, structured queries, etc. Usually, when people implement that functionality on top of a filesystem, it ends up as a yet another me-too half baked "database". It's like with any sufficiently large software project having half-baked LISP functionality in it:)

Huh? The database isn't there just to store data. It offers indexing, structured queries, etc. Usually, when people implement that functionality on top of a filesystem, it ends up as a yet another me-too half baked "database"...

You sum up perfectly why this idea looks so good on a Presenter slide. Never mind that the reality sucks. Because in real life, the database is a whole lot slower than the filesystem and introduces a lot of new boundary conditions that tend to completely overshadow the shiny new functionality introduced. Sorry, but there's a big gap between the way you imagine the the universe, and how it actually is. You'd have done well on Bill Gate's Vista design team. Entirely designed on Powerpoint slides I understand.

You're crazy if you think MySql is somehow underpowered for Akonadi. It's not the problem. The problem is with how Akonadi's details were engineered, and how it was executed. If you seriously think a mainstream database is too slow to do relatively simple indexed queries on a *personal* email/contact database, you're crazy. The database is not a problem. That's about the only design decision I agree with. The filesystem does not offer the data indexing and querying functionality that you need in an email ap

I'm a database guy so this hurts to write. JWZ wrote an email client. It worked. Netscape decided to switch to a database. It didn't work. JWZ wrote about it in addition to his line that: "To a database person, every nail looks like a thumb. Or something like that."
http://www.jwz.org/doc/mailsum.html [jwz.org]

I'll second this. That said, I'd settle for the ability to reply to HTML emails without totalling the formatting, given that it's pretty much the only reason that I have to use an alternative these days.

(Not sure if this is fixed in a later version - I'm on Debian, so I'm still using 4.4 because of the feature freeze.)

Reduction of duplication with Qt by removing classes and using their Qt alternatives

A lot of classes were rewritten way back in the day when the licensing of Qt was under fire. Once those issues went away there really wasn't much point in continuing the duplication of effort. Bringing the two back together is long overdue. In the long run it could bring greater stability to KDE applications since more developers will be working on improving the same framework instead of two independent but close frameworks. This is good for both Qt and KDE.

Ummm... this isn't correct. KDE developers never had a problem with the licensing of any of Qt classes. What this is referring to here is that either 1) something was written in KDE that wasn't available in Qt and Qt has since added support for it - might as well use the Qt version, or 2) a Qt class was extended with a KDE version to add extra functionality and Qt has added the functionality or the functionality is deemed not important enough for an extension.

Ummm... this isn't correct. KDE developers never had a problem with the licensing of any of Qt classes.

Not the Qt licensing per se, but a lot of KDE developers have problems with the Qt contribution agreement. In order to support Qt Commercial etc. you essentially have to sign away all rights to the code, here's perhaps the most relevant part:

Subject to the terms and conditions of this Agreement, Licensor hereby grants, in exchange for good and valuable consideration, the receipt and sufficiency of which is hereby acknowledged, to Digia a sublicensable, irrevocable, perpetual, worldwide, non-exclusive, royalty-free and fully paid-up copyright and trade secret license to reproduce, adapt, translate, modify, and prepare derivative works of, publicly display, publicly perform, sublicense, make available and distribute Licensor Contribution(s) and any derivative works thereof under license terms of Digiaâ(TM)s choosing including any Open Source Software license.

As a result, a lot of code in the KDE libraries that could ideally could have been enhancements to Qt instead (both being LGPL) have remained outside Qt and will most likely remain so. Reducing the duplication has been a stated goal for ages but in reality not much happ

You've missed the non-exclusive part, for one. You're not signing away all rights to the code. Just the rights enumerated above. You can do with your code as you please, and they can do with their copy as they please as well, within the limits of non-exclusivity! You're not losing any rights to your own code! You can, for example, publish it under a license of your choice -- if the code is not a Qt-derived work in the meaning of copyright law. So, if it's not a derived work, you can publish it under BSD, or

True, you keep a slither of positive control in that you can still release it under the licenses you want, but you can't stop your code being used anywhere under any circumstances in any form since the license grant is pretty much limitless. Not exclusively so, but limitless all the same. I'll give you one Hermes Conrad point for being technically correct, though.

Qt licensing has continuously became less restrictive over the years. That fact alone surely has to have had some impact on where KDE libraries went. As I understand it there has always been this top down limitation where Qt changes (while they may have gotten their inspiration from KDE) always came from the Trolltech/Nokia side. The inability to mingle in the upstream (which wasn't helped any by the controversy and confusion in licensing) is what brought about the duplication of effort.

How awesome! When I'm working with a spreadsheet I always wish it was more organic instead of just a boring old grid. I think I would be way more productive if it were organic.

And yeah, I'm sure we've all been there - you go to click a button or type into a form and notice how the graphics quality is so low - it's like they don't know that I have BluRay on my computer or something, even though VLC is installed and can do 1080p.