GLFW 304 wrapper 1.03 (Win/Lin/OSX x86/x64 Static/Dynamic)

[luis]

PB 5.21

Wrapper for glfw + pre-compiled binaries.

It can use both static and dynamic linking, include all the precompiled library for all the OSes in static and dynamic version.

I've tested it a little on all the OSes, x86/x64, ascii/unicode but if you are interested in it I would appreciate if you can report back if it does work for you and your OS version/distribution.

Also if you spot some error, please report back

Download [... from someone who got a copy at the time].

Please note these compiled libraries contains some fixes not present in the original package:

1) A fix to make the OSX application menu work when the lib is used with a PB client (OSX only)
2) A fix relative to some flags used to the check if a OpenGL debug context is available (all platforms)

My thanks to Danilo for sorting out the OSX problem!

[idle]

works fine on linux x64

[IdeasVacuum]

Looks very interesting Luis.

Running test.pb on WinXPx86, PB5.21LTS, Unicode, I get the following message:

PureBasic_Compilation0.exe - Unable to Locate Component
This application has failed to start because MSVCR100D.dll was not found. Re-installing the application may fix this problem.

Could that be changed to use MSVCR100.dll? MSVCR100D.dll is distributed with MS Visual C++ 2010?

[luis]

@idle thanks

This application has failed to start because MSVCR100D.dll was not found. Re-installing the application may fix this problem.

Strange, it shouldn't look for the 'D' unless the project generated by CMake was targeting a debug build, I'll look into it this weekend.
In the meantime could you try to copy the glfw3.x86.vcrt.dll as glfw3.x86.dll (overwriting the latter) and tell me if it works that way ?

I'll try inside a VM too with a fresh install of the OS so there will be not the developing libraries around.

Sorry, I'll sort it out... I have probably lost myself in all the different compilers, OSes, makefiles ...

[applePi]

Thank you luis,
i have also the error message about the msvcr100d.dll . i have downloaded the dll from http://www.dll-files.com/dllindex/dll-f ... ?msvcr100d
i put it in the folder as the PureBasic_Compilation0.exe and it works displaying the colored triangle. but for who want to download the dll don't click on "download msvcr100d.dll Fixer" but click on "download the ZIP_File"
my system is windows xp. i have the vc++ 2010 (x86) runtime installed but the msvcr100d.dll is needed.

[luis]

@ideasvacuum, applepi

Yep, it was using a debug build, sorry. Now it does not include the debug stuff anymore on both win and osx.

On win you can select from two type of dlls, depending on your requirements.

glfw3.x??.dll (default)

the direct dependencies for this one are:

KERNEL32.DLL
USER32.DLL
GDI32.DLL
WINMM.DLL
OPENGL32.DLL
MSVCR100.DLL

glfw3.x??.msvcr.dll (optional)

same of the above minus the MSVCR100.DLL which should not be needed anymore.

I have updated the first post.

[Poshu]

Works fine on osx maverick, PB 5.21 x64. Thanks a lot!

[IdeasVacuum]

...It's perfect now on XP SP3.

[luis]

Just an heads up to let you know I noticed a problem in the OSX version (OSX users, do you confirm this ?).
When the lib creates its cocoa window with the GL view inside, calls some code to create a default menu for the app.
Suppose the name of the app is Boing.

It should show two menus: Boing and Window

Under Boing we have
About Boing
Services
Hide Boing
Hide Others
Show All
Quit Boing

and under Window
Minimize
Zoom
Bring All to Front
Enter Full Screen
"here the title of the window" (with a checkmark)

All this work if you use the library you find in the zip with a minimal C program equivalent to the demo PB program you find also in the zip.

When the program is a PB program though, the menu just contains one menu, the main one, and not the second one (Window).
Under this one (in debug called PureBasic.0, the name of the temp exe) we have

Services
Hide PureBasic.0
Hide Others
Show All
Quit PureBasic.0

Now, I don't know where this contents are coming from and why the code implicitly called from the lib does not have any effect here. Also the hide/show entries works while the quit entry does nothing.

