[KDE/Mac] Review Request 119533: Make ktimetracker build on OS X, where it uses a native method from the ApplicationServices framework for idle time detection, instead of the XScreenSaver.

[René J.V. Bertin]

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


in mainwindow.cpp I added:
#ifdef Q_OS_MAC
75	
	   // not sure if this is really required but this is the code that works for me with g++-mp-4.8
76	
	   static KParts::ReadWritePart *rwp = factory->create<KParts::ReadWritePart>( this );
77	
        static ktimetrackerpart *mp = dynamic_cast<ktimetrackerpart*>( rwp );
78	
        m_part = dynamic_cast<ktimetrackerpart*>( rwp );
79	
	   kError() << "this=" << this << "; rwp=" << rwp << "; mp=" << mp << "; m_part=" << m_part;
80	
#else

turns out that this doesn't work when building with clang 3.4 (which is the current default compiler on OS X 10.9). the `kError` statement prints this:

ktimetracker(92451): this= MainWindow(0x117929f20) ; rwp= ktimetrackerpart(0x103defe60) ; mp= QObject(0x0)  ; m_part= QObject(0x0)  

which means back to the drawing board. 

How can it be that rwp is identified as a (pointer to a) `ktimetrackerpart`, and yet a `dynamic_cast<ktimetrackerpart*>` returns NULL??

Does that have anything to do with the comment just above my change,

        //NOTE: Use the dynamic_cast below. Without it, KPluginLoader will use a qobject_cast
        // that fails, because ktimetrackerpart is defined twice, once in ktimetracker's binary
        // and another one in the plugin. The build system should be fixed.
        //m_part = factory->create<ktimetrackerpart>( this );

meaning someone would have to do the (apparently) required fix to the build system in order for this to work?

- René J.V. Bertin


On July 31, 2014, 10:27 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119533/
> -----------------------------------------------------------
> 
> (Updated July 31, 2014, 10:27 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDEPIM.
> 
> 
> Repository: kdepim
> 
> 
> Description
> -------
> 
> Signed-off-by: RJVB <rjvbertin at gmail.com>
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt.orig d12b90a 
>   ktimetracker/CMakeLists.txt bf7b0ef41d851055359dc2cdcb2d2d3cbce25a6d 
>   ktimetracker/idletimedetector.h 524f739e89a77d1dbd732af8f258b3276e994eba 
>   ktimetracker/idletimedetector.cpp 250dda55582f53cfc44242582dee7e07062f5358 
>   ktimetracker/ktimetrackerutility.cpp efeba3abdc94a3725f0e0d6a9b663959a06dcc1f 
>   ktimetracker/mainwindow.cpp 56d4c286213507490b31fb131f1097a4c00b7abe 
> 
> Diff: https://git.reviewboard.kde.org/r/119533/diff/
> 
> 
> Testing
> -------
> 
> Testing was done under KDE and KDEPIM 4.12.5, MacPorts. The patches from that version applied without issues on the code in git, with 2 exceptions that I could re-apply manually easily.
> 
> With these patches, ktimetracker builds and launches under OS X (•) and loads existing ktimetracker.ics files correctly. The idle time detection feature appears to work as far as I'm able to tell (I don't use it under Linux).
> 
> What remains to be done is to double-check the timing precision: I've had an impression that timing may be too fast but haven't been able to prove timing isn't correct.
> 
> The history output to clipboard feature does ignore the date range and "output only the selection" options; removing entries originating from Linux we have
> 
> "test"	0.00	0.00
> "test->test 1"	0.07	0.03
> "test->test 2"	0.00	0.06
> "test->test 3"	0.00	0.03
> "test->test 4"	0.00	0.03
> 
> and the timing output (which does honour the "output only the selection" option):
> 
> Totaux des tâches
> 20140729 13:09
> 
>  Durée    Tâche
> ----------------------------------------------
>   0:12    test
>    0:05    test 1
>    0:03    test 2
>    0:02    test 3
>    0:02    test 4
> ----------------------------------------------
>   0:12 Total
> 
> 
> •) this supposes libical is installed and built following https://trac.macports.org/ticket/44469, i.e. using cmake instead and including a patch from Ubuntu.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20140915/26ba7146/attachment.html>