Jface wizard placeholder without gradient #10
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
StackRendererTest should remove the used window before each test Before this change the the model elements were not removed after a test.
which allows to render a code mining where the cursor selection does not include the code mining at the given source position.
The tests for the FindReplaceDialog and FindReplaceOverlay currently use reflection to access specific UI elements. This ties the test implementations to implementation details of the production classes (i.e., specific hidden field to be present) and particularly requires the production code to contain (hidden) fields even if they would not be required just to provide according tests. This change replaces the reflective access with widget extraction functionality based on explicit IDs assigned to the UI elements of interest. Fixes eclipse-platform#2060
For Large Java file 'Replace All' takes long time and freezes the UI. One of the reason is Projection Model tries to iterate over all the Projection Annotations to expand/collapse status. We can improve this situation by using Region specific iterator. This returns annotations which are enclosed by given offset. This improves the performance by 25% at least. See eclipse-platform#2257
This reverts commit f9b743f.
The button to toggle whether the replace bar in a find/replace overlay is shown currently appears to be a rather heavyweight button with a border. With this change, the button is replace with a lightweight toolbar item like used for all other buttons in the overlay. This improves the appearance as well as the implementation as the same implementation patterns can now be applied to all buttons in the overlay.
…ort for Compatibility parts and new Parts which represent an Editor and are contributed via eg. PartDescriptors in a Model Fragment. Associated with Issue#2176.
To avoid error messages about missing file after testOpenEditors3()
When using find/replace (via overlay or dialog) in incremental mode, if the currently found element is only a case-insensitive match with the current search string, a replace operation will perform an unnecessary additional search and thus replace the next matching element. The reason is a comparison for whether the currently found string exactly matches the search string, not ignoring the casing. This change adapts the behavior to properly consider case-sensitivity when performing replace operations. It also adds according regression tests.
…#294 Concurrent "Decoration Calculation" sometimes prevented Project from deleting on Windows OS. eclipse-platform#294
When closing a find/replace overlay, the SWT dispose operations try to set focus to some remaining widget. The HistoryTextWrapper tries to pass this operation to the contained Text widget without validating it for already being disposed (which is the case when closing the overlay), thus potentially leading to exception. This change ensures that before trying to set focus on the Text widget of a HistoryTextWrapper that widget is validated for not being disposed.
The find/replace UI tests currently validate for proper focus only in specific situations, usually restricted to when running on GTK. On the one hand, this makes debugging more difficult in case the focus was not properly set in the beginning, e.g., because the workbench window was not active when the test started. On the other hand, it makes the test execution more prone to be indeterministic and platform-specific, as GTK-specific code is involved. This change provides three improvements to mitigate these issues: - It ensures that the workbench window is active when test execution starts - It validates that the find/replace UI (overlay/dialog) has focus every time it is opened during test execution - It gets rid of GTK-specific focus validation
Currently, Window#getShell() only states to return null if the shell has not been created yet. It will, however, also return null if the Window has been closed. The contract of Window#close() only states that the shell will be disposed, but not that #getShell() will return null afterwards as well. This change improves the explicit contract with this information. It has been part of the implicit contract anyway, since it is the behavior ever since the class and method exist.
- ITextSelection.emptySelection has offset and length -1 so those values need to be tolerated downstream, included in the recent-optimized ProjectionAnnotationModel.expandAll method. eclipse-platform#2257
If the IDE is running because we are executing automated tests it doesn't make sense to run this registration job. Fixes : eclipse-platform#2245
Additionally add a styled and drag&drop-able Oomph Configuration button and clean-up the build instructions. Part of eclipse-platform/eclipse.platform.releng.aggregator#2430
during PartRenderingEngineTests eclipse-platform#2367
nightly logfile is flooded with intentional RuntimeException that are hard to distinguish from unintentional exceptions.
as logged during LabelProviderTest asyncExec can happen when viewer is already disposed
to a single "SWT Resource was not properly disposed" during LabelProviderTest (and fixed the font to be not bold)
This commit addresses an occasionally occurring NullPointerException in the LogView class: ``` LogListener.logged threw a non-fatal unchecked exception as follows: java.lang.NullPointerException: Cannot invoke "org.eclipse.jface.action.Action.isChecked()" because "this.fActivateViewAction" is null at org.eclipse.ui.internal.views.log.LogView.asyncRefreshAndActivate(LogView.java:1253) at org.eclipse.ui.internal.views.log.LogView.pushEntry(LogView.java:1212) at org.eclipse.ui.internal.views.log.LogView.logged(LogView.java:1143) at org.eclipse.osgi.internal.log.ExtendedLogReaderServiceFactory.safeLogged(ExtendedLogReaderServiceFactory.java:108) at org.eclipse.osgi.internal.log.ExtendedLogReaderServiceFactory$LogTask.run(ExtendedLogReaderServiceFactory.java:56) at org.eclipse.osgi.internal.log.OrderedExecutor$OrderedTaskQueue$OrderedTask.run(ExtendedLogReaderServiceFactory.java:458) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) at java.base/java.lang.Thread.run(Thread.java:1583) ```
if the last line at the end of the document is empty Fixes: eclipse-platform#2157
…pse-platform#2657 The implementation of FindReplaceDocumentAdapter#findReplace(), used by its API methods #find() and #replace(), currently leaves an inconsistent state when failing because of an invalid input or state. This inconsistent state affects the last executed operation type, which the adapter stores in order to identify whether a replace operation is preceded by an according find operation. In case the #findReplace() method is called with an invalid position or to execute a replace without a preceding find, the method aborts (throwing an exception) without storing the operation to be executed as the last executed operation, i.e., it leaves the adapter as if that method was never called. In case the method is called in regular expression mode and the expression used as find or replace input is invalid, the operation aborts (throwing an exception) but still stores the operation to be executed as the last executed operation, i.e., it leaves the adapter as if that method was called successfully. This behavior is unexpected as is handles invalid inputs inconsistently. This also becomes visible in the existing consumers, such as FindReplaceTarget#replaceSelection() used by the FindReplaceDialog and FindReplaceOvleray. They assume that in case an exception occurs while trying to perform a replace operation, a subsequent replace should succeed without an additional find operation being required. This assumption does currently not hold. This change corrects the behavior of the FindReplaceDocumentAdapter#findReplace() method to always leave the adapter in an unmodified state when the method fails because of being called with invalid input or in an inconsistent state. In addition, regular expressions with an unfinished character escape at the end now lead to a proper exception. Fixes #eclipse-platform#2657
The LineNumberRulerColumn should consider the text widget's LineSpacing when word wrapping is enabled. Fixes eclipse-platform#2668
vogella
force-pushed
the
jface-wizard-placeholder-without-gradient
branch
from
bb2a620 to
db06c43
Compare
…form#1911 Currently, the FindReplaceLogic disables the incremental mode (i.e., search-as-you-type) in case the regex search option is activated. This makes the FindReplaceOverlay, which uses search-as-you-type in all other situations, behave non-intuitively when the regex option is activated. In order to achieve consistent, user-expectable behavior of the find and replace functionality and because of lacking arguments against using search-as-you-type in regex mode, this change makes the regex search mode independent from the incremental mode of the FindReplaceLogic. In consequence, the FindReplaceOverlay always uses search-as-you-type, no matter which search options are activated. In addition, explicit test code for that exceptional behavior is removed or adapted. Contributes to eclipse-platform#2066 Contributes to eclipse-platform#2646 Fixes eclipse-platform#1911
The functionality of the TextMatcher has been integrated in the StringMatcher class from the Equinox bundle, which allows this class to be used without a dependency to the Eclipse UI bundle. Note: To get the same behavior as the TextMatcher, one needs to call matchWords() instead of match(). Furthermore, the pattern needs to be trimmed explicitly, where needed. Contributes to eclipse-platform#2567
The new StringMatcher API used with db41fb4 is only available starting with version 3.33.0 of org.eclipse.core.runtime. See eclipse-platform/eclipse.platform#1673
The styling is done in another Thread by asyncExe anyways, there is no need to do this in an Job. This overhead can be avoided.
…lipse-platform#2666 When closing a workbench window while a find/replace overlay is open and one of the input fields (find/replace) has focus, an exception is thrown. This is caused by the FindReplaceOverlay trying to reactive shortcuts of the underlying editor while the input field is losing focus, but the handler service to perform the activation in is already disposed. Since there is no direct way of determining the underlying handler service from the overlay to identify whether it is already disposed, this change makes the overlay simply check for the workbench window currently being closed. This is reasonable as the reactivation of handlers is unnecessary if the underlying window is closed anyway. Fixes eclipse-platform#2666
Adds missing synchronized overrides of underlying AbstractDocument To synchronize all accesses to AbstractDocument.fEndPositions especially by addPositionCategory() eclipse-jdt/eclipse.jdt.ui#1067
There are some ongoing demands for providing custom icons to the Eclipse IDE or RCP applications. This now adds an example of how such an "icon-pack" can be created and used inside Eclipse IDE.
The search view with "reuse editor" enabled sets new source code in the existing editor and causes a resize. In this call, it can happen that the sticky line number exceeds the amount of line in the new source code. In general this is not a problem since the sticky lines will be recalculated afterwards, but to avoid IllegalArgumentException it is checked for this case. Fixes eclipse-platform#2678
The find and replace input strings of the FindReplaceOverlay are temporarily colored red to indicate failures of find or replace operations, such as no matches being found for the input string or regular expressions being invalid. The behavior is currently inconsistent and partly unexpected. For example: - The field to be colored is selected by the one having focus rather than the one conforming to the current operation; so a failing replace operation will color the search input field if that one has focus - Whenever the replace input field shall be colored, the search input field is also colored - When a find operation following a successful replace fails (because there are not more matches), the replace field is erroneously colored With this change, the error feedback via coloring the find and replace input strings is streamlined based on the two following goals: - Only one of the input fields is colored at one point in time - Which of the fields is colored depends on whether a find or a replace operation failed - The coloring is cleared iff either any of the two input fields loses focus or another find/replace operation was performed
According to the Javadoc on Colors: * Colors do not need to be disposed, however to maintain compatibility * with older code, disposing a Color is not an error.
No need to evaluate for every child since the condition applies to the parent item.
vogella
force-pushed
the
jface-wizard-placeholder-without-gradient
branch
from
db06c43 to
3d09f7b
Compare
These methods are not used since the 3.x migration, time to mark them for deletion.
The activation of monitor-specific rescaling on Windows currently relies on the method Display#setRescalingAtRuntime(), which was found to not take the full intended effect. This change thus replaces the call to that method based on the value of the according experimental preference by setting the according system property to activate that behavior in a proper way. It also removes the obsolete activation of Edge when the experimental preference is set, as Edge has been enabled by default.
vogella
force-pushed
the
jface-wizard-placeholder-without-gradient
branch
from
3d09f7b to
a0e9d8c
Compare
IWorkbenchPreferenceConstants.ENABLE_ANIMATIONS is not supported anymore.
This moves the duplicate code of the E3.x and E4.x based FilteredTree class and moves it into an AbstractFilteredViewerComposite class located in the JFace component. The base class is currently only implementing a tree-based filter, but is structured in such a way that it can easily be extended to also support e.g. table-based filters. Due to being unused, the following fields and methods have been marked as deprecated: - filterToolBar - clearButtonControl - updateToolbar(boolean) Contributes to eclipse-platform#2567
These methods are deprecated since a long time and should be marked for removal. This will enable us to delete them after the API deprecation period.
The gradient placeholder is replace with just an empty image.
vogella
force-pushed
the
jface-wizard-placeholder-without-gradient
branch
from
a0e9d8c to
461b29d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.