On 04/12/2016 06:10 AM, Jonas Ådahl wrote:
Good point. Setting an invalid state should probably result in a
protocol error.
No this cannot be a protocol error because that makes it difficult to
change the size range to a new one that does not intersect the old one.
Perhaps having the commit
Hi Bill,
>
> > > It allows a client to say "I look best below this size, but if the
> > > compositor wants to fill a larger rectangle, I can draw something nicer
> > > than the compositor can do (the compositor can only pad or scale)".
> >
> > That's something different, isn't it? The compositor
On Tue, 12 Apr 2016 15:25:36 + Mike Blumenkrantz
said:
> Sure, that sounds good to me!
i like the idea of keeping < 0 invalid for now... it leaves wiggle room in
future to maybe make it valid and have special meaning but for now is invalid
thus can be assumed to not be used.
> On Tue, Apr 1
> On 04/12/2016 08:17 AM, Olivier Fourdan wrote:
> [...]
> >
> > But that raise another point, what if the client itself specifies a
> > geometry (using set_window_geometry) outside of the min/max?
> >
> > I reckon that would be a protocol error as well. if so, I guess it means I
> > have to update
Sure, that sounds good to me!
On Tue, Apr 12, 2016 at 11:24 AM Olivier Fourdan
wrote:
> Hi Mike.
>
> > Okay, if we're not going with uints then at the least can the "use 0 to
> > unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
> > cover that case?
>
> I think we should sim
Hi Mike.
> Okay, if we're not going with uints then at the least can the "use 0 to
> unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
> cover that case?
I think we should simply indicate that the width and height must be greater
than or equal to zero, so we remain consisten
> > > Good point. Setting an invalid state should probably result in a
> > > protocol error.
> >
> > No this cannot be a protocol error because that makes it difficult to
> > change the size range to a new one that does not intersect the old one.
> >
> > Perhaps having the commit of an invalid st
Okay, if we're not going with uints then at the least can the "use 0 to
unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
cover that case?
On Tue, Apr 12, 2016 at 10:40 AM Olivier Fourdan
wrote:
> Hi,
>
>
> > > Good point. Setting an invalid state should probably result in a
Hi,
> > Good point. Setting an invalid state should probably result in a
> > protocol error.
>
> No this cannot be a protocol error because that makes it difficult to
> change the size range to a new one that does not intersect the old one.
>
> Perhaps having the commit of an invalid state be a
On Apr 12, 2016, at 2:22 AM, Jonas Ådahl wrote:
>
> On Tue, Apr 12, 2016 at 03:20:27AM -0400, Olivier Fourdan wrote:
>> Hi Mike,
>>
>> - Original Message -
>>> I think this should probably use uint instead of int for params since zero
>>> is the "unset" number. Otherwise you have to writ
On Tue, Apr 12, 2016 at 08:05:03AM -0500, Yong Bakos wrote:
> On Apr 12, 2016, at 2:22 AM, Jonas Ådahl wrote:
> >
> > On Tue, Apr 12, 2016 at 03:20:27AM -0400, Olivier Fourdan wrote:
> >> Hi Mike,
> >>
> >> - Original Message -
> >>> I think this should probably use uint instead of int f
Hi Jasper,
- Original Message -
> I figured min/max would be double-buffered state and require a commit
> to take affect. In fact, anything else means that we can't extend with
> additional size constraints in the future, since they couldn't be
> applied atomically.
Completely agree, I'l
On Tue, Apr 12, 2016 at 03:20:27AM -0400, Olivier Fourdan wrote:
> Hi Mike,
>
> - Original Message -
> > I think this should probably use uint instead of int for params since zero
> > is the "unset" number. Otherwise you have to write something about negative
> > sizes.
>
> Reason I used
Hi Mike,
- Original Message -
> I think this should probably use uint instead of int for params since zero
> is the "unset" number. Otherwise you have to write something about negative
> sizes.
Reason I used "int" is because these are limits for size, which are expressed
with int as well
I think this should probably use uint instead of int for params since zero
is the "unset" number. Otherwise you have to write something about negative
sizes.
On Mon, Apr 11, 2016 at 3:11 PM Jasper St. Pierre
wrote:
> On Mon, Apr 11, 2016 at 12:59 AM, Olivier Fourdan
> wrote:
> > Some applicatio
On Mon, Apr 11, 2016 at 12:59 AM, Olivier Fourdan wrote:
> Some application may wish to restrict their window in size, but
> xdg-shell has no mechanism for the client to specify a maximum or
> minimum size.
>
> As a result, the compositor may try to maximize or fullscreen a window
> while the clie
I figured min/max would be double-buffered state and require a commit
to take affect. In fact, anything else means that we can't extend with
additional size constraints in the future, since they couldn't be
applied atomically.
On Mon, Apr 11, 2016 at 12:02 PM, Bill Spitzak wrote:
> Because of the
On Apr 11, 2016, at 2:59 AM, Olivier Fourdan wrote:
>
> Some application may wish to restrict their window in size, but
> xdg-shell has no mechanism for the client to specify a maximum or
> minimum size.
>
> As a result, the compositor may try to maximize or fullscreen a window
> while the clien
Some application may wish to restrict their window in size, but
xdg-shell has no mechanism for the client to specify a maximum or
minimum size.
As a result, the compositor may try to maximize or fullscreen a window
while the client would not allow for the requested size.
Add new requests "set_max
19 matches
Mail list logo
