Subject: Xinerama to-do

From: Dominik Vogt <[email-masked]>
Date: Sun, 22 Jul 2001 12:57:34 +0200

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.  However some of the
Xinerama functions poll the pointer position which reduces
performance a lot, especially in the move and resize loops.

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.

Any comments and help with the implementation are welcome.  For
those who don't have a second monitor I added the configure
option --enable-xinerama-emulation.  The Xinerama code is enabled
on a single screen with the above layout, including the blank
area.  For testing, it is probably best to fill the blank area
with a single window so you can see when the pointer or a window
or menu reaches into the forbidden zone.  You do not need the
Xinerama extension in your X server for this to work.

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: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Mon, 23 Jul 2001 19:31:21 +0700

On 22 Jul 01 at 16:05, [email-masked] wrote:

> On Sun, Jul 22, 2001 at 09:32:38PM +0700, Dmitry Yu. Bolkhovityanov wrote:
[SNIP]
> >   7) Maximizing windows
[SNIP]
> >     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).

    As to Maximize, the syntax can be extended with a single optional switch:

    Maximize [absolute] ...

By default maximization occurs on a window's screen, but if "absolute" is
specified, the global screen is used instead (that's how it is done in E).

    I'm not sure what to do with Move/Resize.  These *can* also use an
optional "absolute" parameter, but Move should allow inter-screen moving by
default. Resize, on the other hand, can benefit from such a constraint.
Yuck, the Move is already constrained by inter-xinerama-screen
EdgeResistance, so applying optional "absolute" to resizing will be enough.

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

    Okay -- than we'll have to add XiSuppGetScreens or, better,

int  XiSuppGetScreensCount(void)
void XiSuppGetNScrRect(int N, int *x, int *y, int *w, int *h).

But that must be re-queried on every XineramaUse/XineramaIgnore to keep
pager's list coherent with XineramaSupport's.  Anyway, users of this
interface should be limited to Pager.

> > > However some of the
> >     Is there any current-pointer-position cache in Xlib, which can be
> > queried instead of always calling XQueryPointer()?  That could be fine.
>
> I don't think so.
>
> > Otherwise we should add something like "XineramaSupportNextEvent", which
> > 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.

    "Optional parameters" decision will require such parameters to too many
calls (some of the cases are not obvious).  It seems better to introduce
FvwmNextEvent and make it call XiSuppSetMouseXY():

Bool cur_ms_coords_set = False;

void XiSuppSetMouseXY(int x, int y)
{
  cur_ms_x = x;
  cur_ms_y = y;
  cur_ms_coords_set = True;
}

static void GetMouseXY(int *x, int *y)
{
  if (cur_ms_coords_set)
  {
    *x = cur_ms_x;
    *y = cur_ms_y;
  }
  else
    XQueryPointer(...);
}

    The cur_ms_coords_set guard is for just-started proggies, when no events
are received yet, but we need to know current pointer position.

    BTW, are there any cases when a module will require XiSupp to do a
current-screen-based decision, while not feeding up-to-date XY info
beforehand (e.g., when the pointer is moved to other screen, and not above
that module's window)?

[SNIP]
> >     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.
>
> Then we need an enhanced version of XParseGeometry() too?

    Yes, that's the XineramaSupportParseGeometry() ;-)

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

    IMHO it is sane to obey sizehints when they request placing on non-
primary screen, and always try to start app on current screen.  In most
cases "current" will be "primary", so if the user wants a window on non-
primary screen, he should either move the pointer there and run an app, or
move an existing window there (resembles FVWM's treatment of virtual
pages/desktops).

> >     And what is completely broken by Xinerama is TaskBar with its autohiding
> > logic (AutoStick, 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.
>
> 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
> > absolutely impossible to do in a module instead of WM itself.
>
> I'll start collecting all this in a xinerama to-do file.

    Okay, these things are:

    Style AutoHide [visible-pixels]
    Style AutoStretch

    The latter is to emulate TaskBar's behaviour -- stretch along the border
which it is stuck to.  As to AutoHide, there is a question: should such
style work in both vertical and horizontal directions, or should it be
limitable?  AutoHide'ing something horizontal like TaskBar to the left/right
border is nonsense.  Or maybe there is some reason to emulate windoze's
taskbar behaviour (it changes orientation according to which border it
sticks to).

    Of course, something like AutoStick is required also -- like making
SnapAttraction a per-style parameter.

    As to what is unimplementable in AutoHide outside the WM: consider the
following layout:

    +------------+
    |            |
    |   Primary  |
    |            |
    +------------+
    |            |
    |  Secondary |
    |            |
    +------------+

If AutoHide'ing window is located at the bottom border of primary screen,
when hiding it shows on Secondary.  The general case is when a window hides
behind a border which contacts another screen, the window shows on that
another screen.

    So FVWM must resize X-window for it to be present entirely on the "host"
screen.  Simply XResizeWindow(tmp_win->frame) will do the thing in
bottom/right cases, but not in top/left -- those will require an additional
offsets while XDraw/XFill'ing.

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