Maybe there is some conflict with something PB does at startup (even if we are not creating a PB window) ?

If anyone is interested, the source code of the lib is available here -> http://www.glfw.org/download.html

The code I'm talking about is inside the file "cocoa_window.m"

Code: Select all

// Set up the menu bar (manually)
// This is nasty, nasty stuff -- calls to undocumented semi-private APIs that
// could go away at any moment, lots of stuff that really should be
// localize(d|able), etc.  Loading a nib would save us this horror, but that
// doesn't seem like a good thing to require of GLFW's clients.
//
static void createMenuBar(void)
{
    NSString* appName = findAppName();

    NSMenu* bar = [[NSMenu alloc] init];
    [NSApp setMainMenu:bar];

    NSMenuItem* appMenuItem =
        [bar addItemWithTitle:@"" action:NULL keyEquivalent:@""];
    NSMenu* appMenu = [[NSMenu alloc] init];
    [appMenuItem setSubmenu:appMenu];

    [appMenu addItemWithTitle:[NSString stringWithFormat:@"About %@", appName]
                       action:@selector(orderFrontStandardAboutPanel:)
                keyEquivalent:@""];
    [appMenu addItem:[NSMenuItem separatorItem]];
    NSMenu* servicesMenu = [[NSMenu alloc] init];
    [NSApp setServicesMenu:servicesMenu];
    [[appMenu addItemWithTitle:@"Services"
                       action:NULL
                keyEquivalent:@""] setSubmenu:servicesMenu];
    [appMenu addItem:[NSMenuItem separatorItem]];
    [appMenu addItemWithTitle:[NSString stringWithFormat:@"Hide %@", appName]
                       action:@selector(hide:)
                keyEquivalent:@"h"];
    [[appMenu addItemWithTitle:@"Hide Others"
                       action:@selector(hideOtherApplications:)
                keyEquivalent:@"h"]
        setKeyEquivalentModifierMask:NSAlternateKeyMask | NSCommandKeyMask];
    [appMenu addItemWithTitle:@"Show All"
                       action:@selector(unhideAllApplications:)
                keyEquivalent:@""];
    [appMenu addItem:[NSMenuItem separatorItem]];
    [appMenu addItemWithTitle:[NSString stringWithFormat:@"Quit %@", appName]
                       action:@selector(terminate:)
                keyEquivalent:@"q"];

    NSMenuItem* windowMenuItem =
        [bar addItemWithTitle:@"" action:NULL keyEquivalent:@""];
    NSMenu* windowMenu = [[NSMenu alloc] initWithTitle:@"Window"];
    [NSApp setWindowsMenu:windowMenu];
    [windowMenuItem setSubmenu:windowMenu];

    [windowMenu addItemWithTitle:@"Minimize"
                          action:@selector(performMiniaturize:)
                   keyEquivalent:@"m"];
    [windowMenu addItemWithTitle:@"Zoom"
                          action:@selector(performZoom:)
                   keyEquivalent:@""];
    [windowMenu addItem:[NSMenuItem separatorItem]];
    [windowMenu addItemWithTitle:@"Bring All to Front"
                          action:@selector(arrangeInFront:)
                   keyEquivalent:@""];

#if MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
    if (floor(NSAppKitVersionNumber) > NSAppKitVersionNumber10_6)
    {
        // TODO: Make this appear at the bottom of the menu (for consistency)

        [windowMenu addItem:[NSMenuItem separatorItem]];
        [[windowMenu addItemWithTitle:@"Enter Full Screen"
                               action:@selector(toggleFullScreen:)
                        keyEquivalent:@"f"]
            setKeyEquivalentModifierMask:NSControlKeyMask | NSCommandKeyMask];
    }
#endif /*MAC_OS_X_VERSION_MAX_ALLOWED*/

    // Prior to Snow Leopard, we need to use this oddly-named semi-private API
    // to get the application menu working properly.
    SEL setAppleMenuSelector = NSSelectorFromString(@"setAppleMenu:");
    [NSApp performSelector:setAppleMenuSelector withObject:appMenu];
}

#endif /* _GLFW_USE_MENUBAR */

and it's invoked here

Code: Select all

// Initialize the Cocoa Application Kit
//
static GLboolean initializeAppKit(void)
{
    if (NSApp)
        return GL_TRUE;

    // Implicitly create shared NSApplication instance
    [GLFWApplication sharedApplication];

    // In case we are unbundled, make us a proper UI application
    [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];

#if defined(_GLFW_USE_MENUBAR)
    // Menu bar setup must go between sharedApplication above and
    // finishLaunching below, in order to properly emulate the behavior
    // of NSApplicationMain
    createMenuBar();
#endif

    [NSApp finishLaunching];

    return GL_TRUE;
}

For the life of me, I don't understand why does not work when called from the PB program.

I'm a little disappointed because seems to work well generally, and I have not found a problem yet under win/linux.

This makes it look very "unpolished" a PB program using this under OSX, sadly. If you want to use only full screen it's not really a problem... but nevertheless.

I leave these notes here in case some one will care to try his hand at this, I don't know enough about OSX to investigate this properly.

*SIGH*

[Poshu]

I guess PB takes control over the menu as soon as the executable start (since the "PureBasic.0" menu is mandatory, it makes sense: pb is intended to be easy to use :p), I can see a way or two around it, but nothing clean :/

[luis]

FYI: I put together a quick and dirty partial wrapper for SDL 2 to test it, and guess what, the Application Menu is again screwed up in the same exact way.
The code used by SDL to setup the menu is more or less equivalent to the one used by glfw.

