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/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.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/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/7Replace 2 uses of `new` with `Gtk::make_managed()` and `std::make_unique()`2019-11-25T20:33:14ZDaniel BolesReplace 2 uses of `new` with `Gtk::make_managed()` and `std::make_unique()`TSIA reallyTSIA reallyhttps://gitlab.gnome.org/GNOME/gtkmm-documentation/-/merge_requests/6Redo examples/explanations around RadioButtons and their Groups2019-11-25T20:33:14ZDaniel BolesRedo examples/explanations around RadioButtons and their GroupsI noticed some `m_` prefixes on local variables, and from there it just spiralled...
***
```
commit 780c74e64ea55543458def03722d9cccb5da276d
Author: Daniel Boles <dboles.src@gmail.com>
Date: Fri Jun 28 18:17:44 2019 +0100
Drop p...I noticed some `m_` prefixes on local variables, and from there it just spiralled...
***
```
commit 780c74e64ea55543458def03722d9cccb5da276d
Author: Daniel Boles <dboles.src@gmail.com>
Date: Fri Jun 28 18:17:44 2019 +0100
Drop pointless/confusing class around RadioButtons
The 2nd example seems to have been trying to be like the 1st, which put
the 3 RadioButtons in a subclass of Window, for no real reason since
they were never then added to said Window... but the 2nd omitted to
declare its members and instead declared new local variables in the
constructor with m_ prefixes, which were managed unlike the 1st example!
Just drop all of that. There's no clear reason to use a containing class
here. By not doing so, we can present both examples in a comparable way.
```
***
```
commit 3d1ea6bbce97d78d5673cc552516a5a4cff1f58d (HEAD -> wip/dboles/radiobutton-group, origin/wip/dboles/radiobutton-group)
Author: Daniel Boles <dboles.src@gmail.com>
Date: Fri Jun 28 18:39:29 2019 +0100
Redo odd wording @ RadioBut.set_group(get_group())
constness isn't the issue here; rather it is the value class of the
argument of set_group(). That method needs an lvalue reference as it
modifies the Group by adding the RadioButton to it. That's why we can't
`rb2.set_group( rb1.get_group() )`. But we can store the Group returned
by get_group() in a variable and then pass that to set_group() calls.
Not that there is much reason to, given join_group(), but it works fine.
Then I got carried away and added a program listing showing it
working... which, while mostly superfluous, does provide a nice
opportunity to explain briefly that RadioButtonGroup is a handle type,
meaning that it can be declared automatically and discarded by RAII
without worrying about thusly releasing the RadioButtons from itself.
That then informs readers for the next example that creates a new Group.
This is the first use of either "lvalue" or "rvalue" in the docbook!
That's either a good thing or a slippery, slippery slope to start on...
```