Bug 105525 - Navigator toolbar disappears when reconfiguring other toolbars
Summary: Navigator toolbar disappears when reconfiguring other toolbars
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Unmaintained
Component: kdeui (show other bugs)
Version: 1.3
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2005-05-12 14:23 UTC by Raphaël Pinson
Modified: 2008-10-25 01:02 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raphaël Pinson 2005-05-12 14:23:28 UTC
Version:           inconnu (using KDE 3.4.0, Debian Package 4:3.4.0-0pre4 (3.1))
Compiler:          gcc version 3.3.5 (Debian 1:3.3.5-12)
OS:                Linux (i686) release 2.6.10-1-686

In Kontact, using a module (Kmail for example), I modify the module toolbar (adding an action to the KMail toolbar for example). When applying the changes, the Navigator toolbar from Kontact disappears. It does the same with all modules. 
I found a way to get the navigator toolbar again, by going to the summary view, select Configuration -> Select Components and Apply. This reloads the navigator toolbar.
Comment 1 Volker Krause 2005-07-15 18:53:22 UTC
The navigator toolbar doesn't really disappear but is completely cleared.
Comment 2 Steffen Fritzsche 2005-07-20 10:12:38 UTC
I have the same problem, after each restart of kontact the navigator bar is completly cleared. I have to modify the toolbar, for example switch the order of the icons and everything is fine.

I use Debian Unstable Packages KDE 3.4.1.
Comment 3 Tobias Koenig 2005-08-16 20:03:09 UTC
Yet another KXMLGUI bug :(
Comment 4 Baris Metin 2006-03-31 14:10:12 UTC
Same bug here with 3.5.2.

Bug arise if you right click the toolbar and configure it manually. Using Kontact's configuration interface works fine.
Comment 5 Thierry Arnoux 2006-07-19 10:40:21 UTC
Same bug with KDE 3.5.3.
It arises when configuring tool bar with right click or with Kontact's configuration interface.
Comment 6 Chris Gow 2006-10-28 16:16:57 UTC
Can not reproduce on KDE 3.5.5/Kontact 1.2.3 (Kubuntu 6.10/edgy).

Here's what I did:
First:

- Start kontact
- selected the kmail component
- Clicked on Settings > Configure Toolbars
- Selected Main Toolbar <kmail_part>
- Added "Brief Headers" from the available actions list to the current actions list
- Clicked apply then ok

Second:
- Selected kmail component, 
- right-clicked on kmail's toolbar
- selected configure toolbars from popup menu
- Selected Main Toolbar <kmail_part>
- Added action from the available actions list to the current actions list
- Clicked apply then ok

In both cases the kontact navigator bar did not disappear. When I clicked the apply button, the kmail toolbar did flash as it was regenerated

I believe the first test duplicated what the original poster attempted to do, the second test duplicated what subsequent commenters described
Comment 7 George Kiagiadakis 2008-09-30 09:55:17 UTC
I can unfortunately confirm this issue in kontact 1.3 svn trunk r865463 (KDE 4.1.68).

Steps to reproduce:
1) Switch to kmail part
2) Enable navigator toolbar (Settings->Toolbars->Navigator)
3) Right click on kmail toolbar and click configure toolbars.
4) Select Main Toolbar <kmail_part>
5) Add a new action.
6) Click ok. Now, the navigator toolbar is still there but shows no actions.

Note: This has nothing to do with the navigator sidebar on the left, which is not affected.
Comment 8 Rafael Fernández López 2008-10-13 00:50:03 UTC
This is basically the same bug as #171186. All KDE applications that use KParts are affected. The basics are:

1) You need to have two toolbars shown, for instance, the main toolbar and a toolbar "foo".

2) "foo" toolbar has to be defined on the .rc file of the app as 'hidden="true"'.

3) What happens is that when you add/remove an action, the whole GUI is reread and thus, KToolBar::loadState() is called, which reads the element dom node which contains 'hidden="true"' what is applied, hiding the toolbar "foo" when adding/removing an action on the main toolbar.

I am working on this fix.
Comment 9 David Faure 2008-10-13 10:40:35 UTC
A call to applyMainWindowSettings after rebuilding the GUI should solve this, no? Well, assuming autosave (or using saving into a temp file before hand if autosave is not set).
Comment 10 Rafael Fernández López 2008-10-13 23:41:47 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
Comment 11 David Faure 2008-10-25 01:02:03 UTC
SVN commit 875625 by dfaure:

Revert r871100 (as well as my createGUI commit), and fix both the "kedittoolbar hides toolbars"
and "<ToolBar hidden=true>" problems at the right level: by letting the guifactory tell the mainwindow
that it's making changes so the mainwindow shouldn't mark settings as dirty. With unit test.
CCBUGS: 105525, 170150, 171186


 M  +12 -38    dialogs/kedittoolbar.cpp  
 M  +11 -0     tests/kxmlgui_unittest.cpp  
 M  +13 -1     xmlgui/kxmlguifactory.cpp  
 M  +14 -3     xmlgui/kxmlguifactory.h  
 M  +12 -6     xmlgui/kxmlguiwindow.cpp  
 M  +3 -0      xmlgui/kxmlguiwindow.h  


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