Re: Some Xinerama problems
On Thu, Sep 30, 2021 at 10:16:34PM +0200, Dominik Vogt wrote: On Fri, Sep 28, 2001 at 05:23:18PM +0200, Olivier Chapuis wrote: Hello, I make some Xinerama test recently using Sls 1x2 on my poor 800x600 screen: --- | | | | 0 | 1 | | | | --- The support seems really great! (BTW, does there exits laptop with a double head video card?). I've noted a few problems with menu position and IconBox 1. if WindowList is called without argument as well as if a menu key binding of the form Key key Context Modifier Menu MyMenu _No_arg_ is activate, then the window list (or the menu) always popup on screen 0. Fixed. With just the WindowList commands without any options, the screen was not set correctly. Ok, but there are an other problem: it is possible to call the WindowList or a menu via a mouse binding function as: DestroyFunc MouseXX AddToFunc MouseXX + I Mouse $0 $2 $3 $4 $5 $6 $7 $8 $9 OR + I Mouse $1 $2 $3 $4 $5 $6 $7 $8 $9 This type of function allows to switch between mouse 2 and 3 in a config file where mouse bindings are defined by MouseXX 2 3 R A WindowList MouseXX 2 3 R S WindowList (CurrentDesk) ..etc. We use this in fvwm-themes. So then the action which arrive to get_menu_options (menu.c) is '' and then the menu position is not good. Ok this is strange but this work with Xinerama Off, the get_option_options has a test for this case (if (!tok)) and strictly speaking an menu position should be equivalent to a null one. I've commited a safe and obvious fix to get_option_options. 3. It seems natural for me that iconification happen on the current screen, so I test IconBox with Style * IconBox [EMAIL PROTECTED], IconGrid 64 10, IconFill left bottom In normal use this work fine. However, if the above command is entered in a way or an other when the mouse cursor is on screen 1 the icons on screen 0 go in a random location (in the top of screen 0). You are misinterpreting what your style line does: it creates an icon box with the given dimensions on whatever screen the pointer is on at the time the style command is issued. It *does not* create one icon box on each screen: this must be done manually. What fvwm does is this: - Create a default icon box that covers the primary screen. (screen 0). - Create the given icon box on the screen with the pointer. (screen 1). Whenever a window is iconified, fvwm looks for a suitable icon box in this order: - Icon boxes that intersect with the screen of the window. - Any icon box other than the default icon box on any screen. - The default icon box. So, what you are seeing is icons being placed in the default icon box on the primary screen since this is the only box that intersects the primary screen. You have to specify a separate icon box for each screen. Of course it would be nice to have a way to specify the same icon box for each screen in a single style command, but I don't see how this can be done easily (most of the icon box calculations are still in style.c). Ok I think I understand. But: a. The order you mention is not totally exact. For example if I've: Style * Iconbox [EMAIL PROTECTED], IconFill left top (Primary is screen 0) then if I iconify a window which is in screen 1 the icon go on the bottom right of screen 0 (no iconbox if found I think). This is caused by the lines in AutoPlaceIcon (icons.c): if (FScreenIsRectangleOnScreen(fscr, FSCREEN_XYPOS, ref)) loc_ok = True; else loc_ok_wrong_screen = True; The test is alawys false as there are no iconbox on screen 1 (and this test may be always false if you iconify from an other page that the page of the window). Moreover if I have: Style * Iconbox [EMAIL PROTECTED],IconFill left top,\ Iconbox [EMAIL PROTECTED], IconFill bottom left Then if the screen 1 iconbox is full, and I iconify a window on screen 1, no iconbox will be found. I think that the order is: go throught all the iconboxes (as there are entred + the default iconbox) take the iconbox only if it is on the same screen than the window. b. IMHO, the @c logic is wrong: a command like Style * Iconbox [EMAIL PROTECTED],IconFill left top will move the icons in an inacceptable way (especially if we fix the bug of a) and so is usable only at startup or if no windows are iconified. Ok, Ok, ... I should use multiple iconboxes and do not use @c. But what I am trying to do is to found a good iconbox for any Xinerama settings (optionally Off). As @c is unusable I suggest to change the @c logic: here current may means the center of the window and not the location of the pointer. I do not think that it is a difficult change. The idea is simple: replace /* get the screen dimensions for the icon box */ FScreenGetScrRect(NULL, icon_boxes_ptr-IconScreen, ref.x, ref.y,
Re: Some Xinerama problems
On Fri, Sep 28, 2001 at 05:23:18PM +0200, Olivier Chapuis wrote: Hello, I make some Xinerama test recently using Sls 1x2 on my poor 800x600 screen: --- | | | | 0 | 1 | | | | --- The support seems really great! (BTW, does there exits laptop with a double head video card?). I've noted a few problems with menu position and IconBox 1. if WindowList is called without argument as well as if a menu key binding of the form Key key Context Modifier Menu MyMenu _No_arg_ is activate, then the window list (or the menu) always popup on screen 0. Fixed. With just the WindowList commands without any options, the screen was not set correctly. 2. For testing let say we have the following binding: Mouse 1 A M Menu MenuFvwmRoot Rectangle [EMAIL PROTECTED] +0 +0 (the @c is not really important). So when I activate this bindings the menu popup at [EMAIL PROTECTED] but if I am on screen 0 and I popup submenus (and subsubmenus) then the menu go into screen 1 (so it is exactly as if I've no XineramaSls support). This does not happen on screen 1 (but here the left limit is my monitor). Similarly if I use: Mouse 1 A M Menu MenuFvwmRoot Rectangle [EMAIL PROTECTED] +0 +0 (and MenuFvwmRoot is larger than 10p) the menu appear in between screen 0 and 1 as it should appear on screen 0 (as it will do with [EMAIL PROTECTED] on screen 1). Fixed. Originally, rectangles referred always to the global screen. Now, the screen part of the geometry also confines the menu into that screen (defaulting to the primary screen). 3. It seems natural for me that iconification happen on the current screen, so I test IconBox with Style * IconBox [EMAIL PROTECTED], IconGrid 64 10, IconFill left bottom In normal use this work fine. However, if the above command is entered in a way or an other when the mouse cursor is on screen 1 the icons on screen 0 go in a random location (in the top of screen 0). You are misinterpreting what your style line does: it creates an icon box with the given dimensions on whatever screen the pointer is on at the time the style command is issued. It *does not* create one icon box on each screen: this must be done manually. What fvwm does is this: - Create a default icon box that covers the primary screen. (screen 0). - Create the given icon box on the screen with the pointer. (screen 1). Whenever a window is iconified, fvwm looks for a suitable icon box in this order: - Icon boxes that intersect with the screen of the window. - Any icon box other than the default icon box on any screen. - The default icon box. So, what you are seeing is icons being placed in the default icon box on the primary screen since this is the only box that intersects the primary screen. You have to specify a separate icon box for each screen. Of course it would be nice to have a way to specify the same icon box for each screen in a single style command, but I don't see how this can be done easily (most of the icon box calculations are still in style.c). Similar things happen with All (CurrentScreen Iconic) RecaptureWindow Also if I have a window which is almost all in screen 1 and if I Iconify it with a title button on screen 0, then the icon go in a random location. More important, if I have a window on screen 1 and if I Iconify it with IconMan which is on screen 0, then again the icon go in a bad location (in screen 0). In the above, screen 0 and 1 are interchangeable. I've not investigate problem 2. 3. I may take a look if no other (more competent than me for these) have the time to fix it (before 2.4.3?). 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: Some Xinerama problems
On Fri, 28 Sep 2001, Olivier Chapuis wrote: Hello, I make some Xinerama test recently using Sls 1x2 on my poor 800x600 screen: --- | | | | 0 | 1 | | | | --- The support seems really great! (BTW, does there exits laptop with a double head video card?). Most modern laptops are dual-headed: first head is laptop's flat panel, the second is VGA output. While VGA typically duplicates the panel, at least those with ATI cards (e.g. Compaq Presario 1700 with ATI Rage Mobility M2) and with Permedia ones are able of displaying different pictures on these heads, and even with different resolutions. _ 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]
Some Xinerama problems
Hello, I make some Xinerama test recently using Sls 1x2 on my poor 800x600 screen: --- | | | | 0 | 1 | | | | --- The support seems really great! (BTW, does there exits laptop with a double head video card?). I've noted a few problems with menu position and IconBox 1. if WindowList is called without argument as well as if a menu key binding of the form Key key Context Modifier Menu MyMenu _No_arg_ is activate, then the window list (or the menu) always popup on screen 0. These problems has been already remarked on this list. I've a very simple fix for this bug, but maybe, Dominik, you prefer to fix it. 2. For testing let say we have the following binding: Mouse 1 A M Menu MenuFvwmRoot Rectangle [EMAIL PROTECTED] +0 +0 (the @c is not really important). So when I activate this bindings the menu popup at [EMAIL PROTECTED] but if I am on screen 0 and I popup submenus (and subsubmenus) then the menu go into screen 1 (so it is exactly as if I've no XineramaSls support). This does not happen on screen 1 (but here the left limit is my monitor). Similarly if I use: Mouse 1 A M Menu MenuFvwmRoot Rectangle [EMAIL PROTECTED] +0 +0 (and MenuFvwmRoot is larger than 10p) the menu appear in between screen 0 and 1 as it should appear on screen 0 (as it will do with [EMAIL PROTECTED] on screen 1). 3. It seems natural for me that iconification happen on the current screen, so I test IconBox with Style * IconBox [EMAIL PROTECTED], IconGrid 64 10, IconFill left bottom In normal use this work fine. However, if the above command is entered in a way or an other when the mouse cursor is on screen 1 the icons on screen 0 go in a random location (in the top of screen 0). Similar things happen with All (CurrentScreen Iconic) RecaptureWindow Also if I have a window which is almost all in screen 1 and if I Iconify it with a title button on screen 0, then the icon go in a random location. More important, if I have a window on screen 1 and if I Iconify it with IconMan which is on screen 0, then again the icon go in a bad location (in screen 0). In the above, screen 0 and 1 are interchangeable. I've not investigate problem 2. 3. I may take a look if no other (more competent than me for these) have the time to fix it (before 2.4.3?). Olivier -- 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]
