> > Normally you would use the gravity of a window to determine the
> > direction in which it grows.
>
> Each window's gravity would then need to be changed whenever its
> position or size changes enough according to some heuristic. At least
> there would be some hope for those poor windows that
On 09/15/14 21:50, Dominik Vogt wrote:
Now, if the position (quadrant) of the window center is not taken into
account, each window will grow downwards and to the right... and
eventually out of view. For windows at the right and bottom halfs,
shrinking their size would move them farther from the b
On Sun, Sep 14, 2014 at 11:08:20PM +0300, Tapio Luukkanen wrote:
> On 09/14/14 17:09, Thomas Adam wrote:
> > The closest you have now is the direction mechanism which will calculate
> > which border to warp to based on the pointer's position, relative to the
> > window which is to be resized. How
On 09/14/14 17:09, Thomas Adam wrote:
> On Sun, Sep 14, 2014 at 05:00:21PM +0300, Tapio Luukkanen wrote:
>> So ... I was experimenting with the PipeRead command to create a
>> "smart" scroll-wheel-based non-interactive window resizing mechanism
>> that would choose the edge where the resize occur
On Sun, Sep 14, 2014 at 05:00:21PM +0300, Tapio Luukkanen wrote:
> So ... I was experimenting with the PipeRead command to create a
> "smart" scroll-wheel-based non-interactive window resizing mechanism
> that would choose the edge where the resize occurs based on where the
> window midpoint is loc
Hello all,
Question 1: I probably should have asked publicly before starting to
experiment with the approach outlined here -- is there any cleaner,
already existing way to achieve these "goals"?
So ... I was experimenting with the PipeRead command to create a
"smart" scroll-wheel-based non-inter
