Re: re: comments - window center hint.
Heather Lanigan USG <[email protected]> Tue, 23 Jul 2002 11:05:04 -0400
| Newsgroups | gmane.comp.video.x.xinerama |
|---|---|
| Message-ID | <[email protected]> |
--------------040602020504030202030303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Now that some time has passed and people have had a chance to mull over this issue some more. Are there any new ideas or perhaps a concensus? The public review period is set to end this friday, 7/26. I'd like to finish this discussion up. -Heather Havoc Pennington wrote: >Hi, > >Sorry to write such a long email, but it seems like a useful general >point for future X.org specs, aside from this specific topic. > >Mark Vojkovich <[email protected]> writes: > >> So are you arguing that we should get rid of the hint? >> > >If it's going to be underspecified, then it will just cause problems >because people will try to use it but in non-interoperable ways. > >So I'm advocating either specifying it in enough detail, or not >specifying it at all, I guess. > >A vague spec just creates confusion and adds no value. > >>Perhaps the hint is too far into the realm of policy. >>Further documentation on how the hint is supposed to be used by >>various applications sounds like moving further and further into >>the realm of policy to me and that, in my opinion, is going in the >>wrong direction. >> > >Stepping back a moment: avoiding policy is not about saying "there's >this hint called FOO, and it does some stuff and we aren't sure >what. You can use it however you want." You haven't provided mechanism >there, because no client can rely on anything about FOO. > >The right way to specify mechanism, while allowing policy changes, is >to say "there is a hint which allows client A to communicate its >policies to client B. In order to communicate its policies, client A >must follow these guidelines X, Y, Z. In order to honor A's policies, >client B must follow these other guidelines Q, R, S." > >Let me put it more concretely. Say I write down a spec that this >center-hint property should be set by the window manager and apps >should never set PPosition based on it. Say my friend Joe writes down >a different spec that says the property should be set by the client >owning the XINERAMA_MANAGER manager selection, and that apps should >set PPosition based on it, and the WM should honor PPosition. > >Furthermore in my spec I say that the property is where dialogs should >be centered, and in Joe's he says that the property is the physical >center of the main screen. Then we each implement placing dialogs 1/3 >from the top of the screen - I set the center-hint property to 1/3 >down and place the dialogs there, Joe sets the center-hint property to >physical center and then offsets dialogs up from it in the >application. > >Now, say I try to use an app or WM designed for my spec, and an app or >WM designed for Joe's spec, at the same time. It will not do anything >useful whatsoever. In fact the result will be broken and totally >buggy. > >Allowing me and Joe to write our own specs is NOT allowing us to >implement our own policies. Key point: we could both have achieved our >goals for our specs _without_ using the same name for the property. > >And in fact, using the same name is what results in everything being >broken. So if you leave it up to me and Joe to specify the details, it >is better to leave it up to us to each specify our own property in our >own namespace so we don't step on each other. You can't have one >property with two meanings, without interoperability problems. > >Now, imagine that either my spec or Joe's spec was established from >the start, as the canonical interpretation of the property in the >Xinerama spec. Then one of us can use the Xinerama property, and the >other one can make up their own property. So there is at least some >value to the Xinerama property at that point. > >So I just really don't understand your point about policy >vs. mechanism. To me, saying "there is this hint called FOO" isn't >policy _or_ mechanism. It's worse than useless: it encourages a lot of >people to try to guess what the mechanism is, which in practice means >using the same name for a lot of separate custom mechanisms, and thus >step on each other's toes. If you want to specify a mechanism, you >have to specify how it works. > >Bottom line: you must specify enough that any client that follows the >spec will work as intended in conjunction with any other client that >follows the spec. I think my "me and Joe" example clearly demonstrates >that people could interpret the current Xinerama spec in totally >non-interoperable-with-each-other ways. > >I'm trying to figure out how to explain this better. > >To try and understand your point better: can you tell me why you think >the "me and Joe" story won't happen? > >Or perhaps: why would you leave the "policy" of who sets the property >unspecified? In what way is that an interesting policy to let people >do differently? > >Havoc > >---------------------------------------------------------------------------- > Bringing you mounds of caffeinated joy > >>> http://thinkgeek.com/sf <<< > >_______________________________________________ >Xinerama-std-review mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/xinerama-std-review > --------------040602020504030202030303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <html> <head> </head> <body> Now that some time has passed and people have had a<br> chance to mull over this issue some more. Are there <br> any new ideas or perhaps a concensus?<br> <br> The public review period is set to end this friday, <br> 7/26. I'd like to finish this discussion up.<br> <br> -Heather<br> <br> Havoc Pennington wrote:<br> <blockquote type="cite" cite="mid:[email protected]"> <pre wrap="">Hi,<br><br>Sorry to write such a long email, but it seems like a useful general<br>point for future X.org specs, aside from this specific topic.<br><br>Mark Vojkovich <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> writes: <br></pre> <blockquote type="cite"> <pre wrap=""> So are you arguing that we should get rid of the hint? <br></pre> </blockquote> <pre wrap=""><!----><br>If it's going to be underspecified, then it will just cause problems<br>because people will try to use it but in non-interoperable ways.<br><br>So I'm advocating either specifying it in enough detail, or not<br>specifying it at all, I guess.<br><br>A vague spec just creates confusion and adds no value.<br><br></pre> <blockquote type="cite"> <pre wrap="">Perhaps the hint is too far into the realm of policy.<br>Further documentation on how the hint is supposed to be used by<br>various applications sounds like moving further and further into<br>the realm of policy to me and that, in my opinion, is going in the<br>wrong direction.<br></pre> </blockquote> <pre wrap=""><!----><br>Stepping back a moment: avoiding policy is not about saying "there's<br>this hint called FOO, and it does some stuff and we aren't sure<br>what. You can use it however you want." You haven't provided mechanism<br>there, because no client can rely on anything about FOO.<br><br>The right way to specify mechanism, while allowing policy changes, is<br>to say "there is a hint which allows client A to communicate its<br>policies to client B. In order to communicate its policies, client A<br>must follow these guidelines X, Y, Z. In order to honor A's policies,<br>client B must follow these other guidelines Q, R, S."<br><br>Let me put it more concretely. Say I write down a spec that this<br>center-hint property should be set by the window manager and apps<br>should never set PPosition based on it. Say my friend Joe writes down<br>a different spec that says the property should be set by the client<br>owning the XINERAMA_MANAGER manager selection, and that apps should<br>set PPosition based on it, and the WM should honor PPosition.<br><br>Furthermore in my spec I say that the property is where dialogs should<br>be centered, and in Joe's he says that the property is the physical<br>center of the main screen. Then we each implement placing dialogs 1/3<br>from the top of the screen - I set the center-hint property to 1/3<br>down and place the dialogs there, Joe sets the center-hint property to<br>physical center and then offsets dialogs up from it in the<br>application.<br><br>Now, say I try to use an app or WM designed for my spec, and an app or<br>WM designed for Joe's spec, at the same time. It will not do anything<br>useful whatsoever. In fact the result will be broken and totally<br>buggy.<br><br>Allowing me and Joe to write our own specs is NOT allowing us to<br>implement our own policies. Key point: we could both have achieved our<br>goals for our specs _without_ using the same name for the property.<br><br>And in fact, us ing the same name is what results in everything being<br>broken. So if you leave it up to me and Joe to specify the details, it<br>is better to leave it up to us to each specify our own property in our<br>own namespace so we don't step on each other. You can't have one<br>property with two meanings, without interoperability problems.<br><br>Now, imagine that either my spec or Joe's spec was established from<br>the start, as the canonical interpretation of the property in the<br>Xinerama spec. Then one of us can use the Xinerama property, and the<br>other one can make up their own property. So there is at least some<br>value to the Xinerama property at that point.<br><br>So I just really don't understand your point about policy<br>vs. mechanism. To me, saying "there is this hint called FOO" isn't<br>policy _or_ mechanism. It's worse than useless: it encourages a lot of<br>people to try to guess what the mechanism is, which in practice means<br>using the same name for a lot of separate custom mechanisms, and thus<br>step on each other's toes. If you want to specify a mechanism, you<br>have to specify how it works.<br><br>Bottom line: you must specify enough that any client that follows the<br>spec will work as intended in conjunction with any other client that<br>follows the spec. I think my "me and Joe" example clearly demonstrates<br>that people could interpret the current Xinerama spec in totally<br>non-interoperable-with-each-other ways.<br><br>I'm trying to figure out how to explain this better.<br><br>To try and understand your point better: can you tell me why you think<br>the "me and Joe" story won't happen?<br><br>Or perhaps: why would you leave the "policy" of who sets the property<br>unspecified? In what way is that an interesting policy to let people<br>do differently?<br><br>Havoc<br><br>----------------------------------------------------------------------------<br> Bringing you mounds of caffeinated joy<br> >>> <a class="moz-txt-link-freetext" href="http://thinkgeek.com/sf">http://thinkgeek.com/sf</a> <<<<br><br>_______________________________________________<br>Xinerama-std-review mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a><br><a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/xinerama-std-review">https://lists.sourceforge.net/lists/listinfo/xinerama-std-review</a><br><br></pre> </blockquote> <br> </body> </html> --------------040602020504030202030303-- ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf