| | [ Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]
STR #3252
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | MacOS |
|---|
| Summary: | Fl_Native_File_Chooser and Fl_Gl_Window on MacOS X |
|---|
| Version: | 1.3-current |
|---|
| Created By: | geuzaine.acm.caltech |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
| |
| #1 | geuzaine.acm.caltech
05:15 Aug 20, 2015 |
| There seems to be a little bug in the way Fl_Native_File_Chooser and Fl_Gl_Window interact on MacOS X in the special case when the MacOS X file chooser is in "gallery" mode, i.e., when the icons are displayed graphically in a scrollable horizontal panorama.
To reproduce the problem:
1) Compile the attached file with "fltk-config --use-gl --compile test_native.cxx" on MacOS X, and run it. A green OpenGL window should appear.
2) Click and move the mouse in the green window: the square should move to the
right.
3) Press "Ctrl+o" and choose the "gallery" mode to view the file icons in a scrollable horizontal gallery.
4) Close the file chooser by clicking on "Cancel".
5) Click in the green window and move the mouse again: the square does not move. This problem does not appear for all other file viewing modes. | |
| |
| #2 | greg.ercolano
05:06 Jul 22, 2016 |
| Just adding my two cents..
Verified on OSX 10.7.5.
Seems like gallery mode of OSX's browser messes up the opengl context somehow,
likely because it uses opengl internally.
I found if I added win->resizable(win); just before the show(),
really bad stuff happens when I resize the window after the browser is shown/cancelled.
The window simply doesn't redraw properly from then on.
Seems like our opengl state gets ruined by the browser's internals.
Needs some investigation.. | |
| |
| #3 | greg.ercolano
20:44 Jul 22, 2016 |
| OK, seems there's a lot about this on the net.
Internally Fl_Native_File_Chooser (or "FNFC") uses the OSX function
NSOpenPanel to open the native dialog.
Googling for "NSOpenPanel OpenGL" seems to yield a lot of hits about
this same issue where the file chooser wrecks opengl apps.
I've tried poking at this quite a bit and can't figure out how to
get opengl working again after the dialog is closed; I've tried various things
after the native.show() method returns:
a) win->invalidate() -- to force glOrtho() et al
b) hide() + show()ing the window (being sure it unmaps)
c) resetting the gl context, with e.g. win->context(0,1); win->make_current()
I'm not really sure what the Apple file browser is breaking here..
it seems to be the opengl context, but I'm pretty sure that's getting
recreated by (b) or (c) above. (See docs for Fl_Gl_Window::context() re: (c))
Maybe Manolo might know what this is; seems like some internal OSX / OpenGL thing,
possibly along the lines of what's shown here:
Restore OpenGL context after showing file dialog
------------------------------------------------
https://github.com/waneck/systools/pull/30/files?diff=split
..which describes how to save and restore the current opengl context from .mm files (ObjectiveC). | |
| |
| #4 | matt
04:23 Jan 20, 2023 |
| Current version of macOS no longer offer gallery mode. I tried the example in all other available modes, and everything seems fine. If there is no reaction, I will close this in a week or two. | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
