In this week's KDE Commit-Digest: A whole set of bugfixes and feature additions in Plasma, and various optimisations across KDE. Usability improvements in Blinken. More work on the timeline tool, including fuzzy selection in Digikam. Support for XComposite translucency in the Konsole KPart. QtScript can now deal transparently with all scripting backends supported by Kross. Improvements in KWin Composite effects. Support for an old feature request, "parenthesis highlighting as an expression" in Kate. Continued interface work in the KHotNewStuff2 library. Progress in the Bonjour protocol implementation in Kopete. Support for stroke gradients, and adding and removing rows, columns and cells in the new Table Flake shape in KOffice. Initial import of kio-giobridge, a bridge interface between the KDE and GNOME I/O methods. Work is resumed on the CIA Plasma applet. A Luna Plasmoid (moon phase display) is added to KDE SVN. Dragon Player (formerly Codeine) is moved from playground/multimedia to kdereview, with a view to moving into kdemultimedia for KDE 4.1. The KDE 4 version of Yakuake, essentially a rewrite, is imported into KDE SVN. Read the rest of the Digest here.
Comments
Thanks Danny, you're the man.
And KWin is awesome in KDE4.0. Even in this early state, it works a lot better for me than compiz ever did (even recent versions). It makes way more sense to add composite support to a window manager that is actually smart than try to put the smart into compiz.
I have the opposite experience (Compiz was quite smooth, KWin incredibly jerky) but I have faith in the KWin developers that it will improve quickly. They also seem to have a better sense of what "effects" are useful (e.g. the keyboard filtering in Present Windows).
Could it be that you have a nVidia card and are having driver issues? I had the same problem with my nVidia care but after applying a so-called Hack (that was mentioned here) and doing a few adjustments in the xorg.conf file the effects are now very smooth.
On the other hand I can't get Compiz-Fusion to run with Xorg on KDE 4.0. It seems to need XGL, which KDE 4.0 seems to be allergic to. I also have problems with Kaffeine when using Compiz-Fusion.
Can you point us to the hacks you made? Please :)
KWin release notes for KDE4.0, see the right section : http://techbase.kde.org/Projects/KWin/4.0-release-notes . I don't know if there are any other possible improvements, so I don't know what those few adjustements could be, but I can add more if people tell me them.
Written by Marcel Partap in thread The Start of Something Amazing:
(attention: put 'export KWIN_NVIDIA_HACK=1' in your /etc/profile or so if you have an nvidia card, it does make a huge difference!)
Also add this to your xorg.conf file:
Section "Extensions"
Option "Composite" "Enable"
EndSection
And make sure that you are using the latest nvidia driver.
You should tell us if it worked for you.
I think the posted referred to this discussion:
http://dot.kde.org/1200050369/1200126492/
I agree. I'm not ready to fully migrate to KDE4 yet, but I've switched to the KDE4 versions of several apps, including kwin. Other than some weirdness with the password dialog in kscreensaver, and the fact that setting KDEWM doesn't seem to work right, so I have to launch it manually, it's great.
If the rotating transparent cube and the wobbly windows get implemented in kwin, i'm sure 90% of compiz users would switch.
Everyone wants wobbly windows! It isn't rational, it is a simply human ;) But keep the wobbling very stiff by default, so as to be noticeably, but no more than that.
Somebody needs to do those :). We decided not to do those for 4.0 because of expected bad gain/effort ratio. They will be probably technically a bit harder to implement than others, and I'm not personally very convinced of their usefulness - e.g. the cube is good for giving non-advanced users a way to grasp the concept of virtual desktops, and for the hype of course (since compositing _is_ the cube, right?), but I was getting motion sickness rather quickly every time I tried to use it, and I had problems to actually find what I was looking for (especially with a higher number of desktops or the additional stuff enabled like cube-from-inside or transparent-cube). So they will be done when somebody finds time to do that, and that can be also you.
PS: The parts about KWin in this commit digest are from KWin's release notes for KDE4.0 : http://techbase.kde.org/Projects/KWin/4.0-release-notes .
Well, it was definitely the right decision to postpone those features, as they're really just eyecandy, nothing more. I love the composite features that are in KDE4.0, but apart from maybe a Vista window switcher (I love that one!), I don't think I need anything else. Please concentrate more on speed, it's way more important IMO!
didn't the Compiz Application Switcher come before the Vista one?
anyway, Wobbly Windows make moving windows around feel much better. it's like the movement is much more... natural.
Those were my favourites too + the shiver effect of drop-down menus etc..
When I set up comiz (or beryl or whatever it was then), I had to use wobbly windows, because it was the only way to get windows to snap to edges. Also, the stiffer the windows, the less they would snap.
That's when I decided KWin was more practical. That wasn't the only reason though, there were also desktop issues, and pager issues, and hotkey issues, etc.
I would!!!
Well I'm using KDE 4.0 already, but I really am missing the: CUBE, EXPOSE, COVERFLOW, MAGIC LAMP
And yes.. Compiz ran smoother on this machine than Kwin does.. I'm patient though.. I know you guys will come around and fix this..
All in due time.. (I hope... :-/ )
Stay serious, Compiz is 20 times more performant than this KDE 4 thing and has 10 times better effects.
20 times, 10 times ... speaking of staying serious, how about you tried to lead the way?
20 times is the sad reality.
I don't know why.
10 times is subjective impression.
And KDE 4 is 30 times better integrated in KDE :) Some of Compiz's effects are also over-kill.
I mean Kwin4 is better integrated in KDE4.
KWin4 is a game *giggles* but yes :)
(You're looking for KWin Composite ;) )
Not any more - KWin4 the game was renamed to KFourInLine in order to prevent this clash :)
http://websvn.kde.org/?view=rev&revision=748209
It's not a game anymore, it's now called KFourInLine ;)
"Stay serious, Compiz is 20 times more performant than this KDE 4 thing and has 10 times better effects."
What on Earth do you think Compiz [Fusion] or Beryl were like when they first started? It's also not being developed as part of a desktop project though, but rather as a separate window manager. Additionally, there are also a lot of corner cases and situations where Compiz doesn't work well, which negates its usage as a day-to-day window manager - no matter how it performs or how many effects it has.
And KWin is a 50x better Window Manager than Compiz, which really is its primary function right???
I am serious. Kwin performs fine for me (Geforce 7900 something) and the effects are nicer (present windows+filter, switching desktops, show desktops, etc). Compiz (0.6.2) had lots of issues with window placement, and weird bugs like wobbly windows never stopping to wobble. The only thing that I miss from Compiz is a zoom function that can be controlled with the mousewheel (the zoom in Kwin doesn't work for me).
Thanks from me too Danny. Well done. I just hope that the whole thing about Compiz and Kwin4 is now clarified.
@ leo S: I am a big fan of Compiz-Fusion but I have to confirm what you said. Compiz-fusion is amazing but it doesn't integrate in KDE very well. Kwin4 at this point doesn't have the glitz, glamour and flair of the ingenious Compiz-Fusion (although I am convinced that it will come in due time) but what it does it does it very well and it's perfectly integrated in KDE :)
Thanks for that Eike. For a few weeks I had to live without it as 2.8 crashed in KDE4.0, but now 2.9 beta is in Debian experimental and I have my Yakuake back! What a great app that is, and I haven't seen any bugs yet.
Odd, though - I used the 2.8.x codebase in KDE 4 for quite a bit of time, and it shouldn't have nor did it crash here :-). Anyhow, a native KDE 4 codebase is a better fit of course. Glad you like it! :)
Yeah I don't know what was going on. But it immediately crashed on start with 3 machines.. They were all running debian unstable though.
The only issue I have with Yakuake 2.9 is that it takes a while (~0.5 second) to appear when I hit F12 (even with zero animation time). But that's an issue with KWin I think, because I only see it when I turn compositing on.
There's also a known speed problem between Qt 4 and nVidia's proprietary graphics driver's XRender implementation, especially when using non-scalable bitmap fonts in Konsole's terminal widgets (which are also used in Yakuake). Check out the KDE4FAQ file I put in the tarball, there's a bit about that in there :).
This is one of my favorite KDE apps! Thanks a whole bunch!
Yakuake did, for me, never crash in a KDE4 session. The only issue I had is that it was looking quite odd if console transparency was enabled without a running kdesktop instance (meaning that the blinking caret stayed there and filled the console white; fortunately I can type blind).
At least as far as Yakuake's UI elements are concerned, this is something that 2.8.1 (the new KDE 3 release released alongside the KDE 4 version, and probably the last KDE 3 release ever) actually fixes as well by checking for whether kdesktop is present and falling back to a configurable solid BG color in the event that it isn't - also relevant for non-KDE users. In the KDE 4 version the situation is different because the pseudo-translucency support is gone in favor of XComposite translucency (which is toggleable as well, however).
Question: will/has Yakuake configurable tab labels just like Konsole4? I mean, with variables like hostname, user etc.
Yep, it does have those.
Great! It's one of my personal killer features in Konsole4, and I'm a yakuake freak, so... :D
Great job again, yakuake is a godsend for every unix sysadmin out there :)
>>Initial import of kio-giobridge, a bridge
>> interface between the KDE and GNOME I/O methods
What exactly this means? Can somebody please explain it?
Thanks in advance.
From what I can consider, this could know that Gnome progs can use the various KIO slaves from fish:/ to audiocd:/, and that KDE programs can use Gnome I/O.
The plan is to have a "common vfs layer" for all applications and file-managers, when working with network protocols like smb, ftp, sftp, webdav and others. The new GIO/GVFS (the successor of Gnome-VFS) pretty much fulfills the requirements for such a "common vfs layer" (desktop/toolkit independent design).
"kio-giobridge" is an adapter to run KIO on top of GIO/GVFS, in order to resolve file-management inconsistencies between KDE apps, and Gtk+ or 3rd party applications like Openoffice, Mozilla,...
I don't understand. can someone please give me a more dumbed-down explanation?
Some Gnome developer are working on something called GIO/GVFS, a subsystem delivering functionality akin to KIO. Making it possible to use things like ftp:/, smb:/ in filedialogs. Something KDE users has been able to for years with KIO.
The "kio-giobridge" makes it possible for KDE programs to using GIO/GVFS. Of course in places where KDE already have native IOSlaves handling the protocoll, it does not make much sense for the users.
> The "kio-giobridge" makes it possible for KDE programs to using GIO/GVFS. Of
> course in places where KDE already have native IOSlaves handling the protocoll,
> it does not make much sense for the users.
Well, the idea behind "kio-giobridge" is that it does make sense to switch off KDEs native IOslaves and to use the shared implementation instead. This is because GIO/GVFS works similar to UNIX mounts: You mount a certain ftp server or smb share and all applications/file-managers can use them without logging in again. The servers/shares stay mounted until you hit the unmount button. Therefore working with network file systems should feel a lot more coherent. You don't have to log in twice when working with KDE apps and Gtk/3rd party apps on the same shares and you don't have to pray that KIOs and GIOs protocol handlers are functionally equivalent.
Except the implementation is not shared. It is just a crappy GNOME attempt to copy KDE. So let's stick to our own implementation instead of promoting second-rate copy-cat implementations.
If there's this "mount like" features, it's definetely better than KIOslaves, at least from an architectural PoV. The fact that KIOslaves are KDE-only and so from the shell or whatever program not using kdelibs (even Qt ones!) you cannot use them directly, sucks so hard... don't get me wrong, if KDE ruled the world, KIOslaves would be the non plus ultra, but since biodiversity is something directly bind with FLOSS, than we have a problem.
The best Linux implementation should be using FUSE, but then we have a problem with other platforms. Don't know exactly how GFS is solving this, but if they can get a mounted point transparent to the system, then they have a winner.
(I mean, the clear example here is OSX, which has the best way to implement remote access)
KIO slaves are no more KDE specific than GIO is gnome-specific --- so what's your point? Actually, you don't have to link to KDE libraries to use I/O slaves --- they are out of process, w/a dbus + socket protocol, so there is absolutely nothing preventing one from writing implementations of slaves or client libraries w/o using KDE libraries.
P.S. KIO does a lot more than VFS, too. And having two overlapping systems used for the same codebase is freaking insane.
> KIO slaves are no more KDE specific than GIO is gnome-specific --- so what's your point? Actually,
> you don't have to link to KDE libraries to use I/O slaves --- they are out of process, w/a dbus +
> socket protocol, so there is absolutely nothing preventing one from writing implementations of
> slaves or client libraries w/o using KDE libraries.
Well - in theory KIO could be implemented desktop independent, that's true. But in praxis rewriting the client and daemon/slave parts isn't easy. As GIO/GVFS already is desktop independent in the implementation, and also seems to have some advantages in design, why not go for it?
> P.S. KIO does a lot more than VFS, too. And having two overlapping systems used for the same
> codebase is freaking insane.
Why is it overlapping? Parts of the functionality in KIO (particularly network transparent file-management like smb, ftp, sftp, webdav) would be delegated to GIO/GVFS. That's just putting the KIO interface on top of a shared implementation.
> Well - in theory KIO could be implemented desktop independent, that's true. > But in praxis rewriting the client and daemon/slave parts isn't easy. As > GIO/GVFS already is desktop independent in the implementation, and also seems >to have some advantages in design, why not go for it?
First of all, there is no reason to rewrite anything. Multiple implementations can talk on the same wire protocol. And GIO is "Desktop independent"? That's just nonsense, to put it politely. It's written exact way GNOME developers like to write things. And "why not" throw out something that works pretty well for a new toy, just because GNOME is being NIH again? Are you being freaking serious?
> Why is it overlapping? Parts of the functionality in KIO (particularly
> network transparent file-management like smb, ftp, sftp, webdav) would be
> delegated to GIO/GVFS. That's just putting the KIO interface on top of a
> shared implementation.
Because you would need the core KIO infrastructure for things like kio_http, kio_imap4, etc. And as someone who may have to fix things in kio_http, I sure as heck won't want to deal with a mismash of g* code in KIO core.
> First of all, there is no reason to rewrite anything.
I think he didn't mean to use the word "rewrite", i.e. replacing an existing implementation with a new one, I am quite certain he meant "from ground up", i.e. starting to implement a second stack starting at the wire level.
> And GIO is "Desktop independent"?
Again I think this is just unfortunate wording. In this context it more likely means "not linking against any GUI library", e.g. an implementation just linking with QtCore would also be "Desktop independent".