OneSwitch pet - control a PC using a single switch

A home for all kinds of Puppy related projects
Message
Author
User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#16 Post by greengeek »

I'm thinking it would be interesting to modify the script to recognise a mouse leftclick or centreclick as an alternative to a bound key to trigger the direction change etc. (and might continue to be recognised when dropdown menus are expanded..)

I need to have a deeper look at this link and evaluate what's possible:
http://stackoverflow.com/questions/8361 ... ash-script

("xdotool --search" answer....)

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#17 Post by SFR »

I need to have a deeper look at this link and evaluate what's possible:
http://stackoverflow.com/questions/8361 ... ash-script
Tried this, but unfortunately mouse-click is detected only when mouse is directly over desktop.
Besides, perhaps I don't fully understand your conception, but if mouse-click would be utilized to trigger movement events, the "click" itself also would interact with everything what lies beneath the cursor, each time...
I wonder if the relative cpu priorities of each process could have such an effect?
I'm afraid it's a deeper issue.
Googling around has revealed quite similar behaviors (though rather old and not directly related to xbindkeys app):
https://bugs.kde.org/show_bug.cgi?id=145732
https://bugs.launchpad.net/ubuntu/+sour ... +bug/32860

I guess xbindkeys intercepts keystrokes on too high level, because, for example: logkeys-0.1.0 has no problems with detecting Pause key in any circumstances...but it would be a huge overkill to utilize a keylogger to monitor state of only one key.

Anyway, I found an app in C that acts similarily, but at least is much smaller:
http://stackoverflow.com/questions/1485 ... linux-in-c

I have compiled it directly in Geany (Compile/Build) and modified both scripts ("horizontal/vertical" & "radar").
However I'm not sure if in all cases '/dev/input/event0' will be the proper input device and if "key 119" will be Pause key...

Source, binary and both scripts are in attached tar.gz.
Just unpack it and launch 'horizontal_vertical' or 'radar'...and see if it works at all in your case..? :wink:

Greetings!
Attachments
one_switch.tar.gz
(5.19 KiB) Downloaded 477 times
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#18 Post by greengeek »

Amazing. That is a huge step.

Let me just describe what my testing showed up (because it has left me a little confused...)

I downloaded the attachment and unzipped it. I trialled the horizontal_vertical script and it is much improved (almost perfect but still a couple of issues which I will try to describe better after some further testing later).

Then, when I looked at the "radar" file I realised it was probably based on one of your earlier scripts that I had not tested (the "rotate svg" one). I had not tested that first rotate script as I had been concentrating only on the horiz_vert one. So I went back to the rotate script and started it from a terminal (just to try and understand it before touching the new file called radar) and ended up with two "radars", and one of them kept turning into a MOVE, CLICK option. I lost control of the cursor and could not figure out how I should be controlling it.

However, when I look at the first rotate script I do not see any "MOVE" or "CLICK" anywhere within it. Obviously the MOVE CLICK is part of the new radar script so I have no idea how that started running (unless triggered somehow by my test of the horizontal_vertical).

So - at this point I'm thinking that I have got rotate1 and radar tangled up and somehow running at the same time.

Anyway - sorry to be confusing - I am just going to have another try and will aim to detail more clearly the horiz_vert issues.

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#19 Post by SFR »

Yes, I introduced MOVE&CLICK in the second version of "radar".
I've no idea how "radar_old" has launched "radar_new"? :shock:

BTW, xbindkeys are no longer needed for both "horiz/vert" & "radar", so unbind the Pause key - maybe this was the culprit..?

Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#20 Post by greengeek »

I didn't get a lot of testing time today unfortunately, but so far I'm very impressed with radar. I was able to do pretty much everything I wanted. The lack of a doubleclick was sometimes problematic, but I found ways around it each time. I think I could make a useful system out of it as is, with radar working together with xvkbd, but if I was to look for any further improvements it would be these:

1) Biggest problem was that the radar disappeared underneath the main system menu, so you could not see the direction it was pointing. Maybe the radar screen could be blocked from entering bottom left or top left airspace, so as to avoid conflict with menus?

2) Sometimes I thought it would be nice for the cursor to be allowed to wrap around the edges of the desktop to allow a shortcut to the other side. Not a biggie though - just a timesaver.

3) It would be helpful at times if the radar screen was partly transparent.

4) It would be great to add "doubleclick" to the Move/click menu

5) Occasionally I thought it would be handy for the radar to pause for half a second at 90, 180, 270 and 360 degrees to make it easier to travel along a line of xvkbd keyboard keys, or a horizontal menu etc, but I'm not sure it's worth the effort as it might be frustrating that it slows down the process at other times.


All in all I think you've done an utterly fantastic job and in such a short time!

Initially I was planning to add the horiz_vert script into a system with the menu and taskbar along the top edge (rather than along the bottom of the screen) so that the control functions were within easy reach of the origin (x=y=0) but I think radar makes that unnecessary. I think it could plug into pretty much any puppy and be useful as is. Really impressive!

I hope to get some more time for more indepth testing tomorrow.

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#21 Post by SFR »

