Community
Participate
Working Groups
The deprecated classes are: CharacterKey IKeyFormatter Key KeyFormatterFactory KeySequence KeyStroke ModifierKey NaturalKey ParseException SpecialKey SWTKeySupport The only class that is not deprecated is IBindingService.java. I found following usages in platform and jdt: CharacterKey MacKeyFormatter NativeKeyFormatter IKeyFormatter AbstractKeyFormatter.java (implementation of interface KeyFormatterFactory.java (also deprecated) Key AbstractInformationControl.java AbstractInformationControl.java AbstractKeyFormatter.java Bug36420Test.java Bug42035Test.java CommandLegacyWrapper.java CommandManagerLegacyWrapper.java CompactKeyFormatter.java EmacsKeyFormatter.java FormalKeyFormatter.java HierarchyInformationControl.java HierarchyInformationControl.java ICommandManager.java IKeySequenceBinding.java JavaOutlineInformationControl.java JavaOutlineInformationControl.java KdeKeyFormatter.java KeySequenceBinding.java MacKeyFormatter.java MultiPageKeyBindingTest.java NativeKeyFormatter.java WorkbenchCommandSupport.java KeyFormatterFactory WorkbenchCommandSupport.java KeySequence AbstractInformationControl.java AbstractInformationControl.java AbstractKeyFormatter.java Bug36420Test.java CommandLegacyWrapper.java CommandManagerLegacyWrapper.java CompactKeyFormatter.java EmacsKeyFormatter.java FormalKeyFormatter.java HierarchyInformationControl.java HierarchyInformationControl.java ICommandManager.java IKeySequenceBinding.java JavaOutlineInformationControl.java JavaOutlineInformationControl.java KdeKeyFormatter.java KeySequenceBinding.java MacKeyFormatter.java MultiPageKeyBindingTest.java NativeKeyFormatter.java KeyStroke AbstractKeyFormatter.java Bug42035Test.java CompactKeyFormatter.java EmacsKeyFormatter.java FormalKeyFormatter.java KdeKeyFormatter.java NativeKeyFormatter.java ModifierKey AbstractKeyFormatter.java AbstractModifierKeyComparator.java AlphabeticModifierKeyComparator.java CompactKeyFormatter.java EmacsKeyFormatter.java KdeKeyFormatter.java KeyStroke.java MacKeyFormatter.java NativeKeyFormatter.java NativeModifierKeyComparator.java NaturalKey AbstractKeyFormatter.java CompactKeyFormatter.java KeyStroke.java ModifierKey.java ParseException Bug42035Test.java CommandManagerLegacyWrapper.java MultiPageKeyBindingTest.java SpecialKey MacKeyFormatter.java NativeKeyFormatter.java SWTKeySupport Bug42035Test.java Bug43800Test.java HierarchyInformationControl.java HierarchyInformationControl.java JavaOutlineInformationControl.java JavaOutlineInformationControl.java WorkbenchCommandSupport.java Should we first remove these usages?
(In reply to Matthias Becker from comment #1) > > Should we first remove these usages? We can not delete these classes until these are gone so I would say yes.
New Gerrit change created: https://git.eclipse.org/r/116536
(In reply to Alexander Kurtakov from comment #2) > (In reply to Matthias Becker from comment #1) > > > > Should we first remove these usages? > > We can not delete these classes until these are gone so I would say yes. +1 in general but sometimes the classes are still used for compatibility reasons and tests. If we need to support them until final deletion, it might not be possible to remove all usage.
(In reply to Lars Vogel from comment #4) > (In reply to Alexander Kurtakov from comment #2) > > (In reply to Matthias Becker from comment #1) > > > > > > Should we first remove these usages? > > > > We can not delete these classes until these are gone so I would say yes. > > +1 in general but sometimes the classes are still used for compatibility > reasons and tests. If we need to support them until final deletion, it might > not be possible to remove all usage. see my gerrit https://git.eclipse.org/r/116536 that tries to remove the usages of SWTKeySupport in platform code
(In reply to Lars Vogel from comment #4) > (In reply to Alexander Kurtakov from comment #2) > > (In reply to Matthias Becker from comment #1) > > > > > > Should we first remove these usages? > > > > We can not delete these classes until these are gone so I would say yes. > > +1 in general but sometimes the classes are still used for compatibility > reasons and tests. If we need to support them until final deletion, it might > not be possible to remove all usage. I ask for that as in some cases there are additional things identified for deprecation and removal in the process and if found late the period extends again as they were not announced. I have experienced this first hand with the update.configurator. Thus starting migration as early as possible helps finishing the task in time without too much drama.
Gerrit change https://git.eclipse.org/r/116536 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b6db1a4b621626f2e056f918794cc9c8b688e68d
Matthias, any more usage of these classes?
the java doc does not help me in knowing how to replace the deprecated classes. E.g. for Key is says: * @deprecated Please use org.eclipse.jface.bindings.keys.KeyStroke and * org.eclipse.jface.bindings.keys.KeyLookupFactory Is there somewhere a guide that tells me hove to changes calls to the deprecated classes with calls to the new api classes?
some of the usages are located in the "Eclipse UI Tests" src folder in org.eclipse.uitest? what is that used for? Do they need to be adapted es well?
New Gerrit change created: https://git.eclipse.org/r/118271
New Gerrit change created: https://git.eclipse.org/r/118272
Gerrit change https://git.eclipse.org/r/118272 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=ee0305db6855b42ab97c1a060dcea4c644f97c1a
What's the status of this? Is it done?
(In reply to Dani Megert from comment #14) > What's the status of this? Is it done? Please reopen if it's not fixed.
