gtkmm-documentation merge requestshttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests2023-11-09T13:38:18Zhttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/21custom_container/mycontainer.cc: Tidy up measure()2023-11-09T13:38:18ZDaniel Bolescustom_container/mycontainer.cc: Tidy up measure()I was thinking of making this use the new overload of `measure()` I just added to _gtkmm_, but it's probably not worth requiring _gtkmm_ 4.14 for the relatively small gain we'll get from that. However, this other tidying I found while te...I was thinking of making this use the new overload of `measure()` I just added to _gtkmm_, but it's probably not worth requiring _gtkmm_ 4.14 for the relatively small gain we'll get from that. However, this other tidying I found while testing that out _does_ seem worth doing. :smile_cat:
***
* Move `dummy_*_baseline` to point of use, renamed to `ignore`.
* Avoid unneeded `height_per_child`; just divide `for_size` in-place.
* Deduplicate two loops, one for each possible `Orientation`.
* Use `std::max()`, instead of reinventing it.
* Donʼt redundantly count nvis_children manually, in one of those loops!Daniel BolesDaniel Boleshttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/20Fix Ch13-Menus and Toolbars. Replace mention of non-existing class...2023-07-24T07:45:33ZKarmavilFix Ch13-Menus and Toolbars. Replace mention of non-existing class...Fix Ch13-Menus and Toolbars. Replace mention of non-existing class Gtk::EventControllerClick for Gtk::GestureClickFix Ch13-Menus and Toolbars. Replace mention of non-existing class Gtk::EventControllerClick for Gtk::GestureClickhttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/19small improvement on togglebutton example2023-07-07T17:23:41ZCarlos Villanueva Simonsmall improvement on togglebutton exampleSmall change, just trying to show better, the behavior of `togglebutton`Small change, just trying to show better, the behavior of `togglebutton`https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/18Add notes re widget destructor behaviour vs gtkmm32023-06-29T14:46:16ZDaniel BolesAdd notes re widget destructor behaviour vs gtkmm3From https://gitlab.gnome.org/GNOME/gtkmm/-/issues/138
```none
And move the glibmm reference link from its own line to the one above,
& drop some blank lines within sections to make their boundaries clear
```From https://gitlab.gnome.org/GNOME/gtkmm/-/issues/138
```none
And move the glibmm reference link from its own line to the one above,
& drop some blank lines within sections to make their boundaries clear
```Daniel BolesDaniel Boleshttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/17index-in.docbook: String fixes2023-03-05T16:14:54ZAnders Jonssonindex-in.docbook: String fixesSome small fixes from looking at recent strings, also standardization on American spelling.
* Use American spelling (some ise->ize , our->or)
* Typo fix
* Split two words that were written togetherSome small fixes from looking at recent strings, also standardization on American spelling.
* Use American spelling (some ise->ize , our->or)
* Typo fix
* Split two words that were written togetherhttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/16Typo and spacing fixes2022-08-15T16:33:18ZAnders JonssonTypo and spacing fixesThis makes some small fixups to things I noticed when starting a translation of gtkmm-documentation.
* Typos (specifed etc.)
* Spacing fixes
* gtkmm4.0-devel now has a . in the name in Fedora https://packages.fedoraproject.org/pkgs/gtkm...This makes some small fixups to things I noticed when starting a translation of gtkmm-documentation.
* Typos (specifed etc.)
* Spacing fixes
* gtkmm4.0-devel now has a . in the name in Fedora https://packages.fedoraproject.org/pkgs/gtkmm4.0/gtkmm4.0-devel/
* Move the plural s out of some class names (it was already placed outside the tag in outer strings).
Also saw some British English spellings. If it is desirable i could make another MR to change these to American spelling.https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/15Sort input file list2022-05-06T13:30:23ZBernhard M. WiedemannSort input file listSort input file list
so that `gtkmm-tutorial/index.docbook` builds in a reproducible way
in spite of indeterministic filesystem readdir order
and http://bugs.python.org/issue30461
See https://reproducible-builds.org/ for why this matter...Sort input file list
so that `gtkmm-tutorial/index.docbook` builds in a reproducible way
in spite of indeterministic filesystem readdir order
and http://bugs.python.org/issue30461
See https://reproducible-builds.org/ for why this matters.
This PR was done while working on [reproducible builds for openSUSE](https://en.opensuse.org/openSUSE:Reproducible_Builds).https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/14PO-files: added: why `fuzzy` tag appears.2021-09-23T07:55:53ZDarkTrickPO-files: added: why `fuzzy` tag appears.https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/13Add a CI pipeline for building, validating, and publishing2021-08-18T14:07:33ZEmmanuele BassiAdd a CI pipeline for building, validating, and publishingWe run the build using Meson, split into three stages:
- validation
- build
- deployment
The validation phase runs the build with -Dvalidation=true; the build
phase runs the build with just the HTML generation and without
translatio...We run the build using Meson, split into three stages:
- validation
- build
- deployment
The validation phase runs the build with -Dvalidation=true; the build
phase runs the build with just the HTML generation and without
translations, for the moment; the deployment phase takes the build
artifacts and publishes them on the GitLab pages space for the project.Emmanuele BassiEmmanuele Bassihttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/12update simplified chinese translation2021-07-18T11:50:06ZCCTV-1update simplified chinese translationhttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/11update simplified Chinese translation2023-01-26T13:56:37ZCCTV-1update simplified Chinese translationhttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/10update simplified chinese translation2020-12-29T16:02:02ZCCTV-1update simplified chinese translationhttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/9update simplified chinese translation2020-12-27T09:15:48ZCCTV-1update simplified chinese translationhttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/8update simplified chinese translation2020-12-26T10:10:23ZCCTV-1update simplified chinese translationhttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/4Clarify that user sometimes must delete if managed [master]2018-11-07T07:36:21ZDaniel BolesClarify that user sometimes must delete if managed [master][ see also https://gitlab.gnome.org/GNOME/gtkmm-documentation/merge_requests/3 ]
I don't think I was fully aware of this until I noticed it incidentally during https://gitlab.gnome.org/GNOME/gtkmm/issues/33#note_341220 in the `gtkmm` ...[ see also https://gitlab.gnome.org/GNOME/gtkmm-documentation/merge_requests/3 ]
I don't think I was fully aware of this until I noticed it incidentally during https://gitlab.gnome.org/GNOME/gtkmm/issues/33#note_341220 in the `gtkmm` documentation. I think I took most of my assumptions about `Gtk::manage()` from `gtkmm-documentation` instead, which doesn't mention this at all.. and I think it is really worth being clear about, so future readers won't end up with leaky code like I now have to go and fix.
>>>
`container.ccg` remembers whether the object was originally un-floated by
`Gtk::manage()` and, if so, restores that state during `Container.remove()`,
with the result that the removed widget is *not* deleted, as it would be
in GTK+, but instead it is re-floated and requires the user to deal with
(e.g. to add it to some other container or to finally call `delete` on it)
This is documented in `container.hg` but nowhere that I can see in our
tutorial, and I think it is worth mentioning here, since it is not
completely intuitive: users might otherwise think that the fact manage()
delegates lifetime management to the `Container` means they get back the
same behaviour of C widgets, i.e. that `remove()` would cause destruction,
but of course that is not the case, and we might thus encourage leaks.
So mention that `manage()` only relieves the user of the burden of calling
`delete` if they add the widget to a parent and do not remove it later, in
both the _Memory Management_ section and the part about deleting wrappers.
>>>https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/3Clarify that user sometimes must delete if managed [gtkmm-3-22]2018-11-07T07:43:18ZDaniel BolesClarify that user sometimes must delete if managed [gtkmm-3-22][ see also https://gitlab.gnome.org/GNOME/gtkmm-documentation/merge_requests/4 ]
I don't think I was fully aware of this until I noticed it incidentally during https://gitlab.gnome.org/GNOME/gtkmm/issues/33#note_341220 in the `gtkmm` ...[ see also https://gitlab.gnome.org/GNOME/gtkmm-documentation/merge_requests/4 ]
I don't think I was fully aware of this until I noticed it incidentally during https://gitlab.gnome.org/GNOME/gtkmm/issues/33#note_341220 in the `gtkmm` documentation. I think I took most of my assumptions about `Gtk::manage()` from `gtkmm-documentation` instead, which doesn't mention this at all.. and I think it is really worth being clear about, so future readers won't end up with leaky code like I now have to go and fix.
>>>
`container.ccg` remembers whether the object was originally un-floated by
`Gtk::manage()` and, if so, restores that state during `Container.remove()`,
with the result that the removed widget is *not* deleted, as it would be
in GTK+, but instead it is re-floated and requires the user to deal with
(e.g. to add it to some other container or to finally call `delete` on it)
This is documented in `container.hg` but nowhere that I can see in our
tutorial, and I think it is worth mentioning here, since it is not
completely intuitive: users might otherwise think that the fact manage()
delegates lifetime management to the `Container` means they get back the
same behaviour of C widgets, i.e. that `remove()` would cause destruction,
but of course that is not the case, and we might thus encourage leaks.
So mention that `manage()` only relieves the user of the burden of calling
`delete` if they add the widget to a parent and do not remove it later, in
both the _Memory Management_ section and the part about deleting wrappers.
>>>https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/2Document the new make_managed() & prefer to use it / Use auto more in example...2018-11-08T15:22:05ZDaniel BolesDocument the new make_managed() & prefer to use it / Use auto more in examples [master]This accompanies the main `gtkmm` merge requests at https://gitlab.gnome.org/GNOME/gtkmm/issues/33
This performs creation and manage()ment in a single step and therefore
avoids the user having to write the discouraged new operat...This accompanies the main `gtkmm` merge requests at https://gitlab.gnome.org/GNOME/gtkmm/issues/33
This performs creation and manage()ment in a single step and therefore
avoids the user having to write the discouraged new operator, looks more
like Standard C++ things like make_shared(), etc. So, move our examples
to it, and elaborate on why it is preferable to manage() or new/delete.
I got sidetracked and tacked on a subsequent commit that uses `auto` a lot more, in the new code and elsewhere. I can split that if anyone want.https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/1Document the new make_managed() & prefer to use it [gtkmm-3-24]2018-11-08T15:21:24ZDaniel BolesDocument the new make_managed() & prefer to use it [gtkmm-3-24]This accompanies the main `gtkmm` merge requests at https://gitlab.gnome.org/GNOME/gtkmm/issues/33
This performs creation and manage()ment in a single step and therefore
avoids the user having to write the discouraged new ope...This accompanies the main `gtkmm` merge requests at https://gitlab.gnome.org/GNOME/gtkmm/issues/33
This performs creation and manage()ment in a single step and therefore
avoids the user having to write the discouraged new operator, looks more
like Standard C++ things like make_shared(), etc. So, move our examples
to it, and elaborate on why it is preferable to manage() or new/delete.