On Sun, Jul 22, 2001 at 09:32:38PM +0700, Dmitry Yu. Bolkhovityanov wrote:
> 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).
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.
> 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.
> > 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.
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.
> > 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. :-)
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).
> 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.
Then we need an enhanced version of XParseGeometry() too?
> 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?
> 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.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
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]
