GLFW for window/input management

LancePutnam commented 11 years ago

As of version 3.0.1, GLFW (http://www.glfw.org/) supports multiple windows. Support for multiple windows was the main reason we stuck with GLUT for so long, putting up with its many annoyances and limitations. However, now I no longer see any strong arguments for using GLUT as GLFW does everything it can plus more and is actively maintained.

It also seems that GLFW plans to add touch support in the future. From its 'touch' branch on github:

/*! @brief The function signature for touch callbacks.

@param[in] window The window that received the event.
@param[in] touch The touch that triggered the event.
@param[in] action One of @ref GLFW_PRESS, @c GLFW_MOVE or @ref GLFW_RELEASE.
@param[in] xpos The new x-coordinate of the touch.
@param[in] ypos The new y-coordinate of the touch.
@ingroup input *
@sa glfwSetTouchCallback / typedef void ( GLFWtouchfun)(GLFWwindow*,int,int,double,double);

grrrwaaa commented 11 years ago

Yes, GLFW 3 looks rather attractive.

Something to watch out for: last week I was trying to use GLFW 2.7 (what's in apt-get / brew) in the allosphere and found that fullscreen windows on ubuntu could not span more than one projector. I fiddled with it for a while and couldn't get it to work, and through googling it appeared to be a limitation of GLFW's X window handling. It would be wise to check of GLFW 3.0 resolves this. (Using multiple windows is a possible fallback, but an annoying one, as it requires multiple or shared GL contexts).

On Aug 23, 2013, at 5:25 AM, Lance Putnam notifications@github.com wrote:

As of version 3.0.1, GLFW (http://www.glfw.org/) supports multiple windows. Support for multiple windows was the main reason we stuck with GLUT for so long, putting up with its many annoyances and limitations. However, now I no longer see any strong arguments for using GLUT as GLFW does everything it can plus more and is actively maintained.

It also seems that GLFW plans to add touch support in the future. From its 'touch' branch on github:

/*! @brief The function signature for touch callbacks.

• @param[in] window The window that received the event. • @param[in] touch The touch that triggered the event. • @param[in] action One of @ref GLFW_PRESS, @c GLFW_MOVE or @ref GLFW_RELEASE. • @param[in] xpos The new x-coordinate of the touch. • @param[in] ypos The new y-coordinate of the touch. • @ingroup input • @sa glfwSetTouchCallback / typedef void ( GLFWtouchfun)(GLFWwindow,int,int,double,double); — Reply to this email directly or view it on GitHub.

donghaoren commented 9 years ago

Recently found that the most recent version of GLFW seems to have resolved this. Here is the code I experimented with:

width = WIDTH_OF_COMBINED_DESKTOP;
height = HEIGHT_OF_COMBINED_DESKTOP;
glfwWindowHint(GLFW_STEREO, GL_TRUE);
glfwWindowHint(GLFW_DECORATED, GL_FALSE);
glfwCreateWindow(width, height, title, NULL, NULL);

width and height can be determined by glfwGetVideoMode. It will give you the x, y, w, h for each monitor in the combined desktop coordinates, from which you can compute the size of the combined desktop.

mantaraya36 commented 8 years ago

This is actively being worked on by Kee in the glfw branch:

https://github.com/AlloSphere-Research-Group/AlloSystem/tree/glfw

younkhg commented 8 years ago

Hello, sorry for late response. I was on a long flight...

The glfw branch contains what I've done as a final project for Andres' class this quarter. The main goal of it was to get newer version of OpenGL run in al_Window class, and it's very simple for now with very messy parts of code. Currently there's still lot to fix and improve, and I talked about future plans on this branch with Andres. I was planning to work more on it during this winter break.

Any recommendations and/or suggestions will be really helpful. There's a lot to discuss.

LancePutnam commented 8 years ago

Is the plan here to replace GLUT? If so, there might be one snag on Linux---APT still only has version 2.7.2:

$ apt-cache show libglfw-dev Package: libglfw-dev Priority: optional Section: universe/libdevel Installed-Size: 199 Maintainer: Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com Original-Maintainer: Debian Games Team pkg-games-devel@lists.alioth.debian.org Architecture: amd64 Source: glfw Version: 2.7.2-1 ...

Thus, a manual build is required on Linux.

For OSX, I strongly suggest we transition to the native Cocoa implementation I worked on. Otherwise, we add unnecessary layers with GLFW.

younkhg commented 8 years ago

Primary plan of glfw project was to test getting newer version (Core Profile) of OpenGL running, rather than replacing GLUT (maybe I named it wrong) Also I didn't know that there will be glfw version problem with Linux...

I picked glfw for the project because I don't know obj-C, but I agree with using native Cocoa for OSX.

I think we can discuss by dividing the cases by OpenGL version (core & compatibility) and platform. (Also we can talk about how much do we want core profile.)

On Dec 15, 2015, at 9:22 PM, Lance Putnam notifications@github.com wrote:

Is the plan here to replace GLUT? If so, there might be one snag on Linux---APT only has version 2.7.2:

$ apt-cache show libglfw-dev Package: libglfw-dev Priority: optional Section: universe/libdevel Installed-Size: 199 Maintainer: Ubuntu Developers ubuntu-devel-discuss@lists.ubuntu.com mailto:ubuntu-devel-discuss@lists.ubuntu.com Original-Maintainer: Debian Games Team pkg-games-devel@lists.alioth.debian.org mailto:pkg-games-devel@lists.alioth.debian.org Architecture: amd64 Source: glfw Version: 2.7.2-1 ...

Thus, a manual build is required on Linux.

For OSX, I strongly suggest we transition to the native Cocoa implementation I worked on. Otherwise, we add unnecessary layers with GLFW.

— Reply to this email directly or view it on GitHub https://github.com/AlloSphere-Research-Group/AlloSystem/issues/18#issuecomment-164748653.

AlloSphere-Research-Group / AlloSystem

GLFW for window/input management #18