Re: Widget, drawing and event coordinates

2017-06-13 Thread Timm Bäder
On 12.06, Matthias Clasen wrote: > Trying to summarize an irc discussion on this topic: > > We generally agreed that the content area should be what all vfuncs > (measure, > size_allocate, snapshot), events and signal handlers operate in. > > The other size that is relevant for widgets is the

Re: Widget, drawing and event coordinates

2017-06-12 Thread Matthias Clasen
Trying to summarize an irc discussion on this topic: We generally agreed that the content area should be what all vfuncs (measure, size_allocate, snapshot), events and signal handlers operate in. The other size that is relevant for widgets is the 'outer' size including the content size, css

Re: Widget, drawing and event coordinates

2017-06-11 Thread Timm Bäder
On 11.06, Matthias Clasen wrote: > On Mon, Jun 5, 2017 at 2:38 PM, Timm Bäder wrote: > > > The goal here is to unify the coordinate systems we use for events, > > drawing and size allocation. > > > > Widget coordinates definitely should be relative to the parent > > allocation

Re: Widget, drawing and event coordinates

2017-06-11 Thread Matthias Clasen
On Mon, Jun 5, 2017 at 2:38 PM, Timm Bäder wrote: > The goal here is to unify the coordinate systems we use for events, > drawing and size allocation. > > Widget coordinates definitely should be relative to the parent > allocation in some sense, so we can move subtrees around

Widget, drawing and event coordinates

2017-06-05 Thread Timm Bäder
The goal here is to unify the coordinate systems we use for events, drawing and size allocation. Widget coordinates definitely should be relative to the parent allocation in some sense, so we can move subtrees around without re-allocating every single widget in it. In master, all event