1) Biggest problem was that the radar disappeared underneath the main system menu, so you could not see the direction it was pointing. Maybe the radar screen could be blocked from entering bottom left or top left airspace, so as to avoid conflict with menus?
Actually it's worse - it disappears underneath _any_ kind of menu (pull-down also).
I thought it's just a matter of priority and experimented with wmctrl, but no go - those menus are for some reason locked on the very top and nothing can override it...
Maybe detach the radar/menus from the cursor position and place it on some fixed position (bottom-right corner)..?
2) Sometimes I thought it would be nice for the cursor to be allowed to wrap around the edges of the desktop to allow a shortcut to the other side. Not a biggie though - just a timesaver.
Done.
3) It would be helpful at times if the radar screen was partly transparent.
I was thinking about it too and tried to use gtk2desklet - unfortunately it places "radar" always on the lowest level, underneath everything...
4) It would be great to add "doubleclick" to the Move/click menu
Done.
5) Occasionally I thought it would be handy for the radar to pause for half a second at 90, 180, 270 and 360 degrees to make it easier to travel along a line of xvkbd keyboard keys, or a horizontal menu etc, but I'm not sure it's worth the effort as it might be frustrating that it slows down the process at other times.
Done - 1 second delay doesn't seem to slow down things. :wink:

Code: Select all

#!/bin/bash

# Req.: Gtkdialog >= 0.8.0, xdotool, detect_key, xwininfo, getcurpos, awk

# =============================================================================
# Init
# =============================================================================

TEMPDIR=/dev/shm/one_switch_temp
mkdir $TEMPDIR

# Delete tempdir and kill all subprocesses on exit
trap 'rm -rf $TEMPDIR; killall detect_key; kill $GTKPID' EXIT

export PIC=$TEMPDIR/cursor_pic
export ROTATION=$TEMPDIR/cursor_rotate
export MENU_1_PIC=$TEMPDIR/menu1_pic
export MENU_1_STATE=$TEMPDIR/menu1_state
echo -10 > $ROTATION
echo 0 > $MENU_1_STATE

PRESS=/tmp/switch_state
[ -f $PRESS ] && rm $PRESS
PAUSE="key 119 state 0"
./detect_key /dev/input/event0 > $PRESS &

# Read current screen resolution
read MAXX MAXY <<< `xwininfo -root | awk 'NR>=8&&NR<=9 {print $2}'`

# =============================================================================
# Gtkdialog structures
# =============================================================================

export PREVIEW='
<window decorated="false" skip-pager-hint="true" skip-taskbar-hint="true" resizable="false">
  <pixmap>
    <variable>PICTURE</variable>
    <input file>'"$PIC"'</input>
  </pixmap>
  <timer visible="false" milliseconds="true" interval="100">
    <action>rotate_line</action>
    <action>refresh:PICTURE</action>
  </timer>
</window>
'

export MENU_1='
<window width-request="74" height-request="74" decorated="false" skip-pager-hint="true" skip-taskbar-hint="true" resizable="false">
  <pixmap>
    <variable>PICTURE</variable>
    <input file>'"$MENU_1_PIC"'</input>
  </pixmap>
  <timer visible="false" milliseconds="true" interval="1000">
    <action>display_menu_1</action>
    <action>refresh:PICTURE</action>
  </timer>
</window>
'

# =============================================================================
# Functions
# =============================================================================

wait_for_switch () {
  until [ "`grep "$PAUSE" $PRESS`" ]; do
    sleep 0.1
  done
}

read_cursor () {
  # Current cursor position
  read CX CY <<< `getcurpos` 
  CX=$(($CX-32)); [ $CX -lt 0 ] && CX=0
  CY=$(($CY-32)); [ $CY -lt 0 ] && CY=0
}

display_menu_1 () {
case "`cat $MENU_1_STATE`" in
  0) POS=2; echo 1 > $MENU_1_STATE ;;
  1) POS=22; echo 2 > $MENU_1_STATE ;;
  2) POS=42; echo 0 > $MENU_1_STATE ;;
esac
echo '<svg width="64" height="64" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<text font-family="DejaVu Sans" font-size="14">
<tspan x="12" y="16">Move</tspan>
<tspan x="14" y="36">Click</tspan>
<tspan x="1" y="56">Dbl-Click</tspan>
</text>
<rect x="0" y="'$POS'" width="64" height="20" stroke="darkgreen" fill="green" stroke-width="2" opacity="0.5" />
</svg>' > $MENU_1_PIC
}
export -f display_menu_1

rotate_line () {
read DEG < $ROTATION
[ $DEG = 0 ] || [ $DEG = 90 ] || [ $DEG = 180 ] || [ $DEG = 270 ] || [ $DEG = 360 ] && sleep 1
DEG=$(($DEG+5))
[ "$DEG" -ge 360 ] && DEG=0
echo $DEG > $ROTATION
# Create svg pic
echo '<svg width="64" height="64" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<circle cx="32" cy="32" r="24" stroke="red" fill="none" stroke-width="3" />
<line x1="32" y1="32" x2="32" y2="8" stroke="black" stroke-width="3" transform="rotate('$DEG' 32 32)" />
</svg>' > $PIC
}
export -f rotate_line

# First call just to make a picture
rotate_line

# =============================================================================
# MAIN LOOP
# =============================================================================

