Review Request 120202: [OS X] improvements to the kwallet/OSX keychain integration

Thomas Lübking thomas.luebking at gmail.com
Wed Sep 24 15:22:23 BST 2014



> On Sept. 21, 2014, 6:11 nachm., Thomas Lübking wrote:
> > kdeui/util/qosxkeychain.h, line 99
> > <https://git.reviewboard.kde.org/r/120202/diff/2/?file=314175#file314175line99>
> >
> >     If OSXKaychain is an exported class (i don't know), this is an ABI incompatible change.
> >     
> >     It's also massively invasive and adds quite some overhead.
> >     
> >     Why did you not just remove the #ifdef from the slot declaration in Wallet (former patch) and #ifdef the implementation body instead?
> >     (There are several such internal slots present, you don't have to "fix" the Wallet architecture with this patch ;-)
> >     
> >     
> >     If there's absolutely no other solution and you do not want to add the slot unconditionally, you can still reimplement protected ::timerEvent() and do the timer "the hard way", ie. "myTimer = startTimer(timeout); ... if (te->timerId() == myTimer()) { blahFoo; } else BaseClass::timerEvent(te);"
> 
> René J.V. Bertin wrote:
>     I would never have done things this way if QOSXKeychain was an exported class... but I'm sensible to the overhead argument. I also realise I could probably have declared it `protected QObject`.
>     I considered your suggestion, but decided against it because it would require patching kwallet.cpp too. Or at least I think it would, I presume one has to provide an implementation for every member function that's declared in the header? Unless one can make the declaration virtual and only provide an implementation in kwallet_mac.cpp (the sort of detail I just cannot seem to memorise :-/ )?
> 
> Thomas Lübking wrote:
>     Ah, I now see: The various backends do not inherit a common base but are just split by architecture (on the same header)
>     
>     As long as it's not referenced, a function does not have to be implemented.
>     BUT: moc will referece all slots, so NO. YOU MUST ADD IMPLEMENTATIONS EVERYWHERE.
>     
>     (What you must not do as well in this regard, is to introduce pure virtual functions, ie "virtual void foo() = 0;" - the class becomes abstract by this and cannot be instatiated)
>     
>     So the remaining option would be "int myTimer = QObject::startTimer(timeout);"
> 
> René J.V. Bertin wrote:
>     Is it a really a big issue to introduce an empty and unused slot in the other Wallet implementation? (After all, "my" Wallet implementation has a number of slots too that are there only to satisfy the needs of the other ;) )
> 
> Thomas Lübking wrote:
>     Not from my POV - it's far less invasive than altering the private baseclass.
>     You "decided against it" (although, timerEvent() would have to be implemented everywhere just as well)
>     
>     
>     Suggestion: isolate it by adding a QObject inheriting member to OSXKeyChain (to call a slot there) for this will no longer be a problem with Qt5 (YEAH for lambda slots! =)
> 
> René J.V. Bertin wrote:
>     Well, I "decided against it" until I realised it wasn't really a big deal :)
>     
>     Just how is "adding a QObject inheriting member to OSXKeyChain" any different in terms of additional overhead than just letting the class itself inherit QObject? 
>     
>     What I might do is define an additional class in QOSXKeychain.h, inheriting QTimer (which inherits QObject), give it a reference to the wallet instance, and then replace the QTimer* member in WalletPrivate with a pointer to that new class. That way the QObject overhead only occurs when I'm actually going to use the timer. Sounds like a plan to me (but that may just be the time of night ^^)

> how is "adding a QObject inheriting member to OSXKeyChain" any different in terms of additional overhead

Isn't at all.
It's just easier to revert since in Qt5 you can just use a lambda slot (what means you can write the functionality inline into the connect - no need for a slot function anywhere)
You can use the QTimer Object for this, yes (it'd be a bit wonky for some public interface, but as a semi-private class, there's no problem with this)


- Thomas


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


On Sept. 21, 2014, 4:40 nachm., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120202/
> -----------------------------------------------------------
> 
> (Updated Sept. 21, 2014, 4:40 nachm.)
> 
> 
> Review request for KDE Software on Mac OS X and kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> -------
> 
> I'm still working on (the KDE4-based version of) my OS X keychain backend for kwallet. I'm at a point where I think I can present a work-in-progress in an RR because at least one feature has been improved enough to be of interest for everyone, and also because I could use feedback on how to proceed.
> I'm currently focussing on 2 settings that are configured in the kwallet KCM (SystemSettings), and for which I'm working on an implementation not requiring kwalletd and/or DBus.
> 
> - idle time closing of wallets. This feature was not supported in the commited version presented in https://git.reviewboard.kde.org/r/119838/ The present patch adds an idleTimer and a shared lastAccessTime member. The idleTimer is reset each time a client performs one of a series of actions that I count as wallet accesses, and before resetting I update the idle timeout value from KConfig. When the timer fires, the elapsed time is compared to the shared last access time, and if it is >= the timeout, the wallet is closed. This applies only to "KDE keychains", so keychains used by OS X applications should not be affected.
> 
> - "close when last application exits". This requires maintaining a "user list" which keeps track of what application has what wallet open. I've implemented an "internal" version of such a registry, mapping wallet name to application names and the list of wallets they have open (a list of wallet reference, pid per application name). The registry is functional, but I have not yet decided (read: figured out) how to make a distributed representation of it.
> 
> So the work-in-progress concerns the distributed user registry. The idea would be to maintain the registry in shared memory, meaning it'd be reset (= disappear) when the last application exits, contrary to a file which can go stale. This would be simple if QSharedMemory objects could be resized, but apparently they cannot, so I'll have to look at other solutions possibly involving OS X frameworks (NSData and it's non-objectiveC version CFDataRef or CFMutableDataRef might be candidates). Suggestions welcome.
> 
> Other work in progress concerns a less wheel-reinventing approach that builds on kwalletd and DBus. I don't see why the code used in `kwallet.cpp` wouldn't work, but I must still misunderstand its finer details. The present patch contains outcommented code that does indeed cause kwalletd to be launched and slots and signals to become visible e.g. in `qdbusviewer`. But they don't work, which in turn makes the whole kwallet layer dysfunctional. Here too feedback is welcome on how what I'm missing and/or how to get this to work.
> Once kwalletd works, wallet idle timeout closing and closing when the last client exits should work out-of-the-box, or at least I suppose.
> 
> 
> Diffs
> -----
> 
>   kdeui/util/kwallet.h d7f703f 
>   kdeui/util/kwallet_mac.cpp 8344ebb 
>   kdeui/util/qosxkeychain.h d0934e6 
>   kdeui/util/qosxkeychain.cpp 7cb9a22 
> 
> Diff: https://git.reviewboard.kde.org/r/120202/diff/
> 
> 
> Testing
> -------
> 
> OS X 10.6.8, kdelibs 4.14.1 git/master, KDE/MacPorts 4.12.5 .
> Once finalised, all changes should port easily to KF5's kwallet_mac.cpp .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140924/27cdbcbf/attachment.htm>


More information about the kde-core-devel mailing list