Read here.
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++

FYI, the inline character of the c'tor is irrelevant, you cannot add non 
static members. period, BUT ;-)

- You _can_ add as many (non virtual unless you know what you're doing) 
functions(), ie. eg. setter()s and getter()s.
- You _can_ add a static member ... eg. a QHash ;-)

So here comes my ultra dirty "why we do not want you to touch kdelibs ever 
again" hack-a-ttempt:

Add
void setWId( WId id );
WId wId();

private:
   static QHash<ClientGroupItem*, WId> ourWIds;

... i assume you can think of the rest, have the setters and getters set and 
fetch the WId's to/from the STATIC (did i mention it has to be static? ;-) 
hash, using "this" as key. Done.
Not super efficient but you probably don't have to call it on every other 
repaint....

One thing i don't know:
deconstructors - it would be nice to have it remove the entry from the hash, 
but there's none and i don't know whether adding one is BC :-(

Cheers,
Thomas

PS: i've so far refused to implement tabbing support for it's ... well: 
"state" :-(  (and for low interest tbf)

Am Wednesday 20 October 2010 schrieb Martin Gräßlin:
> Hi,
> 
> I just wanted to add some awesome tooltips to Aurorae including nice window
> previews. Therefore I would need to know the WId of the tab and here comes
> the problem... it isn't exposed through the API and looking at the source
> it seems I am unable to add it. As it is a small class here the complete
> code:
> 
> class KWIN_EXPORT ClientGroupItem
>     {
>     public:
>         ClientGroupItem( QString t, QIcon i )
>             {
>             title_ = t;
>             icon_ = i;
>             }
>         inline QIcon icon() const
>             {
>             return icon_;
>             }
>         inline QString title() const
>             {
>             return title_;
>             }
>     private:
>         QString title_;
>         QIcon icon_;
>     };
> 
> As far as I understand I cannot add anything to the class as the
> constructor is inline, and there is no d-pointer. So adding a WId field
> won't work, right?
> 
> ClientGroupItem is only used for KDecorationUnstable, but nevertheless I do
> not want to break BC - considering that there are external decorations
> using it (QtCurve, Bespin) and Compiz implementing it (I don't want
> another round of kde-window-decorator crashes).
> 
> Any recommendations? In case of breaking BC I would move this to 4.7 and
> rename KDecorationUnstable to KDecoration2 and do a proper cleanup.
> 
> Martin

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin