I like my rekonq without the bookmark toolbar and as such I go to the rekonq popup and turn it off using the "Bookmarks Toolbar" menu entry. The problem is that on quitting and restarting rekonq it re-appears every time. I expect that turning off the toolbar will cause it to be removed after a restart too.
On Sunday 28 November 2010 21:35:16 Thomas Zander wrote: > https://bugs.kde.org/show_bug.cgi?id=258224 > > Summary: Bookmark toolbar re-appears at every restart > Product: rekonq > Version: latest git snapshot > Platform: Unlisted Binaries > OS/Version: Linux > Status: NEW > Severity: normal > Priority: NOR > Component: general > AssignedTo: adjam7@gmail.com > ReportedBy: zander@kde.org > > > I like my rekonq without the bookmark toolbar and as such I go to the > rekonq popup and turn it off using the "Bookmarks Toolbar" menu entry. > > The problem is that on quitting and restarting rekonq it re-appears every > time. I expect that turning off the toolbar will cause it to be removed > after a restart too. Thomas, are you on Kubuntu?
I am on kubuntu, but compile my own Qt+kdelibs+kdebase+rekonq Should I update my kdebase (using 4.5 branch here)?
Not exactly. I heard this problem 3 times in the last days. And everytime from kubuntu users. I suspect it depends on the menubar "abstraction" you have on default on kubuntu. Do you use it?
Not sure what a menubar abstraction is, but I'm not running a lot of the (k)ubuntu software. Basically nothing higher than X11. Also my distro is 9.10, so not exactly recent. (hence the self-compiled kde). I was more thinking that the problem was in rekonq. When I tried to fix the bug I noticed that the Qt restoring of toolbars is done first (a feature of QMainWindow) and then a little later the bookmarks toolbar is populated by removing it and re-creating it. Adding it unconditionally. Its been a little while since I looked into the sources, so the above may be wrong. I just recall the issue being something along those lines.
Is this fixed?
It still happens with 0.7.0 on KDE 4.6.3, openSUSE 11.4.
*** Bug 269953 has been marked as a duplicate of this bug. ***
I cannot think this is yet happening.
I could never reproduce this. Setting as worksforme in one week or two if no one jumps in again about.
It still happens to me with 0.8.1. 1) When I disable the toolbar and restart the browser, the toolbar is still shown,but the "Bookmark Toolbar" entry under configuration menu seems to be not set 2) When I click that again, nothing is changed but the entry, which is now shown as set 3) When I click the "Bookmark Toolbar" again, the toolbar is hidden for that window (for the new window, the toolbar is there again)
I yet could not reproduce it one time in a row.
Lucky you, unlucky me. Anything I could do to help you debug it?
Hello! I'm on debian testing (wheezy) and have installed rekonq 1.0 but the Bookmark Toolbar problem is still here. I disable it but everytime i restart rekonq, it re-appears. Any fix?
I could never yet reproduce this. How can I fix it?
*** Bug 303428 has been marked as a duplicate of this bug. ***
This also happens with rekonq 1.1-1 installed from debian/experimental. I unlock the toolbars, deselect the unnamed toolbar (why not named "bookmarks"?), the bookmarks vanish. I close rekonq, restart it - voilà, the bookmarks are visible again.
I just renamed ~/.kde/share/apps/rekonq so that rekonq starts with a fresh session. Results: 1. The unnamed toolbar now has a name. 2. When I hide the toolbar, it stays hidden. So there seem to be some old settings that "confuse" rekonq.
The problem/solution is somewhere in this rekonqui.rc: http://pastebin.com/BisscZXq When I delete it rekonq remembers the bookmarks' status and the toolbar has a name. As soon as I re-activate the rekonqui.rc the bookmarks toolbar has no name and rekonq cannot remember its state.
To be precise: in my old rekonqui.rc was missing this part: <ToolBar iconSize="16" iconText="icontextright" fullWidth="true" noEdit="true" name="bookmarkToolBar" newline="true"> <text>Bookmark Toolbar</text> </ToolBar> When I add it, everything is fine. It seems as if some former version of rekonq did not require/provide this line, I remember rekonq used the "small icons" size for the bookmarks bar (which it still does when this line is missing in rekonqui.rc). I guess after upgrading to some new version the new version could not find information about the bookmarks toolbar in the old rekonqui.rc and therefore no name was given to the bar and therefore the state of that bar couldn't be saved.
Hi Janet, and many thanks for this "deep analysis" of the problem. Anyway, it's very strange this happening as we correctly upgraded the ui.rc version number on every change there. So, I suspect the bug here comes from some other parts of kde code. Another strange thing I notice is that your ui.rc file is a bit different from mine here (aka, "the original one"): http://pastebin.com/NT9Hb5Fg. Why is it using kpartgui instead of gui? Is this common from kubunters? Thomas, you compiled it from source, what about yours?
hi Andrea, this rekonqui.rc is not from Kubuntu but siduction which is Debian Sid. But you are right, Debian and Kubuntu seem to use kpartgui instead of gui (I looked at some other ui.rcs from dolphin etc. on my system and a Kubuntu one). By the way I'm still using my old rekonqui.rc (not the new one), I just added the mentioned part about the bookmark toolbar. That was enough to make rekonq work as it should. Dolphin had the same problem after the upgrade from KDE 4.2 to 4.3 which introduced a new toolbar for the nepomuk search box, the existing users' dolphinui.rc was not updated, the nearly same toolbar part was missing: http://lists.kde.org/?l=kde-devel&m=124414293127403
> Thomas, you compiled it from source, what about yours? This bug is nearly 2 years old, I have to admit I have not been compiling rekonq for quite some time now. I also have not seen this bug for a while. (not sure how they relate) I didn't close it since there seem to be others that still have it, but I'm personally not bothered by this issue anymore :)
ok, closing as downstream. Janet's explanation seems enought exaustive about a fix for the issue and I think rekonq cannot be considered guilty if something in your distro changes our settings files.