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, &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
--
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]
