Re: Does anyone know how to update the www.gtkmm.org website?
On Sun, 2022-01-16 at 19:18 +0100, Kjell Ahlstedt via gtkmm-list wrote: > The www.gtkmm.org website has not been updated for a long time. There > are a number of gtkmm issues about obsolete information. I don't know > how to update the website. The source code is stored at > https://gitlab.gnome.org/GNOME/gnomemm-website. I've made a few > updates to the source code, and used GitLab's CI and Pages to have a > partially updated version published at > https://gnome.pages.gitlab.gnome.org/gnomemm-website. That's not good > enough. No one will find it there. Who has permission to update > www.gtkmm.org? I've just updated gtkmm.org. Sorry for the delay. (I ran "make post-html" in docs/, but of course that needs my login.) gtkmm.org's domain is registered at dreamhost.com, and hosted by dreamhost.com. The domain has been owned by me, and hosted under my account, for years because I never found a more appropriate way to do it. I'm glad that you've got hosting at gitlab working. I tried that a couple of years ago, without success. Shall we redirect the gtkmm.org domain to it, following these instructions? https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/index.html I'd also be happy to transfer domain ownership, but I don't know what would be appropriate. Murray ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Does anyone know how to update the www.gtkmm.org website?
Sorry, I forgot to answer your email to me about this. I will check how it works and get back to you. I have previously tried using gitlab for this but it sounds like you have had more luck.On 16 Jan 2022 19:18, Kjell Ahlstedt via gtkmm-list wrote: The www.gtkmm.org website has not been updated for a long time. There are a number of gtkmm issues about obsolete information. I don't know how to update the website. The source code is stored at https://gitlab.gnome.org/GNOME/gnomemm-website. I've made a few updates to the source code, and used GitLab's CI and Pages to have a partially updated version published at https://gnome.pages.gitlab.gnome.org/gnomemm-website. That's not good enough. No one will find it there. Who has permission to update www.gtkmm.org? ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: First stable version of gtkmm-4.0 has been released
On Mon, 2020-12-21 at 13:46 +0100, Kjell Ahlstedt via gtkmm-list wrote: > After several years of being in an unusually unstable state, gtkmm- > 4.0 and gtk4 have now stabilized. [snip] Congratulations, Kjell and everyone who helped, and thanks for all the determined hard work. Getting here is a serious achievement. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Meson and Autotools, or only Meson?
On Thu, 2020-03-26 at 09:42 +0100, Kjell Ahlstedt wrote: > Complete documentation of Meson is at https://mesonbuild.com/. > > The README files of libsigc++, glibmm and pangomm contain very short > descriptions of how to build with Meson and with Autotools. Available > options are in the meson_options.txt file. Or, in the build > directory, run "meson configure". warnings=fatal is the default. I > have tried to make the "warnings" option equal to the Autotools > equivalent, except that "fatal" is the default. I wonder if that's wise. It will lead to unnecessary build breakage, for instance for packagers, when they upgrade compilers or dependencies. If this remains the default, we might need to give people obvious instructions about how to build more forgivingly. > If you want to see exactly which warnings are enabled, look at the > meson.build file in the package's top directory. > > Gtkmm itself can't be built with Meson yet. That's several months > ahead, I think. You might consider, if you like, not removing autotools from the other builds until gtkmm uses Meson, if you remove autotools. That would be a simpler story. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ***UNCHECKED*** Meson and Autotools, or only Meson?
On Wed, 2020-03-25 at 18:49 +0100, Kjell Ahlstedt via gtkmm-list wrote: > These *mm packages can now be built either with Meson or with > Autotools: > > mm-common > libsigc++-2.0, libsigc++-3.0 > glibmm-2.4, glibmm-2.66 > pangomm-1.4, pangomm-2.44 > (gtkmm-documentation-3,) gtkmm-documentation-4 > I've put gtkmm-documentation-3 in parentheses because there is no > released tarball with Meson support, it's only in the git repo. > > Some underlying C packages, such as glib and gtk4, have dropped > Autotools support. Shall we do the same, where possible? > > I think at least one released tarball must contain both Meson support > and Autotools support before Autotools support can be dropped, or > else https://gitlab.gnome.org/GNOME/gnome-build-meta/ will have > problems. Correct me, if I'm wrong here. > > At the moment all of the listed packages use Meson when they are > built with jhbuild, but only mm-common does so when it's built with > gnome-build-meta. > > Regards > Kjell I don't have enough experience with Meson to give a real opinion. So do please do what you think makes things easier for people working on the code. Thanks for pursuing this. Where would I go to find basic instructions for using Meson with gtkmm and co. For instance, how would I build with or without our strict warnings as errors? -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: What shall be the version number of the next mm-common release?
On Sun, 2019-10-27 at 12:34 +0100, Kjell Ahlstedt via gtkmm-list wrote: > Calling the next release 1.0.0 is fine with me. The reason I ask is > that the previous version numbering of mm-common is strange. Several > of the previous versions look stable. Still they are all called 0.y > or 0.y.z, some with an even y, some with an odd y. > > Perhaps it's not as important with mm-common as with most other > modules. mm-common does not create a library file. It's used only by > other *mm-modules (C++ bindings). Yes, I don't think it matters that much. And it's only a weird build- time thing. Feel free to do what feels right and feel free to make it more sane. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: New ABI names for glibmm-2.58, atkmm-2.28 and pangomm-2.42?
On Thu, 2018-09-06 at 15:47 +0200, Kjell Ahlstedt via gtkmm-list wrote: > Shall the ABI names of the future ABI breaking releases of glibmm, > atkmm and pangomm be changed once again? I think, yes, please. > Latest release of glib is 2.58.0. Shall the ABI name of glibmm be > changed from glibmm-2.58 to glibmm-2.60? > Latest release of atk is 2.29.2. Shall the ABI name of atkmm be > changed from atkmm-2.28 to glibmm-2.30? > Latest release of pango is 1.42.4. Shall the ABI name of pangomm be > changed from pangomm-2.42 to pangomm-2.44? > Latest release of cairo is 2.15.13. The ABI name of cairomm can > probably remain cairomm-1.16. > It had probably been easier to use obviously temporary ABI names > until the ABIs are frozen. Perhaps something like glibmm-2.temp, > atkmm-2.temp, pangomm-2.temp? Then the ABI names would have to be > changed only twice, first from e.g. glibmm-2.4 to glibmm-2.temp, then > from glibmm-2.temp to the final name. I'd much prefer to keep using numbers. They indicate some sequence. > If glibmm-2.58 is changed to glibmm-2.60, it will be the 5th change. > /Kjell Well, at least nobody is using them yet, and we have advised distros not to package them. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: C++17
On Thu, 2018-04-12 at 21:10 +0100, Jonathan Wakely wrote: > On 12 April 2018 at 21:02, Murray Cumming wrote: > > I've just released a version of libsigc++-3.0 (currently unstable) > > that > > requires C++17. This means that gtkmm-4.0 (currently unstable) > > requires > > C++17 too. I should have mentioned it first, but I think this is > > fine. > > What are you using from C++17? Nothing major. Just some constexpr if, std::apply() and std::invoke(): https://github.com/libsigcplusplus/libsigcplusplus/commits/master > GCC's C++17 implementation is not stable yet, so there are still ABI > changes possible between GCC 8 and GCC 9. > > IIRC we've already introduced some (minor) incompatibilities between > the std::variant in GCC 7 and GCC 8. gtkmm-4.0 is itself unstable, so that's not a problem. And I see no sign that GTK+ 4.0 will become stable any time soon. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
C++17
I've just released a version of libsigc++-3.0 (currently unstable) that requires C++17. This means that gtkmm-4.0 (currently unstable) requires C++17 too. I should have mentioned it first, but I think this is fine. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: glibmm-2.56 or glibmm-2.58 ABI?
On Wed, 2018-03-14 at 13:46 +0100, Kjell Ahlstedt wrote: > Now glib 2.56.0 has been released. > Will glibmm 2.56.0 be released with glibmm-2.4 ABI, We could do that, sure, maybe by branching from the glibmm-2.54 branch. Please feel very free to take care of that. Thanks. > and will the next parallel-installable ABI be glibmm-2.58? Yes, we should change the ABI name again. > If so, we should take the chance to add some new API before glibmm > 2.56.0 is released. E.g. as suggested in > https://bugzilla.gnome.org/show_bug.cgi?id=787496 > https://bugzilla.gnome.org/show_bug.cgi?id=495762#24 Sure. That should be fine. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
ANNOUNCE: gtkmm 3.93.0 (unstable)
*** gtkmm
gtkmm 3.93 wraps GTK+ 3.93. It will become gtkmm 4.0,
wrapping GTK+ 4.0. It is a version of the gtkmm-4.0 API.
It installs in parallel with gtkmm-3.0.
gtkmm stays in-sync with gtk+ by (mostly) following the official GNOME
release schedule:
http://www.gnome.org/start/unstable/
http://www.gtkmm.org
*** Changes
3.93.0 (unstable):
Distro packagers should probably not package this yet.
Gtk:
* AboutDialog:
- Add set/get/property_system_information().
- Remove unset_license(). Can now be unset with set_license("").
(Kjell Ahlstedt)
* AccelGroup: Remove signal_accel_activate().
(Kjell Ahlstedt)
* ButtonBox: Add property_secondary() and
property_non_homogeneous().
(Kjell Ahlstedt)
* Clipboard: Remove, replaced by Gdk::Clipboard.
(Kjell Ahlstedt)
* Entry: Add property_show_emoji_icon().
(Kjell Ahlstedt)
* FlowBox: Add get_child_at_pos().
(Kjell Ahlstedt)
* FontButton:
- Remove set/get/property_font_name().
- Remove show_style and show_size.
(Kjell Ahlstedt)
* FontButton: Remove show_style and show_size.
* FontChooser: Add the Gtk::FontChooser::Level enum and
set/get/property_level(), get/property_font_features(),
get/property_language().
(Kjell Ahlstedt)
* InfoBar: Add set/get/property_revealed().
(Kjell Ahlstedt)
* ListBox: Add property_accept_unpaired_release().
(Kjell Ahlstedt)
* ListBox: Add property_accept_unpaired_release().
(Kjell Ahlstedt)
* ListBoxRow: Implement the Gtk::Actionable interface.
(Kjell Ahlstedt)
* MenuItem: Fix add_accel_label()
(Christian Schoenebeck)
* Remove RecentFileChooser, RecentChooserDialog, RecentChooserMenu,
(Kjell Ahlstedt)
RecentChooserWidget and RecentFilter.
(Kjell Ahlstedt)
* Remove Screen.
(Kjell Ahlstedt)
* SelectionData: Add set/get_surface(). Remove the non-const
get_pixbuf() and let the const get_pixbuf() return a non-const
Pixbuf.
(Kjell Ahlstedt)
* TargetList: Remove, replaced by Gdk::ContentFormats.
(Kjell Ahlstedt)
* TextTag: Remove event() and signal_event().
(Kjell Ahlstedt)
* Add Gdk::Texture.
(Kjell Ahlstedt)
* Remove ToolItemGroup and ToolPalette.
(Kjell Ahlstedt)
* Remove Visual.
(Kjell Ahlstedt)
* Widget: Remove show_now().
(Kjell Ahlstedt)
* Window:
- Add get_frame_clock().
(Kjell Ahlstedt)
- Add show_uri().
(Daniel Boles) Bug #787242
Gdk:
* Add Gdk::DeviceTool
(Kjell Ahlstedt)
* Add Gkd::Clipboard.
(Kjell Ahlstedt)
* Add ContentFormats.
* ContentFormatsBuilder: Add operator bool().
(Kjell Ahlstedt)
* Add ContentProvider.
(Kjell Ahlstedt)
* Device: Add signal_tool_chaged() and property_tool().
(Kjell Ahlstedt)
* Remove Gdk::DeviceManager.
(Kjell Ahlstedt)
* DrawingContext: Add property_clip().
(Kjell Ahlstedt)
* Display:
- Remove supports_cursor_alpha(), supports_cursor_color(),
get_default_cursor_size(), get_maximal_cursor_size().
- Add signal_setting_changed().
(Kjell Ahlstedt)
* Event
- Inherit from Glib::Object.
- Add set/get_device() and set/get_source_device().
- Move get_device() to the base Event class.
(Kjell Ahlstedt)
* EventButton: Add get_device_tool().
(Kjell Ahlstedt)
* EventMotion: Add get_device_tool().
(Kjell Ahlstedt)
* Add FrameClock and FrameTimings.
(Kjell Ahlstedt)
* GLArea: Remove get/set/property_has_alpha().
(Kjell Ahlstedt)
* GLContext: Add unset_use_es().
(Kjell Ahlstedt) Bug #787898
* IconInfo: Inherit from Glib::Object.
(Kjell Ahlstedt)
* Menu: Add place_on_monitor().
(Kjell Ahlstedt)
* MenuButton: Add set_popup().
(Kjell Ahlstedt)
* Overlay: Add child_property_blur().
(Kjell Ahlstedt)
* Remove PlacesSidebar.
(Kjell Ahlstedt)
* RGBA: Add is_clear() and is_opaque().
(Kjell Ahlstedt)
* StyleContext: Add set/get_frame_clock().
(Kjell Ahlstedt)
, Widget:
- Add get_frame_clock(), add_tick_callback() and
remove_tick_callback().
- Remove all event signals except signal_event(),
signal_key_press_event() and signal_key_release_event().
(Kjell Ahlstedt)
* Texture: Add create_for_gl() and release_gl().
(Kjell Ahlstedt)
* Window:
- Remove add/remove_filter().
- Add set/get/property_hide_on_close() and signal_close_request().
(Kjell Ahlstedt)
Documentation:
* Update the Menus demo.
(Kjell Ahlstedt)
* Pixbufs demo: Use Gdk::FrameClock.
(Kjell Ahlstedt)
* Fix the Change Display demo.
(Kjell Ahlstedt)
* Update the Image demo.
(Kjell Ahlstedt)
* Update the DrawingArea demo.
(Kjell Ahlstedt)
* IconTheme, SelectionData: Add class documentation.
(Kjell Ahlstedt)
* Widget: Document drag_dest_set(Gtk::DestDefaults, Gdk::DragAction).
(Kjell Ahlstedt)
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Moving to gitlab.gnome.org
I will request that we move gtkmm and related projects (starting with glibmm, probably) from git.gnome.org to GNOME's new gitlab instance, if there are no objections. This is the new GNOME git system, so it's mostly just a question of when we make the move, not if. See https://gitlab.gnome.org/GNOME -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
ANNOUNCE: glibmm 2.55.2 (unstable)
*** glibmm: glibmm 2.56 wraps glib 2.56 glibmm 2.56 is a version of the glibmm-2.56 API. It installs in parallel with the glibmm-2.4 API/ABI, of which the most recent version is glibmm 2.52.1. http://www.gtkmm.org *** Changes 2.55.2: (unstable): Distro packagers should probably not package this yet. Glib: * IOCondition: Add an IO_ prefix to the enumerator names (Kjell Ahlstedt) * TimeoutSource: Use monotonic time consistently (Kjell Ahlstedt) Bug #792524 (Dainis Jonitis) * Source: Remove get_current_time(). (Kjell Ahlstedt) * KeyFile, OptionContext, Regex: Add exception specs to errthrow. (Kjell Ahlstedt) * ustring: - Replace 8×format() with 1 variadic template. - Replace 9×compose() with 1 variadic template. - Use std::initializer_list instead of pointer + size (Daniel Boles) Bug #784211 * VariantBase: - Add operator==() and operator!=(). (Kjell Ahlstedt) Bug #789330 (Daniel Boles) - cast_dynamic(): Remove noexcept(false). (Kjell Ahlstedt) Glib::Gio: * AppInfo: Update the name of the AppLaunchContext parameters (Kjell Ahlstedt) * Action: Add exception specs to errthrow. (Kjell Ahlstedt) * Application: Fix property_resource_base_path()'s type (Kjell Ahlstedt) * Credentials, et al.: Add exception specs to errthrow. (Kjell Ahlstedt) * DataInputStream: - Remove read_until*(). - Fix the documentation of read_line_utf8(). (Kjell Ahlstedt) * InetSocketAddress, ProxyAddress: No guint16 in _WRAP_PROPERTY(). (Kjell Ahlstedt) * Settings: set_int() and friends shall return bool. (Kjell Ahlstedt) Bug #784211 * TlsClientConnection: Remove get/set/property_use_ssl3(). (Kjell Ahlstedt) gmmproc: * Warn if parameter lists are not compatible (Kjell Ahlstedt) * _WRAP_METHOD: Accept optional list of exceptions in errthrow (Kjell Ahlstedt) * _WRAP_METHOD_DOCS_ONLY: Optionally suppress @return section. (Kjell Ahlstedt) Bug #787978 * docextract_to_xml.py: Add --exclude-file option. (Kjell Ahlstedt) * Suppress the @return section if return type is void. (Kjell Ahlstedt) * generate_extra_defs.cc: - Write signal flags to .defs files. - Write default values of properties to .defs files. - Write default values of properties to generated documentation. (Kjell Ahlstedt) Bug #785895 (Daniel Boles) * Warn for unmatched deprecations in signals and properties. (Kjell Ahlstedt) Documentation: * Glib::ObjectBase: Don't mention GtkObject in comments. (Kjell Ahlstedt) * Glib::Variant: Hide namespace Glib::detail from Doxygen (Kjell Ahlstedt) Bug #787698 (Daniel Boles) * Glib::Variant: Slightly elaborate Variant docs. (Daniel Boles) Bug #778219 (Daniel Boles) -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: How shall gtkmm wrap a returned cairo_surface_t pointer when it's a nullptr?
On Tue, 2017-10-24 at 10:48 +0200, Kjell Ahlstedt wrote: > 1. Cairo::make_refptr_for_instance(nullptr) This seems obviously better, or maybe something even simpler. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm 3.24 or new API in gtkmm 3.22?
On Fri, 2017-09-15 at 11:29 +0100, Daniel Boles wrote: > Sorry if it was already discussed - I feel like it probably was, but > can't see it right now. > > Even though GTK+ has no plans for versions > 3.22, couldn't gtkmm > branch and have an 'almost-stable' gtkmm-3-24, etc of its own for > changes that are fairly innocuous, but which you still don't want in > the 3-22 branch? Let's keep that as a possibility, but I haven't seen a serious need for it yet. But I could be persuaded by a list of API additions that we'd like to make in 3.22 or 3.24. Otherwise it's just a hypothetical that we don't need to worry about. > It could be a bit confusing in terms of numbering, but as long as > GTK+ keeps to its plan, never ambiguous with GTK+. Anyway, the > potential for ambiguity could be sidestepped by using a different > scheme, e.g. gtkmm-3-22-b, which would probably be sensible from the > outset. [snip] I think that would be even more confusing. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm 3.24 or new API in gtkmm 3.22?
On Thu, 2017-09-14 at 23:17 +0200, Murray Cumming wrote: > On Wed, 2017-04-05 at 16:00 +0200, Murray Cumming wrote: > > On Sat, 2017-04-01 at 09:22 +0200, Kjell Ahlstedt wrote: > > > I agree with Diether and Daniel: Let's do as gtk+ does, even > > > though > > > they break the rules. > > > > OK. Then I don't object anymore. Thanks for being patient. Feel > > free > > to > > add API in the gtkmm-3-22 branch: > > https://git.gnome.org/browse/gtkmm/log/?h=gtkmm-3-22 > > I'm replying to this old thread because I don't think I mentioned > this > at the time: > > We haven't actually added any API yet to gtkmm-3-22, though we have > deprecated API in gtkmm-3-22. I found that there were not, and are > not, > actually any API additions in GTK+ 3.22, so I'd like to avoid them in > gtkmm 3.22 unless there's a serious need. Here is the link, for context, that I meant to paste: https://mail.gnome.org/archives/gtk-devel-list/2017-May/msg00014.html -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm 3.24 or new API in gtkmm 3.22?
On Wed, 2017-04-05 at 16:00 +0200, Murray Cumming wrote: > On Sat, 2017-04-01 at 09:22 +0200, Kjell Ahlstedt wrote: > > I agree with Diether and Daniel: Let's do as gtk+ does, even though > > they break the rules. > > OK. Then I don't object anymore. Thanks for being patient. Feel free > to > add API in the gtkmm-3-22 branch: > https://git.gnome.org/browse/gtkmm/log/?h=gtkmm-3-22 I'm replying to this old thread because I don't think I mentioned this at the time: We haven't actually added any API yet to gtkmm-3-22, though we have deprecated API in gtkmm-3-22. I found that there were not, and are not, actually any API additions in GTK+ 3.22, so I'd like to avoid them in gtkmm 3.22 unless there's a serious need. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is Meson on the horizon?
On Fri, 2017-07-28 at 12:46 +0100, Russel Winder wrote: > On Fri, 2017-07-28 at 12:54 +0200, Murray Cumming wrote: > > […] > > > > Maybe we could try having build file for Meson alongside the > > autotools > > files. Patches would be welcome. Someone might want to work in a > > branch > > for a while until it works. I suggest starting with glibmm. > > The GStreamer folk built their Meson build alongside the Autotools > build in > master rather than a separate branch. The Autotools was the official > build, > but having the Meson build being constructed in master got (at least > in my > view) more input from more people. > > They also created a build super-project that pulled in all the > libraries via > git submodules and then built all at once. This helped a lot with > ensuring > always using a consistent set of libraries for people building from > source. > > I could be inveigled upon to get involved in building a Meson build > for > glibmm, gtkmm, etc. but I cannot get stuck in till September. Thanks. I'd rather not have it in glibmm's git master until it can actually build glibmm. I might change my mind if many people appear who want to work on it. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is Meson on the horizon?
On Fri, 2017-07-28 at 11:48 +0100, Russel Winder wrote: > The gtkmm project mayhap wants to switch to build with Meson instead > of > Autotools. Maybe we could try having build file for Meson alongside the autotools files. Patches would be welcome. Someone might want to work in a branch for a while until it works. I suggest starting with glibmm. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is Meson on the horizon?
On Fri, 2017-07-28 at 17:51 +1200, Ian Martin wrote: > Hi, > > Looking around, I see GTK seems to be adding Meson support (and > possibly > dropping autotools). From what I can see, it looks like it's going > to > be easier to understand; are there plans to add support in the *mm > projects? I have not looked at meson yet. I don't know what support would be needed. I guess someone should try to create a hello world project with meson and gtkmm. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::Entry::set_icon_from_icon_name(nullptr) segmentation fault
On Wed, 2017-07-26 at 09:52 +0100, Daniel Boles wrote: > Well, yeah, it's a way, in that usually you can use a set() method > with its argument being suitably-typed equivalent of 'empty' or > 'null' to achieve unsetting. I don't think we can generally assume that that works as expected. > However, in many or perhaps most cases, there is an unset() to make > things simpler, and IMO that is better API and should be offered/used > where possible. Yes, the unset_*() methods are more obvious. We just need to mention them in the documentation. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Returning sigc::signal by value from a const method?
On Sat, 2017-07-22 at 10:58 +0100, Daniel Boles wrote: > As an aside, since realising that providing any form of full access > to a signal gives external users the ability to emit() it, clear() > it, etc. - I am considering moving to a model whereby I only expose > signals via a method like this: > > sigc::connection signal_whatever_connect(signal_whatever_type slot); > > This involves quite a bit of boilerplate, albeit not all that much > worse than what we have to write to implement a (pointless) by- > reference or -value getter anyway. > > > However, it got me wondering. Has anyone ever come up with a better > way to only allow users to connect() to signals and nothing more, or > at least a way to reduce the required boilerplate of my proposed > mechanism somehow? > > I did find an old thread where IIRC Murray talked about how he would > like to see access control on signals, FWIW! That may have changed in > the meantime, whether through opinion or just practicality. > > I guess it could be done, but with smoe huge API changes; e.g. I > imagine we could return a base class that does not have the modifying > methods from our own objects, while using a derived class that does > provide them internally. > > > At the end of the day, the real question is whether the work of > providing access control would be justifiably better than just > requiring users to encapsulate signals for themselves; I suspect the > answer might be no. Still interested in any thoughts. I'm not aware of any efforts to make this easier. It does bother me too. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Accessing combo box text
On Sat, 2017-07-22 at 12:23 +0100, Daniel Boles wrote: > > On 22 July 2017 at 12:07, <deepak.bhujangac...@harvelsystems.com> > wrote: > > Hi All, > > > > I am getting message like this after stop debugging. "gtkmm- > > CRITICAL **: gtkmm: object `Product_Combo' not found in GtkBuilder > > file." Please help. > > > > Thanks > > Deepak > > Well? Is it in the ui file? Despite your many messages indicating > that you think people here are psychic, they are not. > > I mean, look at what you've asked. What are we meant to do with that? > Psychically tell you what is wrong with this mysterious .ui file you > haven't shown us? > > Again, please spend more time thinking about how to ask usable > questions. You can't just keep posting here saying 'I tried this, but > it doesn't work. What is wrong' and no more info that that. It > doesn't provide any fuel for discussion, and frankly it's starting to > feel like spam. Daniel, please be more patient if you choose to respond. This person is asking for help. Your first two sentences would have been enough. If you also want to teach him how to ask, please be nicer about it. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Connecting signal to destruction of an object - or - self-destructing handlers
On Tue, 2017-07-04 at 09:44 +0100, Daniel Boles wrote: > How/can I receive an event when some object of my choice is > destroyed, so that I can take appropriate action? > > Here's an example I came up against lately. I should probably > refactor the code so I don't need to do things this way... but it > illustrates the question quite well. I have a ComboBox where, via > some boring exposition, I want to put a signal_changed() handler on > its StyleContext. However, that handler holds a reference to a row in > the ComboBox's model. Therefore, I need to receive notification when > that model dies (i.e. when all holders of RefPtrs release them), so > that I can disconnect that signal_changed() handler and therefore > stop it from trying to access a dead row. [snip] This shouldn't generally happen. The sigc::trackable base class should take care of this. Maybe it would be best to try to reduce this to a simple test case. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
ANNOUNCE: gtkmm 3.22.0
*** gtkmm gtkmm 3.22 wraps GTK+ 3.22. gtkmm stays in-sync with gtk+ by (mostly) following the official GNOME release schedule: http://www.gnome.org/start/unstable/ http://www.gtkmm.org *** Changes 3.22.1 (stable): Unusually for a stable micro release, this release has some deprecations compared to 3.22.0, to match similar deprecations in GTK+ 3.22.x. Gtk: * Container: Deprecate the child property. The underlying C property was deprecated in GTK+ 3.22.2. (Kjell Ahlstedt) Bug #773642. * FileChooserDialog: Deprecate the constructors that take a backend parameter. (Kjell Ahlstedt) * Menu: Deprecate popup(). The underlying C functions were deprecated in GTK+ 3.22.2. (Kjell Ahlstedt) Bug #773642 * Widget: - Deprecate is_composited() and signal_composited_changed(). The underlying C functions were deprecated in GTK+ 3.22.3. - Deprecate drag_dest_set_proxy(). The underlying C functions was deprecated in GTK+ 3.22.3. (Kjell Ahlstedt) Bug #773642. * Window: Deprecate set_wmclass(). The underlying C functions was deprecated in GTK+ 3.22.2. (Kjell Ahlstedt) Bug #773642. Gdk: * Screen: Deprecate get_number(), get_width(), get_height(), get_width_mm(), get_height_mm(), make_display_name(), get_n_monitors(), get_primary_monitor(), get_monitor_geometry(), get_monitor_workarea(), get_monitor_at_point(), get_monitor_at_window(), get_monitor_width_mm(), get_monitor_height_mm(), get_monitor_plug_name(), get_monitor_scale_factor(), get_active_window(). The underlying C functions were deprecated in GTK+ 3.22.2. (Kjell Ahlstedt) Bug #773642 * Visual: Deprecate get_system(), get_best(), get_best_depth(), get_best_type(). The underlying C functions were deprecated in GTK+ 3.22.3. (Kjell Ahlstedt) Bug #773642 * Window: - Deprecate process[_all]_updates(). The underlying C functions were deprecated in GTK+ 3.22.7. - Deprecate set_background(), get_background_pattern(), set_debug_updates(). The underlying C functions were deprecated in GTK+ 3.22.2. (Kjell Ahlstedt) Documentation: * Box: Correct the constructor documentation. (Daniel Boles) * CellLayout: Improve docs of get_first_cell() funcs (Daniel Boles) * Frame: Fix the documentation of set_label_align(). (Daniel Boles) Bug #774249 * Label: Improve h/valign constructor documentation and the improve the parameter names. (Daniel Boles) Bug #774652 * TreeModel: Improve docs of foreach*() functions (Daniel Boles) * Minor cleanup of examples and demos. (Daniel Boles) * demo: Don't call Notebook::remove_page() with invalid index. (Daniel Boles) Build: * Update the Visual Studio builds. (Chun-wei Fan) * GtkMainConnectionNode: Remove unused method. (Kjell Ahlstedt) -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
ANNOUNCE: glibmm 2.52.0
*** glibmm: glibmm 2.52 wraps glib 2.52 http://www.gtkmm.org *** Changes 2.52.0 (stable): Gio: * UnixSocketAddress::create(): Remove the default value for the type parameter to avoid ambiguity. (Kjell Ahlstedt) Bug #782592 Gio::DBus * Proxy: Wrap call() and call_sync() methods. (Vyacheslav Yurkov) Bug #781818 Documentation: * RefPtr: Clarify comment about undefined behaviour. (Daniel Boles) -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Making use of move semantics?
On Sun, 2017-05-21 at 15:03 +0100, Daniel Boles wrote: > On 21 May 2017 at 14:29, Murray Cumming <murr...@murrayc.com> wrote: > > We've already used move/r-value-references in several places, but > > not > > for string arguments. I assume that std::string's own move operations give us enough efficiency, so we wouldn't gave much by adding overloads such as set_something(std::string&& str); but we could discuss specific code examples that we'd like to make more efficient. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
C++17's string_view (was Re: Making use of move semantics?)
On Sun, 2017-05-21 at 15:03 +0100, Daniel Boles wrote:
[snip]
> > I guess we might start taking std::string_view with C++17 instead
> > of
> > std::string and this might largely take care of this.
>
>
> I don't see how string_view would make any difference to whether or
> not we end up copying strings. Can it?
I've tried it out now, so here are some thoughts:
I had hoped that std::string_view would avoid copying of C strings in
the temporary std::string in cases like this:
void use_string(const std::string& str) {
gtk_label_set_text(str.c_str());
}
...
use_string("abc");
I think that the "abc" will be copied by the std::string constructor,
though we really only want a const char* anyway.
I had hoped that this would let us just use the original const char*:
void use_string_view(const std::string_view& str) {
gtk_label_set_text(str.c_str());
}
...
use_string_view("abc");
But there is no std::string_view::c_str() because string_view doesn't
assume that its underlying array is null-terminated. It couldn't assume
that while sometimes being just a view of part an existing array.
So, we need to do this:
void use_string_view(const std::string_view& str) {
gtk_label_set_text(str.to_string().c_str());
}
...
use_string_view("abc");
That std::string_view::to_string() does a copy, so I don't think we've
gained anything compared to taking a std::string.
And if we pass a std::string, we'd have a copy where we wouldn't have
had one before:
void use_string_view(const std::string_view& str) {
gtk_label_set_text(str.to_string().c_str());
}
...
use_string_view(some_std_string);
So, I think:
1. We would use std::string_view everywhere if all the C functions took
a length instead of assuming null-termination. That's not going to
happen.
2. Overriding all methods to take either a const char* or a std::string
(ignoring ustring for now), would avoid the extra array copy, but I
don't think it's worth it other than for methods that typically take
very large strings.
3. GTK+ functions that take very large strings tend to take a length,
to avoid the need for copying. For instance,
gtk_text_buffer_set_text(). We could take std::string_view there, but
then our use of std::string_view::to_string() would be wasteful when
someone passes a std::string to our method.
This is discouraging, so I hope I'm wrong about something.
> Separately, how would string_view interact with Glib::ustring?
> Glancing at the available documentation, my guess is "it wouldn't",
> since it seems to be based on fixed-width characters, not to be
> context-sensitive. So it may not be a suitable replacement for
> ustring.
I guess std::string_view deals with bytes, regardless of their
encoding, just as std::string does. If we keep using Glib::ustring,
we'd maybe want to have a Glib::ustring_view, at least as just a type
alias.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: M4-converting gsize to std::size_t
On Mon, 2017-05-29 at 19:22 +0100, Daniel Boles wrote: > On 29 May 2017 at 15:32, Murray Cumming <murr...@murrayc.com> wrote: > > On Fri, 2017-05-26 at 22:11 +0100, Daniel Boles wrote: > > > There are a few uses of the GLib typedef gsize in glibmm et al. > > > > > > I presume it would be safe to provide an M4 conversion from this > > to > > > std::size_t? Do you think that would be good? To me, it seems > > nicer > > > to use the C++ standard type. > > > > Yes, that sounds good. Thanks. > > > Thanks for the confirmation. Does the same apply to other g* types, > both the generic ones (guchar, guint, etc.) and the specific-width > ones (guint8 to std::uint8_t, etc.) ? Personally, I like the brevity of guint compared to unsigned int, or even std::uint32_t. But I could maybe be persuaded. Replacing guint8 with std::uint8_t sounds reasonable, though I doubt there are many of the min the API anyway. I guess we could replace many of the 'guchar's with std::byte in C++17. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: M4-converting gsize to std::size_t
On Fri, 2017-05-26 at 22:11 +0100, Daniel Boles wrote: > There are a few uses of the GLib typedef gsize in glibmm et al. > > I presume it would be safe to provide an M4 conversion from this to > std::size_t? Do you think that would be good? To me, it seems nicer > to use the C++ standard type. Yes, that sounds good. Thanks. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
ANNOUNCE: glibmm 2.53.2 (unstable)
*** glibmm: glibmm 2.54 wraps glib 2.54 glibmm 2.54 is a version of the glibmm-2.54 API. It installs in parallel with the gtkmm-2.4 API/ABI, of which the most recent version is glibmm 2.51.7. http://www.gtkmm.org *** Changes 2.53.2 (unstable): Distro packagers should probably not package this yet. Glib: * ConstructParams: Do not increment allocation size twice (Daniel Elstner) Gio: * ActionMap: Really fix add_action_with_parameter(). (Daniel Boles) Bug 77#c31 * UnixSocketAddress::create(): Remove a default value to avoid ambiguity. (Kjell Ahlstedt) Bug #782592 Gio::DBus * Proxy: Wrap call() and call_sync() methods. (Vyacheslav Yurkov) Bug #781818 gmmproc: * Use of static_cast<> instead of C-style casts. (Murray Cumming) Build: * Fix the build on MacOS, where glib doesn't have gdesktopinfo. (John Ralls) Bug #781947 * Really use desktopappinfo.hg to fix the build. (Murray Cumming) Documentation: * Glib, Gio: Update documentation of in-class enums. (Kjell Ahlstedt) * ActionMap: Improve add_action_with_parameter docs (Daniel Boles) 2.53.1.1 (unstable): Glib: * Use C++11 enum classes instead of old-style enums, and put many enums inside relevant class declarations: - Glib::NodeTree: Move enums into class. - Glib::BindingFlags is now Glib::Binding::Flags. - Glib::KeyfileFlags is now Glib::Keyfile::Flags. - Glib::ModuleFlags is now Glib::Module::Flags. - Glib::ChecksumType is now Glib::Checksum::Type. - Glib::Regex: Move enums inside class. - Glib::Resource: Move enums into class. (Murray Cumming, Kjell Ahlstedt) * RefPtr: Make this an alias for std::shared_ptr<> instead. - Use std::dynamic_pointer_cast<>() instead of RefPtr<>::cast_dynamic(). - Use std::static_pointer_cast<>() instead of RefPtr<>::cast_static(). - Use std::const_pointer_cast<>() instead of RefPtr<>::cast_const(). - When creating RefPtr directly, instead of using create() methods, use Glib::make_refptr_for_instance() so the std::shared_ptr<> has the necessary Deleter. (Murray Cumming) Bug #755037 * Remove Glib::WeakRef. Use std::weak_ref<> instead. (Murray Cumming) Bug #755037 * Object: Use g_object_new_with_properties() instead of (deprecated) g_object_newv() and (deprecated) GParameter. (Murray Cumming) * IOChannel: Avoid creating a RefPtr to this. (Murray Cumming) Bug #755037 * SignalProxy: connect(): Signals with non-void return values now have no default value for the "after" parameter, forcing application developers to think about whether they should connect before or after already-connected signal handlers, and default signal handlers. This is awkward but necessary. Just provide "true" to get the previous behaviour, or use connect_notify(). connect_notify(): Signals with void return values have no connect_notify(), because it is not useful with those signals. (Kjell Ahlstedt) Bug #126213. Gio: * Use C++11 enum classes instead of old-style enums, and put many enums inside relevant class declarations: - Gio::Drive: Move enums into class. - Gio::TlsDatabase: Move enums into class. - Gio::UnixSocketAddressType is now Gio::UnixSocketAddress::Type. - Gio::Mount: Move enums into class. - Gio::TlsPasswordFlags is now Gio::TlsPassword::Flags. - Gio::IOStreamSpliceFlags is now Gio::IOStream::SpliceFlags. - Gio::SettingsBindFlags is now Gio::Settings::BindFlags. - Gio::ResolverRecordType is now Gio::Resolver::RecordType. - Gio::Socket: Move enums into class. - Gio::File: Move some flags enums into the class. - Gio::OutputStreamSpliceFlags is now Gio::OuputStream::SpliceFlags. - Gio::CredentialsType is now Gio::Credentials::Type. - Gio::NotificationPriority is now Gio::Notification::Priority. - Gio::FileMonitorEvent is now Gio::FileMonitor::Event. - Gio::FileAttributeInfoFlags is now Gio::FileAttributeInfo::Flags. - Gio::EmblemOrigin is now Gio::Emblem::Origin. - Gio::Converter: Put enums inside class. - Gio::ConverterFlags is now Gio::Converter::Flags. - Gio::ConverterResult is now Gio::Converter::Result. - Gio::AppInfoCreateFlags is now Gio::AppInfo::CreateFlags. - Gio::ApplicationFlags is now Gio::Application::Flags. (Murray Cumming, Kjell Ahlstedt) * Remove duplicate ErrorEnum declaration. (Kjell Ahlstedt) * ConstructParams: - Remove (hopefully really unnecessary) copy constructor. - C++11: =delete the operator=, instead of making it private. (Murray Cumming) * Value: - Remove the CType alias, which should be unnecessary. - value_custom: Replace a template parameter with C++11 type traits. - Value<RefPtr>: Only use this specialization if T has get_base_type(). (Murray Cumming) Bug #755037 * Variant: - operator bool(): Simplify to avoid clang++ warnings. - C++11: Variant: Replace throw(std::bad_cast) with noexcept(false). See https://bugzilla.redhat.com/show_bug.cgi?id=1438766 (Murray Cummin
ANNOUNCE: gtkmm 3.91.0 (unstable)
*** gtkmm gtkmm 3.91 wraps GTK+ 3.91. It will become gtkmm 4.0, wrapping GTK+ 4.0. It is a version of the gtkmm-4.0 API. It installs in parallel with gtkmm-3.0. gtkmm stays in-sync with gtk+ by (mostly) following the official GNOME release schedule: http://www.gnome.org/start/unstable/ http://www.gtkmm.org *** Changes 3.91.0 (unstable): Distro packagers should probably not package this yet. Gdk: * Improve Gdk::Event, creating a class hierarchy. (Mark Vender, Kjell Ahlstedt) Bug #135978 * Cursor: Change CursorType to Cursor::Type. (Murray Cumming) * Device: Change DeviceType to Cursor::Type. (Murray Cumming) * Pixbuf: - Remove AlphaMode enum. - Change PixbufRotation to Pixbuf::Rotation. (Murray Cumming) * Seat: Change SeatCapabilities to Seat::Capabilities. (Murray Cumming) * Visual: Change VisualType to Visual::Type. (Murray Cumming) * Window: - Change WindowHints to Window::Hints. - Change WindowTypeHint to Window::TypeHint. - Change WindowType to Window::Type. - Change WindowState to Window::State. (Murray Cumming) Gtk: * Assistant: Change AssistantPageType to Assistant::PageType. (Murray Cumming) * Box: pack_start/pack_end(): Reimplement with new GTK+ API. (GtkWidget halign and hexpand properties. The gtk_box_pack_start() and gtk_box_pack_end() functions no longer have the expand and fill arguments. We might remove these parameters later too. Be careful that the default behaviour of pack_start/pack_end() has now changed. - Make PackOptions an enum class, for stricter type checking. (Murray Cumming) * Builder::get_widget_derived(): Make this static. To avoid the need to create a shared_ptr to this. (Murray Cumming) Bug #755037 * ButtonBox: Remove apparently-useless BUTTONBOX_DEFAULT_SPACING. (Murray Cumming) * Application: Change ApplicationInhibitFlags to Application::InhibitFlags. (Murray Cumming) * Calendar: Change CalendarDisplayOptions to Calendar::Display::Options. (Murray Cumming) * CellRendererAccel: Change CellRendererAccelMode to CellRendererAccel::Mode. (Murray Cumming) * CssSection: Change CssSectionType to CssSection::Typewq. (Murray Cumming) * Container: - forall_vfunc(): Remove include_internals parameter. - Remove set_focus_child(), get_focus_child(), etc. (Murray Cumming) * Entry: Change EntryIconPosition to Entry::IconPosition. (Murray Cumming) * FileFilter: Change FileFilterFlags to FileFilter::Flags. (Murray Cumming) * FileChooser: - Change FileChooserConfirmation to FileChooser::Confirmation. - Change FileChooserAction to FileChooser::Action. (Murray Cumming) * IconView: change IconViewDropPosition to IconView::DropPosition. (Murray Cumming) * Image: Change ImageType to Image::Type. (Murray Cumming) * Label: Remove get/set_angle() and property. (Murray Cumming) * LevelBar: Change LevelBarMode to LevelBar::Mode. (Murray Cumming) * Notebook: Remove NotebookTab enum. (Murray Cumming) * Popover: Change PopoverConstraint to Popover::Constraint. (Murray Cumming) * PrintOperation: - Change PrintOperationAction to PrintOperation::Action. - Change PrintOperationResult to PrintOperation::Result. (Murray Cumming) * Range: Derive from (and implement) Orientable. (Muray Cumming) Bug #781655 (Daniel Boles) * RecentFilter: Change RecentFilterFlags to RecentFilter::Flags. (Murray Cumming) * Scrollable: Change ScrollablePolicy to Scrollable::Policy. (Murray Cumming) * ShortcutsShortcut: Derive directly from Widget. (Kjell Ahlstedt) * SizeGroup: Rename SizeGroupMode enum to SizeGroup::Mode. (Murray Cumming) * SpinButton: - Change SpinButtonUpdatePolicy to SpinButton::UpdatePolicy. - Move INPUT_ERROR constant into class. (Murray Cumming) * TextConstIter (TextModel::const_iterator): Add a default constructor. (Murray Cumming) * TextMark: Avoid creating a RefPtr to this. By adding a private TextBuffer::get_iter_at_mark() (Murray Cumming) Bug #755037#c21 * TreeModel: Change TreeModelFlags to TreeModel::Flags. (Murray Cumming) * TreeView: - Change TreeViewGridLines to GridLines. - Change TreeViewDropPosition to TreeView::DropPosition. (Murray Cumming) * TreeViewColumn: Change TreeViewColumnSizing to TreeViewColumn::Sizing. (Murray Cumming) * Widget: - Remove get_preferred_width() etc. (Kjell Ahlstedt) - Remove get/set_center_widget(). (Murray Cumming) * Window: - Remove get/set_hide_titlebar_when_maximized(). - Remove has_toplevel_focus() and property. (Murray Cumming) Documentation: * Gtk::CellLayout: Improve docs of get_first_cell() funcs. (Daniel Boles) * Gtk::TreeModel: Improve docs of foreach*() functions. (Daniel Boles) * Gdk, Gtk: Update documentation of in-class enums. (Kjell Ahlstedt) * Demos: - Fix make check after changes in Glib::SignalProxy::connect() (Kjell Ahlstedt) Bug 126213 - Adapt to changed Box::pack_start/pack_end() behaviour. For instance: Specify EXPAND_WIDGET, where we previously used the default value. (Murray Cumming
Re: Replacing pointers with references for output parameters
On Wed, 2017-05-24 at 17:22 +0100, Daniel Boles wrote: > Some things like Gtk::SpinButton::signal_input() still take pointers > in order to write output parameters. In this case, there's a double* > new_value, which users must write back to with the converted value > represented by whatever string was typed in: *new_value = > get_value(blah) > > It would be cleaner C++ to implement such arguments as out references > instead. Is there a reason this was not doing the first time around, > or can we move towards it now? If there's no comment saying why it's a pointer, you could try to fix it. If that shows why it should still be a pointer, it would be nice to have a comment saying that. Thanks. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Replacing pointers with references for output parameters
On Wed, 2017-05-24 at 17:24 +0100, Daniel Boles wrote:
> Ah. It is documented as being able to return a Gtk::INPUT_ERROR, so
> that's why it's an int. Perhaps a real enumeration would be cleaner
> in this case? With enumerators like {unhandled, success,
> input_error}.
Maybe, but that would be an issue for the C API, right?
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Making use of move semantics?
On Sun, 2017-05-21 at 10:36 +0100, Daniel Boles wrote: > I still occasionally find myself reflexively std::move()ing strings > into glibmm/gtkmm functions that I unconsciously see as taking > ownership of their arguments - only to realise it makes no difference > because all of them take strings as const&. > > This made me wonder whether there are any cases where, if the user > instructs so by using std::move(), glibmm/gtkmm functions could steal > the string [ or at least it's c_str() ] and thus avoid having to copy > it. All those copies quickly add up to a lot. > > But my suspicion, without yet having dived into the code, is that > most or all functions like this just take the c_str() and pass that > to the underlying C methods, which would just see it as a char const* > and copy it anyway - meaning we wouldn't be able to gain much or > anything on the mm side. > > Are my initial suspicions accurate, or are there any cases in which > we can use move semantics to avoid copies, either on the mm or C > sides? We've already used move/r-value-references in several places, but not for string arguments. I guess we might start taking std::string_view with C++17 instead of std::string and this might largely take care of this. > Assuming nothing can be done here, if anyone can think of any other > cases where we could make use of move semantics, that'd be a nice > consolation prize. :D -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: enums that are really just sets of constants
On Sat, 2017-05-06 at 18:08 +0100, Daniel Boles wrote:
> So it seems that the only option is to continue using C-style enums
> within classes, e.g. class Dialog { enum ResponseType{} } as
> present.. As someone already mentioned, I see no problem with this:
> such an enum is not inherently bad in itself; it's only bad if chosen
> in o s case where another solution (enum class, constexpr, etc.) is
> an available and more appropriate option. As that does not apply, the
> C-style enum should continue to serve this purpose well.
The old style-enum won't let us change this, in gtkmm 3,
Gtk::RESPONSE_OK
into this, in gtkmm 4:
Gtk::Dialog::Response::OK
without also polluting the API with this
Gtk::Dialog::OK
Using an old-style enum would let us have this:
Gtk::Dialog::RESPONSE_OK,
(and Gtk::Dialog::Response::RESPONSE_OK)
which is still an improvement, but not quite as nice.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm 3.24 or new API in gtkmm 3.22?
On Sun, 2017-04-16 at 17:19 +0100, Daniel Boles wrote: > > Now would be the right time to add or deprecate API in glibmm-2.24, > > before we make that stable release. However, we cannot break ABI. > > > Thanks for the confirmation. I'll get back to those patches this week > and probably post on the bugs to double-check whether they're > suitable for the 2-52 branch. I'd like to release 2.52.0 soonish, so that would be helpful. Thanks. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm4: Box::pack_start()/pack_end()
On Fri, 2017-04-28 at 14:34 +0200, Murray Cumming wrote: > On Fri, 2017-04-28 at 13:25 +0200, Kjell Ahlstedt wrote: > > On 2017-04-28 09:08, Murray Cumming wrote: > > > On Fri, 2017-04-28 at 08:31 +0200, Kjell Ahlstedt wrote: > > > > Why does Gtk::PackOptions affect only horizontal expansion and > > > > alignment? Look for instance at one of the 3 TreeView demo > > > > programs. > > > > The ScrolledWindow is expanded horizontally but not vertically. > > > > Before the expand and fill parameters were removed from > > > > gtk_box_pack_start() the ScrolledWindow was expanded in both > > > > directions. > > > > > > Maybe our pack_start/end() implementation should set > > > hexpand/halign > > > or > > > vexpand/valign depending on the orientation, or always set both. > > > > > > > I vote for always setting both, if we will keep Gtk::PackOptions. > > This fixes that problem with the ScrolledWindow: > https://git.gnome.org/browse/gtkmm/commit/?id=ece3794336e7216c4d25484 > be > 432d5d142ebab1b > > but it causes the left-hand treeview (list of examples) in the demo > to > not expand vertically, and the "Add item" and "Remove item" buttons > in > the "Editable Cells" example now appear to the left instead of > filling > up the whole horizontal space. > > With the attached patch, things seem better, but then those buttons > expand vertically too. > > I guess we need to find out exactly what > halign/hexpand/valign/vexpand/whatever values are really meant to > provide the same behaviour as the previous pack_start(child, expand, > fill): > https://developer.gnome.org/gtk3/stable/GtkBox.html#gtk-box-pack-star > t > > It doesn't look like our old pack_start(child, SHRINK) is the same as > the new gtk_box_pack_start(child). This seems to explain it: https://mail.gnome.org/archives/gtk-devel-list/2017-April/msg00048.html I guess application code must add an extra box.set_vexpand(false) or box.set_hexpand(false) to get the old behaviour, but not always. I guess we should remove our pack_start/pack_end(options) method, but I'd like to keep it just a little longer, so we can port application code gradually. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm4: Box::pack_start()/pack_end()
On Fri, 2017-04-28 at 13:25 +0200, Kjell Ahlstedt wrote:
> On 2017-04-28 09:08, Murray Cumming wrote:
> > On Fri, 2017-04-28 at 08:31 +0200, Kjell Ahlstedt wrote:
> > > Why does Gtk::PackOptions affect only horizontal expansion and
> > > alignment? Look for instance at one of the 3 TreeView demo
> > > programs.
> > > The ScrolledWindow is expanded horizontally but not vertically.
> > > Before the expand and fill parameters were removed from
> > > gtk_box_pack_start() the ScrolledWindow was expanded in both
> > > directions.
> >
> > Maybe our pack_start/end() implementation should set hexpand/halign
> > or
> > vexpand/valign depending on the orientation, or always set both.
> >
> I vote for always setting both, if we will keep Gtk::PackOptions.
This fixes that problem with the ScrolledWindow:
https://git.gnome.org/browse/gtkmm/commit/?id=ece3794336e7216c4d25484be
432d5d142ebab1b
but it causes the left-hand treeview (list of examples) in the demo to
not expand vertically, and the "Add item" and "Remove item" buttons in
the "Editable Cells" example now appear to the left instead of filling
up the whole horizontal space.
With the attached patch, things seem better, but then those buttons
expand vertically too.
I guess we need to find out exactly what
halign/hexpand/valign/vexpand/whatever values are really meant to
provide the same behaviour as the previous pack_start(child, expand,
fill):
https://developer.gnome.org/gtk3/stable/GtkBox.html#gtk-box-pack-start
It doesn't look like our old pack_start(child, SHRINK) is the same as
the new gtk_box_pack_start(child).
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
From 278b3116ded62f111cb5858239696e95547dcfe4 Mon Sep 17 00:00:00 2001
From: Murray Cumming <murr...@murrayc.com>
Date: Fri, 28 Apr 2017 14:15:25 +0200
Subject: [PATCH] Box::pack_start/pack_end(options): Avoid setting child
properties when possible.
PackOptions::SHRINK seems to correspond with the default behaviour of
the new gtk_box_pack_start()/pack_end(), so in this case it seems wise
to avoid the complication of setting the child properties unnecessarily.
---
gtk/src/box.ccg | 8
1 file changed, 8 insertions(+)
diff --git a/gtk/src/box.ccg b/gtk/src/box.ccg
index 218ca437..94a1abc8 100644
--- a/gtk/src/box.ccg
+++ b/gtk/src/box.ccg
@@ -25,6 +25,10 @@ namespace Gtk
void Box::pack_start(Widget& child, PackOptions options)
{
+ if (options == PackOptions::SHRINK) {
+return pack_start();
+ }
+
const bool expand = (options == PackOptions::EXPAND_PADDING) || (options == PackOptions::EXPAND_WIDGET);
const bool fill = (options == PackOptions::EXPAND_WIDGET);
@@ -38,6 +42,10 @@ void Box::pack_start(Widget& child, PackOptions options)
void Box::pack_end(Widget& child, PackOptions options)
{
+ if (options == PackOptions::SHRINK) {
+return pack_start();
+ }
+
const bool expand = (options == PackOptions::EXPAND_PADDING) || (options == PackOptions::EXPAND_WIDGET);
const bool fill = (options == PackOptions::EXPAND_WIDGET);
--
2.11.0
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm4: Box::pack_start()/pack_end()
On Fri, 2017-04-28 at 08:31 +0200, Kjell Ahlstedt wrote: > On 2017-04-27 12:31, Murray Cumming wrote: > > Thoughts? Should we remove these gtkmm-specific > > Box::pack_start()/pack_end() methods anyway? That will still have > > the > > same change-of-behaviour problem for this code: > > box.pack_start(child) > > but if an application also has code like this it will at least > > cause a > > compiler error that forces the developer to think about it: > > box.pack_start(child, Gtk::PACK_SHRINK). > > > > > Why does Gtk::PackOptions affect only horizontal expansion and > alignment? Look for instance at one of the 3 TreeView demo programs. > The ScrolledWindow is expanded horizontally but not vertically. > Before the expand and fill parameters were removed from > gtk_box_pack_start() the ScrolledWindow was expanded in both > directions. Maybe our pack_start/end() implementation should set hexpand/halign or vexpand/valign depending on the orientation, or always set both. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: libgdamm compilation
On Thu, 2017-04-27 at 23:53 -0500, Pavlo Solntsev wrote: > Murray, > > It looks like I was confused by the version labeling. I was able to > compile libgda (upstream version) but without libcrypto support. I > filed a bug for that. I am trying to compile libgdamm using jhbuild > but > always receive: > configure: error: Package requirements (glibmm-2.54 >= 2.45.31 > libgda- > 6.0 >= 5.0.2) were not met: > > No package 'glibmm-2.54' found > > I just found that default branch is not master. I don't know what default would mean here. The git master branch of libgdamm (the libgdamm-6.0 API) builds with the master branch of libgda (the libgda-6.0 API) and the master branch of glibmm (the glibmm-2.54 API). At least, it's meant to. Maybe you are sometimes talking about distro package versions (Debian, Ubuntu, Fedora?) and sometimes about building from git. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: libgdamm compilation
On Thu, 2017-04-27 at 14:08 -0500, Pavlo Solntsev wrote: > Thanks. > > For me it is confused to see one version in the file name and another > inside. I'm sorry. I don't understand. What change are you suggesting? Maybe a patch would make that clearer. Thanks. Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm4: Box::pack_start()/pack_end()
On Thu, 2017-04-27 at 12:31 +0200, Murray Cumming wrote: > The gtk_box_pack_start()/pack_end() API changed slightly, > meaning that our C++ pack_start()/pack_end() convenience overloads > can > no longer have a default value for our PackOptions convenience enum: > https://git.gnome.org/browse/gtkmm/commit/?id=b07a05bba3a2e1df8778683 > a4 > 7e50d8c8f3fb26b > > As the commit message says, that's awkward because the behaviour has > now changed silently, meaning you need to do this to get the old > behaviour (assuming my new implementation works as intended): > https://git.gnome.org/browse/gtkmm/commit/?id=214be98c94d85aa5ac79031 > fa > a5f995e4b797c26 If we had a gtkmm 3.23/34, we could just remove the default value, forcing people to specify the value in their code, thus making it ready for gtkmm 4. Such a small API change is acceptable between, for instance, 3.22 and 3.24, but would be an unpleasant surprise for people if we did it, for instance, between 3.22.1 and 3.22.2. > Thoughts? Should we remove these gtkmm-specific > Box::pack_start()/pack_end() methods anyway? That will still have the > same change-of-behaviour problem for this code: > box.pack_start(child) > but if an application also has code like this it will at least cause > a > compiler error that forces the developer to think about it: > box.pack_start(child, Gtk::PACK_SHRINK). > > -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: libgdamm compilation
On Thu, 2017-04-27 at 07:58 -0500, Pavlo Solntsev wrote: > Hi, > > Why do we have libgda-6.0 >= 5.0.2 in configure.ac? I haven't seen > the > corresponding branch in libgda. libgda's git master is libgda-6.0: https://git.gnome.org/browse/libgda/tree/libgda-6.0.pc.in > Or maybe I missed something. > The recent package is libgda-5.0 therefore it looks like a typo for > me. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: C++/Gtkmm/XML compared to C#/WPF/XAML
On Thu, 2017-04-27 at 12:27 -0400, Bill William wrote: > fair enough... but, which part of gtk defines how the XML maps to the > GUI objects? gtk+, gtkmm, or glade? GtkBuilder in GTK+, and probably parts of the widgets themselves. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: C++/Gtkmm/XML compared to C#/WPF/XAML
On Thu, 2017-04-27 at 09:09 -0400, Bill William wrote: > The problem I have with all these GUI automation tools like glade, > etc... is that they are all based on the old winforms model > ofdragging and dropping everything with a graphical tool with X,Y > coordinates. GTK+ uses automatic layout and always has. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Which glibmm branch shall be used with gtkmm-3?
On Wed, 2017-04-26 at 17:06 +0200, Kjell Ahlstedt wrote: > When I build gtkmm-3 with jhbuild, I get a glibmm-2.4 which is > fetched from the glibmm-2-50 branch. That's because of info in > https://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites- > core-deps-3.26.modules. Is that correct? Or shall it be the glibmm-2- > 52 branch? It should be the glibmm-2.52 branch, which is the latest glibmm-2.4. > I ask because a deprecation warning in glibmm/glib/glibmm/object.cc > should be suppressed now that g_object_newv() is deprecated. I wonder > in which glibmm branch (or branches) I shall do that. glibmm-2-50 or > glibmm-2-52 or both? I suppose we shall not use the replacement > g_object_new_with_properties() in either of these branches, because > then they would depend on glib version 2.54. Agreed. > On the other hand I suppose that at least glibmm-2-52 should be > compatible with glib 2.54. Yes, that would be nice. Thanks. Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
gtkmm4: Box::pack_start()/pack_end()
The gtk_box_pack_start()/pack_end() API changed slightly, meaning that our C++ pack_start()/pack_end() convenience overloads can no longer have a default value for our PackOptions convenience enum: https://git.gnome.org/browse/gtkmm/commit/?id=b07a05bba3a2e1df8778683a4 7e50d8c8f3fb26b As the commit message says, that's awkward because the behaviour has now changed silently, meaning you need to do this to get the old behaviour (assuming my new implementation works as intended): https://git.gnome.org/browse/gtkmm/commit/?id=214be98c94d85aa5ac79031fa a5f995e4b797c26 Thoughts? Should we remove these gtkmm-specific Box::pack_start()/pack_end() methods anyway? That will still have the same change-of-behaviour problem for this code: box.pack_start(child) but if an application also has code like this it will at least cause a compiler error that forces the developer to think about it: box.pack_start(child, Gtk::PACK_SHRINK). -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: perform_create_table wrapper
On Tue, 2017-04-25 at 22:39 -0500, Pavlo Solntsev wrote: > Hello, > > Still trying to get around libgdamm. I found that > gda_server_operation_perform_create_table() has no wrapper. Is there > any reason for that? Probably not, if there's no comment in the .hg file stating a reason. > I made a simple patch to implement this. I may try > to help more if it is useful. Let me know. Please add the patch to a bugzilla bug: https://bugzilla.gnome.org/page.cgi?id=browse.html=libgdamm -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: enums that are really just sets of constants
On Wed, 2017-04-19 at 10:30 +0100, Jonathan Wakely wrote:
> On 19 April 2017 at 09:37, Murray Cumming wrote:
> > In the ABI-breaking versions of glibmm and gtkmm, we have recently
> > changed the enums to be C++11 "enum class"s. This is generally a
> > welcome improvement.
> > - Their values are, for instance, Things::ONE, rather than
> > THINGS_ONE.
> > - Their values do not convert implicitly to other types such as int
> > or
> > bool, helping the compiler to find some programmer mistakes.
> >
> > We are also gradually moving the enums inside classes when they are
> > typically only used with that class.
> >
> > However, some of the C enums that we wrap are actually meant to be
> > integer constants, so it seems that we cannot and should not use
> > "enum
> > class" for these.
>
> How are they used? Are they compared to integers? Are they passed to
> gtk APIs that expect integers?
Both.
> You can use scoped enums anyway, but you'd need an explicit cast to
> an
> integer, so it might not be appropriate.
Yes, that's what we are doing right now. It's a bit ugly.
> > So I wonder what is the most "modern C++" way to do
> > this while keeping the new-style syntax. Here are two
> > possibilities:
> >
> > 1. Use old-style enums inside a class:
> >
> > class ResponseType {
> > public:
> > enum Enum {
> > NONE = -1,
> > REJECT = -2,
> > ACCEPT = -3,
> > ...
> > };
> > };
>
> You can also use a namespace to give them their own scope, which has
> less overhead than a class type (no RTTI for the class, no way for
> users to create instances of the class type, or pointers to it, which
> would have no purpose if it's just being used to create a new scope
> for the enumerators).
Good point.
I'm leaning towards this at the moment.
> > But shouldn't we just avoid old-style enums completely?
>
> Why? Both types still have uses in modern C++. Old doesn't mean bad.
>
> N.B. since C++11 you can use the enumeration type's name as a
> qualification even for unscoped (i.e. old-style, non-class) enums:
>
> enum E { Foo, Bar, Baz };
>
> auto e = E::Foo;
>
> So you can use the new syntax even with old-style enums. The problem
> is that you're not *required* to do that, you can still just say Foo,
> so the names still leak into the surrounding scope.
OK. I wouldn't like that.
> With a scoped
> (i.e. new-style, class) enum the qualification is required.
>
>
> > 2. Use constexpr int constants inside a class:
> >
> > class ResponseType {
> > public:
> > constexpr int NONE = -1;
> > constexpr int
> > REJECT = -2;
> > constexpr int ACCEPT = -3;
> > ...
> > };
> >
> > But shouldn't we use some kind of enum to group the values
> > together?
>
> Is their type actually important?
Not really. These are generally just ints.
> i.e. are these different values of
> the same logical type? If yes, then using an enumeration makes sense.
> Otherwise just using an enumeration type to create an arbitrary group
> doesn't add any benefit.
>
> The example above looks like these are different values for the same
> "thing" so giving them the same type makes sense to me. It allows
> overloading on that type, for example.
>
> Aside: IMHO the shouty ALL_CAPS naming is not good style in C++, see
> https://accu.org/index.php/articles/1923 for my reasoning.
Yes, I saw that mentioned in the C++ Core Guidelines. I might need to
adapt my habits. But that's something to deal with later.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
enums that are really just sets of constants
In the ABI-breaking versions of glibmm and gtkmm, we have recently
changed the enums to be C++11 "enum class"s. This is generally a
welcome improvement.
- Their values are, for instance, Things::ONE, rather than THINGS_ONE.
- Their values do not convert implicitly to other types such as int or
bool, helping the compiler to find some programmer mistakes.
We are also gradually moving the enums inside classes when they are
typically only used with that class.
However, some of the C enums that we wrap are actually meant to be
integer constants, so it seems that we cannot and should not use "enum
class" for these. So I wonder what is the most "modern C++" way to do
this while keeping the new-style syntax. Here are two possibilities:
1. Use old-style enums inside a class:
class ResponseType {
public:
enum Enum {
NONE = -1,
REJECT = -2,
ACCEPT = -3,
...
};
};
But shouldn't we just avoid old-style enums completely?
2. Use constexpr int constants inside a class:
class ResponseType {
public:
constexpr int NONE = -1;
constexpr int
REJECT = -2;
constexpr int ACCEPT = -3;
...
};
But shouldn't we use some kind of enum to group the values together?
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm 3.24 or new API in gtkmm 3.22?
On Fri, 2017-04-14 at 18:56 +0100, Daniel Boles wrote: > My next thought was that I have several, perhaps more, such patches > for glibmm too - which as of now were only allowed into master. If > patches like this were allowed in gtkmm (and I'll soon know the > answer!), to me it would make sense if glibmm made the same > allowance. > > I have most of these patches tagged on Bugzilla with the API tag, if > that helps. I probably missed one or two, though. We have not released glibmm 2.52.0 yet (a version of glibmm-2.24). It's still unstable - the latest release is 2.51.6. Theoretically it should have been released already, but we didn't do that due to the GTK+4 confusion. We should release 2.52.0 fairly soon, I guess. https://git.gnome.org/browse/glibmm/log/?h=glibmm-2-52 Now would be the right time to add or deprecate API in glibmm-2.24, before we make that stable release. However, we cannot break ABI. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: libgdamm in debian
Murray On Fri, 2017-04-14 at 12:25 -0500, Pavlo Solntsev wrote: > Dear Murray. > > Thank you for the clarification. I wasn't able to find glom in > debian repo, but it is available in the ubuntu repo as well as > libgdamm. OK. Maybe Glom is just in Ubuntu and not in Debian. However, this suggests that the Ubuntu libgdamm package would be a good start for a debian package. > BTW, do you still support Glom? I "support" Glom as much as I ever did - which is not very much. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm 3.24 or new API in gtkmm 3.22?
On Sun, 2017-04-09 at 07:20 +0100, Daniel Boles wrote: > On 5 April 2017 at 15:00, Murray Cumming <murr...@murrayc.com> wrote: > > On Sat, 2017-04-01 at 09:22 +0200, Kjell Ahlstedt wrote: > > > I agree with Diether and Daniel: Let's do as gtk+ does, even > > though > > > they break the rules. > > > > OK. Then I don't object anymore. Thanks for being patient. Feel > > free to > > add API in the gtkmm-3-22 branch: > > https://git.gnome.org/browse/gtkmm/log/?h=gtkmm-3-22 > > Is the recently created glibmm-2-52 branch intended as an API- > breaking/adding (within limits of what the C lib does) wrapper of > GLib 2.50? Glib 2.51/52 is meant to just target glib 2.51/52, with no API or ABI break. glibmm-2.54 is the ABI-breaking API, which will be used with gtkmm-4.0. It's not impossible that this will change again, I'm afraid. I'm not aware of any API/ABI breaks in glib. > Maybe then, based on this decision, that stuff should just be put in > glibmm-2-50 anyway? I don't think there is any issue about where to put glib/glibmm API. It's only unusual for GTK+/gtkmm. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm 3.24 or new API in gtkmm 3.22?
On Sat, 2017-04-01 at 09:22 +0200, Kjell Ahlstedt wrote: > I agree with Diether and Daniel: Let's do as gtk+ does, even though > they break the rules. OK. Then I don't object anymore. Thanks for being patient. Feel free to add API in the gtkmm-3-22 branch: https://git.gnome.org/browse/gtkmm/log/?h=gtkmm-3-22 -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Supporting C++17
On Tue, 2017-04-04 at 15:09 +0100, Jonathan Wakely wrote: > On 4 April 2017 at 14:52, Murray Cumming wrote: > > Any ideas about how we should support C++17 in gtkmm-3.0 without > > losing > > C++11/14 compatibility and without breaking ABI? > > Replace all dynamic exception specifications with noexcept(false) (or > just no exception specification). That's not an ABI change. That's great to know. I'll take care of that then. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Supporting C++17
Any ideas about how we should support C++17 in gtkmm-3.0 without losing C++11/14 compatibility and without breaking ABI? Or should we require C++17 for later gtkmm-3.0 versions? Noticed here: https://bugzilla.redhat.com/show_bug.cgi?id=1438766 -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
gtkmm 3.24 or new API in gtkmm 3.22?
On Mon, 2017-03-27 at 14:40 +0200, Kjell Ahlstedt wrote: > I leave that for Murray to decide. I guess that if there will ever be > a gtkmm 3.24 release, new API shall be added only there, and not in > gtkmm 3.22. I still find this hard to decide. I am generally infuriated that GTK+ has added (and deprecated) API in a stable release cycle. I cannot understand why on earth they didn't just branch for GTK+ 3.24. I don't like breaking our promise, and confusing our API versions, just because they did, but I guess we have to do something. At least, it's not very much API, I suppose. What would you (plural) prefer, out of: 1. We add (and deprecate) API in gtkmm 3.22.x. 2. We release gtkmm 3.24 with the added (and deprecated) API, though there will (probably, but nobody really knows) be a GTK+ 3.24. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: New versioning scheme in gtk+. And in gtkmm?
On Wed, 2017-03-22 at 10:04 +, Chris Vine wrote: > I think it was intended to be 2 years before gtk+-4 That sounds about right. Do you happen to have a link to where someone states that officially? -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: New versioning scheme in gtk+. And in gtkmm?
On Sat, 2017-01-14 at 15:25 +0100, Murray Cumming wrote: > We might choose to wait a bit longer, letting us do another stable > glibmm and gtkmm release, maybe then changing the glibmm-2.52 ABI > name > to glibmm-2.54, for instance. glibmm 2.52.0 has been released, but not GTK+ 4.0.0, so now is probably the time to do this. > I don't know when the GTK+ developers plan to call their GTK+-4.0 API > stable, but it's obviously not going to be ready for the next GNOME > release in March 2017. > > There's no sign of a gtk-3-24 branch yet for GTK+, but we might still > release 3.24.* versions of gtkmm-3.0. > > Let's see how things develop over the next few weeks. There's still no gtk+ 3.23/24, but we could still consider doing gtkmm 3.24/25. For now, I guess there is not a great demand for it. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm: Pixbuf::get_pixels()
On Fri, 2017-03-17 at 07:55 +, Daniel Boles wrote: > The copy is done as follows, to support copy-on-write: > > * This function will cause an implicit copy of the pixbuf data if > the > * pixbuf was created from read-only data. > > https://git.gnome.org/browse/gdk-pixbuf/tree/gdk-pixbuf/gdk-pixbuf.c# > n674 > > I thought as long as the apparent functioning of the object is still > the same to external users, then it is allowed to make internal > changes even on a const instance? Using mutable members. > > If so, then maybe it would still be OK to wrap that as a const > method. We are wrapping that as a const method. But we don't need to make anything mutable. We just const_cast the GdkPixbuf*. C doesn't do full C++-like const, so this is often necessary. If I have misunderstood, maybe you could suggest a particular patch. Thanks. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm: Pixbuf::get_pixels()
On Thu, 2017-03-16 at 14:34 +0100, Kjell Ahlstedt wrote: > The const usage is wrong in both get_pixels() methods. Should be > _WRAP_METHOD(guint8* get_pixels(), gdk_pixbuf_get_pixels) > _WRAP_METHOD(guint8* get_pixels(guint& length), > gdk_pixbuf_get_pixels_with_length) > and perhaps > _WRAP_METHOD(const guint8* get_pixels() const, > gdk_pixbuf_get_pixels, constversion) > _WRAP_METHOD(const guint8* get_pixels(guint& length) const, > gdk_pixbuf_get_pixels_with_length, constversion) > > The documentation of gdk_pixbuf_get_pixels[_with_length]() says > "This function will cause an implicit copy of the pixbuf data if the > pixbuf was created from read-only data." > I take this to mean that it's alright for the caller to change the > pixel data. (The implicit copy is owned by the GdkPixbuf object. The > caller shall not delete it.) There is also the > gdk_pixbuf_read_pixels() function (not yet wrapped in Gdk::Pixbuf) > which returns a const guint8*. It's perhaps a better choice when you > don't want to change the pixels, because it does not make a copy of > read-only data. Thanks. I didn't know about that. I've changed it as you suggest: https://git.gnome.org/browse/gtkmm/commit/?id=422c202a31740d2d52c045e97 975b4b7a9f15be4 -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm: PageSettings
On Thu, 2017-03-16 at 14:35 +0100, Kjell Ahlstedt wrote: > You're probably right. I made a mistake by mixing up ArrayHandle and > ArrayHandler. ArrayHandle has a TODO comment, saying that it shall be > removed when we can break ABI. But PageSettings and PrintJob used > ArrayHandler, not ArrayHandle. I can change back to using > ArrayHandler, if you like. Yes, please. It seems cleaner. Thanks. > Den 2017-03-14 kl. 08:13, skrev Murray Cumming: > > Hi. > > > > In this commit: > > https://git.gnome.org/browse/gtkmm/commit/?id=fb1906febeec767d8463e > > c877 > > 2b6c845bf120455 > > > > If the 2 get_page_ranges() methods need different ownership logic, > > wouldn't that just be a matter of changing the Glib::OWNERSHIP_* > > value > > used? > > -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Glibmm-2.52: Shall StreamIOChannel and IOChannel vfuncs be undeprecated?
On Thu, 2017-03-16 at 14:32 +0100, Kjell Ahlstedt wrote: > I don't know if it's useful. Then let's not have it unless we at least have a test case that uses it, please. > Anyway, if the vfuncs in IOChannel are removed, GlibmmIOChannel in > iochannel.ccg must also be removed. It uses the vfuncs. And the > default constructor, which uses GlibmmIOChannel, must be removed, I > suppose. That makes sense. Thanks. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Glibmm-2.52: Shall StreamIOChannel and IOChannel vfuncs be undeprecated?
On Fri, 2017-03-03 at 13:46 +0100, Kjell Ahlstedt wrote: > This concerns glibmm-2.52, the future API/ABI-breaking release. > The whole StreamIOChannel class is deprecated. So are all virtual > functions in IOChannel. A now removed comment explained why: > This feature of being able to implement a custom Glib::IOChannel is > deprecated in glibmm 2.2. The vfunc interface has not yet stabilized > enough to allow that -- the C++ wrapper went in by pure accident. > Is "not yet stabilized enough" still true? The latest ABI change in > the vfuncs was made in February 2002. I can certainly remove > StreamIOChannel and the vfuncs in glibmm 2.52, but wouldn't it be at > least as good to keep them and undeprecate them? IMO the comment > about not yet stabilized vfuncs is obsolete. Thanks for investigating. Would it be useful? Could we even create a test case showing how to use this feature? -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm-4.0: Remove Gtk::Application::create() with argc and argv?
On Tue, 2017-02-07 at 19:16 +0100, Kjell Ahlstedt wrote: > gtk+-4.0 and gtkmm-4.0 are future API/ABI-breaking versions of gtk+ > and gtkmm. > gtk_init() in gtk+-4.0 does not take argc and argv arguments any > more. Therefore Gtk::Application::create() does not use those > arguments. They are just saved and used by Gtk::Application::run(). > There are run() overloads that also take argc and argv arguments. > Removing that create() overload and the corresponding constructor > would result in the cleanest and most logical API. A drawback is that > it requires an extra change in many (probably most) gtkmm > applications when they are upgraded to gtkmm-4.0. For instance in > more than a hundred example programs in gtkmm-documentation. > I suggest that we remove Gtk::Application::create(argc, argv, > application_id, flags) despite the drawback. > Comments? The change in application code is at least simple. It seems fine to me. Thanks. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
ANNOUNCE: gtkmm 3.89.3
*** gtkmm gtkmm 3.89 wraps GTK+ 3.89. It will become gtkmm 4.0, wrapping GTK+ 4.0. It is a version of the gtkmm-4.0 API. It installs in parallel with gtkmm-3.0. gtkmm stays in-sync with gtk+ by (mostly) following the official GNOME release schedule: http://www.gnome.org/start/unstable/ http://www.gtkmm.org *** Changes 3.89.3: (unstable) Distro packagers should probably not package this yet. Gtk: * Grid: attach(): Add default values. (Kjell Ahlstedt) * TextIter: - TextIter: Make a real const_iterator (Kjell Ahlstedt) Bug #142126 - forward/backward_find_char(): Take a sigc::slot instead of a function pointer. (Kjell Ahlstedt) Documentation: * Demos: Remove obsolete text from the TextView demo (Kjell Ahlstedt) -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: New versioning scheme in gtk+. And in gtkmm?
On Wed, 2016-11-16 at 13:56 +0100, Murray Cumming wrote: > > > * glibmm-2.52 instead of glibmm-2.4 > > > * cairomm-1.14 instead of cairomm-1.0 > > This is now cairomm-1.16 instead. > > > > * pangomm-2.42 instead of pangomm-1.4 > > > * atkmm-2.26 instead of atkmm-1.6 > > > * gtkmm-3.0 instead of gtkmm-2.4 > > > > I mean gtkmm-4.0 instead of gtkmm-3.0. We might choose to wait a bit longer, letting us do another stable glibmm and gtkmm release, maybe then changing the glibmm-2.52 ABI name to glibmm-2.54, for instance. I don't know when the GTK+ developers plan to call their GTK+-4.0 API stable, but it's obviously not going to be ready for the next GNOME release in March 2017. There's no sign of a gtk-3-24 branch yet for GTK+, but we might still release 3.24.* versions of gtkmm-3.0. Let's see how things develop over the next few weeks. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
ANNOUNCE: gtkmm 3.89.2
*** gtkmm gtkmm 3.89 wraps GTK+ 3.89. It will become gtkmm 4.0, wrapping GTK+ 4.0. It is a version of the gtkmm-4.0 API. It installs in parallel with gtkmm-3.0. gtkmm stays in-sync with gtk+ by (mostly) following the official GNOME release schedule: http://www.gnome.org/start/unstable/ http://www.gtkmm.org *** Changes 3.89.2: (unstable) Distro packagers should probably not package this yet. Gtk: * Application: Set the global locale. (Kjell Ahlstedt) Bug #661588 * CellArea, CellRenderer, CheckMenuItem: Remove render functions. (Kjell Ahlstedt) * CellView: Remove Remove property_background(), property_background_rgba() and property_background_set(), and set_background_rgba(). (Kjell Ahlstedt) * Container: - forall_vfunc(): Take a sigc::slot instead of a function pointer. - get_child_property_vfunc() and set_child_property_vfunc(): Take Gtk::Widget* and Glib::ValueBase& instead of GtkWidget* and GValue*. - Add get_path_for_child_vfunc(). (Kjell Ahlstedt) Bug #670204 * IconInfo: Rename load_symbolic(context) to load_symbolic_for_context(). (Kjell Ahlstedt) * LevelBar: Implement the Orientable interface. (Kjell Ahlstedt) * PlacesSidebar: signal_populate_popup(): Change Menu* parameter to Container*. (Kjell Ahlstedt) * RecentChooser: get_recent_manager_vfunc(): Fix refcounting. (Kjell Ahlstedt) * Scrollable: Add get_border_vfunc(). (Kjell Ahlstedt) * ToolBar: Implement the Orientable interface. (Kjell Ahlstedt) * ToolShell: Add some vfuncs and make most others const. (Kjell Ahlstedt) * StyleContext: - Remove set/get_junction_sides(). - Remove get_background_color() and get_border_color(). (Kjell Ahlstedt) * TextView: signal_populate_popup(): Change Menu* parameter to Container*. (Kjell Ahlstedt) * TreeIter: Make a real const_iterator. (Kjell Ahlstedt) Bug #134520 * TreeModelFilter, TreeModelSort: Add const method overloads. (Kjell Ahlstedt) Bug #134520 * TreeSelection: Add const versions of get_selected(). (Kjell Ahlstedt) Bug #94742 * TreeView: Remove get_bin_window(). (Kjell Ahlstedt) * TreeRow, TreeNodeChilren: Make real const versions. (Kjell Ahlstedt) Bug #134520 * ViewPort: Remove get_bin_window() and get_view_window(). (Kjell Ahlstedt) * Widget: - Remove get_style_property_value(). (Kjell Ahlstedt) - Add set_margin(). - Remove get_preferred_height_for_width() that takes a baseline. (Murray Cumming) Gdk: * Device: Remove grab() and ungrab(). (Kjell Ahlstedt) * DeviceManager: Remove list_devices(). * Display: - Add is_composited() and is_rgba(). - Remove get_device_manager(). (Kjell Ahlstedt) * Add DrawContext. (Kjell Ahlstedt) * DrawingContext: Add get_paint_context() and property_paint_context(). (Kjell Ahlstedt) * GLContext: - Derive from DrawContext. - Add get_damage(). - Remove property_display() and property_window(), which are moved to DrawContext. (Kjell Ahlstedt) * Pixbuf: Remove create_from_inline(). Remove non-const versions of save() and save_to_buffer(). (Kjell Ahlstedt) * Window: - begin_draw_frame(): Add (optional) context. - Remove ensure_native() and reparent(). (Murray Cumming) General: * Fix some cppcheck issues. (Murray Cumming) * Use Cairo::make_refptr_for_instance(). (Murray Cumming) -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
ANNOUNCE: glibmm 2.51.1.2
*** glibmm: glibmm 2.52 wraps glib 2.52 glibmm 2.52 is a version of the glibmm-2.52 API. It installs in parallel with the gtkmm-2.4 API/ABI, of which the most recent version is glibmm 2.50. http://www.gtkmm.org *** Changes 2.51.1.2 (unstable): Distro packagers should probably not package this yet. Glib: * Remove some deprecated API (Kjell Ahlstedt) * Variant: Remove the string specializations of cast_dynamic. (Kjell Ahlstedt) * Glib::VariantType: Add get_item_types(), removing first() and next(). (Kjell Ahlstedt) Bug #775741 Gio: * init(): Set the global locale. (Kjell Ahlstedt) Bug #661588 * ActionBase: get_state_hint_variant() now returns VariantContainerBase. (Kjell Ahlstedt) * ActionMap: add_action_with_parameter(): Register the parameter type, to make this work. (Daniel Boles) Bug #77 * ActionResult: Add is_tagged_vfunc(). (Kjell Ahlstedt) * Glib::Dispatcher: Implement the pimpl idiom (Kjell Ahlstedt) Bug #651942 * File, FileInfo, FileIOStream, FileOutputStream: Use Glib::ustring for (UTF-8) file attributes of string type. (Kjell Ahlstedt) Bug #615950 * NetworkMonitor: Derive from Gio::Initable. (Kjell Ahlstedt) * RemoteActionGroup: Rename some vfuncs to add _full(). (Murray Cumming) Documentation: * ActionMap: - ActivateSlot: Mention add_action_bool(). - ActivateWithParameterSlot: Be more specific. (Daniel Boles) Bug #77 Build: * Update the Visual Studio project files. (Chun-wei Fan) * Some minor cppcheck fixes. (Murray Cumming) 2.51.1.1 (unstable): General: * Remove no_default_handler in some _WRAP_SIGNAL()s This allows application developers to simply override the default on_*() signal handlers for these signals too, as they can already with most other signals. If you are using, for instance, the -Wsuggest-override compiler option, watch out for new compiler warnings suggesting that your existing signal handler should now be marked with the override keyword - that means you should do so but you should also stop connecting the signal handler in your code. (Kjell Ahlstedt) * Build: examples/Makefile.am: Re-insert the dispatcher examples (Kjell Ahlstedt) Glib: * Dispatcher: Don't cast a HANDLE to an int on Windows. (Kjell Ahlstedt) Bug #772074 * ObjectBase: - Remove connect_property_changed_with_return() and let connect_property_changed() return a sigc::connection. (Kjell Ahlstedt) - Use std::forward_list for interface class pointers. (Kjell Ahlstedt) - Replace extra_object_base_data map by instance data. (Kjell Ahlstedt) * ObjectBase: overload get_property(). (Marcin Kolny) * Main, IOSource: autodeduce type of fd field. (Marcin Kolny) Bug #770274 * Settings: Add property_settings_schema(), and update signal_changed(). (Kjell Ahlstedt) * Settings: Make set_enum() + set_flags() usable (djb) Bug #774647 * SettingsSchemaKey: Add missing value/range methods (Daniel Boles) Bug #774903 * SignalProxyNormal: Remove connect_() and connect_notify_(), adding connect_impl(). (Kjell Ahlstedt) * Rename SignalProxyDetailed to SignalProxyDetailedBase, and SignalProxyDetailedAnyType to SignalProxyDetailed. Remove SignalProxyDetailed# aliases (# = 0..6). (Kjell Ahlstedt) * Source: Replace extra_source_data by instance data. (Kjell Ahlstedt) Bug #561885 Gio: * ActionMap::add_action_vfunc(): Const correction. (Murray Cumming) * Application: Add dbus_register/unregister_vfunc. (Ritesh Khadgaray, Kjell Ahlstedt) Bug #762191 * Menu: insert/prepend/add_item(): Const correction. (Murray Cumming) * MenuAttributeIter: get_value(): Const correction. (Murray Cumming) * MenuModel: get_item_atribute(): const correction. (Murray Cumming) * RemoteActionGroup: Derive from Gio::ActionGroup. (Murray Cumming) Gio::Dbus: * Proxy: Fix memory leak in get_cached_property_names(). (Kjell Ahlstedt) Bug #775210 * Proxy: Derive from (and implement) Gio::DBus::Interface. (Murray Cumming) -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
gtkmm 4: Glib::ustring: implicit conversions with streams
I guess now is the time to revisit this: https://mail.gnome.org/archives/gtkmm-list/2007-May/msg00061.html I think this is the bug comment that Daniel was referring to there: https://bugzilla.gnome.org/show_bug.cgi?id=93787#c3 Would anyone like to investigate and maybe prepare a patch? -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
ANNOUNCE: gtkmm 3.89.1
*** gtkmm gtkmm 3.89 wraps GTK+ 3.89. It will become gtkmm 4.0, wrapping GTK+ 4.0. It is a version of the gtkmm-4.0 API. It installs in parallel with gtkmm-3.0. gtkmm stays in-sync with gtk+ by (mostly) following the official GNOME release schedule: http://www.gnome.org/start/unstable/ http://www.gtkmm.org *** Changes 3.89.1: (unstable) This is the first release of the gtkmm-4.0 API/ABI, wrapping GTK+-4.0. It installs in parallel with the gktmm-3.0 API/ABI, of which the most recent version is gtkmm 3.22.0. Build/General: * Use GTK+-4.0 instead of GTK+-3.0. (Kjell Ahlstedt) * Use C++14. (Murray Cumming) * Use glibmm-2.52 instead of glibmm-2.4, pangomm-2.42 instead of pangomm-1.4, and atkmm-2.26 instead of atkmm-1.6. Note that, via, glibmm, we now use libsigc++-3.0 instead of libsigc++-2.0. (Murray Cumming) * Remove deprecated API. (Kjell Ahlstedt) * Add default signal handlers (on_*()), where we couldn't before without breaking ABI. (Kjell Ahlstedt) Gtk: * Container: Make add() non-virtual. (Kjell Ahlstedt) * FontButton: Derice from, and implement, the FontChooser interface. (Kjell Ahlstedt) * Label(): don't use misleading align argument names. (djb) Bug #774652 * Object: Remove gobject_disposed_. (Kjell Ahlstedt) * ToolButton: Derive from, and implement, the Actionable interface. (Kjell Ahlstedt) * Widget: Add measure() and measure_vfunc(), which replaces get_preferred_*_vfunc(). (Kjell Ahlstedt) * Window: Make raise() non-virtual. (Kjell Ahlstedt) Documentation: * Frame: Fix the documentation of set_label_align() (Kjell Ahlstedt) Bug #774249 -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
ANNOUNCE: glibmm 2.51.1
*** glibmm: glibmm 2.52 wraps glib 2.52 glibmm 2.52 is a version of the glibmm-2.52 API. It installs in parallel with the gtkmm-2.4 API/ABI, of which the most recent version is glibmm 2.50. http://www.gtkmm.org *** Changes 2.51.1: This is the first release of the glibmm-2.52 API/ABI. It installs in parallel with the gtkmm-2.4 API/ABI, of which the most recent version is glibmm 2.50. We know that is a bit confusing. We are taking the opportunity to do this glibmm ABI break while GTK+ (and therefore gtkmm) is also doing an ABI break. But we cannot call this glibmm-3.0 because there is no glib 3.0. Build: * Require C++14. (Murray Cumming) * Use libsigc++-3.0 instead of libsigc++-2.0. https://www.murrayc.com/permalink/2016/03/07/libsigc-3-0-very-variadi c/ (Murray Cumming) * Remove lots of deprecated API. (Kjell Ahlstedt) Gio: * BufferedInputStream, InputStream, OutputStream: Add vfuncs, allowing implementation in C++. (Krzysztof Kosiński, Kjell Ahlstedt) Bug #572471 * SettingsSchemaSource::get_default(): Correct the reference count. (Marcin Kolny) Bug #774593 * Settings: Fix type of 'key' parameter of writable-change-event signal (Marcin Kolny) Bug #773977 Glib: * ustring: Add cbegin() and cend(). (Murray Cumming) -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Replacing RefPtr with shared_ptr<>.
For gtkmm 4 (well, in the corresponding glibmm), we are thinking of replacing Glib::RefPtr with std::shared_ptr: https://bugzilla.gnome.org/show_bug.cgi?id=755037 This is a large change so I'm mentioning it here too. It shouldn't affect application code much if it works. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: New versioning scheme in gtk+. And in gtkmm?
On Mon, 2016-11-14 at 11:08 +0100, Murray Cumming wrote: > > * glibmm-2.52 instead of glibmm-2.4 > > * cairomm-1.14 instead of cairomm-1.0 This is now cairomm-1.16 instead. > > * pangomm-2.42 instead of pangomm-1.4 > > * atkmm-2.26 instead of atkmm-1.6 > > * gtkmm-3.0 instead of gtkmm-2.4 > > I mean gtkmm-4.0 instead of gtkmm-3.0. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: New versioning scheme in gtk+. And in gtkmm?
On Mon, 2016-11-14 at 10:51 +0100, Murray Cumming wrote: > * glibmm-2.52 instead of glibmm-2.4 > * cairomm-1.14 instead of cairomm-1.0 > * pangomm-2.42 instead of pangomm-1.4 > * atkmm-2.26 instead of atkmm-1.6 > * gtkmm-3.0 instead of gtkmm-2.4 I mean gtkmm-4.0 instead of gtkmm-3.0. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: New versioning scheme in gtk+. And in gtkmm?
On Thu, 2016-11-10 at 12:15 +0100, Murray Cumming wrote: > Because we are creating a new parallel-installable gtkmm ABI (gtkmm- > 4.0), for use with GTK+ 4.0, this is a fairly good time to do the > same > with glibmm, though glib will not have a new ABI at this time. > > That let's us remove some deprecated API and let's us depend on the > newer, simpler (because it's C++14) libsigc++-3.0. That means that > gtkmm-4.0 would require C++14, but I think that should be fine for > anyone who's likely to want to use it. > > The last stable version of glibmm (the glibmm-2.4 ABI) was glibmm > 2.50, > so we would have to call our new glibmm ABI glibmm-2.52. That's not > pretty, but I don't see a better alternative. We can't call it > glibmm- > 3.0 because that would cause problems when there is a glib-3.0 one > day. I have pushed the changes to the git master branches. So we now have: * glibmm-2.52 instead of glibmm-2.4 * cairomm-1.14 instead of cairomm-1.0 * pangomm-2.42 instead of pangomm-1.4 * atkmm-2.26 instead of atkmm-1.6 * gtkmm-3.0 instead of gtkmm-2.4 That is a bit of a mess, so I welcome alternative suggestions, though I guess this is how it must be. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: New versioning scheme in gtk+. And in gtkmm?
Because we are creating a new parallel-installable gtkmm ABI (gtkmm- 4.0), for use with GTK+ 4.0, this is a fairly good time to do the same with glibmm, though glib will not have a new ABI at this time. That let's us remove some deprecated API and let's us depend on the newer, simpler (because it's C++14) libsigc++-3.0. That means that gtkmm-4.0 would require C++14, but I think that should be fine for anyone who's likely to want to use it. The last stable version of glibmm (the glibmm-2.4 ABI) was glibmm 2.50, so we would have to call our new glibmm ABI glibmm-2.52. That's not pretty, but I don't see a better alternative. We can't call it glibmm- 3.0 because that would cause problems when there is a glib-3.0 one day. Any objections? -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: New versioning scheme in gtk+. And in gtkmm?
On Tue, 2016-10-25 at 16:22 +0200, Kjell Ahlstedt wrote: > Gtk+ has announced a new versioning scheme: > https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-pr > omise-in-gtk > Now the gtk+ developers have created a gtk-3-22 branch and started > removing deprecated API in the master branch. I guess we have to do > the same in gtkmm whether we like it or not, if we want gtkmm to be > compatible with gtk+'s master branch. Is there a reasonable > alternative? > Kjell Agreed. Anything else would be even more confusing. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: New versioning scheme in gtkmm? In glibmm?
On Mo, 2016-09-26 at 22:26 +0200, Murray Cumming wrote: [snip] > I don't think it's likely to work so I'd rather just wait and see > what > actually happens. At the least, it just looks like a suggestion that > they want to start working more now on a parallel-installable GTK+ 4. > That would be nice but I don't see how that's much more likely to > happen quickly now than before. > > I'm happy for us to try targeting GTK+ 4, but I wouldn't do that in > git > master before GTK+ 3.9/4 is in git master. GTK+ 4 does seem to be happening in GTK+'s git master now. I haven't built it yet, but I'm happy for us to target it in gtkmm's git master. I have already created the stable gtkmm-3-22 branch. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: New versioning scheme in gtkmm? In glibmm?
On Di, 2016-09-27 at 01:27 +0100, Chris Vine wrote: > On Mon, 26 Sep 2016 22:26:01 +0200 > Murray Cumming <murr...@murrayc.com> wrote: > > > > On Fr, 2016-09-23 at 16:51 +0200, Kjell Ahlstedt wrote: > > > > > > Gtk+ has announced a new versioning scheme: > > > https://blog.gtk.org/2016/09/01/versioning-and-long-term-stabilit > > > y-pr > > > omise-in-gtk > > > I suppose that it will affect gtkmm. Will gtkmm use the same > > > versioning scheme? If so, I suppose that once a gtkmm-3-22 branch > > > has been created in the git repository, we shall start removing > > > all > > > deprecated API in the master branch. And fix bug reports that > > > require an ABI and/or API break. Am I right? > > > Will glib use a similar versioning scheme? I.e. soon an ABI/API- > > > breaking glib 2.90 release and then glib 3.0? > > > Kjell > > It's very hard to know what they really intend, or what will really > > happen. But it looks like this is what they want: > > * GTK+ 4.0, 5.0, 6.0, etc, will be stable releases (installed in > > parallel, as we'd already expect). > > * GTK+ 3.9*, 4.9*, 5.9* will be unstable releases of those APIs. > > * These will take longer to become stable releases, compared to the > > 6- > > monthly cycles we have now, with releases such as 3.2.x, 3.4.x, > > 3.6.x, > > etc. > > > > So it just looks like they want to take much longer between stable > > releases that add new API. > That isn't really it. The intention is that API/ABI will be broken > with > every new major stable release, as at present (so 5.0 will be API/ABI > incompatible with 4.0, and so on), but that these new major stable > releases will come out at a much higher rate than at present - every > 2 > to 3 years. Yes. I don't think that's workable, at least not with a time-based release schedule that people believe in. I can't see how they will avoid adding API in stable releases too. So in the end, I don't see how much will change, other than that we will now have uncertainty about what and when things should, and will, happen. I'm not a fan, clearly. It looks like people have got so used to having time-based releases that they forgot why they need them - a bit like thinking that diseases aren't serious because we are used to having vaccinations. But I'm also not heavily involved, so my opinion shouldn't count for much. > This is supposedly firstly to allow for a higher rate of > innovation (official breakage), and secondly to reduce the amount of > unofficial breakage between ostensibly stable and compatible > releases, Of course, the answer to that would be just to document things properly. > which has caused problems with the 3.* series. Successive > incompatible > stable releases will come out more frequently, but within any major > version compatibility will be more rigorously enforced. In > particular, > once a new major stable release has actually come out, thereafter it > will only receive bug fixes and not new features. > > There will still be six-monthly releases of new minor versions, > leading > to the next stable release every 2 to 3 years' time, but these minor > releases are not guaranteed to be compatible with one another. > > I can't say I like it, but there we are. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: New versioning scheme in gtkmm? In glibmm?
On Fr, 2016-09-23 at 16:51 +0200, Kjell Ahlstedt wrote: > Gtk+ has announced a new versioning scheme: > https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-pr > omise-in-gtk > I suppose that it will affect gtkmm. Will gtkmm use the same > versioning scheme? If so, I suppose that once a gtkmm-3-22 branch has > been created in the git repository, we shall start removing all > deprecated API in the master branch. And fix bug reports that require > an ABI and/or API break. Am I right? > Will glib use a similar versioning scheme? I.e. soon an ABI/API- > breaking glib 2.90 release and then glib 3.0? > Kjell It's very hard to know what they really intend, or what will really happen. But it looks like this is what they want: * GTK+ 4.0, 5.0, 6.0, etc, will be stable releases (installed in parallel, as we'd already expect). * GTK+ 3.9*, 4.9*, 5.9* will be unstable releases of those APIs. * These will take longer to become stable releases, compared to the 6- monthly cycles we have now, with releases such as 3.2.x, 3.4.x, 3.6.x, etc. So it just looks like they want to take much longer between stable releases that add new API. That doesn't seem so different to how it was a few years ago before GTK+ finally synchronized with the 6-monthly GNOME schedule. It didn't work very well then. Too many people won't try new API until they are fairly sure that it's going to be available soon. And without a firm stable release date they cannot risk using it in GNOME application code that does have a firm release date. So the GTK+ developers won't get feedback until long after they've committed the code, and often won't get that feedback until too late, after they've declared the API stable. This is why we have time-based releases. I don't think it's likely to work so I'd rather just wait and see what actually happens. At the least, it just looks like a suggestion that they want to start working more now on a parallel-installable GTK+ 4. That would be nice but I don't see how that's much more likely to happen quickly now than before. I'm happy for us to try targeting GTK+ 4, but I wouldn't do that in git master before GTK+ 3.9/4 is in git master. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtkmm-list Digest, Vol 149, Issue 3
Could you please subscribe to the full mailing list, so we don't see these odd email subjects when you reply. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Bug in documentation: Gio::File Class Reference
On Do, 2016-08-11 at 19:05 +0200, Kjell Ahlstedt wrote: > Den 2016-08-09 kl. 19:28, skrev Kjell Ahlstedt: > > Den 2016-08-05 kl. 09:45, skrev Murray Cumming: > > > Maybe we could just remove any sentence that includes "g_free". > > > We > > > might lose a little information that happens to be in the same > > > sentence, but I guess it would be worth it. > > > > > > > > That's a good idea. I'll test it to see what it would do to the > > documentation of glibmm and gtkmm. > > Kjell > > > I have pushed the patch "gmmproc: Add > DocsParser::remove_c_memory_handling_info()" > https://git.gnome.org/browse/glibmm/commit/?id=1ced6f1a720828122b5c8e > 7d136c8e93f1fb05ea > > It behaves reasonably well when building glibmm and gtkmm. [snip] Thanks, Kjell. That should be a big improvement. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Bug in documentation: Gio::File Class Reference
On Do, 2016-08-04 at 09:16 +0200, Kjell Ahlstedt wrote: [snip] > Unless you, or someone else, make > a considerable improvement of the gmmproc command. Maybe we could just remove any sentence that includes "g_free". We might lose a little information that happens to be in the same sentence, but I guess it would be worth it. Alwin, thanks for mentioning these documentation errors. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: C++14
Actually, I don't see a real need for it, so I don't have a good reason to require C++14 (instead of C++11) just yet. Murray On Mo, 2016-08-01 at 21:04 +, Christoph Brill wrote: > Hi Murray, > > I'm all for latest C++ changes. g++ supports it, clang supports it. > That's all compilers relevant to me. > > Best wishes, > Christoph > > Murray Cumming <murr...@murrayc.com> schrieb am Do., 7. Juli 2016 um > 12:19 Uhr: > > Our current stable versions require C++11. Does anybody object to > > us > > requiring C++14 for the current unstable versions, which will > > become > > the next stable versions? GCC 6 uses C++14 by default. > > > > We don't need C++14 for anything urgently but it would be nice to > > have > > some little things such as decltype(auto) and std::make_unique(). > > > > -- > > Murray Cumming > > murr...@murrayc.com > > www.murrayc.com > > > > > > > > ___ > > gtkmm-list mailing list > > gtkmm-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtkmm-list > > > ___ > gtkmm-list mailing list > gtkmm-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtkmm-list -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: gtksourceviewmm changes
On Mo, 2016-08-01 at 21:01 +, Christoph Brill wrote: > Hi list, > > last year I did some changes to gtksourceviewmm which I never > attempted to put upstream. See: > > https://github.com/egore/gtksourceviewmm/commits/master > > Is there any interest by "upstream" (hi Murray ;-) to accept these > changes? Or should I just throw them away. I'm not having any trouble > with it either way. Just let me know. Thanks. I've made some fixes to those commits (see my comments in github), and some extra commits, and I have pushed it to master: https://git.gnome.org/browse/gtksourceviewmm You shouldn't need to write the documentation inline in the .hg file unless you are significantly rewriting it. gmmproc generates documentation based on the C documentation. But I didn't bother to remove the inline documentation to check that that is working properly. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is libgnomedbmm obsolete?
On Do, 2016-07-28 at 09:59 +0200, Kjell Ahlstedt wrote: > There is an open gtkmm bug that actually concerns libgnomedbmm, https > ://bugzilla.gnome.org/show_bug.cgi?id=768819 > That made me wonder about the status of both libglademm and > libgnomedbmm. > Both libglade, libglademm, libgnomedb and libgnomedbmm are listed as > products in Bugzilla, but with different classification. > libglade: Deprecated > libglademm: Otherlibgnomedb: Deprecated > libgnomedbmm: Other > The deprecated products are found only on Bugzilla's search page. > > Should libglademm and libgnomedbmm also be classified as deprecated? Yes. libglademm is replaced by Gtk::Builder. libgnomedbmm is replaced by libgdamm. > I know that libglademm has been superseded by Gtk::Builder. > I don't know much about libgnomedbmm. Is it correct that > libgnomedb(mm) is a GUI for libga(mm)? Recent versions of libgda > contain GUI classes like GdauiGrid and GdauiForm. It looks like > libgnomedb has become a part of libgda. Has libgnomedbmm been > superseded by libgda-uimm? > > When I built libgdamm and libgda-uimm from the latest code in the git > repository, I noticed that both libgdamm and libgda-uimm needed some > fixes in order to build. They have not kept up with the latest > changes in libgda. Would it be a good idea for me to update them? I wouldn't waste time on them, if I was you. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
C++14
Our current stable versions require C++11. Does anybody object to us requiring C++14 for the current unstable versions, which will become the next stable versions? GCC 6 uses C++14 by default. We don't need C++14 for anything urgently but it would be nice to have some little things such as decltype(auto) and std::make_unique(). -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Accessing pair in Gtk::TreeModelColumn
On Fr, 2016-07-01 at 15:14 +0530, Kamalpreet Grewal wrote: > I am making a pair as data type of Gtk::TreeModelColumn. > Gtk::TreeModelColumn<std::pair<Glib::ustring, Glib::ustring> > col; > > At some places I wish to get only first string of this pair. So I did > something like row[columns.col].first to access it. But I get an > error. > > error: 'class Gtk::TreeValueProxy<std::pair<Glib::ustring, > Glib::ustring> >' has no member named 'first' > > I am accessing it just like one will do with another std::pair. How > can this be achieved? Try putting it in a pair first. For instance: std::pair<Glib::ustring, Glib::ustring> thing = row[columns.col]; auto str = thing.first; That might also work like this: const std::pair<Glib::ustring, Glib::ustring>& thing = row[columns.col]; const auto& str = thing.first; -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: ABI report for Glibmm, Pangomm and Cairomm
On Fr, 2016-06-24 at 17:08 +0300, Ponomarenko Andrey wrote: > Hello, > > The Glibmm, Pangomm and Cairomm libraries have been added recently to > the upstream ABI tracker project. The tracker performs backward > binary compatibility analysis for the recent versions of libraries: > > http://abi-laboratory.pro/tracker/timeline/glibmm/ > http://abi-laboratory.pro/tracker/timeline/pangomm/ > http://abi-laboratory.pro/tracker/timeline/cairomm/ > > The reports are generated daily with the help of the abi-compliance- > checker and abi-tracker tools: https://github.com/lvc/abi-tracker > > Hope this will help users, maintainers and developers of libraries to > maintain backward compatibility. Thanks. But this would be more useful if it understood about stable and unstable development cycles. ABI changes are to be expected between unstable releases, but not when comparing stable releases. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::TreeSelection problem (redux)
On Mo, 2016-05-16 at 08:16 -0700, Phil Wolff wrote: [snip] > Both of these code snippets generate the following two error > messages > when the if-test is satisfied: > > Gtk-CRITICAL **: gtk_tree_store_get_value: assertion > 'VALID_ITER > (iter, tree_store)' failed > GLib-GObject-CRITICAL **: g_value_get_string: assertion > 'G_VALUE_HOLDS_STRING (value)' failed > > Is this reasonable? This might just be a symptom of some other problem, such as a null pointer somewhere. You might get more clues by running under valgrind, or just by cutting your code down to the smallest possible example that reproduces the problem. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Gtk::PageSetup and Gtk::PrintSettings
On Do, 2016-04-28 at 11:12 -0700, Phil Wolff wrote: > The static members create_from_file() and create_from_key_file() are > public in Gtk::PageSetup, but protected in Gtk::PrintSettings. Is > there > a reason for this difference? It looks like a simple mistake in PrintSettings and you are the first to try to use those methods since they were added in 2008, or at least the first to mention it. Thanks. I've fixed it in git master: https://git.gnome.org/browse/gtkmm/commit/?id=0283fe2267f7d978945f7e8d2 68895b56c7e438d For now, you could try just using the public create() method and calling load_from_*(), like the implementation of the protected create_*() methods: https://git.gnome.org/browse/gtkmm/tree/gtk/src/printsettings.ccg#n77 -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Compiling and options
On Fri, 2016-04-22 at 09:22 +0100, Russel Winder wrote: > On Mon, 2016-04-18 at 19:57 +0200, Murray Cumming wrote: > […] > > On debian, it's actually coming from the libsigc++ pkg-config file, > > as > > I think you'll find when you do this: > > $ pkg-config sigc++-2.0 --cflag > > > > They have done this against our wishes: > > https://bugzilla.gnome.org/show_bug.cgi?id=755750#c13 > > This has been marked as "resolved wontfix" so clearly they are > telling > everyone already using C++14 and C++17 to "shut up and put up", which > I > guess is not untypical. That's our upstream bug. It's wontfix because we refused to put -std=c+=11 in the pkg-config file. But debian did it themselves anyway. > Currently, using SCons, I can edit the -std=c++11 out and add my own > -std=c++14, but using CMake things are far more awkward. > > > This is very much a distro-specific problem that you should > > complain > > to > > your distro about. Sorry. I am annoyed with them, not with you. > > Thanks > > for letting me know. > > I will add a bug to the Debian archive. It seems Fedora already work > around this somehow. Fedora just didn't do this. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Compiling and options
On Mon, 2016-04-18 at 17:37 +0100, Russel Winder wrote: > This appears to be just a Debian Sid thing, it does not happen with > Fedora Rawhide or OSX/MacPorts. > > > > > pkg-config glibmm-2.4 --cflags > -std=c++11 -I/usr/include/glibmm-2.4 -I/usr/lib/x86_64-linux- > gnu/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib/x86_64 > -linux- > gnu/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64 > -linux- > gnu/sigc++-2.0/include > > > > pkg-config gtkmm-3.0 --cflags > -std=c++11 -pthread -I/usr/include/gtkmm-3.0 -I/usr/lib/x86_64-linux- > gnu/gtkmm-3.0/include -I/usr/include/atkmm-1.6 -I/usr/include/gtk- > 3.0/unix-print -I/usr/include/gdkmm-3.0 -I/usr/lib/x86_64-linux- > gnu/gdkmm-3.0/include -I/usr/include/giomm-2.4 -I/usr/lib/x86_64 > -linux- > gnu/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib/x86_64- > linux-gnu/pangomm-1.4/include -I/usr/include/glibmm-2.4 > -I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/gtk-3.0 > -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 > -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include > -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ > -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz > -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/cairomm-1.0 -I/usr/lib/x86_64-linux-gnu/cairomm- > 1.0/include -I/usr/include/cairo -I/usr/include/pixman-1 > -I/usr/include/freetype2 -I/usr/include/libpng16 > -I/usr/include/sigc++- > 2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -I/usr/include/gdk > - > pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include On debian, it's actually coming from the libsigc++ pkg-config file, as I think you'll find when you do this: $ pkg-config sigc++-2.0 --cflag They have done this against our wishes: https://bugzilla.gnome.org/show_bug.cgi?id=755750#c13 This is very much a distro-specific problem that you should complain to your distro about. Sorry. I am annoyed with them, not with you. Thanks for letting me know. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Compiling and options
On Mon, 2016-04-18 at 13:51 +0100, D. B. wrote: > Russel: Just reorder arguments in your makefile such that your own > compiler options come after pkg-config's ones. Any later value for a > given option overrides the earlier one. > > Murray: I had to do exactly this to use -std=c++14 on Debian testing, > so yes, it does happen 'in the wild'. I can't find any such patch for the debian packages via this system: https://sources.debian.net/patches/gtkmm3.0/ https://sources.debian.net/patches/glibmm2.4/ Please show us the output of these commands, so we can see exactly where this -std=c++11 is coming from: $ pkg-config glibmm-2.4 --cflags $ pkg-config gtkmm-3.0 --cflags > Do you mean that 'plain' gtkmm does not enforce any -std? Indeed. It does not, for this very reason. > I thought C++11 was required for gtkmm, but do you normally require > users to add that manually in their own place? Yes. Adding it as CFLAG from pkg-config would cause this very problem. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Compiling and options
On Sun, 2016-04-17 at 14:53 +0100, Russel Winder wrote: > From 3.18 onwards, the pkg-config for gtkmm-3.0 enforces -std=c++11. No, it doesn't. Maybe you are using some strange distro package of gtkmm that has made this change? > This is really sad for those of use wanting to use -std=c++14 or > later. > Does anyone have an idiomatic way of not allowing pkg-config to > enforce > the -std=c++11? -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Replace Gtk::manage() with std::unique_ptr<>?
On Mon, 2016-02-08 at 21:50 +0100, Murray Cumming wrote: > The more I see how awkward my suggestion can be, the more I hesitate > to > deprecate Gtk::manage() even if we have support unique_ptr<>. I plan to commit this, without deprecating Gtk::manage(), but probably not for gtkmm 3.20 because there would not be enough time for people to test it. https://bugzilla.gnome.org/show_bug.cgi?id=761665 -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is there a .defs spec? Where?
I can't find it anymore. It was here: http://www.gnome.org/~james/defs-format.html though I don't know if that was the latest version. And it should be here, if the waybackmachine works again for that page some time: https://web.archive.org/web/20141224110746/http://people.gnome.org/~jam es/defs-format.html However, maybe this was a later official version: https://git.gnome.org/browse/gtk+/commit/?id=65db1100ecae9d0878be95eaba 92cc3612bfe8cf There are not so many projects that use the .defs format now, so you should feel free to use it however you like. Murray On Mon, 2016-03-07 at 10:24 +0100, Kjell Ahlstedt wrote: > The file glibmm/tools/extra_defs_gen/generate_extra_defs.cc contains > the comment > //#t and #f aren't documented, but I guess that it's correct > based on the example in the .defs spec. > Where can I find that spec? > > It would be fine if gmmproc could report wrapped signals and > properties that are deprecated in glib/gtk+ but not in glibmm/gtkmm. > To be able to do that, I want to add some information to the > *_signals.defs files. If these files meet a spec, I want them to meet > that spec also after my changes, if possible. > > Kjell > > ___ > gtkmm-list mailing list > gtkmm-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtkmm-list -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: clang-format syntax
I will run this on glibmm first, quite soon. Let me know if there are any patches that you want to get in first, before I cause merge/rebase conflicts. -- Murray Cumming murr...@murrayc.com www.murrayc.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
