Next stop on toolbar handling. Konqueror (& more)

[David Faure]

On Tuesday 26 August 2008, Rafael Fernández López wrote:
> Hi all,
> 
> When fixing the toolbar problems I was trying to make state of toolbars be 
> "active component" dependant, since for instance, the main toolbar can change 
> its number of items, and when loading and restoring from different parts, it 
> could lead to problems.
> 
> This was my first idea, and i thought it would have been great. However this 
> got me into problems when starting konqueror (konqueror component) and then 
> visiting "http://www.kde.org" (khtml component). Visually, they are exactly 
> the same, but when you move a toolbar after having entered into the web, and 
> restart konqueror, it would load the konqueror component config part, so the 
> toolbar you moved is remaining on the original position ("ignoring" the user). 
> This happened unless you marked as initial action "Show my initial page", 
> which loads khtml directly and when you restore/save you are doing everything 
> on the khtml component part.
> 
> Now, I really loved that approach since that was app and component dependant. 

But app-and-component dependent is a problem, as you found out.
Let's take another example: Kontact. If you move the main toolbar to the left side
while viewing mail, and then switch to the Calendar part, should the main toolbar
really come back up on top? I guess we'd agree on saying no, given that it's
a toolbar that is shared between all components. This is how the old code
worked, and I'm still sad that Qt4 doesn't offer us any way to position individual
toolbars (although, well, we could try move() on them maybe?
Failing that, I guess we're better with *one* window state being saved/restored
per application than telling users to do their configuration 10 times...

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).