OneSwitch pet - control a PC using a single switch

A home for all kinds of Puppy related projects
Message
Author
User avatar
SFR
Posts: 1800
Joined: Wed 26 Oct 2011, 21:52

#61 Post by SFR »

Ok, it works as follows:
If Radar or NavBar is already running and a user tries to launch the other one (no matter if from GUI or directly), a pop-up window will appear (see screenshot) with 'Swap' button.

Thanks for testing &
Greetings!
Attachments
OneSwitch-1.1.4.pet
(93.1 KiB) Downloaded 440 times
Screenshot.jpg
(72.22 KiB) Downloaded 486 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

#62 Post by greengeek »

Excellent, thanks. The swap works well in both directions.

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

#63 Post by greengeek »

This thread now split off from the original early stage programming discussions and relabelled in order to make this topic easier for people to find.

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#64 Post by Ted Dog »

off-topic is not correct way of splinting off thread. This hides it from non-registered members. :?

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

#65 Post by greengeek »

Ahhh, thanks Ted Dog - I didnt think of that. I will ask Flash to relocate it. What do you think would be the best place for this to be moved to?

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#66 Post by Flash »

:oops: Oops, I didn't mean to put it in Off-topic when I split it. I guess I didn't check afterward.

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#67 Post by Ted Dog »

Now that you read this far. Here are two threads that follow the effort one is the hardware mods ideas and actions, the other is the software


Hardware Thread
http://www.murga-linux.com/puppy/viewtopic.php?t=87103

Software Thread
http://www.murga-linux.com/puppy/viewtopic.php?t=85466

Enjoy!

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

#68 Post by greengeek »

I am proposing a slight change to the radar choices and wondered what other users thought...

I find I do not use the "cycle" function as it seems just as easy to pick the desired window up off the taskbar - but what I really miss is the ability to drag an entire window using Alt/Leftclick. This seems so much easier than trying to grab a window by it's title bar and then selecting drag - I often find the title bar is offscreen or too far away etc etc, whereas alt/leftclick allows you to grab the window anywhere that it is visible.

So what I have trialled is a mod to radar, eliminating the cycle function and replacing it with "DragWindow". (we still need to retain "Drag" as it acts as a "lasso" function within the window contents, whereas "DragWindow" moves the whole window as one).

Should we ask SFR to make this function part of an official OneSwitch - or should I just keep this mod as my personal variation?

Mod as follows:

Remove "cycle" code from /usr/local/OneSwitch/radar-main

Code: Select all

             3) "$XDOTOOL" keydown alt
                until [ "`grep "$SWITCH" $PRESS`" ]; do
                  "$XDOTOOL" key Tab
                  sleep $CYCLE_DELAY
                done
                "$XDOTOOL" keyup alt
             ;;
and replace with a slightly modified version of the "drag" code:

Code: Select all

             3) "$XDOTOOL" keydown alt mousedown 1
                while :; do
                  align_radar
                  sleep $TRANS_DELAY
                  : > $PRESS
                  echo radar > $MODE
                  wait_for_switch
                  echo freeze > $MODE
                  move_mouse
                 
                  reset_menu
                  echo menu_3 > $MODE
                  wait_for_switch
                  echo freeze > $MODE
           
                  [[ $(<$MENU_STATE) = 0 ]] && "$XDOTOOL" keyup alt mouseup 1 && break
                done
             ;;
and then altered line 281 to change the radar display from "cycle" to "DragWindw"

Code: Select all

      <tspan x="'$TEXT_X'" y="'$((3*$SIZE))'">DragWindw</tspan>
I could not see an easy way to make this change utilising the "custom" method but maybe there is a way to do that? (Although my preference is for the DragWindw function to be available as early as possible in the radar menu, rather than having to step too deep).

I haven't trialled this on navbar yet but I guess it will be identical.
.
Attachments
DragWindow Mod.jpg
(43.74 KiB) Downloaded 221 times

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

#69 Post by SFR »

Hey Greengeek, nicely done! :)

Good to see you're getting accustomed to the OneSwitch code, which is also good, since I need to take a serious break from computing in general soon - I badly strained my eyes lately. :roll:

Well, the idea is fair, but Radar's area is so tight that I can see (yet) only these alternatives:
1. Put it instead of other option, as you did.
2. Increase the amount of options per page to six, by decreasing font size - it's the most challenging way and the result might be unsatisfactory (too small font, ugly design).

In case of NavBar there's no reason to hesitate, because there's still some spare space (at least on my 1366px wide screen :wink: ).

BTW, I'm quite surprised that it worked this way, but yes - we can utilize one of "Custom" fields, even in two ways:

1. The code has to be folded into one, single line and we can't use quotes around $XDOTOOL command:

Code: Select all

