Submitted by Gtk+ has GNOME on the one hand, and Xfce on the other. Qt, on the other hand, only has KDE – there’s no lightweight, less encompassing alternative if KDE doesn’t float your boat, but you’d still want a Qt desktop. Luckily for you, there’s now Razor-qt, a small, lightweight and simple Qt desktop environment.
Razor-qt is not an entire desktop environment in the sense that KDE and GNOME are; most important, it is supposed to worked with an existing window manager. The Razor-qt developers prefer Openbox, but it can work with everything else, from Kwin to fvwm. For the rest, Razor-qt consists of modules, and you can mix and match them to suit your needs.
“Razor-qt is an advanced, easy-to-use, and fast desktop environment based on Qt technologies,” the project website reads, “It has been tailored for users who value simplicity, speed, and an intuitive interface. Unlike most desktop environments, Razor-qt also works fine with weak machines.”
Since it’s a relatively new open source project, they’re also looking for help. “Razor-qt is a new open-source project and you can help us improve it. We welcome your bug reports and suggestions; you are free to translate all into your own language, create more attractive graphics, anything,” the team states.
This is a very interesting project, and I’d love for it to pick up more steam. It’s pretty easy to get it running on your Linux installation, so get cracking!
Looks neat except for the pizza cutter logo.
it’ll look awesome on my FreeBSD netbook!
It kind of looks like a bastard child of Xfce & KDE. I like it.
It’s not bad. Runs well so far.
Simple and out-of-the way.
I love QT (and the old KDE3) but the new KDE4, while it is great in some areas, is getting in my hair a bit.
I couldn’t welcome this project more. Will definitely look to contribute if I ever get time to.
Surprised nothing like this has popped up earlier, actually.
Bring it on!
There is Antico. But it stalled.
How about Razor-qt + QT + Wayland then? Bleeding edge.
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.
I run Debian and it seems that there are no packages available for it. I assume this means I would have to compile the entire desktop myself to get it to work. Yay.
No thanks, I’ll wait until either I switch distributions or a Debian package is made.
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.
Everything I have seen about Qt I like.
KDE is a nice desktop, but the developers don’t tend to fix the important bugs, just the ones they feel they have to.
Lots of ibus integration bugs in 4.7. I wish they would fix them, but probably won’t because they are adding more features to 4.8.
I wish they would freeze the version for one year and just kill the bugs and I think KDE would be great for the average person.
Another Qt based desktop is something I think is a great idea!
-Hack
Just wish they would fix permissions on their package management software so you don’t have to launch if from sudo in terminal.
That aside, after looking at alternatives, KDE for now is my choice on Linux.
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.
I’m interested in this qt-razor. It might be just what I want. KDE is huge but there are some KDE apps that I like. I’m gonna try it out.
Reminds me KDE version 1. Why not port this version to new QT framework?
http://www.kde.org/screenshots/kde1shots.php
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.
Sounds a tiny bit like Qt-LXDE. I hope this will spawn more standalone Qt-appications. There seem to be a lot more Gtk+ ones, than Qt.
Btw., I have no experience on this, but the transition from Qt3 to Qt4 didn’t seem to be too easy (at least I remember some complaints ’bout that). Does anyone know how Qt4 to Qt5 is/will be.
Edited 2011-12-21 11:24 UTC
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
Is there a Qt mail client, like Claws-Mail but is more independent of KDE than KMail?
I have been using Trinity Desktop which is an excellent fork of KDE3.5 and I can tell you now I am extremely happy with its look and performance + I can run KDE4 apps on top of TDE. For instance, I installed Kolour Paint — both the KDE3 and KDE4 versions. Another KDE4 app I installed was KGet. My favorite feature in TDE is everything but especially the quick launch applet on the very flexible panel. One thing I like about TDE is the whole integration. So far I have been able to drag any icon from any toolkit (tried Fox, GTK, DE4, XUL) into the quick launch. The whole desktop environment is very quick and responsive. The T menu has a search box and there are many other improvements…
Edited 2011-12-22 12:21 UTC
http://www.joelonsoftware.com/articles/fog0000000020.html
“Convenient though it would be if it were true, Mozilla [Netscape 1.0] is not big because it’s full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. But being a shining jewel of perfection was not a goal when we wrote Mozilla.”
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.