Re: glibmm versions

The gtk+ team are working on a new gtk+-4.0 ABI, parallel-installable with gtk+-3.0. The corresponding gtkmm ABI is gtkmm-4.0. The glib team don't plan for a new glib ABI. It will still be glib-2.0. But there will be a new glibmm ABI, parallel-installable with glibmm-2.4. Unfortunately the name

Re: glibmm versions

glibmm-2.56 was once the tentative ABI-name of a series of new ABI-breaking releases of glibmm. Now the still tentative ABI-name is glibmm-2.58. It's very confusing. I've tried to explain in a jhbuild bug. https://bugzilla.gnome.org/show_bug.cgi?id=792047#c6

New ABI names for glibmm-2.58, atkmm-2.28 and pangomm-2.42?

Shall the ABI names of the future ABI breaking releases of glibmm, atkmm and pangomm be changed once again? 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

Re: libgdamm development

I have not worked with libgdamm, but when looking at some files in the GitLab repository, I can see that they are out of date and/or inconsistent. jhbuild's gnome-world.modules file says that libgdamm's master branch depends on gtkmm-3 (and thus indirectly on glibmm-2.4). This does not fit

Re: C++17

On 14 April 2018 at 15:38, Murray Cumming wrote: 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

Re: c++ source generation from C code

On 2018-07-12 05:43, Pavlo Solntsev via gtkmm-list wrote: Hi, As I mentioned before, libgda was significantly modified and as results, libgdamm is broken. I was trying to fix this. Overall, I was very close to the final solution but it looks like the generated c++ code contains statement like:

Re: Which new releases of gtkmm and friends shall be made?

Den 2018-10-23 kl. 17:26, skrev Daniel Boles via gtkmm-list: If we agree to merge Gtk::make_managed(), then the patch I have in an MR on GitLab will make gtkmm-documentation 3.24 more interesting, as it includes updates about that! Agree. Based on what you said on GitLab, I guess you're

Which new releases of gtkmm and friends shall be made?

No new releases of gtkmm and friends have been made for a long time. This is what I think shall be released fairly soon: _Module__Branch__New release_ libsigcplusplus  libsigc++-2-10  2.10.1 libsigcplusplus master    2.99.12 glibmm  glibmm-2-56  2.56.1 glibmm  glibmm-2-58 (new)  2.58.0 glibmm 

Re: Which new releases of gtkmm and friends shall be made?

Will you create merge requests, merge yourself, or do you want me to do it? I can't do much on cairomm. I have no write permission there. /Kjell Den 2018-10-26 kl. 13:58, skrev 范，君維: Hi Kjell, The mentioned branches should be ready now; I also opened two issues on cairomm for the master

Re: How to set application flags?

In gtkmm-3.0 and the corresponding glibmm-2.4 it's Gio::APPLICATION_NON_UNIQUE or Gio::ApplicationFlags::APPLICATION_NON_UNIQUE. In gtkmm-4.0 and the corresponding glibmm-2.60 it's Gio::Application::Flags::NON_UNIQUE. Gtkmm-4.0 and glibmm-2.60 are still highly unstable. They are not yet

Re: Dead links to documentation

On 2018-11-13 14:23, Daniel Boles via gtkmm-list wrote: Yes, clearly the new releases of 3.22 and/or 3.24 just suffer from the same problem (3.22 does not work, and stable is either that or 3.24), and it's going to keep happening and become more of a problem until someone fixes it. Either way,

Re: Dead links to documentation

On 2018-11-13 19:46, Kasper Peeters wrote: This has been a known problem for more than a year. The program that publishes reference documentation for released modules at https://developer.gnome.org// is not compatible with new versions of Doxygen. Does anyone know who is in charge of this? Not

Why is glibmm said to require builddir == sourcedir builds?

From jhbuild/modulesets/gnome-suites-core-deps-latest.modules:     I've used jhbuild to build glibmm without the supports-non-srcdir-builds="no" parameter. I can't see nay problem. Everything seems to work normally in a builddir != sourcedir build: make, make install, make check, make

Re: Dead links to documentation

