I'm writing a c++ application that creates a GTK3 window at some point, while also running X11 code in other places.
For the pure X11 part i'm using XOpenDisplay() to open a display.
Running the X11 part and opening a GTK window afterwards works fine. Also running the X11 part multiple times is no problem as i release the display there using XCloseDisplay.
The problem i'm facing occurs when i try to run the X11 code after gtk has been initialized (to be more specific, calling XOpenDisplay() after the gtk initialization).
I'm suspecting that after running gtk_init() the display is never being released, even after gtk_main_quit().
I didn't find anything about deinitialization in the gtk3 documentation. Is there any way to propperly deinitialize gtk or free the display in another way?
The solution was completely unrelated. I was setting the DISPLAY environment variable twice by accident. Apparently gtk can handle this but XOpenDisplay crashes.
I have added a test to only set it once, now everything works. Perhaps gtk does propperly deinitialize after gtk_main_quit()
Related
So I have a program where I'm doing some processing with the OpenCV library and then show the results in a Qt made gui (on a widget). The thing is if i wanted to 'debug' the opencv implementation inside the gui, ie do a imshow of some frames/mask, it creates the window but doesn't refresh it except sporadically.
Trying to add a waitKey(1) to force a refresh just freezes the gui so its another dead end.
Any idea on how to fix this? If its needed I'll try to do a MWE but with the state of my program is a bit difficult to extract the functionality.
Thanks in advance.
Well seems that doing a
QApplication::ProcessEvents()
forces the image to update, albeit really slow, but for debugging purposes it will suffice.
I just have a simple question, with a Windows Runtime Component (as in a library) that I am making how do I get the window object for the app? CoreWindow::GetForCurrentThread() throws an exception as it seems that the library runs in a different thread then the app. Any one know how to get the app window?
EDIT: GetForCurrentThread is not the problem, it seems that that it only works on the UI thread not a background thread, I would like a way to get at it from a background thread. Is it possible?
I think Window.Current is what you are looking for.
Using mixed managed/unmanaged C++ (Visual Studio 2008) I'm opening a windows form child window from a DirectX application. Weird stuff indeed, but it works, mostly. If I use showDialog() the child window works perfectly, but obviously the main app stops running (until the child is closed). If I use show() life is good, but the child has subtle issues. A textbox works and accepts input for example, but you can no longer use the Tab key to move to different controls. Mnemonics (Alt+hotkey) have stopped working as well.
I'm a huge keyboard shortcut fan, so this is very annoying. To make it worse, I'm not even sure how to Google this issue. Any help would be greatly appreciated.
To resolve the tabbing problem either use a separate thread to create the dialog and call showDialog(), or call IsDialogMessage in your main message loop.
I'm using Ubuntu 12.04 here and developing an SDL1.2 app in c++. What I would like to achieve is that the user could open like a "Preferences" window or something from the "Main" window (both window should have a titlebar etc). I'd also like to have this program be able to run cross-platform, and SDL2 is not an option, either.
Is this achievable in any way? What I could think of so far is writing another SDL program that will be called from inside the 'main' program, but that would include some system() calls, and anyways, it's not the best solution IMO.
SDL only supports a single window. If you upgrade to SDL2, it supports multiple windows, though you can't put one window inside of another window.
If you want this functionality without upgrading, you'll have to render the window-in-a-window yourself.
still relatively new to Qt (and to stackoverflow as well) but succeeded over the last weeks to replace our old obsolete-when-new GUI code with Qt and improve several things along the way as well. Now however I am running into a problem I so far have not been able to google my way out of.
Some background:
Application has an opengl main window which is created outside Qt (most of this application is completely outside Qt), Qt windows are only used for (development) subfunctionality, just GUI.
I am calling processEvents() from the main loop each frame.
Using locally built Qt 4.7.4 on both platforms.
Everything works fine on linux. The Qt windows behave properly and I can interact with the application/simulation in the main opengl window through mouse and keyboard just as was always possible.
However, when I applied the same changes to incorporate Qt on windows the mouse no longer works in the main window. Keyboard does, but our mouse code never seems to get any WM_INPUT events. When I disable calling processEvents() the mouse works fine again. (but then obviously the Qt windows won’t work properly)
It seems Qt is catching mouse events intended for the main window and throwing them away/forgetting them instead of delivering them to the main window.
Unfortunately I haven’t found anything that points to this being a common occurrence (with a common simple solution).
I did find http://qt-project.org/forums/viewthread/502 referencing an issue with mouse events but the resolution mentioned there of compiling Qt with _WIN32_WINNT=0×501 defined does not make any difference.
Any insights would be highly appreciated!