I need to launch another program from my code but I also need to set its screen position?
Is this possible using QT?
Very simple In principal but as usual extremely difficult in QT...
If the program you are calling allows it through the command line arguments then it is definitely possible.
in windows there is the option of providing the STARTUPINFO but that only works if the program uses CW_USEDEFAULT for its location
Otherwise you would need to use a debugger to hook into the relevant setLocation call and change the arguments, this is very hard without intimate knowledge of the program in question.
This can be done by setting the dwX and dwY varibles In the STARTUPINFO struct and then setting dwFlags to STARTF_USEPOSITION.
Then call CreateProcess
Related
I want to use Qt's QWindow::fromWinID function to draw widgets onto an external window (hopefully this will work).
Unfortunately, I need to draw on a window which has a certain name/class (I can show it using xwininfo and xprop). The only code I can find to do this is inside the source of xwininfo and xprop, but it seems like a bunch of unnecessary code to do a simple thing: find the window with a certain property equal to some string, and return its window ID for Qt to use. Unfortunately, I'm very badly versed in XCB, and wouldn't know how to start.
How can I do this without 200 lines of code?
The only code I can find to do this is inside the source of xwininfo and xprop
Which really is a great resource, alongside with xdotool.
find the window with a certain property equal to some string
Yeah, but there's no X11 built-in that does this, which is why those tools go that way. Then there's things to consider like reparenting and non-reparenting window managers, i.e., whether or not you need to descend into the client window and so on.
I'm afraid there's no much easier way. Low-level X programming, whether with Xlib or XCB, just brings some verbosity.
One thing you could consider is using the library extracted from (and used by) xdotool, called libxdo. It would offer this functionality for you in xdo_search_windows. The library uses (and therefore pulls in) Xlib rather than XCB, though.
Here's a sample program you can compile with gcc -lxdo test.c:
#include <xdo.h>
int main() {
xdo_t *xdo = xdo_new(NULL);
xdo_enter_text_window(xdo, CURRENTWINDOW, "A", 0);
return 0;
}
RGTK2 block user input while processing its explain how to block user input using RGTK2 but I dont know how to add that code to my GUI code, im using tcltk. What I want same like in RGTK2 block user input while processing but using tcltk2
I use this code to run button "filter cluster" and the command function is filter (function to do something)
tkpack(tkbutton(f4, text='Filter Cluster', command=filter), side='left',padx= 5, pady = 20)
In tcltk, you would use tkgrab.set on a non-responsive window and tkfocus on a window that has a binding on the <Key> event that prevents further processing. An inconspicuous tkframe is great for that sort of thing — set it to size 1×1, but ensure it is on the screen — as it has no default behaviour to get in the way. (You'll also want to make a bunch of cosmetic changes, such as marking the widgets as disabled and setting the cursor to watch.) In 8.6, there's tk busy (call with tcl("tk","busy",…) since the Tcl tk command appears to not have a convenient mapping) which makes this all much easier (though I don't know if/how that's mapped into R). The simplest way to release a grabbed window is to destroy it, but you can also tkgrab.release.
Do not use a global grab. They're easy to get wrong and can cause you a lot of grief. (If you insist, you're strongly recommended to make mouse activity cancel it and to test very thoroughly. Locking up your display is not a pleasant experience!) The default local grabs are less of a problem, since you can switch to another program and kill off a stuck app if necessary.
The full documentation for Tk (and Tcl) is online; pick the version of the docs for the version of the library that you're using, probably 8.5, hopefully 8.6 ('cos it has some nice extras) and possibly 8.4 (old skool!) As the R documentation for tcltk says, you can invoke anything in Tcl or Tk through tcl(…), passing in the words of the command name and arguments as many strings… (Tcl is a naturally var-args language and uses that extensively.) The limited scope of the default convenience mapping should not hinder you substantively.
General advice, not so closely related to your question
Most Tk programmers try to write their code to not lock users out that way if possible. You get a better user experience if you can keep the GUI responsive and instead just temporarily disable (via the state option on most reactive widgets) the parts that would otherwise trigger reentrancy problems for the duration. (The long-running processing might be also event-driven, or put in another thread, or even delegated to a sub-process. Just remember, Tk GUIs are strictly single threaded — the implementation assumes this very deeply, though it's possible to have wholly independent apps in different threads, if rather hairy to get working right — so you've got to come back to the GUI thread to update anything in the GUI.)
I am using QT under windows and have an application where I want to use the arguments to determine if this comes from a bat file and so all data is in the arguments, or if it should pop us the menu window to allow the user to input the data.
Any examples of how to do this?
Thanks
Simply don't create or show the QMainWindow
There are a few extra complexities about event loops and signals/slots. There is also an issue on Windows that whether the create a console or not is a linker not a runtime option.
See How do I create a simple Qt console application in C++?
I think you want to check if your application is lauched with command line argument or not. If not then display some dialogbox to get input.
main function of c++ program has two argument, first is the number of arguments and other is an argument array. you can use these two parameters to decide it you got the command line parameter the from user or not.
My scenario here is the following: I am using a pyqt widget to display a solid color fullscreen on a second display and observe this display with a camera that is continuously capturing images. I do some processing with the images and this is the data I am interested in. This works great when used interactively with ipython and matplotlib using the qt4agg backend like so
% ipython -pylab
# ... import PatternDisplay, starting camera
pd = PatternDisplay(); pd.show(); pd.showColor(r=255,g=255,b=255)
imshow(cam.current_image)
I need a similar behavior now in a console script though: it should display the PatternDisplay widget, capture an image, than change the color on the PatternDisplay and take a new image and so on.
The problem is now that the PatternDisplay is never updated/redrawn in my script, likely because PyQt never gets a chance to run it's event queue. I had no luck trying to move the linear worker part of my script into a QThread because I cannot communicate with the PatternDisplay Widget from another Thread any longer. I tried to replicate the implementation of ipython/matplotlib, but I didn't fully understand it, it is quite complicated - it avoids running the QApplication main loop via monkey patching and somehow moves QT into it's own thread. It then checks periodically using a QTimer if a new command was entered by the user.
Isn't there an easy way to achieve what I want to do? I am gladly providing more information if needed. Thanks for any help!
What you need is easier than IPython's job - IPython makes the Qt application and the command line interactive at the same time.
I think the way to do it in Qt is to use a timer which fires at regular intervals, and connect the signal to the 'slot' representing your function that gets the new image and puts it in the widget. So you're pulling it in from the event loop, rather than trying to push it.
I've not used Qt much, so I can't give specifics, but the more I think about it, the more I think that's the right way to do it.
I solved the same problem (i.e. interactive ipython console in terminal, and GUI thread running independently) in the following way with ipython 0.10 (code here)
1. Construct QApplication object, but don't enter its event loop explicitly
2. Run the embedded IPython instance
3. Run the UI code you need by instantiating your window and calling show() on it (like here with the yade.qt.Controller(), which I aliased to F12. (I did not find a way how to ask the embedded shell to run a command at the start of the session, as if the user had typed it)
(You can also show() your window first, then run the embedded ipython. It will provide event loop for Qt.)
(BTW I also tried running Qt4 from a background thread (using both python threads module, and Qt4.QThreads), but it refuses to run in such way stubbornly. Don't bother going that way.)
The disadvantage is that UI will be blocked while ipython is busy. I hope to finding something better for 0.11, which should have much better threading facilities (I asked on ipython-users about how to unblock the UI).
HTH, v.
I am writing my own shell as part of course assignment. So I need to support background jobs. I am maintaining data strutures for job id and background jobs. But I need to also tell the kernel that this is a background process, so that there is only one terminal foreground process. Until now I am handling background jobs at my program level.
What is the function call to register a background process?
If you want a process to not be part of the terminal's controlling group, the simplest method is to simply give it a different group.
switch (fork()) {
case 0:
setpgid(getpid(), getpid());
execvp(...);
Sorry, misread your question. You need to use thetcsetpgrpfunction.
Read this section in the GNU C Library Manual for details:
http://www.gnu.org/s/libc/manual/html_node/Job-Control.html
On Linux look at the daemon function:
int daemon(int nochdir, int noclose);
If the daemon function doesn't exist on the system you're using you need to use setsid and fork instead.