[Kde-pim] Review Request: Automatically start akonadi when necessary

Robert Marmorstein robert at narnia.homeunix.com
Wed Aug 12 19:24:37 BST 2009



> On 2009-07-20 18:03:46, Kevin Krammer wrote:
> > trunk/KDE/kdepim/kpilot/conduits/akonadibase/akonadisetupwidget.cc, line 64
> > <http://reviewboard.kde.org/r/1090/diff/1/?file=8699#file8699line64>
> >
> >     I think you should complete the setup of the widget before doing the Akonadi thing.
> >     
> >     You could also try Control::widgetNeedsAkonadi()

Okay.  I had tried widgetNeedsAkonadi with no luck.  The problem is that it falls through that function and then tries to use Akonadi even though it is no longer available.  I will create a new patch that wraps the initialization code in an if statement (using ServerManager::isRunning()).


- Robert


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


On 2009-07-20 16:32:40, Robert Marmorstein wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1090/
> -----------------------------------------------------------
> 
> (Updated 2009-07-20 16:32:40)
> 
> 
> Review request for KDE PIM, Jason Kasper and Bertjan Broeksema.
> 
> 
> Summary
> -------
> 
> This patch uses Akonadi::Control::start to automatically launch akonadi under the following circumstances:
> 
> 1.  A configuration dialog is launched that needs access to the Akonadi Collection List.
> 
> 2.  The "isOpen" function is called on an akonadi-based conduit.
> 
> This second step means that whenever we sync to an Akonadi conduit, the akonadi server will be started -- or else we abort the sync with an error.
> 
> I have tested this with my LifeDrive and it works for me.  However, I think the "isOpen" solution is a little hacky.  Perhaps a better solution would be to start the server in the loadRecords function.  The problem with this is that "isOpen" will cause the sync to abort before loadRecords is even called.  One possible solution is to move the functionality of isOpen into the loadRecords function and get rid of isOpen calls everywhere.  This is a more invasive procedure, since it would require updating all of the existing akonadi-based conduits to eliminate the "isOpen" check, but I think it is probably the right direction to go, long-term.
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdepim/kpilot/conduits/akonadibase/akonadidataproxy.cc 999887 
>   trunk/KDE/kdepim/kpilot/conduits/akonadibase/akonadisetupwidget.cc 999887 
> 
> Diff: http://reviewboard.kde.org/r/1090/diff
> 
> 
> Testing
> -------
> 
> Pulled up settings dialog.  Akonadi server was started and I was able to select a collection.  Turned off akonadi server using akonadictl.  The error overlay WAS displayed and the collection dialog was disabled.  Started akonadi server again, overlay disappeared and I was again able to configure a collections.  Then turned off akonadi server and started a sync.  The akonadi server was started and I synced succesfully.
> 
> 
> Thanks,
> 
> Robert
> 
>

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/



More information about the kde-pim mailing list