From omajid at redhat.com Mon Jan 12 14:26:00 2009 From: omajid at redhat.com (Omair Majid) Date: Mon, 12 Jan 2009 17:26:00 -0500 Subject: Background/Foreground colors and Gtk Look and Feel Message-ID: <496BC378.9090101@redhat.com> Hi, I have noticed a few issues in the Gtk Look and Feel and would like to know what the correct behaviour should be. The attached program shows a few of my concerns. 1) For each of the components, setForeground(color) and/or setBackground(color) assignments are randomly ignored. Is this the expected behaviour? I can understand that using the native look and feel, the feel is exactly preserved and the programmer's preferences are ignored. But there doesn't seem to be any consistency - some components accept the color changes, some silently ignore it. Is there a list showing whether setForeground() and setBackground() is ignored for each swing component with the gtk look and feel? 2) The behaviour varies across jdk6 and openjdk6. For example, the closed-source jdk6 respects JTextPane.setBackground(UIManager.getColor("Panel.background")) but openjdk6 ignores it. In situations like this, what is the correct behaviour? Should I attempt to patch openjdk6 to behave more like closed source jdk6? Thanks, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: TestGtkBackground.java Type: text/x-java Size: 2163 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20090112/e1f73b7a/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: sun-jdk.png Type: image/png Size: 11787 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20090112/e1f73b7a/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk6.png Type: image/png Size: 14387 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20090112/e1f73b7a/attachment-0001.png From roman.kennke at aicas.com Wed Jan 14 05:54:56 2009 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 14 Jan 2009 14:54:56 +0100 Subject: [PATCH] DefaultDesktopPane fix Message-ID: <1231941296.6213.5.camel@moonlight> I found a problem in DefaultDesktopPane. Dragging in fast mode does not work correctly (at least not on all platforms) if the pane is obscured by another heavyweight. Graphics.copyArea() isn't guaranteed to work correctly in this case. I think we need to do like in JViewport and check if the heavyweight is guaranteed to be not obscured and only do the fast dragging if this is the case. I pulled the checking code from JViewport to SwingUtilities so they can share this thing. I know this is a corner case, because in most cases, when dragging an internal frame, the user clicks on the frame and brings the window to the top anyway, so it should not be obscured, but there could be always-on-top dialogs or similar, which stay on top of the app, even when the user drags something. The webrev is here: http://kennke.org/~roman/desktoppane/webrev/ What do you think? Should this be included in OpenJDK? /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From fbrunnerlist at gmx.ch Sat Jan 17 08:34:21 2009 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Sat, 17 Jan 2009 17:34:21 +0100 Subject: 6179357: Generics: JList: getSelectedValues In-Reply-To: <495A8B9D.9080804@JoGiles.co.nz> References: <200812302155.14405.fbrunnerlist@gmx.ch> <495A8B9D.9080804@JoGiles.co.nz> Message-ID: <200901171734.21718.fbrunnerlist@gmx.ch> So, does everybody agree? Would be great to also have opinions from someone working at Sun? Pavel, especially your opinion is quite important since you will probably be the one who will have to eventually accept and commit my patch. :-) -Florian Am Dienstag, 30. Dezember 2008 schrieb Jonathan Giles: > Florian, > > Your proposed solution of deprecating the old method and referring to > the new method seems like a good idea to me. > > Cheers, > Jonathan Giles > > Florian Brunner wrote: > > Hi, > > > > I hope you all had a Merry Christmas! I started now to add generics to > > ListModel and JList. While adding generics to the ListModel is quite > > straightforward, I think, there are some issues with JList, I would > > like to dicuss. I start here with the first issue: getSelectedValues > > > > Am I right, that there is no way to change the signature of this > > method to: > > > > public E[] getSelectedValues() > > > > where E is the type parameter of the class? > > > > (Because of generic array creation, which is not supported by Java.) > > > > Here is the current implementation: > > > > public Object[] getSelectedValues() { > > > > ListSelectionModel sm = getSelectionModel(); > > > > ListModel dm = getModel(); > > > > int iMin = sm.getMinSelectionIndex(); > > > > int iMax = sm.getMaxSelectionIndex(); > > > > if ((iMin < 0) || (iMax < 0)) { > > > > return new Object[0]; > > > > } > > > > Object[] rvTmp = new Object[1+ (iMax - iMin)]; > > > > int n = 0; > > > > for(int i = iMin; i <= iMax; i++) { > > > > if (sm.isSelectedIndex(i)) { > > > > rvTmp[n++] = dm.getElementAt(i); > > > > } > > > > } > > > > Object[] rv = new Object[n]; > > > > System.arraycopy(rvTmp, 0, rv, 0, n); > > > > return rv; > > > > } > > > > If this is not possible I propose to add a new method: > > > > public List getSelectedItems() > > > > and deprecate getSelectedValues: > > > > ... > > > > * @deprecated As of JDK 1.7, replaced by {@link #getSelectedItems()} > > > > */ > > > > @Deprecated > > > > public Object[] getSelectedValues() { > > > > ... > > > > } > > > > /** > > > > * Returns a list of all the selected items, in increasing order based > > > > * on their indices in the list. > > > > * > > > > * @return the selected items, or an empty list if nothing is selected > > > > * @see #isSelectedIndex > > > > * @see #getModel > > > > * @see #addListSelectionListener > > > > * > > > > * @since 1.7 > > > > */ > > > > public List getSelectedItems() { > > > > ListSelectionModel sm = getSelectionModel(); > > > > ListModel dm = getModel(); > > > > int iMin = sm.getMinSelectionIndex(); > > > > int iMax = sm.getMaxSelectionIndex(); > > > > if ((iMin < 0) || (iMax < 0)) { > > > > return Collections.emptyList(); > > > > } > > > > List selectedItems = new ArrayList(); > > > > for(int i = iMin; i <= iMax; i++) { > > > > if (sm.isSelectedIndex(i)) { > > > > selectedItems.add(dm.getElementAt(i)); > > > > } > > > > } > > > > return selectedItems; > > > > } > > > > Note: Ignore for now 'E' vs '? extends E', I will start another thread > > for this. I'm just interested if you think it's a good idea to add the > > getSelectedItems method and to deprecate getSelectedValues. > > > > So I wish you a Happy New Year and hope to hear from you soon. > > > > -Florian From Alexander.Potochkin at Sun.COM Sun Jan 18 05:28:19 2009 From: Alexander.Potochkin at Sun.COM (Alexander Potochkin) Date: Sun, 18 Jan 2009 16:28:19 +0300 Subject: 6179357: Generics: JList: getSelectedValues In-Reply-To: <200901171734.21718.fbrunnerlist@gmx.ch> References: <200812302155.14405.fbrunnerlist@gmx.ch> <495A8B9D.9080804@JoGiles.co.nz> <200901171734.21718.fbrunnerlist@gmx.ch> Message-ID: <49732E73.9090001@sun.com> Hello Florian > So, does everybody agree? > > Would be great to also have opinions from someone working at Sun? Sorry for delay public E[] getSelectedValues() looks ok at the first glance (but I didn't do all testing) there is no way to create a generified array like this: E[] array = new E[10]; but you can use the following workaround: @SuppressWarnings("unchecked") E[] array = (E[])new Object[10]; Generification is a challenging task, because it must be backward compatible, fortunately compatibility was one of the main feature of generics Thanks alexp > > Pavel, especially your opinion is quite important since you will probably be > the one who will have to eventually accept and commit my patch. :-) > > -Florian > > Am Dienstag, 30. Dezember 2008 schrieb Jonathan Giles: >> Florian, >> >> Your proposed solution of deprecating the old method and referring to >> the new method seems like a good idea to me. >> >> Cheers, >> Jonathan Giles >> >> Florian Brunner wrote: >>> Hi, >>> >>> I hope you all had a Merry Christmas! I started now to add generics to >>> ListModel and JList. While adding generics to the ListModel is quite >>> straightforward, I think, there are some issues with JList, I would >>> like to dicuss. I start here with the first issue: getSelectedValues >>> >>> Am I right, that there is no way to change the signature of this >>> method to: >>> >>> public E[] getSelectedValues() >>> >>> where E is the type parameter of the class? >>> >>> (Because of generic array creation, which is not supported by Java.) >>> >>> Here is the current implementation: >>> >>> public Object[] getSelectedValues() { >>> >>> ListSelectionModel sm = getSelectionModel(); >>> >>> ListModel dm = getModel(); >>> >>> int iMin = sm.getMinSelectionIndex(); >>> >>> int iMax = sm.getMaxSelectionIndex(); >>> >>> if ((iMin < 0) || (iMax < 0)) { >>> >>> return new Object[0]; >>> >>> } >>> >>> Object[] rvTmp = new Object[1+ (iMax - iMin)]; >>> >>> int n = 0; >>> >>> for(int i = iMin; i <= iMax; i++) { >>> >>> if (sm.isSelectedIndex(i)) { >>> >>> rvTmp[n++] = dm.getElementAt(i); >>> >>> } >>> >>> } >>> >>> Object[] rv = new Object[n]; >>> >>> System.arraycopy(rvTmp, 0, rv, 0, n); >>> >>> return rv; >>> >>> } >>> >>> If this is not possible I propose to add a new method: >>> >>> public List getSelectedItems() >>> >>> and deprecate getSelectedValues: >>> >>> ... >>> >>> * @deprecated As of JDK 1.7, replaced by {@link #getSelectedItems()} >>> >>> */ >>> >>> @Deprecated >>> >>> public Object[] getSelectedValues() { >>> >>> ... >>> >>> } >>> >>> /** >>> >>> * Returns a list of all the selected items, in increasing order based >>> >>> * on their indices in the list. >>> >>> * >>> >>> * @return the selected items, or an empty list if nothing is selected >>> >>> * @see #isSelectedIndex >>> >>> * @see #getModel >>> >>> * @see #addListSelectionListener >>> >>> * >>> >>> * @since 1.7 >>> >>> */ >>> >>> public List getSelectedItems() { >>> >>> ListSelectionModel sm = getSelectionModel(); >>> >>> ListModel dm = getModel(); >>> >>> int iMin = sm.getMinSelectionIndex(); >>> >>> int iMax = sm.getMaxSelectionIndex(); >>> >>> if ((iMin < 0) || (iMax < 0)) { >>> >>> return Collections.emptyList(); >>> >>> } >>> >>> List selectedItems = new ArrayList(); >>> >>> for(int i = iMin; i <= iMax; i++) { >>> >>> if (sm.isSelectedIndex(i)) { >>> >>> selectedItems.add(dm.getElementAt(i)); >>> >>> } >>> >>> } >>> >>> return selectedItems; >>> >>> } >>> >>> Note: Ignore for now 'E' vs '? extends E', I will start another thread >>> for this. I'm just interested if you think it's a good idea to add the >>> getSelectedItems method and to deprecate getSelectedValues. >>> >>> So I wish you a Happy New Year and hope to hear from you soon. >>> >>> -Florian > > From Thomas.Hawtin at Sun.COM Mon Jan 19 07:00:36 2009 From: Thomas.Hawtin at Sun.COM (Tom Hawtin) Date: Mon, 19 Jan 2009 15:00:36 +0000 Subject: 6179357: Generics: JList: getSelectedValues In-Reply-To: <49732E73.9090001@sun.com> References: <200812302155.14405.fbrunnerlist@gmx.ch> <495A8B9D.9080804@JoGiles.co.nz> <200901171734.21718.fbrunnerlist@gmx.ch> <49732E73.9090001@sun.com> Message-ID: <49749594.8080205@sun.com> Alexander Potochkin wrote: > > but you can use the following workaround: > > @SuppressWarnings("unchecked") > E[] array = (E[])new Object[10]; Consider this client code: JList list = ...; String[] strs = list.getSelectedValues(); In that code you have a ClassCastException from Object[] to String[]. Unfortunately you can *not*, for obscure language reasons, even declare JList.getSelectedValues as: public T[] getSelectedValues() So, I think if you want the method genericisted, it needs to be deprecated (or as near as we are allowed) and replaced. Although for my money, you're always better off going for a model and leaving the actual JComponent well alone. Tom Hawtin From Alexander.Potochkin at Sun.COM Mon Jan 19 07:27:10 2009 From: Alexander.Potochkin at Sun.COM (Alexander Potochkin) Date: Mon, 19 Jan 2009 18:27:10 +0300 Subject: 6179357: Generics: JList: getSelectedValues In-Reply-To: <49749594.8080205@sun.com> References: <200812302155.14405.fbrunnerlist@gmx.ch> <495A8B9D.9080804@JoGiles.co.nz> <200901171734.21718.fbrunnerlist@gmx.ch> <49732E73.9090001@sun.com> <49749594.8080205@sun.com> Message-ID: <49749BCE.30107@sun.com> Hello Tom > but you can use the following workaround: >> >> @SuppressWarnings("unchecked") >> E[] array = (E[])new Object[10]; > > Consider this client code: > > JList list = ...; > String[] strs = list.getSelectedValues(); > > In that code you have a ClassCastException from Object[] to String[]. > > Unfortunately you can *not*, for obscure language reasons, even declare > JList.getSelectedValues as: > > public T[] getSelectedValues() > > So, I think if you want the method genericisted, it needs to be > deprecated (or as near as we are allowed) and replaced. Although for my > money, you're always better off going for a model and leaving the actual > JComponent well alone. I must agree here The only robust solution would be to use a Class instance as a constructor to create the array, e.g. as EventListenerList.getListeners(Class t) does however it will require huge API change so we'd better leave it as is Thanks alexp > > Tom Hawtin From Pavel.Porvatov at Sun.COM Mon Jan 19 08:15:56 2009 From: Pavel.Porvatov at Sun.COM (Pavel Porvatov) Date: Mon, 19 Jan 2009 19:15:56 +0300 Subject: 6179357: Generics: JList: getSelectedValues In-Reply-To: <200901171734.21718.fbrunnerlist@gmx.ch> References: <200812302155.14405.fbrunnerlist@gmx.ch> <495A8B9D.9080804@JoGiles.co.nz> <200901171734.21718.fbrunnerlist@gmx.ch> Message-ID: <4974A73C.2050905@sun.com> Hi Florian, > So, does everybody agree? > > Would be great to also have opinions from someone working at Sun? > > Pavel, especially your opinion is quite important since you will probably be > the one who will have to eventually accept and commit my patch. :-) I think we are not able to do anything with the getSelectedValues() method. So we should introduce the new method and deprecate the old one. Regards, Pavel. > > -Florian > > Am Dienstag, 30. Dezember 2008 schrieb Jonathan Giles: >> Florian, >> >> Your proposed solution of deprecating the old method and referring to >> the new method seems like a good idea to me. >> >> Cheers, >> Jonathan Giles >> >> Florian Brunner wrote: >>> Hi, >>> >>> I hope you all had a Merry Christmas! I started now to add generics to >>> ListModel and JList. While adding generics to the ListModel is quite >>> straightforward, I think, there are some issues with JList, I would >>> like to dicuss. I start here with the first issue: getSelectedValues >>> >>> Am I right, that there is no way to change the signature of this >>> method to: >>> >>> public E[] getSelectedValues() >>> >>> where E is the type parameter of the class? >>> >>> (Because of generic array creation, which is not supported by Java.) >>> >>> Here is the current implementation: >>> >>> public Object[] getSelectedValues() { >>> >>> ListSelectionModel sm = getSelectionModel(); >>> >>> ListModel dm = getModel(); >>> >>> int iMin = sm.getMinSelectionIndex(); >>> >>> int iMax = sm.getMaxSelectionIndex(); >>> >>> if ((iMin < 0) || (iMax < 0)) { >>> >>> return new Object[0]; >>> >>> } >>> >>> Object[] rvTmp = new Object[1+ (iMax - iMin)]; >>> >>> int n = 0; >>> >>> for(int i = iMin; i <= iMax; i++) { >>> >>> if (sm.isSelectedIndex(i)) { >>> >>> rvTmp[n++] = dm.getElementAt(i); >>> >>> } >>> >>> } >>> >>> Object[] rv = new Object[n]; >>> >>> System.arraycopy(rvTmp, 0, rv, 0, n); >>> >>> return rv; >>> >>> } >>> >>> If this is not possible I propose to add a new method: >>> >>> public List getSelectedItems() >>> >>> and deprecate getSelectedValues: >>> >>> ... >>> >>> * @deprecated As of JDK 1.7, replaced by {@link #getSelectedItems()} >>> >>> */ >>> >>> @Deprecated >>> >>> public Object[] getSelectedValues() { >>> >>> ... >>> >>> } >>> >>> /** >>> >>> * Returns a list of all the selected items, in increasing order based >>> >>> * on their indices in the list. >>> >>> * >>> >>> * @return the selected items, or an empty list if nothing is selected >>> >>> * @see #isSelectedIndex >>> >>> * @see #getModel >>> >>> * @see #addListSelectionListener >>> >>> * >>> >>> * @since 1.7 >>> >>> */ >>> >>> public List getSelectedItems() { >>> >>> ListSelectionModel sm = getSelectionModel(); >>> >>> ListModel dm = getModel(); >>> >>> int iMin = sm.getMinSelectionIndex(); >>> >>> int iMax = sm.getMaxSelectionIndex(); >>> >>> if ((iMin < 0) || (iMax < 0)) { >>> >>> return Collections.emptyList(); >>> >>> } >>> >>> List selectedItems = new ArrayList(); >>> >>> for(int i = iMin; i <= iMax; i++) { >>> >>> if (sm.isSelectedIndex(i)) { >>> >>> selectedItems.add(dm.getElementAt(i)); >>> >>> } >>> >>> } >>> >>> return selectedItems; >>> >>> } >>> >>> Note: Ignore for now 'E' vs '? extends E', I will start another thread >>> for this. I'm just interested if you think it's a good idea to add the >>> getSelectedItems method and to deprecate getSelectedValues. >>> >>> So I wish you a Happy New Year and hope to hear from you soon. >>> >>> -Florian > > From alex.menkov at sun.com Mon Jan 19 09:24:17 2009 From: alex.menkov at sun.com (alex.menkov at sun.com) Date: Mon, 19 Jan 2009 17:24:17 +0000 Subject: hg: jdk7/swing/jdk: 6702956: OpenJDK: replace encumbered code (software synthesizer); ... Message-ID: <20090119172429.C6A7BDBD1@hg.openjdk.java.net> Changeset: b06c29386f63 Author: amenkov Date: 2009-01-19 20:11 +0300 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/b06c29386f63 6702956: OpenJDK: replace encumbered code (software synthesizer) 6717691: Update Gervill with post 1.0 fixes 6740210: Update Gervill with more post 1.0 fixes 6748247: Further update Gervill with still more post 1.0 fixes 6748251: Apply IcedTea midi sound patch 6758986: Gervill: Turn SoftJitterCorrector, SoftAudioPusher threads into a daemon threads Reviewed-by: ohair, darcy ! make/common/Release.gmk ! make/common/internal/BinaryPlugs.gmk ! make/javax/sound/Makefile - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java + src/share/classes/com/sun/media/sound/AudioFileSoundbankReader.java + src/share/classes/com/sun/media/sound/AudioFloatConverter.java + src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java + src/share/classes/com/sun/media/sound/AudioFloatInputStream.java + src/share/classes/com/sun/media/sound/AudioSynthesizer.java + src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java + src/share/classes/com/sun/media/sound/DLSInfo.java + src/share/classes/com/sun/media/sound/DLSInstrument.java + src/share/classes/com/sun/media/sound/DLSModulator.java + src/share/classes/com/sun/media/sound/DLSRegion.java + src/share/classes/com/sun/media/sound/DLSSample.java + src/share/classes/com/sun/media/sound/DLSSampleLoop.java + src/share/classes/com/sun/media/sound/DLSSampleOptions.java + src/share/classes/com/sun/media/sound/DLSSoundbank.java + src/share/classes/com/sun/media/sound/DLSSoundbankReader.java ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java + src/share/classes/com/sun/media/sound/EmergencySoundbank.java + src/share/classes/com/sun/media/sound/FFT.java + src/share/classes/com/sun/media/sound/InvalidDataException.java + src/share/classes/com/sun/media/sound/InvalidFormatException.java + src/share/classes/com/sun/media/sound/JARSoundbankReader.java + src/share/classes/com/sun/media/sound/ModelAbstractChannelMixer.java + src/share/classes/com/sun/media/sound/ModelAbstractOscillator.java + src/share/classes/com/sun/media/sound/ModelByteBuffer.java + src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java + src/share/classes/com/sun/media/sound/ModelChannelMixer.java + src/share/classes/com/sun/media/sound/ModelConnectionBlock.java + src/share/classes/com/sun/media/sound/ModelDestination.java + src/share/classes/com/sun/media/sound/ModelDirectedPlayer.java + src/share/classes/com/sun/media/sound/ModelDirector.java + src/share/classes/com/sun/media/sound/ModelIdentifier.java + src/share/classes/com/sun/media/sound/ModelInstrument.java + src/share/classes/com/sun/media/sound/ModelInstrumentComparator.java + src/share/classes/com/sun/media/sound/ModelMappedInstrument.java + src/share/classes/com/sun/media/sound/ModelOscillator.java + src/share/classes/com/sun/media/sound/ModelOscillatorStream.java + src/share/classes/com/sun/media/sound/ModelPatch.java + src/share/classes/com/sun/media/sound/ModelPerformer.java + src/share/classes/com/sun/media/sound/ModelSource.java + src/share/classes/com/sun/media/sound/ModelStandardDirector.java + src/share/classes/com/sun/media/sound/ModelStandardTransform.java + src/share/classes/com/sun/media/sound/ModelTransform.java + src/share/classes/com/sun/media/sound/ModelWavetable.java ! src/share/classes/com/sun/media/sound/Platform.java + src/share/classes/com/sun/media/sound/RIFFInvalidDataException.java + src/share/classes/com/sun/media/sound/RIFFInvalidFormatException.java + src/share/classes/com/sun/media/sound/RIFFReader.java + src/share/classes/com/sun/media/sound/RIFFWriter.java ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java + src/share/classes/com/sun/media/sound/SF2GlobalRegion.java + src/share/classes/com/sun/media/sound/SF2Instrument.java + src/share/classes/com/sun/media/sound/SF2InstrumentRegion.java + src/share/classes/com/sun/media/sound/SF2Layer.java + src/share/classes/com/sun/media/sound/SF2LayerRegion.java + src/share/classes/com/sun/media/sound/SF2Modulator.java + src/share/classes/com/sun/media/sound/SF2Region.java + src/share/classes/com/sun/media/sound/SF2Sample.java + src/share/classes/com/sun/media/sound/SF2Soundbank.java + src/share/classes/com/sun/media/sound/SF2SoundbankReader.java + src/share/classes/com/sun/media/sound/SimpleInstrument.java + src/share/classes/com/sun/media/sound/SimpleSoundbank.java + src/share/classes/com/sun/media/sound/SoftAbstractResampler.java + src/share/classes/com/sun/media/sound/SoftAudioBuffer.java + src/share/classes/com/sun/media/sound/SoftAudioProcessor.java + src/share/classes/com/sun/media/sound/SoftAudioPusher.java + src/share/classes/com/sun/media/sound/SoftChannel.java + src/share/classes/com/sun/media/sound/SoftChannelProxy.java + src/share/classes/com/sun/media/sound/SoftChorus.java + src/share/classes/com/sun/media/sound/SoftControl.java + src/share/classes/com/sun/media/sound/SoftCubicResampler.java + src/share/classes/com/sun/media/sound/SoftEnvelopeGenerator.java + src/share/classes/com/sun/media/sound/SoftFilter.java + src/share/classes/com/sun/media/sound/SoftInstrument.java + src/share/classes/com/sun/media/sound/SoftJitterCorrector.java + src/share/classes/com/sun/media/sound/SoftLanczosResampler.java + src/share/classes/com/sun/media/sound/SoftLimiter.java + src/share/classes/com/sun/media/sound/SoftLinearResampler.java + src/share/classes/com/sun/media/sound/SoftLinearResampler2.java + src/share/classes/com/sun/media/sound/SoftLowFrequencyOscillator.java + src/share/classes/com/sun/media/sound/SoftMainMixer.java + src/share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java + src/share/classes/com/sun/media/sound/SoftMixingClip.java + src/share/classes/com/sun/media/sound/SoftMixingDataLine.java + src/share/classes/com/sun/media/sound/SoftMixingMainMixer.java + src/share/classes/com/sun/media/sound/SoftMixingMixer.java + src/share/classes/com/sun/media/sound/SoftMixingMixerProvider.java + src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java + src/share/classes/com/sun/media/sound/SoftPerformer.java + src/share/classes/com/sun/media/sound/SoftPointResampler.java + src/share/classes/com/sun/media/sound/SoftProcess.java + src/share/classes/com/sun/media/sound/SoftProvider.java + src/share/classes/com/sun/media/sound/SoftReceiver.java + src/share/classes/com/sun/media/sound/SoftResampler.java + src/share/classes/com/sun/media/sound/SoftResamplerStreamer.java + src/share/classes/com/sun/media/sound/SoftReverb.java + src/share/classes/com/sun/media/sound/SoftShortMessage.java + src/share/classes/com/sun/media/sound/SoftSincResampler.java + src/share/classes/com/sun/media/sound/SoftSynthesizer.java + src/share/classes/com/sun/media/sound/SoftTuning.java + src/share/classes/com/sun/media/sound/SoftVoice.java + src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java + src/share/classes/com/sun/media/sound/WaveFloatFileReader.java + src/share/classes/com/sun/media/sound/WaveFloatFileWriter.java ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.MidiDeviceProvider ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.MidiFileReader ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.SoundbankReader ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.AudioFileReader ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.FormatConversionProvider ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.MixerProvider - src/share/lib/audio/soundbank.gm + test/javax/sound/midi/Gervill/AudioFloatConverter/GetFormat.java + test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Available.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Close.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFormat.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFrameLength.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/MarkSupported.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Read.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArray.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArrayIntInt.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Reset.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Skip.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankFile.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream2.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankUrl.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/ding.dls + test/javax/sound/midi/Gervill/EmergencySoundbank/TestCreateSoundbank.java + test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java + test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java + test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java + test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java + test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java + test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetAttenuation.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetChannels.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopLength.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopStart.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetPitchCorrection.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBuffer.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormatFloat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferFloat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Open.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Set8BitExtensionBuffer.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/SetLoopType.java + test/javax/sound/midi/Gervill/ModelDestination/NewModelDestination.java + test/javax/sound/midi/Gervill/ModelDestination/NewModelDestinationModelIdentifier.java + test/javax/sound/midi/Gervill/ModelDestination/SetIdentifier.java + test/javax/sound/midi/Gervill/ModelDestination/SetTransform.java + test/javax/sound/midi/Gervill/ModelIdentifier/EqualsObject.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierString.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringInt.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringString.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringStringInt.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetInstance.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetObject.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetVariable.java + test/javax/sound/midi/Gervill/ModelPerformer/GetOscillators.java + test/javax/sound/midi/Gervill/ModelPerformer/SetConnectionBlocks.java + test/javax/sound/midi/Gervill/ModelPerformer/SetDefaultConnectionsEnabled.java + test/javax/sound/midi/Gervill/ModelPerformer/SetExclusiveClass.java + test/javax/sound/midi/Gervill/ModelPerformer/SetKeyFrom.java + test/javax/sound/midi/Gervill/ModelPerformer/SetKeyTo.java + test/javax/sound/midi/Gervill/ModelPerformer/SetName.java + test/javax/sound/midi/Gervill/ModelPerformer/SetSelfNonExclusive.java + test/javax/sound/midi/Gervill/ModelPerformer/SetVelFrom.java + test/javax/sound/midi/Gervill/ModelPerformer/SetVelTo.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSource.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifier.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBoolean.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBoolean.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBooleanInt.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierModelTransform.java + test/javax/sound/midi/Gervill/ModelSource/SetIdentifier.java + test/javax/sound/midi/Gervill/ModelSource/SetTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBoolean.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBoolean.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBooleanInt.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetDirection.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetPolarity.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformAbsolute.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConcave.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConvex.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformLinear.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformSwitch.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java + test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java + test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java + test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java + test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankFile.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream2.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankUrl.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/ding.sf2 + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrument.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformer.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArray.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/Clear.java + test/javax/sound/midi/Gervill/SimpleInstrument/SetName.java + test/javax/sound/midi/Gervill/SimpleInstrument/SetPatch.java + test/javax/sound/midi/Gervill/SimpleSoundbank/AddInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/AddResource.java + test/javax/sound/midi/Gervill/SimpleSoundbank/GetInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/RemoveInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetDescription.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetName.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetVendor.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetVersion.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Array.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Clear.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Get.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/NewSoftAudioBuffer.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetFormat.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetPropertyInfo.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/Open.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/OpenStream.java + test/javax/sound/midi/Gervill/SoftChannel/AllNotesOff.java + test/javax/sound/midi/Gervill/SoftChannel/AllSoundOff.java + test/javax/sound/midi/Gervill/SoftChannel/ChannelPressure.java + test/javax/sound/midi/Gervill/SoftChannel/Controller.java + test/javax/sound/midi/Gervill/SoftChannel/LocalControl.java + test/javax/sound/midi/Gervill/SoftChannel/Mono.java + test/javax/sound/midi/Gervill/SoftChannel/Mute.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOff.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOff2.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOn.java + test/javax/sound/midi/Gervill/SoftChannel/Omni.java + test/javax/sound/midi/Gervill/SoftChannel/PitchBend.java + test/javax/sound/midi/Gervill/SoftChannel/PolyPressure.java + test/javax/sound/midi/Gervill/SoftChannel/ProgramChange.java + test/javax/sound/midi/Gervill/SoftChannel/ResetAllControllers.java + test/javax/sound/midi/Gervill/SoftChannel/SoftTestUtils.java + test/javax/sound/midi/Gervill/SoftChannel/Solo.java + test/javax/sound/midi/Gervill/SoftCubicResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal_mono.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive_mono.java + test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java + test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftProvider/GetDevice.java + test/javax/sound/midi/Gervill/SoftReceiver/Close.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ActiveSense.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_AllNotesOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_AllSoundOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ChannelPressure.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Controller.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Mono.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_AllChannels.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Delayed.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Multiple.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Omni.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_PitchBend.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_PolyPressure.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ProgramChange.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ResetAllControllers.java + test/javax/sound/midi/Gervill/SoftReceiver/SoftTestUtils.java + test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftSynthesizer/Close.java + test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetChannels.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetDefaultSoundbank.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetDeviceInfo.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetLatency.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxPolyphony.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxReceivers.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxTransmitters.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMicrosecondPosition.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver2.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceivers.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitter.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitters.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetVoiceStatus.java + test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java + test/javax/sound/midi/Gervill/SoftSynthesizer/IsOpen.java + test/javax/sound/midi/Gervill/SoftSynthesizer/IsSoundbankSupported.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java + test/javax/sound/midi/Gervill/SoftSynthesizer/OpenStream.java + test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/TestRender1.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/ding.sf2 + test/javax/sound/midi/Gervill/SoftSynthesizer/expresso.mid + test/javax/sound/midi/Gervill/SoftTuning/GetName.java + test/javax/sound/midi/Gervill/SoftTuning/GetTuning.java + test/javax/sound/midi/Gervill/SoftTuning/GetTuningInt.java + test/javax/sound/midi/Gervill/SoftTuning/Load1.java + test/javax/sound/midi/Gervill/SoftTuning/Load2.java + test/javax/sound/midi/Gervill/SoftTuning/Load4.java + test/javax/sound/midi/Gervill/SoftTuning/Load5.java + test/javax/sound/midi/Gervill/SoftTuning/Load6.java + test/javax/sound/midi/Gervill/SoftTuning/Load7.java + test/javax/sound/midi/Gervill/SoftTuning/Load8.java + test/javax/sound/midi/Gervill/SoftTuning/Load9.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuning.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningByteArray.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatch.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatchByteArray.java From omajid at redhat.com Wed Jan 21 08:47:38 2009 From: omajid at redhat.com (Omair Majid) Date: Wed, 21 Jan 2009 11:47:38 -0500 Subject: Background/Foreground colors and Gtk Look and Feel Message-ID: <497751AA.7010802@redhat.com> Hi, Sorry for sending this email again, but I didn't get any response last time. Is there a better place for asking this? I have noticed a few issues in the Gtk Look and Feel and would like to know what the correct behaviour should be. The attached program shows a few of my concerns. 1) For each of the components, setForeground(color) and/or setBackground(color) assignments are randomly ignored. Is this the expected behaviour? I can understand that using the native look and feel, the feel is exactly preserved and the programmer's preferences are ignored. But there doesn't seem to be any consistency - some components accept the color changes, some silently ignore it. Is there a list showing whether setForeground() and setBackground() is ignored for each swing component with the gtk look and feel? 2) The behaviour varies across jdk6 and openjdk6. For example, the closed-source jdk6 respects JTextPane.setBackground(UIManager.getColor("Panel.background")) but openjdk6 ignores it. In situations like this, what is the correct behaviour? Should I attempt to patch openjdk6 to behave more like closed source jdk6? Thanks, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: TestGtkBackground.java Type: text/x-java Size: 2163 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20090121/787a7b14/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: openjdk6.png Type: image/png Size: 14387 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20090121/787a7b14/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: sun-jdk.png Type: image/png Size: 11787 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20090121/787a7b14/attachment-0001.png From peter.zhelezniakov at sun.com Wed Jan 21 10:33:51 2009 From: peter.zhelezniakov at sun.com (peter.zhelezniakov at sun.com) Date: Wed, 21 Jan 2009 18:33:51 +0000 Subject: hg: jdk7/swing/jdk: 6792401: Windows LAF: ActiveWindowsIcon should not be greedy with fallback icon Message-ID: <20090121183402.C2A32DD38@hg.openjdk.java.net> Changeset: cda097df492f Author: peterz Date: 2009-01-21 21:30 +0300 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/cda097df492f 6792401: Windows LAF: ActiveWindowsIcon should not be greedy with fallback icon Summary: Fallback mechanism changed to use symbolic name instead of icon. Reviewed-by: igor, rupashka ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java From naoto.sato at sun.com Wed Jan 21 14:09:08 2009 From: naoto.sato at sun.com (naoto.sato at sun.com) Date: Wed, 21 Jan 2009 22:09:08 +0000 Subject: hg: jdk7/swing/jdk: 6627549: ISO 3166 code addition: Saint Barthelemy and Saint Martin; ... Message-ID: <20090121220920.26819DD71@hg.openjdk.java.net> Changeset: cf591ddc3456 Author: naoto Date: 2009-01-21 13:58 -0800 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/cf591ddc3456 6627549: ISO 3166 code addition: Saint Barthelemy and Saint Martin 6786276: Locale.getISOCountries() still contains country code "CS" Reviewed-by: okutsu ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/LocaleNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Locale/LocaleTest.java ! test/sun/text/resources/LocaleData From Kirill.Kirichenko at Sun.COM Thu Jan 22 03:12:52 2009 From: Kirill.Kirichenko at Sun.COM (Kirill Kirichenko) Date: Thu, 22 Jan 2009 14:12:52 +0300 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <497751AA.7010802@redhat.com> References: <497751AA.7010802@redhat.com> Message-ID: <497854B4.4050406@sun.com> Hi Omar Sorry for delay from out side. I'm a responsible engineer for GTK L&F. Omair Majid wrote: > I have noticed a few issues in the Gtk Look and Feel and would like to > know what the correct behaviour should be. The attached program shows a > few of my concerns. > > 1) For each of the components, setForeground(color) and/or > setBackground(color) assignments are randomly ignored. Is this the > expected behaviour? I can understand that using the native look and > feel, the feel is exactly preserved and the programmer's preferences are > ignored. But there doesn't seem to be any consistency - some components > accept the color changes, some silently ignore it. Is there a list > showing whether setForeground() and setBackground() is ignored for each > swing component with the gtk look and feel? Generally GTK L&F leverages theme settings for colors, indents and fonts. And you shouldn't be able to change them using standard swing API when GTK L&F is active. Sometimes this does work but you shouldn't use this feature. This is the policy for GTK L&F. Actually the have been similar requests and I tried to resolve the issue. The thing is GTK itself doesn't allow changing colors freely for all components it just uses the theme settings. > 2) The behaviour varies across jdk6 and openjdk6. For example, the > closed-source jdk6 respects > JTextPane.setBackground(UIManager.getColor("Panel.background")) but > openjdk6 ignores it. In situations like this, what is the correct > behaviour? Should I attempt to patch openjdk6 to behave more like closed > source jdk6? It may happen because the codebases slightly different. I haven't applied all fixes to openjdk6 which I have to jdk6. Hope that helps. From omajid at redhat.com Thu Jan 22 07:40:44 2009 From: omajid at redhat.com (Omair Majid) Date: Thu, 22 Jan 2009 10:40:44 -0500 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <497854B4.4050406@sun.com> References: <497751AA.7010802@redhat.com> <497854B4.4050406@sun.com> Message-ID: <4978937C.6080101@redhat.com> Hi Kirill, Kirill Kirichenko wrote: > Hi Omar > Sorry for delay from out side. > I'm a responsible engineer for GTK L&F. > No problem. I am just glad I am getting a response from someone who knows this stuff. > > Omair Majid wrote: >> I have noticed a few issues in the Gtk Look and Feel and would like to >> know what the correct behaviour should be. The attached program shows >> a few of my concerns. >> >> 1) For each of the components, setForeground(color) and/or >> setBackground(color) assignments are randomly ignored. Is this the >> expected behaviour? I can understand that using the native look and >> feel, the feel is exactly preserved and the programmer's preferences >> are ignored. But there doesn't seem to be any consistency - some >> components accept the color changes, some silently ignore it. Is there >> a list showing whether setForeground() and setBackground() is ignored >> for each swing component with the gtk look and feel? > Generally GTK L&F leverages theme settings for colors, indents and > fonts. And you shouldn't be able to change them using standard swing API > when GTK L&F is active. Sometimes this does work but you shouldn't use > this feature. This is the policy for GTK L&F. Actually the have been > similar requests and I tried to resolve the issue. The thing is GTK > itself doesn't allow changing colors freely for all components it just > uses the theme settings. So the _correct_ behaviour is that setBackground()/setForeground() are ignored completely? So if a component actually responds to setBackground() or setForeground(), it's a bug? > > >> 2) The behaviour varies across jdk6 and openjdk6. For example, the >> closed-source jdk6 respects >> JTextPane.setBackground(UIManager.getColor("Panel.background")) but >> openjdk6 ignores it. In situations like this, what is the correct >> behaviour? Should I attempt to patch openjdk6 to behave more like >> closed source jdk6? > It may happen because the codebases slightly different. I haven't > applied all fixes to openjdk6 which I have to jdk6. > > Hope that helps. I am still a little confused. If closed source jdk allows setting the background, and openjdk doesn't, doesn't that mean openjdk is correct and the fixes should be applied to the closed source jdk? Basically, I am asking what the ideal behaviour should be. Should setBackground()/setForeground() have any effect when using the gtk look and feel? Cheers, Omair From Kirill.Kirichenko at Sun.COM Thu Jan 22 07:58:45 2009 From: Kirill.Kirichenko at Sun.COM (Kirill Kirichenko) Date: Thu, 22 Jan 2009 18:58:45 +0300 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <4978937C.6080101@redhat.com> References: <497751AA.7010802@redhat.com> <497854B4.4050406@sun.com> <4978937C.6080101@redhat.com> Message-ID: <497897B5.6020205@sun.com> Omair Majid wrote: > So the _correct_ behaviour is that setBackground()/setForeground() are > ignored completely? So if a component actually responds to > setBackground() or setForeground(), it's a bug? It's not a bug. It just happens to be so. I mean you shouldn't count on this. Altering colors in GTK L&F rather than in the theme config file is not supported. > I am still a little confused. If closed source jdk allows setting the > background, and openjdk doesn't, doesn't that mean openjdk is correct > and the fixes should be applied to the closed source jdk? Basically, I > am asking what the ideal behaviour should be. Should > setBackground()/setForeground() have any effect when using the gtk look > and feel? No they shouldn't. From swingler at apple.com Thu Jan 22 08:27:12 2009 From: swingler at apple.com (Mike Swingler) Date: Thu, 22 Jan 2009 08:27:12 -0800 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <497854B4.4050406@sun.com> References: <497751AA.7010802@redhat.com> <497854B4.4050406@sun.com> Message-ID: <5E3DA69E-0318-412A-9853-613AD7346C2C@apple.com> On Jan 22, 2009, at 3:12 AM, Kirill Kirichenko wrote: > Hi Omar > Sorry for delay from out side. > I'm a responsible engineer for GTK L&F. > > Omair Majid wrote: > >> I have noticed a few issues in the Gtk Look and Feel and would like >> to know what the correct behaviour should be. The attached program >> shows a few of my concerns. >> 1) For each of the components, setForeground(color) and/or >> setBackground(color) assignments are randomly ignored. Is this the >> expected behaviour? I can understand that using the native look and >> feel, the feel is exactly preserved and the programmer's >> preferences are ignored. But there doesn't seem to be any >> consistency - some components accept the color changes, some >> silently ignore it. Is there a list showing whether setForeground() >> and setBackground() is ignored for each swing component with the >> gtk look and feel? > > Generally GTK L&F leverages theme settings for colors, indents and > fonts. And you shouldn't be able to change them using standard swing > API when GTK L&F is active. Sometimes this does work but you > shouldn't use this feature. This is the policy for GTK L&F. Actually > the have been similar requests and I tried to resolve the issue. The > thing is GTK itself doesn't allow changing colors freely for all > components it just uses the theme settings. This is basically the policy of the Aqua Look and Feel on Mac OS X as well. Sometimes we do pick up the foreground/background colors for some controls where it makes sense, or the TCK requires us to, but generally, we use our own system artwork to draw these controls. Not every component (particularly non-rectangular ones) have a good sense of what a "background" color is. Also, on Mac OS X, we are particularly sensitive to allowing developers to create rainbow kaleidoscope apps that clash with the rest of the Mac OS X desktop experience, and try to make Java apps that have not necessarily tested on our platform still look like Mac apps. >> 2) The behaviour varies across jdk6 and openjdk6. For example, the >> closed-source jdk6 respects >> JTextPane.setBackground(UIManager.getColor("Panel.background")) but >> openjdk6 ignores it. In situations like this, what is the correct >> behaviour? Should I attempt to patch openjdk6 to behave more like >> closed source jdk6? > > It may happen because the codebases slightly different. I haven't > applied all fixes to openjdk6 which I have to jdk6. > > Hope that helps. Cheers, Mike Swingler Java Runtime Engineer Apple Inc. From omajid at redhat.com Thu Jan 22 10:46:27 2009 From: omajid at redhat.com (Omair Majid) Date: Thu, 22 Jan 2009 13:46:27 -0500 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <497897B5.6020205@sun.com> References: <497751AA.7010802@redhat.com> <497854B4.4050406@sun.com> <4978937C.6080101@redhat.com> <497897B5.6020205@sun.com> Message-ID: <4978BF03.6010801@redhat.com> Hi Kirill, Kirill Kirichenko wrote: > > > Omair Majid wrote: >> So the _correct_ behaviour is that setBackground()/setForeground() are >> ignored completely? So if a component actually responds to >> setBackground() or setForeground(), it's a bug? > It's not a bug. It just happens to be so. I mean you shouldn't count on > this. Altering colors in GTK L&F rather than in the theme config file is > not supported. > >> I am still a little confused. If closed source jdk allows setting the >> background, and openjdk doesn't, doesn't that mean openjdk is correct >> and the fixes should be applied to the closed source jdk? Basically, I >> am asking what the ideal behaviour should be. Should >> setBackground()/setForeground() have any effect when using the gtk >> look and feel? > No they shouldn't. Thanks. That clears up things. Cheers, Omair From omajid at redhat.com Thu Jan 22 11:01:35 2009 From: omajid at redhat.com (Omair Majid) Date: Thu, 22 Jan 2009 14:01:35 -0500 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <5E3DA69E-0318-412A-9853-613AD7346C2C@apple.com> References: <497751AA.7010802@redhat.com> <497854B4.4050406@sun.com> <5E3DA69E-0318-412A-9853-613AD7346C2C@apple.com> Message-ID: <4978C28F.4060407@redhat.com> Hi Mike, Mike Swingler wrote: > On Jan 22, 2009, at 3:12 AM, Kirill Kirichenko wrote: > >> Hi Omar >> Sorry for delay from out side. >> I'm a responsible engineer for GTK L&F. >> >> Omair Majid wrote: >> >>> I have noticed a few issues in the Gtk Look and Feel and would like >>> to know what the correct behaviour should be. The attached program >>> shows a few of my concerns. >>> 1) For each of the components, setForeground(color) and/or >>> setBackground(color) assignments are randomly ignored. Is this the >>> expected behaviour? I can understand that using the native look and >>> feel, the feel is exactly preserved and the programmer's preferences >>> are ignored. But there doesn't seem to be any consistency - some >>> components accept the color changes, some silently ignore it. Is >>> there a list showing whether setForeground() and setBackground() is >>> ignored for each swing component with the gtk look and feel? >> >> Generally GTK L&F leverages theme settings for colors, indents and >> fonts. And you shouldn't be able to change them using standard swing >> API when GTK L&F is active. Sometimes this does work but you shouldn't >> use this feature. This is the policy for GTK L&F. Actually the have >> been similar requests and I tried to resolve the issue. The thing is >> GTK itself doesn't allow changing colors freely for all components it >> just uses the theme settings. > > This is basically the policy of the Aqua Look and Feel on Mac OS X as > well. Sometimes we do pick up the foreground/background colors for some > controls where it makes sense, or the TCK requires us to, but generally, > we use our own system artwork to draw these controls. Thanks for the insight! > Not every component (particularly non-rectangular ones) have a good > sense of what a "background" color is. Also, on Mac OS X, we are > particularly sensitive to allowing developers to create rainbow > kaleidoscope apps that clash with the rest of the Mac OS X desktop > experience, and try to make Java apps that have not necessarily tested > on our platform still look like Mac apps. I agree, getting Java apps to blend in with the rest of the desktop seems like the right thing to do. I just wasnt sure if that was intentional or not in the gtk look and feel. Cheers, Omair From Joshua.Marinacci at Sun.COM Thu Jan 22 11:28:07 2009 From: Joshua.Marinacci at Sun.COM (Joshua Marinacci) Date: Thu, 22 Jan 2009 11:28:07 -0800 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <4978C28F.4060407@redhat.com> References: <497751AA.7010802@redhat.com> <497854B4.4050406@sun.com> <5E3DA69E-0318-412A-9853-613AD7346C2C@apple.com> <4978C28F.4060407@redhat.com> Message-ID: <42C4FEB2-EE4B-4B5B-A244-D9A11A737663@sun.com> I believe I had filed a bug some time ago to clarify the spec of 'what does background / foreground actually mean for Swing components'. I ran into some issues with fixing bugs in the Windows Look and Feel. As we started using more of the actual skins from the OS we no longer used the background color set on a component, which was filed as a regression against previous versions of the Windows Look and Feel. This is one of those nasty 'what is the definition of correct' kind of bugs. :) -j On Jan 22, 2009, at 11:01 AM, Omair Majid wrote: > Hi Mike, > > Mike Swingler wrote: >> On Jan 22, 2009, at 3:12 AM, Kirill Kirichenko wrote: >>> Hi Omar >>> Sorry for delay from out side. >>> I'm a responsible engineer for GTK L&F. >>> >>> Omair Majid wrote: >>> >>>> I have noticed a few issues in the Gtk Look and Feel and would >>>> like to know what the correct behaviour should be. The attached >>>> program shows a few of my concerns. >>>> 1) For each of the components, setForeground(color) and/or >>>> setBackground(color) assignments are randomly ignored. Is this >>>> the expected behaviour? I can understand that using the native >>>> look and feel, the feel is exactly preserved and the programmer's >>>> preferences are ignored. But there doesn't seem to be any >>>> consistency - some components accept the color changes, some >>>> silently ignore it. Is there a list showing whether >>>> setForeground() and setBackground() is ignored for each swing >>>> component with the gtk look and feel? >>> >>> Generally GTK L&F leverages theme settings for colors, indents and >>> fonts. And you shouldn't be able to change them using standard >>> swing API when GTK L&F is active. Sometimes this does work but you >>> shouldn't use this feature. This is the policy for GTK L&F. >>> Actually the have been similar requests and I tried to resolve the >>> issue. The thing is GTK itself doesn't allow changing colors >>> freely for all components it just uses the theme settings. >> This is basically the policy of the Aqua Look and Feel on Mac OS X >> as well. Sometimes we do pick up the foreground/background colors >> for some controls where it makes sense, or the TCK requires us to, >> but generally, we use our own system artwork to draw these controls. > > Thanks for the insight! > >> Not every component (particularly non-rectangular ones) have a good >> sense of what a "background" color is. Also, on Mac OS X, we are >> particularly sensitive to allowing developers to create rainbow >> kaleidoscope apps that clash with the rest of the Mac OS X desktop >> experience, and try to make Java apps that have not necessarily >> tested on our platform still look like Mac apps. > > I agree, getting Java apps to blend in with the rest of the desktop > seems like the right thing to do. I just wasnt sure if that was > intentional or not in the gtk look and feel. > > Cheers, > > Omair From uckelman at nomic.net Thu Jan 22 13:21:46 2009 From: uckelman at nomic.net (Joel Uckelman) Date: Thu, 22 Jan 2009 22:21:46 +0100 Subject: Background/Foreground colors and Gtk Look and Feel Message-ID: <20090122212147.06AC310085@charybdis.ellipsis.cx> Hi, I'm the guy who reported the bug which Omair was referring to. The context in which in which I noticed that the GTK L&F ignores setBackground() is that I was subclassing JTextPane in order to get a label which would support both word wrap and full justification of text. In this case, the correct background color is really not what the theme thinks the background color should be for a JTextPane, but rather what the theme thinks the background color should be for a JLabel. This kind of policy makes the uses to which components can be put very narrow if you're using a native L&F. To be clear: What I want to achieve is to have this component of mine to have the same background color as a JLabel, because it *is* functionally a JLabel, despite that it inherits from JTextPane. I'm not trying to circumvent the color scheme provided by the L&F here, I'm trying to follow it---so it's very disheartening to read the replies on this thread. If the intended behavior of native L&Fs is to ignore setBackground(), then what's the right way to do what I'm trying to do? -- J. From Joshua.Marinacci at Sun.COM Thu Jan 22 14:18:44 2009 From: Joshua.Marinacci at Sun.COM (Joshua Marinacci) Date: Thu, 22 Jan 2009 14:18:44 -0800 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <20090122212147.06AC310085@charybdis.ellipsis.cx> References: <20090122212147.06AC310085@charybdis.ellipsis.cx> Message-ID: <4D232E5A-9517-48FE-B431-B2AED9B79B26@sun.com> If we wish to support custom components that try to fit in with the native look and feels (which I think is your goal, right? To use a textpane for a fancy label?), then the look and feel should pre- populate the defaults table with the right colors. Then other 3rd party code and query that table when trying to do the right thing. This still means that the native L&F can ignore setBackground, but at least you'll be able to make your own code respect colors properly. - Josh On Jan 22, 2009, at 1:21 PM, Joel Uckelman wrote: > Hi, > > I'm the guy who reported the bug which Omair was referring to. The > context > in which in which I noticed that the GTK L&F ignores setBackground() > is > that I was subclassing JTextPane in order to get a label which would > support > both word wrap and full justification of text. In this case, the > correct > background color is really not what the theme thinks the background > color > should be for a JTextPane, but rather what the theme thinks the > background > color should be for a JLabel. > > This kind of policy makes the uses to which components can be put > very narrow > if you're using a native L&F. To be clear: What I want to achieve is > to have > this component of mine to have the same background color as a > JLabel, because > it *is* functionally a JLabel, despite that it inherits from > JTextPane. I'm not > trying to circumvent the color scheme provided by the L&F here, I'm > trying to > follow it---so it's very disheartening to read the replies on this > thread. > > If the intended behavior of native L&Fs is to ignore > setBackground(), then > what's the right way to do what I'm trying to do? > > -- > J. From swingler at apple.com Thu Jan 22 16:23:49 2009 From: swingler at apple.com (Mike Swingler) Date: Thu, 22 Jan 2009 16:23:49 -0800 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <20090122212147.06AC310085@charybdis.ellipsis.cx> References: <20090122212147.06AC310085@charybdis.ellipsis.cx> Message-ID: <93D8BA0A-27BE-4D81-AE80-7883450A0FF5@apple.com> On Jan 22, 2009, at 1:21 PM, Joel Uckelman wrote: > Hi, > > I'm the guy who reported the bug which Omair was referring to. The > context > in which in which I noticed that the GTK L&F ignores setBackground() > is > that I was subclassing JTextPane in order to get a label which would > support > both word wrap and full justification of text. In this case, the > correct > background color is really not what the theme thinks the background > color > should be for a JTextPane, but rather what the theme thinks the > background > color should be for a JLabel. In this case, Aqua actually implements it's background as a border, and by setting that border to null, we turn off both the text field edge as well as the default white background. If someone just sets a background color on our JTextFields, with simply do a fillRect() with that color inside of the Aqua edges (and it looks terrible). Most of the time, when folks are trying to create a multi-line label, they null out the border too, so we catch those cases most of the time. > This kind of policy makes the uses to which components can be put > very narrow > if you're using a native L&F. To be clear: What I want to achieve is > to have > this component of mine to have the same background color as a > JLabel, because > it *is* functionally a JLabel, despite that it inherits from > JTextPane. I'm not > trying to circumvent the color scheme provided by the L&F here, I'm > trying to > follow it---so it's very disheartening to read the replies on this > thread. Well, this all begs for a more powerful JLabel...but I digress. > If the intended behavior of native L&Fs is to ignore > setBackground(), then > what's the right way to do what I'm trying to do? You might want to replace that component's peer with the BasicTextPaneUI or another known UI delegate, since you are stripping all the usual adornments off of it anyway. I fear that might reset some things like ctrl-C vs. meta-C for copy (if you allow selection), but all the other adornments like the Caret, or keybindings probably aren't relevant, since this won't be editable. Best of luck, Mike Swingler Java Runtime Engineer Apple Inc. From sergey.malenkov at sun.com Fri Jan 23 07:31:07 2009 From: sergey.malenkov at sun.com (sergey.malenkov at sun.com) Date: Fri, 23 Jan 2009 15:31:07 +0000 Subject: hg: jdk7/swing/jdk: 4222508: JColorChooser ignores setEnabled() function call Message-ID: <20090123153119.49DE4DFDF@hg.openjdk.java.net> Changeset: f650e6e22c16 Author: malenkov Date: 2009-01-23 18:31 +0300 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/f650e6e22c16 4222508: JColorChooser ignores setEnabled() function call Reviewed-by: peterz, rupashka ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java + test/javax/swing/JColorChooser/Test4222508.html + test/javax/swing/JColorChooser/Test4222508.java From uckelman at nomic.net Fri Jan 23 12:10:43 2009 From: uckelman at nomic.net (Joel Uckelman) Date: Fri, 23 Jan 2009 21:10:43 +0100 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <4D232E5A-9517-48FE-B431-B2AED9B79B26@sun.com> References: <20090122212147.06AC310085@charybdis.ellipsis.cx> <4D232E5A-9517-48FE-B431-B2AED9B79B26@sun.com> Message-ID: <20090123201044.303B110086@charybdis.ellipsis.cx> Thus spake Joshua Marinacci: > If we wish to support custom components that try to fit in with the > native look and feels (which I think is your goal, right? To use a > textpane for a fancy label?), Yes, that is my goal. > then the look and feel should pre- > populate the defaults table with the right colors. Then other 3rd > party code and query that table when trying to do the right thing. > This still means that the native L&F can ignore setBackground, but at > least you'll be able to make your own code respect colors properly. > > - Josh If I can't call setBackground(), though, how do I tell the JTextPane what color its background should be? Getting the Color I want is no problem---I can fetch that with UIManager.getColor("Label.background") ---what I don't see now is what I'm supposed do with that once I have it. I don't want to change the background color for all JTextPanes, so calling setColor on "TextPane.background" is no good. Overriding paintComponent() is of no use because I need super.paintComponent() to paint the text for me, but it also paints the background. I can't subclass the UI delegate, because the user might be using some L&F I don't even have myself. Making my component non-opaque only works if I know that its parent already has the same background color as a JLabel would have. I see no way to do what I'm trying to do if I can't use setBackground() for it. What am I missing here? -- J. From i30817 at gmail.com Fri Jan 23 17:47:41 2009 From: i30817 at gmail.com (Paulo Levi) Date: Sat, 24 Jan 2009 01:47:41 +0000 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <20090123201044.303B110086@charybdis.ellipsis.cx> References: <20090122212147.06AC310085@charybdis.ellipsis.cx> <4D232E5A-9517-48FE-B431-B2AED9B79B26@sun.com> <20090123201044.303B110086@charybdis.ellipsis.cx> Message-ID: <212322090901231747xd84083di534461e011d37bb1@mail.gmail.com> Well this should be reversed. I have a custom component to read text, and i (and my users, of which i am one) want to have the ability to change the background color if i damn well want to. What the problem with setting black on white for reading text? If you're going to do such a (imo) stupid thing at least allow us to set exception on a per application or per component basis. From i30817 at gmail.com Fri Jan 23 17:48:47 2009 From: i30817 at gmail.com (Paulo Levi) Date: Sat, 24 Jan 2009 01:48:47 +0000 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <212322090901231747xd84083di534461e011d37bb1@mail.gmail.com> References: <20090122212147.06AC310085@charybdis.ellipsis.cx> <4D232E5A-9517-48FE-B431-B2AED9B79B26@sun.com> <20090123201044.303B110086@charybdis.ellipsis.cx> <212322090901231747xd84083di534461e011d37bb1@mail.gmail.com> Message-ID: <212322090901231748m56495cdgc1902d7788916bb5@mail.gmail.com> And by the way i do respect OS settings. There is a big button saying reset somewhere in my color chooser. From i30817 at gmail.com Fri Jan 23 17:59:09 2009 From: i30817 at gmail.com (Paulo Levi) Date: Sat, 24 Jan 2009 01:59:09 +0000 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <212322090901231748m56495cdgc1902d7788916bb5@mail.gmail.com> References: <20090122212147.06AC310085@charybdis.ellipsis.cx> <4D232E5A-9517-48FE-B431-B2AED9B79B26@sun.com> <20090123201044.303B110086@charybdis.ellipsis.cx> <212322090901231747xd84083di534461e011d37bb1@mail.gmail.com> <212322090901231748m56495cdgc1902d7788916bb5@mail.gmail.com> Message-ID: <212322090901231759l24840a1x842413236c407da3@mail.gmail.com> Also this is strange, but Joshua when talk about the "defaults table" you really mean SystemColor, the special case mutable Color right? Because that is what i use to reset my components (yes, a manual process) Color.text and such. There is another way based on class name? From yuka.kamiya at sun.com Sun Jan 25 16:31:51 2009 From: yuka.kamiya at sun.com (yuka.kamiya at sun.com) Date: Mon, 26 Jan 2009 00:31:51 +0000 Subject: hg: jdk7/swing/jdk: 6796489: (tz) Support tzdata2009a Message-ID: <20090126003211.8D7E0E109@hg.openjdk.java.net> Changeset: d75ae3f11e01 Author: peytoia Date: 2009-01-26 09:19 +0900 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/d75ae3f11e01 6796489: (tz) Support tzdata2009a Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java From Joshua.Marinacci at Sun.COM Mon Jan 26 20:12:52 2009 From: Joshua.Marinacci at Sun.COM (Joshua Marinacci) Date: Mon, 26 Jan 2009 20:12:52 -0800 Subject: Background/Foreground colors and Gtk Look and Feel In-Reply-To: <212322090901231759l24840a1x842413236c407da3@mail.gmail.com> References: <20090122212147.06AC310085@charybdis.ellipsis.cx> <4D232E5A-9517-48FE-B431-B2AED9B79B26@sun.com> <20090123201044.303B110086@charybdis.ellipsis.cx> <212322090901231747xd84083di534461e011d37bb1@mail.gmail.com> <212322090901231748m56495cdgc1902d7788916bb5@mail.gmail.com> <212322090901231759l24840a1x842413236c407da3@mail.gmail.com> Message-ID: I mean the UIDefaults table, which is populated by Swing Look and Feels. In any case, if a native look and feel ignores setBackground then knowing the correct color still won't help. The question is whether components under native look and feels are required to honor fore/back colors. I'm curious what native GTK apps do. - Josh On Jan 23, 2009, at 5:59 PM, Paulo Levi wrote: > Also this is strange, but Joshua when talk about the "defaults table" > you really mean SystemColor, the special case mutable Color right? > Because that is what i use to reset my components (yes, a manual > process) Color.text and such. There is another way based on class > name? From sergey.malenkov at sun.com Thu Jan 29 04:32:42 2009 From: sergey.malenkov at sun.com (sergey.malenkov at sun.com) Date: Thu, 29 Jan 2009 12:32:42 +0000 Subject: hg: jdk7/swing/jdk: 6788531: java.beans.Statement imposes excessive access control Message-ID: <20090129123254.08273E3A9@hg.openjdk.java.net> Changeset: e02f2d591cd5 Author: malenkov Date: 2009-01-29 15:34 +0300 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e02f2d591cd5 6788531: java.beans.Statement imposes excessive access control Reviewed-by: peterz, rupashka ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/Statement.java + test/java/beans/EventHandler/Test6788531.java + test/java/beans/Statement/Test6788531.java From pavel.porvatov at sun.com Thu Jan 29 08:10:24 2009 From: pavel.porvatov at sun.com (pavel.porvatov at sun.com) Date: Thu, 29 Jan 2009 16:10:24 +0000 Subject: hg: jdk7/swing/jdk: 6794836: BasicSliderUI throws NullPointerExc when JSlider maximum is Integer.MAX_VALUE Message-ID: <20090129161036.C8A7DE3BD@hg.openjdk.java.net> Changeset: ff6633279632 Author: rupashka Date: 2009-01-29 19:06 +0300 URL: http://hg.openjdk.java.net/jdk7/swing/jdk/rev/ff6633279632 6794836: BasicSliderUI throws NullPointerExc when JSlider maximum is Integer.MAX_VALUE Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6794836/bug6794836.java