I can't understand the use of scroll lock.
I searched on Google, Wikipedia and used that particular technic but still I am confused.
Scroll lock is a remnant of the original IBM keyboard and its purpose was to alter the arrow key behavior when it was pressed.
Not many applications use scroll lock anymore, as we got the mouse for scrolling nowadays. Very few applications/pages/etc respect this old principle. Imagine it like num-lock key.
Here you can have all the details about it:
https://en.wikipedia.org/wiki/Scroll_lock
Related
While there is a WebAIM guideline on keyboard accessibility, I was unable to find any guidelines - or even recommendations - about how to convey the existence of custom keyboard shortcuts to sighted people.
For screen reader users like myself it is simple enough:
<input type="submit" aria-keyshortcuts="Alt+S" value="Send" />
A screen reader would then announce "Send button Alt plus S" and the keyboard shortcut would also be apparent for braille display users.
Sighted users who cannot or do not want to use the mouse, however, need a simple indicator of which keyboard shortcuts are available on a given control so that they have a similar user experience and don't have to search for lists of keyboard shortcuts in separate documentation. (Such lists are, of course, important, but they shouldn't be the only way for sighted users to know which keyboard shortcuts they can use.)
Can you provide me with resources or suggestions how to visually indicate available keyboard shortcuts?
The guidance for aria-keyshortcuts says:
Authors SHOULD provide a way to expose keyboard shortcuts so that all users may discover them, such as through the use of a tooltip.
which is essentially what you're asking about. You know you should convey the information to all users but how should that info be conveyed? A tooltip, as suggested in the spec, is one possibility but only if that tooltip is exposed for keyboard users too. Currently, a tooltip (title attribute) is only displayed upon mouse hover with Firefox and Chrome (not sure about Safari). Say what you will about Internet Explorer but IE would display the tooltip upon keyboard focus so that's a great feature. That feature was carried forward into Edge as well.
So you can use a tooltip but would still need another way to convey that information for all users. If space allows, I often see the keyboard hint as text right on the page. Ideally, the hint is near the element it applies to but if there are several shortcut keys, then having a section with all the keys listed might be a better option. Have an appropriate <h#> element for that section to make it easier to find with a screen reader.
Note that using the accesskey attribute for the shortcut key will automatically be announced by screen readers so you wouldn't need aria-keyshortcuts. But that attribute only allows a simple letter and would still have the issue of it not being conveyed to sighted keyboard users. Browsers should automatically display a tooltip for an element with an accesskey but sadly they don't.
Another alternative is suggested in this answer, How to display a specific shortcut key in HTML?. Look at the CSS solution (link should go directly to that answer) but instead of referring to accesskey in the CSS, refer to aria-keyshortcuts. (Ignore the javascript part of that answer.)
I wanted to make a software with Godot in GDScript that advice you when pressing the bloq mayus button changing the color of the taskbar icon. But, I couldn't find any special code or something that makes it.
I saw the video of Adderly Cespedes making the same software (but in gamemaker) and he said that he found a special extension for it but never said the name.
This isn't currently possible in Godot.
The engine doesn't allow you to map Caps Lock (bloq mayus) to an input.
Edit: From Calinou’s comment, OS.request_attention() can be used to flash the taskbar.
import pywinauto
from pywinauto.application import Application
PATH = 'c:/Users/User/PycharmProjects/InviterChannel/Telegram/Telegram.exe'
app = Application().start(PATH)
app.Telegram.ClickInput(coords=(330, 530)) # This is what the user should not see
Is it possible to hide the window while continuing to click in it?
How to do it?
The task is to hide from the user what the algorithm does (keyboard input, mouse clicks, etc.)
Both .click_input() and .type_keys() methods require active window.
There is only workaround for keyboard input that is sometimes possible for minimized window (after app.Telegram.minimize()):
.send_keys() and .send_keystrokes() (the difference may appear for some special keys that may work or may not).
I haven't heard about similar possibilities for mouse actions. Maybe app.Telegram.move_window(x=-1000, y=-1000) would help. The window will have negative coordinates. It will be in focus, but invisible to user. So usual .click_input() and .type_keys() should work, but these actions may bother a user. So you'll have to remember mouse cursor (by win32api.GetCursorPos()) and get it back by win32api.SetCursorPos(...) quickly. Also need to switch focus back to previous active window.
P.S. I'm in doubt moving Telegram window would work, because it's not movable by hands as far as I remember. They made some defense against this probably. :)
I love the mod4 + mouse-drag combo for moving/resizing windows in Awesome WM, it's very intuitive with regular mouse. Now that I'm using Awesome WM on my laptop, however, I find this combo more annoying when using the touchpad vs regular mouse.
The problem stems from the fact that I now need 3 fingers to perform a gesture that I could do with 2 before (1 to move on the touchpad, 1 to keep on the left-click at all times, and one on mod4). Alternatively, I can apply more force to the touchpad and have it pressed as I drag my finger, which is not any better since it puts a lot of stress on the finger doing the dragging).
What I would like to do instead is have awesome treat left-mouse button as pressed if both of the following conditions are met:
mod4 is pressed
movement event is coming from touchpad and not regular mouse
To do so, however, I need to be able to detect that the movement is coming from the touchpad. Is there a way to do so in Awesome WM/Linux? I've looked through the keysyms (http://wiki.linuxquestions.org/wiki/List_of_keysyms) but don't see anything for the mouse. I've also looked at the mouse.lua file in Awesome WM but it doesn't seem to have anything to differentiate between the two either (https://github.com/awesomeWM/awesome/blob/master/lib/awful/mouse/init.lua). If there is a way to tell that the last coordinate change came from a touchpad on Linux that would resolve the issue as I could simply create a lua file to run such check whenever Mod4 is pressed.
To do so, however, I need to be able to detect that the movement is coming from the touchpad. Is there a way to do so in Awesome WM/Linux?
Nope, there is no such way in AwesomeWM. Sorry.
In X11, this is possible via the input extension. However, awesome does not use that extension.
I'd like to write a Linux screen magnifier that's customized to my liking. Ideally, the magnified window would be a square about 150 pixels wide that follows the mouse cursor wherever it goes.
Is it possible to do this in X11? Would it be easier to have an application window that follows the mouse around, or would it be better (or possible) to forget about the window altogether and just make the mouse pointer a 150x150 square that magnifies whatever's underneath?
Look at the source to xeyes?
This actually already exists, it's called Xmag (do a Google search for additional info). You might want to check out the source code for it if you want to know how it works.
EDIT: looks like I misread your question a little bit... if you want a magnified square to follow the mouse pointer around, I suppose it should be possible, but I don't know the technical details of how you'd do it. Regardless, the place to start is probably by looking at Xmag as a starting point.
I am unsure if this can run as its own app or would have to be integrated into your window manager. Either way, you would need libx11 (might have a different name from distro to distro). Also, I would suggest taking a look at swarp. I know this is not even close to what you are talking about, but the source code is only 35 lines and it shows what can be done with libx11.
I would personally make that a frameless window that always stays atop with a 1px hole in the middle. The events that the user makes (Mouse clicks, keypresses, whatever) is passed to the window below.
And when the user moves it's cursor it is ought to be visible to your window and you just move it over a bit. For the magnifying part, well - that is left as an exercise to the reader (Because I do not know how to do that as of yet ;-).
Texworks comes with such a feature to inspect the pdf resulting from typesetting a latex source. You can also choose between a square or a circular magnifier. See https://www.tug.org/texworks/ for access to the code which can serve a launchpad.