Window manager - Revision history

Martin at 20:06, 4 April 2007

2007-04-04T20:06:47Z

Martin: /* Window Level */

2007-04-04T19:43:57Z

Window Level

Martin at 04:26, 30 March 2007

2007-03-30T04:26:06Z

Martin: /* Menu */

2007-03-30T04:23:43Z

Martin at 04:16, 30 March 2007

2007-03-30T04:16:28Z

Martin at 04:08, 30 March 2007

2007-03-30T04:08:18Z

Martin: /* App Icon */

2007-03-30T04:03:15Z

App Icon

Martin at 03:58, 30 March 2007

2007-03-30T03:58:11Z

Martin: /* Window Type */

2007-03-30T03:40:18Z

Window Type

Martin: /* Window Type */

2007-03-30T03:39:49Z

Window Type

@@ Line 1: / Line 1: @@
 In Windows and Mac OS X the window manager is tied into the OS. That's not the case for Linux or BSD. [[Window Maker]] is the recommended window manager for GNUstep, but a standard feature-set is needed. GNUstep-based applications have additional needs beyond traditional window managers, like handling the dock icon or the menus. Collecting the requirements here will lead to a specification, so any window manager can clearly state whether or not it is GNUstep-compliant.
-=Backend WM Attributes=
+=WM Attributes=
 Headers/x11/XGServerWindow.h defines
    unsigned long flags
@@ Line 26: / Line 26: @@
    #define WMFHideOtherApplications            10
    #define WMFHideApplication                  12
 =Window Level=

@@ Line 28: / Line 28: @@
 =Window Level=