On 2018-11-14 13:18, Kjell Ahlstedt wrote: On 2018-11-13 19:46, Kasper Peeters wrote: This has been a known problem for more than a year. The program that publishes reference documentation for released modules at https://developer.gnome.org// is not compatible with new versions of Doxygen.

Re: Pango alignment versus wrapping

In the description of Pango::Alignment at https://developer.gnome.org/pangomm/2.38/group__pangommEnums.html#gaf6b8926663368e305380e01f8858caca I found this: If the Pango::Layout is set to justify using Pango::Layout::set_justify(), this only has effect for partial lines. The description of

Re: Sockets (Client/Server)

TCP communication is handled by Gio::Socket in glibmm. There is an example at https://gitlab.gnome.org/GNOME/glibmm/tree/glibmm-2-58/examples/network but it does not include windows. Gtk::Socket is another kind it socket. It has nothing to do with TCP or UDP. /Kjell On 2019-02-26 21:44,

Re: Cannot get button press event on drawing area

You must set the optional /after/ parameter in connect() to false: signal_button_press_event().connect(sigc::mem_fun(*this, ::draw_get_mouse), false); See https://developer.gnome.org/gtkmm-tutorial/stable/sec-xeventsignals.html.en If you want normal event processing to continue after your

Re: Cannot get button press event on drawing area

get_window()->set_events(Gdk::EventMask::BUTTON_PRESS_MASK); or    add_events(Gdk::EventMask::BUTTON_PRESS_MASK); If you want to receive button press events, then set the button press mask. If you want to receive button motion events, then set a button motion mask. It's usually better to use

Re: Cannot get button press event on drawing area

On 2019-03-01 16:58, Радомир Хаџић wrote: Also, I did try to change set_events to add_events but again, nothing changed. 2019-03-01 14:27 GMT+01:00, Радомир Хаџић : Sorry, I meant "BUTTON1_MOTION_MASK," but it doesn't really matter. Yes, it does matter. Like you say, you have

Re: Cannot get button press event on drawing area

On 2019-03-01 17:28, Kjell Ahlstedt wrote: On 2019-03-01 16:58, Радомир Хаџић wrote: Also, I did try to change set_events to add_events but again, nothing changed. 2019-03-01 14:27 GMT+01:00, Радомир Хаџић: Sorry, I meant "BUTTON1_MOTION_MASK," but it doesn't really matter. Yes, it does

Re: Unable to pass additional argument to signal handling function

If you want to pass a widget to a signal handler, I suggest you pass a widget pointer. See e.g. https://gitlab.gnome.org/GNOME/gtkmm-documentation/blob/gtkmm-3-24/examples/book/buildapp/step5/exampleapplication.cc line 46. In your case:

Re: How to use Glib::Value?

Replace    data.init(G_TYPE_DATE_TIME); by    data.init(data.value_type()); or    data.init(Glib::Value::value_type()); You don't store a GDateTime, you store a Glib::DateTime. That's not the same thing. This is not well described in the documentation, but there is an example at

Re: How to use Glib::Value?

init() is a method in Glib::ValueBase, base class of all Glib::Value<> specializations. The documentation says     init() is not implemented as constructor, to avoid the necessity     to implement a forward constructor in each derived class. There are many subclasses of Glib::ValueBase. Most of

Re: How to use Glib::Value?

Right now we're maintaining two parallel-installable versions of glibmm, the stable glibmm-2.4 ABI series with the latest release glibmm 2.58.0 (git branch glibmm-2-58), and the new and very unstable glibmm-2.60 ABI with the latest release 2.59.1 (git branch master). In the master branch we

It's time for new releases of glibmm

glib 2.60.0 has been released. Therefore it's time for new releases of glibmm and yet another new ABI name in the very unstable master branch in the git repo. This is what I'll do unless someone has a better idea: _Master branch_ New ABI name: glibmm-2.62 New unstable release: 2.61.1

Re: API-Reference is missing

