[kde-linux] KDE3 Apps to KDE4?
1i5t5.duncan at cox.net
Sat Nov 14 01:32:12 UTC 2009
Allistar posted on Thu, 12 Nov 2009 12:09:25 +1300 as excerpted:
> Duncan wrote:
>> Allistar posted on Wed, 11 Nov 2009 09:59:17 +1300 as excerpted:
>>> And an important one for some of us: proper multi-session support. I
>>> have a triple-head setup and from what I can tell I cannot use this in
>> Triple-head should work (if your X supports it), but only as a combined
>> single-session, aka "xinerama mode", spread out over all heads.
> Yes - I don't really want that though. I have my left two monitors (my
> primary workspace) as a single KDE session using Nvidia twinview (so no
> xinerama here) and the right hand third display as a separate desktop.
> This allows me to change the virtual workspace (or whatever compiz calls
> it) on the left two without also changing the one on the third. I find
> this setup makes me much more productive.
> Also, I have noticed that xinerama is slower than twinview, especially
> for3D stuff.
As I understand it, "xinerama", per se, isn't really supported by xorg
any more. They're switching to randr based systems now. But that's
quite a different thing entirely from "xinerama mode", which uses X API
extensions first developed in xinerama, and which are anything /but/ dead.
One of the issues is that true xinerama basically did not do 3D at all --
it was limited to 2D (at least accelerated), because the 3D engines, like
overlays, were limited to single chips -- or in more modern terms single
framebuffers (which can be shared between chips/cards using the modern
interleaving techniques... between cards of the same brand and general
The first improvement, once they started coming out with dual output
chips/cards, was merged framebuffer, twinview being nVidia's trademarked
name for it, but merged framebuffer in the native freedomware xorg
drivers. But that was limited to a single hardware card/chip/engine,
thus, generally, dual monitors corresponding to the dual outputs, tho it
did improve things markedly as it allowed accelerated 3D over two
monitors, at least.
Now, merged framebuffer per se is also gone, and it's all intended to be
handled dynamically with randr, thus allowing monitors of varying
resolutions to come and go, as is so common a scenario with laptops,
without having to restart X with a different config, as used to be
But 3D support is dragging right now. The components are just barely
coming together, and it'll be another year or so (maybe more, I'm not up
on the status of all the components...) before distributions are carrying
versions with it working and stable for a reasonable number of users.
Even then, I'm not sure how well it's going to handle split hardware,
especially when they're differing brands.
Meanwhile, xinerama, had been the first to deal with multiple outputs,
back when they came one to a card and it meant multiple video cards. The
extensions developed for it, as mentioned above, are still called
xinerama mode, when active, even tho now it's much more commonly merged-
framebuffer or some other "pseudo-xinerama" technology. "Xinerama mode"
simply refers to the extensions that allow a window manager to know where
one monitor/viewport ends and another begins, for the purposes of window
placement, maximizing windows, etc. Without those extensions, the whole
thing is literally treated as a single framebuffer with no internal edges
and no "holes" like those that occur when one monitor runs at lower
resolution than the other. As such, centered windows often appear split
across both screens, windows maximize to both, even if that means part of
them isn't displayed because it's in the "hole" due to differing
More loosely, "xinerama mode" has also come to mean merged framebuffer
mode in general, regardless of whether the xinerama extensions are
enabled. This means windows can be dragged between screens, etc, and is
the way I was using the term.
What you use with different sessions is now often referred to as "Zaphod
mode", a reference to the guy in HHGG (Hitch-hiker's Guide to the Galaxy)
as many of us geeks read in the 80s but as has now been popularized by
the movies. But those books were a long time ago for me and I've not
seen the movies, so I don't really remember him, but obviously he must
have been multi-headed or something. =;^)
Of course, you're using a combination, two monitors in xinerama aka
single/merged framebuffer mode, with a third as a separate session.
Meanwhile, multiple card support was (temporarily) sort of left behind as
well, with the more modern randr based setups. But the very newest
kernels (2.6.32 I believe, it's not even out yet except in rc) bring back
a vital component for proper support, the video arbitration system. But
that too is going to be several months at least before it's properly out
there for folks to use. Of course there's black-box-ware solutions for
those willing to use them, but I'm not.
>> what I read, kde4 is single-session only, with no one currently working
>> on changing that.
> How does this work for people that have a single computer with 4
> keyboards, 4 mice and 4 monitors providing a separate independant
> desktop to four people? Can they not use KDE4?
That works rather differently. As best I understand it and I've never
actually worked with it so I'm somewhat vague on the details, those work
with multiple entirely separate X sessions, each with its own keyboard/
mouse/display. Generally, those sorts of systems use a lighter setup,
icewm or one of the *box wms, for instance, as the systems doing that are
normally doing it to save money and running four X sessions on four
different pci cards on a system with often well under a gig of memory, is
hard enough as it is, without the weight of a full-feature desktop
environment to deal with as well. However, assuming the machine had the
muscle for it, multiple kde4 sessions should work fine, because it's one
per X session, not trying to run multiple kde sessions in the same x
Talking about... I've never tried it, but I've read about this thing
called nested X. Basically, you run a second X session in a window on
your first X session. I suspect the performance on the nested one might
suck, I really don't know, but it occurs to me that /that/ might be one
way to get a second kde session running, since it would be in its own X
session, and the first would just see it as another (non-kde) X client.
>> Apparently, the multi-session support in kde3 was never deliberately
>> intended either, it just happened to work. But kde4 was enough of a
>> rewrite that whatever allowed it to work in kde3 is long gone, and it's
>> not likely to return until someone with sufficient skills gets
>> sufficiently interested in making it happen... that it does happen.
> I think I may using a different WM for the third monitor. That's a shame
> though as it won't look or feel consistent. The third monitor is the one
> I put Superkaramba on and from what I've read I'll replace this with
> Plasmoids (or whatever they're called). That's not going to work if it's
> not running KDE.
If it's the same X session, /can/ you run a second WM? I thought they
were limited to one per X session, and that they controlled the whole X
Meanwhile, sounds like you didn't know, plasma has native superkaramba
theme support now. With 4.3 you can actually run superkaramba themes two
different ways, directly in plasma, or with the ported superkaramba.
When run natively in plasma, they have slightly different properties than
when run in superkaramba. However, based on what I've read, the ported
superkaramba will probably eventually be going away, leaving only the
native plasma support. But plasma itself is still developing quite
rapidly and its native superkaramba theme support is still a bit rough
around the edges. (The GUI lets you import them, where they become a
choice on the add-plasmoid list, but it doesn't yet let you remove them
from that list, even if you just tried the theme and later deleted it,
for instance. That should be fixed for 4.4 I think, with the new
plasmoid explorer that's replacing the current add plasmoid list.) So
there's both for now, until plasma gets a bit better at handling them and
a bit more mature in general.
Finally, you may also wish to take a look at the yasp-scripted plasmoid
available on kde-look (which as kgetnewstuff, is far better integrated
into kde4 than it was in kde3). I couldn't find a superkaramba theme to
replace the ksysguard kicker applet I ran in kde3, and "the application
formerly known as ksysguard" is still SERIOUSLY buggy for any decent
monitoring in kde4, so I was expecting I'd have to learn the superkaramba
config language myself and create my own theme. However, I discovered
yasp-scripted, which is sort of a superkaramba-lite. It doesn't have a
horizontal layout scheme and simply takes the widgets in order as they
appear in the yasp-scripted script, so it's all vertical layout (you
control the width by the width of your widest text entry value), but that
was enough for me and simpler to learn than superkaramba's layout
language. I simply created multiple scripts and ran multiple yasp-
scripted plasmoids side-by-side -- eight of them across my screen! I
mailed the author my scripts and a screenshot, and he posted the
screenshot, and is now shipping the scripts, tho they'll likely need
hacked slightly for other systems.
yasp-scripted, watch the link-wrap!
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
More information about the kde-linux