# Infinite loop
while :; do
  
  read_cursor
  gtkdialog -G 64x64+$CX+$CY -p PREVIEW & GTKPID=$!
  
  wait_for_switch
  
  # Kill Gtkdialog window
  kill $GTKPID

  : > $PRESS
  
  read DEG < $ROTATION
  
  # Move cursor until switch signal will appear again
  until [ "`grep "$PAUSE" $PRESS`" ]; do
    xdotool mousemove_relative --polar $DEG 5
    read X Y <<< `getcurpos`
    [ $X -ge $(($MAXX-1)) ] && X=1 && xdotool mousemove $X $Y
    [ $X -le 0 ] && X=$MAXX && xdotool mousemove $X $Y
    [ $Y -ge $(($MAXY-1)) ] && Y=1 && xdotool mousemove $X $Y
    [ $Y -le 0 ] && Y=$MAXY && xdotool mousemove $X $Y
    sleep 0.1
  done
  
  : > $PRESS
  
  read_cursor
  echo 0 > $MENU_1_STATE
  display_menu_1
  gtkdialog -G 64x64+$CX+$CY -p MENU_1 & GTKPID=$!
  
  wait_for_switch
  
  kill $GTKPID

  : > $PRESS
  
  case "`cat $MENU_1_STATE`" in
    2) xdotool click 1; sleep 0.5 ;;
    0) xdotool click --repeat 2 1; sleep 0.5 ;;
  esac

done

# =============================================================================
Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#22 Post by greengeek »

You're quick!

Doing some more testing now....

Couple of thoughts:
1) If radar is detached from cursor I would not recommend bottom right as many screen dialogs have "cancel", "OK" buttons etc close to bottom right. Maybe dead centre of screen as a trial?
2) Instead of detaching radar from the cursor, is it possible to add a duplicate radar screen that stays at screen centre while the first radar screen still tracks the cursor?
3) or maybe two radar screens that both track the cursor, but place them 10cm apart so that there is always a good chance that one of them is visible.

(whatever is possible...)

EDIT : Just another thought - maybe the radar screen could be positioned so that it "half-tracks" the cursor - ie: if cursor is at V pixels vertically above screen centreline, radar screen could be placed at V_divided_by_2 pixels above centreline, and similarly if cursor is at H pixels to the left of vertical centreline of screen then radar screen could be placed at H_divided_by_2 pixels to the left of the vertical centreline.

Once the cursor moves below, or to the right of the centrelines the displacement magnitude would be calculated in the same manner but would obviously be in the opposite direction.

(centrepoint minus H/2, centrepoint minus V/2, centrepoint plus H/2, centrepoint plus V/2)

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#23 Post by SFR »

1) If radar is detached from cursor I would not recommend bottom right as many screen dialogs have "cancel", "OK" buttons etc close to bottom right. Maybe dead centre of screen as a trial?
I mean to completely detach the radar, make it indepentend of cursor.
Like you said "dead centre", but I had in mind 'bottom-right'.
So, for starters, I modified the script to handle those and (for consistency) a few more placements: Cursor (as it was by default), Center, Top/Bottom & Top/Bottom-Left/Right, so you can test if this is right direction.
You can adjust it on the beginning of the script.

But there's another problem. I noticed (in Firefox again) that when a pull-down menu is opened, pressing Pause key closes that menu (Pause key itself is not the problem, but appearing of a new window is).
And again - it doesn't happen with other apps like Geany/DeaDBeef/AviDemux etc...
Have you encountered similar behavior?

Code: Select all

#!/bin/bash

# Req.: Gtkdialog >= 0.8.0, xdotool, detect_key, xwininfo, getcurpos, awk, tr

# POSITION can be one of these:
# CURSOR, CENTER, TOP-LEFT, TOP, TOP-RIGHT, BOTTOM-LEFT, BOTTOM, BOTTOM-RIGHT
POSITION=BOTTOM-RIGHT

# =============================================================================
# Init
# =============================================================================

# Exit if another instance is already running
[ `pidof $(basename $(readlink -e "$0")) -o %PPID | wc -w` -gt 1 ] && exit

POSITION="`echo $POSITION | tr [:lower:] [:upper:]`"

TEMPDIR=/dev/shm/one_switch_temp
mkdir $TEMPDIR

# Delete tempdir and kill all subprocesses on exit
trap 'rm -rf $TEMPDIR; killall detect_key; kill $GTKPID' EXIT

export PIC=$TEMPDIR/cursor_pic
export ROTATION=$TEMPDIR/cursor_rotate
export MENU_1_PIC=$TEMPDIR/menu1_pic
export MENU_1_STATE=$TEMPDIR/menu1_state
echo -10 > $ROTATION
echo 0 > $MENU_1_STATE

PRESS=/tmp/switch_state
[ -f $PRESS ] && rm $PRESS
PAUSE="key 119 state 0"
./detect_key /dev/input/event0 > $PRESS &

# Read current screen resolution
read MAXX MAXY <<< `xwininfo -root | awk 'NR>=8&&NR<=9 {print $2}'`

# =============================================================================
# Gtkdialog structures
# =============================================================================

export PREVIEW='
<window width-request="74" height-request="74" decorated="false" skip-pager-hint="true" skip-taskbar-hint="true" resizable="false">
  <pixmap>
    <variable>PICTURE</variable>
    <input file>'"$PIC"'</input>
  </pixmap>
  <timer visible="false" milliseconds="true" interval="100">
    <action>rotate_line</action>
    <action>refresh:PICTURE</action>
  </timer>
</window>
'

export MENU_1='
<window width-request="74" height-request="74" decorated="false" skip-pager-hint="true" skip-taskbar-hint="true" resizable="false">
  <pixmap>
    <variable>PICTURE</variable>
    <input file>'"$MENU_1_PIC"'</input>
  </pixmap>
  <timer visible="false" milliseconds="true" interval="1000">
    <action>display_menu_1</action>
    <action>refresh:PICTURE</action>
  </timer>
</window>
'

# =============================================================================
# Functions
# =============================================================================

wait_for_switch () {
  until [ "`grep "$PAUSE" $PRESS`" ]; do
    sleep 0.1
  done
}

