The Windows SDK declares BOOL as an int. Objective C defines BOOl as a char.
Those two types clash. MinGW's implementation of the Windows SDK uses the WINBOOL
type to avoid this clash. When compiling natively on Windows, we need to manually
define WINBOOL.
MinGW will define _DEF_WINBOOL_ if it has defined WINBOOL so we can use the same trick
here.
See https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-headers/include/ntdef.h#L355
* Solve an undelcared close function
* Fix xdgshell protocol handling and resolve compile errors
* Fixing build errors in WaylandServer+Cursor
* Revert changes except wl_cursor_destroy to fix build and avoid regressions
* Fix selector warnings and method call type issues
* Use window parameter directly
* Comments removed
* Include NSGraphics to eliminate redundant declaration.
* Remove NSWindow include that was replaced by NSGraphics
name and WindowGroupHint to temporary window. Created window designed
to help get window frame offsets only - appicon window will be created
later. This change prevents appicon flickering on WindowMaker at
application start.
(_createWMAppiconHack, _setupRootWindow): WindowMaker hack removed in
favour of solution introduced in _checkStyle:.
* Source/x11/XGServerWindow.m: WindowMaker doesn't support
_NET_REQUEST_FRAME_EXTENTS message andthe only way to determine offsets
is creating and mapping window. In this case first mapped window of
application is not appicon window.
Early appicon creating inserted back as _createWMAppiconHack method and
called only if no other way to determine window's offsets (before call to
_checkStyle);appicon window size is set to size icon;
(_setupRootWindow, window::::): removed WindowMaker appicon hack and
- now unused - _wmAppIcon variable.
Description: The removed code removed creates and maps zero-sized
window in hope that WindowMaker will recognize app by this event and
create app icon window. Although when application requests window
for appicon through the `-window::::` method call, it returns newly
created and mapped window. This actually happens but application icon
flickers between WM icon creation and application icon window appearance.
This fix based on the fact that root application window (ROOT) is mapped
in `-orderwindow:::` and this is the event of application recognition
by WindowMaker because it is a first application window that is
mapped.
(_handleTakeFocusAtom:forContext:): if application (window) receives
WM_TAKE_FOCUS in hidden state it means WindowMaker wants us to be
unhidden.
Description: There are 2 protocols defined in XGServerWindow.h:
WMFHideApplication and WMFHideOtherApplications. These protocols exist
to help GNUstep application and WindowMaker notify each other
about "Hide" and "Hide Others" actions. There are no protocols for
"unhide" action.
Test case steps:
1. Open application with window opened.
2. Hide application with "Hide" menu item.
3. Open WindowMaker's "Windows" menu (middle-click on desktop).
4. Select hidden application window.
Application unhides, activates, restored window is focused (receives) input
and "Hide" menu item unselected.
(hideApplication:): send application's root window to WindowMaker (WM)
because it's a "group leader" that clearly identifies application
inside WM. WM uses XFindContext to get WApplication structure and
"group leader" window ID is a key to find it.