On 2019-02-14 10:39, Daniel Boles via gtkmm-list wrote: Btw, if anyone in this latest thread doesn't know yet, you can substitute 3.20 into the URLs for documentation pointing at 3.22/3.24/stable and usually set something that's *almost* relevant, although 3.20 is increasingly old. Failing

Re: Setting custom Glib::Property values in Gtk::Builder .ui XML

On 6/13/19 2:41 PM, Daniel Boles via gtkmm-list wrote: > for posterity, it looks like someone else has had the same questions but didn't get much further: That user was also using wrap_register() to have code called when glibmm wraps the C instances. I know next to nothing about that - but I

Re: Setting custom Glib::Property values in Gtk::Builder .ui XML

On 6/10/19 6:50 PM, Kjell Ahlstedt wrote: On 6/10/19 10:39 AM, Daniel Boles via gtkmm-list wrote: A related question here is: How can we ensure the derived type is registered with GObject before GtkBuilder would need it? Will a simple g_type_ensure( g_type_from_name("gtkmm__Custom_Whatever") )

Re: Setting custom Glib::Property values in Gtk::Builder .ui XML

On 6/9/19 11:04 AM, Daniel Boles via gtkmm-list wrote: Short of having to write an underlying class in C, is there any way to have custom derived widgets with custom Glib::Property, and set those custom properties through a Gtk::Builder .ui? Presuming the answer is no, because the properties

Re: Setting custom Glib::Property values in Gtk::Builder .ui XML

