> On Nov. 16, 2015, 1:15 p.m., René J.V. Bertin wrote:
> > Here's a debugging trace after hitting a breakpoint set on the qFatal() 
> > statement I put into `MacPoller::stopCatchingIdleEvents` . One can see 
> > `KIdleTime::stopCatchingResumeEvent` being called in frame 1, but I cannot 
> > identify the calling frame. It doesn't appear to be 
> > `KIdleTimePrivate::_k_resumingFromIdle()` (a breakpoint in there isn't hit).
> > 
> > 
> > ```C++
> > Process 88123 launched: 
> > '/Applications/MacPorts/KF5/examples/kidletime_example.app/Contents/MacOS/kidletime_example'
> >  (x86_64)
> > starting the idletime poll QTimer with interval 0 and m_minTimeout -1 ; 
> > start of catch
> > Your idle time is 595
> > Welcome!! Move your mouse or do something to start...
> > Great! Now stay idle for 5 seconds to get a nice message. From 10seconds 
> > on, you can move your mouse to get back here.
> > If you will stay idle for too long, I will simulate your activityafter 25 
> > seconds, and make everything start back
> > Appended timeout 5000 ; min.== -1
> > Appended timeout 10000 ; min.== -1
> > Appended timeout 25000 ; min.== -1
> > stopping the idletime poll QTimer; end of catch, idle= 2
> > Process 88123 stopped
> > * thread #1: tid = 0x37451f, 0x0000000104fb4359 
> > KF5IdleTimeOsxPlugin.so`MacPoller::stopCatchingIdleEvents(this=<unavailable>)
> >  + 297 at macpoller.cpp:372, queue = 'com.apple.main-thread', stop reason = 
> > breakpoint 1.1
> >     frame #0: 0x0000000104fb4359 
> > KF5IdleTimeOsxPlugin.so`MacPoller::stopCatchingIdleEvents(this=<unavailable>)
> >  + 297 at macpoller.cpp:372
> >    369      if (m_idleTimer) {
> >    370          qDebug() << "stopping the idletime poll QTimer; end of 
> > catch, idle=" << poll(false);
> >    371  // stopCatchingIdleEvents is called after each resumingFromIdle 
> > signal??!
> > -> 372          qFatal(__FUNCTION__);
> >    373          m_idleTimer->stop();
> >    374      }
> >    375  #endif
> > (lldb) bt
> > * thread #1: tid = 0x37451f, 0x0000000104fb4359 
> > KF5IdleTimeOsxPlugin.so`MacPoller::stopCatchingIdleEvents(this=<unavailable>)
> >  + 297 at macpoller.cpp:372, queue = 'com.apple.main-thread', stop reason = 
> > breakpoint 1.1
> >   * frame #0: 0x0000000104fb4359 
> > KF5IdleTimeOsxPlugin.so`MacPoller::stopCatchingIdleEvents(this=<unavailable>)
> >  + 297 at macpoller.cpp:372
> >     frame #1: 0x000000010000b2c1 
> > libKF5IdleTime.5.dylib`KIdleTime::qt_static_metacall(QObject*, 
> > QMetaObject::Call, int, void**) [inlined] 
> > KIdleTime::stopCatchingResumeEvent() + 43 at kidletime.cpp:113
> >     frame #2: 0x000000010000b296 
> > libKF5IdleTime.5.dylib`KIdleTime::qt_static_metacall(_o=<unavailable>, 
> > _c=<unavailable>, _id=<unavailable>, _a=<unavailable>) + 582 at 
> > moc_kidletime.cpp:113
> >     frame #3: 0x0000000101141252 
> > QtCore`QMetaObject::activate(sender=0x00000001041161f0, 
> > signalOffset=<unavailable>, local_signal_index=<unavailable>, 
> > argv=<unavailable>) + 2978 at qobject.cpp:3713
> >     frame #4: 0x0000000101141252 
> > QtCore`QMetaObject::activate(sender=0x00000001041071c0, 
> > signalOffset=<unavailable>, local_signal_index=<unavailable>, 
> > argv=<unavailable>) + 2978 at qobject.cpp:3713
> >     frame #5: 0x0000000101139740 
> > QtCore`QObject::event(this=0x00000001041071c0, e=<unavailable>) + 48 at 
> > qobject.cpp:1220
> >     frame #6: 0x000000010004854b 
> > QtWidgets`QApplicationPrivate::notify_helper(this=<unavailable>, 
> > receiver=0x00000001041071c0, e=0x00007fff5fbfd4e0) + 251 at 
> > qapplication.cpp:3716
> >     frame #7: 0x000000010004b904 
> > QtWidgets`QApplication::notify(this=<unavailable>, receiver=<unavailable>, 
> > e=<unavailable>) + 8212 at qapplication.cpp:3681
> >     frame #8: 0x0000000101110703 
> > QtCore`QCoreApplication::notifyInternal(this=<unavailable>, 
> > receiver=<unavailable>, event=<unavailable>) + 115 at 
> > qcoreapplication.cpp:970
> >     frame #9: 0x0000000101163d16 
> > QtCore`QTimerInfoList::activateTimers(this=0x0000000104059b10) + 1270 at 
> > qcoreapplication.h:224
> >     frame #10: 0x0000000104ca5502 
> > libqcocoa.dylib`QCocoaEventDispatcherPrivate::activateTimersSourceCallback(info=0x0000000104059a90)
> >  + 18 at qcocoaeventdispatcher.mm:121
> >     frame #11: 0x00007fff90e4e5b1 
> > CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 
> > 17
> >     frame #12: 0x00007fff90e3fc62 CoreFoundation`__CFRunLoopDoSources0 + 242
> >     frame #13: 0x00007fff90e3f3ef CoreFoundation`__CFRunLoopRun + 831
> >     frame #14: 0x00007fff90e3ee75 CoreFoundation`CFRunLoopRunSpecific + 309
> >     frame #15: 0x00007fff93440a0d HIToolbox`RunCurrentEventLoopInMode + 226
> >     frame #16: 0x00007fff934407b7 HIToolbox`ReceiveNextEventCommon + 479
> >     frame #17: 0x00007fff934405bc 
> > HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 65
> >     frame #18: 0x00007fff8ac9c24e AppKit`_DPSNextEvent + 1434
> >     frame #19: 0x00007fff8ac9b89b AppKit`-[NSApplication 
> > nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
> >     frame #20: 0x00007fff8ac8f99c AppKit`-[NSApplication run] + 553
> >     frame #21: 0x0000000104ca611d 
> > libqcocoa.dylib`QCocoaEventDispatcher::processEvents(this=0x0000000104056170,
> >  flags=<unavailable>) + 2189 at qcocoaeventdispatcher.mm:418
> >     frame #22: 0x000000010110de2d 
> > QtCore`QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) [inlined] 
> > QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 381 at 
> > qeventloop.cpp:128
> >     frame #23: 0x000000010110de14 
> > QtCore`QEventLoop::exec(this=0x00007fff5fbfee70, flags=<unavailable>) + 356 
> > at qeventloop.cpp:204
> >     frame #24: 0x0000000101110ca5 QtCore`QCoreApplication::exec() + 325 at 
> > qcoreapplication.cpp:1234
> >     frame #25: 0x00000001000025ec kidletime_example`main(argc=1, 
> > argv=<unavailable>) + 60 at main.cpp:29
> >     frame #26: 0x00007fff8d7ef5fd libdyld.dylib`start + 1
> > ```
> 
> René J.V. Bertin wrote:
>     Line 113 in moc_kidletime.cpp reads
>     
>     ```C++
>             case 7: _t->stopCatchingResumeEvent(); break;
>     ```

Ok, so apparently `KIdleTimePrivate::_k_resumingFromIdle()` does get called, 
and it's that method which then calls `stopCatchingResumeEvent`.

If that's the intended behaviour, why does the KIdleTime example work on Linux, 
without "restarting" `catchNextResumeEvent`??


- René J.V.


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


On Nov. 15, 2015, 11:58 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126078/
> -----------------------------------------------------------
> 
> (Updated Nov. 15, 2015, 11:58 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kidletime
> 
> 
> Description
> -------
> 
> I noticed that the KIdleTime example doesn't work properly on OS X, and that 
> the plugin for OS X still uses the deprecated Carbon-based algorithm that I 
> already patched for KDE4.
> 
> This patch is a work-in-progress (hence the qDebugs) update to use IOKit, 
> IORegistry and CoreServices to do idle-time calculation as it should be done, 
> and allow simulated user activity through a "less deprecated" function.
> 
> 
> Diffs
> -----
> 
>   src/plugins/osx/macpoller.cpp ad9c10f 
>   src/plugins/osx/CMakeLists.txt e1b50b8 
>   src/plugins/osx/macpoller.h ef51ea5 
> 
> Diff: https://git.reviewboard.kde.org/r/126078/diff/
> 
> 
> Testing
> -------
> 
> On OS X 10.9 with Qt 5.5.1 and frameworks 5.16.0 .
> 
> The example now works: when I set a QTimer with interval==0, the expected 
> wait for user input (`resumingFromIdle` signal) works. However, I am getting 
> a `stopCatchingIdleEvents` signal which means the application waits forever, 
> without ever getting to compare idle time to the list of timeouts.
> I haven't been able to figure out where that signal comes from, nor why this 
> doesn't happen on Linux.
> 
> Surely I'm missing something, but what?
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Reply via email to