read_cursor () {
  # Current cursor position
  read CX CY <<< `getcurpos`
  CX=$(($CX-32)); [ $CX -lt 0 ] && CX=0
  CY=$(($CY-32)); [ $CY -lt 0 ] && CY=0
}

set_position () {
case "$POSITION" in
  "CURSOR" ) read_cursor ;;
  "CENTER" ) CX=$(($MAXX/2-37)); CY=$(($MAXY/2-37)) ;;
  "TOP-LEFT" ) CX=0; CY=32 ;;
  "BOTTOM-LEFT" ) CX=0; CY=$(($MAXY-32-74)) ;;
  "TOP-RIGHT" ) CX=$(($MAXX-74)); CY=32 ;;
  "BOTTOM-RIGHT" ) CX=$(($MAXX-74)); CY=$(($MAXY-32-74)) ;;
  "TOP" ) CX=$(($MAXX/2-37)); CY=32 ;;
  "BOTTOM" ) CX=$(($MAXX/2-37)); CY=$(($MAXY-32-74)) ;;
  * ) read_cursor ;;
esac
}

display_menu_1 () {
case "`cat $MENU_1_STATE`" in
  0) POS=0; echo 1 > $MENU_1_STATE ;;
  1) POS=16; echo 2 > $MENU_1_STATE ;;
  2) POS=32; echo 3 > $MENU_1_STATE ;;
  3) POS=48; echo 0 > $MENU_1_STATE ;;
esac
echo '<svg width="64" height="64" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<text font-family="DejaVu Sans" font-size="13" font-weight="bold">
<tspan x="12" y="12">Move</tspan>
<tspan x="14" y="28">Click</tspan>
<tspan x="1" y="44">Db-Click</tspan>
<tspan x="3" y="60">Rt-Click</tspan>
</text>
<rect x="0" y="'$POS'" width="64" height="16" stroke="darkgreen" fill="green" stroke-width="2" opacity="0.5" />
</svg>' > $MENU_1_PIC
}
export -f display_menu_1

rotate_line () {
read DEG < $ROTATION
[ $DEG = 0 ] || [ $DEG = 90 ] || [ $DEG = 180 ] || [ $DEG = 270 ] || [ $DEG = 360 ] && sleep 1
DEG=$(($DEG+5))
[ "$DEG" -ge 360 ] && DEG=0
echo $DEG > $ROTATION
# Create svg pic
echo '<svg width="64" height="64" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<circle cx="32" cy="32" r="28" stroke="red" fill="none" stroke-width="3" />
<line x1="32" y1="32" x2="32" y2="4" stroke="black" stroke-width="3" transform="rotate('$DEG' 32 32)" />
</svg>' > $PIC
}
export -f rotate_line

# First call just to make a picture
rotate_line

# =============================================================================
# MAIN LOOP
# =============================================================================

# Infinite loop
while :; do
 
  set_position
  gtkdialog -G 64x64+$CX+$CY -p PREVIEW & GTKPID=$!
 
  wait_for_switch
 
  # Kill Gtkdialog window
  kill $GTKPID

  : > $PRESS
 
  read DEG < $ROTATION
 
  # Move cursor until switch signal will appear again
  until [ "`grep "$PAUSE" $PRESS`" ]; do
    xdotool mousemove_relative --polar $DEG 5
    read X Y <<< `getcurpos`
    [ $X -ge $(($MAXX-1)) ] && X=1 && xdotool mousemove $X $Y
    [ $X -le 0 ] && X=$MAXX && xdotool mousemove $X $Y
    [ $Y -ge $(($MAXY-1)) ] && Y=1 && xdotool mousemove $X $Y
    [ $Y -le 0 ] && Y=$MAXY && xdotool mousemove $X $Y
    sleep 0.1
  done
 
  : > $PRESS
 
  set_position
  echo 0 > $MENU_1_STATE
  display_menu_1
  gtkdialog -G 64x64+$CX+$CY -p MENU_1 & GTKPID=$!
 
  wait_for_switch
 
  kill $GTKPID

  : > $PRESS
 
  case "`cat $MENU_1_STATE`" in
    2) xdotool click 1; sleep 0.5 ;;
    3) xdotool click --repeat 2 1; sleep 0.5 ;;
    0) xdotool click 3; sleep 0.5 ;;
  esac

done

# =============================================================================
PS. Added right-click.

Greetings!
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#24 Post by greengeek »

OK, trialling now.

I think it might be handy to add a title at the top of each new script so that I can identify my feedback appropriately eg: maybe call this new script Radar3 or similar?

Code: Select all

#!/bin/bash

#Script Title = Radar3

# Req.: Gtkdialog >= 0.8.0, xdotool, detect_key, xwininfo, getcurpos, awk, tr

# POSITION can be one of these:
# CURSOR, CENTER, TOP-LEFT, TOP, TOP-RIGHT, BOTTOM-LEFT, BOTTOM, BOTTOM-RIGHT
POSITION=BOTTOM-RIGHT
And, by the way, thanks for all this magnificent help. I'm feeling that this is going to result in a very useful addition to puppy.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#25 Post by greengeek »

SFR wrote: I noticed (in Firefox again) that when a pull-down menu is opened, pressing Pause key closes that menu (Pause key itself is not the problem, but appearing of a new window is).
And again - it doesn't happen with other apps like Geany/DeaDBeef/AviDemux etc...
Have you encountered similar behavior?
Hmmm, now that you mention it I do have that same behaviour when using SeaMonkey. However, only when using any version of radar. Horiz_vertical (keydetect version) does not exhibit that problem.

