[kde-linux] Re: Konqueror Toolbar stability

[Duncan]

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