Messages

1

Window / Re: How to set X11 _NET_WM_PID property ?

« on: July 04, 2015, 12:32:10 am »

Thanks, but i'm not sure how the system handle will help me. I think I have this figured out, which is to query the xwindow system by the _NET_WM_NAME property, instead of the PID property. Thank you both for trying to help me with this

2

Window / Re: How to set X11 _NET_WM_PID property ?

« on: July 03, 2015, 11:12:35 pm »

I'm trying to embed an sfml window into a qt5 window. I saw the howto about converting an sfml window into a QT widget, but this will NOT work, because my sfml window creates an opengl context and uses glew to make openGL calls. this basically means you cannot embed the window in QT, as qt has its own openGL subsystem that is NOT compatible with glew. My only hope is to spawn the sfml window into its own process and capture it (using its window ID) and embed it into a widget. The problem is, how do you get the windowID from the PID ? one of the ways if the window sets the _NET_WM_PID property (there was an example on stackoverflow), and this works , but apparently SFML doesn't set the property.

3

Window / How to set X11 _NET_WM_PID property ? [ SOLVED ]

« on: July 03, 2015, 10:37:15 pm »

I need to be able to get the window ID from the PID, and I read that there is a standard X11 property called _NET_WM_PID that windows should set. Does SFML set this property, and if not, is there a way to set it manually ?


EDIT: Solved. I compromised and instead of searching by PID, I search by window name. From the windows name I get its window-ID and can successfully embed it into my QT application. if anyone wants to see the code that does this, you can find it here:

https://gist.github.com/anonymous/6df3c14250833ed40484

warning, it says atomPID but this has nothing to do with pid, it searches for windows by name.

4

Window / Re: Polling events after attaching to existing window

« on: April 19, 2015, 04:09:50 am »

sure. I am using the Model/View/Controller design pattern. Controller passes control commands to Model and View. The reason it can talk directly to View is to control the camera in the GL scene. It talks to Model to create and update objects. On any given update, the vertices are passed to View to update the draw.

Currently, I have Controller create a tiny SFML window from which I move the mouse and type to issue Control commands. I realize it looks dirty and it's annoying to have to click in one window and see the result on another window. The reason I can't just move the window event handling to View is because of Modeler. It would be acceptable if I *only* needed to read mouse events to control the camera, but the keyboard events control the objects, so they have to be sent to Modeler.

Since I'm doing 3D, frame rates matter. So I don't want to fiddle with the View to make it now send messages back the other way to Model. I'd rather just have Controller come up as a separate (headless) process, attach to the existing SFML window, read its events, and continue the way it already works.

I feel like this could be a bug in SFML. I'm running Linux Mint 17 with SFML-dev v2.1+dfsg-4ubuntu2.

This link http://www.sfml-dev.org/tutorials/2.0/window-window.php says

"In this case, SFML will create a drawing context inside the given window and catch all its events without interfering with the parent window management."

However, later on it says "the event loop (more precisely, the pollEvent or waitEvent function) must be called in the same thread that created the window"

Can you help reconcile these two statements or confirm whether this is a bug or not ? I get the sf::Window to correctly attach to the window handle, and I get to read some events, but not all events, such as the scroll wheel or mouse click. but mouseMove *does* work. This seems like a bug.

Thanks

5

Window / Re: Polling events after attaching to existing window

« on: April 19, 2015, 03:37:56 am »

I forgot to specify: they are both sfml windows. I want a completely separate process , which currently reads in mouse and keyboard events from its own SFML window to instead attach to the SFML of another window, via its window handle. The attachement works, but now I'm only getting a subset of the possible window events.

6

Window / Polling events after attaching to existing window

« on: April 19, 2015, 12:39:02 am »

Hi, I am kind of asking for confirmation about the documentation that says "Events must be polled in the window's thread".

I have an open GL render window, but for various reasons, I'm not binding to it for window events such as mouse and keyboard. I got annoyed at having a separate window that I have to click and type into, so I looked into sfml's ability to attach to existing windows. I got the window handle correctly, I attach to it, but now it only halfway works for polling events. It reads keyboard events fine, and it reads *one* mouse event , MouseMoved, but not all the other mouse events, such as mouseButton press/release, etc. I looked at the documentation and found that discouraging bit about how events must be polled in the thread that created the window. But I wanted to ask here for confirmation because this is kind of a gray area. I "created" an SFML window, just from a handle instead of from scratch. I confirmed that the window I'm binding to does not already poll for any events. It just creates a GL context and calls display on it.

Can anyone shed some light on this, basically just confirm I can't expect things to work this way ? Thanks.

Mary