On Sun, 07 Sep 2014 21:30:52 -0700
Bill Spitzak spit...@gmail.com wrote:
On 09/05/2014 10:47 PM, Ryo Munakata wrote:
Hi, Bill.
Thank you for reviewing.
On Fri, 05 Sep 2014 18:08:44 -0700
Bill Spitzak spit...@gmail.com wrote:
I think if the strdup's were removed it would get rid
Hi,
On 5 September 2014 12:07, Pekka Paalanen ppaala...@gmail.com wrote:
On Mon, 1 Sep 2014 17:20:32 +0200
Marek Chalupa mchqwe...@gmail.com wrote:
When we are moving window or its state changed, update the
output, so that configure event and maximizing/fullscreening actions
have
shsurf-output is the output that user expects the shell surface
is on. When maximizing, we don't have any explicit setting of the output
like in the case of fullscreening, so set the output to the one that
the surface is currently on. In the case that the surface is not mapped yet,
(if it ever
On Mon, 8 Sep 2014 09:28:17 +0300
Pekka Paalanen ppaala...@gmail.com wrote:
On Sun, 07 Sep 2014 21:30:52 -0700
Bill Spitzak spit...@gmail.com wrote:
On 09/05/2014 10:47 PM, Ryo Munakata wrote:
Hi, Bill.
Thank you for reviewing.
On Fri, 05 Sep 2014 18:08:44 -0700
Bill
On 09/07/2014 11:28 PM, Pekka Paalanen wrote:
I think it is safe to assume the contents of argv will not get overwritten.
It is common to copy argv itself and modify that, but not to modify the
strings it points at.
This would be feasible only if we can guarantee that no-one will ever
need
Just to be clear, I have no objection to adding strdup() to all
functions that return strings.
I don't like adding unnecessary free() statements to the end of
called-once functions such as main, especially if you also have to add
labels and gotos and temporary variables to keep track of
I'm probably being stupid, but I still can't figure out how it chooses
the output for a NON-maximized surface. I would think that should use
exactly the same algorithm as maximized does here?
On 09/08/2014 03:34 AM, Marek Chalupa wrote:
shsurf-output is the output that user expects the shell
On Fri, Sep 05, 2014 at 11:25:25AM +1000, Peter Hutterer wrote:
WL_CALIBRATION, introduced in weston-1.1, requires the translation component
of the calibration matrix to be in screen coordinates. libinput does not have
access to this and it's not a very generic way to do this anyway. So with
WL_CALIBRATION, introduced in weston-1.1, requires the translation component
of the calibration matrix to be in screen coordinates. libinput does not have
access to this and it's not a very generic way to do this anyway. So with
the libinput backend, WL_CALIBRATION support is currently broken
On Mon, Sep 08, 2014 at 08:16:07PM +0200, Jonas Ådahl wrote:
On Fri, Sep 05, 2014 at 11:25:25AM +1000, Peter Hutterer wrote:
WL_CALIBRATION, introduced in weston-1.1, requires the translation component
of the calibration matrix to be in screen coordinates. libinput does not
have
access
10 matches
Mail list logo
