Re: AWT Dev [8] Review request for 7156194 [macosx] Can't type non-ASCII characters into applets
Hi Anthony,
Anthony Petrov wrote:
Hi Dmitry,
On 4/5/2012 11:47 AM, Dmitry Cherepanov wrote:
src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
188 while (index length) {
189 c = text.charAt(index);
190 peer.dispatchKeyEvent(KeyEvent.KEY_TYPED,
191 System.currentTimeMillis(),
192 0,
KeyEvent.VK_UNDEFINED, c,
193
KeyEvent.KEY_LOCATION_UNKNOWN);
194 index++;
195 }
Are we sure we want to dispatch each character for the
handleInputEvent(String) event with its own timestamp? Does a
browser combine several unrelated key strokes into a single
InputEvent, or are all the characters actually represent one
integral input event? Put another way, should user code be able to
see that a bunch of TYPED events actually belongs to one native
input event?
I'm not sure that I understood your question correctly. When a
browser starts a complex text composition, the Plug-in doesn't
receive KeyDown/KeyUp events but it receives TextInput event
containing the composed string and this TextInput event is sent when
the composition is finished. If this doesn't answer your question,
could you please give an example?
At line 191 in the above quote you're assigning a new timestamp to
every Java TYPED event, while all the characters sent via the TYPED
events actually belong to just one browser's InputEvent. I'm wondering
whether all these TYPED events should share the same timestamp (e.g.
acquired before entering the while loop) or not. Could you
investigate/clarify this please?
Both ways seems to be fine to me because the plug-in doesn't receive any
TextInput events during 'in-progress' text composition and receives the
TextInput event when the text composition is done. If you think that
there should be some kind of consistency in it, I guess that its okay to
have these TYPED events with the same timestamp but I don't see any
reason why it should matter.
Thanks,
Dmitry
Re: AWT Dev [8] Review request for 7156194 [macosx] Can't type non-ASCII characters into applets
On 4/10/2012 2:18 PM, Dmitry Cherepanov wrote:
On 4/5/2012 11:47 AM, Dmitry Cherepanov wrote:
src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
188 while (index length) {
189 c = text.charAt(index);
190 peer.dispatchKeyEvent(KeyEvent.KEY_TYPED,
191 System.currentTimeMillis(),
192 0,
KeyEvent.VK_UNDEFINED, c,
193
KeyEvent.KEY_LOCATION_UNKNOWN);
194 index++;
195 }
Are we sure we want to dispatch each character for the
handleInputEvent(String) event with its own timestamp? Does a
browser combine several unrelated key strokes into a single
InputEvent, or are all the characters actually represent one
integral input event? Put another way, should user code be able to
see that a bunch of TYPED events actually belongs to one native
input event?
I'm not sure that I understood your question correctly. When a
browser starts a complex text composition, the Plug-in doesn't
receive KeyDown/KeyUp events but it receives TextInput event
containing the composed string and this TextInput event is sent when
the composition is finished. If this doesn't answer your question,
could you please give an example?
At line 191 in the above quote you're assigning a new timestamp to
every Java TYPED event, while all the characters sent via the TYPED
events actually belong to just one browser's InputEvent. I'm wondering
whether all these TYPED events should share the same timestamp (e.g.
acquired before entering the while loop) or not. Could you
investigate/clarify this please?
Both ways seems to be fine to me because the plug-in doesn't receive any
TextInput events during 'in-progress' text composition and receives the
TextInput event when the text composition is done. If you think that
there should be some kind of consistency in it, I guess that its okay to
have these TYPED events with the same timestamp but I don't see any
reason why it should matter.
OK then. I just wanted to make sure there's no problem with different
timestamps for TYPED events generated from a single InputEvent. If this
is OK, then I'm fine with the fix.
--
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
AWT Dev hg: jdk8/awt/jdk: 7158712: Synth Property ComboBox.popupInsets is ignored
Changeset: 8fe9b93e2474 Author:rupashka Date: 2012-04-10 19:09 +0300 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/8fe9b93e2474 7158712: Synth Property ComboBox.popupInsets is ignored Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthComboPopup.java + test/javax/swing/plaf/synth/7158712/bug7158712.java ! test/javax/swing/regtesthelpers/Util.java
AWT Dev hg: jdk8/awt/jdk: 7097771: setEnabled does not work for components in disabled containers.
Changeset: 33c604bf074f Author:serb Date: 2012-04-10 22:09 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/33c604bf074f 7097771: setEnabled does not work for components in disabled containers. Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XComponentPeer.java + test/java/awt/Component/7097771/bug7097771.java
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
