Re: AWT Dev Add mutter as a window manager.
On 6/5/2012 3:14 AM, Omair Majid wrote: Thanks. I have pushed the fix: http://hg.openjdk.java.net/jdk8/awt-gate/jdk/rev/79df0a4a6573 Thanks Omair. -- best regards, Anthony
Re: AWT Dev Add mutter as a window manager.
On 04/20/2012 11:01 AM, Artem Ananiev wrote: On 4/11/2012 11:21 PM, Anthony Petrov wrote: Hi Omair and Artem, On 4/11/2012 9:20 PM, Omair Majid wrote: PS. Perhaps it also makes sense to rewrite that comment in the XDecoratedPeer to replace the word bug with something saying that this is implemented according to the ICCCM specification with a reference to the paragraph 4.1.5 of it? Agreed. I would like to go so far as to make this the default, and add other window managers (which are deviating from ICCCM) as exceptions. I am afraid of introducing regressions, though. I wholeheartedly support this idea in theory. But it seems scary in practice. We would need to run all automatic and manual AWT regression tests on at least all major WMs (Metacity, Kwin, Compiz, and (sic!) CDE - as long as we support Solaris CDE desktops, not sure if this is relevant to JDK 8 though) to ensure no regressions arise. Note that we have to test this with quite old versions of the WMs, e.g. Metacity from Gnome 2.6 (or is it 2.4?) - this is what Solaris 10 has to offer, etc. And ideally we would also want to test on all those forgotten/rare creatures like SawFish, Motif, Enlightenment, etc. This looks like a lot of work for such a simple fix. However, your current fix looks pretty safe and is fully consistent with our current XAWT code. Artem, what's your opinion? Sorry for such a long delay from my side... Mario absolutely correctly wrote in his email: To be honest, I'm not that happy with the fix, but not because of Omair's patch, which is very fine given the current state of things, but because we keep adding this to each and every new WM we find, although fixing AWT in this regard will be probably more work than adding another exception to the list and an issue for perennial backward compatibility... and I feel exactly the same: the fix is fine, but the current AWT approach to workaround WM bugs isn't. Please, consider this as my approval :) Thanks. I have pushed the fix: http://hg.openjdk.java.net/jdk8/awt-gate/jdk/rev/79df0a4a6573 Cheers, Omair
Re: AWT Dev Add mutter as a window manager.
Hi Mario, On 04/11/2012 07:39 AM, Mario Torre wrote: I also agree with Omair. To be honest, I'm not that happy with the fix, but not because of Omair's patch, which is very fine given the current state of things, but because we keep adding this to each and every new WM we find, although fixing AWT in this regard will be probably more work than adding another exception to the list and an issue for perennial backward compatibility... Anyway, I just wanted to give Omair my +1 to this patch. Thanks for reviewing the patch. Unfortunately, since you are not listed as a reviewer for jdk8 [1], I couldnt list you as a reviewer in the changeset. Sorry about that. Thanks, Omair [1] http://openjdk.java.net/census#neugens
Re: AWT Dev Add mutter as a window manager.
On 4/11/2012 11:21 PM, Anthony Petrov wrote: Hi Omair and Artem, On 4/11/2012 9:20 PM, Omair Majid wrote: PS. Perhaps it also makes sense to rewrite that comment in the XDecoratedPeer to replace the word bug with something saying that this is implemented according to the ICCCM specification with a reference to the paragraph 4.1.5 of it? Agreed. I would like to go so far as to make this the default, and add other window managers (which are deviating from ICCCM) as exceptions. I am afraid of introducing regressions, though. I wholeheartedly support this idea in theory. But it seems scary in practice. We would need to run all automatic and manual AWT regression tests on at least all major WMs (Metacity, Kwin, Compiz, and (sic!) CDE - as long as we support Solaris CDE desktops, not sure if this is relevant to JDK 8 though) to ensure no regressions arise. Note that we have to test this with quite old versions of the WMs, e.g. Metacity from Gnome 2.6 (or is it 2.4?) - this is what Solaris 10 has to offer, etc. And ideally we would also want to test on all those forgotten/rare creatures like SawFish, Motif, Enlightenment, etc. This looks like a lot of work for such a simple fix. However, your current fix looks pretty safe and is fully consistent with our current XAWT code. Artem, what's your opinion? Sorry for such a long delay from my side... Mario absolutely correctly wrote in his email: To be honest, I'm not that happy with the fix, but not because of Omair's patch, which is very fine given the current state of things, but because we keep adding this to each and every new WM we find, although fixing AWT in this regard will be probably more work than adding another exception to the list and an issue for perennial backward compatibility... and I feel exactly the same: the fix is fine, but the current AWT approach to workaround WM bugs isn't. Please, consider this as my approval :) Thanks, Artem -- best regards, Anthony
Re: AWT Dev Add mutter as a window manager.
On 4/11/2012 11:21 PM, Anthony Petrov wrote: Hi Omair and Artem, On 4/11/2012 9:20 PM, Omair Majid wrote: PS. Perhaps it also makes sense to rewrite that comment in the XDecoratedPeer to replace the word bug with something saying that this is implemented according to the ICCCM specification with a reference to the paragraph 4.1.5 of it? Agreed. I would like to go so far as to make this the default, and add other window managers (which are deviating from ICCCM) as exceptions. I am afraid of introducing regressions, though. I wholeheartedly support this idea in theory. But it seems scary in practice. We would need to run all automatic and manual AWT regression tests on at least all major WMs (Metacity, Kwin, Compiz, and (sic!) CDE - as long as we support Solaris CDE desktops, not sure if this is relevant to JDK 8 though) to ensure no regressions arise. Note that we have to test this with quite old versions of the WMs, e.g. Metacity from Gnome 2.6 (or is it 2.4?) - this is what Solaris 10 has to offer, etc. And ideally we would also want to test on all those forgotten/rare creatures like SawFish, Motif, Enlightenment, etc. This looks like a lot of work for such a simple fix. I don't think CDE, SawFish, older versions of Metacity and KWin, and all other window managers which are not compliant to ICCCM and _NET really should be cared of in JDK8. If we can refactor our code to throw out most/all the WM-specific workarounds and get cleaner and more robust code and fix many insets-related bugs, I would love to do so. However, it's a huge work, it doesn't make any sense to start it until we know for sure we'll get some benefits. As usual, community contributions are always welcome, though :) Thanks, Artem However, your current fix looks pretty safe and is fully consistent with our current XAWT code. Artem, what's your opinion? -- best regards, Anthony
Re: AWT Dev Add mutter as a window manager.
Hi all,
I also agree with Omair.
To be honest, I'm not that happy with the fix, but not because of
Omair's patch, which is very fine given the current state of things,
but because we keep adding this to each and every new WM we find,
although fixing AWT in this regard will be probably more work than
adding another exception to the list and an issue for perennial
backward compatibility...
Btw, this patch brings in another small issue:
static boolean isNonReparentingWM() {
return (XWM.getWMID() == XWM.COMPIZ_WM || XWM.getWMID() ==
XWM.LG3D_WM || XWM.getWMID() == XWM.CWM_WM);
}
I don't remember at this moment why this was needed at all, but if my
memory is correct, Compiz is a reparenting WM now. I'm not sure if
mutter is or not.
Anyway, I just wanted to give Omair my +1 to this patch.
Cheers,
Mario
2012/4/11 Anthony Petrov anthony.pet...@oracle.com:
Hi Omair,
The analysis below sounds reasonable to me, and as I've already mentioned
I'm OK with your fix.
Let's hear what Artem says though.
PS. Perhaps it also makes sense to rewrite that comment in the
XDecoratedPeer to replace the word bug with something saying that this is
implemented according to the ICCCM specification with a reference to the
paragraph 4.1.5 of it?
--
best regards,
Anthony
On 4/11/2012 8:50 AM, Omair Majid wrote:
Hi Artem,
On 04/09/2012 07:10 AM, Artem Ananiev wrote:
I really hope we can drop most of the ancient WMs listed in the XWM
class (MOTIF, OPENLOOK, CDE, SAWFISH, etc) in JDK8. We know AWT/Swing
works fine on the modern WMs that conform to ICCCM and NET standards,
and I don't see any reasons to have (and add more!) workarounds for
non-conformant window managers.
I spent a little bit of time reading up on ICCCM (and X11), and here's a
summary of my findings. I am not familiar with this, so it could be that
I am making a mistake. Please correct me if I am wrong.
The problematic case (that the reproducer shows) is that when we
maximize a window by double clicking on the title bar under mutter, java
does not detect that the window has moved/changed size.
ICCCM 4.1.5 [1] states:
If the window manager decides to respond to a ConfigureRequest request by:
... snip ...
- Resizing the window or changing its border width (regardless of
whether the window was also moved or restacked).
A client that has selected for StructureNotify events will receive a
real ConfigureNotify event. Note that the coordinates in this event are
relative to the parent, which may not be the root if the window has been
reparented. The coordinates will reflect the actual border width of the
window (which the window manager may have changed). The
TranslateCoordinates request can be used to convert the coordinates if
required.
The general rule is that coordinates in real ConfigureNotify events are
in the parent's space; in synthetic events, they are in the root space.
Advice to Implementors
Clients cannot distinguish between the case where a top-level window
is resized and moved from the case where the window is resized but not
moved, since a real ConfigureNotify event will be received in both
cases. Clients that are concerned with keeping track of the absolute
position of a top-level window should keep a piece of state indicating
whether they are certain of its position. Upon receipt of a real
ConfigureNotify event on the top-level window, the client should note
that the position is unknown. Upon receipt of a synthetic
ConfigureNotify event, the client should note the position as known,
using the position in this event. If the client receives a KeyPress ,
KeyRelease , ButtonPress , ButtonRelease , MotionNotify , EnterNotify ,
or LeaveNotify event on the window (or on any descendant), the client
can deduce the top-level window's position from the difference between
the (event-x, event-y) and (root-x, root-y) coordinates in these events.
Only when the position is unknown does the client need to use the
TranslateCoordinates request to find the position of a top-level window.
To me, this says that when a window has been resized (by, say, double
clicking on the title bar), a real ConfigureNotify event will be sent.
The implementation (awt, in this case) should query for the coordinates
relative to the root and use them.
This is pretty much exactly what the CDE/MWM/Metacity/Sawfish bug
currently does. It seems like this should be the correct default
behaviour (for all window managers, including mutter).
What do you think?
Thanks,
Omair
[1] http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.5
--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
IcedRobot: www.icedrobot.org
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/
Please, support open standards:
Re: AWT Dev Add mutter as a window manager.
Hi Mario,
On 4/11/2012 3:39 PM, Mario Torre wrote:
I also agree with Omair.
To be honest, I'm not that happy with the fix, but not because of
Omair's patch, which is very fine given the current state of things,
but because we keep adding this to each and every new WM we find,
although fixing AWT in this regard will be probably more work than
adding another exception to the list and an issue for perennial
backward compatibility...
That would be fine, indeed. However, this would require a lot of testing
with all the WMs AWT knows about to make sure no regressions are introduced.
Btw, this patch brings in another small issue:
static boolean isNonReparentingWM() {
return (XWM.getWMID() == XWM.COMPIZ_WM || XWM.getWMID() ==
XWM.LG3D_WM || XWM.getWMID() == XWM.CWM_WM);
}
I don't remember at this moment why this was needed at all, but if my
memory is correct, Compiz is a reparenting WM now. I'm not sure if
mutter is or not.
I believe there would be a bug filed already about this, since in
XDecoratedPeer.handleConfigureNotify() this would cause the newLocation
to be assigned with the relative position of the frame, not absolute
position. As long as there's no bug filed, I assume it's OK to report
Compiz as a non-reparenting WM for AWT.
--
best regards,
Anthony
Anyway, I just wanted to give Omair my +1 to this patch.
Cheers,
Mario
2012/4/11 Anthony Petrov anthony.pet...@oracle.com:
Hi Omair,
The analysis below sounds reasonable to me, and as I've already mentioned
I'm OK with your fix.
Let's hear what Artem says though.
PS. Perhaps it also makes sense to rewrite that comment in the
XDecoratedPeer to replace the word bug with something saying that this is
implemented according to the ICCCM specification with a reference to the
paragraph 4.1.5 of it?
--
best regards,
Anthony
On 4/11/2012 8:50 AM, Omair Majid wrote:
Hi Artem,
On 04/09/2012 07:10 AM, Artem Ananiev wrote:
I really hope we can drop most of the ancient WMs listed in the XWM
class (MOTIF, OPENLOOK, CDE, SAWFISH, etc) in JDK8. We know AWT/Swing
works fine on the modern WMs that conform to ICCCM and NET standards,
and I don't see any reasons to have (and add more!) workarounds for
non-conformant window managers.
I spent a little bit of time reading up on ICCCM (and X11), and here's a
summary of my findings. I am not familiar with this, so it could be that
I am making a mistake. Please correct me if I am wrong.
The problematic case (that the reproducer shows) is that when we
maximize a window by double clicking on the title bar under mutter, java
does not detect that the window has moved/changed size.
ICCCM 4.1.5 [1] states:
If the window manager decides to respond to a ConfigureRequest request by:
... snip ...
- Resizing the window or changing its border width (regardless of
whether the window was also moved or restacked).
A client that has selected for StructureNotify events will receive a
real ConfigureNotify event. Note that the coordinates in this event are
relative to the parent, which may not be the root if the window has been
reparented. The coordinates will reflect the actual border width of the
window (which the window manager may have changed). The
TranslateCoordinates request can be used to convert the coordinates if
required.
The general rule is that coordinates in real ConfigureNotify events are
in the parent's space; in synthetic events, they are in the root space.
Advice to Implementors
Clients cannot distinguish between the case where a top-level window
is resized and moved from the case where the window is resized but not
moved, since a real ConfigureNotify event will be received in both
cases. Clients that are concerned with keeping track of the absolute
position of a top-level window should keep a piece of state indicating
whether they are certain of its position. Upon receipt of a real
ConfigureNotify event on the top-level window, the client should note
that the position is unknown. Upon receipt of a synthetic
ConfigureNotify event, the client should note the position as known,
using the position in this event. If the client receives a KeyPress ,
KeyRelease , ButtonPress , ButtonRelease , MotionNotify , EnterNotify ,
or LeaveNotify event on the window (or on any descendant), the client
can deduce the top-level window's position from the difference between
the (event-x, event-y) and (root-x, root-y) coordinates in these events.
Only when the position is unknown does the client need to use the
TranslateCoordinates request to find the position of a top-level window.
To me, this says that when a window has been resized (by, say, double
clicking on the title bar), a real ConfigureNotify event will be sent.
The implementation (awt, in this case) should query for the coordinates
relative to the root and use them.
This is pretty much exactly what the CDE/MWM/Metacity/Sawfish bug
currently does. It seems like this should be the correct default
behaviour (for all window
Re: AWT Dev Add mutter as a window manager.
On 04/11/2012 06:43 AM, Anthony Petrov wrote: Hi Omair, The analysis below sounds reasonable to me, and as I've already mentioned I'm OK with your fix. Let's hear what Artem says though. Yes, I was trying to convince Artem all this time ;) PS. Perhaps it also makes sense to rewrite that comment in the XDecoratedPeer to replace the word bug with something saying that this is implemented according to the ICCCM specification with a reference to the paragraph 4.1.5 of it? Agreed. I would like to go so far as to make this the default, and add other window managers (which are deviating from ICCCM) as exceptions. I am afraid of introducing regressions, though. Thanks, Omair
Re: AWT Dev Add mutter as a window manager.
Hi Omair and Artem, On 4/11/2012 9:20 PM, Omair Majid wrote: PS. Perhaps it also makes sense to rewrite that comment in the XDecoratedPeer to replace the word bug with something saying that this is implemented according to the ICCCM specification with a reference to the paragraph 4.1.5 of it? Agreed. I would like to go so far as to make this the default, and add other window managers (which are deviating from ICCCM) as exceptions. I am afraid of introducing regressions, though. I wholeheartedly support this idea in theory. But it seems scary in practice. We would need to run all automatic and manual AWT regression tests on at least all major WMs (Metacity, Kwin, Compiz, and (sic!) CDE - as long as we support Solaris CDE desktops, not sure if this is relevant to JDK 8 though) to ensure no regressions arise. Note that we have to test this with quite old versions of the WMs, e.g. Metacity from Gnome 2.6 (or is it 2.4?) - this is what Solaris 10 has to offer, etc. And ideally we would also want to test on all those forgotten/rare creatures like SawFish, Motif, Enlightenment, etc. This looks like a lot of work for such a simple fix. However, your current fix looks pretty safe and is fully consistent with our current XAWT code. Artem, what's your opinion? -- best regards, Anthony
Re: AWT Dev Add mutter as a window manager.
Hi Anthony, On 04/09/2012 09:22 AM, Anthony Petrov wrote: Mutter is the direct descendant of Metacity, so there's nothing wrong with it inheriting some inconvenient behavior of its parent. Given that Mutter is the standard WM for Gnome 3.0. I'm fine with the fix. A comment regarding the test: 61 frame.pack(); 62 frame.setSize(500, 500); What's the point of this operations sequence? You should either simply set the desired size, or rely on the pack() alone if the automatically calculated size satisfies you. It just doesn't make sense to do both. You are right. I have removed the pack() line. Also, the @bug line in the test should mention a real CR for this issue, I think it is 7043963. Ah, I didn't have this number. Fixed now. Updated webrev at: http://cr.openjdk.java.net/~omajid/mutter-support/02/ Given Artem's comments, though, I not sure what to do here. Thanks, Omair
Re: AWT Dev Add mutter as a window manager.
Hi Artem, On 04/09/2012 07:10 AM, Artem Ananiev wrote: I really hope we can drop most of the ancient WMs listed in the XWM class (MOTIF, OPENLOOK, CDE, SAWFISH, etc) in JDK8. We know AWT/Swing works fine on the modern WMs that conform to ICCCM and NET standards, and I don't see any reasons to have (and add more!) workarounds for non-conformant window managers. I spent a little bit of time reading up on ICCCM (and X11), and here's a summary of my findings. I am not familiar with this, so it could be that I am making a mistake. Please correct me if I am wrong. The problematic case (that the reproducer shows) is that when we maximize a window by double clicking on the title bar under mutter, java does not detect that the window has moved/changed size. ICCCM 4.1.5 [1] states: If the window manager decides to respond to a ConfigureRequest request by: ... snip ... - Resizing the window or changing its border width (regardless of whether the window was also moved or restacked). A client that has selected for StructureNotify events will receive a real ConfigureNotify event. Note that the coordinates in this event are relative to the parent, which may not be the root if the window has been reparented. The coordinates will reflect the actual border width of the window (which the window manager may have changed). The TranslateCoordinates request can be used to convert the coordinates if required. The general rule is that coordinates in real ConfigureNotify events are in the parent's space; in synthetic events, they are in the root space. Advice to Implementors Clients cannot distinguish between the case where a top-level window is resized and moved from the case where the window is resized but not moved, since a real ConfigureNotify event will be received in both cases. Clients that are concerned with keeping track of the absolute position of a top-level window should keep a piece of state indicating whether they are certain of its position. Upon receipt of a real ConfigureNotify event on the top-level window, the client should note that the position is unknown. Upon receipt of a synthetic ConfigureNotify event, the client should note the position as known, using the position in this event. If the client receives a KeyPress , KeyRelease , ButtonPress , ButtonRelease , MotionNotify , EnterNotify , or LeaveNotify event on the window (or on any descendant), the client can deduce the top-level window's position from the difference between the (event-x, event-y) and (root-x, root-y) coordinates in these events. Only when the position is unknown does the client need to use the TranslateCoordinates request to find the position of a top-level window. To me, this says that when a window has been resized (by, say, double clicking on the title bar), a real ConfigureNotify event will be sent. The implementation (awt, in this case) should query for the coordinates relative to the root and use them. This is pretty much exactly what the CDE/MWM/Metacity/Sawfish bug currently does. It seems like this should be the correct default behaviour (for all window managers, including mutter). What do you think? Thanks, Omair [1] http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.5
Re: AWT Dev Add mutter as a window manager.
Hi, Omair, although the patch is technically fine, I'm reluctant to any changes like this. Ideally, in AWT code we shouldn't have any WM checks at all: all of them are workarounds for various problems with our and their code. I really hope we can drop most of the ancient WMs listed in the XWM class (MOTIF, OPENLOOK, CDE, SAWFISH, etc) in JDK8. We know AWT/Swing works fine on the modern WMs that conform to ICCCM and NET standards, and I don't see any reasons to have (and add more!) workarounds for non-conformant window managers. Thanks, Artem On 4/9/2012 2:28 AM, Omair Majid wrote: On 05/10/2011 12:07 PM, Phil Race wrote: So the repos aren't open any more. Only approved fixes can go in. There was email on this a couple of weeks ago. I have updated Denis' patch to apply to jdk8. Webrev available at: http://cr.openjdk.java.net/~omajid/mutter-support/01/ Thoughts? Cheers, Omair
Re: AWT Dev Add mutter as a window manager.
Hi Omair, Mutter is the direct descendant of Metacity, so there's nothing wrong with it inheriting some inconvenient behavior of its parent. Given that Mutter is the standard WM for Gnome 3.0. I'm fine with the fix. A comment regarding the test: 61 frame.pack(); 62 frame.setSize(500, 500); What's the point of this operations sequence? You should either simply set the desired size, or rely on the pack() alone if the automatically calculated size satisfies you. It just doesn't make sense to do both. Also, the @bug line in the test should mention a real CR for this issue, I think it is 7043963. -- best regards, Anthony On 04/09/12 02:28, Omair Majid wrote: On 05/10/2011 12:07 PM, Phil Race wrote: So the repos aren't open any more. Only approved fixes can go in. There was email on this a couple of weeks ago. I have updated Denis' patch to apply to jdk8. Webrev available at: http://cr.openjdk.java.net/~omajid/mutter-support/01/ Thoughts? Cheers, Omair
Re: AWT Dev Add mutter as a window manager.
On 05/10/2011 12:07 PM, Phil Race wrote: So the repos aren't open any more. Only approved fixes can go in. There was email on this a couple of weeks ago. I have updated Denis' patch to apply to jdk8. Webrev available at: http://cr.openjdk.java.net/~omajid/mutter-support/01/ Thoughts? Cheers, Omair
Re: AWT Dev Add mutter as a window manager.
On 5/12/2011 7:28 PM, Denis Lila wrote:
Hi Denis.
we could use implementation for them as a default one and skip it in
case if custom querying is not needed.
I'm not sure what you mean by this. Can you please ellaborate,
or possibly give a short pseudocode example?
I think Denis F. meant to say that the correct way to add support for
mutter or any other window manager is to get rid of the workaround and
fix this missing ConfigureNotify issue, so we don't have to query for
particular WM at all.
Thanks,
Artem
Thank you,
Denis.
- Original Message -
Hi Denis,
the fix looks good but may be we should consider another approach.
Instead of going through just all known WMs like we do under the
switch
729 switch (XWM.getWMID()) {
730 case XWM.CDE_WM:
731 case XWM.MOTIF_WM:
732 case XWM.METACITY_WM:
733 case XWM.SAWFISH_WM:
734 case XWM.MUTTER_WM:
If you investigate a possibility and efficiency of such a change it
would be great.
Thank you,
Denis.
On 10.05.2011 17:48, Denis Lila wrote:
Hi.
We have this bug where, using the mutter window manager,
if one moves netbeans anywhere on the screen except at
the top left and then maximizes it, clicking is broken.
This is because after maximizing the position of the
XDecoratedPeer is not updated. On Metacity and some other
WMs this is done using a WM specific workaround.
I've added Mutter as a WM, and this webrev fixes the problem:
http://icedtea.classpath.org/~dlila/webrevs/mutterBug/
Any comments are much appreciated.
Thank you,
Denis.
Re: AWT Dev Add mutter as a window manager.
Hi Denis.
we could use implementation for them as a default one and skip it in
case if custom querying is not needed.
I'm not sure what you mean by this. Can you please ellaborate,
or possibly give a short pseudocode example?
Thank you,
Denis.
- Original Message -
Hi Denis,
the fix looks good but may be we should consider another approach.
Instead of going through just all known WMs like we do under the
switch
729 switch (XWM.getWMID()) {
730 case XWM.CDE_WM:
731 case XWM.MOTIF_WM:
732 case XWM.METACITY_WM:
733 case XWM.SAWFISH_WM:
734 case XWM.MUTTER_WM:
If you investigate a possibility and efficiency of such a change it
would be great.
Thank you,
Denis.
On 10.05.2011 17:48, Denis Lila wrote:
Hi.
We have this bug where, using the mutter window manager,
if one moves netbeans anywhere on the screen except at
the top left and then maximizes it, clicking is broken.
This is because after maximizing the position of the
XDecoratedPeer is not updated. On Metacity and some other
WMs this is done using a WM specific workaround.
I've added Mutter as a WM, and this webrev fixes the problem:
http://icedtea.classpath.org/~dlila/webrevs/mutterBug/
Any comments are much appreciated.
Thank you,
Denis.
AWT Dev Add mutter as a window manager.
Hi. We have this bug where, using the mutter window manager, if one moves netbeans anywhere on the screen except at the top left and then maximizes it, clicking is broken. This is because after maximizing the position of the XDecoratedPeer is not updated. On Metacity and some other WMs this is done using a WM specific workaround. I've added Mutter as a WM, and this webrev fixes the problem: http://icedtea.classpath.org/~dlila/webrevs/mutterBug/ Any comments are much appreciated. Thank you, Denis.
