Re: [AD] SF.net SVN: alleg:[13184] allegro/branches/4.9

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On April 3, 2010, Thomas Fjellstrom wrote:
> On April 3, 2010, Peter Wang wrote:
> > On 2010-04-03, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > > On April 3, 2010, Peter Wang wrote:
> > > > On 2010-04-03, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > > > > On April 3, 2010, Peter Wang wrote:
> > > > > > Milan's description sounded like the window is indeed
> > > > > > frameless, and positioned somewhere (I assumed at 0,0 but
> > > > > > Milan will have to confirm) but the *viewport* is not
> > > > > > initially at 0,0.
> > > > > 
> > > > > As far as I know, that isn't possible. I mean I could tell XRandR
> > > > > to move the display's absolute positions, but that would likely
> > > > > mess things up, and since the window is created at the display's
> > > > > own origin, it CAN'T be wrong. Or somehow the driver is moving
> > > > > the origin when a mode is set, which makes no sense.
> > > > 
> > > > Another data point:
> > > > 
> > > > nvidia-driver-180.51
> > > > xorg-server 1.6.3
> > > > 
> > > > * ex_fs_resize set the screen mode correctly both times, but the
> > > > panel
> > > > 
> > > >   (taskbar) at the top of the screen remains visible, with the
> > > >   Allegro window just underneath.  The mouse cursor is trapped in
> > > >   the Allego window.  If I alt-tab away I can't regain focus in the
> > > >   Allegro window. The window manager is IceWM.
> > > 
> > > Yeah, I haven't figured out how to fully force an ALWAYS ON TOP flag.
> > > I tried with the set_above method, but it doesn't seem to work.
> > 
> > Any reason to use _NET_WM_STATE_ABOVE instead of
> > _NET_WM_STATE_FULLSCREEN?  Not that the latter worked on this machine
> > either.
> 
> FULLSCREEN does a lot of the work for you, including resizing and
> positioning. the wm handles it all.
> 
> I suppose we could switch to using that, and skip all of the positioning
> nonsense.
> 
> > > have to look into the alt tabbing though.. technically it grabbed the
> > > mouse, so it really shouldn't have alt-tab'ed away, no place for the
> > > mouse to go.
> > > 
> > > Could try just skipping the GrabMouse and see what that does. Theres
> > > no virtual res scrolling with these mode sets afaik, so grabbing the
> > > mouse may not be needed, unless you want to make sure the mouse
> > > can't move to a another monitor just by moving it.
> > 
> > Indeed, XGrabPointer seems to be unnecessary with randr (unlike xf86vm)
> > and I don't think we should prevent the user alt-tabbing away if that's
> > what they want to do.
> 
> Yeah, I've commented it out in my latest commit.

I love replying to my own emails....

Another slight bug, on my media box, running the radeon driver (though Im 
not sure how the driver relates to the problem) using flwm, the windows are 
created at entirely wrong positions. It might be a flwm bug I don't have any 
proof of that.

I just tried icewm on the same system to compare, it doesn't position the 
window oddly, but it doesn't place the window above the icewm panel. I can 
only assume icewm doesn't respect the ICCCM flags we're using.

In fact wikipedia's list of WMs that support the Extended Window Manager 
Hints, neither icewm nor flwm are included.

Do we support old and seemingly unsupported window managers? I can try and 
find methods to work around that, but I'm not sure we should include code to 
work around every WM out there.

> > Peter
> > 
> > -----------------------------------------------------------------------
> > -- ----- Download Intel&#174; Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx