<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 22/09/2014 23:47, Jason Ekstrand a
écrit :<br>
</div>
<blockquote
cite="mid:CAOFGe95K57XrEcb1yV=iAmV7uMtJCS16Y4xhxo=Rs=9Qr0sFjw@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<div class="h5">
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div>
<div>
<br>
</div>
</div>
I would certainly like to do this,
but wl_output.transform is<br>
always passed as a signed integer
and I'm not sure if this is a<br>
bitfield or not. I assumed it is,
because you can<br>
reconstruct "270", "flipped_90",
"flipped_180" and "flipped_270"<br>
out of "90", "180" and "flipped".
Or is this just a coincidence?<br>
</blockquote>
<div><br>
</div>
</div>
</div>
<div>It's both... More in a couple of
lines<br>
</div>
<span>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
Also, is there a reason why some
enumerations are passed as<br>
a signed integer
(wl_output.subpixel) and others
aren't?<br>
<span><br>
><br>
> So, what do other people
think of the idea in this patch?<br>
</span></blockquote>
<div><br>
</div>
</span>
<div>I'm a little unsure. I think
trying to completely solve this
problem in a way that will truly make
strongly typed languages happy is
insanity. That said, I'm cautiously
ok with defining bitfields and enums
as long as we are very careful in
scoping what "bitfield" and "enum"
mean. A "bitfield" should have only
power of two values and the result
should always be interpreted as an OR
of those values. An enum should have
every possible value enumerated. If
anyone has a good example of something
that validly doesn't fit into either
of these, please speak up.<br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div>
</div>
<div>xdg_shell.resize_edges. It is both a bitfield
(top / left / right / bottom edges are powers of
two) and an enum (top right / bottom left corner
convenience values, with top / bottom being left
out as it is undefined).<br>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>That's an example of an enum with cleverly chosen
values so that you can do bitfield-like things. What I'm
more concerned about is something where it would be
impractical to actually enumerate all of the possibilities
in the protocol spec but it's not a bitfield either.<br>
</div>
<div> </div>
<br>
</div>
</div>
</div>
</blockquote>
xdg_surface.state seems to correspond to the description.<br>
It's an enum, but DE can extend this enum with its own values.<br>
<br>
<br>
<br>
</body>
</html>