-GNUstep needs arbitrary window levels. EWMH defines these two:
+GNUstep needs arbitrary window levels. [http://standards.freedesktop.org/wm-spec/wm-spec-latest.html Extended Window Manager Hints] defines these two:
    _NET_WM_STATE_ABOVE, ATOM
    _NET_WM_STATE_BELOW, ATOM

← Older revision		Revision as of 04:26, 30 March 2007
Line 79:		Line 79:

	And now, some people like to have a horizontal menu (like Mac OS X) instead of a vertical menu (like NEXTSTEP). They behave differently for submenus. For a horizontal menu, the submenu will close on an action fire. For a vertical menu, the submenu will stay open after an action fire. So I guess only GNUstep can handle it.		And now, some people like to have a horizontal menu (like Mac OS X) instead of a vertical menu (like NEXTSTEP). They behave differently for submenus. For a horizontal menu, the submenu will close on an action fire. For a vertical menu, the submenu will stay open after an action fire. So I guess only GNUstep can handle it.
		+
		+	=Window Resizing and Moving=
		+	GNUstep defines:
		+	#define GSWindowWillResizeNotificationsFlag (1<<1)
		+	#define GSWindowWillMoveNotificationsFlag (1<<2)
		+	I didn't see it in Window Maker, therefore, I don't know whether it is really supported. But it may be key for some windows turning black when resizing.

@@ Line 73: / Line 73: @@
 X has focused and unfocused window, GNUstep has key window and main window, plus menu and app icon. I don't know how the chain of focus should go when the window and menu are up and down. But again, if there is a hint for the main window, key window, main menu, etc, it will be easy for the window manager to know where the focus should go. A documentation of how the focus should shift from which to which may help.
-=Menu=
+=Menus=
 Again, because there are no real hints about which one is the main menu and submenu besides window level, it is hard to find the correct one. So menus are treated as regular windows in most cases.

← Older revision		Revision as of 04:16, 30 March 2007
Line 72:		Line 72:
	=Focus=		=Focus=
	X has focused and unfocused window, GNUstep has key window and main window, plus menu and app icon. I don't know how the chain of focus should go when the window and menu are up and down. But again, if there is a hint for the main window, key window, main menu, etc, it will be easy for the window manager to know where the focus should go. A documentation of how the focus should shift from which to which may help.		X has focused and unfocused window, GNUstep has key window and main window, plus menu and app icon. I don't know how the chain of focus should go when the window and menu are up and down. But again, if there is a hint for the main window, key window, main menu, etc, it will be easy for the window manager to know where the focus should go. A documentation of how the focus should shift from which to which may help.
		+
		+	=Menu=
		+	Again, because there are no real hints about which one is the main menu and submenu besides window level, it is hard to find the correct one. So menus are treated as regular windows in most cases.

← Older revision		Revision as of 04:08, 30 March 2007
Line 69:		Line 69:

	EWMH defines <tt>_NET_WM_ICON</tt> for app icon image. GNUstep supports it, but I am not sure if it is updated when the app icon image is changed. And if people use app icon as a <tt>NSWindow</tt> and draw directly on it, there is no way the window manager will know. The solution is that if there is a notification that the icon is redrawn, the window manager or GNUstep can copy (or take a screenshot of) the image from that <tt>NSWindow</tt> and put it into <tt>_NET_WM_ICON</tt>. It requires something like <tt>XCopyArea()</tt>.		EWMH defines <tt>_NET_WM_ICON</tt> for app icon image. GNUstep supports it, but I am not sure if it is updated when the app icon image is changed. And if people use app icon as a <tt>NSWindow</tt> and draw directly on it, there is no way the window manager will know. The solution is that if there is a notification that the icon is redrawn, the window manager or GNUstep can copy (or take a screenshot of) the image from that <tt>NSWindow</tt> and put it into <tt>_NET_WM_ICON</tt>. It requires something like <tt>XCopyArea()</tt>.
		+
		+	=Focus=
		+	X has focused and unfocused window, GNUstep has key window and main window, plus menu and app icon. I don't know how the chain of focus should go when the window and menu are up and down. But again, if there is a hint for the main window, key window, main menu, etc, it will be easy for the window manager to know where the focus should go. A documentation of how the focus should shift from which to which may help.

← Older revision		Revision as of 04:03, 30 March 2007
Line 67:		Line 67:
	=App Icon=		=App Icon=
	GNUstep used to have <tt>NSDockWindowLevel</tt>, but it is deprecated. So to know which window is the app icon, you have to first find a GNUstep window, check its <tt>group_leader</tt>, (See <tt>XWMHints</tt> in X protocols), then check its <tt>icon_window</tt> which points to app icon. Again, it will be easier if there is hint (see above).		GNUstep used to have <tt>NSDockWindowLevel</tt>, but it is deprecated. So to know which window is the app icon, you have to first find a GNUstep window, check its <tt>group_leader</tt>, (See <tt>XWMHints</tt> in X protocols), then check its <tt>icon_window</tt> which points to app icon. Again, it will be easier if there is hint (see above).
		+
		+	EWMH defines <tt>_NET_WM_ICON</tt> for app icon image. GNUstep supports it, but I am not sure if it is updated when the app icon image is changed. And if people use app icon as a <tt>NSWindow</tt> and draw directly on it, there is no way the window manager will know. The solution is that if there is a notification that the icon is redrawn, the window manager or GNUstep can copy (or take a screenshot of) the image from that <tt>NSWindow</tt> and put it into <tt>_NET_WM_ICON</tt>. It requires something like <tt>XCopyArea()</tt>.

← Older revision		Revision as of 03:58, 30 March 2007
Line 64:		Line 64:

	Comments from Yen-Ju Chen: "GNUstep has no such definition and use window level for this purpose. Personally, I wish GNUstep had a better way to tell which window is for which functions, like app icon, floating panel, menu, key window, main window. The window level is not that reliable when people want to do some tricks. It may not match EWMH one-to-one, but it will be useful for various reasons."		Comments from Yen-Ju Chen: "GNUstep has no such definition and use window level for this purpose. Personally, I wish GNUstep had a better way to tell which window is for which functions, like app icon, floating panel, menu, key window, main window. The window level is not that reliable when people want to do some tricks. It may not match EWMH one-to-one, but it will be useful for various reasons."
		+
		+	=App Icon=
		+	GNUstep used to have <tt>NSDockWindowLevel</tt>, but it is deprecated. So to know which window is the app icon, you have to first find a GNUstep window, check its <tt>group_leader</tt>, (See <tt>XWMHints</tt> in X protocols), then check its <tt>icon_window</tt> which points to app icon. Again, it will be easier if there is hint (see above).

← Older revision		Revision as of 03:40, 30 March 2007
Line 63:		Line 63:
	_NET_WM_WINDOW_TYPE_NORMAL, ATOM		_NET_WM_WINDOW_TYPE_NORMAL, ATOM

−	Comments from Yen-Ju Chen: "GNUstep has no such definition and use window level for this purpose. Personally, I wish GNUstep ~~hasa~~ better way to tell which window is for which functions, like app icon, floating panel, menu, key window, main window. The window level is not that reliable when people want to do some tricks. It may not match EWMH one-to-one, but it will be useful for various reasons."	+	Comments from Yen-Ju Chen: "GNUstep has no such definition and use window level for this purpose. Personally, I wish GNUstep had a better way to tell which window is for which functions, like app icon, floating panel, menu, key window, main window. The window level is not that reliable when people want to do some tricks. It may not match EWMH one-to-one, but it will be useful for various reasons."

← Older revision		Revision as of 03:39, 30 March 2007
Line 62:		Line 62:
	_NET_WM_WINDOW_TYPE_DND, ATOM		_NET_WM_WINDOW_TYPE_DND, ATOM
	_NET_WM_WINDOW_TYPE_NORMAL, ATOM		_NET_WM_WINDOW_TYPE_NORMAL, ATOM
		+
		+	Comments from Yen-Ju Chen: "GNUstep has no such definition and use window level for this purpose. Personally, I wish GNUstep hasa better way to tell which window is for which functions, like app icon, floating panel, menu, key window, main window. The window level is not that reliable when people want to do some tricks. It may not match EWMH one-to-one, but it will be useful for various reasons."