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..)

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...

Quote:

I wonder if the relative cpu priorities of each process could have such an effect?

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.

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..?

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.

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!

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)..?

Quote:

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.

Quote:

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...

Quote:

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

Done.

Quote:

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.

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.

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?

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?

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, 05:20; edited 3 times in total

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.

(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?)

-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...

Quote:

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.

Quote:

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.

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?

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum