So here's my problem. I've looked at pyautogui, and pywinauto so far. In terms of what I would like to do, I would like to simulate mouse and keyboard inputs to a non-active window that the user is currently not using, and not actually interrupt what the user is doing. In pyautogui, it forces actual mouse movement which makes it impossible for me to do other tasks while such a script is running.
Related
On an embedded system, due to very specific hardware/software limitations, we need another program to be able to display info via the framebuffer (/dev/fb0), while keeping our Qt5/QML program running in the background. We display a custom QQuickItem derived black rectangle (with nothing but a 'return' in the update()) in QML while the second program runs, but we still see flickering on our LCD display. We surmise that QT is still painting the Screen Graph (possibly of other items layered beneath the rectangle) to /dev/fb0, thus causing flickering by both programs writing to /dev/fb0 at the same time.We cannot use a second framebuffer approach (/dev/fb1) because the compositing increases processor loads dramatically such that the system becomes unusable. One thought is iterate through screen graph tree, marking all nodes 'ItemHasContents' flag as false so the screen graph renderer will not write to FB, then re-enable when the secondary program finishes its task. Another thought is to turn off rendering via the top level QWindow, but nothing in the documentation says this is even possible... Is this possible via QT, or even though a shell script?
/dev/fb0 sounds like you'd be working on a Linux-based system.
You're not saying whether you need the Qt application really continuing to run, just without screen updates, or whether simply "freezing" it while your other app uses the frame buffer would suffice.
If you are fine with the latter, the easiest solution to stop the Qt app from rendering is simply send it a SIGSTOP signal, it will freeze and cease to upgrade the frame buffer. Once you're done with the fb, send a SIGCONT signal. Sometimes the simplest approaches are the best...
I would like to add a keystroke handler to my Linux system (actually Ubuntu Linux, but pointers to X11 generally will be helpful).
The goal is simple enough in principle, I have a "drawing" program that lets me write on a transparent panel. I want to have a single keystroke that toggles this from the top to the bottom (and back again) of the window stack.
I guess I need to interact with the window manager, but that's where my ideas run out. Any suggestions for research directions?
Thanks,
Toby
I am new to wxPython, so please be gentle. I am trying to make a game using wxPython. I need to be able to handle events (button clicks) while the game is in progress.
The process is:
Deal the cards
Wait for user input
Continue accordingly
The way I have implemented it is:
app = wx.App()
g = Game() # calls g.Play() which executes the process above
app.Mainloop()
However the application freezes. I think the problem relates to being unable to respond to events while the process is being executed. How can I get around this?
I had a look at threading, but cannot see how to make this work in my case. If I create a new thread to deal with user inputs from within Game(), that will not be able to update the values in Game().
I am sure there is a "correct" way of doing this which I don't know because I am unfamiliar with wxPython. Can anyone help?
Yo do not need a seperate function play() to run the game. Just set up the event handlers to compute the state of the game during every event which results in a move of the game.
A good option would be to define a game state as say the cards in each players hands, and the turns that have been played and the scores, all defined as an object of a state class.
Chalk out an outline of how your game's architecture first. And you might also want to take a look at some examples and documentations on wxPython if you are new to it.
wxPython (and all GUI toolkits) are event driven. What this means is that they all wait for the user to "do something", like press a button, move the mouse, press a key on the keyboard, etc. When the uses does one of these things, wxPython checks to see if any of those events are bound to an event handler. If they aren't, wx will usually ignore the events.
You can learn about how to bind events properly here:
http://wiki.wxpython.org/self.Bind%20vs.%20self.button.Bind
So when you start the program, it should probably deal the cards at the start or possibly prompt the user to see if they want to start a new game or possibly continue a game. After that, the application would wait for the user to "do something". If the user executes a process that takes a long period of time (like a complex calculation, downloading a large file, etc), that process should be put into a thread. If you don't put it into a thread, then that process will block the UI's main loop and your app will freeze. See the following articles for information about wxPython and threads:
http://wiki.wxpython.org/LongRunningTasks
http://www.blog.pythonlibrary.org/2010/05/22/wxpython-and-threads/
I hope these links help you on your way.
Is it possible to start a screen saver and stop the screen saver from waking up when the mouse moves or when when keys are pressed?
I want to be able to display an emergency warning full screen message on the computer (like during a fire evacuation) and so I want to lock the computer remotely, change the screen saver to a screen saver that has the message I want to display and start the screen saver when the screen is locked. I have done some research and I think I might be able to do all that but I want to make sure the message says up. I could probably have a loop and keep restarting the screen saver but if there is a way to limit what input can wake the screen saver I think that would be better.
I will only be running this on Windows 7 computers.
I searched a lot on this, but didn't found any suggestions. Maybe you can try it from another perspective:
Use Toddler Keys (with you can disable your keyboard/mouse), and use macros on it. So whenever you want to make this alarm, run a macro file on each computers that opens Toddler Keys, turns off keyboard and mouse, and runs the screen saver as a warning message. After it run another macro that kills Toddler Keys from processes.
Hope that helps
I have simple window in Tcl/Tk which on hitting OK button runs simulation. I am using Linux. The window is destroyed when the simulation finishes. The problem is window lingers on while the simulation is running. I want the window to vanish after I hit OK button.
I tried using wm withdraw .mywindow but it makes the area where the window was displayed (containing OK button) to be white.
I found update while googling but it is said to be harmful.
If you do wm withdraw .mywindow, the window won't actually vanish until the event loop is entered, because it is the event loop that handles redrawing the screen.
You have a couple of choices to solve your problem. For one, you can call update idletasks. That is a variation on update that just handles "idle" tasks such as painting the screen, but not tasks like responding to buttons and other user-generated events. So, solution one is to do:
wm withdraw .mywindow
update idletasks
run_simulation
By the way, the reason update is harmful is because it essentially starts a new event loop -- another infinite loop. If during that event loop an event comes in that causes the same code to run again, you start a third, and a fourth, and so on. As a general rule, nested infinite loops are never a good thing. Remember: tcl is single threaded so those event loops don't run in parallel.
The other solution is to enter the event loop naturally, and schedule your simulation to run once all other events have been processed. Do do this, start your simulation by using the after command. Using after will place an event in the event queue. When the event loop gets to that event your simulation will begin.
For example:
wm withdraw .mywindow
after idle run_simulation
When the above code exits -- assuming it was called as a result of an event such as pressing a button or key -- the event loop will be re-entered, any pending events will be processed, then your run_simulation command will run.
By the way -- if you have a GUI that needs to be responsive while your simulation is running, you should read Keep a GUI alive during a long calculation on the tcler's wiki. There's a lot to read there which makes the problem seem harder than it is, but it's not as complicated as it might first seem.