signals and slots vs. virtual_hook (was [PATCH] KFileDialog overwrite confirmation)

Rafael Fernández López ereslibre at
Tue Jul 15 22:28:22 BST 2008


> We could maybe add a marco which would do nothing in kde4, but that we
> could redefine in KDE5 to throw a compilation error or warning
> #define KDE5ERROR
> or something like that.
> but i'm not sure it would ease porting

Hmm, don't know... In theory just grepping for KDE*4 could make the trick. I 
am sure not everybody will agree defining "a macro?" which prints out a 
warning right now that we are working on KDE4, but an error that prints out an 
error on KDE5 is not very polite. ;)

> Over 3):  Adding a virtual function grow the virtual table. It might be
> negletible. but this would be added to all of our virtual tables anyway.
> But with QObject we already have that hook for free

No harm. When you already have X entries and you have _the virtual table_, one 
entry more is no harm at all.

> Over 3): How with an enum do you handle conflicts between libraries?  For
> exemple if libkopete want to maintain BC and use some of the virtual hooks
> and then we need to add another hook in kdelibs, we need to take it in
> account, which might not be easy.

Hmm, I don't see the problem... can you elaborate ?

> The current policy is using 2) for class than inherit from QObject, and 3)
> for other classes that may need it.  And i think it is a good policy.

Yes, very probably...

Rafael Fernández López.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the kde-core-devel mailing list