Fred, can you confirm PB tries to do something with the Application Menu at startup even if no window is opened ?
If that's the case, could be possible to make that part of the initialization optional ?
Or do you have some suggestions to bypass this problem ? Some code do destroy the App menu (if it's possible, but probably not) before initializing a third part lib like glfw or sdl to leave them to create the menu ? With a minimal C program they work just fine.
I had thought the cocoa code in the post above would have replaced the PB menu, but it doesn't seem the case.
Please also note the "ghost" menu does not have the About and Preferences entries, it starts with "Services", if that can suggest you anything.

[Danilo]

FYI: I put together a quick and dirty partial wrapper for SDL 2 to test it, and guess what, the Application Menu is again screwed up in the same exact way.
The code used by SDL to setup the menu is more or less equivalent to the one used by glfw.

I had the same problem few days ago, without PureBasic. Bought Monkey and BlitzMax and changed the Monkey IDE source a little bit.
It is C++ code and uses QT 4.8.4. Same problem, the menus are all gone, except the first one (and this menu is not correct, exactly same way you said).
So it is the same issue with C++ and QT. I also tried to compile with latest QT 5.2.0, same issue.

Could it be a Mac OS X issue/bug with Mavericks? I guess if you compile on Mountain Lion, it works correctly.
The already compiled Monkey IDE (that comes with the product) works correctly on Mavericks.
Compiling on Mavericks itself and the menus are gone! So my guess is, it has something to do with the Xcode libraries on Mavericks.
Requires more investigation what has changed. What APIs are deprecated, what old APIs got removed, etc.
Maybe it was officially changed and we have to rewrite our menu code?

Can you try to compile on Mountain Lion, and then run the executable on Mavericks? I have the feeling this should work.

[luis]

I had the same problem few days ago, without PureBasic. Bought Monkey and BlitzMax and changed the Monkey IDE source a little bit. It is C++ code and uses QT 4.8.4. Same problem, the menus are all gone, except the first one (and this menu is not correct, exactly same way you said).

This is very interesting because it would seem to suggest it's not PB related. But I don't think it does match with my experience.
I'm not using Mavericks. Please read more below.

Could it be a Mac OS X issue/bug with Mavericks? I guess if you compile on Mountain Lion, it works correctly.
The already compiled Monkey IDE (that comes with the product) works correctly on Mavericks.
Compiling on Mavericks itself and the menus are gone! So my guess is, it has something to do with the Xcode libraries on Mavericks.
Requires more investigation what has changed. What APIs are deprecated, what old APIs got removed, etc.
Maybe it was officially changed and we have to rewrite our menu code?

I'm talking now only about glfw because it's the only one where I rebuilt the library from source. With SDL I just tried with the precompiled binaries and so I would have to verify it better.
Back on glfw.

I'm using Mountain Lion, updated with the latest updates available from Apple.
I've compiled the library with XCode 4.63, and PB has installed the 4.62 version of the command line tools.
The library come with some sample programs. They work has expected when compiled by myself against the library just created.
Using PB with the same library, the menu is broken as discussed above.
And therefore, the code creating the menu it's the same, compiled from the same set of lbs, running under the same OS, and it does work in a case but not in the other.

So, unless I'm missing something, this does not seem to validate your hypothesis for this specific case, right ?
Nevertheless something funny it's happening in the scenario you described, but maybe it's not the same thing ?

Can you try to compile on Mountain Lion, and then run the executable on Mavericks? I have the feeling this should work.

I can't because I only have a single Mac with ML, but Poshu (read above) tried it on mavericks. Initially he said "works fine" but then has replied to my message where I was revealing the problem and he didn't say "but here works well!"
So I think he saw the problem too, in the end.

poshu can you confirm ?

BTW you can try it on Mavericks too if you like, the zip contains all that's needed

Anyway, what can I say, I'll double check it again based on what you said Danilo, just to be absolutely sure I didn't run something pre-built who-knows-how in some way. I'll change some string in the menus in the library code to be absolute sure and have visual confirmation everyone it is really using what it should be using.
If you have any other idea, comment, suggestion, I would be happy to hear it.

[luis]

I have double checked. Rebuilt all, verified that both the demo C sources and the PB test source were using the same lib: menu screwed up with PB 5.21, ok with C program, all under OSX ML 10.8.5 as described above.

[Danilo]

Got my C++/QT thingy working today. It had nothing to do with your problem.

Now I looked at your problem an got the menu working here. The problem is the following function in cocoa_window.m:

Code: Select all

// Initialize the Cocoa Application Kit
//
static GLboolean initializeAppKit(void)
{
    if (NSApp)
        return GL_TRUE;

    // Implicitly create shared NSApplication instance
    [GLFWApplication sharedApplication];

    // In case we are unbundled, make us a proper UI application
    [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];

#if defined(_GLFW_USE_MENUBAR)
    // Menu bar setup must go between sharedApplication above and
    // finishLaunching below, in order to properly emulate the behavior
    // of NSApplicationMain
    createMenuBar();
#endif

    [NSApp finishLaunching];

    return GL_TRUE;
}

The first check is always true here:

Code: Select all

    if (NSApp)
        return GL_TRUE;

It means the other code never gets executed. I removed the 2 lines and it worked here.

This function gets called on every window creation. To prevent this (always create new menu),
I introduced a new variable and a check to the code:

Code: Select all

bool appKitAlreadyInitialized = false;

// Initialize the Cocoa Application Kit
//
static GLboolean initializeAppKit(void)
{
    if ((appKitAlreadyInitialized == true) && NSApp)
        return GL_TRUE;

    appKitAlreadyInitialized = true;

    // Implicitly create shared NSApplication instance
    [GLFWApplication sharedApplication];

    // In case we are unbundled, make us a proper UI application
    [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular];

#if defined(_GLFW_USE_MENUBAR)
    // Menu bar setup must go between sharedApplication above and
    // finishLaunching below, in order to properly emulate the behavior
    // of NSApplicationMain
    createMenuBar();
#endif

    [NSApp finishLaunching];

    return GL_TRUE;
}

Now I have all menus here on Mavericks.

Maybe PB already creates some NSApp stuff for initialization, something your C code does not do automatically.
My change forces to do the init one time, even if NSApp is already initialized by PB. Should also be compatible to older OS.


BTW, nice work! Thanks!