Re: Some Xinerama problems
On Tue, Oct 02, 2001 at 01:11:25PM +0200, Olivier Chapuis wrote:
> 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.
Ah, I see.
> > > 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).
It did find the icon box, but the loops did not break in case
loc_ok_wrong_screen got set and thus always chose the last
position to fit the icon, not the first one.
Fixed.
[snip]
> 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.
The logic is consistent with all other uses of the 'c' screen.
> 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, &ref.width, &ref.height);
>
> by
>
> /* get the screen dimensions for the icon box */
> if (icon_boxes_ptr->IconScreen == FSCREEN_CURRENT)
> {
> FScreenGetScrRect(&fscr,FSCREEN_XYPOS ,
> &ref.x, &ref.y, &ref.width, &ref.height);
> }
> else
> FScreenGetScrRect(NULL, icon_boxes_ptr->IconScreen,
> &ref.x, &ref.y, &ref.width, &ref.height);
>
> in AutoPlaceIcon and fix the test of a). In fact a more elaborated
> FScreenGetScrRect(FSCREEN_XYPOS) is needed, one that can get
> the screen dimension from a xypos on the desktop (which seems
> needed, for example, to fix iconification from an other page
> problem of a).
>
> The other alternative is to add an @w screen as suggested
> by Dmitry for iconbox geometry.
You're right, that was very easy to implement. I didn't change
the 'c' behaviour because it would have been confusing.
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 F
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
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 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 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]
