Suggestions and ideas
From GLFW
This page is used to keep track of ideas that have not yet been approved for inclusion into any version of GLFW. Once an idea has been approved, it should be moved to the roadmap page. Unlike the roadmap, this page is free for anyone to add to. If an idea is rejected, it should not be removed but rather expanded to include the reasons why it was rejected.
Not sure yet what do do about the fact that this duplicates the role of the feature request tracker.
Update existing examples
The existing examples are out of date and not good examples of using OpenGL. They should be reworked in order to reflect modern OpenGL best practices. This does not mean that they will require GL3; just that they should start users off with good and relevant habits.
Contact: Camilla
Add new examples
Each GLFW version from now on should include a new example. Proposals for GLFW 3.0 includes a multi-window example of a simple immediate mode UI toolkit.
Contact: Olivier
Documentation
Replacing both guides with Doxygen based documentation. One aspect of the guide would be the reference manual based on function description. The other aspect which is the user manual is to provide cross topic walk through that explain how the different function of the GLFW API interact with each other. The documentation might cover some of the examples as well.
Contact: Olivier
Clean up and document internal API
The interaction between the shared and platform specific parts of GLFW is ad hoc and not documented, making future ports more difficult.
Event based joystick input
X11: implementation detailed sorted out prototype in progress Win32: Need investigation Cocoa: Daniel Brandt <dbr@mindglow.se>
Multi-dimensional scrolling
I think the number of axis supported by GLFW should not be fixed. If a device comes with two bi dimensional scrolling at some point GLFW should be able to handle it. I would like to have a generic API that provide a more generic API maybe even the same as the joystick API. The mouse could become an N-Axis capable device and the API would report all axis separately. I am not sure if it is the good way to go as we can probably assume that all device have two axis at least so we could keep the first two axis together and have a generic callback for all other axis. This goes of course with the capability to list capability of a device.
Contact: Olivier
(unclamped) Relative mouse movement
Double-click support
Direct support for double-click events. The issue preventing this is the lack of support for this concept at the Xlib level, as well as the different mechanisms used by various popular toolkits.
One proposal is to use .XDefault. However, this is used by neither Gnome nor KDE, so it is not a workable solution.
API to interrupt glfwWaitEvents from a secondary thread
A working solution has been identified for X11.
Oh dear, we're becoming GLUT.
Device enumeration and capability discovery
This work applies to the following devices:
- mice
- tablets
- joysticks
Several idea are encompass in the context of discovering capabilities. The current API of GLFW does not give us much information on the number of buttons or axis available on the mouse. The current API does not allow us to list the number of joystick/tablet devices available. Support for enumeration of those and extraction of there description would be nice.
It is most likely possible to use HID to get information about input device. However, it is not the best choice for linux and it usually only covers Bluetooth and USB devices. Most of the time it is okay. Linux provide the input interface which covers more devices. The input interface also allow basic discovery of capabilities of joysticks including:
- name,
- number of axis,
- number of button.
Further work is needed in order to find out capabilities for other devices and tablet.
Tablet input
Support input from tablets.
Removal of retained mode input
Removal of glfwGetKey and friend, most people who gave feedback on it feels against it... shame I might have to keep it in.
Better video mode enumeration
The current API for enumeration video modes is awful and needs to be replaced with something sane.
Monitor API
Enumeration of monitors, notifications of monitor connection/disconnection, enumeration of video modes for a specific monitor, query for the physical dimensions of a specific monitor.
Exposing native handles
From time to time, people request an API to access the native handles for context, window, etc. While this would encourage unportable coding practices, perhaps there is some way to make it worthwhile to include.
Separate window and context APIs
Exposing contexts and windows as separate API objects would make the GLFW API more flexible and orthogonal. The main issue preventhing this is that GDI only allows the pixel format to be set once for a given window.
Off-screen context support
If it is possible to create "hardware-accelerated" off-screen contexts on all supported platforms, support for it should potentially be added.
Contact: Camilla, Olivier
Replace window hints with Long Peak style attrib object
Since we decided to require window creation to be performed by the main thread, this is less relevant than it was in earlier GLFW3 designs. Still, it may be a cleaner and clearer design than the current one.
Custom window icon API
Resurrect the GLFWimage structure and allow client code to specify a window icon at runtime. Potential issues include the wildly different sizes used on different platforms, as OS X uses (huge) dock icons instead of individual window icons (no, document icons don't count).
Custom mouse cursor API
Resurrect the GLFWimage structure and allow client code to specify a cursor image at runtime. Potential issues include the limitation on cursor colors on X11.
Callbacks for cursor entering/leaving windows
One or two callbacks notifying client code whenever the cursor enters or leaves a GLFW window.
Support for X11/EGL
Fairly similar to the current X11/GLX port, but able to run on platforms such as Maemo and MeeGo. A patch has been contributed.
EGL wrapper of GLFW
A re-implementation of EGL on top of GLFW and OpenGL, especially useful now that GLFW has support for the ES2 profile.
Window hint for centered windows
Add a window hint that requests windows be initially centered on the specified monitor.
Window hint for requesting the software rasterizer
Someone may want this at some point for something.
WGL
There may be sane pixel formats tagged as supported by the MS rasterizer but not the GPU.
NSOpenGL
The software rasterizer can be explicitly requested.
GLX
No explicit mechanism appears to be available.
Callback for window position
Add a callback that is called when the window is moved.
Allow visible cursor to be limited to client area
Don't remember why someone requested this.
Support for Cocoa Touch/EAGL
Somewhat similar to the current Cocoa/NSGL port, but able to run on iOS.
Rename glfwEnable/glfwDisable
The glEnable/glDisable acts on library global data, while the GLFW counterparts act on per-window data. This needs to be reflected in their naming.
Window hint allowing single-buffered pixel formats
Someone wanted it, that's why.
Queries for window frame size
Allows client code to tell both where the client area and the full window is on screen.
![[Main Page]](http://wiki.glfw.org/wiki/images/logo.png){kind=logo}