OSNews

There is Antico. But it stalled.

Yeah I was expecting something new like this would be working on Wayland already. I'm disappointed.

Not until Kwin is on wayland, RazorQt can choose window managers so when Kwin gains wayland support it shouln't be too long until RazorQt could be ported.

OK nice, can't wait for that to happen.

What, can't use the Ubuntu deb's?

That's generally a bad idea.

I run Debian too, and was able to build the desktop in a matter of about five minutes. The few dependencies are listed on the website, and the build is done through CMake, which is really quite easy.

That will be your distro of choice rather than KDE as a whole.

Case in point: on Arch Apper brings up the kdesudo dialogue as it should.

Edited 2011-12-21 10:53 UTC

That's right, Kubuntu does the same.

The other reply to your post is correct. It's a security issue. With a secure OS, you can't just go around making changes that will affect other users, security or the stability of the OS.

You could get around this restriction by doing something stupid like signing onto the box as root, then start root's desktop. You'll never be prompted for permissions again.

Edited 2011-12-21 12:14 UTC

http://www.theregister.co.uk/2006/02/24/bofh_2006_episode_8/

Real Linux users run as Root ;-)

But in all seriousness though most people when installing stuff in *nix system just trust the package manager/package maintainer and run it with elevated privileges anyway.

If the purpose of the program is to install new software it should just be given the privileges if the user is in the wheel group ... don't ya think?

Edited 2011-12-21 13:23 UTC

No. I don't think so.

Nothing is preventing you from installing applications inside of your home dir though. I do that all of the time.

Why would I want to install it to my home directory if I am part of the wheel group?

If you are in a *nix group that enables you to su to root or run sudo...and, you don't want to be limited to installing apps in your home directory....and, you don't want to be prompted to enter a password.....then, I see 1 option: log in as root.

Otherwise, how would your OS know that it is OK for you to install applications system wide to directories like /bin and /sbin, but not execute privileged commands like rm -fr /bin and rm -fr /sbin?

I'm not an expert in *nix security. I've always just accepted things for being the way they are because I give the benefit of the doubt to the kernel hackers. I trust it's all been well thought out. If you really want less security, run it less securely or run a less secure OS. Problem solved.

Sorry to say it would be simpler to build it from nothing than port old kde 1.0 code base to current qt

We have be lacking a wm to compete with KDE using the qt. Other than KDE many forms.

I'm searching for old KDE 1.x.x source code and dependancies (Qt 1.x.x and friends) across all over the web with no luck , I'm still searching.... anybody has the sources?

Edited 2011-12-21 15:42 UTC

For KDE 1.1:
http://quickgit.kde.org/?p=kdelibs.git&a=tree&hb=09f647f6958b72f68e...

And I let you as an exercice get the link for other packages... The full KDE history is in git (and for some modules still in svn) and you can get it from there.

Of course, for Qt it might be more difficult.

http://slackware.cs.utah.edu/pub/slackware/slackware-4.0/source/xap...

Slackware sources for KDE 1.1.1 and QT. As close as you can get to vanilla.

Edited 2011-12-22 10:50 UTC

That is probably part of the appeal. It certainly is for me.

It's anticipated that the transition from Qt4 to Qt5 will be much, much less painful: apparently, the vast majority of changes will still be source-compatible.

The long-term plans of Nokia (shove accelerated graphics into the hardware requirements, deprecate C++ widgets in favor of CSS+Javascript... err... I mean QML) may be a bit harder for developers to digest, though.

How is this inaccurate ?

http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/

A working OpenGL implementation will be required for Qt 5+ software to run. Knowing the fantastic performance of software OpenGL emulation and the new focus on shiny animations and touchscreen gestures, it is likely that a GPU with working drivers will be required for future Qt software to run properly. Fun times for Linux users with recent graphics hardware...

This article also explicitly states that QML + Javascript is the future, and that they expect you to only use C++ for application logic, or even not at all.

I am the first to hope that this madness will cease before it has gone too far, as I like Qt 4 as a framework and it saddens me to see it take that direction.

Edited 2011-12-21 18:04 UTC

Well the good thing about the new open source governance for qt5 is if enough people agree with you, a consensus should be able to ensure qml-declarative doesn't entirely dominate the direction.

Nokia still pays alot of committer salaries though :|

I have seen Qt5 run on top of Mesa software rendering, and the performance is great.

Including when tapping into Qt's new animation capabilities ?

I know that the QML demos of Qt 4.7 are somewhat sluggish on the Fedora 15 install of my laptop, which offers a typical example of imperfect GPU support (Dual-GPU setup in which the Intel chip works reasonably well and the NVidia chip doesn't).

My problem with that is that as outdated as pre-Sandy Bridge Intel GPUs may be, I believe they still vastly outperform Mesa OpenGL emulation on CPUs for the same period. If you know of a simple way to temporarily disable GPU acceleration on Linux, I can experimentally test this belief.

So, unless Qt 5 has vastly improved rendering performance over Qt 4, what will happen when developers will start to put pretty animated transitions everywhere in their software, as is somewhat encouraged by the QML part of the Qt SDK ?

Animated transitions are not the problem, they execute well in 2D.

Shader effect programs are prone to be problematic, and probably shouldn't be used without real hw acceleration. Luckily you can avoid using them - QML doesn't force you to add everything in your UI, even if it makes it straightforward (provided that you know how to write gl shader programs, of course).

No they are not deprecated. They are considered complete and mature by Nokia. And while it is true that Nokia is not going to take care of the maintenance, and/or of future development, if there is enough interest, developers can and will contribute. There is still a lot of interest by other companies (especially from the industrial world) to keep funding the development of the C++ widgets for years to come, and also from the KDE and open source side. Also, note that QWidgets and QML share a lot of things in common (like the graphic stack), and one of the main reason of Qt5 is to cleanly split QWidgets, QML and the common stuff.

It seems there is a misunderstanding between us about the meaning of the "deprecate" word.

For me, deprecating a feature is stating "We don't work on this feature anymore, and we expect to remove it at some point in the future, so we declare it legacy. Don't use it in any new software." Which is pretty much what Nokia did in their blog post about Qt 5 :
http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/

I'm specifically thinking about this part :

"We should expect that over time all UIs will be written in QML. JavaScript will become a first class citizen within the Qt community and we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++. The expectation is that many application developers will actually start out with QML and JavaScript and only implement functionality in C++ when required."

and this part :

"While the QWidget based classes are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML. Separating the QWidget based functionality into its own library is therefore a good measure to achieve a clean architecture in Qt 5 in the long term."

Edited 2011-12-22 08:55 UTC

As much as I like Joel, this argument is just fundamentally flawed. There's no cause-effect relationship between the internet "being big" and Firefox being big.

Different folks, different strokes.