[gentoo-amd64] Re: Heads-up: KDEers: Particularly kde3-ers,

[Duncan]

Volker Armin Hemmann posted on Tue, 25 Aug 2009 01:33:23 +0200 as
excerpted:

> On Montag 24 August 2009, Sebastian Beßler wrote:

>> 3) Screen-setup: I have to monitores connected to my pc static in xorg
>> as two seperated displays :0.0 and :0.1. If I start kde <4.4-svn I have
>> both screens on my main monitor and the second is just as good as dead.
>> There is a patch for this in svn (or is it git now?) and as much as I
>> can say by testing a few live-builds this point will be gone by next
>> release.
>
> ok, sounds like a genuine stupid bug. Can't even fixed with krandrtray?

This one is a known kde4 issue, and earlier, they weren't planning to fix 
kde4 to do multiple X sessions like kde3 did.  From what I've read it was 
purely an accident that kde3 handled multiple sessions that way.

It's possible that may change, given the requests they've gotten, but I 
don't expect the devs to prioritize it, which practically speaking, means 
they'll take patches...

Meanwhile, kde4.3.0 still has issues with xinerama (what SB calls "big 
screen") mode in some cases (including mine), too.  It detects two 
monitors, but only sees one CRTC, apparently, and thus forces them into 
clone mode.  The systemsettings display applet preview shows just one 
screen, with the label for the second monitor overwriting that of the 
first, so the result is an almost unreadable combination of the two 
labels.  And the settings for each monitor are all there except for the 
position control that would allow you to set on-top-off, to-the-right-of, 
etc.  (I didn't even know what it was supposed to look like until someone 
else with the problem posted a screenshot to one of the kde lists I'm 
following, and another poster followed up with a screenshot of how it /
should/ look.)

But I've seen several mentions that the problem has been fixed in trunk, 
for 4.4, and the fix may or may not make it into 4.3.x.

Meanwhile, since kde3's display applet never worked right either for me, 
I've developed my own scripts to manage resolution changes here, calling 
xrander to do it.  As long as I don't open the kde display settings 
applet or run krandrtray and screw with it, I'm fine, but if I even so 
much as open the display settings applet, kde screws things up royally, 
and just running the xrander script doesn't fix that.  I have to screw 
around with plasma to get it back the way it's supposed to be, as well.

So for now, I just don't go there any more, and I'm fine.  But I'm 
looking forward to 4.4.0 or 4.3.x when that fix gets into the release, 
hoping I can actually manage displays using kde then, for the first time 
ever! =:^)

>> 4) Design: I have a very small design with two small bars at the bottom
>> and on the right side. I can't create a design in kde4.x so far that
>> consumes as few space on my monitor as i have it in kde 3.
>
> but you know that you can make the plasma bar very small - and add a
> couple of them to the desktop?

4.3 might actually be able to do this now.  Each 4.X release has VASTLY 
improved plasma, so far, and in this area 4.2 was finally becoming semi-
usable and 4.3 is actually very reasonable, now.

If small is what you want, 4.3 really does allow small now.  I have one 
panel set as small as it'll allow, looks like 12 px high (horizonal 
panel).  IIRC the minimum in kicker was 24 px?

But I still find the panel settings widget clumsy and inefficient, 
compared to how kicker worked.

And while the panel settings widget at least works, the entirely 
automated panel plasmoid sizing is still simply broken in some regards.  
There really needs to be a way to force a plasmoid to only take up so 
much space in the direction of the orientation of the panel (width on a 
horizontally oriented panel, height on a vertically oriented one).  By 
that I mean, have /plasma/ force it, regardless of what ideas the 
plasmoid has about its size.  Some of the plasmoids simply hog space, and 
can't be forced smaller, without changing the size of the panel itself 
(height on a horizontally oriented panel, width on a vertical oriented 
panel).

If plasma could force it, the plasmoids would have to adapt.  If they 
didn't, they'd probably simply die out from disuse, as people found 
solutions that actually worked.

I was hoping the spacers introduced with 4.3.0 would correct the problem, 
and they would have if they could be arbitrarily placed, thereby limiting 
the area the plasmoids on either side had to work with, but the hogging 
plasmoid simply shoves over the spacer.

One way plasma could implement this while staying compatible with older 
plasmoids, would be to lie to them about the panel size, if it had to, 
thereby forcing them to adapt to what they believed was a smaller sized 
panel.

Another problem still existing in 4.3.0, is that if the install new 
widgets functionality is used (so the new widget appears in the list 
available to add), there's no GUI method to remove what has been 
installed (so it no longer appears in that list).  One must actually find 
the location in kde's configuration tree on-disk, and remove the offender 
there.  If it can be installed via GUI, it should be uninstallable via 
GUI as well.

And one of my big irritations is that there's no ksysguard plasmoid to 
replace the ksysguard kicker applet.  It's bugged.  IDR whether I filed 
the bug or just CCed an existing bug, adding my own request, but either 
way, there have been several folks add comments asking for it as well, 
since I did whichever.

