If there's any way to simulate a real mouse click (press + release) at the absolute position of current desktop with PyQt, without other extenal library like PyUserInput?
I search around and just found this and this. But If I don't misunderstand, they seem to send their click event to Qt application it self, instead of the desktop?
Use PyQt's QTest, together with unittest or such. See also for example http://www.voom.net/pyqt-qtest-example.
If this is not for unit testing, look at sendEvent and postEvent (See http://doc.qt.digia.com/qq/qq11-events.html#syntheticevents). There are some limitations to Qt's mechanism for generating "artificial" events but based on what you describe, it is likely to work. If you have tried those and it doesn't work, please post the code you tried.
Related
I come from Unity, and there you can use ContextMenu method attribute. It will add a button in the editor you can click and the method in your script will be invoked.
This is very helpful for testing/debugging purposes. When you are testing a functionality and you want an easy way to trigger it.
Is there something similar in Godot, or any workaround I can use?
(Godot 3.5 here)
There are multiple ways to run code in the editor.
In fact, Godot games and the Godot editor are built on the same core. One way to say is that Godot is build on Godot… But a more accurate way to say it is that your games are Godot without the editor, plus whatever you built on top.
As a consequence, you have a lot of freedom when extending the Godot editor.
For starters you will be making a tool script. To do that you the tool keyword on the top of the script file. This allows the script to run in the editor.
Warning: Remember that in Godot the Game is not running inside the Editor. Anything that your script moves while running in the Editor would be a modification to the project, for good or ill. And it does not come with build-in undo functionality. It is possible to add undo functionality (with the UndoRedo class), but that is also something you would have to program.
By the way, you might want to know if your code is running on the editor or not. For that, you can check Engine.editor_hint which will be true in the editor.
Read more on the article Running code in the editor.
Since the tool script modify the project. What I present below is more often used to setup parts of the scene or to automate parts of the development workflow. Not for testing features. However since the linked documentation about ContextMenu mentions that it is useful for…
automatically setting up Scene data from the script
I believe what present below is not out of place.
With that said, some modifications of the editor are harder than others. I believe you don't really want to go into the trouble of adding a button to the editor (which is perfectly possible) or an option to the menus (which is also possible, but not everywhere, at least not easily). Instead, I'll stay with the easy options for this answer:
You can make an EditorScript. That is a script that extends the EditorScript class and overrides the _run method. For example:
tool
extends EditorScript
func _run():
print("Hello from the Godot Editor!")
To execute it, have it open in the Script Editor, and to the File menu, and select Run. You can also use secondary click on the script on the "Scripts Panel (on the left of the Script Editor) and select Run in the contextual menu.
The drawback is that is script does not work in the game. It is only for the editor.
Although Godot 3.x does not have official (there is a plugin) support for inspector actions (it might land in Godot 4), we can workaround that. What we will do is export a bool property, and handle (with a setter, which we specify with setget) what happens when you set it. Like this:
tool
extends Node # or whatever
export var do_something:bool setget on_do_something
func on_do_something(_mod_value:bool) -> void:
# do whatever you want
pass
The property should show up as a checkbox in the Inspector panel when the node is selected. And clicking the checkbox will trigger the setter method on_do_something… Which will do whatever you want it to do. Notice also that I'm discarding the value that Godot is trying to set to the property (_mod_value) so it will remain false.
This pattern has got popularity among Godot developers.
If you want to add elements to the Godot UI you would have to make an EditorPlugin (see the Editor Plugins section in the documentation).
Alright but, since the tool script could cause modifications to the project, which might be a problem for testing… What do we do for testing?
Well, I will remind you that you can tell Godot to execute specific scenes (it does not have to run the main scene), and that can another way to test your code.
Furthermore, when your game is running you can go to the Scene panel and select the Remote tab to see the Nodes that exist in the game. Which will allow you to select them, which shows their properties in the Inspector, which would be able to modify (having an effect in real time on the executing game).
… And thus something similar to what I described above about using a setter would work. Except it does not need the tool keyword since it won't be running in the editor:
# No tool
extends Node # or whatever
export var do_something:bool setget on_do_something
func on_do_something(_mod_value:bool) -> void:
# do whatever you want
pass
By the way, in the inspector, when the game is executing and you have the relevant Node selected, you will see your property twice. The first one will trigger the setter, while the second one bypasses it. So pay attention which one you are using.
You might also be interested in the "Project Camera Override" feature, which allows you to freely move the game camera from the editor. You access the feature via the top bar in the editor.
You will also find that it is possible to modify Resources in the editor and see the effect in real time while the game is running. And a Script is a Resource… However pause the game from the Debugger panel (or use a breakpoint) and make sure the script you want to modify is not being executed before you modify it.
Ok. had enough of trying out lightboxes, overlays and dialog boxes plugins. The problem is that very few of them support nested (multiple) dialog open at the same time - a typical requirement in my opinion.
I'm looking for a recommendation for a simple plugin that:
supports callsbacks for the usual onShow/onLoad... events
supports nested instances i.e. the user open a dialog, clicks a button on it, another dialog opens up while keeping the first one open in the background. In other words, it should support the closure of each instance programatically
is NOT the jquery ui dialog plugin
This came about after the big disappointment with SimpleModal's inability to support multiple modal boxes open simultaneously!!!! #EricM, why would you do that to me? why???? ;)
I have narrowed it down to jqModal and the jquery tools overlay. The usage of the latter is weird. Maybe i'm tired but i just don't get it.
So before i dive into jqModal, does anyone have any recommendation based on personal experience that will achieve what I'm trying to do?
thanks
I'm working on a I/O verification tool based on Linux in a game project. It is written in C++, and,since using the same I/O module as our game, it's based on OIS 1.2. Thus, though all I need is to print users' inputs on the console, I still need to create a window for OIS.
So here comes my question: How can I create a mapped window while it is still invisible and processes keyboard events?
I can't unmapped the window in that it won't process any keyboard event anymore. I also can't find function for show/hide a window.(maybe I search through a wrong diretion...)
My little tool works fine now except there is a stupid top-level empty window which needs to be focused for processing keyboard events...
Any advise is welcomed.
Thanks!!!
After reading this post: Linux/X11 input library without creating a window,
I realized my problem was that I misunderstood the philosophy of X11. All I need to do is simply pass the root window handle to OIS, and set the x11_grabkeyboard flag as true. The only drawback is maybe I can hardly debug my program with gdb since the keyboard is grabbed...
Though my situation is solved, there is one thing left.
Every article I read said an InputOnly window won't be visible and is capable for handling input events, while my InputOnly window is absolutely visible after mapped...
Maybe it's my Linux, or again, a misunderstanding...
I am working on old Motif-based application for Linux. I want to be able to programmatically change the active window of our application. I can redirect the input by using XSetInputFocus() function and the keyboard input start to go there, but XReconfigureWMWindow() and XRaiseWindow() functions just don't work.
I've read that Window Managers try to stop this behaviour, so tried to disable configure redirection, but this doesn't work either. Any ideas how to make one of my own windows on top of the window stack?
There is a tiny program called wmctrl available (at least in Debian/Ubuntu it is in standard distribution) which is able to perform many operations on windows and desktops, and handles plenty of window managers. I'd suggest testing whether it works in your environment, and if so, peeking at its sources.
You may find the answer to this is dependent on the Window Manager the user is using, or even what settings they've given to the Window Manager. I like to set my Window Managers to do "focus follows mouse", which means you can't send the focus to a window that I haven't put my mouse on, unless you also warp the mouse there (is that function called XWarpMouse?).
We've got some in-house applications built in MFC, with OpenGL drawing routines. They all use the same code to draw on the screen and either print the screen or save it to a JPEG file. Everything's been working fine in Windows XP, and I need to find a way to make them work on Vista.
In three of our applications, everything works. In the remaining one, I can get the window border, title bar, menus, and task bar, but the interior never shows up. As I said, these applications use the exact same code to write to the screen and capture the window image, and the only difference I see that looks like it might be relevant is that the problem application uses the MFC multiple document interface, while the ones that work use the single document interface.
Either the answer isn't on the net, or I'm worse at Googling than I thought. I asked on the MSDN forums, and the only practical suggestion I got was to use GDI+ rather than GDI, and that did nothing different. I have tried different things with every part of the code that captures and prints or save, given a pointer to the window, so apparently it's a matter of the window itself. I haven't rebuilt the offending application using SDI yet, and I really don't have any other ideas.
Has anybody seen anything like this?
What I've got is four applications. They use a lot of common code, and share the actual .h and .cpp files, so I know the drawing and screen capture code is identical.
There is a WindowtoDIB() routine that takes a *pWnd, and a source rectangle and destination size. It looks like very slightly adapted Microsoft code, and I've found other functions in this file on the Microsoft website. Of my four applications, three handle this just fine, but one doesn't. The most obvious difference is that the problem one is MDI.
It looks to me like the *pWnd is the problem. I'm not a MFC guru by a long shot, and it seems to me that the problem may be that we've got one window setup in the SDIs, and more than one in the MDI. I may be passing the wrong *pWnd to the function.
In the meantime, it has started working properly on the 64-bit Vista test machine, although it still doesn't work on the 32-bit Vista machine. I have no idea why. I haven't changed anything since the last tests, and I didn't think anybody else had. (On the 32-bit version, the Print Screen key works as expected, but it does not save the screen as a JPEG.)
Your question title mentions screen capture but your actual question doesn't. Please elaborate more clearly. Is the problem that you can do screen capture of three of your applications, but not the fourth one? You can use different screen capture software that can capture OpenGL/DirectX windows. Those surfaces are handled directly by the Window Manager and won't show up with a simple 'PrtScn'.
Switching to GDI+ won't solve it, nor will switching to SDI.
If it's the content of the CView that you want, then yes, that should be right one. If it's the content of the whole screen (at least the content, without the toolbar(s) and status bar), then you should pass it the CMainFrame (that's the default name which may have been changed, the one that is derived from CMDIFrameWnd).
Can you post the code of WindowToDIB()? I've just tried it and It Works For Me (TM), but without OpenGL code in the view. Try passing the following windows to your WindowToDIB() function:
CMainFrame* mainfrm = static_cast<CMainFrame*>(::AfxGetMainWnd());
- mainfrm
- mainfrm->MDIGetActive()
- mainfrm->MDIGetActive()->GetActiveView()
and see what you get.
The contents of each window are directX surfaces and are only assembled by the window manager in the graphics card. You'd not be able to capture this unless you switch off the new interface (DWM) or code specifically for screen capture from the DWM.
Wikipedia has a good description of the Desktop Window Manager (DWM)
Sorry, I still don't understand. You're trying to get the Print Screen key to work on all four applications? Or you're trying to get the WindowtoDIB() function to work, which takes a 'screenshot' (from within your own application) of the application itself, so that it can be saved as an image file?
Also, what do you mean with 'he Print Screen key works as expected, but it does not save the screen as a JPEG.'? Print Screen only copies to the clipboard, what happens when you paste in Paint?
If your WindowtoDIB() function only 'captures' the window you pass to it, then yes, your MDI child windows are not going to show up.
We eventually solved this by creating a different OpenGL context, and drawing everything to that. We gave up on the screen capture.