On Wed, 2012-07-25 at 14:28 -0700, Bill Spitzak wrote: > > Juan Zhao wrote: > > On Tue, 2012-07-24 at 23:17 -0700, Bill Spitzak wrote: > >> On 07/24/2012 10:32 PM, Juan Zhao wrote: > >> > >>>> Therefore I suggest that the sample client work as proposed, and > >> only > >>>> prevent that point from being obscured. > >>> Do you mean, avoiding the places where it could triger the drag to > >> be > >>> obscured? > >> I mean only the point that is clicked. It avoids *one* place that can > >> trigger a window drag, not all of them. > >> > > It should be defined in the client side. > > Getting lost.... > > What I am saying is that the shell can assume that if the client > triggers a window drag for a click at 100,100, that is will *always* > trigger a window drag for a click at 100,100. > > This means that the only point that must not be obscured is 100,100. It > does not matter if the client also triggers a drag from the point > 200,200. The user by dragging 100,100 can move 200,200 off the screen. > But the user will still be able to get it back because they can still > grab 100,100 and move the window so 200,200 is back on the screen. > > The shell can make similar assumptions about resizes. If the clicked > point is distance xy from a moving corner, it can assume that the point > at that distance will always trigger a resize of that corner. This means > that when resizing it only has to make sure the point still exists in > the window and is not obscured.
I sent a new patch related to the implementation. Thanks, Juan > _______________________________________________ > wayland-devel mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
