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
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 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 URL: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 fvwm-workers@fvwm.org 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 URL: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 fvwm-workers@fvwm.org 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 URL: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 fvwm-workers@fvwm.org writes: On Mon, Aug 20, 2001 at 09:45:11AM -0400, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org 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 primary_screen_number 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 URL: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 fvwm-workers@fvwm.org writes: On Mon, Aug 20, 2001 at 09:45:11AM -0400, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org 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 primary_screen_number 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 URL: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 URL: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 URL: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 fvwm-workers@fvwm.org 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 primary_screen_number 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 URL: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 fvwm-workers@fvwm.org 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 URL: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 fvwm-workers@fvwm.org 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 URL: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 fvwm-workers@fvwm.org 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 primary_screen_number 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 URL: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 fvwm-workers@fvwm.org writes: On Mon, Aug 20, 2001 at 09:45:11AM -0400, Dan Espen wrote: Dominik Vogt fvwm-workers@fvwm.org 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 URL: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 fvwm-workers@fvwm.org 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 URL: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 URL: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 URL: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 URL: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 URL: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 URL: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 URL: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 URL: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. widthscreen_width widthscreen_width+edge_moving), 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). ___ 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 URL: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 URL: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
@screen 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
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
@screen 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 URL: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 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
@screen 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 Mail for Dos ;-). It is cvs diff -u (similar-looking functions made
diff slightly insane, so the patch layout looks a bit inoptimal).
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 URL: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 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 URL: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 URL: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 URL: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 primary, so if the user wants a window on non-
primary screen, he should either move the pointer there and
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 URL: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 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 a religion). As to general, standard X geometry specification turned to be insufficient for Xinerama, so new XineramaSupport.c enables one to specify
