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