$XDOTOOL keydown alt mousedown 1; while :; do align_radar; sleep $TRANS_DELAY; : > $PRESS; echo radar > $MODE; wait_for_switch; echo freeze > $MODE; move_mouse; reset_menu; echo menu_3 > $MODE; wait_for_switch; echo freeze > $MODE; [[ $(<$MENU_STATE) = 0 ]] && $XDOTOOL keyup alt mouseup 1 && break; done
Additionally, the code of /usr/local/OneSwitch/radar-config needs to be rectified in order to properly handle > characters in custom string i.e. all these lines:
<default>'$CUSTOM_1_EXEC'</default>
...
<default>'$CUSTOM_2_EXEC'</default>
...and so on...

have to be changed to:

Code: Select all

<default>"'$CUSTOM_1_EXEC'"</default>
...and so on...

OR

2. Put the code into a function (within "Functions" area in /usr/local/OneSwitch/radar-main):

Code: Select all

dragwin () {
  "$XDOTOOL" keydown alt mousedown 1 
  while :; do 
    align_radar 
    sleep $TRANS_DELAY 
    : > $PRESS 
    echo radar > $MODE 
    wait_for_switch 
    echo freeze > $MODE 
    move_mouse 
    reset_menu 
    echo menu_3 > $MODE 
    wait_for_switch 
    echo freeze > $MODE 
    [[ $(<$MENU_STATE) = 0 ]] && "$XDOTOOL" keyup alt mouseup 1 && break 
  done
}
export -f dragwin
and then type dragwin into one of custom fields in GUI.

But I agree, would be nice to have it closer than on 3rd page...
Besides, you're surely using/testing OneSwitch much more often and extensively than me (I'm running it only while testing the code), so it's up to you. :)

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

#70 Post by greengeek »

Thanks SFR - some good suggestions there. It will be good to see what the consensus is with other users. I will wait for their feedback before incorporating any change.

It is good that you have a break - what you did in developing this pet is fantastic work and extremely useful and I am sure i am not alone in wanting to thank you for your handling of the coding pressure.

I imagine the heatwave there has not helped the dry eyes or the cpu temperature!

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

#71 Post by SFR »

greengeek wrote:I imagine the heatwave there has not helped the dry eyes or the cpu temperature!
No doubt it hasn't... And won't be cooler for the next 2-3 weeks at least. :roll:

One more thing, before I'll take a break. :wink:
I did split all parts of the "main loop" in Radar and NavBar into a separate functions.
Thanks to this the code is much more readable (no more endless levels of indentations) and easier to maintain, I hope.
Attached here for now, since I haven't tested yet if everything still works 100% correctly.
If all will be ok, this version should be a base for future development.

Thanks &
Greetings!
Attachments
OneSwitch-1.4.pet
(94.55 KiB) Downloaded 392 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
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

Changing Drag

#72 Post by mikeslr »

Hi greengeek, SFR:

Another method for including drag-window might be assigning it to one of xvkbd's function keys. There are twelve. All quickly accessible. And only the F1 and F11 keys are commonly used by applications. See attached [Even if an application assigned some routine to a function key, they is almost always a method within such application to modify the Hotkeys it uses], And since we can modify the labels xvkbd displays, the Function Key Labels can take a mnemonic: for example, if F3 were assigned the drag-window function, it could be labeled DW.

Re: Adding additional functions to radar, Radar's panels/windows currently can display only 5 choices, and after the first "compass" panel, two choices must be assigned to moving to earlier or later panels. Although radar's current first panel display -- a circle within a square-- is aesthetically pleasing, I don't think it's actually necessary. It is likely that xvkbd's keyboard will be adjacent. The result is that above radar's display is screen-space which is, for all practical purposes, unusable. Perhaps, therefore, radar's basic display could be a rectangle with greater height which would allow more choices to appear on each panel. Alternatively --or additionally-- perhaps some kind of index-paging system could be used and displayed rather than "back" and "more." "More" would bring up a list of function panels including the "compass" panel.

mikesLr
Attachments
4_SimpleFunctionKeys.png
Function Keys generally not assigned functions
(26.27 KiB) Downloaded 202 times

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

Re: Changing Drag

#73 Post by greengeek »

mikeslr wrote: The result is that above radar's display is screen-space which is, for all practical purposes, unusable. Perhaps, therefore, radar's basic display could be a rectangle with greater height which would allow more choices to appear on each panel.
Interesting idea. That will be worth experimenting with. I do feel the idea of reserving the whole righthand margin of the screen is more appropriate to widescreen displays though. (I do most of my troubleshooting on a netbook so I find that even the space above the radar display is valuable)

