gtkmm merge requestshttps://gitlab.gnome.org/GNOME/gtkmm/-/merge_requests2023-10-31T10:26:23Zhttps://gitlab.gnome.org/GNOME/gtkmm/-/merge_requests/84Widget: Fix outdated, wrong destructor doc comment2023-10-31T10:26:23ZDaniel BolesWidget: Fix outdated, wrong destructor doc comment```none
commit 449249a8098cacdb1a6410472366527201e2cc77 (origin/dboles/Widget-doc-cosmetics, dboles/Widget-doc-cosmetics)
Author: Daniel Boles <dboles.src@gmail.com>
Date: Mon Oct 30 16:31:45 2023 +0000
Widget: Fix outdated, wrong...```none
commit 449249a8098cacdb1a6410472366527201e2cc77 (origin/dboles/Widget-doc-cosmetics, dboles/Widget-doc-cosmetics)
Author: Daniel Boles <dboles.src@gmail.com>
Date: Mon Oct 30 16:31:45 2023 +0000
Widget: Fix outdated, wrong destructor doc comment
Now destroying a widget will not remove it from a parent if it has one,
as GTK4 removed GtkContainer and hence any uniform way to remove() etc.
https://gitlab.gnome.org/GNOME/gtkmm/-/issues/138#note_1775964
commit 92caa8a2fa882339479e33faf25750c1e2d8a843
Author: Daniel Boles <dboles.src@gmail.com>
Date: Mon Oct 30 16:28:24 2023 +0000
Widget: Add some 'section heading' comments
commit 88128a723d8987b7c65883ca009e683a6beef26b
Author: Daniel Boles <dboles.src@gmail.com>
Date: Mon Oct 30 15:45:26 2023 +0000
Widget: Sort includes
commit 246ae7696665ae158a29e3f9dcfda1390dc31f76
Author: Daniel Boles <dboles.src@gmail.com>
Date: Mon Oct 30 15:38:22 2023 +0000
Widget—Remove redundant Gtk:: namespace qualifiers
```Daniel BolesDaniel Boleshttps://gitlab.gnome.org/GNOME/gtkmm/-/merge_requests/81Regenerate defs + wrap added Shortcuts methods and PopoverMenu::flags property2023-10-05T13:38:20ZDaniel BolesRegenerate defs + wrap added Shortcuts methods and PopoverMenu::flags propertyI've wrapped 'new' API that I've recently got into GTK. There is probably more, of course!
I _think_ I got everything right (eventually) in regenerating the defs, but a more educated review would be appreciated.
This builds and tests f...I've wrapped 'new' API that I've recently got into GTK. There is probably more, of course!
I _think_ I got everything right (eventually) in regenerating the defs, but a more educated review would be appreciated.
This builds and tests fine; I haven't done any interactive testing (yet?) but assume if we build, we'll run.
```none
commit b40dbd230ff5467e78259731da72dc8f15152c65 (HEAD -> dboles/RegenAndWrapNewAPI, origin/dboles/RegenAndWrapNewAPI)
Author: Daniel Boles <dboles.src@gmail.com>
Date: Wed Oct 4 12:11:20 2023 +0100
Shortcuts: Wrap new add_*() methods to populate
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6249
commit 200ab60530e509c1516504b1d778928809bbff01
Author: Daniel Boles <dboles.src@gmail.com>
Date: Wed Oct 4 12:08:41 2023 +0100
PopoverMenu: Wrap new property :flags + [gs]etters
I have changed this from a ctor param only to a property in GTK4 `main`.
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6298
commit 8d00555a0af6a55b457ccd932c4218cf4c6901bb
Author: Daniel Boles <dboles.src@gmail.com>
Date: Wed Oct 4 11:57:51 2023 +0100
Regenerate (gdk|gtk)_(docs|enums|methods|signals)*
```Daniel BolesDaniel Boleshttps://gitlab.gnome.org/GNOME/gtkmm/-/merge_requests/22add Gtk::Button::unset_image() and remove mentions of nullptr in set_image()2019-11-24T13:34:24ZDaniel Bolesadd Gtk::Button::unset_image() and remove mentions of nullptr in set_image()Fix #58
The doc fix can go into `gtkmm-3-24`. The new method presumably wants to wait until `gtkmm-3-26` with the rest, unless we decide to change that policy.
`master` has no `set_image()`, so neither are applicable there.Fix #58
The doc fix can go into `gtkmm-3-24`. The new method presumably wants to wait until `gtkmm-3-26` with the rest, unless we decide to change that policy.
`master` has no `set_image()`, so neither are applicable there.https://gitlab.gnome.org/GNOME/gtkmm/-/merge_requests/12FileFilter: Add missing custom docs; don't mention unwrapped function; improv...2019-01-07T18:09:32ZDaniel BolesFileFilter: Add missing custom docs; don't mention unwrapped function; improve formattingTSIA really
Where possible, docs are adapted from GTK with `mm`ification and fixes to poor grammar. Otherwise, I just made them up, so feel free to quibble about wording!TSIA really
Where possible, docs are adapted from GTK with `mm`ification and fixes to poor grammar. Otherwise, I just made them up, so feel free to quibble about wording!https://gitlab.gnome.org/GNOME/gtkmm/-/merge_requests/10Builder: Fix wrong use of @retval for output args [gtkmm-3-24]2018-12-17T18:30:39ZDaniel BolesBuilder: Fix wrong use of @retval for output args [gtkmm-3-24]See https://gitlab.gnome.org/GNOME/gtkmm/merge_requests/9 for discussionSee https://gitlab.gnome.org/GNOME/gtkmm/merge_requests/9 for discussionhttps://gitlab.gnome.org/GNOME/gtkmm/-/merge_requests/9Builder: Fix wrong use of @retval for output args [master]2018-12-17T18:32:55ZDaniel BolesBuilder: Fix wrong use of @retval for output args [master]```
@retval is for documenting the meanings of particular values of the
returned variable, not output reference/pointer arguments like this.
```
These were the only uses of `@retval` in `gtkmm` (at least `master`). This should also...```
@retval is for documenting the meanings of particular values of the
returned variable, not output reference/pointer arguments like this.
```
These were the only uses of `@retval` in `gtkmm` (at least `master`). This should also be cherry-picked to `gtkmm-3-24`.
There are more such occurrences of `@retval` in `glibmm`; I can prepare an MR for that, too.
In practice, I guess it is in one way convenient that Doxygen produces a section headed "Return values" and puts the output argument in there, but I don't think the current usage is semantically correct, and it seems better to have all the arguments together in order anyway.