[kde-linux] KDE3 Apps to KDE4?

[Duncan]

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
>>> KDE4.3.
>> 
>> 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 
generation, anyway).  

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 
required.

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 
resolutions, etc.

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.

>> From
>> 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 
session.

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 
session?

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!

http://www.kde-look.org/content/show.php/Yasp-Scripted+(Systemmonitor)?
content=109367

-- 
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