Is it the display of the radar screen that is upsetting the browser menu display function?

(crazy thought - I wonder if it is possible to use a rotating cursor {ie: switching between 6 different cursors...} to demonstrate the proposed direction of travel, rather than having to open up the svg window?)

While I have been trying to get past various oddities I have sometimes been resorting to using xvkbd (and it's "focus" button and keyboard shortcuts to "grab" control of window menus, and sometimes that has been successful where radar's handling of the menus did not, but I had not noticed the Seamonkey problem. Now that I test it, neither radar nor xvkbd can drive the seamonkey menus correctly, but horiz_vert can. I will keep testing to see if I can clarify my symptoms and find a workaround.

One other question (in case it has any bearing on other testing issues): if I use a /root/startup symlink to run radar I do get the radar display showing up, but no keydetect active. In order for keydetect to work I have to start radar by manually clicking the radar icon inside the folder that also contains keydetect. (I don't have a good understanding of "PATHs" but maybe that's where my problem lies?

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#26 Post by greengeek »

Some testing results:
(Just getting my thoughts on paper...)

Seamonkey menu problem:

If I use radar to position the cursor over the bookmarks tab and then select "click" with the radar menu the bookmarks list appears, then disappears. However, if I position the cursor using the real mouse, then select "click" with the radar menu, it works fine. Is this a problem with radar forcing a change in window focus unnecessarily or non-standardly?

(oddly, when using radar for the move / click combo it LOOKS like the window focus for radar does not change as it always stays on top - So maybe the state of window focus is nothing to do with the problem...or else maybe the way the system changes window focus when I manually interact is different to the way that radar changes focus when switching from move to click???)

Whatever triggers the problem it seems to occur at the moment of the transition from "move" to "click"

This might express more clearly how I'm testing it:

1)Shrink the seamonkey window enough that the radar svg is visible at bottom right corner
2)Use the pause key until the radar menu is displaying its "choose action" menu (and cursor no longer moving)
3)Manually move the mouse to position the cursor over the bookmarks and click the mouse to display the bookmarks list. Hover over one of the bookmarks.
4)Press the pause key. The chosen website is displayed successfully.

Example 2
1)Shrink the seamonkey window enough that the radar3 svg is visible at bottom right corner
2)Use the pause key until the radar circle is rotating.
3)Manually move the mouse to position the cursor over the bookmarks and click the mouse to display the bookmarks list. Hover over one of the bookmarks.
4)Press the pause key when the indicator is horizontal. The bookmarks remain visible and the cursor moves horizontally.
5) Press the pause key again and the bookmarks disappear, so the problem appears to occur at the transition from the move state into the click state

Question: why does radar have the http links around line 89? (Line 126 in radar3). That couldn't be upsetting the browsers could it?

EDIT : deleted some of my poor guesswork from here. I really can't read a complex script to save myself.

Wish I had enough experience/ability to be of some use here... Sadly that is not the case.
Last edited by greengeek on Sun 17 Mar 2013, 09:20, edited 3 times in total.

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#27 Post by greengeek »

Just had another thought - the way it is at the moment the script automatically goes back into "choose direction" mode straight after you select "click". Would it alter the script behaviour if, after selecting click, it went back to the "choose action" menu and waited for the user to specifically choose "move"? (even if all this does is introduce a delay into certain parts of the script).

Might this prevent the focus from dropping away from the highlighted Seamonkey menus too soon?

Previously I said I thought the problem occurred at the moment of switching from "move" to "click", but maybe the problem is that the "click" is too quickly transferring control back over to the "choose direction" script instead of pausing for a moment (to let Seamonkey do it's thing) before going back to the action menu.

(ps: just tell me if my guesses become annoying... :oops: )

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#28 Post by greengeek »

I just tried QTWeb browser and it works fine so far. Will try Opera and some others tomorrow.

Even if there's no way to beat this dropdown menu issue I think this is still going to be very useful.

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#29 Post by SFR »

(crazy thought - I wonder if it is possible to use a rotating cursor {ie: switching between 6 different cursors...} to demonstrate the proposed direction of travel, rather than having to open up the svg window?)
I found only this:
http://www.x.org/archive/X11R7.5/doc/ma ... oot.1.html
-cursor cursorfile maskfile
This lets you change the pointer cursor to whatever you want when the pointer cursor is outside of any window.[...]
-cursor_name cursorname
This lets you change the pointer cursor to one of the standard cursors from the cursor font.
Tried that and indeed doesn't work when cursor is over the window...
One other question (in case it has any bearing on other testing issues): if I use a /root/startup symlink to run radar I do get the radar display showing up, but no keydetect active. In order for keydetect to work I have to start radar by manually clicking the radar icon inside the folder that also contains keydetect. (I don't have a good understanding of "PATHs" but maybe that's where my problem lies?
Fixed.
Question: why does radar have the http links around line 89? (Line 126 in radar3). That couldn't be upsetting the browsers could it?
It's a part of SVG specification (see any of these examples), something like '/root/.config/rox.sourceforge.net'.
EDIT: It seems to work also without those links, but IIRC there are some situations where it's needed (however, I can't recall details).

________________________

The only way to override browsers' issue I found so far is not to kill/raise_back Gtkdialog window while switching from 'radar' to 'menu' mode and vice versa - everything is happening within one, static window now, so no more messing with the focus.
But to keep the window on top, I had to add wmctrl binary to the suite.
And I removed 'CURSOR' option, since window is now on fixed position all the time.

See how it works now.

Greetings!
Attachments
radar-0.4.tar.gz
(36.53 KiB) Downloaded 397 times
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#30 Post by greengeek »

Thats looking pretty good. Nice touch with the rounded corners on the svg.

Also, I tried installing it on Wary 5.2.2 and placed a symlink to xvkbd and radar4 in the startup folder and the PC boots up beautifully into a state where radar4 and xvkbd are both in action and ready to go. Nice combination.

The only real issue I am experiencing so far is that I can't get the radar screen to sit on top of other windows - it always stays in the background behind everything else (so I have to reduce the size of other windows to see it). I guess this means that wmctrl is not working for me. Perhaps I am putting files in wrong places? I have made a folder called /usr/local/apps/radar-0.4 and it contains all the files detect_key, detect_key.C, radar and wmctrl.
(I am using jwm which I notice is not on the list mentioned on the wmctrl page)

Other comments:
1) After I use the "choose action" window to select "click" radar drops back automatically into the "choose direction" mode. Initially that seemed efficient, but now I find it makes it harder to do a "repeated key click". Would it create any adverse problems if that was changed so that after selecting "click" the "choose action" dialog would reappear? Example: when I am using xvkbd I sometimes need to repeatedly click backspace, delete, or page down etc. It would be nice to be able to repeat a keyclick without going through a new "move" procedure. (I guess different users might have a different preference, so I could keep two separate versions of radar to accomodate both methods)