My first version of switchpup used XFCE which makes it very easy to totally reserve a variable width margin at any edge of the screen, and I do intend to go back to that version and refine it once I'm happy with the JWM versions.

With regard to the the idea of increasing functionality by programming the xvkbd F keys - do you find that xvkbd is always visible? On my system it does not stay visible, despite the run-time parameter of --always-on-top.

if xvkbd would stay on top I think it would be great to be able to enlarge it's Fkeys and programme some functions there. (although having said that I do sometimes prefer to NOT have xvkbd visible - although I can use a different desktop if I need more clear space...)

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

Consider using rg66's X-precise as a base

#74 Post by mikeslr »

Hi greengeek,

Once you're satisfied with SwitchPup running under jwm, you might want to consider basing a version on rg66's X-precise. http://murga-linux.com/puppy/viewtopic.php?t=87717. Although he is still working out some kinks, it is already fully functional. Xfce, like openbox and Lxde, and unlike jwm are fully XDG compliant. I think SFR mentioned somewhere not being XDG compliant is the cause of one having to use Xvkbd's focus button (and then click on desired target application) to focus output to a target application. Anything which eliminates time and key-events is a step forward. Additionally, X-Precise is "bare-bones": Add any precise application you want and not clutter the menu with applications a OneSwitch user is unlikely to use. And as rg66 mentioned, many apps from Carolina may also work.
I've actually started to built a "OneSwitch" Pup based on X-precise. With one exception the OS worked fine, as well as any other such Pup. That exception was excessive delay before Thunar opened. Rg66 quickly responded to my concern on the above thread. [I didn't mention that the delay may have been caused in part by my 2 sd drives adding up to 1.5 terabytes, divided into 9 partitions].
I stopped building to address more pressing concerns: (1) Need to revise keyboardchoices pet now that SFR built into radar's xvkbd mode's alternate scan methods and (2) general difficulty in using the Square Keyboard, suggesting that I re-think it.
What I particularly like about Xfce (and Lxde) is the ease with which a second panel, populated by launchers for frequently employed apps, can be created that remains hidden until moused-over. Launcher Icon size can be set to make them easy targets.

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

#75 Post by greengeek »

Sounds great. I feel like I'm not too far away from switchpup 1.0, and after that I'm keen to get into some more adventurous versions in an effort to boost productivity. I'm keen to try your X-precise when you're ready for some testers.

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

Not my OneSwitchPup & Not covering xvkbd keyboard

#76 Post by mikeslr »

Hi greengeek,

First, not having apps cover the keyboard-- the following works. Right-click the app's title bar and select "Stick." Thereafter, you can move and resize it to your heart's content. It will remember it's parameters when you close it so that when re-opened it will occupy exactly the same screen area until you choose to move or resize it again, or "unstick" it. Maximizing will, however, overlay the keyboard until "unmaximized".
Edit: Actually, I just tried to do the above in a Precise Pup to which I had installed vicmz's OpenboxPlus. Abiword didn't have a "sticky" option from its Titlebar. So I selected Layer>Always on bottom. That actually worked better: xvkbd's keyboard remained on top even when Abiword was Maximized. Well, not so much. It didn't survive closing either Abiword or geany.I wonder if "sticky" is exclusive to xfce?
Unfortunately, I don't know how to accomplish the either effect on initial bootup or the first opening of an app. I think that can be done with some apps, just as with the xvkbd keyboard, by setting perameters in a script or the exec definition used in the desktop file. [I know, annoyingly, that OpenOffice Lite opens with fixed parameters that I haven't figured out how to change]. The alternative is to use a tiling window manager I haven't been able to convince anyone to build.
There's really no reason for me to build an alternate OneSwitch Pup. I started while you were "on hiatus", but now that you're building a Pup which, i expect, will require less resources than the excellent Pups ETP is working on, I see no reason to duplicate your effort. Frankly, at this stage you have a better grasp than I of the technical aspects.
If you had no interest in building an XDG compliant Pup, it might make sense for me to modify one of the SFSes to provide that functionality to SwitchPup. It still might make sense for me to build an SFS which includes those applications you decide not to incorporate. But, throughout the now several threads I've tried to identify things which I thought worth including in a OneSwitch Pup: such as ETP's advice regarding visabilty --i.e., the large white mouse cursor and the faeza_lrx theme-- and my suggestions for "mouseless" addons to web-browsers. By the way, I've discovered another. Opera has an extension named "Hit-a-Hint" which works very well. So, in addition to the tasks I mentioned in my previous post, I think a separate "OneSwitch" hints thread which would accumulate all suggestions in one location may be of value.

mikesLr

Edit: Google Search for Abiword Preference Tweaks revealed a settings config file at
/.AbiSuite. Note the dot. Perhaps this can be used to set Abiword's parameters when opened the first time.

User avatar
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

