Review Request: Provide (mostly) automatic synchronization between separate instances of KXMLGUIClient-derivatives

Thomas Friedrichsmeier thomas.friedrichsmeier at ruhr-uni-bochum.de
Fri Aug 14 13:11:06 BST 2009



> On 2009-08-14 08:04:33, Nick Shaforostoff wrote:
> > in case of several instances inside same process: am i right in that all the data is duplicated between all the instances? (if yes, why not store the data only once...)

Yes, but "all the data" in this case is one entry in the QString->KActionCollection* hash and one connected slot per instance (lines 72 and 73 of the patch). So that is little more than simply keeping track of all similar instances.

It is true, that each instance of the same KXMLGUIClient keeps a separate copy of the XML document. It might be possible to improve this, but such optimization should likely happen in KXMLGUIClient itself (and may not be quite trivial). This patch does not change anything in that respect.

One potential optimization in this patch would be to tell only one client to reload the XML, then pass the domDocument() using setDOMDocument(). In the case of many instances of the same KXMLGUIClient, this could save quite a few cylces looking up, parsing, and merging the XML files, though I'm not sure this would really matter in practice (keep in mind that these reloads happen after user-interaction, only). This would have the side effect of saving some memory via implicit sharing of the QDomDocument (*after* reloading, only). But again, if we are to do this sort of optimization, I believe it should go into KXMLGUIClient, directly.

Yet another potential optimization would be to limit rebuildGUIs() to really refresh the action properties and toolbars, only, not the complete gui. If anybody knows, just how to do that, that would probably be a good idea (and such functionality should be added to KXMLGUIFactory).


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1238/#review2023
-----------------------------------------------------------


On 2009-08-11 12:19:00, Thomas Friedrichsmeier wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1238/
> -----------------------------------------------------------
> 
> (Updated 2009-08-11 12:19:00)
> 
> 
> Review request for Kate and kdelibs.
> 
> 
> Summary
> -------
> 
> First to sum up the problem, I'm trying to solve. I'll use konqueror as an example:
> 1) Fire up two instances of konqueror. In one of the instances, set the shortcut of "Show History" to "Shift+F6". Now switch to the other instance: The change has not been propagated. Ok, perhaps you did not expect that to work in the first place, but now:
> 2) Fire up a single instance of konqueror, the open a new window (File->New Window). Do the same game as in 1. The change is not propagated between the two toplevel windows of the same konqueror instance, either. Finally:
> 3) Fire up a single instance of konqueror, with a single toplevel window. Open a second tab inside this window. Navigate both tabs to e.g. http://www.kde.org. Switch to tab A. Change the shortcut of "View Document Source" to "Shift+F6". Take a look at the "View"-menu to see the new shortcut. Now switch to tab B. Take another look at the "View"-menu. The shortcut is still at the previous setting, here. Switch back to tab A. The shortcut is back to the previous setting as well.
> 4) If you like to, play games 1-3 with modifying the toolbars, instead of shortcuts.
> 
> So much for the bug description. Konqueror is not really to blame, here, and neither is it the only application to be affected. The problem is that we're missing a mechanism to synchronize user settings between separate instances of KXMLGUIClients. That's what the new class KXmlGuiClientSyncer - contained in this patch - does. See the API-documentation within for usage details. For the "essence" of the code, see KXmlGuiClientSyncerPrivate::uiRcFileChanged().
> 
> Some points, I wasn't sure about:
> 1) Originally, I tried to incorporate this into KXMLGUIClient, directly (or rather KXMLGUIClientPrivate). That would have allowed for *fully* automatic synchronization, i.e. without having to register/watch the clients manually. However, kio depends on kdeui, and this would have added a cyclic dependency back to kio. Any idea on how to work around this? Or this semi-automatic solution safer in the first place?
> 2) I placed this inside kio, pretty much for the reason above. Is this appropriate?
> 3) Which kDebug area to use?
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdelibs/includes/CMakeLists.txt 1006783 
>   trunk/KDE/kdelibs/includes/KXmlGuiClientSyncer PRE-CREATION 
>   trunk/KDE/kdelibs/kdeui/xmlgui/kxmlguiclient.h 1009993 
>   trunk/KDE/kdelibs/kio/CMakeLists.txt 1006783 
>   trunk/KDE/kdelibs/kio/kio/kxmlguiclientsyncer.h PRE-CREATION 
>   trunk/KDE/kdelibs/kio/kio/kxmlguiclientsyncer.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/kio/kio/kxmlguiclientsyncer_p.h PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/1238/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Thomas
> 
>





More information about the kde-core-devel mailing list