Subject: Re: Xinerama to-do

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Sun, 22 Jul 2001 21:32:38 +0700

On 22 Jul 01 at 12:57, [email-masked] wrote:

> Here is a list of features Xinerama support may or may not
> support:
>
>   1) Window placement
>   2) Icon placement
>   3) Menu placement
>   4) Menu position hints
>   5) Sizing menus for different screen sizes
>   6) Position of the geometry window
>   7) Maximizing windows
>   8) Limit SnapAttraction to windows on same screen.
>   9) Enable and Disable Xinerama on the fly (including modules)
>  10) Xinerama support in Pager
>  11) Xinerama support in WindowList
>  12) XineramaSupport in various icon managers (IconMan, WinList)
>  13) EdgeScrolling between Xinerama screens.
>  14) Handle Xinerama screens in Move/Resize parameters.
>
> Currently, 3, 6, 9 and 13 are implemented.

    I've already implemented 11 (i.e. FvwmWinList obeys current xinerama-
screen when managing its geometry, but should we introduce
"ShowCurrentScreen" option?  I think no).

    Implementation of 7 also doesn't look problematic, I can do it.

    BTW, did you mean "EdgeResistance" in 13?

    And what do you mean in 10 -- should Pager draw each page as a complex
shape, consisting of several rectangles, with possible "blank areas",
instead of current simple rectangle?  And should it limit moving "mini-
windows" as moving real ones are limited to existing screen space?

> However some of the
> Xinerama functions poll the pointer position which reduces
> performance a lot, especially in the move and resize loops.

    Is there any current-pointer-position cache in Xlib, which can be
queried instead of always calling XQueryPointer()?  That could be fine.
Otherwise we should add something like "XineramaSupportNextEvent", which
could do caching instead.

> Consider this layout of a Xinerama screen consisting of two
> physical screens:
>
>   Xinerama screen
>   +---------------------+--------------+
>   |                     |              |
>   |                     |              |
>   |                     |              |
>   |                     |              |
>   |                     |  screen 2    |
>   |     screen 1        |              |
>   |                     |              |
>   |                     |              |
>   |                     |              |
>   |                     |              |
>   +---------------------+              |
>   |   blank area        |              |
>   |                     |              |
>   +---------------------+--------------+
>
>
> At the moment, the most annoying problems are:
>
>  - Fvwm happily places windows and icons in blank areas.
>  - Menus are sized for the whole screen.  If a menu that is as
>    tall as screen 2 is opened on screen 1, the bottom items are
>    not accessible.
>  - Maximizing windows always covers the whole screen, not only
>    the sub screen with the window.
>
> In another step it may be worthwhile to put all code dealing with
> screen dimensions in a single library libs/Screen.c instead of
> libs/XineramaSupport.c.  This libraray could handle all
> arithmetics with screen dimensions and would be the only place
> that knows about Xinerama at all.

    It is exactly the point which was taken when designing XineramaSupport --
to make an abstract "screen geometry" layer.  RandR support fits fine into
this model.  "Screen.c" seems to be a reasonable name (I already thought
about using AdvScrn.c ("advanced screen management"), and hence "AdvScrn"
prefix for all its functions -- "XineramaSupportXXX" is soooo long. :-)

    As to general, standard X geometry specification turned to be
insufficient for Xinerama, so new XineramaSupport.c enables one to specify
WxH+X+Y[@S], where optional S parameter is a screen.

    The screen can be either a number or one of "g" (global -- emulates
XParseGeometry), "c" (current -- where pointer is), "p" -- primary (usually
1st screen, unless changed), this is the default.

    Plus a concept of "primary screen", where main controls are located
(Pager, Wharf, TaskBar (sic!)).  (Since XFree86 4.1 XDM places its login
window to the 1st Xinerama screen too.)

    And what is completely broken by Xinerama is TaskBar with its autohiding
logic (AutiStick, however, is fixable).  I've spent a lot of time trying to
make it work, but seems that it will be *much* easier to implement
Style AutoHide.  The latter is more correct, BTW, since some aspects are
absolutely impossible to do in a module instead of WM itself.

(It seems I write too much this evening, time to go to sleep ;-)

       ___________________________________________________________________
       Dmitry Yu. Bolkhovityanov  |  Novosibirsk, RUSSIA
       phone (383-2)-39-49-56     |  The Budker Institute of Nuclear Physics
                                  |  Lab. 5-13

--
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: Dominik Vogt <[email-masked]>
Date: Sun, 22 Jul 2001 16:05:24 +0200

> "ShowCurrentScreen" option?  I think no).

With 11 I meant the WindowList command, not the FvwmWinList
module.  Of course it should be done in the module too.

>     Implementation of 7 also doesn't look problematic, I can do it.

Perhaps we should first discuss how to implement the new syntax in
general.  There are several places where Xinerama specific
parameters would be useful (Move, Resize, ResizeMove, Maximize,
MoveToPage and others).  

>     BTW, did you mean "EdgeResistance" in 13?

Yes.

> windows" as moving real ones are limited to existing screen space?

At least it would be nice to optionally have some kind of
separator similar to page separators.  Also, the blank areas
should be visible and it shouldn't be possible to move windows
entirely into them.

> queried instead of always calling XQueryPointer()?  That could be fine.

I don't think so.

> could do caching instead.

Another solution would be to allow screen coordinates as optional
parameters to the XineramaSuporrt... function calls.  The pointer
would only be queried if no position was given.  I'm not yet sure
what the best solution would be.

I have been thinking about fvwm replacements for X and other
library funtions for a while.  It may be a good idea to drop in
functions a la FvwmNextEvent as replacements for the X functions
and somehow automatically create a compiler error for all places
where the original function is used.

> prefix for all its functions -- "XineramaSupportXXX" is soooo long. :-)

How about "FvwmAdvancedScreenManagementModule" as a prefix ;-)  I
guess "fvwmlib_..." would do, or perhaps "fvwmlib_screen_..." (I
prefer underscores to capitals, but I won't make it a religion).
 
> WxH+X+Y[@S], where optional S parameter is a screen.

Then we need an enhanced version of XParseGeometry() too?

> window to the 1st Xinerama screen too.)

Yes, the concept of a primary screen is a good idea - my primary
screen is right of the second one, so all kinds of windows don't
appear where I would like them to.  Does it make sense to not use
the second screen at all unless the user explicitly moves or
starts applications there?

> logic (AutoStick, however, is fixable).  I've spent a lot of time trying to
> Style AutoHide.

Don't waste your time on fixing that autohide feature.  It was
broken from the start and will never work properly anyway.  A
style is much better.

>  The latter is more correct, BTW, since some aspects are

I'll start collecting all this in a xinerama to-do file.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]