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
