On 22 Jul 01 at 12:57, [EMAIL PROTECTED] 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
[EMAIL PROTECTED], 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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
