> "Elijah Newren" <[EMAIL PROTECTED]> wrote:
>
> > Ugh. Apparently, I busted our fullscreen handling in metacity>=2.14.x
> > in lots of cases in addition to problems we've being talking about in
> > this thread. See http://bugzilla.gnome.org/show_bug.cgi?id=343115#c6
> > if you're curious. Anyw
"Elijah Newren" <[EMAIL PROTECTED]> wrote:
Ugh. Apparently, I busted our fullscreen handling in metacity>=2.14.x
in lots of cases in addition to problems we've being talking about in
this thread. See http://bugzilla.gnome.org/show_bug.cgi?id=343115#c6
if you're curious. Anyway, I think I've f
On 8/7/06, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
"Elijah Newren" <[EMAIL PROTECTED]> wrote:
> Anyway, the returning from fullscreen mode bug makes perfect sense,
> and I'm pretty sure I know the cause: metacity tries to return the
> window to the size it was before it was fullscreened, and
On 8/6/06, Vincent Povirk <[EMAIL PROTECTED]> wrote:
The patches in comments #13 and #5 had no effect.
I didn't try #2 because firefox doesn't change the screen resolution.
#2, #5, and #13 were all alternative versions of patches for the same
issue for the "Thief" game. It's not surprising th
"Elijah Newren" <[EMAIL PROTECTED]> wrote:
Anyway, the returning from fullscreen mode bug makes perfect sense,
and I'm pretty sure I know the cause: metacity tries to return the
window to the size it was before it was fullscreened, and it sounds
like it was successful in this case. Remember tha
The patches in comments #13 and #5 had no effect.
#6 didn't apply cleanly (I'm using metacity 2.14.3--I tried to get the
latest version from cvs, but it requires a newer gtk than I have).
After applying it, firefox is fixed, except that when returning from
fullscreen mode the window is bigger tha
"Dmitry Timoshkov" <[EMAIL PROTECTED]> wrote:
"Havoc Pennington" <[EMAIL PROTECTED]> wrote:
You could try patching metacity with either of the fixes mentioned here
(or some other fix) and verify that they work for wine:
http://bugzilla.gnome.org/show_bug.cgi?id=346927
They are both basically
"Havoc Pennington" <[EMAIL PROTECTED]> wrote:
You could try patching metacity with either of the fixes mentioned here
(or some other fix) and verify that they work for wine:
http://bugzilla.gnome.org/show_bug.cgi?id=346927
They are both basically 1-2 line changes, so there's no patch there but
Dmitry Timoshkov wrote:
"Havoc Pennington" <[EMAIL PROTECTED]> wrote:
Dmitry Timoshkov wrote:
It's OK that a WM constrains windows to be placed inside of its work
area
but still allows to place them into a fullscreen state on request.
How would
you suggest to properly inform a WM that a win
"Havoc Pennington" <[EMAIL PROTECTED]> wrote:
Dmitry Timoshkov wrote:
It's OK that a WM constrains windows to be placed inside of its work area
but still allows to place them into a fullscreen state on request. How
would
you suggest to properly inform a WM that a window needs to be in a
full
Dmitry Timoshkov wrote:
It's OK that a WM constrains windows to be placed inside of its work area
but still allows to place them into a fullscreen state on request. How
would
you suggest to properly inform a WM that a window needs to be in a
fullscreen
state? Does metacity ignore ClientMessage
"Havoc Pennington" <[EMAIL PROTECTED]> wrote:
to shift it below the top GNOME top panel by 25 pixels (btw,
that's why I wrongly thought that the top GNOME top panel remained above
in Z order of the main game's window, actually they do not overlap each
other).
Metacity does this with all win
Dmitry Timoshkov wrote:
At this point WM decides to correct position of an invisible application's
window (why?)
In the metacity log, this is in the proper order (the window is mapped,
metacity sets its position, and the window is withdrawn). I would
conclude that this is a race; remember th
Something I think I may have suggested long ago is some sort of "WINE
hints" that WMs could implement; in essence, have calls to the WM that
map to Windows API calls exactly and try to have the same semantics. IOW
implement the windows API in conjunction with the WM.
This is probably the only
"Havoc Pennington" <[EMAIL PROTECTED]> wrote:
I can't tell enough from this log, because remember things are
asynchronous. So we don't know what information metacity already had or
did not have at each point in the log. i.e. WINE may think it said "hide
the window" then get a configure notify,
Dmitry Timoshkov wrote:
1. Why the WM thinks that it knows better than the app where to place
its window
and insists on moving it to another position? That's not a user related
interaction
related to moving a window using mouse or a keyboard, IMO the WM should
not do
this kind of things behi
"Elijah Newren" <[EMAIL PROTECTED]> wrote:
On 7/7/06, Havoc Pennington <[EMAIL PROTECTED]> wrote:
Currently what appears to be triggering the issue in metacity is that
the window's minimum and maximum size are also changed, such that the
window is not resizable. There's an exception to this r
On 7/6/06, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
From http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html
"_NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire
screen and have no window decorations. Additionally the Window Manager is
responsible for restoring the
Dmitry Timoshkov wrote:
Anyway, few WM bugs can be resolved by appeal to specifications alone...
Ok, let's appeal to the fact that Wine's fullscreen stuff works in KDE and
doesn't in GNOME :-) If you could point out what Wine is doing in wrong way
I'm all ears.
Don't get defensive, everyone i
Dmitry Timoshkov wrote:
An algorithm in Wine which asks a WM to activate fullscreen state for
a window is quite simple: it checks the size of a just resized visible
window and if it's equal or larger than screen size sends an event to
a WM. We are trying to understand at the moment why metacity s
Dmitry Timoshkov wrote:
So, all the checks metacity does for window decorations and window size are
contradicting the spec IMO.
Both the ICCCM and EWMH are specs for "hints" - they have a big "any of
these hints may be ignored" disclaimer attached.
In practice, categorically ignoring (or mis
"Havoc Pennington" <[EMAIL PROTECTED]> wrote:
Anyway, few WM bugs can be resolved by appeal to specifications alone...
Ok, let's appeal to the fact that Wine's fullscreen stuff works in KDE and
doesn't in GNOME :-) If you could point out what Wine is doing in wrong way
I'm all ears.
Don't ge
"Havoc Pennington" <[EMAIL PROTECTED]> wrote:
We used to have a "strict spec compliance"/"disable workarounds" mode in
metacity and it was unusable unless you ran GTK/Qt apps exclusively,
pretty much.
While my memory is too fuzzy to point to specific bugs, I'd be willing
to bet that I added
"Elijah Newren" <[EMAIL PROTECTED]> wrote:
Also the fact that a window isn't resizeable means only that it's not supposed
to be resizeable by a user, still allowing to resize it programmatically.
Feel free to point to anywhere in the ICCCM or EWMH that says so. Of
course apps can be resized p
"Havoc Pennington" <[EMAIL PROTECTED]> wrote:
Look at src/window.c:recalc_window_features() for possible reasons
metacity decided to disable fullscreenability.
In this case it looks pretty clear though - the firefox window isn't
resizable, metacity disables fullscreen in that case unless the
Look at src/window.c:recalc_window_features() for possible reasons
metacity decided to disable fullscreenability.
In this case it looks pretty clear though - the firefox window isn't
resizable, metacity disables fullscreen in that case unless the window
size is equal to the screen size and the
On 7/6/06, Havoc Pennington <[EMAIL PROTECTED]> wrote:
Look at src/window.c:recalc_window_features() for possible reasons
metacity decided to disable fullscreenability.
In this case it looks pretty clear though - the firefox window isn't
resizable, metacity disables fullscreen in that case unles
Metacity has some heuristics for fullscreening windows that don't
fullscreen themselves. IIRC, it looks to see if the window hits all the
screen edges and then pretends that it's fullscreen for stacking
constraints, etc.
-Rob
(metacity fullscreens all x clients that don't fullscreen themselves.
On 7/4/06, Vincent Povirk <[EMAIL PROTECTED]> wrote:
I've enabled that key combination, and I can now make gedit fullscreen
with alt+f11 so I think that's working properly (this is nifty; wonder
how I missed it..).
Pressing alt+f11 when windows firefox thinks it's in fullscreen mode
has no effec
Looking through the code made me notice the meta_verbose function and
then the METACITY_VERBOSE environment variable. I set that and logged
an attempt to fullscreen and then unfullscreen firefox. I can send the
whole log if it might be helpful, but here's what stood out for me.
Before firefox att
I do not know if this helps, but on some games, Wine correctly activates
fullscreen mode in metacity, but in others, it just resizes the screen and
gets stuck that way... For example, Sim City 3000. Ubuntu Breezy and Fedora
Core 5 cannot seem to properly go into fullscreen mode. But when running
W
What does "windows firefox thinks it's in fullscreen mode" mean? Does
the application try to manually resize itself in addition to sending
the state change messages to the root window (perhaps as a workaround
for WMs not supporting the _NET_WM_STATE stuff)? Or is there some
other notification th
This is forwarded because I forgot to CC it... Sorry-- Forwarded message --From: Neal Gompa <[EMAIL PROTECTED]
>Date: Jul 5, 2006 5:54 PMSubject: Re: wine's fullscreen code has no effect on metacityTo: Vincent Povirk <[EMAIL PROTECTED]>
I do not know if this helps, but on some games
On 7/4/06, Vincent Povirk <[EMAIL PROTECTED]> wrote:
running metacity:
[EMAIL PROTECTED]:~$ xprop | grep _NET_WM_STATE
_NET_WM_STATE(ATOM) =
running kwin:
[EMAIL PROTECTED]:~$ xprop | grep _NET_WM_STATE
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN
Not that I understood how this was suppose
On 7/2/06, Vincent Povirk <[EMAIL PROTECTED]> wrote:
Some patches were committed to wine recently to make it use
_NET_WM_STATE_FULLSCREEN for fullscreen apps. These patches appear to
work in kwin but not metacity (I was using firefox as a test). In
metacity, it appears wine recognizes that it nee
I've enabled that key combination, and I can now make gedit fullscreen
with alt+f11 so I think that's working properly (this is nifty; wonder
how I missed it..).
Pressing alt+f11 when windows firefox thinks it's in fullscreen mode
has no effect. xprop shows no _NET_WM_STATE.
However, it does wor
running metacity:
[EMAIL PROTECTED]:~$ xprop | grep _NET_WM_STATE
_NET_WM_STATE(ATOM) =
running kwin:
[EMAIL PROTECTED]:~$ xprop | grep _NET_WM_STATE
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN
Not that I understood how this was supposed to work to begin with, but
this really doesn't make
I've tried that; it didn't work in this case. :/
On 7/4/06, Mike Hearn <[EMAIL PROTECTED]> wrote:
On Sun, 02 Jul 2006 13:09:59 -0400, Vincent Povirk wrote:
> So, uh, metacity people, under what circumstances would metacity be
> likely to put a window that had sent the proper _NET_WM_STATE_ADD
>
On Sun, 02 Jul 2006 13:09:59 -0400, Vincent Povirk wrote:
> So, uh, metacity people, under what circumstances would metacity be
> likely to put a window that had sent the proper _NET_WM_STATE_ADD
> message for _NET_WM_STATE_FULLSCREEN behind panels?
Run metacity from the command line so you can se
Some patches were committed to wine recently to make it use
_NET_WM_STATE_FULLSCREEN for fullscreen apps. These patches appear to
work in kwin but not metacity (I was using firefox as a test). In
metacity, it appears wine recognizes that it needs to make a window
fullscreen and send the appropriat
40 matches
Mail list logo