[Kde-graphics-devel] Review Request 120920: Fill SendTo menu async to fix "Bug 312495 - Very slow 'Send to' menu"

[Albert Astals Cid]

> On nov. 8, 2014, 11:54 a.m., Aaron J. Seigo wrote:
> > So firstly: thanks for working on this; the slow menu population is indeed a wart on the application.
> > 
> > That said, I'd prefer to see it done with a QRunnable. There is less to get wrong than with a QThread, even though the code you have would remain nearly the same. (So little/no effort lost ...) The QRunnable would emit a signal with the populated list of actions which KSnapshot would then hang on to itself. It could even take a pointer to the parent QObject to parent the actions to (and move them to the same thread as that QObject) which would clean up a few more details.
> > 
> > With that done, this could certainly go into master as well as the frameworks branch (by which point kipi should be shortly on the way to being ported)

I find that QtConcurrent::run is usually easier than using a QRunnable, have a look at it too.


- Albert


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120920/#review70042
-----------------------------------------------------------


On nov. 1, 2014, 1:46 p.m., Gregor Mi wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120920/
> -----------------------------------------------------------
> 
> (Updated nov. 1, 2014, 1:46 p.m.)
> 
> 
> Review request for KDE Graphics, KSnapshot, Aaron J. Seigo, and Dominik Haumann.
> 
> 
> Bugs: 312495
>     http://bugs.kde.org/show_bug.cgi?id=312495
> 
> 
> Repository: ksnapshot
> 
> 
> Description
> -------
> 
> Hi, I also feel slightly impaired by Bug 312495 - Very slow "Send to" menu. So here is a fix.
> 
> It consists of the following commits:
>     1. move long-running retrieval of SendTo items to separate method
>     2. fillSendToActionsCache at startup but not yet async
>     3. move code related to SendTo actions to own class and file
>          (this includes the kipi code but KIPI_FOUND was not set in my dev env so thats not tested)
>     4. SendTo menu is built on a separate thread to speed up populating
>     5. delete actions in dtor
> 
> The SendTo actions are now created in QThread which is started on startup of ksnapshot.
> If the user opens the SendTo menu too soon there is a message (as single menu item) that says
> that the menu is still being constructed and that he/she should try a moment later.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 7ec17867e599fb8ea06b709e22fb7437e0207e9b 
>   ksnapshot.h 898e313cf963a132387e9e5ecf422f94a1437d0a 
>   ksnapshot.cpp 81ecd392ec7fe4076d68d0ef52ca82b6315bf150 
>   ksnapshotsendtoactions.h PRE-CREATION 
>   ksnapshotsendtoactions.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/120920/diff/
> 
> 
> Testing
> -------
> 
> 1. Start ksnapshot (notice that is as fast as before)
> 2. Immediately open SendTo menu => there is a message that the menu is not ready yet.
> 3. Try again after 1 second: menu is populated.
> 4. Close ksnapshot.
> 
> 
> 1. Start ksnapshot. Wait two seconds and then click SendTo menu
>    => menu is populated right away
> 2. Close it.
> 
> 
> 1. Start ksnapshot. Hit the SendTo menu with insanely high button click speed.
>    => No crash observed.
> 
> Could NOT test the moved kipi code because KIPI_FOUND is not set on my environment.
> 
> 
> Thanks,
> 
> Gregor Mi
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-graphics-devel/attachments/20141108/a95a0641/attachment.html>