Subject: Re: Some Xinerama problems

From: Dominik Vogt <[email-masked]>
Date: Thu, 30 Sep 2021 22:16:34 +0200

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 1x1+200+200@c +0 +0
> 
> (the @c is not really important). So when I activate this
> bindings the menu popup at 200+200@c 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 1x1+390+200@g +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 1x1+790+200@g 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 370x400+10-10@c, 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-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Olivier Chapuis <[email-masked]>
Date: Tue, 2 Oct 2001 13:11:25 +0200

> 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.

> this can be done easily (most of the icon box calculations are

Ok I think I understand. But:

a. The order you mention is not totally exact. For example if I've:
	Style * Iconbox 200x400+0+0@p, 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 200x400+0+0@0,IconFill left top,\
		Iconbox 200x400+0-0@1, 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 200x400+10-10@c,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, &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.

I will try to fix the problems of a) any advice and 
"authorization" for b) is welcome.

I Hope that I've not misunderstand something this time,
Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 2 Oct 2001 16:01:58 +0200

On Tue, Oct 02, 2001 at 01:11:25PM +0200, Olivier Chapuis wrote:
> should be equivalent to a null one.

Ah, I see.

> (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]

> or if no windows are iconified.

The logic is consistent with all other uses of the 'c' screen.

> 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-masked]
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-masked].
To report problems, send mail to [email-masked]