Jerome Yuzyk posted on Sun, 12 Jun 2011 11:41:27 -0600 as excerpted: > WTF do I have to do to keep my Konqueror Toolbar settings? I keep having > to add and re-add the HTML toolbar as it disappears between Konq > sessions, > sometimes even from switching between KHTML and WebKit renderings. I'm > running 4.6.3 but this has been going on since 4.2. I've Saved View > Profile more than I can remember but it seems to matter little - once > the toolbar disappears it disappears for all new Konq sessions. Why > doesn't "Save" mean "Save?"
[Pardon me while I air my own gripes with konqueror, first. The discussion of your issue occurs at the bottom. Look for the "..." on its own line.] FWIW, I've been threatening to switch to firefox for some time, mainly because I prefer to keep scripting off by default and there's simply no way other than reading the source, in konqueror, to see what sites a particular page wants to run scripts from, in ordered to enable them individually. I've run konqueror for years and thus have my usual sites all configured to my liking, but new sites... forget it! I end up switching to firefox (with noscript) for them, sometimes just to see what sites want scripting so I can selectively enable them back in konqueror, if I even bother... The problem isn't really konqueror itself, as firefox on its own is pretty lame as well, it's that konqueror's share is so tiny on its own that there's no practical hope of attracting enough of a community around it to make for a viable extensions community. I've suggested that konqueror should complete the switch to webkit (which after all originated with khtml), and that all the webkit browsers should then cooperate to form a common extension standard, thus getting the critical mass that chrome/chromium does appear to be getting on its own, but slowly, with firefox having a huge head-start. If safari and chrome/ chromium/iron/etc and webkit based rekonq/konqueror and however many other little webkit based browsers were to cooperate on a common extension standard, the extension community would attain comparability with firefox's extension community somewhat faster. But alas, it doesn't appear that's going to happen, at least not in the near term. That might not be so bad for chrome/chromium, or even for safari, which have a reasonable community and may well reach extension community viability as it is (I believe chrome/chromium already has, tho it's still well behind firefox I believe, I honestly don't know about safari as it's Apple proprietary and I don't do proprietary, chrome wouldn't interest me for much the same reason, were it not for chromium), but it pretty much seals the fate of konqueror. Well, I finally threw in the towel and started to do just that, switch, changing the kde default web browser to firefox, starting the process of switching all my login info over (there's a kwallet integration extension for firefox, but the way the two browsers work is enough different that it's not the same, and the kwallet extension ends up being incredibly irritating as it triggers kwallet open prompts on *EVERY* page with a login, which appears from my short trial to be most of the web, these days), etc. So that's /my/ response to constant niggling konqueror frustrations. To be sure, firefox has some of its own, not the least of which being that it's gtk based (oh, that the qt-based-firefox UI project had gone somewhere!), but as I grab missing extensions and figure out the various config options, the worst ones are steadily disappearing, such that the worst remaining ones (the close kde integration possible with konqueror being an exception, of course, it NOT being possible with firefox, but mainly, that's just a matter of setting file associations among other config options, in two places, kde and firefox, rather than one) are less and less of a practical issue. My VERY strong feeling is that nearly ALL of the KDE devs and most of the users as well have long since done the same thing, or konqueror bugs such as the so long missing proper SSL certificate management (much better with 4.6, but not yet to where late 3.5 was by far) would have *LONG* *AGO* been fixed out of shear frustration of having to deal with them all the time. That they haven't been fixed... is as strong an indication as it gets, that few kde devs actually USE konqueror for browsing, that they've instead moved on to other things. Well, I guess I've finally joined them. =:^\ And I guess that means I'll be recommending the same for others, from now on. =:^\ Not that I wasn't having to recommend that before, out of simple practicality, but now that I'm not using konqueror as my default browser either... ... So however reluctantly, that's now my recommendation to you and others with unfixed for ages konqueror problems, as well. At some point it's simply time to give up and move on. Chrome or opera are well supported if you can handle proprietary (I can't and won't), chromium and firefox, particularly the latter, are open source alternatives supported by most distributions. Meanwhile, given that you say konqueror resets the toolbar config on its own, and that once it does, all new konqueror windows get the borked version... What it sounds like to me is that something (I don't know what) might be triggering konqueror to overwrite its own config. Once it does, the behavior would be as you reported, all new windows would appear with the config konqueror decided IT wanted, on its own, regardless of what YOU want. There are two possible fixes for this, depending on how deeply konqueror's overwriting is. Unfortunately, neither one is particularly user friendly and the second one requires a bit of messing around by hand with config files, but if you're upto it, one or the other will hopefully work. A brief bit of preliminary background. Fortunately, kde (including konqueror) continues to store the vast majority of its config in "ini style" plain text files and all that is required to edit them is a plain text editor and a basic knowledge of the ini format (line based, sections consisting of text with [] around them, followed by individual setting=value lines, lines starting with # are comments and ignored, as are blank lines). However, for performance reasons, the config in all these text files is read and cached in binary format at runtime, in what is called the Kde SYstem COnfig CAche, ksycoca, for short. A daemon called kded (simply kde daemon, I believe) is responsible for keeping the ksycoca and text-based config in sync automatically (among other things, it's also the bit of kde that responds to kde app queries regarding their config, I believe, and has other in-the-guts duties as well), but should they get out of sync for some reason, the kbuildsycoca4 command can be used to rebuild the binary cache based on what's in the text files. Based on that... the below assumes that if you set it correctly and quit kde, then login again, it remembers the /correct/ settings at least /some/ of the time, IOW, that the settings are actually written to the config files and something just triggers a reset from time to time... 1) If the problem is confined to ksycoca, then simply running kbuildsycoca4 (from a konsole window or krunner, noting that you'll probably get a lot of strange and somewhat alarming but generally harmless output if you run it from a konsole window where you can see it) should "remind" konqueror of the config found in its config files, and new instances should again get the config you've set. 2) If THAT doesn't work, then presumably konqueror is rewriting its config files when the problem triggers, as well, so you always get the bad config until you set it correct and save. If that's the case, then one thing that I've found to work on occasion, is to figure out what config file the app (konqueror in this case) actually stores this info in, set it correctly and save, then manually SET THAT FILE READ-ONLY, so the app can't as easily overwrite it. Sometimes that won't work either because the app saves the new config as a temp file and then renames it over the old one, but there are ways around that, too, if you're persistent enough. (If there's not too much else stored in the dir that needs rewritten frequently, setting the entire dir read-only can work. Or, ext2/3/4 filesystems in particular have an immutable attribute you can try. Or, you can use mount-bind to mount just that file from a different location, then change the mount options to enforce read-only -- of course this normally requires root privs and some knowledge of how Linux filesystems and mount works, but it's then enforced by the kernel at a filesystem level, and barring some major security bug, no mere user app is going to get thru THAT, so it's a solution that WORKS.) However, just setting the file read-only works in most cases. The problem then becomes one of figuring out just which file konqueror is storing that config info in. That's where strace comes in handy. strace -feopen konqueror, run in a konsole window, should produce the needed info, but lost amongst WAY too much other info to be useful. (-f says trace thru program forks, -eopen says trace only file-open calls, thus giving you the names of every file the app you trace tries to open.) So, pipe STDERR (file descriptor 2, STDERR being what all that tracing info is spit out on) to grep, grepping for only files in your home dir, something like this: strace -feopen 2>&1 | grep /home/myuser That should reduce the output dramatically, but it may still be too much. However, you should be able to either redirect that to a file, or narrow down the output further using grep, as necessary, assuming of course a bit of technical knowledge of grep and shell redirection, etc. What you're looking for is probably a file in $KDEHOME/share/config/, possibly with a name of the pattern konqueror*rc. If not, then look for something in $KDEHOME/share/apps/konqueror/* or similar. ($KDEHOME defaults to ~/.kde if unset, tho some distributions make that ~/.kde4 .) Assuming you know enough about the shell, grep, strace, etc, to pick it up from there, you should be able to do so. If not, welllll... back to my previous recommendation, throw in the towel on konqueror. <shrug> Similarly back to my previous recommendation, if you ALWAYS have to reset the toolbar, even if you set it, saved, and immediately restarted kde, thus indicating that the setting apparently isn't being saved at all. At some point you just have to throw in the towel. Of course, if even with the frustrations, konqueror remains a better alternative than the others, continue to use it... as I myself did for years. (In part, that was because I was compensating for some of konqueror's browsing deficiencies by using privoxy as an ad-blocker and junk-rewriting proxy, between me and the net. Actually, that simplified my transition to firefox as well, since I just set firefox to use privoxy too, and it "magically" inherited the same junk-busting settings I had it configured to deliver for konqueror. No need to worry about recustomizing ad-blockers, custom page filters I'd created over the years, etc, as I'd have to do if I for instance used firefox's greasemonkey extension for those sorts of things, now that I'm using firefox, and then tried to switch to something else) I know the above's not an easy thing for a non-technically-inclined user to do, and is rather a hassle even for a technically inclined user, but I guess that's just another reason so few continue to use konqueror, even on kde. <shrug> But at least there's something that at least the technically inclined users can do about it if they're sufficiently motivated, unlike the situation for many proprietary solutions. -- 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 ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
