Re: Xinerama
On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote: > On Sat, Nov 20, 2021 at 02:15:58PM +, Thomas Adam wrote: > > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote: > > > > > Is Xinerama still useful for anything or can we remove it? > > > > > It has already been removed. Where are you seeing references to it? > > Everywhere. I'll remove the junk on the parser branch. > > $ rgrep -i xinerama . 2> /dev/null > ./libs/defaults.h:/*** Xinerama ***/ > ./libs/defaults.h:#define DEFAULT_XINERAMA_ENABLEDTrue /* Xinerama on > by default */ > ./libs/defaults.h:#define XINERAMA_CONFIG_STRING "XineramaConfig" These can go, and the corresponding callers in FvwmForm can be changed. This looks to be the mechanism module used to use to register Xinerama interest. > ./libs/FTips.c: fscreen_scr_arg *fsarg = NULL; /* for now no xinerama > support */ That comment is misleading and can be changed, > ./modules/FvwmForm/FvwmForm.c: if (strncasecmp(buf, XINERAMA_CONFIG_STRING, > ./modules/FvwmForm/FvwmForm.c: > sizeof(XINERAMA_CONFIG_STRING)-1) == 0) > ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + > sizeof(XINERAMA_CONFIG_STRING)-1); > ./modules/FvwmForm/FvwmForm.c:buf, XINERAMA_CONFIG_STRING, > sizeof(XINERAMA_CONFIG_STRING)-1) > ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + > sizeof(XINERAMA_CONFIG_STRING)-1); See above. > ./modules/FvwmButtons/FvwmButtons.h:void handle_xinerama_string(char *args); That's just a function declaration without an implementation and can be removed. > ./.git/rr-cache/1c03ad931074cd97196af43ae2fc0134a13171cd/preimage:directly > adjacent to the screen's or xinerama screen's border. It > ./.git/rr-cache/d3fcccba50db8b879e64033b3c5f2ebe88fa6f57/preimage:directly > adjacent to the screen's or xinerama screen's border. It rerere cache from git so will ignore. > ./doc/fvwm3_commands.ad:directly adjacent to the screen's or xinerama > screen's border. It > ./doc/fvwm3all.1:directly adjacent to the screen\(cqs or xinerama screen\(cqs > border. It > ./doc/fvwm3_styles.ad:directly adjacent to the screen's or xinerama screen's > border. It > ./doc/fvwm3styles.1:directly adjacent to the screen\(cqs or xinerama > screen\(cqs border. It > ./doc/fvwm3_manpage_source.adoc:directly adjacent to the screen's or xinerama > screen's border. It These can change to either mention RandR, or just "screen". > ./fvwm/windowlist.c: * because it sets the xinerama screen origin */ > ./fvwm/add_window.c: fw->edge_resistance_xinerama_move = > ./fvwm/add_window.c: pstyle->edge_resistance_xinerama_move; > ./fvwm/move_resize.c: * in case Xinerama is used. */ > ./fvwm/move_resize.c: /* Resist moving windows between xineramascreens */ > ./fvwm/move_resize.c: if (fw->edge_resistance_xinerama_move) > ./fvwm/move_resize.c: scr_x1 + fw->edge_resistance_xinerama_move) > ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move) > ./fvwm/move_resize.c: scr_y1 + fw->edge_resistance_xinerama_move) > ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move) Funtionally now referencing RandR and are poorly named as xinerama isn't used. > ./fvwm/style.c: if (add_style->flags.has_edge_resistance_xinerama_move) > ./fvwm/style.c: SSET_EDGE_RESISTANCE_XINERAMA_MOVE( > ./fvwm/style.c: > SGET_EDGE_RESISTANCE_XINERAMA_MOVE(*add_style)); > ./fvwm/style.c: unsigned has_xinerama_move; > ./fvwm/style.c: has_xinerama_move = 0; > ./fvwm/style.c: has_xinerama_move = 1; > ./fvwm/style.c: has_xinerama_move = 0; > ./fvwm/style.c: > ps->flags.has_edge_resistance_xinerama_move = > ./fvwm/style.c: has_xinerama_move; > ./fvwm/style.c: > ps->flag_mask.has_edge_resistance_xinerama_move = 1; > ./fvwm/style.c: > ps->change_mask.has_edge_resistance_xinerama_move = 1; > ./fvwm/style.c: SSET_EDGE_RESISTANCE_XINERAMA_MOVE(*ps, > val[1]); > ./fvwm/fvwm.h:char*IconScreen; /* Xinerama > screen */ > ./fvwm/fvwm.h:unsigned has_edge_resistance_xinerama_move : 1; > ./fvwm/fvwm.h:int edge_resistance_xinerama_move; > ./fvwm/fvwm.h:int edge_resistance_xinerama_move; As above. This just needs renaming. > ./fvwm/commands.h:F_XINERAMA, > ./fvwm/commands.h:F_XINERAMAPRIMARYSCREEN, > ./fvwm/commands.h:F_XINERAMASLS, > ./fvwm/commands.h:F_XINERAMASLSSCREENS, > ./fvwm/commands.h:F_XINERAMASLSSIZE, > ./fvwm/commands.h:void CMD_Xinerama(F_CMD_ARGS); > ./fvwm/commands.h:void CMD_XineramaPrimaryScreen(F_CMD_ARGS); > ./fvwm/commands.h:void CMD_XineramaSls(F_CMD_ARGS); > ./fvwm/commands.h:void CMD_XineramaSlsScreens(F_CMD_ARGS); > ./
Re: Xinerama
On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote: > On Sat, Nov 20, 2021 at 02:15:58PM +, Thomas Adam wrote: > > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote: > > > > > Is Xinerama still useful for anything or can we remove it? > > > > > It has already been removed. Where are you seeing references to it? > > Everywhere. I'll remove the junk on the parser branch. No sorry, too complex for me, and I don't know the new implementation. The code in menus.c, move_resize.c etc is non-trivial and maybe still necessary. But wen can't do it with the parser branch pending. It would cause too many conflicts. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Xinerama
On Sat, Nov 20, 2021 at 02:15:58PM +, Thomas Adam wrote: > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote: > > > Is Xinerama still useful for anything or can we remove it? > > > It has already been removed. Where are you seeing references to it? Everywhere. I'll remove the junk on the parser branch. $ rgrep -i xinerama . 2> /dev/null ./libs/defaults.h:/*** Xinerama ***/ ./libs/defaults.h:#define DEFAULT_XINERAMA_ENABLEDTrue /* Xinerama on by default */ ./libs/defaults.h:#define XINERAMA_CONFIG_STRING "XineramaConfig" ./libs/FTips.c: fscreen_scr_arg *fsarg = NULL; /* for now no xinerama support */ ./modules/FvwmForm/FvwmForm.c: if (strncasecmp(buf, XINERAMA_CONFIG_STRING, ./modules/FvwmForm/FvwmForm.c:sizeof(XINERAMA_CONFIG_STRING)-1) == 0) ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + sizeof(XINERAMA_CONFIG_STRING)-1); ./modules/FvwmForm/FvwmForm.c: buf, XINERAMA_CONFIG_STRING, sizeof(XINERAMA_CONFIG_STRING)-1) ./modules/FvwmForm/FvwmForm.c: FScreenConfigureModule(buf + sizeof(XINERAMA_CONFIG_STRING)-1); ./modules/FvwmButtons/FvwmButtons.h:void handle_xinerama_string(char *args); ./.git/rr-cache/1c03ad931074cd97196af43ae2fc0134a13171cd/preimage:directly adjacent to the screen's or xinerama screen's border. It ./.git/rr-cache/d3fcccba50db8b879e64033b3c5f2ebe88fa6f57/preimage:directly adjacent to the screen's or xinerama screen's border. It ./doc/fvwm3_commands.ad:directly adjacent to the screen's or xinerama screen's border. It ./doc/fvwm3all.1:directly adjacent to the screen\(cqs or xinerama screen\(cqs border. It ./doc/fvwm3_styles.ad:directly adjacent to the screen's or xinerama screen's border. It ./doc/fvwm3styles.1:directly adjacent to the screen\(cqs or xinerama screen\(cqs border. It ./doc/fvwm3_manpage_source.adoc:directly adjacent to the screen's or xinerama screen's border. It ./fvwm/windowlist.c: * because it sets the xinerama screen origin */ ./fvwm/add_window.c:fw->edge_resistance_xinerama_move = ./fvwm/add_window.c:pstyle->edge_resistance_xinerama_move; ./fvwm/move_resize.c:* in case Xinerama is used. */ ./fvwm/move_resize.c: /* Resist moving windows between xineramascreens */ ./fvwm/move_resize.c: if (fw->edge_resistance_xinerama_move) ./fvwm/move_resize.c: scr_x1 + fw->edge_resistance_xinerama_move) ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move) ./fvwm/move_resize.c: scr_y1 + fw->edge_resistance_xinerama_move) ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move) ./fvwm/style.c: if (add_style->flags.has_edge_resistance_xinerama_move) ./fvwm/style.c: SSET_EDGE_RESISTANCE_XINERAMA_MOVE( ./fvwm/style.c: SGET_EDGE_RESISTANCE_XINERAMA_MOVE(*add_style)); ./fvwm/style.c: unsigned has_xinerama_move; ./fvwm/style.c: has_xinerama_move = 0; ./fvwm/style.c: has_xinerama_move = 1; ./fvwm/style.c: has_xinerama_move = 0; ./fvwm/style.c: ps->flags.has_edge_resistance_xinerama_move = ./fvwm/style.c: has_xinerama_move; ./fvwm/style.c: ps->flag_mask.has_edge_resistance_xinerama_move = 1; ./fvwm/style.c: ps->change_mask.has_edge_resistance_xinerama_move = 1; ./fvwm/style.c: SSET_EDGE_RESISTANCE_XINERAMA_MOVE(*ps, val[1]); ./fvwm/fvwm.h: char*IconScreen; /* Xinerama screen */ ./fvwm/fvwm.h: unsigned has_edge_resistance_xinerama_move : 1; ./fvwm/fvwm.h: int edge_resistance_xinerama_move; ./fvwm/fvwm.h: int edge_resistance_xinerama_move; ./fvwm/commands.h: F_XINERAMA, ./fvwm/commands.h: F_XINERAMAPRIMARYSCREEN, ./fvwm/commands.h: F_XINERAMASLS, ./fvwm/commands.h: F_XINERAMASLSSCREENS, ./fvwm/commands.h: F_XINERAMASLSSIZE, ./fvwm/commands.h:void CMD_Xinerama(F_CMD_ARGS); ./fvwm/commands.h:void CMD_XineramaPrimaryScreen(F_CMD_ARGS); ./fvwm/commands.h:void CMD_XineramaSls(F_CMD_ARGS); ./fvwm/commands.h:void CMD_XineramaSlsScreens(F_CMD_ARGS); ./fvwm/commands.h:void CMD_XineramaSlsSize(F_CMD_ARGS); ./fvwm/screen.h:unsigned has_xinerama_state_changed : 1; ./fvwm/module_interface.h:void broadcast_xinerama_state(void); ./fvwm/placement.c: * Xinerama screen. 1: The intuitive way giving a geometry ./fvwm/placement.c: * 2: Do NOT specify a Xinerama screen (or specify it to be ./fvwm/functable.c: /* - Move a window to another Xinerama screen */ ./fvwm/style.h:#define SGET_EDGE_RESISTANCE_XINERAMA_MOVE(s) \ ./fvwm/style.h: ((s).edge_resistance_xinerama_move) ./fvwm/style.h:#define SSET_EDGE_RESISTANCE_XINERAMA_MOVE(s,x) \ ./fvwm/style.h: ((s).edge_resistance_xinerama_move = (x)) ./fvwm/menuparameters.h:/* A position on the Xinerama screen on which the menu should be ./fvwm/menuparameters.h:/* A position on the Xineram
Re: Xinerama
On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote: > Is Xinerama still useful for anything or can we remove it? > It has already been removed. Where are you seeing references to it? Kindly, Thomas > >
Re: Xinerama/colour management, ideas please
On Thu, May 29, 2003 at 10:36:14PM +0200, Olivier Chapuis wrote: > On Thu, May 29, 2003 at 09:31:59PM +0200, [EMAIL PROTECTED] wrote: > > I have a problem with my Xinerama setup , but I do not know how to > > resolve it. I have two screens: the primary screen uses 24 > > bitplanes, and, due to lack of memory on the video card, the > > second screen has only 16 bitplanes. > > > > How this is possible? One fvwm run on two screens with different > depth! Outch ... I do not understand. What about running > your two screen with depth 16 (via your X config file) ;o) Works perfectly well. By the way, when I move the button bar to the second screen (the one with depth 16), look like they should. > > I have an FvwmIconMan swallowed in an FvwmButtons on the primary > > screen. The relevant portion of the config is this: > > > > Colorset 2 fg red, bg green > > *FvwmIconMan*FocusColorset 2 > > > > The problem is that the bg colour is completely ignored in the > > icon manager. Even if I change the colour later from an > > FvwmConsole, buttons lit in the icon manager always use a gray > > background. > > > > I think the problem comes from the fact that my screens have > > different depths. By the way, the same colour set works fine in > > all other modules and window decorations. Any input on this > > problem is welcome. > > > > Anyway, I will take a look. Thanks. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama/colour management, ideas please
On Thu, May 29, 2003 at 09:31:59PM +0200, [EMAIL PROTECTED] wrote: > I have a problem with my Xinerama setup , but I do not know how to > resolve it. I have two screens: the primary screen uses 24 > bitplanes, and, due to lack of memory on the video card, the > second screen has only 16 bitplanes. > How this is possible? One fvwm run on two screens with different depth! Outch ... I do not understand. What about running your two screen with depth 16 (via your X config file) ;o) > I have an FvwmIconMan swallowed in an FvwmButtons on the primary > screen. The relevant portion of the config is this: > > Colorset 2 fg red, bg green > *FvwmIconMan*FocusColorset 2 > > The problem is that the bg colour is completely ignored in the > icon manager. Even if I change the colour later from an > FvwmConsole, buttons lit in the icon manager always use a gray > background. > > I think the problem comes from the fact that my screens have > different depths. By the way, the same colour set works fine in > all other modules and window decorations. Any input on this > problem is welcome. > Anyway, I will take a look. Regards, Olivier -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: xinerama windowlist patch
On Thu, Feb 21, 2002 at 12:20:28PM +, Darren Marshall wrote: > Attached is a patch to fix a problem where clicking the mouse button to popup > the windowlist on the secondary screen of an xinerama setup always pops up on > the primary screen. I'll apply the patch shortly. Thanks for your help. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
Dominik Vogt <[EMAIL PROTECTED]> writes: > On Mon, Aug 20, 2001 at 08:05:14PM -0400, Dan Espen wrote: > > "Dmitry Yu. Bolkhovityanov" <[EMAIL PROTECTED]> writes: > > > On Mon, 20 Aug 2001, Dan Espen wrote: > > > > > > > Dominik Vogt writes: > > > > > Currently, fvwm uses the icon boxes in the order of creation. So, > > > > > if one icon box is created on screen 0 and one is created on > > > > > screen 1, all icons are placed on screen 0 until the icon box is > > > > > full, then all icons are put on screen 1. My question was if it > > > > > is necessary to skip icon boxes that are not on the same screen as > > > > > the window. > > > > > > > > I don't think we'd want to apply the same screen test unless the > > > > user indicated that the iconbox was for a specific screen. > > > > Right now, theres no way to do that. > > > > > > Would it be possible to remember the screen# together with > > > translated geometry? > > > > It can be saved, but what for? > > For recalculation of the icon boxes when the "Xinerama" command is > used. Let's assume Xinerama is enabled with two screens. Thanks, now I understand. I added the screen spec to the iconbox structure for the case when a geometry style spec is used, but the IconBox can also be defined in "l r t b" format. There are times when that format is required. I don't know what format you'd like to use in that case. I suppose just another string and pass it over to XineramaSupportParseScreenBit? Like: Style * Iconbox -80 240 -1 -1 g I didn't do anything but put the value in the structure. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
On Mon, Aug 20, 2001 at 08:05:14PM -0400, Dan Espen wrote: > "Dmitry Yu. Bolkhovityanov" <[EMAIL PROTECTED]> writes: > > On Mon, 20 Aug 2001, Dan Espen wrote: > > > > > Dominik Vogt writes: > > > > Currently, fvwm uses the icon boxes in the order of creation. So, > > > > if one icon box is created on screen 0 and one is created on > > > > screen 1, all icons are placed on screen 0 until the icon box is > > > > full, then all icons are put on screen 1. My question was if it > > > > is necessary to skip icon boxes that are not on the same screen as > > > > the window. > > > > > > I don't think we'd want to apply the same screen test unless the > > > user indicated that the iconbox was for a specific screen. > > > Right now, theres no way to do that. > > > > Would it be possible to remember the screen# together with > > translated geometry? > > It can be saved, but what for? For recalculation of the icon boxes when the "Xinerama" command is used. Let's assume Xinerama is enabled with two screens. Style * IconBox [EMAIL PROTECTED] puts the icon box at 0 0 of screen 1. Now, Xinerama off is issued. The @1 must now refer to the global screen since there are no more Xinerama screens. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
On Tue, Aug 21, 2001 at 08:57:20AM -0400, Dan Espen wrote: > Dominik Vogt writes: > > On Mon, Aug 20, 2001 at 09:45:11AM -0400, Dan Espen wrote: > > > Dominik Vogt writes: > > > > On Sun, Aug 19, 2001 at 06:45:32PM -0400, Dan Espen wrote: > > > > > Is there a way to test screen size changes without Xinerama working? > > > > > > > > With Xinerama emulation. Run configure with > > > > > > > > $ ./configure --enable-xinerama-emulation > > > > > > > > The screen is then split into two fake Xinerama screens and a > > > > blank area that doesn't belong to any screen. To switch > > > > Xinerama on and off just use > > > > > > > > Xinerama off > > > > > > > > or > > > > > > > > Xinerama on > > > > > > > > or > > > > > > > > Xinerama > > > > > > Hmm, none of these actually change where the icon box is. > > > I tried on, off, 0-3. > > > > Ah, I see. You moved the calculations from style.c to icons.c, > > but they still use the global screen dimensions. Instead, the > > specified screen has to be stored too. Then, one of the > > XineramaSupportGet...ScrRect() functions can be called in > > AutoPlaceIcon() to get the actual size and offset of the screen. > > Also, the call to XineramaSupportParseGeometry in style.c has to > > be changed to XineramaSupportParseGeometryWithScreen() so that the > > screen spec can be stored in the icon box (its a signed integer). > > > > When this is completed, the following should work: > > > > Xinerama 1 > > Style * iconbox 100x100-0-0 > > Next iconify > > # iconifies on screen 1 > > Xinerama 0 > > Next iconify > > # iconifies on screen 0 > > Xinerama off > > Next iconify > > # iconifies on global screen > > Yes, I saw how XineramaSupportParseGeometryWithScreen > is needed to get the screen number, but I still don't see > how the screen number is going to be used. Is it needed > by the Iconify command? No. Somewhere in icons.c the actual position and size of the icon boxes is calculated. To do this, the global screen dimensions and position (0 0) are used. These values have to be replaced with the screen dimensions of the Xinerama screen that is to be used. All this has to be done every time the Xinerama command is called. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
Dominik Vogt writes: > On Mon, Aug 20, 2001 at 09:45:11AM -0400, Dan Espen wrote: > > Dominik Vogt writes: > > > On Sun, Aug 19, 2001 at 06:45:32PM -0400, Dan Espen wrote: > > > > Is there a way to test screen size changes without Xinerama working? > > > > > > With Xinerama emulation. Run configure with > > > > > > $ ./configure --enable-xinerama-emulation > > > > > > The screen is then split into two fake Xinerama screens and a > > > blank area that doesn't belong to any screen. To switch > > > Xinerama on and off just use > > > > > > Xinerama off > > > > > > or > > > > > > Xinerama on > > > > > > or > > > > > > Xinerama > > > > Hmm, none of these actually change where the icon box is. > > I tried on, off, 0-3. > > Ah, I see. You moved the calculations from style.c to icons.c, > but they still use the global screen dimensions. Instead, the > specified screen has to be stored too. Then, one of the > XineramaSupportGet...ScrRect() functions can be called in > AutoPlaceIcon() to get the actual size and offset of the screen. > Also, the call to XineramaSupportParseGeometry in style.c has to > be changed to XineramaSupportParseGeometryWithScreen() so that the > screen spec can be stored in the icon box (its a signed integer). > > When this is completed, the following should work: > > Xinerama 1 > Style * iconbox 100x100-0-0 > Next iconify > # iconifies on screen 1 > Xinerama 0 > Next iconify > # iconifies on screen 0 > Xinerama off > Next iconify > # iconifies on global screen Yes, I saw how XineramaSupportParseGeometryWithScreen is needed to get the screen number, but I still don't see how the screen number is going to be used. Is it needed by the Iconify command? -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
On Mon, Aug 20, 2001 at 09:45:11AM -0400, Dan Espen wrote: > Dominik Vogt writes: > > On Sun, Aug 19, 2001 at 06:45:32PM -0400, Dan Espen wrote: > > > Is there a way to test screen size changes without Xinerama working? > > > > With Xinerama emulation. Run configure with > > > > $ ./configure --enable-xinerama-emulation > > > > The screen is then split into two fake Xinerama screens and a > > blank area that doesn't belong to any screen. To switch > > Xinerama on and off just use > > > > Xinerama off > > > > or > > > > Xinerama on > > > > or > > > > Xinerama > > Hmm, none of these actually change where the icon box is. > I tried on, off, 0-3. Ah, I see. You moved the calculations from style.c to icons.c, but they still use the global screen dimensions. Instead, the specified screen has to be stored too. Then, one of the XineramaSupportGet...ScrRect() functions can be called in AutoPlaceIcon() to get the actual size and offset of the screen. Also, the call to XineramaSupportParseGeometry in style.c has to be changed to XineramaSupportParseGeometryWithScreen() so that the screen spec can be stored in the icon box (its a signed integer). When this is completed, the following should work: Xinerama 1 Style * iconbox 100x100-0-0 Next iconify # iconifies on screen 1 Xinerama 0 Next iconify # iconifies on screen 0 Xinerama off Next iconify # iconifies on global screen Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
"Dmitry Yu. Bolkhovityanov" <[EMAIL PROTECTED]> writes: > On Mon, 20 Aug 2001, Dan Espen wrote: > > > Dominik Vogt writes: > > > Currently, fvwm uses the icon boxes in the order of creation. So, > > > if one icon box is created on screen 0 and one is created on > > > screen 1, all icons are placed on screen 0 until the icon box is > > > full, then all icons are put on screen 1. My question was if it > > > is necessary to skip icon boxes that are not on the same screen as > > > the window. > > > > I don't think we'd want to apply the same screen test unless the > > user indicated that the iconbox was for a specific screen. > > Right now, theres no way to do that. > > Would it be possible to remember the screen# together with > translated geometry? It can be saved, but what for? -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
Dominik Vogt writes: > On Mon, Aug 20, 2001 at 09:45:11AM -0400, Dan Espen wrote: > > Dominik Vogt writes: > > > On Sun, Aug 19, 2001 at 06:45:32PM -0400, Dan Espen wrote: > > > > Is there a way to test screen size changes without Xinerama working? > > > > > > With Xinerama emulation. Run configure with ... > > Hmm, none of these actually change where the icon box is. > > I tried on, off, 0-3. > > I don't know if you did this, but I only made the X geometry like > syntax work with screens. The other syntax still addresses the > global screen if you did not write this. Try > > Style * IconBox [EMAIL PROTECTED] Neat. Issuing the Style command moves the icons around. It looks good to me. The man page needs work. > > I'm not sure if they should. I sort of thought if I had > > "on" followed by "0", it might use the smaller box on the left > > as the primary screen but it didn't seem to do that. > > The proper syntax is > > Xinerama 3 > not > Xinerama on 3 I meant to say, I issued: Xinerama on Xinerama 0 > I guess this should be changed anyway since it interferes with the > parsing of 0/1 values of the bool argument. My biggest problem is spelling the command. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
On Mon, Aug 20, 2001 at 09:45:11AM -0400, Dan Espen wrote: > Dominik Vogt writes: > > On Sun, Aug 19, 2001 at 06:45:32PM -0400, Dan Espen wrote: > > > Is there a way to test screen size changes without Xinerama working? > > > > With Xinerama emulation. Run configure with > > > > $ ./configure --enable-xinerama-emulation > > > > The screen is then split into two fake Xinerama screens and a > > blank area that doesn't belong to any screen. To switch > > Xinerama on and off just use > > > > Xinerama off > > > > or > > > > Xinerama on > > > > or > > > > Xinerama > > Hmm, none of these actually change where the icon box is. > I tried on, off, 0-3. I don't know if you did this, but I only made the X geometry like syntax work with screens. The other syntax still addresses the global screen if you did not write this. Try Style * IconBox [EMAIL PROTECTED] > I'm not sure if they should. I sort of thought if I had > "on" followed by "0", it might use the smaller box on the left > as the primary screen but it didn't seem to do that. The proper syntax is Xinerama 3 not Xinerama on 3 I guess this should be changed anyway since it interferes with the paring of 0/1 values of the bool argument. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
On Mon, 20 Aug 2001, Dan Espen wrote:
> Dominik Vogt writes:
> > Currently, fvwm uses the icon boxes in the order of creation. So,
> > if one icon box is created on screen 0 and one is created on
> > screen 1, all icons are placed on screen 0 until the icon box is
> > full, then all icons are put on screen 1. My question was if it
> > is necessary to skip icon boxes that are not on the same screen as
> > the window.
>
> I don't think we'd want to apply the same screen test unless the
> user indicated that the iconbox was for a specific screen.
> Right now, theres no way to do that.
Would it be possible to remember the screen# together with
translated geometry?
> I don't think that just because the iconbox lies completely within
> a screen is sufficient reason to only use it for one screen.
>
> Since I don't have a setup, I can only guess, but my guess is
> that we don't need a iconbox for each screen feature.
Well, maybe not "iconbox for each screen", but "iconify on the
same screen". It seems most natural that windows iconify on the same
screen where they are.
A possible way to achieve this behaviour is to define a "floating"
iconbox: i.e. "IconBox -80x200-1-1" will create an iconbox which will be
treated as "@w" ("w" is "window's current screen"). Not sure about
implementation details, though -- I'm speaking of this mainly as a user of
several multiheaded machines.
BTW, there's a little problem with specifying iconboxes separately
for each screen: this is okay for a static configuration, but what about
an XDM server which works for several different-headed machines? So
there's a need in a single command to bind iconboxes to all screens.
I have yet to test the latest CVS, so sorry if everything is
already done.
_
Dmitry Yu. Bolkhovityanov
[EMAIL PROTECTED]
The Budker Institute of Nuclear Physics
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
Dominik Vogt writes: > Currently, fvwm uses the icon boxes in the order of creation. So, > if one icon box is created on screen 0 and one is created on > screen 1, all icons are placed on screen 0 until the icon box is > full, then all icons are put on screen 1. My question was if it > is necessary to skip icon boxes that are not on the same screen as > the window. I don't think we'd want to apply the same screen test unless the user indicated that the iconbox was for a specific screen. Right now, theres no way to do that. I don't think that just because the iconbox lies completely within a screen is sufficient reason to only use it for one screen. Since I don't have a setup, I can only guess, but my guess is that we don't need a iconbox for each screen feature. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
Dominik Vogt writes: > On Sun, Aug 19, 2001 at 06:45:32PM -0400, Dan Espen wrote: > > Is there a way to test screen size changes without Xinerama working? > > With Xinerama emulation. Run configure with > > $ ./configure --enable-xinerama-emulation > > The screen is then split into two fake Xinerama screens and a > blank area that doesn't belong to any screen. To switch > Xinerama on and off just use > > Xinerama off > > or > > Xinerama on > > or > > Xinerama Hmm, none of these actually change where the icon box is. I tried on, off, 0-3. I'm not sure if they should. I sort of thought if I had "on" followed by "0", it might use the smaller box on the left as the primary screen but it didn't seem to do that. It must be pretty neat to watch FvwmAnimate draw lines from one screen to another. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
On Mon, Aug 20, 2001 at 04:19:19PM +0700, Dmitry Yu. Bolkhovityanov wrote: > On Mon, 20 Aug 2001, Dominik Vogt wrote: > > > On Sun, Aug 19, 2001 at 07:35:15PM -0400, Dan Espen wrote: > > > Dominik Vogt <[EMAIL PROTECTED]> writes: > > > > Dan, I looked at the icon box code in style.c because I wanted to > > > > make it work with changes of the Xinerama state, but the matter is > > > > too complex to write a patch in short time for me. > > > > > > > > What I want to do: > > > > > > > > 1) Default to using the primary screen for icon box specs > > > > (already works for X geometry like specs and is easy to do for > > > > the other syntax). > > > > 2) Recalculate all icon boxes when the Xinerama layout of the > > > > screen changes (switched on or off). > > > > > > > > The difficult part is (2) because all the calculations are done > > > > when the style is defined. The precise spec string is thrown away > > > > afterwards. So doing this requires to remove the calculations > > > > from style.c and do them somewhere is icons.c. Can you take a > > > > look at this, please? I think this could wait until after 2.4.1. > > > > > > Done. You may want to test this on a system that supports > > > Xinerama. I tested it with: > > > > > > Style "*" IconBox -80 240 -1 -1, IconGrid 80 67, \ > > > IconBox 1040x20+0-40, IconGrid 80 80, IconFill r t > > > > > > which tests both formats and some negative coordinates. > > > > Great! I am still unsure about a few things that could be done: > > > > - Should each screen have a default icon box? > > Yes. The natural way is to place icon on the same screen where > the window is. > > - Should icons always be placed in an icon box that overlaps the > >window's screen first? > > Can you please explain what you mean by that? Currently, fvwm uses the icon boxes in the order of creation. So, if one icon box is created on screen 0 and one is created on screen 1, all icons are placed on screen 0 until the icon box is full, then all icons are put on screen 1. My question was if it is necessary to skip icon boxes that are not on the same screen as the window. > > - Is it worthwhile to prevent icons from being placed between > >screens if the icon box spans the whole desktop? (I guess not). > > Agreed. If the user makes a "global" iconbox, his choice should > be obeyed. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
On Mon, 20 Aug 2001, Dominik Vogt wrote: > On Sun, Aug 19, 2001 at 07:35:15PM -0400, Dan Espen wrote: > > Dominik Vogt <[EMAIL PROTECTED]> writes: > > > Dan, I looked at the icon box code in style.c because I wanted to > > > make it work with changes of the Xinerama state, but the matter is > > > too complex to write a patch in short time for me. > > > > > > What I want to do: > > > > > > 1) Default to using the primary screen for icon box specs > > > (already works for X geometry like specs and is easy to do for > > > the other syntax). > > > 2) Recalculate all icon boxes when the Xinerama layout of the > > > screen changes (switched on or off). > > > > > > The difficult part is (2) because all the calculations are done > > > when the style is defined. The precise spec string is thrown away > > > afterwards. So doing this requires to remove the calculations > > > from style.c and do them somewhere is icons.c. Can you take a > > > look at this, please? I think this could wait until after 2.4.1. > > > > Done. You may want to test this on a system that supports > > Xinerama. I tested it with: > > > > Style "*" IconBox -80 240 -1 -1, IconGrid 80 67, \ > > IconBox 1040x20+0-40, IconGrid 80 80, IconFill r t > > > > which tests both formats and some negative coordinates. > > Great! I am still unsure about a few things that could be done: > > - Should each screen have a default icon box? Yes. The natural way is to place icon on the same screen where the window is. > - Should icons always be placed in an icon box that overlaps the >window's screen first? Can you please explain what you mean by that? > - Is it worthwhile to prevent icons from being placed between >screens if the icon box spans the whole desktop? (I guess not). Agreed. If the user makes a "global" iconbox, his choice should be obeyed. _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
On Sun, Aug 19, 2001 at 07:35:15PM -0400, Dan Espen wrote: > Dominik Vogt <[EMAIL PROTECTED]> writes: > > Dan, I looked at the icon box code in style.c because I wanted to > > make it work with changes of the Xinerama state, but the matter is > > too complex to write a patch in short time for me. > > > > What I want to do: > > > > 1) Default to using the primary screen for icon box specs > > (already works for X geometry like specs and is easy to do for > > the other syntax). > > 2) Recalculate all icon boxes when the Xinerama layout of the > > screen changes (switched on or off). > > > > The difficult part is (2) because all the calculations are done > > when the style is defined. The precise spec string is thrown away > > afterwards. So doing this requires to remove the calculations > > from style.c and do them somewhere is icons.c. Can you take a > > look at this, please? I think this could wait until after 2.4.1. > > Done. You may want to test this on a system that supports > Xinerama. I tested it with: > > Style "*" IconBox -80 240 -1 -1, IconGrid 80 67, \ > IconBox 1040x20+0-40, IconGrid 80 80, IconFill r t > > which tests both formats and some negative coordinates. Great! I am still unsure about a few things that could be done: - Should each screen have a default icon box? - Should icons always be placed in an icon box that overlaps the window's screen first? - Is it worthwhile to prevent icons from being placed between screens if the icon box spans the whole desktop? (I guess not). I already wrote the code to update the icon boxes when the Xinerama layout changes, but it needs yet to be tested. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
On Sun, Aug 19, 2001 at 06:45:32PM -0400, Dan Espen wrote: > Dominik Vogt <[EMAIL PROTECTED]> writes: > > Dan, I looked at the icon box code in style.c because I wanted to > > make it work with changes of the Xinerama state, but the matter is > > too complex to write a patch in short time for me. > > > > What I want to do: > > > > 1) Default to using the primary screen for icon box specs > > (already works for X geometry like specs and is easy to do for > > the other syntax). > > 2) Recalculate all icon boxes when the Xinerama layout of the > > screen changes (switched on or off). > > > > The difficult part is (2) because all the calculations are done > > when the style is defined. The precise spec string is thrown away > > afterwards. So doing this requires to remove the calculations > > from style.c and do them somewhere is icons.c. Can you take a > > look at this, please? I think this could wait until after 2.4.1. > > It doesn't look too hard, it just needs to save the signs separately > (for -0) and apply screen dimensions later. > > Is there a way to test screen size changes without Xinerama working? With Xinerama emulation. Run configure with $ ./configure --enable-xinerama-emulation The screen is then split into two fake Xinerama screens and a blank area that doesn't belong to any screen. To switch Xinerama on and off just use Xinerama off or Xinerama on or Xinerama Currently this only allows to switch the emulation on and off, not to change the Xinerama layout. Also, it is done for fvwm and all modules, which is inefficient and a bit confusing during startup. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
Dominik Vogt <[EMAIL PROTECTED]> writes: > Dan, I looked at the icon box code in style.c because I wanted to > make it work with changes of the Xinerama state, but the matter is > too complex to write a patch in short time for me. > > What I want to do: > > 1) Default to using the primary screen for icon box specs > (already works for X geometry like specs and is easy to do for > the other syntax). > 2) Recalculate all icon boxes when the Xinerama layout of the > screen changes (switched on or off). > > The difficult part is (2) because all the calculations are done > when the style is defined. The precise spec string is thrown away > afterwards. So doing this requires to remove the calculations > from style.c and do them somewhere is icons.c. Can you take a > look at this, please? I think this could wait until after 2.4.1. Done. You may want to test this on a system that supports Xinerama. I tested it with: Style "*" IconBox -80 240 -1 -1, IconGrid 80 67, \ IconBox 1040x20+0-40, IconGrid 80 80, IconFill r t which tests both formats and some negative coordinates. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
Oops, ignore that comment about XineramaSupportGetNumberedScrRect. -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama support for IconBox style?
Dominik Vogt <[EMAIL PROTECTED]> writes: > Dan, I looked at the icon box code in style.c because I wanted to > make it work with changes of the Xinerama state, but the matter is > too complex to write a patch in short time for me. > > What I want to do: > > 1) Default to using the primary screen for icon box specs > (already works for X geometry like specs and is easy to do for > the other syntax). > 2) Recalculate all icon boxes when the Xinerama layout of the > screen changes (switched on or off). > > The difficult part is (2) because all the calculations are done > when the style is defined. The precise spec string is thrown away > afterwards. So doing this requires to remove the calculations > from style.c and do them somewhere is icons.c. Can you take a > look at this, please? I think this could wait until after 2.4.1. It doesn't look too hard, it just needs to save the signs separately (for -0) and apply screen dimensions later. Is there a way to test screen size changes without Xinerama working? I did a CVS update, now I have this: Undefined first referenced symbol in file XineramaSupportGetNumberedScrRect placement.o -- Dan Espen 444 Hoes Lane Room RRC 1C-214 E-mail: [EMAIL PROTECTED] Piscataway, NJ 08854 Phone: (732) 699-5570 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama patch for "Maximize"
On Sat, Aug 18, 2001 at 06:59:56PM +0700, Dmitry Yu. Bolkhovityanov wrote:
> On Fri, 17 Aug 2001, Dominik Vogt wrote:
>
> > On Fri, Aug 17, 2001 at 11:46:45AM +0700, Dmitry Yu. Bolkhovityanov wrote:
> > > On Thu, 16 Aug 2001, Dominik Vogt wrote:
> > >
> > > > On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov
> > > > wrote:
> > > > >
> > > > > I've added an optional "global" switch, which means that
> > > > > maximization should be made on a global screen, otherwise it is made
> > > > > on
> > > > > the screen where the center of a window is. "grow*" are also adjusted
> > > > > (that turned to be the easiest part of the task).
> > > >
> > > > I have been thinking about an entirely different approach that
> > > > uses XGeometry specs:
> > > >
> > > > Maximize on [EMAIL PROTECTED]
> > > >
> > > > The problem here is to specify the resize unit (screen % or
> > > > pixels) and where to place the "grow" option. The same syntax
> > > > could be used for the Move, Resize and ResizeMove commands.
> > >
> > > IMHO these two approaches aren't contradictory
> >
> > That's true, but I don't think we would want to develop a
> > second syntax. My idea was to support maximizing/moving/resizing
> > only with the new, X geometry like syntax and phase out the old
> > one.
>
> Okay, but there are two issues.
>
> First, while the geometry syntax is "mathematically" okay, it is
> just too complicated (messy?) for an ordinary user -- like a Perl program
> for a person which knows only Pascal. I don't want to say that users are
> silly, but "640pxgrow-5+0p" is a bit too much.
Well, the ordinary user would not use that syntax at all but stick
with
Maximize on
Maximize on 100 0
Maximize on 0 100
Anyway, as nice as a common syntax for all the resizing/moving
commands would be, its not the proper time to do this.
> BTW, this syntax employs latin letters for three different uses:
> 1) unit size ("p"); 2) keywords ("grow"); 3) times/multiplication operator
> ("x"); and all these go without any separators. While this is definitely
> parseable, it isn't very fancy and is too error-prone.
Yes, and my X11 book says: "If the [parse]string is not in Host
Portable Character Encoding, the result is
implementation-dependent."
> Anyway, can you please post a formal definition of new syntax,
> like a BNF?
No, I can't. I don't even know the correct definition of the
standard X11 geometry spec.
> Sorry for only criticizing, but I yet have to find out some
> reasonable suggestions.
Let's skip my idea for now and update the old syntax.
> Second, due to compatibility reasons, the old syntax should still
> be supported.
Of course. I only though about not writing new features for the
old syntax.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama patch for "Maximize"
On Fri, 17 Aug 2001, Dominik Vogt wrote:
> On Fri, Aug 17, 2001 at 11:46:45AM +0700, Dmitry Yu. Bolkhovityanov wrote:
> > On Thu, 16 Aug 2001, Dominik Vogt wrote:
> >
> > > On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote:
> > > >
> > > > I've added an optional "global" switch, which means that
> > > > maximization should be made on a global screen, otherwise it is made on
> > > > the screen where the center of a window is. "grow*" are also adjusted
> > > > (that turned to be the easiest part of the task).
> > >
> > > I have been thinking about an entirely different approach that
> > > uses XGeometry specs:
> > >
> > > Maximize on [EMAIL PROTECTED]
> > >
> > > The problem here is to specify the resize unit (screen % or
> > > pixels) and where to place the "grow" option. The same syntax
> > > could be used for the Move, Resize and ResizeMove commands.
> >
> > IMHO these two approaches aren't contradictory
>
> That's true, but I don't think we would want to develop a
> second syntax. My idea was to support maximizing/moving/resizing
> only with the new, X geometry like syntax and phase out the old
> one.
Okay, but there are two issues.
First, while the geometry syntax is "mathematically" okay, it is
just too complicated (messy?) for an ordinary user -- like a Perl program
for a person which knows only Pascal. I don't want to say that users are
silly, but "640pxgrow-5+0p" is a bit too much.
BTW, this syntax employs latin letters for three different uses:
1) unit size ("p"); 2) keywords ("grow"); 3) times/multiplication operator
("x"); and all these go without any separators. While this is definitely
parseable, it isn't very fancy and is too error-prone.
Anyway, can you please post a formal definition of new syntax,
like a BNF?
Sorry for only criticizing, but I yet have to find out some
reasonable suggestions.
Second, due to compatibility reasons, the old syntax should still
be supported. Otherwise most users of <=2.4 (especially those with 1
monitor) will live with old versions, and in some cases even
fvwmNN_convert wouldn't be able to help them (think about AnotherLevel and
alikes).
_
Dmitry Yu. Bolkhovityanov
[EMAIL PROTECTED]
The Budker Institute of Nuclear Physics
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama patch for "Maximize"
On Fri, Aug 17, 2001 at 11:46:45AM +0700, Dmitry Yu. Bolkhovityanov wrote: > On Thu, 16 Aug 2001, Dominik Vogt wrote: > > > On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: > > > > > > I've added an optional "global" switch, which means that > > > maximization should be made on a global screen, otherwise it is made on > > > the screen where the center of a window is. "grow*" are also adjusted > > > (that turned to be the easiest part of the task). > > > > I have been thinking about an entirely different approach that > > uses XGeometry specs: > > > > Maximize on [EMAIL PROTECTED] > > > > The problem here is to specify the resize unit (screen % or > > pixels) and where to place the "grow" option. The same syntax > > could be used for the Move, Resize and ResizeMove commands. > > IMHO these two approaches aren't contradictory That's true, but I don't think we would want to develop a second syntax. My idea was to support maximizing/moving/resizing only with the new, X geometry like syntax and phase out the old one. > -- yours allows > more flexibility, while the logic im my patch is required in case when no > parameters are specified (i.e. just "Maximize") or the old syntax is used > (incl. e.g. "grow"). But, of course, with some efforts old syntax parser > can be changed to generate an appropriate "on" geometry spec. Basically, the parser would have to do the same as the non geometry based dimension/position parsers we have. For each bit of the geometry spec it should optionally accept a suffix to the number, e.g. 100px100p+0m+0m, and possibly a list of key words. This way it would finally possible to have something like this: Maximize 640pxgrow-5+0p (maximized window is placed 5% of the screen width off the right border and ant the top of the screen with a width of 640 pixels and whatever height fits). Of course this requires a pre parsing pass over the geometry string that filters out all the fancy suffices and key words before calling ...ParseGeometry. int FancyParseGeometry( char *geom, int *ret_x, int *ret_y, int *ret_w, int *ret_h, char *xy_suffix_array, int *xy_units_array, char **xy_keywords, int *ret_x_unit, int *ret_y_unit, char *wh_suffix_array, int *wh_units_array, char **wy_keywords, int *ret_w_unit, int *ret_h_unit, int *ret_w_keyword, int *ret_h_keyword); Pretty complex I guess, but very useful. > There's a pitfall in geometry syntax for Maximize: what would > mean "Maximize [EMAIL PROTECTED]" if applied to a window on different > page/desk? > Would it be current screen where the *pointer* is, or the screen, where > that *window* is (more precisely, where it *would* be when "Focus" > applied)? And what to do in case when current page doesn't start on a > page boundary? As usual, @c would address the screen that contains the pointer, possibly projected to other pages or desks. To force the window into the current viewport, the MoveToDesk/Page/Screen commands can be used. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama patch for "Maximize"
On Thu, 16 Aug 2001, Dominik Vogt wrote: > On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: > > > > I've added an optional "global" switch, which means that > > maximization should be made on a global screen, otherwise it is made on > > the screen where the center of a window is. "grow*" are also adjusted > > (that turned to be the easiest part of the task). > > I have been thinking about an entirely different approach that > uses XGeometry specs: > > Maximize on [EMAIL PROTECTED] > > The problem here is to specify the resize unit (screen % or > pixels) and where to place the "grow" option. The same syntax > could be used for the Move, Resize and ResizeMove commands. IMHO these two approaches aren't contradictory -- yours allows more flexibility, while the logic im my patch is required in case when no parameters are specified (i.e. just "Maximize") or the old syntax is used (incl. e.g. "grow"). But, of course, with some efforts old syntax parser can be changed to generate an appropriate "on" geometry spec. There's a pitfall in geometry syntax for Maximize: what would mean "Maximize [EMAIL PROTECTED]" if applied to a window on different page/desk? Would it be current screen where the *pointer* is, or the screen, where that *window* is (more precisely, where it *would* be when "Focus" applied)? And what to do in case when current page doesn't start on a page boundary? _ Dmitry Yu. Bolkhovityanov [EMAIL PROTECTED] The Budker Institute of Nuclear Physics -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama patch for "Maximize"
On Wed, Aug 15, 2001 at 08:30:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: > Hi! > > This patch touches solely the move_resize.c. I've tried to modify > fvwm2.1, but my roff skills seem to be below what required to keep > "Maximize" description in the same style (the latter seems a bit wrong BTW > -- too many spaces). > > I've added an optional "global" switch, which means that > maximization should be made on a global screen, otherwise it is made on > the screen where the center of a window is. "grow*" are also adjusted > (that turned to be the easiest part of the task). I have been thinking about an entirely different approach that uses XGeometry specs: Maximize on [EMAIL PROTECTED] The problem here is to specify the resize unit (screen % or pixels) and where to place the "grow" option. The same syntax could be used for the Move, Resize and ResizeMove commands. > There are some problems with maximizing windows that aren't on the > current page when the page itself doesn't start on a page boundary, but > that effect existed before anyway. I see. Consider it fixed :) > And there is a comment "maximize on visible page" after > IsRectangleOnThisPage() check, which doesn't seem to be correct -- somehow > it happens that windows are maximized on visible page even if they are by > some part (not entirely) on it. The comment should better read: maximize on the page where the center of the window is, but if any part of the window is on the current page, maximize it there. > BTW, Dominik, was it done intentionally that in Xinerama emulation mode > the vertical separator doesn't separate, but in fact overlaps two > left pixels of the second pseudo-screen? The result seems a bit > confusing ;-) You would have to ask Olivier. He wrote that stuff. Anyway, I don't really care about this. It is only meant as visible feedback for testing and debugging. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama merger -- part 1
On 28 Jul 01 at 18:15, [EMAIL PROTECTED] wrote: [SNIP] > > The point is not cleaning the code, but a correct operation of modules > > -- > > do you need a pager on non-primary screen? > > I don't quit understand the question. Of course I'd usually > prefer the pager on the primary screen, but perhaps I wnat one on > both screens. What I meant is that introducing Xinerama support into fvwm2 binary, but leaving modules still use XParseGeometry() is inconsistent -- the pieces of code responsible for window's placement should be modified too (sorry for my not-so-perfect english ;-). Otherwise in the case of the following layout: +--++ | 1024 |800 | | 768 |600 | | ++ +--+ too many things will tend to place themselves into the void. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama merger -- part 1
On Sun, Jul 29, 2001 at 02:13:56PM +0700, Dmitry Yu. Bolkhovityanov wrote: > On 28 Jul 01 at 18:15, [EMAIL PROTECTED] wrote: > > [SNIP] > > > The point is not cleaning the code, but a correct operation of > > > modules -- > > > do you need a pager on non-primary screen? > > > > I don't quit understand the question. Of course I'd usually > > prefer the pager on the primary screen, but perhaps I wnat one on > > both screens. > > What I meant is that introducing Xinerama support into fvwm2 binary, but > leaving modules still use XParseGeometry() is inconsistent -- the pieces of > code responsible for window's placement should be modified too (sorry for my > not-so-perfect english ;-). Otherwise in the case of the following layout: > > +--++ > | 1024 |800 | > | 768 |600 | > | ++ > +--+ > > too many things will tend to place themselves into the void. Ah, yes, of course. I did not think about this. Bye Dominik ^_^ ^_^ P.S.: Please keep the discussion on the workers list. -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama w/ EdgeResistance problem
On Sun, Jul 29, 2001 at 02:07:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: > On 28 Jul 01 at 18:00, [EMAIL PROTECTED] wrote: > > > There is a problem with Xinerama Edgeresistance and different > > screen sizes on the screens: > > > > Layout: > > > > screen 1 screen 2 > > +--++ > > | |+--+| > > | || || > > | ||window|| > > | || || > > +--+| || > > |+--+| > > || > > ++ > > > > When you move a window that is taller than screen 1 along the top > > edge of screen 2 and finally move it against or over the border > > between the screens it will then snap to the bottom border of > > screen 1: > > > > +--+ > > +--| |-+ > > | | | | > > | | | | > > | | | | > > | +--+ | > > +--+| > > || > > || > > ++ > > > > This can be very confusing, especially if the pointer is still on > > the second screen. One way to handle this may be to snap only to > > the screen that contains the pointer (?) > > There's no such thing as "the decision" for this problem. Some people > will prefer current behaviour, while some -- current-pointer-screen-based one > you suggest. IMHO the current bahaviour can be left as is to watch feedback > after 2.4.1 release. > > EdgeResistance is a non-trivial concept on itself (remember what happens > to windows with e.g. width>screen_width && width and when combined with even more non-trivial concept of Xinerama, it can > really confuse people (they wouldn't know themselves what they want fvwm to > do). I think it's easy to describe what the average user wants: When (s)he move the window to the left (s)he expects that the left edge of the window will be aligned with the left edge of the screen respectively the right edge of other windows. It would also be desirable that a previous alignment with the top/bottom edges is not broken while moving to the left. But (s)he would definitely not expect to align window on the right side. The same applies to all other directions, of course. The problem is that fvwm usually can't guess in which direction the user wants to move a window and mouse input is way too unreliable. At present I am using big values for SnapAttraction (20), SnapGrid (8 8) and EdgeResistance (128) for a screen with quite a few windows and it often causes trouble. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama w/ EdgeResistance problem
On 28 Jul 01 at 18:00, [EMAIL PROTECTED] wrote: > There is a problem with Xinerama Edgeresistance and different > screen sizes on the screens: > > Layout: > > screen 1 screen 2 > +--++ > | |+--+| > | || || > | ||window|| > | || || > +--+| || > |+--+| > || > ++ > > When you move a window that is taller than screen 1 along the top > edge of screen 2 and finally move it against or over the border > between the screens it will then snap to the bottom border of > screen 1: > > +--+ > +--| |-+ > | | | | > | | | | > | | | | > | +--+ | > +--+| > || > || > ++ > > This can be very confusing, especially if the pointer is still on > the second screen. One way to handle this may be to snap only to > the screen that contains the pointer (?) There's no such thing as "the decision" for this problem. Some people will prefer current behaviour, while some -- current-pointer-screen-based one you suggest. IMHO the current bahaviour can be left as is to watch feedback after 2.4.1 release. EdgeResistance is a non-trivial concept on itself (remember what happens to windows with e.g. width>screen_width && widthhttp://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama merger -- part 1
On 28 Jul 01 at 13:07, [EMAIL PROTECTED] wrote:
> > > - Please keep in mind that that fvwm is controlled and configured
> > >by configuration commands, not by environment variables. It's
> > >not necessary to make features configurable via the
> > >environment. (I'll remove the corresponding code).
> >
> > As to this point, one reason was an ability to pass these parameters to
> > modules (so that they will automatically be inherited via environment), and
> > another is that some other proggies can theoritically use XiSupp.c (think
> > about XMMS and various toolkits) or a similar thing, and they have no
> > standard means of communicating to FVWM.
>
> Ah, okay. The solution to both problems is the module interface.
> Some settings like "Colorset" are communicated to the modules over
> the module pipe. The state of Xinerama{En,Dis}abled can be easily
> communicated too. In fact I have already done this. Take a look
> at the code in virtual.c:
>
> void CMD_XineramaDisable(F_CMD_ARGS)
> {
> XineramaSupportDisable();
> BroadcastConfigInfoString("XineramaDisable");
> }
>
> Any module listening for M_CONFIG_INFO packets will receive the
> string "XineramaDisable" when the function is called an can react
> properly. I think I still forgot to send this string when the
> module is initially started, so the module's Xinerama state may
> not match fvwm's state at first. I will take care of this.
>
> Any program that wants to communicate to fvwm tightly should be
> written as an fvwm module. Another way would be to communicate
> via FvwmCommand, but that is inefficient and littl internal
> information about fvwm's state it communicated this way.
>
> > Sure, modules interface can (and should?) be extended to accept
> > PrimaryScreen change, but this is mostly irrelevant -- primary screen is
> > usually taken into account only at startup.
The problem of other programs remain -- they should *not* communicate to
fvwm, they should work with *any* WM. In fact, the problem here is lack
of X.org specification. IMHO the natural way will be to use a root window
property -- like _XINERAMA_PRIMARY_SCREEN. In that case any program could
request notification of property's change. This isn't urgent, but AFAIK
nobody have done something in this area yet, so if we do, this can become a
standard.
[SNIP]
> > > - RandR support will certainly be no part of 2.4.1. You should
> > >really try to split the patches you made on your disk into
> > >several patch files that can be applied individually.
> >
> > Well, the RandR support can be at the same position as multibyte
> > support -
> > it is present but switched off by default. When HAS_RANDR is undefined,
> > RandR will have no effect at all -- nothing will be queried in XiSupp.c, and
> > no RandR handlers will be called in events.c and FvwmPager.c.
> >
> > I added RandR support as an additional step forward -- it enables to
> > understand which currently used concepts will become obsolete in some near
> > future, and what should be changed for more flexibility. That was the main
> > goal, not an ability to use resize feature of yet very rarely used KDrive.
> > ;-)
>
> Let me explain why I commented it (actually, commenting it made a
> huge, big mess of XineramaSupport.c): The risk that new problems
> are introduced in the *stable* 2.4.1 release has to be minimised.
Can you please explain about a mess? If I did something too interveawed
with other code, I need to know :-).
> > > One question about the XiParseGeometry function: I don't
> > > understand why is does so many things. It really shouldn't do
> > > more than just parsing the geometry string like XParseGeometry
> > > does and use the same signature. I'll comment out all the extra
> > > stuff for now.
> >
> > The answer is that modules do way too many calculations themselves
> > (negative handling, gravity selection, etc.). Much of them are duplicates,
> > and with submitted XiParseGeometry() modules become much simpler -- you add
> > one/two lines and remove sometimes several dozens (look at patches for
> > modules).
> >
> > Well, maybe XiParseGeometry is not a very appropriate name, in fact what
> > this function does is very similar to XWMGeometry.
>
> Well, then let's split up the function. XiParseGeometry() does
> exactly what XParseGeometry() does but with the additional
> "@" parsing. Another function could take its output as
> input and do the additional calculations. Or if that won't work,
> there should at least be an alias of the function that can be
> called like XParseGeometry().
Okay, lets do int XiParseGeometry(char *str, int *{x,y,w,h,scr}) and
XiGetGeometry(), which will do the actual calculations. The thing is that
"screen" parameter is not very useful outside XineramaSupport.c, since list
of screens shouldn't be visible outside.
The patch is attached (I'm very-very sorry for uppercase, that's my
Pegasus Ma
Re: Xinerama merger -- part 1
On Sat, Jul 28, 2001 at 09:42:42PM +0700, Dmitry Yu. Bolkhovityanov wrote:
Content-Description: Mail message body
> On 28 Jul 01 at 13:07, [EMAIL PROTECTED] wrote:
>
> > > > - Please keep in mind that that fvwm is controlled and configured
> > > >by configuration commands, not by environment variables. It's
> > > >not necessary to make features configurable via the
> > > >environment. (I'll remove the corresponding code).
> > >
> > > As to this point, one reason was an ability to pass these parameters
> > > to
> > > modules (so that they will automatically be inherited via environment),
> > > and
> > > another is that some other proggies can theoritically use XiSupp.c (think
> > > about XMMS and various toolkits) or a similar thing, and they have no
> > > standard means of communicating to FVWM.
> >
> > Ah, okay. The solution to both problems is the module interface.
> > Some settings like "Colorset" are communicated to the modules over
> > the module pipe. The state of Xinerama{En,Dis}abled can be easily
> > communicated too. In fact I have already done this. Take a look
> > at the code in virtual.c:
> >
> > void CMD_XineramaDisable(F_CMD_ARGS)
> > {
> > XineramaSupportDisable();
> > BroadcastConfigInfoString("XineramaDisable");
> > }
> >
> > Any module listening for M_CONFIG_INFO packets will receive the
> > string "XineramaDisable" when the function is called an can react
> > properly. I think I still forgot to send this string when the
> > module is initially started, so the module's Xinerama state may
> > not match fvwm's state at first. I will take care of this.
> >
> > Any program that wants to communicate to fvwm tightly should be
> > written as an fvwm module. Another way would be to communicate
> > via FvwmCommand, but that is inefficient and littl internal
> > information about fvwm's state it communicated this way.
> >
> > > Sure, modules interface can (and should?) be extended to accept
> > > PrimaryScreen change, but this is mostly irrelevant -- primary screen is
> > > usually taken into account only at startup.
>
> The problem of other programs remain -- they should *not* communicate to
> fvwm, they should work with *any* WM. In fact, the problem here is lack
> of X.org specification. IMHO the natural way will be to use a root window
> property -- like _XINERAMA_PRIMARY_SCREEN. In that case any program could
> request notification of property's change. This isn't urgent, but AFAIK
> nobody have done something in this area yet, so if we do, this can become a
> standard.
Writing a standard for this would clearly be something that should
go into the "Enhanced Window Manager Hints" spec. In any case,
it's much better to do it as a root window property. But I since
nobody is writing applications especially for fvwm, any property
we define would not be used anyway.
> > Well, then let's split up the function. XiParseGeometry() does
> > exactly what XParseGeometry() does but with the additional
> > "@" parsing. Another function could take its output as
> > input and do the additional calculations. Or if that won't work,
> > there should at least be an alias of the function that can be
> > called like XParseGeometry().
>
> Okay, lets do int XiParseGeometry(char *str, int *{x,y,w,h,scr}) and
> XiGetGeometry(), which will do the actual calculations. The thing is that
> "screen" parameter is not very useful outside XineramaSupport.c, since list
> of screens shouldn't be visible outside.
No, it shouldn't be visible outside. Don't return it through the
interface. If you want a function that returns more than x/y/w/h,
don't call it ...ParseGeometry(). This will just be confusing. As
far as I can see the knowledge of the screen is not needed
awterwards. If you need that information to call another
function, you can write an internal variant of the
...ParseGeometry() function that returns screen numbers too. Then
call it from your XiWMGeometry() function and from
XiParseGeometry(). But you should not change standard interfaces.
> The patch is attached (I'm very-very sorry for uppercase, that's my
> Pegasus Mail for Dos ;-).
Eeeek!
> It is cvs diff -u (similar-looking functions made
> diff slightly insane, so the patch layout looks a bit inoptimal).
Don't care
> ...
> The point is not cleaning the code, but a correct operation of modules --
> do you need a pager on non-primary screen?
I don't quit understand the question. Of course I'd usually
prefer the pager on the primary screen, but perhaps I wnat one on
both screens.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama merger -- part 1
On Fri, Jul 27, 2001 at 09:35:49PM +0700, Dmitry Yu. Bolkhovityanov wrote:
> On 27 Jul 01 at 11:56, fvwm-workers@fvwm.org wrote:
>
> > - Code is written with 80 characters per line, a basic
> >indentation width of 2.
> > - Always compile the code with and without your ifdefs. Remove
> >all warnings (compile with 'make CFLAGS="-Wall -Werror -g").
>
> Okay. I usually set CFLAGS="-W -Wall" -- this gives more interesting
> info.
>
> > - Please keep in mind that that fvwm is controlled and configured
> >by configuration commands, not by environment variables. It's
> >not necessary to make features configurable via the
> >environment. (I'll remove the corresponding code).
>
> As to this point, one reason was an ability to pass these parameters to
> modules (so that they will automatically be inherited via environment), and
> another is that some other proggies can theoritically use XiSupp.c (think
> about XMMS and various toolkits) or a similar thing, and they have no
> standard means of communicating to FVWM.
Ah, okay. The solution to both problems is the module interface.
Some settings like "Colorset" are communicated to the modules over
the module pipe. The state of Xinerama{En,Dis}abled can be easily
communicated too. In fact I have already done this. Take a look
at the code in virtual.c:
void CMD_XineramaDisable(F_CMD_ARGS)
{
XineramaSupportDisable();
BroadcastConfigInfoString("XineramaDisable");
}
Any module listening for M_CONFIG_INFO packets will receive the
string "XineramaDisable" when the function is called an can react
properly. I think I still forgot to send this string when the
module is initially started, so the module's Xinerama state may
not match fvwm's state at first. I will take care of this.
Any program that wants to communicate to fvwm tightly should be
written as an fvwm module. Another way would be to communicate
via FvwmCommand, but that is inefficient and littl internal
information about fvwm's state it communicated this way.
> Sure, modules interface can (and should?) be extended to accept
> PrimaryScreen change, but this is mostly irrelevant -- primary screen is
> usually taken into account only at startup.
>
> > - Please try to use one of the formatting styles that is used in
> >the fvwm code (indentation style). Try not to put commands on
> >the same line as a condition.
>
> BTW, I looked for some style guide inside fvwm sources, but didn't find
> any. Your recommendations are definitely worth putting to some
> fvwm_style_guide.txt.
Another one of the things that nobody has the time and leisure to
do. The common practice is that everybody formats his code pieces
as he likes. Whenever one of the more active developers works a
lot with a certain piece of code (mostly me) he is free to
reformat that code as he likes. I think there would be a lot of
potential for an extensive religios war about brace, whitepace and
comment placement if we really tried to write something down :-)
> > - RandR support will certainly be no part of 2.4.1. You should
> >really try to split the patches you made on your disk into
> >several patch files that can be applied individually.
>
> Well, the RandR support can be at the same position as multibyte support -
> it is present but switched off by default. When HAS_RANDR is undefined,
> RandR will have no effect at all -- nothing will be queried in XiSupp.c, and
> no RandR handlers will be called in events.c and FvwmPager.c.
>
> I added RandR support as an additional step forward -- it enables to
> understand which currently used concepts will become obsolete in some near
> future, and what should be changed for more flexibility. That was the main
> goal, not an ability to use resize feature of yet very rarely used KDrive.
> ;-)
Let me explain why I commented it (actually, commenting it made a
huge, big mess of XineramaSupport.c): The risk that new problems
are introduced in the *stable* 2.4.1 release has to be minimised.
> > One question about the XiParseGeometry function: I don't
> > understand why is does so many things. It really shouldn't do
> > more than just parsing the geometry string like XParseGeometry
> > does and use the same signature. I'll comment out all the extra
> > stuff for now.
>
> The answer is that modules do way too many calculations themselves
> (negative handling, gravity selection, etc.). Much of them are duplicates,
> and with submitted XiParseGeometry() modules become much simpler -- you add
> one/two lines and remove sometimes several dozens (look at patches for
> modules).
>
> Well, maybe XiParseGeometry is not a very appropriate name, in fact what
> this function does is very similar to XWMGeometry.
Well, then let's split up the function. XiParseGeometry() does
exactly what XParseGeometry() does but with the additional
"@" parsing. Another function could take its output as
input and do the additiona
Re: Xinerama merger -- part 1
On 27 Jul 01 at 11:56, fvwm-workers@fvwm.org wrote: > - Code is written with 80 characters per line, a basic >indentation width of 2. > - Always compile the code with and without your ifdefs. Remove >all warnings (compile with 'make CFLAGS="-Wall -Werror -g"). Okay. I usually set CFLAGS="-W -Wall" -- this gives more interesting info. > - Please keep in mind that that fvwm is controlled and configured >by configuration commands, not by environment variables. It's >not necessary to make features configurable via the >environment. (I'll remove the corresponding code). As to this point, one reason was an ability to pass these parameters to modules (so that they will automatically be inherited via environment), and another is that some other proggies can theoritically use XiSupp.c (think about XMMS and various toolkits) or a similar thing, and they have no standard means of communicating to FVWM. Sure, modules interface can (and should?) be extended to accept PrimaryScreen change, but this is mostly irrelevant -- primary screen is usually taken into account only at startup. > - Please try to use one of the formatting styles that is used in >the fvwm code (indentation style). Try not to put commands on >the same line as a condition. BTW, I looked for some style guide inside fvwm sources, but didn't find any. Your recommendations are definitely worth putting to some fvwm_style_guide.txt. > - RandR support will certainly be no part of 2.4.1. You should >really try to split the patches you made on your disk into >several patch files that can be applied individually. Well, the RandR support can be at the same position as multibyte support - it is present but switched off by default. When HAS_RANDR is undefined, RandR will have no effect at all -- nothing will be queried in XiSupp.c, and no RandR handlers will be called in events.c and FvwmPager.c. I added RandR support as an additional step forward -- it enables to understand which currently used concepts will become obsolete in some near future, and what should be changed for more flexibility. That was the main goal, not an ability to use resize feature of yet very rarely used KDrive. ;-) > One question about the XiParseGeometry function: I don't > understand why is does so many things. It really shouldn't do > more than just parsing the geometry string like XParseGeometry > does and use the same signature. I'll comment out all the extra > stuff for now. The answer is that modules do way too many calculations themselves (negative handling, gravity selection, etc.). Much of them are duplicates, and with submitted XiParseGeometry() modules become much simpler -- you add one/two lines and remove sometimes several dozens (look at patches for modules). Well, maybe XiParseGeometry is not a very appropriate name, in fact what this function does is very similar to XWMGeometry. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama merger -- part 1
On Thu, Jul 26, 2001 at 05:43:39PM +0700, Dmitry Yu. Bolkhovityanov wrote:
Content-Description: Mail message body
> Hi!
>
> That's part 1 of XineramaSupport v2 merger. It contains
> libs/XineramaSupport.[ch] as drop-in replacements. Next part will be
> configure script, followed by modules.
>
> The only change required is to fvwm/menus.c -- to use
> XiSuppClipToScreenAt() instead of XiSuppClipToScreen() (the first of them
> appeared in XiSupp after february version).
>
> Dominik, I have a question/correction regarding your changes to XiSupp.c.
> The XiSuppDisable() was intended as a mechanism to hard-disable Xinerama,
> while XiSuppSetState() -- to turn it on/off on the fly. As I understood,
> you changed XiSuppSetState() to be internal call, while
> XiSupp{Enable,Disable} are used as previously XiSuppSetState(). Am I right?
I just took the time to start merging the patch. Please try to
write code keeping this in mind:
- Code is written with 80 characters per line, a basic
indentation width of 2.
- Always compile the code with and without your ifdefs. Remove
all warnings (compile with 'make CFLAGS="-Wall -Werror -g").
- Please keep in mind that that fvwm is controlled and configured
by configuration commands, not by environment variables. It's
not necessary to make features configurable via the
environment. (I'll remove the corresponding code).
- Please try to use one of the formatting styles that is used in
the fvwm code (indentation style). Try not to put commands on
the same line as a condition.
- RandR support will certainly be no part of 2.4.1. You should
really try to split the patches you made on your disk into
several patch files that can be applied individually.
One question about the XiParseGeometry function: I don't
understand why is does so many things. It really shouldn't do
more than just parsing the geometry string like XParseGeometry
does and use the same signature. I'll comment out all the extra
stuff for now.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama merger -- part 1
On Thu, Jul 26, 2001 at 05:43:39PM +0700, Dmitry Yu. Bolkhovityanov wrote:
Content-Description: Mail message body
> Hi!
>
> That's part 1 of XineramaSupport v2 merger. It contains
> libs/XineramaSupport.[ch] as drop-in replacements. Next part will be
> configure script, followed by modules.
>
> The only change required is to fvwm/menus.c -- to use
> XiSuppClipToScreenAt() instead of XiSuppClipToScreen() (the first of them
> appeared in XiSupp after february version).
I will start applying your patches as soon as possible. Since my
mother pays me a visit this weekend I can't promise that I'll have
the time.
> Dominik, I have a question/correction regarding your changes to XiSupp.c.
> The XiSuppDisable() was intended as a mechanism to hard-disable Xinerama,
> while XiSuppSetState() -- to turn it on/off on the fly. As I understood,
> you changed XiSuppSetState() to be internal call, while
> XiSupp{Enable,Disable} are used as previously XiSuppSetState(). Am I right?
Yes. I did not understand this logic and I did not want that the
interface of XiSetState() was visible outside the module because
it has an interface that can be called in a way that would crash
fvwm later. I think a simple on/off call is enough. Also, it is
more flexible if you can't disable Xinerama support completely.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama patch -- v2
On Tue, Jul 24, 2001 at 09:48:02PM +0700, Dmitry Yu. Bolkhovityanov wrote: > On 23 Jul 01 at 18:55, fvwm-workers@fvwm.org wrote: > > > On Mon, Jul 23, 2001 at 06:34:52PM +0700, Dmitry Yu. Bolkhovityanov wrote: > > Content-Description: Mail message body > > > Hi! > > > > > > Attached is a new version of Xinerama patch. The .tgz contains a diff > > > file (against 05-Jul-2001 snapshot), two new files in libs/, and a > > > description of what was done. > > > > Could you by any chance update this patch for the current CVS > > version? The risk that I do something wrong if I merge the patch > > with the current code is way too high. > > > > > This patch has a very basic RandR support, which is disabled by > > > default. > > > > > > Also new from previous version is XiSuppParseGeometry(), which > > > implements a concept of "primary screen". > > > > > > To enable lots of debug info, -DDEBUG_PRINTS=1 can be used. > > > > > > Since some Xinerama support was already added to CVS, I decided to > > > post > > > this patch immediately and not spend time adapting it to current CVS > > > (which > > > will advance even further by the time adaptation is finished ;-). > > > > Well, either you adapt it or I do. Sice you wrote the patch > > yourself it's safer if you do it. Don't believe merging the patch > > is less work just because someone else does it ;-) > > Well, we should first decide who does it (sorry for such a bureacracy ;-) Okay, then you should do it. I and Olivier already made some changes to the libs/Xinerama... files. If you spent any time patching menus.c, don't include it in the patch but instead make a separate patch with a description of the changes. I will then do all the work in the menu code. > -- there's a 100%-possibility of conflict when simultaneously making changes > to the same pieces of code. I'll have time for it about friday. The point > is that new version should be integrated as soon as possible, for next > changes to be based on it instead of older one. > > As I understand, all modifications to the modules/ can be performed > safely, since you didn't touch them yet, right? And, BTW, the patch > contained a slightly modified version of TaskBar patch (with revealed-when- > focused functionality), which is already in CVS. > > So, if you do it now -- okay; if you give me a timeslot on friday -- > I'll do it myself. If you actively develop code, the best way ist to always keep up to date with CVS always. The conflicts are much easier to resolve at the moment they occur. Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama patch -- v2
On 23 Jul 01 at 18:55, fvwm-workers@fvwm.org wrote: > On Mon, Jul 23, 2001 at 06:34:52PM +0700, Dmitry Yu. Bolkhovityanov wrote: > Content-Description: Mail message body > > Hi! > > > > Attached is a new version of Xinerama patch. The .tgz contains a diff > > file (against 05-Jul-2001 snapshot), two new files in libs/, and a > > description of what was done. > > Could you by any chance update this patch for the current CVS > version? The risk that I do something wrong if I merge the patch > with the current code is way too high. > > > This patch has a very basic RandR support, which is disabled by default. > > > > Also new from previous version is XiSuppParseGeometry(), which > > implements a concept of "primary screen". > > > > To enable lots of debug info, -DDEBUG_PRINTS=1 can be used. > > > > Since some Xinerama support was already added to CVS, I decided to post > > this patch immediately and not spend time adapting it to current CVS (which > > will advance even further by the time adaptation is finished ;-). > > Well, either you adapt it or I do. Sice you wrote the patch > yourself it's safer if you do it. Don't believe merging the patch > is less work just because someone else does it ;-) Well, we should first decide who does it (sorry for such a bureacracy ;-) -- there's a 100%-possibility of conflict when simultaneously making changes to the same pieces of code. I'll have time for it about friday. The point is that new version should be integrated as soon as possible, for next changes to be based on it instead of older one. As I understand, all modifications to the modules/ can be performed safely, since you didn't touch them yet, right? And, BTW, the patch contained a slightly modified version of TaskBar patch (with revealed-when- focused functionality), which is already in CVS. So, if you do it now -- okay; if you give me a timeslot on friday -- I'll do it myself. ___ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama patch -- v2
On Mon, Jul 23, 2001 at 06:34:52PM +0700, Dmitry Yu. Bolkhovityanov wrote: Content-Description: Mail message body > Hi! > > Attached is a new version of Xinerama patch. The .tgz contains a diff > file (against 05-Jul-2001 snapshot), two new files in libs/, and a > description of what was done. Could you by any chance update this patch for the current CVS version? The risk that I do something wrong if I merge the patch with the current code is way too high. > This patch has a very basic RandR support, which is disabled by default. > > Also new from previous version is XiSuppParseGeometry(), which > implements a concept of "primary screen". > > To enable lots of debug info, -DDEBUG_PRINTS=1 can be used. > > Since some Xinerama support was already added to CVS, I decided to post > this patch immediately and not spend time adapting it to current CVS (which > will advance even further by the time adaptation is finished ;-). Well, either you adapt it or I do. Sice you wrote the patch yourself it's safer if you do it. Don't believe merging the patch is less work just because someone else does it ;-) Bye Dominik ^_^ ^_^ -- Dominik Vogt, email: [EMAIL PROTECTED] LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Xinerama to-do
On 22 Jul 01 at 16:05, [EMAIL PROTECTED] wrote:
> On Sun, Jul 22, 2001 at 09:32:38PM +0700, Dmitry Yu. Bolkhovityanov wrote:
[SNIP]
> > 7) Maximizing windows
[SNIP]
> > Implementation of 7 also doesn't look problematic, I can do it.
>
> Perhaps we should first discuss how to implement the new syntax in
> general. There are several places where Xinerama specific
> parameters would be useful (Move, Resize, ResizeMove, Maximize,
> MoveToPage and others).
As to Maximize, the syntax can be extended with a single optional switch:
Maximize [absolute] ...
By default maximization occurs on a window's screen, but if "absolute" is
specified, the global screen is used instead (that's how it is done in E).
I'm not sure what to do with Move/Resize. These *can* also use an
optional "absolute" parameter, but Move should allow inter-screen moving by
default. Resize, on the other hand, can benefit from such a constraint.
Yuck, the Move is already constrained by inter-xinerama-screen
EdgeResistance, so applying optional "absolute" to resizing will be enough.
> > And what do you mean in 10 -- should Pager draw each page as a complex
> > shape, consisting of several rectangles, with possible "blank areas",
> > instead of current simple rectangle? And should it limit moving "mini-
> > windows" as moving real ones are limited to existing screen space?
>
> At least it would be nice to optionally have some kind of
> separator similar to page separators. Also, the blank areas
> should be visible and it shouldn't be possible to move windows
> entirely into them.
Okay -- than we'll have to add XiSuppGetScreens or, better,
int XiSuppGetScreensCount(void)
void XiSuppGetNScrRect(int N, int *x, int *y, int *w, int *h).
But that must be re-queried on every XineramaUse/XineramaIgnore to keep
pager's list coherent with XineramaSupport's. Anyway, users of this
interface should be limited to Pager.
> > > However some of the
> > > Xinerama functions poll the pointer position which reduces
> > > performance a lot, especially in the move and resize loops.
> >
> > Is there any current-pointer-position cache in Xlib, which can be
> > queried instead of always calling XQueryPointer()? That could be fine.
>
> I don't think so.
>
> > Otherwise we should add something like "XineramaSupportNextEvent", which
> > could do caching instead.
>
> Another solution would be to allow screen coordinates as optional
> parameters to the XineramaSuporrt... function calls. The pointer
> would only be queried if no position was given. I'm not yet sure
> what the best solution would be.
>
> I have been thinking about fvwm replacements for X and other
> library funtions for a while. It may be a good idea to drop in
> functions a la FvwmNextEvent as replacements for the X functions
> and somehow automatically create a compiler error for all places
> where the original function is used.
"Optional parameters" decision will require such parameters to too many
calls (some of the cases are not obvious). It seems better to introduce
FvwmNextEvent and make it call XiSuppSetMouseXY():
Bool cur_ms_coords_set = False;
void XiSuppSetMouseXY(int x, int y)
{
cur_ms_x = x;
cur_ms_y = y;
cur_ms_coords_set = True;
}
static void GetMouseXY(int *x, int *y)
{
if (cur_ms_coords_set)
{
*x = cur_ms_x;
*y = cur_ms_y;
}
else
XQueryPointer(...);
}
The cur_ms_coords_set guard is for just-started proggies, when no events
are received yet, but we need to know current pointer position.
BTW, are there any cases when a module will require XiSupp to do a
current-screen-based decision, while not feeding up-to-date XY info
beforehand (e.g., when the pointer is moved to other screen, and not above
that module's window)?
[SNIP]
> > As to general, standard X geometry specification turned to be
> > insufficient for Xinerama, so new XineramaSupport.c enables one to specify
> > [EMAIL PROTECTED], where optional S parameter is a screen.
>
> Then we need an enhanced version of XParseGeometry() too?
Yes, that's the XineramaSupportParseGeometry() ;-)
> > The screen can be either a number or one of "g" (global -- emulates
> > XParseGeometry), "c" (current -- where pointer is), "p" -- primary (usually
> > 1st screen, unless changed), this is the default.
> >
> > Plus a concept of "primary screen", where main controls are located
> > (Pager, Wharf, TaskBar (sic!)). (Since XFree86 4.1 XDM places its login
> > window to the 1st Xinerama screen too.)
>
> Yes, the concept of a primary screen is a good idea - my primary
> screen is right of the second one, so all kinds of windows don't
> appear where I would like them to. Does it make sense to not use
> the second screen at all unless the user explicitly moves or
> starts applications there?
IMHO it is sane to obey sizehints when they request placing on non-
primary screen, and always try to start app on current screen. In most
cases "current" will be
Re: Xinerama to-do
On Sun, Jul 22, 2001 at 09:32:38PM +0700, Dmitry Yu. Bolkhovityanov wrote:
> On 22 Jul 01 at 12:57, [EMAIL PROTECTED] wrote:
>
> > Here is a list of features Xinerama support may or may not
> > support:
> >
> > 1) Window placement
> > 2) Icon placement
> > 3) Menu placement
> > 4) Menu position hints
> > 5) Sizing menus for different screen sizes
> > 6) Position of the geometry window
> > 7) Maximizing windows
> > 8) Limit SnapAttraction to windows on same screen.
> > 9) Enable and Disable Xinerama on the fly (including modules)
> > 10) Xinerama support in Pager
> > 11) Xinerama support in WindowList
> > 12) XineramaSupport in various icon managers (IconMan, WinList)
> > 13) EdgeScrolling between Xinerama screens.
> > 14) Handle Xinerama screens in Move/Resize parameters.
> >
> > Currently, 3, 6, 9 and 13 are implemented.
>
> I've already implemented 11 (i.e. FvwmWinList obeys current xinerama-
> screen when managing its geometry, but should we introduce
> "ShowCurrentScreen" option? I think no).
With 11 I meant the WindowList command, not the FvwmWinList
module. Of course it should be done in the module too.
> Implementation of 7 also doesn't look problematic, I can do it.
Perhaps we should first discuss how to implement the new syntax in
general. There are several places where Xinerama specific
parameters would be useful (Move, Resize, ResizeMove, Maximize,
MoveToPage and others).
> BTW, did you mean "EdgeResistance" in 13?
Yes.
> And what do you mean in 10 -- should Pager draw each page as a complex
> shape, consisting of several rectangles, with possible "blank areas",
> instead of current simple rectangle? And should it limit moving "mini-
> windows" as moving real ones are limited to existing screen space?
At least it would be nice to optionally have some kind of
separator similar to page separators. Also, the blank areas
should be visible and it shouldn't be possible to move windows
entirely into them.
> > However some of the
> > Xinerama functions poll the pointer position which reduces
> > performance a lot, especially in the move and resize loops.
>
> Is there any current-pointer-position cache in Xlib, which can be
> queried instead of always calling XQueryPointer()? That could be fine.
I don't think so.
> Otherwise we should add something like "XineramaSupportNextEvent", which
> could do caching instead.
Another solution would be to allow screen coordinates as optional
parameters to the XineramaSuporrt... function calls. The pointer
would only be queried if no position was given. I'm not yet sure
what the best solution would be.
I have been thinking about fvwm replacements for X and other
library funtions for a while. It may be a good idea to drop in
functions a la FvwmNextEvent as replacements for the X functions
and somehow automatically create a compiler error for all places
where the original function is used.
> > Consider this layout of a Xinerama screen consisting of two
> > physical screens:
> >
> > Xinerama screen
> > +-+--+
> > | | |
> > | | |
> > | | |
> > | | |
> > | | screen 2|
> > | screen 1| |
> > | | |
> > | | |
> > | | |
> > | | |
> > +-+ |
> > | blank area| |
> > | | |
> > +-+--+
> >
> >
> > At the moment, the most annoying problems are:
> >
> > - Fvwm happily places windows and icons in blank areas.
> > - Menus are sized for the whole screen. If a menu that is as
> >tall as screen 2 is opened on screen 1, the bottom items are
> >not accessible.
> > - Maximizing windows always covers the whole screen, not only
> >the sub screen with the window.
> >
> > In another step it may be worthwhile to put all code dealing with
> > screen dimensions in a single library libs/Screen.c instead of
> > libs/XineramaSupport.c. This libraray could handle all
> > arithmetics with screen dimensions and would be the only place
> > that knows about Xinerama at all.
>
> It is exactly the point which was taken when designing XineramaSupport --
> to make an abstract "screen geometry" layer. RandR support fits fine into
> this model. "Screen.c" seems to be a reasonable name (I already thought
> about using AdvScrn.c ("advanced screen management"), and hence "AdvScrn"
> prefix for all its functions -- "XineramaSupportXXX" is s long. :-)
How about "FvwmAdvancedScreenManagementModule" as a prefix ;-) I
guess "fvwmlib_..." would do, or perhaps "fvwmlib_screen_..." (I
prefer underscores to capitals, but I won't make it
Re: Xinerama to-do
On 22 Jul 01 at 12:57, [EMAIL PROTECTED] wrote:
> Here is a list of features Xinerama support may or may not
> support:
>
> 1) Window placement
> 2) Icon placement
> 3) Menu placement
> 4) Menu position hints
> 5) Sizing menus for different screen sizes
> 6) Position of the geometry window
> 7) Maximizing windows
> 8) Limit SnapAttraction to windows on same screen.
> 9) Enable and Disable Xinerama on the fly (including modules)
> 10) Xinerama support in Pager
> 11) Xinerama support in WindowList
> 12) XineramaSupport in various icon managers (IconMan, WinList)
> 13) EdgeScrolling between Xinerama screens.
> 14) Handle Xinerama screens in Move/Resize parameters.
>
> Currently, 3, 6, 9 and 13 are implemented.
I've already implemented 11 (i.e. FvwmWinList obeys current xinerama-
screen when managing its geometry, but should we introduce
"ShowCurrentScreen" option? I think no).
Implementation of 7 also doesn't look problematic, I can do it.
BTW, did you mean "EdgeResistance" in 13?
And what do you mean in 10 -- should Pager draw each page as a complex
shape, consisting of several rectangles, with possible "blank areas",
instead of current simple rectangle? And should it limit moving "mini-
windows" as moving real ones are limited to existing screen space?
> However some of the
> Xinerama functions poll the pointer position which reduces
> performance a lot, especially in the move and resize loops.
Is there any current-pointer-position cache in Xlib, which can be
queried instead of always calling XQueryPointer()? That could be fine.
Otherwise we should add something like "XineramaSupportNextEvent", which
could do caching instead.
> Consider this layout of a Xinerama screen consisting of two
> physical screens:
>
> Xinerama screen
> +-+--+
> | | |
> | | |
> | | |
> | | |
> | | screen 2|
> | screen 1| |
> | | |
> | | |
> | | |
> | | |
> +-+ |
> | blank area| |
> | | |
> +-+--+
>
>
> At the moment, the most annoying problems are:
>
> - Fvwm happily places windows and icons in blank areas.
> - Menus are sized for the whole screen. If a menu that is as
>tall as screen 2 is opened on screen 1, the bottom items are
>not accessible.
> - Maximizing windows always covers the whole screen, not only
>the sub screen with the window.
>
> In another step it may be worthwhile to put all code dealing with
> screen dimensions in a single library libs/Screen.c instead of
> libs/XineramaSupport.c. This libraray could handle all
> arithmetics with screen dimensions and would be the only place
> that knows about Xinerama at all.
It is exactly the point which was taken when designing XineramaSupport --
to make an abstract "screen geometry" layer. RandR support fits fine into
this model. "Screen.c" seems to be a reasonable name (I already thought
about using AdvScrn.c ("advanced screen management"), and hence "AdvScrn"
prefix for all its functions -- "XineramaSupportXXX" is s long. :-)
As to general, standard X geometry specification turned to be
insufficient for Xinerama, so new XineramaSupport.c enables one to specify
[EMAIL PROTECTED], where optional S parameter is a screen.
The screen can be either a number or one of "g" (global -- emulates
XParseGeometry), "c" (current -- where pointer is), "p" -- primary (usually
1st screen, unless changed), this is the default.
Plus a concept of "primary screen", where main controls are located
(Pager, Wharf, TaskBar (sic!)). (Since XFree86 4.1 XDM places its login
window to the 1st Xinerama screen too.)
And what is completely broken by Xinerama is TaskBar with its autohiding
logic (AutiStick, however, is fixable). I've spent a lot of time trying to
make it work, but seems that it will be *much* easier to implement
Style AutoHide. The latter is more correct, BTW, since some aspects are
absolutely impossible to do in a module instead of WM itself.
(It seems I write too much this evening, time to go to sleep ;-)
___
Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA
phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics
| Lab. 5-13
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
