This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107855/

On January 2nd, 2013, 8:38 a.m., Martin Gräßlin wrote:

kwin/client.cpp (Diff revision 3)
void Client::setOnActivity(const QString &activity, bool enable)
1505
#define NULL_UUID "00000000-0000-0000-0000-000000000000"
@Ivan: could that define become part of the public API?

On January 2nd, 2013, 11:40 a.m., Ivan Čukić wrote:

I really don't think that kactivities should provide api for uuid when there already is QUuid.

Adding it to apidox would be bearable.

On January 2nd, 2013, 3:21 p.m., Thomas Lübking wrote:

"Because you're not yourself"

The string is hardcoded in libkactivities, QUuid().toString() is actually "{00000000-0000-0000-0000-000000000000}" and QUuid("00000000-0000-0000-0000-000000000000").isNull() is true by implementation detail only (half sentence in QUuid API doc that you can omit the curlies)

I assume the string is hardcoded in kactivties because you didn't want the braces?
-> What uuid should we set on the window?
-> How will other clients react to that?

I don't want to get back to "why a string representation instead of the 16 RFC4122 bytes", but the current implemention deviates  from QUuid (or rather QUuid deviates from RFC4122 which does not describe curly braces) and needs to be specified or based upon a common source (QUuid)


I intend to stash it until RC3 is open
(so we can sort out the hash invocation and provide update scripts, fix rules kcm(?) and align kactivities)

- Thomas


On December 31st, 2012, 8:24 p.m., Thomas Lübking wrote:

Review request for kwin, Ivan Čukić and Martin Gräßlin.
By Thomas Lübking.

Updated Dec. 31, 2012, 8:24 p.m.

Description

When the activity daemon is not reposponding, the lib cache will answer with the null activity which is so far just "invalid", cannot be activate and by this its not a good idea to assign any window to it (happens when you open a window and it gets on the current "null" activity)

Using it instead of the "ALL" property is more robust (anytime there's sth. slightly wrong in the system we fall back to "on all activities" rather than loosing windows on some unreachable activities) as well as more consistent (there's now always a uuid string as activity property)

Notice that there's a pending reference to "ALL" in "service/ui/plugins/declarativeui/DeclarativeUi.cpp" which Ivan wants to scratch as soon as we use the null uuid in git master.

Testing

No regression spotted.
Reg. the original problem:
semi - i once ran into one or more window/s being on that id, not with the patch since after.

Diffs

  • kwin/client.cpp (b555c11)

View Diff