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,
