Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Issues with GLFW 3.0

Using GLFW
Robert
2013-07-04
2013-07-04
  • Robert
    Robert
    2013-07-04

    Dear GLFW Developer(s),

    Forgive me in advanced if I sound harsh as I try to write this without spewing out an infinite string of curses in rage and frustration, however please hear me out.

    In the latest release of GLFW 3.0 (and 3.0.1) there have been some changes that have really more than just irritated me over the past numerous weeks. These changes beyond irritating relate to key inputs. More specifically 2 things.

    The first is key inputs now take tokens and no longer values produced by the keyboard. Which said in the documentation "for all keys on a standard [US] 105 key keyboard". This really concerns me as the majority of people I target my software towards do not use a standard American keyboard. Take for example a Mandarin keyboard, there are many variations of this in use and a lot of them have more than 105 physical keys (and more key values, my keyboard alone has 113+ physical keys).

    Second and a 1000x more important is removal of system wide keys. This was one of the most important things to me from GLFW. I cannot develop nearly half the things I was working on now due to this (and I'm not exaggerating if anything I'm unexaggerating). One of the major things I was working on was an Opengl wrapper for a cross-platform OS interface (much like the windows explorer but better). And you see without the system keys I cannot develop for what is needed. However I cannot revert back to GLFW 2.0 because a multi-windowed system is needed. And I do not wish to switch libraries because there are none out there that fits my needs better than GLFW already has (and developing my own is kinda redundant with all those out there). Now that's just one example of many and probably a bad one at that but my point is I like to have full control over my computer (reason why I use C++ instead of virtual style code like java applets) and I believe more power to the people is better (I also am working on a simulator that require use of 1000+ key commands for the better or worse it's kinda the whole premise of the game). And I'm not the only one that thinks this (my whole development team agrees with me) but I still want to know why. Now I could bring in ethical issues into this (I really could) but this is dragging out far too long and if your still reading by now I thank you.

    So I do have few work-arounds but I do not know if they are going to work (and who not better to ask than the person working on it). I (and another member of my team) have been thinking if it would be possible to extract code from 2.7.2 and fuse it with 3.0.1 to re-enable system wide hot-keys or more so what are the conflicts between the two.

    As for all of the other things in the recent release things like name changes, they're annoying but that's just it annoying. These things I can get used to and it's the price of updating a library half way through a project.
    GLFW has been and hopefully will be one of the best libraries out there and I think that the only way to keep something good is if the people knowing the issues address the issues to the people who can fix the issues. Many thanks are given if you have read all this and even more if you have considered to write back.
    Thanks, Robert Stere.

    P.S sorry if this was posted in the wrong place, I was trying to find the most appropriate place to send this to.
    P.S. pt2 Unrelated but is the documentation going to be further worked on for 3.0 because there are many things that don't make sense in it like fullscreen (I can't get fullscreen to render anything it just puts my screen to sleep). Thanks again.

     
  • Marcel Metz
    Marcel Metz
    2013-07-04

    The first is key inputs now take tokens and no longer values produced by the keyboard. Which said in the documentation "for all keys on a standard [US] 105 key keyboard". This really concerns me as the majority of people I target my software towards do not use a standard American keyboard. Take for example a Mandarin keyboard, there are many variations of this in use and a lot of them have more than 105 physical keys (and more key values, my keyboard alone has 113+ physical keys).

    Those tokens describe common/known keys, following the USB HID Usage Tables v1.12. You still have the scancode parameter to identify non-common and platform specific keys.

    Second and a 1000x more important is removal of system wide keys.

    Most applications shouldn't implement the system wide interception of input. I personally don't like the idea that anything but the shell would would snitch away system wide keys input. However you stated that you're actually writing something like a shell or maybe not? You talk an explorer like OS interface in one paragraph and about a simulator in another.

    and I believe more power to the people is better

    The intention of GLFW to provide a uniform interface to the underlying windowing system, the opengl context creation and input processing that has a well defined semantic on all supported platforms and not giving more power to the people, whatever that should mean in this context.

    As for all of the other things in the recent release things like name changes, they're annoying but that's just it annoying.

    An API breakage should to be expected when the major version changes.

     
  • Camilla Löwy
    Camilla Löwy
    2013-07-04

    The US keyboard layout is used for the names of the key tokens. It doesn't mean that keyboard input is limited to that or any other layout. Use the events test to see how it works in practice on your keyboard.

    Global input grabbing was removed as it's rude. People in 2013, myself included, expect to be able to Alt-Tab out of things. That said, if you want it brought back, submit a feature request and make a case for it.

    If full screen mode puts your monitor to sleep then that's a bug. Please file a bug report so this doesn't get lost.