AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity

Merge branch 'ebassi/docs-for-master' into 'master'

Browse Source 
docs: Mention Window::close-request in the migration guide

See merge request GNOME/gtk!3655
This commit is contained in:
Matthias Clasen 2021-06-09 17:30:02 +00:00
commit 8a890238f5
1 changed files with 16 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
docs/reference/gtk/migrating-3to4.md
View File

@ -187,11 +187,22 @@ for this change.
| ::grab-broken-event | - |
Event signals which are not directly related to input have to be dealt with
on a one-by-one basis. If you were using `::configure-event` and
`::window-state-event` to save window state, you should use property
notification for corresponding [class@Gtk.Window] properties, such as
[property@Gtk.Window:default-width], [property@Gtk.Window:default-height],
[property@Gtk.Window:maximized] or [property@Gtk.Window:fullscreened].
on a one-by-one basis:
- If you were using `::configure-event` and `::window-state-event` to save
window state, you should use property notification for corresponding
[class@Gtk.Window] properties, such as [property@Gtk.Window:default-width],
[property@Gtk.Window:default-height], [property@Gtk.Window:maximized] or
[property@Gtk.Window:fullscreened].
- If you were using `::delete-event` to present a confirmation when using
the close button of a window, you should use the
[signal@Gtk.Window::close-request] signal.
- If you were using `::map-event` and `::unmap-event` to track a window
being mapped, you should use property notification for the
[property@Gdk.Surface:mapped] property instead.
- The `::damage-event` signal has no replacement, as the only consumer
of damage events were the offscreen GDK surfaces, which have no
replacement in GTK 4.x.
### Set a proper application ID