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.

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.

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:

/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 ) 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:

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.

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.

Considering moving the Function Keys to the keypad as a possible remedy for target applications obscuring the keyboard, I turned Function Keys off using xvkbd's menu. Although examining the config file for xvkbd's strip keyboard indicates that function keys can be assigned to the keys on the keypad, doing so and turning the keyboard function keys off won't alleviate the overlap problem. The remaining keys on the keyboard increase in size vertically so that the keyboard occupies the same screen-space.
But in exploring the 1Switch keyboard again I think there can be some improvement. Although, in building a keyboard I use the computer's built-in keyboard and mouse, I always test the results using radar. Radar, in xvkbd-linear mode, begins its automatic scroll pattern at the left top corner. I placed the spacebar there reasoning that it would be one of the most frequently used keys. I now wonder if radar's default timing provides sufficient opportunity to press the "button" before the cursor will have scrolled below top row. And, if the spacebar isn't the "first" key, what key would you recommend as the first key?
I placed an Esc Key on each row. Pressing the "button" while the cursor is over an Esc key does nothing other than returning the cursor to the start of its scroll pattern. Esc keys enable easy recovery if the cursor is scrolling on the wrong row. Most are near the end of their rows, so also serve to return the cursor to the start of the pattern rather than allowing the cursor to scroll beyond the keyboard and enduring the time it would take to re-enter xvkbd mode. But, I wonder if they might be better placed near the middle of the row? Perhaps a "Beginner's" keyboard until the user becomes familiar with the characters appearing on each row. I know I had to "Esc" several times having "missed" the correct row, or having pressed the "button" too soon, starting the right-ward scroll on the wrong row.
Can either of these concerns be handled through adjustments in radar's config file? Frankly, I'm not certain what each parameter is supposed to accomplish?
Regarding having to focus on a target application rather than respond to a mis-directed keypress: Radar's toggle works well to change focus. It takes far less time to send a "backspace" to erase a misplaced keypress followed by radar's toggling to the desired target, than maneuvering to the focus key, then allowing the mouse-cursor to scroll off the keyboard, manually directing the cursor onto the desired target application's title bar, sending a keypress and then re-entering xvkbd mode to begin commence typing.

The remaining keys on the keyboard increase in size vertically so that the keyboard occupies the same screen-space.

But the geometry of the keyboard is easy to control at start time. Do I understand your meaning correctly - are you wanting to reduce the keyboard height?

Quote:

...begins its automatic scroll pattern at the left top corner. I placed the spacebar there reasoning that it would be one of the most frequently used keys. I now wonder if radar's default timing provides sufficient opportunity to press the "button" before the cursor will have scrolled below top row. And, if the spacebar isn't the "first" key, what key would you recommend as the first key?

Good point - there is insufficient time to think about clicking a row, before the cursor has already gone past it. The first key almost needs to be the least valuable one. (in fact - may be some value in keeping the function keys just as a "filler row" to allow the senses time to register the cursor position).

Quote:

Regarding having to focus on a target application rather than respond to a mis-directed keypress: Radar's toggle works well to change focus. It takes far less time to send a "backspace" to erase a misplaced keypress followed by radar's toggling to the desired target,

What do you mean by the toggle? Maybe I haven't used this mode enough to grasp what you are referring to...

You correctly understood: My intention had been to reduce the keyboard height by turning off the top, Function key, row. But you're also correct on two other points: (1) the keyboard can be reduced in size so that it will, at startup, be smaller and (2) the first key --and by extension-- the first row should house seldom used key-values to provide the user with a "filler row" to "to allow the senses time to register the cursor position."
I mis-spoke when I used the term "toggle." I meant cycle. I took the attached screenshot after I invoked radar's cycle mode. At the time I had geany, abiword and opera opened. radar --cycling focus among them-- shows that at that moment pressing the "button" would have assigned focus to geany. Geany's border also reflects that. [I also had had mtpaint snapshot open, but had set it to take a screenshot automatically after a given amount of time. Mtpaint snapshot had been among the applications offered for focus by an icon which, however, "disappeared" in the interval between triggering the snapshot and its effectuation]*.
By the way, the system appearing in the snapshot is pemasu's raring 3.9.9.1** to which vicmz's OpenboxPlus with lxpanel was added. The icons theme is faenza_lrx recommended by ETP, although few of its icons appear. Other visual effects recommended by ETP were also employed. This is currently the system I'd recommend for two reasons: (1) When only one application is open, Openbox assigns focus to it automatically; and (2) although to take the screenshot I set the second --left-edge-- panel to always show, it is usually set to hide the launcher's unless moused-over. As it shows, the left-panel can be populated with large launchers of commonly needed applications, fairly easily activated by radar in "move cursor then click" mode. The launchers on the bottom panel can also be resized. But that would require either moving or eliminating the desktop drive icons. The latter may be preferred with the addition of a bottom launcher for rox to open to the home partition: by creating a new desktop file in /usr/share/applications whose executable is “rox /mnt/home”. In the screenshot, such a launcher (the house) appears on the left panel.
Actually, now that I’m thinking about it radar’s cycle mode together with Openbox nicely deals with two other related problems: limited screen area and overlapping applications. Xvkbd keyboard can be set to “always be on top” and other applications set to “always be on the bottom.” It doesn’t matter if applications other than xvkbd keyboard overlap. Cycle would not only provide focus, but bring the desired target application “to the top” albeit below xvkbd’s keyboard.
I only wish there was some way to set “always be on...” at an applications initial opening.

mikesLr

* I could not take the screenshot just using radar because, in cycle mode, only selection of a target application is permitted which, when accomplished, takes radar out of cycle mode terminating the display of the cycle mode panel. mtpaint snapshot, however, can be used under radar's "move cursor then click" mode.
** raring 3.9.9.1 can be used "as is" but it currently has a resize Savefile problem. There's a work-around, see discussion starting here, http://murga-linux.com/puppy/viewtopic.php?p=718454#718454, and the next version will --in all likelyhood-- eliminate it.

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