Re: [AD] SF.net SVN: alleg:[13184] allegro/branches/4.9 |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: "Coordination of admins/developers of the game programming library Allegro" <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] SF.net SVN: alleg:[13184] allegro/branches/4.9
- From: Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>
- Date: Sat, 3 Apr 2010 20:40:20 -0600
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.
> Peter
>
> -------------------------------------------------------------------------
> ----- Download Intel® 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