Merge changes to my fork - #1
Open
Coderr123 wants to merge 38 commits into
Open
Conversation
Implement GTK4 DropTarget support using GtkDropTargetAsync with accept, enter/motion/leave and drop handlers. Add GTK4 drop data flow integration by matching offered GTypes, reading drop values asynchronously via gdk_drop_read_value_async/finish, and finishing drops with the selected action. Tested with DNDExample. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
On GTK4 widgets have no per-widget GdkWindow, so paint order is simply the parent's child-list order (first = bottom, last = top) thus the Gtk3 hack calling moveAbove from moveBelow is not needed.
Register the click controller to listen for all buttons and hook showMenu to rightClick.
Connect activate for checkbox menues too
The first attempt to wire submenu SHOW/HIDE listeners happens too early, at bar map time. On GTK4 those nested GtkPopoverMenu children may not be fully reachable yet, so Eclipse never receives SWT.Show for the cascade submenu and never runs menuAboutToShow() . The retry in gtk_show() runs after the parent dropdown is actually shown, when GTK has built the widget tree, so the nested submenu popovers can be found and connected
Avoid creating a new Accessible from Control.removeRelation() while a control is already being torn down. Reuse existing accessibility objects instead to prevent GTK handle access after disposal. Fixes #1367
NSControlSizeRegular/Small/Mini and NSControlStateValueOn/Off/Mixed are already used and registered as swt_gen="true" in AppKitFull.bridgesupport.extras, but were missing from the actual AppKitFull.bridgesupport (only their legacy names, e.g. NSRegularControlSize/NSOnState, are present there). Since extras only carries generation flags and can't supply a value that isn't present in the underlying bridgesupport file, MacGenerator failed with "No value for enum" and silently dropped the constants on regeneration. Add the modern names to bridgesupport with the same values as their legacy counterparts, as a stand-in until the file is regenerated against a macOS SDK new enough to emit them natively. Follow-up to #3304 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The usages of deprecated CFURLCreateFromFSRef have been replaced in a recent change with URLForApplicationToOpenURL/URLForApplicationToOpenContentType and the generated code for this function has been removed. However, the the function was still declared in the bridge support which makes the MacGenerator regenerate code for that function upon execution. This change cleans up the declaration of the function in bridge support. Follow-up to #3187
The entries of the AppKitFull.bridgesupport.extras and OS classes are currently not ordered according to what the MacGenerator produces. In order to have consistent MacGenerator results without ordering changes, this change applies the order of class entries that is generated by the MacGenerator.
The cancel button constant for the file selection dialog has been added to the OS constants without adding the auto-generation instruction for the MacGenerator to the bridgesupport.extras. As a consequence, a MacGenerator tool execution removes the constant from the OS class. This change adds the according instruction. Follow-up to #1026
raise On GTK4, widgets have no per-widget GdkWindow, so the native sibling list doubles as both paint order and Composite._getChildren() order. This caused several fast-view (minimize/restore) regressions vs GTK3: - Control.destroyWidget() only called swt_fixed_remove() when fixedHandle != 0, silently skipping the native unparent for widgets without a separate wrapper handle. Their Java objects were marked disposed while the native widget stayed alive and rendered, leaving stale toolbar/button remnants behind after a restore. - Composite.moveAbove()/moveBelow() raising a Shell-direct child to the front (e.g. a flyout pane) did not actually reorder GTK4 paint order, since the general child-list-preserving behavior needed by other callers took precedence. - ToolBar.getItemCount()/_getItems() did not account for a Menu's GtkPopover appearing as a native sibling alongside real ToolItems, causing a ClassCastException and item count/index mismatches when a context menu was attached to a fast-view toolbar.
NSWorkspace.URLForApplicationToOpenURL: and URLForApplicationToOpenContentType:, introduced as a replacement for deprecated file-association API, were hand-written directly in NSWorkspace.java without registering them for MacGenerator. Since UTType.typeWithFilenameExtension: (the other new API involved, UniformTypeIdentifiers framework, macOS 12+) is not declared in any bridgesupport file, MacGenerator had no way to reproduce these methods and silently dropped them on the next regeneration. - Declare the two NSWorkspace selectors and a minimal UTType class (one method) in AppKitFull.bridgesupport/.extras by hand, since neither API exists in the SDK version the bridgesupport files were generated from, and UTType's own framework has no dedicated bridgesupport file in this project. This makes both methods regenerable instead of being a permanent manual exception. - Rename the two NSWorkspace methods to the casing MacGenerator derives from the Objective-C selector, matching existing conventions elsewhere (e.g. NSURL.URLWithString). - Introduce a proper UTType wrapper class instead of passing its handle around as a raw long, consistent with how every other Cocoa object is represented in this codebase; NSWorkspace.URLForApplicationToOpenContentType now takes a typed UTType argument. - Update Program.findAppURLForExtension() to use the generated UTType.typeWithFilenameExtension() wrapper instead of manual objc_getClass/objc_msgSend calls. Follow-up to #3187
GtkPopoverMenu inserts section-separator widgets from a GLib idle callback (gtk_menu_section_box_handle_sync_separators), but SWT popped the popover synchronously in the same call that built the items, so the popover measured its height before the separators existed, undersized itself and fell back to a scrollbar. Defer gtk_popover_popup() via display.asyncExec() so GTK's pending idle work runs first. Additionally, a bottom-of-screen menu carries GDK_ANCHOR_RESIZE_Y and is shrunk into a scrolled view when it fits neither below nor flipped above the anchor. Wayland has no global window coordinates to compute the overflow, so compare the popover's allocated height to its natural height and iteratively shift the anchor up by the shortfall, keeping the popover hidden (opacity 0) until it fits. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
NSScrollerDecrementLine and NSScrollerIncrementLine are deprecated since macOS 10.14 without replacement, as scrollers do not have arrow buttons anymore since macOS 10.7. Remove the constants together with the dead switch cases in ScrollBar and Slider that handled hits on the no longer existing scroller arrows. Contributes to #3214 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The CGPDFContext* functions are all present in the CoreGraphicsFull.bridgesupport files but were never registered in the corresponding .extras files, so MacGenerator silently dropped them on the next regeneration. This adds the missing swt_gen="true" entries and reruns the MacGenerator to adopt its ordering of generated entries in the OS class. Follow-up to #2882 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
NSProgressIndicatorPreferredThickness is deprecated since macOS 10.14 in favor of using controlSize and sizeToFit. Add a binding for NSProgressIndicator#sizeToFit and use it in ProgressBar#computeSize to determine the default thickness for the progress indicator's control size, restoring the original frame afterwards. Contributes to #3214 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> # Conflicts: # bundles/org.eclipse.swt/Eclipse SWT PI/cocoa/org/eclipse/swt/internal/cocoa/AppKitFull.bridgesupport.extras # bundles/org.eclipse.swt/Eclipse SWT PI/cocoa/org/eclipse/swt/internal/cocoa/OS.java
The macOS AppKit framework deprecated the old-style NSAlert alert style constants in macOS 10.12 (Sierra) in favour of the NSAlertStyle enum, and the old-style NSEvent modifier flag constants in macOS 10.12 in favour of the NSEventModifierFlags option set type. This change replaces all seven deprecated constants throughout the SWT macOS/Cocoa implementation with their modern equivalents, eliminating compiler deprecation warnings and improving forward compatibility with future macOS SDK versions. Replaced constants (values are unchanged): NSWarningAlertStyle -> NSAlertStyleWarning (0) NSInformationalAlertStyle -> NSAlertStyleInformational (1) NSCriticalAlertStyle -> NSAlertStyleCritical (2) NSShiftKeyMask -> NSEventModifierFlagShift (131072) NSControlKeyMask -> NSEventModifierFlagControl (262144) NSCommandKeyMask -> NSEventModifierFlagCommand (1048576) NSHelpKeyMask -> NSEventModifierFlagHelp (4194304) Contributes to #3214
Some macOS enum constants have different numeric values on x86_64 versus aarch64, since aarch64 values were inherited from iOS headers and diverge from the values in the x86_64/bridgesupport definitions. Until now, this was handled by hand-editing the generated OS.java after every MacGenerator run, since the generator had no way to express an architecture-dependent value and the divergence isn't present in the (machine-generated, non-editable) bridgesupport files themselves. MacGenerator now supports a new "swt_value_aarch64" attribute on <enum> elements in *.bridgesupport.extras files. When set, it declares the value to use on aarch64, while the regular value/value64 attribute continues to describe the x86_64 value; the generator derives the appropriate architecture-conditional expression from both. This removes the need to manually patch generated code after each run and keeps the architecture-specific knowledge in the extras file, alongside the other custom generation hints already maintained there. Follow-up to 0ffafe6 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
When setMRUVisible(true) and all tabs fit without a chevron, navigating past the last tab with Ctrl+PageDown (TRAVERSE_PAGE_NEXT) or before the first tab with Ctrl+PageUp (TRAVERSE_PAGE_PREVIOUS) had no effect. Now navigation wraps around to the first/last visible tab respectively, matching the existing behavior of the non-MRU traversal path. Adds a new option to the CTabFolder tab in the CustomControlExample (under: Other > Activate MRU) which demonstrates the before/after behavior. Fixes eclipse-platform/eclipse.platform.ui#4135 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
GC.drawImage() operations use a temporary image handle mechanism that creates a bitmap handle scaled to the pixel size required for each drawing operation. When an image is not available at the requested zoom, the closest available zoom is used instead. Previously, a fresh handle was created for every new drawing size, even when the same underlying image data would be used. For example, an image only available at 100% zoom (such as a plain PNG without HiDPI variants) caused a new handle to be allocated and immediately discarded on every drawImage() call that requested a different size. This change introduces the concept of "nearest available zoom" on image providers: each provider now reports, for a given requested zoom, the effective zoom at which it would actually supply data. This information is stored alongside the cached temporary handle after each drawImage(). Before allocating a new temporary handle for a different draw size, the nearest available zoom is used to look up an already existing handle: first in the image's persistent handle cache, then by comparing it against the zoom recorded with the previously cached temporary handle. If a matching handle is found, it is reused instead of creating a new one. If no handle exists and the nearest available zoom is 100%, a persistent handle is created eagerly: this frees any image data previously retained for API calls such as getImageData() and makes the handle available through the regular persistent handle lookup for all subsequent calls. This applies to any image where consecutive drawImage() calls at different sizes map to the same underlying data — e.g. a 100%-only image drawn at 200% and 300%, or an image with 100% and 200% variants when drawing at sizes between 200% and 300%. Four regression tests are added to ImagesWin32Tests to verify handle reuse (positive cases), the absence of unintended reuse across different nearest-available-zoom regions (negative case), and that a persistent handle created outside of drawImage() is found and reused by the nearest-available-zoom lookup. Fixes #3419
GC.drawImage() operations use a temporary image handle mechanism that selects the best-fitting native handle for each pixel size. A recent change introduced the concept of "nearest available zoom" so that handles can be reused when consecutive draw calls at different sizes map to the same underlying image data, and eagerly persists handles when the nearest available zoom is 100%. This change extends the handle-selection logic in two ways. Exact imageZoom lookup before nearestAvailableZoom: Before consulting the nearestAvailableZoom, the image's persistent handle manager is now queried at the exact imageZoom first. This ensures that a handle explicitly created for a zoom — even one the provider would not normally supply on its own — is found and reused. For example, when win32_getHandle() has been called at 200% for a 100%-only image, drawing at the 200%-equivalent pixel size now returns the pre-existing 200% handle rather than the 100% handle from nearestAvailableZoom. Monitor-zoom persistence: The condition for eagerly persisting a handle is extended from "nearestAvailableZoom == 100%" to also include any zoom that matches a current monitor. Monitor zooms are obtained from the zoom reported by each open Shell via Display.getShells(). When imageZoom or nearestAvailableZoom matches a monitor zoom, the image is likely being drawn repeatedly at that screen's native resolution, so persisting the handle avoids repeated allocations across consecutive draw calls. As a minor cleanup, getAvailableMonitorZooms() is now called once and its result reused within getExistingHandle() instead of being called twice. Two regression tests are added to ImagesWin32Tests to cover the new behaviors: one verifying that an existing handle at the exact imageZoom is preferred over a nearestAvailableZoom handle, and one verifying that drawing at the monitor zoom creates a persistent handle that is then reused via win32_getHandle() without a second native allocation. See #3419 Contributes to #3454
When drawing cropped and scaled images, the calculation for the source rectangle to draw is quite error prone: - It does not distinguish between different scale factors in X and Y direction, leading to large rounding errors if the extents in one direction are highly different from the extents in the other direction - It does not apply rounding that is consistent to the scaling done by the Image class, thus leading to differently rounded sizes when scaling an image in the Image class and drawing that same image in the GC - The "error correction" to deal with rounding at fractional scale factors is too restrictive, in particular when the scale factor is less than 1, and is not applied when only one axis has a non-unity scale factor This change reimplements the source rectangle calculation as follows: - It treats the scale factors for both axes independently - It applies the same rounding method to the rectangle extents as done by the Image scaling implementation - It rounds up the scale factor when checking for the allowed size error on fractional scaling, such that a scale factor less than 1 still allows for an error of 1 in size - It applies the bounds correction whenever either axis has a non-unity scale factor, not only when both axes do A regression test is added to GCWin32Tests that verifies all three drawImage overloads (3-arg, 5-arg, and 9-arg) produce identical pixel output for a 500-wide image across a matrix of small prime heights and fractional zoom levels (100%, 125%, 150%, 175%, 200%). Fixes #3454 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
clearing - Added manual regression test (created with the help from Copilot and based on the original JFace based TreeCrashBug.java reproducer). Fixes #3329
The ImageList.remove(int) method has no caller anywhere in the SWT codebase and it's not public API either. Besides being dead code, its implementation was also subtly wrong: after shifting the images array down it cleared images[index] instead of the now-vacated last slot images[count], which would corrupt the images-to-native mapping if it were ever used. Rather than fixing an unreachable method, remove it entirely to avoid accidental usage of a buggy method by future callers.
Drawing a blank (empty) image via GC.drawImage() with a scaled source/destination region failed with a NullPointerException. The nearest-zoom lookup tried to derive the zoom from an existing image handle, but an empty image has no handle yet, so the lookup resolved to null. The nearest-zoom lookup now falls back to using an empty image at 100% zoom when no image handle exists yet, so drawing an empty image succeeds. Adds an OS-independent GC test that draws an empty image with a scaled region to guard against this regression. Fixes #3442 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
A recent change forced a full image refresh for every ToolItem on every DPI change by nulling and re-setting the image in Item.handleDPIChange in order to ensure proper resizing of the ToolItem (issue #3073). That is costly (it removes and re-adds every item's image on every zoom change) and, for tool bars, it can relocate an item to a lower free slot in the image list when a hole is present, so re-adding the native button with its previously captured image index restores a stale slot - the item then shows another item's icon or a blank one. This change reverts Item.handleDPIChange to the cheap no-op refresh and lets ToolBar.handleDPIChange reinitialize each item's image in place via ToolItem.updateImages after the buttons have been re-added and the image lists refreshed. updateImages writes the rescaled image at the item's existing image list slot (no clear/re-add, so no relocation) and forces the button width to be recomputed, which keeps issue #3073 fixed without the overhead and without the wrong-icon regression. Fixes #3466 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
On a monitor zoom (DPI) change, ToolBar.handleDPIChange removes and re-adds every button so Windows re-lays out the tool bar at the new zoom. It snapshots each button with TB_GETBUTTON - including its image-list slot index (iBitmap) - and re-adds the button from that snapshot. So far the snapshot was taken before the item was notified of the zoom change. If that notification changes an item's image-list slot, the re-added button carries a stale image index and the item shows another item's icon or a blank one. With this change, we capture the button with TB_GETBUTTON after notifyListeners(ZoomChanged) instead, so the current, post-refresh image index is always the one that is re-added. This makes the image-index capture correct by construction and guards against an item's image-list slot changing while the zoom change is handled. Contributes to #3466 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
On GTK4, gtk_widget_hide() resets a widget's allocation to 0x0. A Composite that is laid out while it (or an ancestor) is hidden therefore sizes its children against a stale 0x0 client area, leaving them collapsed at their minimum size once the Composite is finally shown. The content only expands after a manual resize forces a re-layout. The size given while hidden is still stored in the parent's swt_fixed child list. When such a Composite is shown, re-run the parent's size allocation to re-apply this control's real size (restoring its client area), then re-layout its own subtree so the children pick up the now-correct client area. Fixes #3450 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Since the tab height also accounts for the top-left/top-right tab controls, it depends on Control#computeSize() of those controls. That size is only meaningful once the control has processed the zoom change itself: a control is scaled from pixels to points using its parent's zoom, and on a DPI change the folder is rescaled before its children. Measuring a child in that window mixes the old zoom's pixel size with the new zoom, which yields a too large tab height when moving from a higher to a lower zoom. Nothing recomputed the tab height afterwards, so the header stayed too high until the folder was updated for another reason, for example by selecting a different tab. Recompute the tab height when a tab control reports a zoom change. The listener is added after the control's own zoom handling is registered, so the control is already rescaled when the folder measures it again. The added test drives a tab control that reports a stale size and then sends a zoom change, so it verifies the recomputation on all platforms without requiring monitors with different scaling. Fixes #3456
Wire nested GtkPopoverMenu SHOW/HIDE via the model's "items-changed" signal (connected in the after phase, so GTK has already rebuilt the popover) and re-discover popovers on each pass to handle GTK rebuilds. Replaces the previous fixed-count retry. Fixes #3451 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
On GTK4 a SWT.CASCADE menu item was created via g_menu_item_new_submenu which has no associated action. setEnabled() only manipulates the item's action, so calling setEnabled(false) on a cascade item was a no-op: the item stayed sensitive and opened an empty popover. getEnabled() also hard-coded true for cascade items. On GTK3 the same call correctly greys out the item via gtk_widget_set_sensitive. This affected e.g. Navigate > Back/Forward, which Eclipse disables when there is nothing to navigate to: on GTK4 they remained enabled and showed an empty menu. Create cascade items with a backing SimpleAction (g_menu_item_new plus g_menu_item_set_submenu) so their sensitivity can be toggled, and return the action's enabled state from getEnabled() for all GTK4 items. The activate signal is not wired for cascade items, so opening the submenu still works and navigation is not hijacked. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Menu inserts its action group on the shell under a prefix, so an item's action has two names: the plain one it was registered with, and the detailed menuHash.itemHash that resolves through the prefix. releaseWidget() passed the detailed name to g_action_map_remove_action(), which keys actions by their plain name, so it silently removed nothing and entries accumulated for the lifetime of the group. Store the plain name as actionId and remove by that, keeping actionName for the places that refer to an action by name (GMenuItem, GtkNamedAction). All four item styles were affected. This does not free the action itself: the reference from g_simple_action_new() is never released, and unref'ing it here leaves the top-level menu bar items without labels. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Add two backend-agnostic regression tests for BrowserFunction lifecycle: - a disposed BrowserFunction must not be re-injected on a subsequently loaded page - redefining a function with the same name takes effect and survives navigation, and the previous definition is not resurrected Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
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.