Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

GTK4 issues found by SWT test suite

オープン
#3,743 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
28/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
java
領域
desktop

調査の方向性

Start with Display._getDeviceZoom and the GTK4 branch of getPrimaryMonitor for the zoom case; the other items require locating the SWT event code for each affected widget. Reproduce under GTK4 using the internal SWT test harness and compare event ordering and values with GTK3, Win32, or Cocoa. Because this is an umbrella list spanning input, focus, widgets, tables and trees, and display scaling, a newcomer should first select one reproducible item rather than attempt all reported defects.

索引モデルが issue の本文から書いたものです。

説明

A while ago @akurtakov asked me to test GTK4, which I finally found the time for.
Here are the GTK4 bugs our internal SWT test harness found.
Each one is a difference from SWT on GTK3, which behaves like Win32 and Cocoa here.
Tested on master (3376e1982a), GTK 4.22.4 against GTK 3.24.52, X11 backend (GDK_BACKEND=x11).
If a description is not sufficient, let me know.

Input and events
  • Display.post synthesizes nothing and returns false for every event type, so SWT tests cannot post mouse or key input on GTK4.
  • Clicks on Button, List, Table and Tree send no MouseDown/MouseUp; List sends a MouseUp without the MouseDown before it. Listeners that react to mouse down/up (drag start, context actions) never run.
  • Text and Combo send Modify without a preceding Verify when typing, so VerifyListeners that filter or reject input (numeric fields, length limits) have no effect.
  • A double click sends MouseDoubleClick before the second MouseDown; GTK3, Win32 and Cocoa send MouseDown (with count 2) first and then MouseDoubleClick, so code that handles the press in MouseDown sees the double click first.
  • Shifted letters and symbols report the shifted character as keyCode (72 'H' for Shift+h, 33 '!' for Shift+1), while GTK3, Win32 and Cocoa report the unshifted key (104 'h', 49 '1'). Key bindings that check keyCode together with SWT.SHIFT stop matching.
  • FocusIn is also sent to the ancestor composites of the control that receives focus, so focus-tracking code (for example part activation) sees extra focus events. Seen for Text, List, Table, Tree and Spinner, by click, Tab traversal and forceFocus().
  • Check Button toggled with Space: Selection arrives between KeyDown and KeyUp, instead of after the key is released as on GTK3.
  • Spinner sends no Verify when its value changes through the arrow buttons, the Up/Down keys or the mouse wheel; GTK3 sends one before the Modify.
  • Spinner sends Modify before Selection (arrow buttons and Up/Down keys), the reverse of GTK3.
  • Slider: a thumb drag ends without the final Selection with detail = SWT.NONE, the mouse wheel fires no MouseWheel event and moves by a different step than on GTK3, and the slider takes keyboard focus, which it does not on GTK3.
Table and Tree
  • Dragging a column header fires no TableColumn/TreeColumn Resize or Move, and dragging a movable column does not reorder the columns, so user column resizing and reordering are invisible to the application.
  • With a visible header, item geometry and hit testing use two different origins: TableItem.getBounds(int) includes the header height (item 0 at y = 28) while TableItem.getBounds(), getTextBounds and all TreeItem bounds start below it (y = 0), and getClientArea() (y = 28), getItem(Point) and toDisplay count from the widget top, so getItem at a point inside item.getBounds() returns null or the previous row. GTK3 uses one origin for all of them. getItemHeight() also reports 25 while the rows are 23 px apart.
  • Control.setOrientation(SWT.RIGHT_TO_LEFT) on a Table or Tree that has columns throws UnsatisfiedLinkError, because it calls GTK3.gtk_container_forall, which does not exist in GTK4.
Graphics
  • GC.drawFocus paints nothing (0 pixels for drawFocus(10, 10, 40, 12) on an Image; GTK3 paints a ring), because it renders with the style context of the shell, which has no focus outline on GTK4.
Display
  • The device zoom ignores GDK_SCALE and stays at 100 with GDK_SCALE=2, so the UI renders at 100% (Display._getDeviceZoom; the GTK4 branch of getPrimaryMonitor always takes monitor 0).
主要言語
Java
スター
202
フォーク
206
平均マージ
21時間 55分
マージ済み PR(30日)
110

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

eclipse-platform/eclipse.platform.swt のほかの issue

eclipse-platform/eclipse.platform.swt の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。