2) The radar sweep is now more jerky than it was previously. It is not a problem but I wondered if this was a deliberate choice, or just a byproduct of the script being "busier" than before?

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#31 Post by SFR »

The only real issue I am experiencing so far is that I can't get the radar screen to sit on top of other windows - it always stays in the background behind everything else[...]
Strange, I'm using Compiz on daily basis, but just tested the script under JWM and 'always-on-top' also works fine for me.
Did you check wmctrl permissions?
Also, what will happen when, after launching radar, you'll type directly (open terminal in folder where wmctrl is):

Code: Select all

./wmctrl -r "OneSwitch - Radar/Menu" -b add,above
Another thought - it's rather unlikely, but perhaps you need to recompile wmctrl by yourself..?
1) After I use the "choose action" window to select "click" radar drops back automatically into the "choose direction" mode. Initially that seemed efficient, but now I find it makes it harder to do a "repeated key click". Would it create any adverse problems if that was changed so that after selecting "click" the "choose action" dialog would reappear? Example: when I am using xvkbd I sometimes need to repeatedly click backspace, delete, or page down etc. It would be nice to be able to repeat a keyclick without going through a new "move" procedure. (I guess different users might have a different preference, so I could keep two separate versions of radar to accomodate both methods)
Done. I too think it's more comfortable.
2) The radar sweep is now more jerky than it was previously. It is not a problem but I wondered if this was a deliberate choice, or just a byproduct of the script being "busier" than before?
I reduced number of possible directions from 71 to 35 since some of intermediate degrees were being disregarded by xdotool.
Now cursor really goes where radar shows and indeed - CPU suffers 2xLess. :wink:

Code: Select all

#!/bin/bash

# Radar v0.5

# Req.: Gtkdialog >= 0.8.0, xdotool, detect_key, wmctrl, xwininfo, getcurpos, awk, tr

# POSITION can be one of these:
# CENTER, TOP-LEFT, TOP, TOP-RIGHT, BOTTOM-LEFT, BOTTOM, BOTTOM-RIGHT
POSITION=BOTTOM-RIGHT

# =============================================================================
# Init
# =============================================================================

# Exit if another instance is already running
sleep 0.1
[ `pidof $(basename $(readlink -e "$0")) -o %PPID | wc -w` -gt 1 ] && exit

APPDIR="$(dirname $(readlink -e "$0"))"

POSITION="`echo $POSITION | tr [:lower:] [:upper:]`"

TEMPDIR=/dev/shm/one_switch_temp
mkdir $TEMPDIR

# Delete tempdir and kill all subprocesses on exit
trap 'rm -rf $TEMPDIR; killall detect_key; kill $GTKPID' EXIT

export PIC=$TEMPDIR/cursor_pic
export ROTATION=$TEMPDIR/cursor_rotate
export MENU_1_STATE=$TEMPDIR/menu1_state
export MODE=$TEMPDIR/mode
export DELAY4MENU=$TEMPDIR/delay4menu
export DELAY4RADAR=$TEMPDIR/delay4radar
echo -10 > $ROTATION
echo 0 > $MENU_1_STATE
echo radar > $MODE
echo 4 > $DELAY4RADAR

PRESS=/tmp/switch_state
[ -f $PRESS ] && rm $PRESS
PAUSE="key 119 state 0"
"$APPDIR/detect_key" /dev/input/event0 > $PRESS &

# Read current screen resolution
read MAXX MAXY <<< `xwininfo -root | awk 'NR>=8&&NR<=9 {print $2}'`

# =============================================================================
# Gtkdialog structures
# =============================================================================

export PREVIEW='
<window title="OneSwitch - Radar/Menu" width-request="74" height-request="74" decorated="false" skip-pager-hint="true" skip-taskbar-hint="true" resizable="false">
  <pixmap>
    <variable>PICTURE</variable>
    <input file>'"$PIC"'</input>
  </pixmap>
  <timer visible="false" milliseconds="true" interval="200">
    <action>animate</action>
    <action>refresh:PICTURE</action>
  </timer>
</window>
'

# =============================================================================
# Functions
# =============================================================================