Of course, ksysguard4 still has some serious bugs of its own, including 
the fact that it doesn't properly restore user set minimum and maximum 
settings on the fancy-plotters, if the user has turned off auto-ranging.  
That too is bugged.

Meanwhile, I've been working on setting up a superkaramba scheme that 
does what I want, but that's still on my list, I've not been able to do 
it yet.  (The other last big issue I had was khotkeys multi-key, but I 
solved that with my own script, as I described in a previous post.)  
Superkaramba is much more flexible than ksysguard in layout, etc, so it 
should be great when I get it setup, but it's a matter of actually having 
the time to do it.

Until then, I have to reset a half-dozen plotters to their proper ranges 
every time I restart kde or just ksysguard.  That sort of repetitive work 
is /exactly/ the sort of thing computers are supposed to be able to 
handle for us humans, so it's rather ironic that ksysguard is making me 
do it, instead of allowing me to tell it how I want it set and have it do 
it.
 
>> The fifth point on my list is that many of the functions and (3rd
>> party) kde programms I use day by day aren't there yet at all or only
>> with lack of functions and mostly in late alpha-state: k3b, amarok,
>> kdevelop, kvirc to just name a few.
>
> I haven't found anything missing in k3b or amarok - and I don't use
> kdevelop or kvirc. What are you missing from k3b?

k3b I use in general, but haven't tried the kde4 version yet. (I have it 
merged, and ran it briefly to see how it looked, tho, and nothing lept 
out at me as lacking.)

But I finally got so fed up with amarok I found a different solution.  
They killed all the functionality I actually used, while adding a bunch 
of junk I'm not interested in.

Have they gotten the winamp/xmms skinnable mini-player back yet?  Last 
time I checked, they weren't interested in the idea.  What about 
visualizations?  That actually may be back in the kde4 version now, I 
don't know, but I had a lot more use for that then all the fancy main UI 
changes they did.  And I never /did/ use all that fancy scoring and etc. 
functionality.

It's fine if they don't do it.  It's just that our paths have obviously 
separated (not that they were ever really the same, but it was convenient 
to travel with them for a time).  Like the last ISP I left, they're free 
to develop the product as they wish, but I'm simply no longer interested 
in going where they were headed.  Thus, they can go their way and I'll go 
mine.  

Still, the thing that really had me fed up was somewhat different.  
That's the way they handled the transition to the MySQL backend.  Not 
only is that entirely unnecessary for the features I'm interested in (tho 
I'd have tolerated it if they had kept the features I actually used), but 
they demonstrated a COMPETE disregard for their amd64 users when they 
added it, as it was ENTIRELY broken on this arch at the time.  The 
library they were using wasn't designed for dynamic use, only static, and 
thus simply wouldn't function as a dynamic library on amd64 (at least not 
without affecting the performance of all the rest of the package, 
including the mysql app itself), as dynamic libs here require -FPIC, and 
at the time the only way to get that was to compile the entire package 
with it.

That was the last straw for me.  Not only were they dropping all the 
useful stuff (from my perspective) from their kde4 version, but 
demonstrating a total disregard for their amd64 users as they did, that 
was more than I was willing to take, and I decided there were simply 
better options available.

>> The last reason I stick with kde 3.5.10 for a while is that working
>> with kde 4.x just doesn't feel right. Switching to kde4 is like
>> switching to a completly different DE. KDE 4 isn't kde anymore, it is
>> something absolutly different that calls itself kde.
>
> people said the same when going from 1.1 to 2.0 and 2.2 to 3.0....

Indeed.  I expected some adjustment time, and that's why I was running 
the live version before 4.0 came out, with the idea that by the time it 
was ready, I'd be ready too.

But I had no idea it would be 4.2 before it even got to the beta state 
this early-adopter likes to jump in at, 4.3 before it got to rc, and 
apparently 4.4 before it gets to actual normal X.0 release quality!

And /as/ such an early adopter, I had no idea I'd be feeling the clock 
ticking on the end of support and removal from my distribution on the 
actually generally usable version, before I could even do the usual beta 
testing I normally do with such important products.

> The only two things that I really disliked about kde 4.X is the new
> 'systemsettings' - I liked kcontrol. Very much. And akonadi creeping
> into everything.

akonadi is frustrating, for sure.  As is nepomuk, soprano, etc, at least 
here.

And I agree on kcontrol vs. system-settings, as well.  FWIW, you can 
change the system-setting menu entry (using kmenuedit), renaming it 
kcontrol, if you want, and you can use the qt --caption or the kde --
title option if you wish.  But the title changes back to System Settings 
as soon as you activate any of the applets.

Of course I'm using the tree view option they added back to it in 4.3, 
that was the way kcontrol3.

But as with kde3, I put the kcontrol/systemsettings menu widget on a 
panel (complete with its own keyboard shortcut, even), and seldom invoke 
the full kcontrol/systemsettings any more.  There's really no reason to, 
once you figure out what applet a particular setting is in, and you have 
your system setup in general the way you want it, so you're only doing a 
single change or two in a particular place, here or there.  But as with 
kde3, I still access the settings enough that the menu's worth having.

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