Next stop on toolbar handling. Konqueror (& more)

[Rafael Fernández López]

Hi,

> 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...

I have changed this on Kontact. And yes, against all bets I would say "yes, I 
expect the main toolbar to go up". Why ?

My reason is the next. Suppose Kontact, now that we are with it:

Component 1:

| Main toolbar            | Second toolbar                                  |

Component 2:

| Main toolbar                                           | Second toolbar   |

Since components can (and usually will) modify the main toolbar (and other 
critical GUI elements), it is possible that I want the main toolbar to be
moved to somewhere else for only the Component 2, for having the Second 
toolbar more handy on the Component 2 (while on the Component 1 it is on the 
top still).

I agree we have a very bad limitation on handling toolbars manually... but 
maybe we just don't need it.

The case of Konqueror is pretty critical, since the Konqueror and KHTML 
component look the same to the user.

What I really think is that we need a way of being able to handle this better. 
We need to be able to let the designer of the app decide whether if the user 
is moving the main toolbar somewhere else in one component, it is seen by the 
rest (take in count you might not want that, and that is what I want you to 
also see, that other use case).

But in general yes, if we are willing to work on that (I am willing to work on 
XMLGUI and in general improvements, whatever is needed), yes, we actually need 
more power into toolbars.

Another problem, and pretty offtopic, is that we are absolutely ignoring the 
icons kcm... it would be great to have it in count, and take icon sizes and 
effects... on other case, we should just take that kcm off (or the tab only).


Regards,
Rafael Fernández López.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080828/5f0612f9/attachment.sig>