From 72528d58bedae05a3eb3477bf19d6827f3b4675b Mon Sep 17 00:00:00 2001 From: Havoc Pennington Date: Mon, 7 Jun 2004 20:48:33 +0000 Subject: add item about per-display activation --- doc/TODO | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/doc/TODO b/doc/TODO index e906db1b..a35a6a41 100644 --- a/doc/TODO +++ b/doc/TODO @@ -116,14 +116,20 @@ since protocol probably modifies the API. But we could have it there as a safety net. -- STRING_OR_NIL is wrong, doesn't work in C++ etc. ; should not have done that. - Use empty string or special string values or separate functions/signals - or whatever instead. - -- For recursive types, one approach is that "structs" are done as parens, - so e.g. s(ii) is a string and struct { int; int; } etc. Type codes - then all have to be done as strings not single ints. - We could also put the type signature for the message body in a header field. - An "any" type has the type string included in the value. - + - STRING_OR_NIL is wrong, doesn't work in C++ etc. ; should not have done that. + Use empty string or special string values or separate functions/signals + or whatever instead. + + - For recursive types, one approach is that "structs" are done as parens, + so e.g. s(ii) is a string and struct { int; int; } etc. Type codes + then all have to be done as strings not single ints. + We could also put the type signature for the message body in a header field. + An "any" type has the type string included in the value. + + - do we need per-display activation; if so I'd like to do this by setting a + "display ID" property on screen 0, with a GUID, and keying activation by + said GUID. Otherwise you get all kinds of unrobust + string/hostname-based mess. per-screen is then done by appending screen number + to the display. If displays have a deterministic ID like this, you can + do per-display by simply including GUID in the service name. -- cgit