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 behind applications back.
>
> 2. How that could happen that the WM maps a window to
the screen
> although it
> clearly was not asked to?
>
> I hope that the log above will help to shed some light
into the
> investigated
> problem and will allow to find a resolution to it.
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, but metacity
may have sent the
configure notify BEFORE the window was hidden. (Just an
example.)
I'd suggest getting a new WINE log but with metacity
verbose logging on
also. Then we'll have the exact same run of this app from
both sides of
the issue and we can tell exactly what happened during that
run of the
app. Metacity verbose log will mention all the property
changes and
configure requests and so forth.
btw the "synchronous" vs.
"asynchronous" API impedance mismatch is a big
problem; I worked with the Eclipse project on this years
ago, where they
had it with SWT vs. GTK. Though they did not afaik use the
advice we
gave them, which was to leave X/gtk working asynchronously
but have a
"write-through cache" of the server side state
so things looked
synchronous from the SWT point of view.
Of course the most robust approach is to design any API that
has to run
on top of X to have async semantics, but that's not an
option with
exisitng APIs like SWT or win32.
Havoc
_______________________________________________
metacity-devel-list mailing list
metacity-devel-list gnome.org
http://mail.gnome.org/mailman/listinfo/metacity-devel-
list
|