Puppy Linux Discussion Forum

[SFR]

[greengeek]

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

[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/8361263/detect-mouse-click-in-bash-script

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

[SFR]

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

[SFR]

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

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

Greetings!

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

[SFR]

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

[SFR]

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

[greengeek]

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

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

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