Providing for up to 16 Special Routines

#77 Post by mikeslr »

Hi greengeek and SFR,

Pleased with the 1Switch keyboard, disappointed with Square, I was already thinking again about keyboards when greengeek mentioned the problem of the function keys being obscured by opened applications. Unlike 1Switch where I built in lots of ESC keys that did nothing other than return the cursor to its "Start" position-- the problem with Square is that an inaccurate guess in the direction radar would send the cursor can not be easily corrected. I was also thinking about three routines which could be of value in Square-"manual" [two generally]: jump to Word-completion Window, Jump back to Central Space Key and Jump to Start Menu.
It all fell into place when I realized that Square operates without a keypad, and 1Switch doesn't need it. Conclusion: Move the Function Keys to the Keypad. [And turn off the Function Key Line on the Keyboard].
Well, that's the idea. Reality may be something different. I'll see what I can come up with on the Keyboard end.
SFR -- are you certain radar's circular scan mode is working correctly. I thought it was supposed to return the cursor to a centrally located Space-key. It seems to do the same thing as linear: return the cursor to the keypad's top-left corner.
greengeek, now that you've got the hang of xdotools, and SFR -- think about the three routines I mentioned above; Jump to Start Menu should be easy as it is to fixed x,y co-ordinates.; Jump to Central Space Key should work the same way the Alternate radar SFR wrote when I first suggested Square, except that scrolling is never turned on; and Jump to Word-completion window should work similar to how radar finds the top-left corner of the keyboard when xvkbd mode is invoked: using the title of the window.
My right-brain-hemisphere [gestalt-visioning] has always been stronger than my left-analytical-functioning brain-hemisphere. Probably because the latter depends on memory providing details and I have a memory like a teflon strainer. So I really would hate having to master new detail-rich material, in this case, xdotool.

mikesLr

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

#78 Post by SFR »

Hi Mike
SFR -- are you certain radar's circular scan mode is working correctly. I thought it was supposed to return the cursor to a centrally located Space-key. It seems to do the same thing as linear: return the cursor to the keypad's top-left corner.
Hmm, yes - it works as it should for me (OneSwitch-1.4 + "xvkbd - Virtual Keyboard (square)" layout).
Maybe the console output would tell something:

Code: Select all

/usr/local/OneSwitch/radar-main
Also ensure, that in /usr/local/OneSwitch/radar_settings is:
XVKBD_SCAN=Circular

I'll digest your other ideas, but so far I keep trying (mostly unsuccessfully - I can't resist :wink: ) to reduce the time I'm spending in front of the monitor, in order to not overstrain my eyes again.

BTW, a quick/alternative solution for "Jump to Menu" - type it into one of Custom fields:

Code: Select all

$XDOTOOL mousemove 10 $(($MAXY-10)); break 2
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
mikeslr
Posts: 3890
Joined: Mon 16 Jun 2008, 21:20
Location: 500 seconds from Sol

Revised Keyboard Choices Pet

#79 Post by mikeslr »

Hi greengeek, SFR and All,

With SFR having included both linear (for 1Switch & default keyboards) and circular (for Square keyboard) xvkbd mode scanning patterns in radar and Navbar, and selection between them being made by the radar/Navbar GUI, revision of the keyboard_choices pet was required. I've attached that revision. It provides for choosing between the keyboard layouts without having any effect on radar/navbar.

I've changed its desktop category to X-Utility, so it should now appear on the Utility submenu. I made that change after discovering that the previous category assignment did not generate a menu entry when XFCE was used as window manager. I was testing how things held together using rg66's X-precise as a base. It seems to work well. However, my initial impression is, like jwm and unlike Openbox, I seem to have to focus on a target application even when only one target application is open. Will test more to confirm.
SFR -- you were right, the circular scan pattern in 1.4 works. I think I must have accidentally installed 1.1.4.
Attachments
keyboard_choices-0.92.pet
Revision to co-ordinate with OneSwitch 1.4 and above
(9.88 KiB) Downloaded 358 times

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

Re: Revised Keyboard Choices Pet

#80 Post by greengeek »

mikeslr wrote: I seem to have to focus on a target application even when only one target application is open.
I haven't been too worried about needing to use the focus button - I think it is good practice for the user to do it to ensure they get the exact outcome they want. Yes,any extra keypresses are a pain, but typing into thin air or into the wrong box is more of a pain.

And if xvkbd is being used to generate keyboard shortcuts then it is vital that no guesses are made about where those commands are sent I think.

If someone was using this sort of pup JUST as a communicator (keyboard output straight into a textbox) it would be beneficial to not require focussing, but when multiple functions are in use I think there is more to lose by relying on correct AUTOfocus than assuming a need for manual focus.

Post Reply