Next stop on toolbar handling. Konqueror (& more)

Rafael Fernández López ereslibre at kde.org
Tue Aug 26 12:20:00 BST 2008


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. 
So, there are two solutions now I would like to give the approach:

1) Do something with Konqueror and get back the app + component internal 
saving. This would force Konqueror to set the active part to konqueror or 
khtml the whole time (except, if you enter for instance on Dolphin, which 
would be dolphinpart and is fine [see how your location bar is hiding some 
icons if you keep it on the same place as navigating the web]).

2) Let the internals as are at the moment and save in different groups 
depending on the component, taking in count if we are in konqueror or khtml we 
want to save to the same config group.

Why 2) is not the "ideal" one. Because this would force our developers to make 
the group component dependant on their code, and probably that would be nice 
to be hidden. For instance, as a developer, if we had chosen 2) I would have 
to write something like:

KConfigGroup cg(&cg, KGlobal::activeComponent().componentName());

Which I think it would be nice to be ignored from the developer point of view.

So, ideas, suggestions ?


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/20080826/b3b84f32/attachment.sig>


More information about the kde-core-devel mailing list