stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [STUMP] rat-bisect-move


From: Marco Wahl
Subject: Re: [STUMP] rat-bisect-move
Date: Sat, 11 Jun 2016 10:02:34 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Hi Scott,

Thanks for your answer.

> Mention keynav as alternative and describe major differences if any.

keynav looks good.  Of course I should have checked what is already
there before implementing anything but I didn't.  I put keynav onto my
personal list of programs to try.  For now I added a link to keynav in
the readme.

> Under dependencies I would perhaps mention that the user will need to
> install the zpng lisp dependency. It is required by the screenshot
> module which is mentioned but the user will likely not have used that
> module previously so when loading your module they may see a zpng
> package missing error.

> xloadimage package is required on Debian for xsetbg.
>
> Maybe write keybindings in stumpwm format, like s-c, s-b, 
> s-{left,right,down,up}
>
> Module is mispelled modul twice in readme.

Okay, thanks again.

> As for using rat-bisect-move, I only tried it briefly, since I'm OK
> using the mouse, so I may be missing something/using it incorrectly.
>
> Issue 1: resize indicators left on the screen.
> I've had issues before with iresize leaving old indicators on the
> screen and my system does the same for rat-bisect-move. The old
> rectangles are left on the screen and it becomes confusing seeing the
> active area. This very well may be limited to my system. I'm assuming
> that only the active area is supposed to indicated at any given
> moment. If it is working as intended (show old areas that have been
> divided) then I find it confusing.

Actually I liked the traces left by the indicators.  But I agree that to
many indicators on the screen might yield to confusion.  In a next
version there shall be at least the alternative to have always just the
current indicator on the screen.

> Issue 2: it wasn't clear how to abort
> In iresize the user can C-g or ESC. This may be related to issue #1. I
> wonder why you chose not to go with a single top-level binding and
> have all the other bindings underneath that like iresize. You could
> have left,right,down,up,c,b all unprefixed which may make repeatedly
> pressing them easier.

Good points.  I did think about a mode-like enter and abort but I was
too lazy to work out the details.  Up to now the user must do the work
of restoring the windows.

I did not think about alterative key bindings.  Indeed iresize is a fine
example.

All these issues go to my list.


Best regards,
-- 
Marco Wahl
GPG: 0x49010A040A3AE6F2




reply via email to

[Prev in Thread] Current Thread [Next in Thread]