Bug 171186 - Editing the toolbar hides it
Summary: Editing the toolbar hides it
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-16 23:00 UTC by Ivo Anjo
Modified: 2008-10-13 23:41 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ivo Anjo 2008-09-16 23:00:23 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

Right-clicking the okular toolbar, selecting "configure toolbars" and adding or removing something to the toolbar makes it disappear when you click ok on the toolbar editing dialog.

(Settings > Show toolbar Still works makes it visible again though)
Comment 1 Pino Toscano 2008-10-12 18:32:17 UTC
Fixed in KDE 4.2 (r870502) and KDE 4.1.3 (r870503).
Comment 2 Rafael Fernández López 2008-10-12 20:23:35 UTC
This is a general problem happening in very single KDE application. I am looking for a fix in KToolBar (ktoolbar.cpp, where the problem resides). Any other local fix on the application is just a workaround for the original problem.

When you add/remove an action to the toolbar, the original xml file is read and applied again to the client, what makes for instance being read "hidden = 'true'" and applied (so the toolbar is hidden). This fix is needed in KToolBar.
Comment 3 Pino Toscano 2008-10-12 20:33:01 UTC
> This is a general problem happening in very single KDE application.

Not all of them, just the kparts carrying on a "manual toolbar editing code" from KDE 3 times (modulo porting to KDE 4, of course).

> I am looking for a fix in KToolBar (ktoolbar.cpp, where the problem resides).

Yay, thanks.

> Any other local fix on the application is just a workaround for the original
> problem.

Well, in this case that cleanup was not a bad idea either: a flag more to do all the job :)
Comment 4 Rafael Fernández López 2008-10-12 21:15:01 UTC
(In reply to comment #3)
> > This is a general problem happening in very single KDE application.
> 
> Not all of them, just the kparts carrying on a "manual toolbar editing code"
> from KDE 3 times (modulo porting to KDE 4, of course).

Well, right, that's the detailed description =) Also the application needs to have more than one toolbar, and the one being shown with 'hidden = true' set as flag on the rc file. I suppose is the case, right ?


> > I am looking for a fix in KToolBar (ktoolbar.cpp, where the problem resides).
> 
> Yay, thanks.

=) I started to have a look yesterday night to this problem due to a similar report on Kontact till I saw that yes, it is actually a problem on KToolBar. Let's hope I can have enough time this week to fix this one.

> > Any other local fix on the application is just a workaround for the original
> > problem.
> 
> Well, in this case that cleanup was not a bad idea either: a flag more to do
> all the job :)
> 

I am unable to find that commit... :(
Comment 5 Rafael Fernández López 2008-10-13 23:41:49 UTC
SVN commit 871100 by ereslibre:

Fix the problem of a toolbar being hidden if adding/removing actions on another toolbar. Just have to disable temporarily the auto save setting of the main window while we
regenerate the interface. It happens that in the case that auto save is enabled, the main window is listening to appearance changes. After removing and readding all the
containers of the window, KToolBar::loadState() was being called (on createContainer()), which was triggering a save on the rc file of the app, saving the settings that
XMLGUI has just set, and overriding the real user set ones. This disables this temporarily, and sets auto save again back when the rebuild has finished.

BUG: 105525
BUG: 170150
CCBUG: 171186


 M  +29 -0     kedittoolbar.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=871100