wait_for_switch () {
  until [ "`grep "$PAUSE" $PRESS`" ]; do
    sleep 0.1
  done
}

set_position () {
case "$POSITION" in
  "CENTER" ) CX=$(($MAXX/2-37)); CY=$(($MAXY/2-37)) ;;
  "TOP-LEFT" ) CX=0; CY=32 ;;
  "BOTTOM-LEFT" ) CX=0; CY=$(($MAXY-32-74)) ;;
  "TOP-RIGHT" ) CX=$(($MAXX-74)); CY=32 ;;
  "TOP" ) CX=$(($MAXX/2-37)); CY=32 ;;
  "BOTTOM" ) CX=$(($MAXX/2-37)); CY=$(($MAXY-32-74)) ;;
  * ) CX=$(($MAXX-74)); CY=$(($MAXY-32-74)) ;;
esac
}

animate () {
case "`cat $MODE`" in

  "radar" )
    read DEG < $ROTATION
    read DELAY < $DELAY4RADAR
    if [ $DEG = 0 ] || [ $DEG = 90 ] || [ $DEG = 180 ] || [ $DEG = 270 ]; then
      [ $DELAY -gt 0 ] && ((DELAY--)) && echo $DELAY > $DELAY4RADAR && exit
    else
      echo 4 > $DELAY4RADAR  
    fi
    DEG=$(($DEG+10))
    [ "$DEG" -ge 360 ] && DEG=0
    echo $DEG > $ROTATION
    # Create svg pic
    echo '<svg width="64" height="64" xmlns="http://www.w3.org/2000/svg">
    <circle cx="32" cy="32" r="28" stroke="red" fill="none" stroke-width="3" />
    <line x1="32" y1="32" x2="32" y2="4" stroke="black" stroke-width="3" transform="rotate('$DEG' 32 32)" />
    </svg>' > $PIC
  ;;

  "freeze" )
    exit
  ;;

  "menu" )
    read DELAY < $DELAY4MENU
    if [ $DELAY -gt 0 ]; then
      ((DELAY--)); echo $DELAY > $DELAY4MENU
    else
      echo 4 > $DELAY4MENU      
      case "`cat $MENU_1_STATE`" in
        0) POS=0; echo 1 > $MENU_1_STATE ;;
        1) POS=16; echo 2 > $MENU_1_STATE ;;
        2) POS=32; echo 3 > $MENU_1_STATE ;;
        3) POS=48; echo 0 > $MENU_1_STATE ;;
      esac
      echo '<svg width="64" height="64" xmlns="http://www.w3.org/2000/svg">
      <text font-family="DejaVu Sans" font-size="13" font-weight="bold">
      <tspan x="12" y="12">Move</tspan>
      <tspan x="14" y="28">Click</tspan>
      <tspan x="1" y="44">Db-Click</tspan>
      <tspan x="3" y="60">Rt-Click</tspan>
      </text>
      <rect x="0" y="'$POS'" width="64" height="16" stroke="darkgreen" fill="green" stroke-width="2" opacity="0.5" />
      </svg>' > $PIC
    fi
  ;;
  
esac
}
export -f animate && animate


# =============================================================================
# MAIN LOOP
# =============================================================================

set_position
gtkdialog -G 64x64+$CX+$CY -p PREVIEW & GTKPID=$!
sleep 1
"$APPDIR/wmctrl" -r "OneSwitch - Radar/Menu" -b add,above

# Infinite loop
while :; do
    
  wait_for_switch
  
  : > $PRESS
  echo freeze > $MODE
 
  read DEG < $ROTATION
  # Move cursor until switch signal will appear again
  until [ "`grep "$PAUSE" $PRESS`" ]; do
    xdotool mousemove_relative --polar $DEG 6
    read X Y <<< `getcurpos`
    [ $X -ge $(($MAXX-1)) ] && X=1 && xdotool mousemove $X $Y
    [ $X -le 0 ] && X=$MAXX && xdotool mousemove $X $Y
    [ $Y -ge $(($MAXY-1)) ] && Y=1 && xdotool mousemove $X $Y
    [ $Y -le 0 ] && Y=$MAXY && xdotool mousemove $X $Y
    sleep 0.1
  done

  while :; do
    : > $PRESS
    echo 0 > $DELAY4MENU
    echo 0 > $MENU_1_STATE
    echo menu > $MODE
  
    wait_for_switch
    echo freeze > $MODE
  
    case "`cat $MENU_1_STATE`" in
      1) break ;;
      2) xdotool click 1 ;;
      3) xdotool click --repeat 2 1 ;;
      0) xdotool click 3 ;;
    esac
  
    sleep 0.5
  done
  echo radar > $MODE
  echo 0 > $DELAY4MENU
  echo 0 > $MENU_1_STATE
  : > $PRESS
done

# =============================================================================
__________________

A bit different approach, using dzen2 (wmctrl no needed, dzen acts as a dock): a top or bottom bar with rolling options. No radar picture, but arrows instead (only 8 directions).
See attached tgz.

Greetings!
Attachments
NavBar.tar.gz
(20.94 KiB) Downloaded 429 times
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#32 Post by greengeek »

Navbar looks interesting. I will have to give this a good try on several different puppies.

Two things I have noted so far:
1) On my Slacko53 install some program windows opened up so large that the control functions (minimise/maximise/close) are hidden behind the navbar. I think I can get around this by resizing manually, then it should be ok next time I open that program.
2) If I accidentally rightclick the navbar it stops running and disappears. :-)
(Mind you that might be a handy shortcut to stop the script if needed...)

