|
|
Dingo Gully > Jedd > Excogitations > IT > KDE 4
KDE 4Table of contents
What's broken (and how to fix it) 2009-07-27: It's been a few months since I have updated this page - I've now gone through it with the proverbial fine-toothed comb and updated things I'd sorted out. I'm now running KDE 4.2.4 of course, and this solved a handful of the problems. KDE 4.3 is nearly ready, and fingers crossed that it'll resolve a bunch more. 2009-08-11: KDE 4.3 arrived in Debian unstable and - happily - it's a beautiful thing in comparison to KDE 4.2.x. The stats on bug fixes are impressive to read, but it just feels safer somehow. I'm seeing a lot fewer crashes, but it is not without annoyances. Briefly: o KMail still insists on bolding words wrapped in *asterisks* (with no option to disable this too-smart feature) 2009-12: KDE 4.3.4 arrived, with many promises. In reality I've seen little changes. konsole still takes several seconds to resize (possibly a nVidia conflict, and it seems to be related to 'desktop effects'). Remember The Milk (rtm) plasma widget works, which is good. I'm seeing the same number of nepomuk slow-downs - I think we're another minor release or two away from some satisfaction on that front. Konqueror toolbar munging still occurs, KMail still bolds words you don't want it to, Konqueror crashes still occur with accompanying weirdness, manual sorting of the toolbar (despite it being in the CVS for a month or two now) still isn't back. I've added the on-going move-tab problem to the list below (it's been in b.k.o for a year and a half).
This page details everything I've found that fails to work with KDE 4, but worked just fine with KDE 3. It is written as a response to having KDE-4 forced upon me by the introduction of it into the unstable branch of Debian, in April 2009. If you are a KDE developer, then be warned - it is written in the tone of someone who loves KDE 3.5.x, and who is both astounded and disappointed that more than a year after the release of 4.0, the latest version (4.2.4) is still such a backward step in terms of features, and often simply broken, in so very many ways.
PreambleI don't buy the whole no pain no gain bollocks. KDE 3.5.x is a beautiful thing. It does its job remarkably well. It is highly configurable, in look as well as in action. It is reasonably lightweight. It is hugely stable. Most of all it is so very, very predictable. This is what you want in an operating environment (unless you're a Windows Fista user). With Debian introducing KDE 4 into their unstable branch this month (April 2009) a large number of people -- most importantly yours truly -- are being hit by these problems described below. Obligatory disclaimers: I've been a user - and advocate - of KDE since 1998, and Debian since a few years before that. I love 'em both, and though much of the stuff below is going to sound like it's just one big whinge, it should be taken in this context of fondness and advocacy. Note that much of the stuff below actually is a whinge - but mostly about the change for the sake of change, and the backwards steps that are asserted to be necessary if we're to move forward. As I say, I just don't buy those types of arguments - mostly because of the myriad of things that worked just fine in KDE 3 but have been ripped out or dumbed down or functionally regressed in KDE 4. The stuff that I cover here may be related to debian package management, or to KDE 4 issues, or in some cases a combination of both. So keep that in mind if you're not a Debian unstable with KDE 4. I originally experimented with KDE 4 in August of 2008 - but reverted to 3.5.x for a number of reasons (many of which reappear on this page). The biggies were lack of application support for key items, though - quanta and kphotoalbum are two examples. I also found the system to be generally buggy and components would frequently crash. Strangely this has been my experience again this month (April 2009). My laptop previously would run KDE 3.5.9 for several days at a time (only rebooting to play with other OS's). Within a half hour of installing KDE4, and while changing a kmail setting for fonts, the thing crashed to an extent that it required a power off (KDE managed to take X and the whole OS with it). I've had kmail crash about 8 times in 24 hours, just from making changes to account settings. (8 more crashes than in the previous seven months that I've run KDE 3 on this laptop.) So my expectations were low, and have remained so. Also worth noting - I originally tried to migrate my existing KDE3 settings into KDE4, but had huge problems - many things just didn't work as they should have and I feared that I might suffer eternal stability and configuration curiosities forever if I battled on. So I then removed all my KDE settings, and launched again with a completely raw skeleton of KDE4 settings, as configured by the KDE / Debian developers. What follows is therefore based on the experience of a very vanilla-flavoured KDE 4 setup. Finally, I've almost exclusively used an MSI Wind netbook for the past few months, so some of the problems I highlight relate to the small screen size (1024x600) - and modest grunt factor (1.6GhZ Atom with 2GB RAM). Around the time that 4.2.4 was released into Debian unstable I also got my desktop machine back - and that's made a huge difference - it's a quad-core, 2GB RAM, SLI nVidia setup with a decent (22") monitor. Mind, in turn it's now sadder (all over again) that KDE 4 is so reliant on a fast / large machine to hide its short-comings. I still use the MSI Wind, though, and in turn I now have a few more issues - with regards keeping data in sync between the two boxes - that are new problems to this list. My bug/feature/wishlist items follow - kept all on one page for easier management, and better results for other people searching for some answers of their own.
Akonadi - general pain in the proverbialExplanationAt login, and at random times while using kmail, and when trying to launch kaddressbook or korganizer, the Akonadi pop-up does its thing - which seizes all those applications - and then reports an error. My understanding of akonadi at the moment is that it is a kind of hopping-point for new mail (and other PIM stuff) - and that no data is stored within the database component. I can begin to understand the grand plan for this sub-system, and have no issues with their approach. What does worry me is what happens when they do start to store long-term data inside the database. Not because I don't like databases (I love 'em!) but because it makes the issue of synchronising data between desktop and laptop (or indeed just backing your system up to remote server or USB drive etc) so much more painfully complicated. I need to do some more research on this one. I've encouraged the Debian KDE maintainers to get together with other Debian maintainers, and agree on setting up mysql a bit more consistently (ie. per system, rather than per user). It's a very complex situation, to be sure, but I don't think the current KDE 4.2.4 approach is scalable. Work-aroundHere's my method of getting it working. Migrating your extant data (ics, maildir, contacts, addressbook, etc) is left as an exercise for the reader. The following will simply get akonadi to work. Requirements: You need a MySQL daemon running, ideally (but not necessarily) locally. If you don't have one running already, there's a good chance that the Akonadi script will have worked just fine, as it seems to want to run one of its own. I have no idea how this will go with multiple concurrent users on the machine, though. Hmmm. I speculate quite badly as each akonadi instance will want to run a quite heavy database process, and more importantly, lock it into the same port number. Overview: We are going to set up the database, and permissions to same, and configure the akonadi configuration file, and that should be enough to get it going. Method: The configuration file for akonadi is located at: ~/.config/akonadi/akonadiserverrc Edit this file - mine looks like this: [%General] Driver=QMYSQL [QMYSQL] Name=akonadi_jedd User=akonadi_jedd Password=secret Options= ServerPath=/usr/sbin/mysqld StartServer=false Host=localhost [Debug] Tracer=null The key things you need to add / modify here are:
Next we configure the MySQL database. If you don't already have a running database, seek elsewhere for getting this working - really, I'm here to help people who are in the same situation I was (extant MySQL db on localhost). # mysql -u root -p Enter password: ... mysql> create database akonadi_jedd; mysql> grant all on akonadi_jedd.* to akonadi_jedd@localhost identified by 'secret'; mysql> flush privileges; mysql> exit At this point I tried to re-start the akonadi daemon using the akonadictl utility, but this failed to work. Out of desperation I logged out and back in again, and lo - this worked a treat. Hopping back in to mysql I could see that the tables had been created, and akonadi started properly. There were a few migration notice boxes displayed, but things seem to be fine. Bug reportPossibly irrelevant - it's a mostly packaging problem, and the Debian maintainers are going to be very familiar with this problem, particularly as more things swing across to using Akonadi over the next several months.
Alt-F1 (main menu hotkey) disappearsExplanationAlt-F1 has always been the way to get the main menu - for those that eschew gratuitous mouse activities. In KDE 4 the Alt-F1 shortcut is usually there, but seems to come and go. It is not configurable within the System Settings | Input options - which is very strange indeed. Work-aroundBecause you can't configure this hotkey in the same place as all other hot keys are configured, you'd be forgiven for thinking that you can't configure it at all - happily (and in a way, sadly) this isn't the case. Right-click the main menu button and select Application Menu Launcher Settings and you can change the hotkey in there. Alt-F2 (krunner) wouldn't let me launch web searchesThis bug manifested itself after I did the KDE3->Kaboom->KDE4 conversion, and after some searching around and finding a few other people affected, but nothing in the way of a solution, I reverted all KDE 4 configuration files back to factory default settings (as per the introduction above). The bug bears describing, however. Alt-F2 (or krunner) is the pop-up thing that lets you launch anything. It's been enhanced in KDE 4, and part of that enhancement I like (it's snazzy) and part I don't (it feels slower, especially as it tries to match something that you already know, and delays you by offering you those options instead of attending to what you have just typed in). In any case - I could run any application by name, and I could bang in URL's - they'd both work just fine. But if I tried the class wp: string of words (as well as gg: , ud:, etc) - it would not act. The return key just didn't trigger anything. It was especially weird. Konqi was happy with the web shortcuts - the configuration was sound, and doing wp: string of words in the location bar of a konqueror window did exactly what you'd expect.
WorkaroundI'd previously beleived that there was no workaround (short of re-installing) but have had some measure of success playing with the configuration (the little spanner next to the alt-f2 dialog). There also appears to be (as with some other UI bugs) interference between gestures and global shortcuts/hotkeys that sometimes get in the way. I've not seen the problem with KDE 4.2.4, though, so it may well be properly fixed now.
Alt-F2 (krunner) doesn't support 'run as root' anymoreExplanationUnder KDE 3 - the alt-f2 dialog would give you an Options button - this included things like running as a different user (including root), modifying the priority, and so on. Under KDE 4 no such feature is presented to the user. This makes it very challenging to do certain things - for example the System Settings dialog has a bunch of items that require root access, but unlike KDE 3's Kontrol Panel, it doesn't offer a way of elevating rights within the utility to root. Not even a catch-22 here. WorkaroundThere's only one workaround until the promised bliss of KDE 4.3 gets us back to the same feature set we had for a decade in earlier versions of KDE. And that is to use kdesu - this is actually packaged as part of the kdebase-runtime package, and is located at /usr/lib/kde4/libexec/kdesu - happily this appears to be in the path of a normal Alt-F2 run. So, you just run alt-F2, then type in 'kdesu .... ' and whatever else you were going to type. The obvious shortcoming here is that it's much more painful than it was before, and you'll have to get out of this habit once KDE 4.3 fixes it properly, and it's substantially more difficult to run something as a different and non-root user. Bug report
Hide button on task barExplanationOn KDE 3 you could have a hide button - of customisable width - on left, or right, or both - of the task bar. This was insanely handy. You could just mouse to the bottom right corner (say), click once, and you'd be in full screen mode. You could do the same again - as the hide button (usually about 4 or 5 pixels wide) would stay on top of every other window - and go back to showing the taskbar. Work flow example - normally you'd want to see stuff in the task bar (clock, tasks, desktop #, CPU load, etc) - but if viewing a web page or playing with GIMP you might hide the taskbar to get that extra bit of screen real estate. The minimal effort required to hide/unhide it made this quite effective. On KDE 4 you can either set the taskbar to be always there or to auto-hide itself. You can not customise how long it takes to auto-hide (another feature KDE 3 had) and there doesn't seem to be a way to customise one of the corners of the screen to trigger this act, or indeed any hot key combo. Work-aroundNone as yet - at the moment I'm working with auto-hide - it's essential on a small screen, but equally it's very painful on a slow machine. 2009-07 update - this still shits me to tears with KDE 4.2.4 -- were the developers of KDE4 unaware of KDE3's features? I would have thought they were the same guys that wrote and used most of them. Bug report
Kaboom doesn't play nice with 600 pixel high displaysExplanationKaboom is Debian's front end to the migration of settings from KDE 3 and 4 (experimental) to KDE 4 (production). On the 'import settings' page, the dialog box is typically > 600 pixels wide. This obscures the buttons (specifically Back and Next). The usual KDE trick of using Alt+left-mouse to drag windows around doesn't work at that time. Work-aroundDo the upgrade while attached to a bigger monitor (untested). Tab twice and you should get Next (unfortunate case you get Back, worst case you might get a Cancel). Use Alt-N to trigger the short-cut key for the Next button (untested). Bug report
KDM - background goes weird during loginExplanationJust prior to logging in, and before KDE 4 takes over from KDM, the background appears to split into two - the left half presents on the right side of the screen, and vice versa. A very weird visual effect. I'm not sure if this is a feature of my dodgy graphics driver (some Intel on-board thing) or just an artefact of KDM 4. Kaboom (see above) proceeds to run with this background appearing broken. Usual login procedure is fast enough that you don't see this effect for more than a few seconds. Work-aroundNone known. Ephemeral visual problem only. Bug report
KMail - can't disable bolding or italicising of * and / surrounded wordsExplanationKMail (reader) will interpret words wrapped in asterisks and slashes - for example, if you *really* wanted to /emphasise/ something - by turning the word bold or italic. This is fine on a wiki, where you're trying to explain what bold and italic words look like, but really annoying in mail where you want to see the raw text, not the marked-up interpretation of that text. Work-aroundThere doesn't appear to be any way to disable this 'feature' Bug reportI haven't filed one yet.
KMail - not retaining column settingsExplanationKMail 1.11.2 has a number of irritating and surprising bugs. The inability to select (and have it retain) a particular column order is just one of them. You should be able to simply drag a column header (say Sender) left or right to the preferred location, and kmail should remember that. It does not. Failing that, using the Theme support (something I'm only using to get around yet another bug in kmail where settings | appearance | fonts are not respected) to do this column order configuration - also fails to retain the preferred order between kmail sessions. Work-aroundNone known. Have to manually modify the column layout on each kmail launch. KMail - not retaining custom font preferencesExplanationChanging fonts using kmail's Settings | Appearance | Fonts - has no effect. It appears to be because the theme stuff overrides it. There's no way to disable the theme(s) from doing this. Because it's a profound bug - there's no clear way on how to handle this conflicting setting information - it'll probably be around for a while. Work-aroundUtilise the theme approach - I've cloned an existing theme and modified its fonts. This is effective and leaves you with the same outcome as modifying fonts properly. The only problem will be if/when this is fixed, it'll likely revert your changes (or leave you with a configuration that is theme based, rather than kmail/settings/fonts based - so you'll have to remember to change it in here forever more). Konqueror - clear location bar icon is wrongExplanationThe icon - which in 3.5.x was a small [x] that would clear the contents of the location bar (handy for people familiar with middle-button-paste) used to be located on the far left, right next to where the contents of the location bar generally was - and was a small [x]. With 4.2.2 the icon appears to be the OpenOffice Impress icon (I don't know why) and is now way over on the far right. SolutionYou can select Settings | Configure Toolbars and then modify the Location toolbar, and from the left side, drag over the 'Location Clear'. I don't know how it can be in the unselected left side, since it's clearly present in the current toolbar. You can also change the icon (look around Location... in the icon list) 2009-07 note (kde 4.2.4) - on my laptop this works fine. On my desktop - with exactly the same set of packages - it fails to work - I simply can't get the 'clear this text box' icon to either be a) the little [x] thing (it went to something else I didn't recognise, but has come back to the openoffice impress icon again) or b) live on the left - even when I do the above, it consistently stays on the right hand side of the location bar in konqueror. Curiously I'm also unable to get the Up icon to move back to where I want it in my toolbar on the desktop (but it's fine on the laptop). This is using the same konqueror-configuration dialog. It's especially weird and irritating.
Konqueror - ctrl-middle-click doesn't open new tabExplanationIn KDE 3 you could configure Konqueror to open new URL's in a new window, and then force certain ones to open in a new tab by doing Ctrl + middle click. A very handy feature as it let you retain groupings of web pages between different konqi windows. In KDE 4 you can configure Konqueror to either load new URLs into a new tab or into a new window - but no arrangement of meta-key modifiers lets you adjust this to the KDE 3 behaviour. So, definitely a regressive step. Work-aroundNo workarounds exist that provide the same functionality. You can always right-click on a URL and select whether to open in a new window or a new tab - but this is a right royal pain. At the moment I've set default to open-in-new tab, and do the right-click thing if I want to open in a new window. Bug reportAn existing bug report at https://bugs.kde.org/show_bug.cgi?id=170567 is tracking this problem.
Konqueror - detach-tab breaks the toolbar layoutExplanationThis is related to the bug above (konqueror - html toolbars break on reload of session / etc). It seems to rely on that bug manifesting, actually, before this one does. Two tabs - detach one, and it opens in a new window. The new window should be a normal web-browsing profile konqueror window, with icons and so on in all the right places. It is not. The three pictures here show 1) normal good window with single tab, 2) second tab created and toolbars still okay, and then 3) the second tab contents after detaching and showing the screwed up location (all reverted to top) and settings (icons+text now shown) for the toolbars.
Work aroundNone available Konqueror - find function now limited to 'inline' onlyExplanationKonqi's find function used to give you a dialog box that let you do find next, go backward, flip to case-sensitive, etc - all with a single click (each option was presented). It also didn't take up an additional 30 x screen-width pixel area for the privelege. Under KDE 4 you get the 'extended status bar' approach to find that every other browser suffers from, and no option to revert to the way that every KDE user had previously gotten used to. If you want to select case-sensitive searches, it is now two clicks rather than one. Ditto backward searches. Ditto everything. The goal should be to simplify, not increase the number of clicks to get things done! Work-aroundThere's a solution to this one ! Very much bigtime happiness about this. Someone told me what to do, and it's a bit weird - but it works. It's a possible hint of other fixes - insofar as you have to go into a different application's settings dialog - but all hints are good. Open up Dolphin (yes, Dolphin - even if you don't use it, konqueror apparently does on your behalf). Settings | Configure Dolphin | General | (unclick) Rename Inline You may need to open up a few more konqueror (file browser) instances to clear your cache of pre-loaded konquerors - but it does work. Bug report
Konqueror - HTML-Toolbar (font smaller / larger buttons) forgotten between sessionsExplanation
This means that I have three separate toolbars that make up my toolbar - which I keep on the left side of my konqueror window. Needless to say on KDE 3 this worked consistently and happily. With KDE 4, any konqueror web browser window that has two or more tabs will not remember this toolbar component, and they simply disappear on the next session. They do not get relocated to the top, or hiddden elsewhere - the toolbar settings show that the HTML toolbar is no longer shown. Work-aroundDon't use tabs. Meh. Konqueror - middle click on title bar does not lower windowExplanationThis is a standard feature of KDE 3 as well as KDE 4. It was working fine for me for the first few days, but now is not. It is extremely weird. Nothing has been done by me that should have affected this feature. One thing changed - and that was a major change to Xorg and HAL within Debian. This meant that xorg.conf no longer knows about devices - they're coming out of the HAL / FDI approach, which is all a bit new and scary to me at the moment. In any case, I didn't have middle button recognised at all for a while there, and then got it back. The weird thing is that middle-click will lower every other application window - it is only failing with Konqueror. (Both file and web instances, btw.) I had another test account - that I didn't use during the no-middle-button-crisis - and that works just fine with the middle button on konqueror windows now. So it appears to be something especially weird that was perhaps generated by the lack of middle button during one of the logins. Added weirdness - if a blocking child dialog window is open - eg. Configure Shortcuts - then you can use the middle-button to lower the parent konqueror window. More weirdness - ctrl-middle-click will lower the konq window (and all other applications). Work-aroundHold down ctrl a lot. Use Iceweasel. Revert to KDE 3.5.9 Fixed!System Settings | Input Actions Obviously this doesn't help any users who like to use gestures .. but, well, bugger them! This is the first 'fix' I've had (albeit for a bug that shouldn't have ever existed) - but I'm hoping that I'll start feeling some more love soon as a result. Disclaimer - I never fiddled with the gesture settings, so I'm still bewildered what caused this to stop working. I did add some hotkeys - alt-f6 (konq-web), alt-f7 (konq-file), prt-scr (ksnapshot) - but can't see how they would have influenced this problem. Konqueror - move tab doesn't play niceExplanationUsing the alt-shift-left and alt-shift-right key combos to move a tab left or right works only if the focus is in the tab contents. This is usually the situation when you use the key combo, however it's not guaranteed (your focus might be in the location bar). This is moderately irritating, but what really bites is that as soon as you move a tab left or right, konqueror changes focus to the Location bar! This means you have to use the mouse to click into the content (or press tab some weird and non-intuitive number of times) and then do the alt-shift-left/right thing again. Every other browser in existence lets you move tabs around with the mouse or with a key combo. Konqueror - progress pop-up dialogs don't play niceExplanationOn a slow machine, the black (ignoring the selected desktop theme!) mini-windows showing progress of downloads and copies, can stack up - four of them will obscure a quarter of my laptop's screen. Seriously. Work-aroundKDE 4.2.4 seems to handle these far more elegantly now - insofar as they don't default to never showing (you could tell KDE 3.5.x to have a single dialog for this, and like Firefox's download window you could tell KDE to not show it to you all the time). KDE 4.2.x has a little [?] thing that sits in the system tray that you can toggle visibility of these progress dialogs. New progress dialogs seem to force a showing of all active dialogs, which is a bit frustrating, particularly if you've just clicked the [?] thing to make them minimised. Even more annoying if you've got an auto-hide panel, I'd imagine. Bug report
Konqueror - scrolling is *very* slow with 3D effectsExplanationWhen scrolling up and down in a mostly text web page, response is hugely laggy compared to KDE 3. Disabling the desktop effects (alt-shift-F12, I think). Better yet, you can disable them permanently for your account using this line in your .kde/share/config/kwinrc : [Compositing] Enabled=false Alternatively, turn of composite in your xorg.conf file This might be related to my woeful 3D speed on this laptop, in turn related to a dodgy xorg configuration for the Intel chipset I'm on - but even that shouldn't impact this savagely on 2D scrolling of text/images in a web page. Work-aroundDisable desktop effects. Bug report
Konqueror - view page source (ctrl-u)ExplanationWhen doing a view page source of a page in konqueror web browser, it would launch OpenOffice Writer - and then show something approximating the rendered HTML (not the HTML source). It appears to be very much a Debian packaging issue, and was surprisingly tricky to track down the cause - it's obviously a mime / file association problem. FixI am pretty sure that this was text/plain - but I didn't note it down when I solved it. I did try a few other things, so be confident that it's fixable, even if this doesn't fix it for you: Konqueror | Settings | Configure Konqueror | File Associations | text / plain Move kwrite (or whatever you prefer - kate might be a better option, though after a teenage infatuation with a girl called Kate I still find it weird to type that name - though more pragmatically, on a slow machine kwrite is noticably faster to start than kate) to the top. If OpenOffice writer is already the preferred application, then it's a bit of a giveaway. If this doesn't fix it you can search for anything that has OpenOffice writer as the default app (you'll have to do a bit of clicking, you can't 'search' search, in case you just got excited for a second there).
Konqueror - wasted spacesExplanationKonqueror 4 (web mode) wastes inordinate amounts of space - around the menu bar, the location bar, the icons, and the status bar. Particularly painful on small monitors. Around 20% of the space is lost on header/footer components of konqueror, which is just abysmal. Work-aroundYou can minimise icons - but that introduces its own woes (konqi is handling these inconsistently for me at the moment). You can choose a window decoration that is narrow. You can remove text from all icons. You can drop in and out of full-screen-mode. None of these actually address the base problem - which is lots of blank space between entitites within konqueror's primary window. Bug reportExisting wishlist item - to add 'hide status bar' feature: https://bugs.kde.org/show_bug.cgi?id=177494 Existing item - to reduce space wastage in status bar: https://bugs.kde.org/show_bug.cgi?id=180856
KWeather users are left out in the rainExplanationKWeather is a funky little utility that parks itself into the sys-tray in KDE 3 - it shows - temperature, optionally wind speed and direction, and an icon reflecting the type of weather. Yes, you could look out the window for some of this, but that's not the point. It was actually very handy for telling you the weather in places that you were not in. KWeather does not appear to be available as a task bar widget for KDE 4. Work-aroundThere's two plasma weather plugins that Debian ships with, and these are quite competent - but they limit you to the desktop view (you can ctrl-F12 or whatever the shortcut is to 'show desktop', or keep one of virtual desktops empty so you can ctrl-F1 thru Ctrl-F6 to get to it, say) - but both are extra work. I've heard tell of people having a weather function in the panel, but I haven't got it working yet - it might just be a module that isn't shipped by Debian. Bug report
PrtScr (Print Screen) doesn't launch KSnapShotExplanationIn KDE 3, the PrtScr button would initiate KSnapShot (for capturing the screen or parts of the screen). In KDE 4 this key is assigned to 'print the page' from within whatever application is in use at the time. Arguably this is a benefit to some users, but it seems like those users could have made the reconfiguration, rather than people used to the status quo having to make it. {sigh} Work-aroundEasy enough. Run System Settings , then Input Actions | right-click in big empty space on left and do New Global Shortcut | Command / URL. Call it KSnapshot, enter something useful in the comment (General) field, and set Action-Command/URL to ksnapshot, and then hit the Shortcut button and then hit the PrtScr button - it'll ask if you want to reassign this key, and since you do, you click yes. Easy. Then Apply and you're done.
Quanta Plus users are left out in the coldExplanationQuanta's release cycle has been on the downward spiral for a while - for a variety of reasons - and apparently compiling the existing version to work in KDE 4 is a tad tricky. I haven't tried. Quanta's current release works fine in KDE 4 - it's just the package management doesn't let it live there (conflicts with dependencies). Work-aroundGrab the quanta packages from your local apt mirror and force install them, eg.
Whenever you do any subsequent apt-get install or upgrade work, it'll want you to fix this (apt-get -f install) before commencing on the new packages - which is fairly irritating. The Debian maintainers I've spoken to have separately suggested that yes, it should be reasonable to do an NMU on the quanta package to not have these unnecessary packaging dependencies, but on another occasion I've been told that Debian will drop quanta entirely from unstable Real Soon Now. This is a particular shame for me as I really like quanta, and the only reasonable replacement (netbeans) is a) slow as a wet week in August (it's a java app for flip's sake) and b) broken (it doesn't show tabs in the editor, and does very weird things with indenting). Bug reportDebian package (unstable) bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523551
Scrolling doesn't grant focus anymoreExplanationWith KDE 3, you could scroll (middle mouse button) on a window that wasn't in the foreground, and that window would get focus (while the foreground window would retain its position in the foreground). This was a very handy feature. It meant you could keep a foreground window where you wanted it, and start typing in an in-focus-but-background window. With KDE 4, this feature is only partially there - you can scroll in background windows, but focus doesn't change until you click (left mouse button). You have much the same options (in System Settings | Window Behaviour | Focus ) as 3.5.x offered - it just appears to be implemented differently. And, in my opinion, less intuitively. Or at the very least, because this was a change to the existing behaviour, a configuration item should have been offered. Work-aroundNone, and it's very annoying (more annoying is that I've now gotten used to working around this short-coming - and I hate assimilating to feature-depleted software as if and when the feature ever comes back you tend to be so used to not using it that it's now wasted on you). Bug report
Startup (or login and logout) sounds are backExplanationIn a move guaranteed to remind you of those noobs on the plane with their XP startup sound bothering everyone else, there's startup and shutdown audio snippets played with KDE4. I think the way to turn them off is a little less intuitive than in KDE3, but that may be just me. Work-aroundPresented here for reference of people a tad confused about controlling these sounds.
There does not appear to be a way to disable all system notification sounds in one fell swoop, which if true is a bit of a backward step.
Taskbar sorting (manually) is brokenExplanationIn KDE 3.x, the default 'sort' for items in your task bar was, as new applications were launched, they'd appear to the right of existing applications in your task bar. This was pleasantly predictable - things stayed where you first saw them - and so it was quite workable. With KDE 4.2.x this option had gone, and was replaced by 'no sort' (which seemed to randomly shuffle them around when you weren't looking) , 'alphabetical' (which just seems wrong given task names for browsers, f.e., seem to adopt the URL of the site you're on) and 'manually sort' (which would have been far less cynical if KDE 4.2.x didn't crash so danged often). As it happened, manually sorted was the closest approximation to predictable that I could get - I'd rather sort my applications for each of my 6 virtual desktops once, at login, and get the benefit of a consistent location for certain key apps, even if that only gave me a few hours of predictability before the next crash. With KDE 4.3 the options are still the same, but manual sort is now broken - it simply doesn't respect the changes you make. Sure, you can make 'em, move things around and so on, but when you leave and then return to that virtual desktop the order of your applications in the task bar has reverted to some internal machine-preferred order. Work-aroundNone as such. Bug ReportThere's an extant bug report at b.k.o for this problem with KDE 4.2, but seems appropriate to extend this to the 4.3 manifestation : http://bugs.kde.org/show_bug.cgi?id=178032 There's a possibly better one, specific for KDE 4.3 at https://bugs.kde.org/show_bug.cgi?id=202562 - though Aaron is claiming that this is normal behaviour for 4.x. It certainly isn't - this worked just fine in 4.2.2 and 4.2.4. Personally I'd be happy just to have the 3.5.x approach back again .. but I like dealing with predictable machines.
Window title context menu, and task's panel menu, differExplanationIf you right click on the title bar of a window, you get the usual context menu - advanced (keep above, keep below), send-to-desktop, maximise, minimise, etc. If you right-click on that window's entry in the panel you get a similar, though annoyingly not identical context menu. Obviously both menus should be the same. KDE 4.3 - this appears to be resolved! Bug ReportThere are two relevant bug reports: https://bugs.kde.org/show_bug.cgi?id=148074 - an existing one dating back to the 3.5 branch that describes the original inconsistency with the four additional 'advanced' menu items that appear when you right-click the title bar of a window. http://bugs.kde.org/show_bug.cgi?id=190823 - an existing one for 4.x that describes the problem with 'To Desktop' appearing at the top of the context menu from the title bar, but second (its original location in 3.5) from the top from the panel context menu.
Yakuake or session manager failing to retain settingsExplanationOn logout, and login - yakuake's settings are not retained. Any of them. Specifically observed with 'hide when focus lost' as well as showing tab bars, scroll history retained. Previous handy feature of yakuake - to utilise konsole's current profile - is not available anymore. Which is sad. Work-aroundMake your setting changes, and then quit yakuake, and then re-start it. Settings are saved at exit - and seemingly the exit triggered by logout doesn't provide enough of a trigger, or enough time, for yakuake to save its settings - but exiting it does. Appendix A - Weird things I've seen but can't reliably reproduce (yet)I've seen things you people wouldn't believe. Things that I can't explain, never saw happen under KDE 3, can't replicate (so can't file a bug for) and Mulder isn't take my calls about. I will try to migrate this stuff into the primary list of bugs above (and subsequently file bug reports for them) as I work out ways to reliably reproduce them. Konqueror - menu items in wrong orderI'm not sure how this happened - and I spent quite some time trying to reproduce the conditions (I'd just modified the khtmget toolbar component - removing the target icon from same) but never could. It's just plain weird. I haven't seen this happen again in KDE 4.2.4 Graphic artefacts - seemingly limited to konquerorOn session re-start, konq suffers from bad screen artefacts a bit too often, and in ways that almost hint at graphic card problems - I'd buy the latter if a) I hadn't changed my xorg video driver, and b) I hadn't changed it to something hugely generic ('intel' as it happens, from the 810 specific driver). Creating a new konq browser, cutting-and-pasting the URL across, and it loads and displays just fine. 2009-07 addenda - I've not seen many artefact bugs with my desktop (nVidia, proprietary drivers, 22" screen, KDE 4.2.4). Swapping from full screen videos (xine etc) to windows will often show the original background - not my chosen desktop background - you know, the KDE shipped one with the bubbles. Konqueror loads from cache, rather than web site, on start-upOn session restore, konq seems to consistently reload the page from its internal cache, rather than (as with 3.5.9) hitting the site again. It's extra weird, because KDE 4 seems to take a lot longer to start up than my 3.5.9 session did (and I used to have about 40 konq windows open with 3.5.9 - so far with 4.2.2 I've been sticking to around 5 windows). A frustrating 'feature' given I then have to go and hit reload on each of those pages before trusting their content. EDIT: Configure Konq | Web Browsing | Cache - turn off - experimenting with this option.
Appendix B - Things that I suspect have gone forever and sadly doubt will ever come back (but still want to complain about)Show all windows on all desktops - middle-click on backgroundA frequently useful shortcut - middle click on any desktop's background, and you'd get a full list (itemised by desktop name/number) of all application windows currently running (minimised or otherwise). I suspect the response is that this feature is replaced by the 'expose'-esque function. However, that function a) only works if you are running desktop effects (not everyone does), and b) only shows application windows on the current desktop (not all your desktops - which is when you need it most - when you've 'lost' a running application somewhere). |