[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