Also noted that in my PuppyNOP532 installation Opera seems to have the old symptom of closing the bookmarks list when clicking. Will have to try Opera on a wider variety of pups. At least functionality seems good with pups using Seamonkey and Firefox.

EDIT :Both radar4 and Navbar run really well on MagooPup (which is based on Precise and targeted at the vision-challenged) so I think these scripts are ready to be mentioned on the other thread about single-switch functionality.

Are you happy for me to go ahead and post there or would you prefer to do it?

I will be doing more testing with a range of puppies and browsers to get a better idea of what can be recommended, but I think the performance on Magoo suggests that these scripts are already at the stage where they could benefit many users, so I think the time is right to mention them.

What do you think?

(and which names do you prefer to call your scripts? I prefer radar4 and Navbar, but maybe you prefer one_switch or similar? )

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#33 Post by SFR »

1) On my Slacko53 install some program windows opened up so large that the control functions (minimise/maximise/close) are hidden behind the navbar. I think I can get around this by resizing manually, then it should be ok next time I open that program.
Hmm, when NavBar is already running and then I maximize a window, its top bar (with all control buttons) is right below NavBar.
Did you try that? (tested in JWM/Compiz - Slacko-5.5)
2) If I accidentally rightclick the navbar it stops running and disappears. :)
(Mind you that might be a handy shortcut to stop the script if needed...)
Luckily dzen has "-e ungrabmouse" option - it disables that behavior, but for now it's indeed more convenient to have this "shortcut" active.
Also noted that in my PuppyNOP532 installation Opera seems to have the old symptom of closing the bookmarks list when clicking. Will have to try Opera on a wider variety of pups. At least functionality seems good with pups using Seamonkey and Firefox.
Maybe problems with Opera will end when they'll switch to WebKit..?
EDIT :Both radar4 and Navbar run really well on MagooPup (which is based on Precise and targeted at the vision-challenged) so I think these scripts are ready to be mentioned on the other thread about single-switch functionality.

Are you happy for me to go ahead and post there or would you prefer to do it?

I will be doing more testing with a range of puppies and browsers to get a better idea of what can be recommended, but I think the performance on Magoo suggests that these scripts are already at the stage where they could benefit many users, so I think the time is right to mention them.

What do you think?

(and which names do you prefer to call your scripts? I prefer radar4 and Navbar, but maybe you prefer one_switch or similar? )
Be my guest. :)

And I think "Radar" (now 0.6) and "NavBar" are fine.

______________

I found statically (I guess) compiled version of xdotool.
I included it into the suite, so practically everything what's needed is in one place now.
(However if one has xdotool already installed - it'll be utilized in the first place.)

In addition I polished up both scripts a bit and added 'Drag' menu option, so now one can drag icons/windows and select text.

Greetings!
Attachments
Radar-0.6.tar.gz
(66.89 KiB) Downloaded 424 times
NavBar-0.2.tar.gz
(51.7 KiB) Downloaded 418 times
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

User avatar
greengeek
Posts: 5789
Joined: Tue 20 Jul 2010, 09:34
Location: Republic of Novo Zelande

#34 Post by greengeek »

Magnificent work SFR - thank you very much. These scripts seem to be very useful in their current form. I need to do a lot of testing across a range of puppies and browsers before I can make any further comments (but will not be around the computer much for the next few weeks...)

Hopefully others will also give some feedback over the next few weeks and pinpoint good combinations of puppy/browser/window manager.

This has been a very satisfying effort for me. Thanks so much!

User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#35 Post by SFR »

Thanks Greengeek, it'll be very helpful since these apps really like to behave differently under various WMs/Puppies.
For example, I just found two another oddities:
- under JWM dragging window causes xdotool freeze until left mouse button is pressed (physically), but no problems under Compiz and Openbox
- In Lupu-528 NavBar is displayed ~ in the middle of the screen and there's no way to adjust its Y position (perhaps there's a need to recompile dzen right there..?)

Anyway, Will asked to have more control on Radar size, so I made the code more configurable - most of settings is customizable now (see at the beginning of the code).
Same done to NavBar.

______________

EDIT: Ok, I have found a workaround for 'JWM window move' problem:
1. Open as text /root/.jwm/jwmrc-personal
2. Change these two parameters from 'outline' to 'opaque':

Code: Select all

<!-- The move mode (outline or opaque) -->
<MoveMode>opaque</MoveMode>

<!-- The resize mode (outline or opaque) -->
<ResizeMode>opaque</ResizeMode>
3. Restart JWM

And now it works as it should.

_______________
me wrote:- In Lupu-528 NavBar is displayed ~ in the middle of the screen and there's no way to adjust its Y position
It's not Lupu specific, but Openbox issue. But I also found a workaround:
Go to Menu -> Desktop -> Desktop Settings -> Openbox Config (or Obconf or similar)
then press 'Windows' tab and make sure that:
- Place new windows under the mouse pointer
- Center new windows when they are placed
checkboxes are both UNCHECKED.

It seems to (usually) work, however only TOP position is being respected.
BOTTOM works, so far, only under Compiz...

BTW, I reuploaded the attachment with added 'readme.txt', which contains the above workarounds.

Greetings!
Attachments
radar-0.7+navbar-0.3.tar.gz
(119.13 KiB) Downloaded 421 times
[color=red][size=75][O]bdurate [R]ules [D]estroy [E]nthusiastic [R]ebels => [C]reative [H]umans [A]lways [O]pen [S]ource[/size][/color]
[b][color=green]Omnia mea mecum porto.[/color][/b]

Post Reply