In this week's KDE Commit-Digest: Image support in Parley, and support for formulas in the note feature of the Step physics simulation package. blinKen changes capitalisation to Blinken for the KDE 4.0 release. Theme work across kdegames, with better collision detection in Kolf. More XMP integration work in Digikam. Work on KConfig merged back into trunk/. Colour conversion system becomes fully operational in Krita. Continued work on the port of the Kickoff menu to KDE 4, initial work on a centred-button menu in Raptor. KIOFuse, the KIOSlave filesystem bridge, starts to be ported to KDE 4. An uncertain future for the Klipper applet in KDE 4.0, compared to its KDE 3.x form.
Dot Categories:
Comments
It seems that Qt 4.4 will be much more memory efficient because of the "invasion by aliens" (http://labs.trolltech.com/blogs/2007/08/09/qt-invaded-by-aliens-the-end-...). Besides it probably will be release before the KDE 4.0 final release.
So, does KDE4 developers intend to use it, since it would be nice to see KDE4 using less memory?
Thanx for the good work. It really rocks.
Bráulio
> it probably will be release before the KDE 4.0 final release
not likely. KDE 4.0 is set for december and Qt 4.4 is set for Q1 of next year.
that doesn't mean that you couldn't compile it with qt 4.4 when it comes out and get those improvements for free.
So this means that many main distributions, most of which just have had a release (suse, mandriva) or are going to do one (Ubuntu, Fedora) will probably use Qt 4.4...
As far as Fedora is concerned, even if Qt 4.4 misses Fedora 9, it will almost certainly be pushed out as an update. It's backwards source and binary compatible, so why wouldn't we push the update?
PS: It will most likely end up in all releases supported at that time, even. For example, Qt 4.3 was pushed all the way down to Fedora 5.
Does anyone know? will you really be able to run KDE 4 in the Linux frame buffer without X11 running at all?? I saw a video on youtube to that effect.
there was some early work on this; essentially kde4 compiles with Qt/E and apps do run but there are a number of remaining Qt/E-specific feature/bugs in kde that need continued work.
Is this project alive?
I've only run KDE 4 off LiveCDs so far, and running off a disc is not a great way to gauge performance, but from what I've heard thus far, KDE 4 is a little slower and slightly less responsive than 3.5.7
I know 3.5.7 is a very well polished release, and KDE 4 is a beta, but I thought QT 4 was going to bring speed and memory improvements to the table.
Are the speed issues related to added features (such as Plasma), the lack of polish in such a new refactoring of the code, or perhaps these are "debug" builds, and not nearly as optimized as they can be?
I'm curious how the KDE 4.0 release builds should compare to 3.5.7 (or 3.5.8 by that point) in terms of responsiveness?
this is impossible to answer this without actual numbers, so as to know what is being measured, how it is measured and the actual differences. it's just too vague a question as stated.
personally, i find it faster in many regards though the immense amounts of debug output does slow some things down right now.
I've heard nothing but bad things about the state of Qt4's resource consumption compared to that of Qt3 (at least from programmers not affiliated with Trolltech/ KDE), and this includes people writing release builds of software on Windows. Resizing of windows/ re-layouting of widgets is one thing that seems to be particularly slower. All KDE4 apps I've tried use more memory that their KDE3 counterparts (measured as RES minus SHR to counteract the fact that the code is swollen with debug code), *and* they seem to use more X-server resources too, leading to significantly higher net usage (presumably due to caching of pixmaps for double-buffering; I don't know).
The "KDE4 will use much less memory than KDE3!" spiel was mostly given before KDE4 was even running properly, so I'd take it with a pinch of salt.
Things like alpha-blending and other fancy effects are very fast, though :)
Get latest skype or any other Qt4 app and judge by yourself,
don't believe to liars.
... For the records, I am not affiliated with either Trolltech or KDE, and I have only good things to say about Qt4 (with perhaps the single exception of non-windowless child widgets, which is already fixed in trunk). Really, really badass fast and lightweight.
Which doesn't mean much about KDE 4.0 itself, however, seeing as lots of new (and as such not as well tested) technology has been created for it, I'll gladly grant you that.
I'm not too worried, though. KDE 3 was already so crazy light you could run it fine on a computer two generations old, so even if the first few revisions of KDE 4 aren't as optimized yet, there's still a lot of leeway until it actually becomes bad. Time will tell.
To me all Qt4 apps I use (mathematical programs, Skype, etc., non-KDE stuff) are as fast as other Qt3/KDE 3.x apps I have. So I can't follow your judgement.
But the best would be to post real benchmarks, maybe you've found a nasty bug which should better be fixed?
In any way, regarding speed improvements/problems of Qt4 there was already a highly interesting thread going on at the dot some years back:
http://dot.kde.org/1135084395/1135109572/
It is worth a read and sheds some light why in some situations Qt4 can be "slower" than former Qt3 applications (it's X' fault, not Qt's fault :) ).
And thats why we want KDE 4 running on Linux frame buffer.
Qt/KDE running on the linux framebuffer sounds like no accelerated graphics like on the x server, no (x-server) nvidia/ati drivers, no games.. - is that correct or does it work another way? Care to explain?
I can't of course, just wishful thinking.
Dreams of small and fast, like eXPerience33's TinyXP.
Or MicroXP with the Evil desktop.
Thats where the competition is, not with Vista or OSX.
I've had a discussion about this with Zack (and others) and their point was: when you do exactly the same with Qt4 compared to Qt3, generally speaking you can expect it to be (much) faster.
Yet, nobody does the same with Qt4 - see Oxygen, which is much heavier yet compared to plastik. See all the animations in Qt4 (have you tried KDE 4 yet? it's chockful of subtle animations, like when drag'n'dropping dockers, selecting stuff, etc). Those will undoubtedly suck CPU, no matter how much more efficient Qt4 is. And another thing is of course the fact KDE has just been ported to Qt 4, apps don\t use it very efficient yet. I'm pretty confident there still is a lot low hanging fruit in the optimization area. KDE 4.1 might really turn out to be a big thing: actually taking advantage of all new architectural stuff, inclusion of the things which wheren't ready for 4.0, AND optimizations and a better Qt ;-)
So, KDE 4, and esp 4.0, will use more resources than KDE 3. Yes, it sucks. But you GET more as well, and there are probably ways to lower the resource usage - choosing Plastik as theme, turning off effects (no idea if you can turn off the Qt effects, btw).
Could one of the devs please say how easy it is to cut back on animations and other eye candy if you wish to go lightweight?
> yet? it's chockful of subtle animations, like when drag'n'dropping dockers, selecting stuff, etc).
Uhgh - hopefully it's possible to disable this crap in KDE 4.0. There isn't a lot I do hate more than superfluous animations for the sake of animation (buy a game console for this purpose, please!), eating cpu cycles, causing the cpu frequency to raise unnecessarily.
Well the animations aren't there just for the sake of animations. Animations are very helpful to better illustrate changes in the user interface, and guide the user between transitions. Read up on visual momentum, it's very interesting. http://www.google.de/search?q=visual+momentum&ie=UTF-8&oe=UTF-8
That said there is definitely a need for an "off" switch as you said.
Ok, same "Anon" here, and the comments sound very promising to me, so I have high hopes for the future :)
Can someone from TT weigh in on how the double-buffering works, though? I note that I can drag a window over another window in Qt4 and, as opposed to Qt3, I no longer get the terrible "sheering" and "trails" left behind. I'm not sure how this could be accomplished short of caching the entirety of each window so that, as another window moves over it, the bits just "re-exposed" can be *instantly* "redrawn" (I'm ignoring X hardware compositing as I don't think that's the mechanism used, as the same smooth effect can be seen in a Xephyr session), but surely having every single window cached in this way would gobble up a large amount of X-server memory, increasing the total memory used by running Qt4 apps, even when the apps themselves take less memory? Especially when a window is maximised on a high-resolution screen. Or is there some other TT-magic employed here? :)
A full screen 1280x1024 window is 3.75MB (5.00MB if you do 32-bit alignment / use an alpha channel). That isn't really that much in this day and age.
Compix/AIGLX basically do the same thing for every window, except I believe they use video RAM instead. Windows draw to off-screen buffers in video RAM, and those buffers get composited to the screen every frame via the 3D pipeline (which isn't really taxing at all for today's video cards).
"A full screen 1280x1024 window is 3.75MB (5.00MB if you do 32-bit alignment / use an alpha channel). That isn't really that much in this day and age."
But it would be more than in Qt3 which (presumably) doesn't use this method. Hence my concern about whether Qt4 really is more lightweight than Qt3 - kwrite would end up gobbling up *twice as much RAM* using Qt4 than Qt3!
Well I am a Qt4 developer working on Windows, not affiliated with KDE or Trolltech, and I have no complaints about the performance. At the moment, it does seem a little slow on Linux compared to Qt3 though. Hard to judge though, since I always run debug builds of my stuff.
The Raptor link is pointing to a wallpaper currently.
Is there anyplace I can see what Raptor is going to look like, or how it might function?
Also, in varying screenshots I've seen thus far, it seems the Plasma widgets have this beautiful, simple glass border/frame. Yet the normal window decorations in KWin have been fairly typical/traditional.
I'm curious if there was any consideration for the Oxygen theme to have window decorations closely related to those beautiful borders on the Plasma widgets. Wouldn't it make the entire desktop more consistent (not to mention breathtaking)?
http://pinheiro-kde.blogspot.com/2007/10/raptor-join-fun.html
Some mockups were posted, I do hope those mockups come to life. Looks minimal yet provides everything you need.
I love it. Looks great!
Man, I am just full of comments and questions today. I apologize.
I don't want to start a flame-fest on Kickoff, as we have had in the past. As far as I'm concerned, I'm a proponent of choice. I enjoy that today we can use KMenu, KBFX or Kickoff and I assume we will have options in the future.
I know Kickoff is supposed to be well-researched, and the description in the digest keeps mentioning how it is supposedly designed to allow users to navigate quicker.
Personally I find Kickoff to be visually pleasing, but I find it slows me down considerably. The "favorites" pane (akin to pinned entries in the Windows menu) might provide quick access to a small number of apps, but if there are 4 apps or so you use that frequent, I usually pin an icon to a panel, or use a dock with some shortcuts. People might also just put icons on their desktop.
Navigating to Kickoff, and then your favorites seems like an extra step to me. And if I want to navigate the full menu, I click through layers of the menu, which transitions a little slow for my taste.
The traditional KMenu isn't pretty, but it is quite fast.
I'm hoping that we might be able to configure/alter the speed of Kickoff. Perhaps there exists a method today that I'm not aware of?
> The traditional KMenu isn't pretty, but it is quite fast.
for those of us who have gotten used to it and are good with such lists, it can be fast for certain types of functions. however, it's hardly optimal for most people and many tasks. this is what makes things like kickoff a net win.
that said, *what* exactly do you find slower (exact use cases, so i'm not thinking you're saying A but you're really saying B) and can you measure the speed differences so we have some numbers?
this is also pretty much completely the wrong place to discuss these things; [email protected] would probably be a lot more sane.
Let's say I want to play a game.
When using Kickoff (which I switched away from and haven't used in a while) I believe, it opened with a favorites tab, and I had to switch to my programs tab, which involves a click, and a pause.
Then I click and pause on the Games menu.
Then I click and pause on a subcategory, like Card Games.
Then I click on the program.
Personally, I don't think I'm the target user for the app. Most of the time, I just hit Alt+F2 and type the app name. Kickoff was the app that frankly drove me away from using menus in general. However, I'm excited to try out Raptor in the future.
What I'd *really* like to see is something like the traditional Kmenu but editable in place, like, hold a meta key and drag and drop entries with the LMB and RMB opens a small dialog to edit, copy, new and remove an entry etc.
The main problem with the traditonal heirarchical menu is the godawful default layouts offered by most distros. Once the menus are customised and streamlined for the particular end user they are very convenient and fast to use. So some equally easy and fast method of modifying Kmenu options makes the most sense to me... and some way for newly installed packages to respect the USERS grouping, ie; I use separate Audio and Video menu folders but new A/V apps insist on being dumped in some stupid Multimedia folder. I guess that's a matter for XDG standards but the easier it is for this end user to customize these things the happier he'll be.
AMEN!
I second this.
Like in Windows? In the start menu in Windows (at least the XP I have to use frequently because of my printer) you can drag items around. However, it is designed awfully, with dialog boxes when you move items which are shown to all users.
That said, I am not using a KMenu or Kickoff any more. I have removed the button from my panel. Therefore, only Alt-F2 or F12 for Yakuake can be used to invoke commands or start programs. That is the perfect protection against Windows users. ;-)
> Like in Windows?
Really! I use XP occasionally and had no idea one could move the Start menu items around from within the Start menu itself. I'm impressed and now interested to reboot to see how good, or badly, it's implemented.
(To anyone) If in my wildest dreams I could learn how to hack on KDE4, where would I best start to try and implement (or reimplement from scratch) a self-editing Kmenu? Is there a Qt4 list/view widget that would be a good example to start from (gentle, total novice here)?
Question: Why not simply use the search feature in kickoff? You can type in the name of the game or the executable. Then press Enter. It's a built-in Run Command + Search...
If I don't know the name of the executable, then I need to search for it. But quickly I learn the names of all the programs I use.
Typing the name of the application is enough, you don't have to necessarily know the name of the executable.
"Typing the name of the application" is impossible, if you do not know it either.
However, you could just type "game", and all applications which are somehow associated with "game" will show up.
do you realy think this is faster than just clicking on "games" for most users!?
In the google-age, yeah, I definitely think that writing "games" is quickier than visually scan a menu with 20+ submenus.
Except for people with disabilities like missing fingers, and people like me, who hate to type when I don't have to. I shouldn't have to type when opening programs. I customize the kmenu with categories where all my programs are only one layer deep. I'll put my program-opening speed up against anybody that types program names into kickoff. Unless they have three hands...
Ha. With a good system (unfortunately I haven't found one yet on Linux.. Launchy is the best for Windows), I can launch an application before you can even display the start menu. Alt-Space-F-Enter. Takes a fraction of a second and launches Firefox, or Alt-Space-Sp-Enter launching Speedcrunch. There is no way you can be faster than that kind of interaction with a mouse based approach.
Also, the disability card is a misnomer. If you look at alternative input devices, most of them emulate a keyboard at some point, and providing efficient keyboard based navigation is crucial for people with many types of disabilities.
>> unfortunately I haven't found one yet on Linux
Alt+F2 in KDE or maybe Katapult?
>> I can launch an application before you can even display the start menu.
When I know the name of the applications, I often use Katapult/Alt+F2 to start it. But sometimes I just want to see what I've installed, and maybe find a new game; in these cases, I prefer the old KMenu to Kickoff's navigation system. (Note: I haven't used the latter one very much, thos could be because I'm simply used to the old menu system.)
I'll take on either! Katapult is cool, but I find that the search finds too many similarly-spelled commands. Especially in KDE where the habit of naming everything with a "K" hasn't been completely shaken yet.
True. Opening "Konqueror", for example, was a pain in the "old" Katapult.
Ryan Bitanga has started a Katapult fork named "Katapult Fast Track", you can find it here: http://kde-apps.org/content/show.php/Katapult-Fast+Track?content=60941
There are some great new features, such as
* Support for multiple results (Press up or down keys to see more results)
* Adaptive search
However, there are some issues; random crashes etc. Also, be sure to delete your old katapultrc after upgrade.
Cool, thanks for the link. Hope they stabilize it. This might be what I'm looking for. Of course, if krunner turns out as I initially proposed it, we won't need katapult anymore.
>> Alt+F2 in KDE or maybe Katapult?
Sorry, neither of those are nearly as good as launchy. The run dialog doesn't know about application names, and katapult doesn't learn, and doesn't provide alternate options, and can't run apps not in the k menu easily.
I'm not against a regular menu, but for the rare time when I want to browse my apps, kickoff is just fine. I don't see myself being much slower with it. It avoids the annoyance of nested popup menus, which are a pain with innacurate trackpads.
Maybe not faster in a one-application contest. But now lets open a bunch of randomly-selected applications in succession. That means you have to memorize a bunch of multi-key combinations (more than 60 on my system). Yuck. If you do have all those memorized, I humbly bow to your superiority :-)