On 6/10/19 10:25 AM, Daniel Boles via gtkmm-list wrote:  Do you think it would be possible, or worth thinking about, to add ways to do this (and probably custom signals) in C++? It would be nice if we could add properties and signals to the class without having to go into C (or rather, by

Re: Drawing a widget as a drag icon (without going down to C)

On 6/23/19 4:40 PM, Daniel Boles via gtkmm-list wrote: Yeah, it doesn't seem like it's 'protecting' anything by not being usable publicly. Can the access specifier perhaps be changed in a future stable release, or is that too much? I suppose the access specifier can be changed from

Re: Drawing a widget as a drag icon (without going down to C)

On 6/23/19 3:35 PM, Daniel Boles via gtkmm-list wrote: I have a small widget that can be a drag/drop source/sink. When it's dragged, I want it to be the drag-icon, so you can see that you're dragging that particular widget (and its particular label, etc.) However,

Re: Setting custom Glib::Property values in Gtk::Builder .ui XML

On 6/10/19 10:39 AM, Daniel Boles via gtkmm-list wrote: A related question here is: How can we ensure the derived type is registered with GObject before GtkBuilder would need it? Will a simple g_type_ensure( g_type_from_name("gtkmm__Custom_Whatever") ) work? I imagine not, as the GObject class

Building gtkmm-documentation with meson

I have added meson.build files to the master branch of gtkmm-documentation in gitlab.gnome.org. If you want to test it, please do. Read the README file for instructions. I hope meson can soon replace autotools for building gtkmm-documentation. *Question:* docs/tutorial/Makefile.am contains

Re: Getting GValue* from Glib::Value

I have fixed Glib::Checksum, DateTime and TimeZone in the master branch. These classes are now wrapped as _CLASS_BOXEDTYPE, which means they get Glib::Value specializations. I've also added TODO comments in the glibmm-2-60 branch. Hopefully, I remember to fix it there when glibmm 2.62.0 is

Shall libgdkmm-4.0 be merged with libgtkmm-4.0?

This post concerns only gtkmm-4.0, wrapping the still very unstable gtk4. Gtk4 installs only one library file and one .pc file. Bug https://bugzilla.gnome.org/show_bug.cgi?id=773100 discusses the change from three installed libraries (gdk, gsk and gtk) to one (gtk) with all code from the

Re: Setting custom Glib::Property values in Gtk::Builder .ui XML

On 6/27/19 7:00 PM, Daniel Boles via gtkmm-list wrote: That all looks incredible! Thanks so much for putting all that work in - hugely appreciated. Does "Using derived widgets" in the doc book need updated here too? I didn't see it being amended. Right now it says: Yes, the "Using derived

Re: Setting custom Glib::Property values in Gtk::Builder .ui XML

On 6/15/19 11:57 AM, Daniel Boles via gtkmm-list wrote: Thanks for testing it anyway! I wondered also if one could register properties in ExtraClassInit, but delay applying until them wrapping with wrap_new()*, i.e. have C++ actually reflect whatever values were set... but that seems like it

Re: Getting GValue* from Glib::Value

What's wrong with Glib::ValueBase::gobj()? It returns a pointer to gobject_. What else do you want? How should your proposed Glib::ValueBase::get_gvalue() differ from Glib::ValueBase::gobj()? On 2019-04-23 06:14, Pavlo Solntsev via gtkmm-list wrote: Hi, I have Glib::Value data;

Re: Getting GValue* from Glib::Value

Don't change GDateTime in glib because of Glib::Value<>. Many boxed types get Glib::Value specializations almost automatically. Those that are wrapped as _CLASS_OPAQUE_COPYABLE don't. GDateTime is one of them. I'll either add the Glib::Value specialization manually to glibmm/datetime.h or

Re: Getting GValue* from Glib::Value

The description of Glib::ValueBase says  * Glib::Value<> is specialized for almost any type used within the glibmm and gtkmm libraries.  *  * - Basic types like int, char, bool, etc., also void*.  * - Glib::ustring and std::string.  * - Pointers to classes derived from Glib::Object.  * -

Re: Additional Glib::RefPtr Safety Mechanism

Den 2019-08-30 kl. 11:29, skrev Jonathan Wakely via gtkmm-list: On Thu, 29 Aug 2019 at 21:27, Karsten Pedersen > wrote: Hi all, One area of C++ that always frustrates me is safety. Smart pointers such as the Glib::RefPtr go a good way to avoid dangling

Build C++ binding modules with Meson

Many Gnome modules have been converted to using Meson instead of Autotools. The C++ bindings, glibmm, gtkmm etc, are not yet among the converted modules. (gtkmm-documentation and mm-common can be built with Meson, but they are not C++ bindings.) Now I have uploaded a proposal, showing how

Re: Trapping Glib critical error messages

Or, in gdb: break g_log Den 2019-08-08 kl. 00:58, skrev Daniel Boles via gtkmm-list: run with G_DEBUG=fatal-criticals or -warnings or etc to taste On Wed, 7 Aug 2019, 23:50 Phil Wolff via gtkmm-list, mailto:gtkmm-list@gnome.org>> wrote: GLib-GObject-CRITICAL **: 15:30:09.453:

Re: building pangomm

Oops, my fault! The meson.build files were copied from the master branch, but two of them had not been enough modified to fit pangomm-1.4. I have fixed it in the git repo now. Kjell Den 2019-11-08 kl. 16:26, skrev Pavlo Solntsev via gtkmm-list: Hi, I am not sure if this post should go here

"Weird versions and unclear branching " in the *mm modules

Our parallel development of two sequences of each module is a nuisance to some people. No wonder. But I suppose there's not much we can do about it now. Just hope that gtk4 will stabilize soon. https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests/435#note_636748

Re: custom TreeModel

Your custom TreeModel can perhaps be added either to the gtkmm demo programs or to the gtkmm tutorial at https://gitlab.gnome.org/GNOME/gtkmm-documentation. Let's decide when you have a working program. Have you noticed that there is a custom TreeModel example at

Re: custom TreeModel

Have you declared your custom TreeModel something like class MyTreeModel : public Glib::Object, public Gtk::TreeModel That's wrong. Glib::Object must be declared after the base interface(s): class MyTreeModel : public Gtk::TreeModel, public Glib::Object This restriction was introduced about 5

Re: Make `Widget.get_style_context() const` return a `StyleContext const`?

It looks like a mistake. I've changed it in the master branch (gtkmm4). I guess we have to live with it in gtkmm3. The same change there would break API. Perhaps also ABI, but I'm not sure. Kjell On 2019-12-10 16:05, Daniel Boles via gtkmm-list wrote: I suspect this might have been asked and

Re: What shall be the version number of the next mm-common release?

for the upcoming version. All unstable version will be incremented using the second and the third number. Thanks. On Sat, 2019-10-26 at 15:37 +0200, Kjell Ahlstedt via gtkmm-list wrote: mm-common in the git repo now supports Meson in several ways. mm-common itself can be built with Meson. It supports other

Re: gtk-demo and "foreigndrawing"

The programs under demos/ and tests/ are built when you run "make check". gtkmm/demos/gtk-demo builds and functions, but it does not include as many demos as gtk+/demos/gtk-demo. Kjell Ahlstedt Den 2019-10-23 kl. 23:25, skrev Hans L via gtkmm-list: I've attempted to build gtkmm (3.22.3)

What shall be the version number of the next mm-common release?

mm-common in the git repo now supports Meson in several ways. * mm-common itself can be built with Meson. * It supports other modules that are built with Meson (so far only pangomm's master branch). * The skeletonmm directory shows the start of a module which will be built with Meson.

Re: custom TreeModel

An alternative would be to add this in a new gtkmm-documentation/examples/book/custom/custom_treemodel directory in the gtkmm tutorial. And a description in a new section in the /Custom Widgets/ chapter (which should then be renamed). Isn't this kind of custom class that implements one or

Re: goocanvasmm and gtkmm4

Anything that works with gtkmm3 will not work with gtkmm4. I don't know much about goocanvasmm. I just looked at the configure.ac files in GitLab's repo. I can see that a goovanvasmm-3, meant to work with gtkmm4, has been started in the master branch. But it has not been updated for a long

Re: how to get key press event in goocanvasmm

I don't know anything about goocanvasmm, but I know a lot about gtkmm and glibmm. As far as I can see your on_key_press_event() should be called, provided that m_canvas has the keyboard focus. If a child of m_canvas has the keyboard focus, on_key_press_event() should be called if the child

gtk4 and gtkmm-4.0

There are two parallel-installable series of libsigc++, cairomm, glibmm, pangomm, atkmm and gtkmm, one stable, the other extremely unstable. This situation has been going on for a couple of years. It has now and then resulted in Bugzilla bugs and GitLab issues from people who have tried to use

Re: Where to free dynamic allocated widgets, generated within signal handlers

I think https://gitlab.gnome.org/GNOME/gtkmm-documentation/blob/gtkmm-3-24/examples/book/application/command_line_handling/exampleapplication.cc contains a solution to your problem. See ExampleApplication::create_window() and ExampleApplication::on_window_hide(). Kjell On 2020-01-04 00:43,

Re: Where to free dynamic allocated widgets, generated within signal handlers

On 2020-01-04 12:14, Klaus wrote: Am 04.01.20 um 11:55 schrieb Kjell Ahlstedt: I think https://gitlab.gnome.org/GNOME/gtkmm-documentation/blob/gtkmm-3-24/examples/book/application/command_line_handling/exampleapplication.cc contains a solution to your problem. See

Re: custom TreeModel

I have filed https://gitlab.gnome.org/GNOME/gtkmm-documentation/issues/9 On 2019-12-27 14:41, danny wrote: hi, on one hand I genuinely feel that there is a real use case for this: imagine a library that you've written, and you want to show its results in a gtk treeview, but straight from

Re: Meson and Autotools, or only Meson?

On 2020-03-26 11:01, Murray Cumming wrote: On Thu, 2020-03-26 at 09:42 +0100, Kjell Ahlstedt wrote: 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

Re: Trying (and installing) gtk4mm (3.97) ...?

On 2020-04-20 15:54, Martin Brodbeck via gtkmm-list wrote: Hi, (I hope this is the right place to ask...) I'm on Arch Linux and just wanted to get acquainted to (early) gtkmm4. Unfortunately, there are no pre-release packages (like 3.97.1) in AUR yet. I might be able to build them, but some

Re: mmification of gspell

On 2020-04-16 09:19, Daniel Boles via gtkmm-list wrote: On Thu, 16 Apr 2020, 04:18 Pavlo Solntsev via gtkmm-list, mailto:gtkmm-list@gnome.org>> wrote: Check this project https://gitlab.com/mnauw/cppgir Wow, so someone is trying it, great! Thanks. The lack of constness and limitations

***UNCHECKED*** Meson and Autotools, or only Meson?

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

Re: mm-common and mm-common-get

mm-common-get is new in mm-common 1.0.0, released 2019-10-29. Which version of mm-common have you got? On 2020-03-26 19:35, Pavlo Solntsev via gtkmm-list wrote: Hi, Working on meson, I found that mm-common-get is not available in

Re: Determining widget type

On 2020-03-27 16:54, Phil Wolff via gtkmm-list wrote: I want to modify the primary message widget so I can select and copy the text.     Gtk::Box* pBox = pDialog->get_content_area ();     std::vector v = pBox->get_children ();     Glib::ustring str = ((Gtk::Label*)v[0])->get_label (); This

Re: Why cursor keys are not longer reported in key press events

On 2020-03-27 17:03, Klaus wrote: Some research later: Seems that build in event handler of Gtk::Window has changed behavior. class MyWin: public Gtk::Window {     bool on_key_press_event( GdkEventKey* event ) override     {     std::cout << "KeyPressEvent" << std::endl;     bool

Re: Why cursor keys are not longer reported in key press events

On 2020-03-28 21:52, Klaus wrote: This is normal behavior for event signals. The default handler can stop further processing by returning true. It's described e.g. at https://developer.gnome.org/gtkmm-tutorial/stable/sec-xeventsignals.html.en

Re: Meson and Autotools, or only Meson?

On 2020-03-26 03:06, Pavlo Solntsev wrote: 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

Re: Meson and Autotools, or only Meson?

On 2020-03-26 09:06, Murray Cumming wrote: 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

Re: Meson and Autotools, or only Meson?

On 2020-03-26 11:01, Murray Cumming wrote: 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.

Re: Meson and Autotools, or only Meson?

On 2020-03-26 10:10, Tom Schoonjans via gtkmm-list wrote: Will cairomm also be getting meson as buildsystem? Probably and hopefully, but I don't know when it will happen. Cairomm, atkmm and gtkmm should also get Meson support. ___ gtkmm-list

Re: Cannot `dynamic_cast` custom wrapped widget from Gtk::Builder

On 2020-05-01 23:28, Josh Bialkowski via gtkmm-list wrote: ~~~ class PanZoomArea : public Gtk::DrawingArea {   _CLASS_GOBJECT(PanZoomArea, GtkPanZoomArea, GTK_PANZOOM_AREA,                  Gtk::DrawingArea, GtkDrawingArea); ~~~ You must use _CLASS_GTKOBJECT() instead of _CLASS_GOBJECT() for

Re: Cannot `dynamic_cast` custom wrapped widget from Gtk::Builder

On 2020-05-03 20:12, Josh Bialkowski wrote: Ok, I think I figured it out the m4 include path issue for gmmproc, but I still can't load the widget from GtkBuilder even when using `_CLASS_GTKOBJECT`. I think that with two `-I` in the command line, one must be overriding the other. The following

Re: Cannot `dynamic_cast` custom wrapped widget from Gtk::Builder

On 2020-05-04 23:45, Josh Bialkowski wrote: > You said in a previous post that you execute... Well... this is executed inside the generated `wrap_init()` which is part of the `Gtk::` namespace (in hindsight, a bad idea) and apparently this function is not getting called. If I call it

Re: mmification of gspell

On 2020-04-15 01:51, Emmanuel Gil Peyrot wrote: Hi, In Inkscape[1] I’ve been trying to replace[2] both GtkSpell and aspell with gspell[3], but I couldn’t find any gspellmm library. I’ve been looking through your mm libraries to see how to generate it, but it seems you write almost all of the

Re: Meson and Autotools, or only Meson?

On 2020-03-26 16:03, Kjell Ahlstedt wrote: On 2020-03-26 10:10, Tom Schoonjans via gtkmm-list wrote: Will cairomm also be getting meson as buildsystem? Probably and hopefully, but I don't know when it will happen. Cairomm, atkmm and gtkmm should also get Meson support. Cairomm and atkmm and

Re: Cannot `dynamic_cast` custom wrapped widget from Gtk::Builder

I don't understand why panzoomarea.h (and I suppose also panzoomarea.cc) is broken. Don't you get any kind of warning or error message? Probably your gmmproc-command can be made much shorter: /usr/lib/x86_64-linux-gnu/glibmm-2.4/proc/gmmproc -I /usr/lib/x86_64-linux-gnu/gtkmm-3.0/proc/m4

Re: Enable / disable a Gio::SimpleAction.

Have you seen the gtkmm tutorial? https://developer.gnome.org/gtkmm-tutorial/3.24/gtkmm-tutorial.html One of the examples in the /Menus and Toolbars/ chapter has a menu with radio items. There is also a menu demo among the gtkmm demo programs.

Re: Enable / disable a Gio::SimpleAction.

On 2020-10-05 17:07, Kjell Ahlstedt wrote: Gio::SimpleActionGroup belongs to glibmm, not to gtkmm. Both gtkmm 2.x and gtkmm 3.x use glibmm versions from the glibmm-2.4 ABI series. I don't understand how you can do what you say you do in gtkmm 2.x. Haven't you used Gtk::ActionGroup and

Re: Enable / disable a Gio::SimpleAction.

On 2020-10-07 22:04, Carlo Wood wrote: When I put that string in an XML file "example.glade" and try to read it, glade gives the error: example.glade targets Gtk+ 2.12 But this version of Glade is for GTK+ 3 only. Make sure you can run this project with Glade 3.8 with no

Re: Enable / disable a Gio::SimpleAction.

Gio::SimpleActionGroup belongs to glibmm, not to gtkmm. Both gtkmm 2.x and gtkmm 3.x use glibmm versions from the glibmm-2.4 ABI series. I don't understand how you can do what you say you do in gtkmm 2.x. Haven't you used Gtk::ActionGroup and Gtk::Action?  Something like     Glib::RefPtr

Re: Help on Gtk::Layout and Gtk::ScrolledWindow

On 2020-08-22 15:53, josephenry via gtkmm-list wrote: Hi, I am learning Gtk+ with gtkmm and my goal is to create a node based interface for visual programming. I started a thread on the Gnome discourse : https://discourse.gnome.org/t/project-guidance-node-based-ui/

Re: Parsing custom-typed properties from Glade file

Is Type a custom enum? I have never tried to use such an enum in a glade file, but I looked at what gtk does. Their enums are registered with g_enum_register_static(). Each enum value is specified with a GEnumValue, which contains a nickname. The nickname is used in glade files. Example:

Re: Please help

There are lots of working example programs at https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/gtkmm-3-24/examples See e.g. https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/gtkmm-3-24/examples/book/menus/main_menu and

Re: Clock widget not showing when put in Gtk::Grid.

I printed the width and height values in Clock::on_draw(). With the original code: width=200, height=200 After adding a Grid, like you've done: width=1, height=1 After I also added    c.set_hexpand();    c.set_vexpand(); in main.cc: width=200, height=200 On 2020-08-05 20:55, Carlo Wood wrote:

Re: Documentation for gstreamermm?

The documentation for gstreamermm 1.10.0 was created with doxygen 1.8.13, for gstreamermm 1.8.0 with doxygen 1.8.12, for gstreamermm 1.4.3 with doxygen 1.8.6. (I checked the tarballs at https://download.gnome.org/sources/gstreamermm/. Doxygen writes its version in every generated html file.)

Re: FlowBox::get_child_at_pos() seems missing

I have created https://gitlab.gnome.org/GNOME/gtkmm/-/issues/74 On 2020-06-06 13:14, Daniel Boles via gtkmm-list wrote: Please check if it was already requested at the GNOME GitLab for gtkmm, and if not please create a new Issue doing so. ___

Re: Using Gtk::Builder with a doubly-derived widget

A subject line would be fine. Do you intend to create a GtimerController widget from the gtimer.glade file? Something like    GtimerController *gtimer = nullptr;    refFileBuilder->get_widget_derived("m_main_window", gtimer); I would try GtimerController::GtimerController(BaseObjectType*

Re: Update data in Gtk::ListStore

On 2020-06-07 05:43, Liomar da Hora via gtkmm-list wrote: Hello, How do I update a given ListStore data? According to the example in the book, I can add rows of data, but I haven't found a way to update a specific data. See the treeview/editable_cells example at

Re: How to initialize gtkmm without Gtk::Application?

Most of Gtk::Main is deprecated. Gtk::Main::init_gtkmm_internals() is an exception. It's not deprecated in gtkmm3. In gtkmm4 (still very unstable) Gtk::Main has been removed. Gtk::Main::init_gtkmm_internals()is still available, but it's called Gtk::init_gtkmm_internals(). On 2020-07-23

Re: Please help (core dump)

On 2020-07-25 17:35, Carlo Wood wrote: Why would this core dump?? LinuxChessboardWidget is defined as: class LinuxChessboardWidget : public cwmm::ChessPositionWidget, public Gio::ActionMap { ... I have to derive from Gio::ActionMap because its constructor is protected. The call to

Re: Merging UI strings into Gtk::Builder?

I made some tests with the menus_and_toolbars example in gtkmm-documentation. Something like this will probably work: Glib::ustring ui_info = "" " " "" ... "" " " ""; Glib::ustring ui_info2 = "" " " "" ... "" " " "";

Re: Please help (core dump)

On 2020-07-27 09:40, Carlo Wood wrote: Is there an example somewhere that shows how I can combine the `void on_menu_mode_*()` member functions of a widget that is not derived (indirectly) from Gio::ActionMap to the menu of the window that this widgets belongs to? Thanks, Carlo Wood Look at

Re: First stable version of gtkmm-4.0 has been released

On 2020-12-29 11:42, Alexander Borro wrote: Thank you for all the great work . I managed to build successfully from tarballs on Fedora 33. I observed one issue however. gtkmm4 compilation failed because valkan/vulkan.h was missing. I then installed vulkan-loader-devel and all completed. I

Re: Failure to add radio buttons to popup menu.

I combined ideas from the book/menus/main_menu and book/menus/popup examples in gtkmm-documentation. Then it works. See attached files. On 2020-12-04 16:51, Carlo Wood wrote: Hi Kjell, I've been trying for days to get radio buttons working in my popup menu. I can't get closer than "it doesn't

Re: Failure to add radio buttons to popup menu.

On 2020-12-08 16:25, Carlo Wood wrote: On Tue, 8 Dec 2020 08:41:58 +0100 Kjell Ahlstedt wrote: I don't know if it works with a file that glade has written. That sounds like you don't support glade. I am confused, because I thought that glade was the defacto standard that Gnome wants users to

Re: Failure to add radio buttons to popup menu.

I don't know if it works with a file that glade has written. Can't glade write files without GtkMenu, GtkRadioMenuItem, etc? If it can't, it's not compatible with gtk4 and gtkmm4, at least not when it comes to creating menus. Classes like GtkMenuBar, GtkMenu, GtkMenuItem, GtkRadioMenuItem have

Re: Segfault on Gtk::ListStore::clear ()

I added some code to one of the example programs in gtkmm-tutorial, https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/gtkmm-3-24/examples/book/combobox/complex ExampleWindow::~ExampleWindow() {   Gtk::TreeIter iList = m_refTreeModel->get_iter("0");   while (iList)   {     std::cout <<

Re: First stable version of gtkmm-4.0 has been released

The dead link has been removed in the git repo. I've also made other updates in the description of jhbuild. These corrections will show up at https://developer.gnome.org/gtkmm-tutorial/4.0/ after the next release of gtkmm-documentation. Don't know when that will be. On 2020-12-21 21:42,

First stable version of gtkmm-4.0 has been released

After several years of being in an unusually unstable state, gtkmm-4.0 and gtk4 have now stabilized. Application programmers can build them from tarballs or from git clones. I assume that they will be available in Linux distributions in due time. gtkmm-4.0 depends on new releases of several

  1   2   >