Re: Question about GdkEventButton in gtkmm-4.0

[Kjell Ahlstedt via gtkmm-list]

Use Gtk::GestureClick. Some examples:
https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/blob/master/examples/book/menus/popup/examplewindow.cc
https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/blob/master/examples/book/popover/examplewindow.cc

In most (perhaps all) situations where event signals have been used in 
gtkmm3, use one of the many subclasses of Gtk::EventController.

https://gnome.pages.gitlab.gnome.org/gtkmm/classGtk_1_1EventController.html

Den 2022-10-06 kl. 23:57, skrev Aaron Scheinberg via gtkmm-list:

Hello,

I hope this is the right place for this, sorry if not!

I'm trying to implement an example gtkmm 3.0 code in gtkmm 4.0 and ran 
into a problem. The goal is to get the cursor's coordinates and what 
type of click occurred when clicking on a button. In gtkmm 3.0, I 
could use|GdkEventButton|, as in this example from thedocs 
:


|bool on_button_press(GdkEventButton* event); Gtk::Button 
button("label"); button.signal_button_press_event().connect( 
sigc::ptr_fun(_button_press) ); |


But |GdkEventButton| seems to no longer exist or no longer be 
accessible in gtkmm 4.0.


There is a reference to GdkEvent API changes in the migration 
documentation , but I 
still do not understand how to migrate that example code. Is anyone 
more familiar or has any sort of related example?


I've also posted this on stack overflow: 
https://stackoverflow.com/questions/73979631/gdkeventbutton-when-migrating-from-gtkmm-3-0-to-gtkmm-4-0


Thanks for your help,
Aaron

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Add Gtk::TextView to Gtk::Grid

[Kjell Ahlstedt via gtkmm-list]

set_child(m_grid); shows that this is gtkmm4.

I made some tests with the TextView example in gtkmm-documentation,

https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/master/examples/book/textview

1. Replaced Gtk::Box m_VBox; by Gtk::Grid m_grid; The TextView is a 
child of a ScrolledWindow, which is a child of the Grid, which is the 
child of the window.

The text in the TextView was shown.

2. Removed the ScrolledWindow.
The TextView was not shown. Or, rather, it was minimized.

3. Added m_TextView.set_expand();
The TextView was shown again.

Den 2022-10-06 kl. 13:00, skrev Rodolfo Ribeiro Gomes:

If you are gtkmm3, widgets are hidden by default.
You should call Gtk::Container::show_all_children() or 
Gtk::Widget::show_all().


AFAIK, in gtkmm4 this isn't necessary anymore, as widgets are 
(finally) visible by default.


Em qui., 6 de out. de 2022 às 07:33, Bill Greene via gtkmm-list 
 escreveu:


Thanks for taking a look at this.

Unfortunately, even after I make the TextView   a class member, I
still don't see the text displayed in the window.
A concise description of the problem is this:
If I make the TextView a child of the window, the text is
displayed. If I make the TextView a child of a Grid, and the
Grid a child of the window, the text is not displayed.

I am assuming there might be some property of the Grid I need to set?

On Wed, Oct 5, 2022 at 12:40 PM Kjell Ahlstedt
 wrote:

You have declared the TextView  as a local variable in the
constructor.
It will be deleted when the constructor finishes. You must either
declared it in your window class, like the buttons in


https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/blob/master/examples/book/grid/examplewindow.h

or create it with Gtk::make_managed() in the constructor, like
the button in


https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/blob/master/examples/book/scrolledwindow/examplewindow.cc

Den 2022-10-05 kl. 17:00, skrev Bill Greene via gtkmm-list:
> I am trying to add a TextView instance to a Grid. But when I
display
> the window, it is
> empty. The Grid examples I have seen add buttons to the grid
and these
> work fine
> for me. But I don't understand the difference between adding
a button
> and adding
> a TextView. If anyone can help me with this, I
would appreciate it.
>
> Here is my sample code (part of the constructor for my window):
>
>   set_child(m_grid);
>   Gtk::TextView tc;
>   Glib::RefPtr tb = Gtk::TextBuffer::create();
>   std::string msg("cell 1,1");
>   auto it = tb->insert(tb->begin(), msg);
>   tc.set_buffer(tb);
>   m_grid.attach(tc, 0, 0);
>   m_grid.set_visible();
>

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Add Gtk::TextView to Gtk::Grid

[Kjell Ahlstedt via gtkmm-list]

You have declared the TextView  as a local variable in the constructor. 
It will be deleted when the constructor finishes. You must either 
declared it in your window class, like the buttons in


https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/blob/master/examples/book/grid/examplewindow.h

or create it with Gtk::make_managed() in the constructor, like the button in

https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/blob/master/examples/book/scrolledwindow/examplewindow.cc

Den 2022-10-05 kl. 17:00, skrev Bill Greene via gtkmm-list:
I am trying to add a TextView instance to a Grid. But when I display 
the window, it is
empty. The Grid examples I have seen add buttons to the grid and these 
work fine
for me. But I don't understand the difference between adding a button 
and adding

a TextView. If anyone can help me with this, I would appreciate it.

Here is my sample code (part of the constructor for my window):

  set_child(m_grid);
  Gtk::TextView tc;
  Glib::RefPtr tb = Gtk::TextBuffer::create();
  std::string msg("cell 1,1");
  auto it = tb->insert(tb->begin(), msg);
  tc.set_buffer(tb);
  m_grid.attach(tc, 0, 0);
  m_grid.set_visible();



___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Builder derived widgets with properties -- error validate_and_install_class_property: assertion 'class->set_property != NULL' failed

[Kjell Ahlstedt via gtkmm-list]

Den 2022-08-29 kl. 23:37, skrev Dan Lo Forte:


I have a glade file from which I load a derived widget that has a 
Glib::Property.  When I load the main window, I get the following error:


```

GLib-GObject-CRITICAL **: validate_and_install_class_property: 
assertion 'class->set_property != NULL' failed


```

I have created a simplified example, as per this page: 
https://developer-old.gnome.org/gtkmm-tutorial/stable/sec-builder-using-derived-widgets.html.en, 
using a derived Gtk::Button and still see the error.



Your simplified example is very similar to the example at 
https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/gtkmm-3-24/examples/book/builder/derived, 
which does not print an error message. There is a significant difference 
in the glade file (glade_str). You shall change GtkButton to 
gtkmm__CustomObject_DerivedButtonProp, the Gtype name of your button class.

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtk webview wrong rendering on load and small artifact

[Kjell Ahlstedt via gtkmm-list]

Den 2022-08-04 kl. 22:47, skrev Michael Nazzareno Trimarchi:

Did you get this strange resize effect? Seems the window is resized
and the webview part resizes later, so it's totally not fluent. Anyway
the idea behind the project
is to create a way to interact with alexa stack using webkit and gtkmm
and websocket.

Michael

Yes, I can see that the bbbc2f4dd0a9586f053308ab9a1a.png figure is 
clipped on its sides until the window is resized. I haven't yet been 
able to find out which part of the program draws this figure. I suspect 
that it's the main.bundle.js Javascript. If this can be a bug in a 
Javascript, I can't help you.


Kjell
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtk webview wrong rendering on load and small artifact

[Kjell Ahlstedt via gtkmm-list]

Den 2022-08-04 kl. 16:13, skrev Michael Nazzareno Trimarchi:

Are you building with gnome-builder?

Michael

No, I'm building as described in README.md. But I had defined the 
environment variable GSETTINGS_SCHEMA_DIR. It's needed be other programs 
that I run now and then. In this case, it was a mistake. When I unset 
GSETTINGS_SCHEMA_DIR, ./src/alexa started.


Now the output is

Connection from WebPage
Connect to Alexa
Error: The server did not accept the WebSocket handshake.

I don't get the warning about /called gtk_widget_queue_resize() during 
size_allocate()/ when I resize the window. Nothing seems to disappear 
from the window. What's the artifact you're talking about? Is it the 
blue circle before the text "amazon alexa"?


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtk webview wrong rendering on load and small artifact

[Kjell Ahlstedt via gtkmm-list]

Den 2022-08-03 kl. 12:07, skrev Michael Nazzareno Trimarchi via gtkmm-list:

Hi

On Wed, Aug 3, 2022 at 11:55 AM Michael Nazzareno Trimarchi
 wrote:

Hi

I have created a simple example using gtkmm and webkit here:

https://github.com/panicking/gtkmm_alexa

I downloaded your example and managed to build it. When I execute it, I 
get the error


(alexa:7545): GLib-GIO-ERROR **: 15:36:51.296: Settings schema 
'org.amarula.alexa' is not installed


How do I install the schema? I'm not very familiar with CMake.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Unparenting from GtkWidget "destroy"

[Kjell Ahlstedt via gtkmm-list]

Den 2022-08-01 kl. 18:01, skrev Baldvin Kovacs:


1. 
https://developer-old.gnome.org/gtkmm-tutorial/stable/chapter-customwidgets.html.en
developer-old.gnome.org is not updated any more. The latest version of 
the gtkmm tutorial is stored at 
https://gnome.pages.gitlab.gnome.org/gtkmm-documentation.


I'm not super happy with it though. Trusting users to unparent from 
both places without the framework enforcing or at least verifying it 
is problematic.
Writing custom container widgets, derived directly from Gtk::Widget, was 
more difficult in gtkmm3 than it is in gtkmm4. I think very few gtkmm 
users ever did it. And like you say, it's far from perfect in gtkmm4.___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Unparenting from GtkWidget "destroy"

[Kjell Ahlstedt via gtkmm-list]

Den 2022-07-31 kl. 00:37, skrev Baldvin Kovacs:
I took a stab at it, PTAL. Another option is to not do this, but 
document in both the howtos, and the documentation

of Gtk::Widget that container-like custom widgets are not supported.

Thx,
Baldvin


I have updated the custom container example in the gtkmm tutorial, 
https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/master/examples/book/custom/custom_container. 
Now it's more like a simplified vertical Box. It works well, except if 
it's a managed widget. I've noted this restriction in a comment in the 
source code. If you think it's too complicated the explain how to use a 
signal_destroy(), we can leave it at that for the moment.


Kjell
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Unparenting from GtkWidget "destroy"

[Kjell Ahlstedt via gtkmm-list]

Den 2022-07-30 kl. 11:46, skrev Kjell Ahlstedt:

Den 2022-07-10 kl. 13:28, skrev Baldvin Kovacs:


I'll send a merge request with exposing signal_destroy, and another 
small one to the documentation, to the custom widget section.


Baldvin

What has happened with the merge requests? I can easily add 
_WRAP_SIGNAL(void destroy(), "destroy") myself,



I mean _WRAP_SIGNAL(void destroy(), "destroy", no_default_handler)


but it needs a good documentation. Otherwise it will be more confusing 
than helpful to most users of gtkmm.


Kjell
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Unparenting from GtkWidget "destroy"

[Kjell Ahlstedt via gtkmm-list]

Den 2022-07-10 kl. 13:28, skrev Baldvin Kovacs:


I'll send a merge request with exposing signal_destroy, and another 
small one to the documentation, to the custom widget section.


Baldvin


What has happened with the merge requests? I can easily add 
_WRAP_SIGNAL(void destroy(), "destroy") myself, but it needs a good 
documentation. Otherwise it will be more confusing than helpful to most 
users of gtkmm.


Kjell
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: [gtkmm4] Help on DrawingArea plus Mouse Activity

[Kjell Ahlstedt via gtkmm-list]

Den 2022-07-09 kl. 20:02, skrev Mj Mendoza IV via gtkmm-list:


I've tried the Cairo-based Clock demo, and adjusted my code to reflect 
needed changes to port to gtkmm4.  Now, I'm currently missing mouse 
activities.


In addition to what Andrew Potter suggested, if you want to track all 
mouse movements, use Gtk::EventControllerMotion.


Just about everything that was done in event signal handlers in gtkmm3 
is now done with the many subclasses of Gtk::EventController.




I've read the gtkmm4 changes section 
 
of the tutorial 
(https://developer-old.gnome.org/gtkmm-tutorial/unstable/gtkmm-tutorial.html#changes-gtkmm4) 
but content is more of a note than actual information for beginner 
porters like me.


I don't think anyone will ever take the time to write a real migration 
guide from gtkmm3 to gtkmm4.


The documentation at developer-old.gnome.org is not updated any more. If 
you want to see the latest version of the gtkmm4 tutorial, look at 
https://gnome.pages.gitlab.gnome.org/gtkmm-documentation.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Unparenting from GtkWidget "destroy"

[Kjell Ahlstedt via gtkmm-list]

Den 2022-07-09 kl. 18:50, skrev Andrew Potter via gtkmm-list:
Beyond exposing the destroy signal, another approach might be adding a 
virtual dispose method if there is some known problem with sigc++ at 
this point in the object lifecycle.

Adding a virtual method to an existing class breaks ABI. It won't be done.


Maybe Kjell knows there is a good reason to not expose signal destroy 
/ dispose in gtkmm? If so you'd have to settle for subclassing a 
container, but otherwise I'd prefer all signals to be available.


No, I don't know why the destroy signal is not exposed in gtkmm. 
Probably no one thought it would be useful. Even confusing to most 
users? It's not explicitly ignored, probably because no one has been 
sure it's useless. And now it seems it is useful, even necessary, to 
some users.


I don't mind adding Gtk::Widget::signal_destroy() to gtkmm4. I'd prefer 
a merge request, If you, Baldvin, have write permission to gitlab you 
can even add it yourself. Adding a _WRAP_SIGNAL is trivial, but it needs 
a better description than the one that will be inherited from gtk.


Is this an issue mostly for people who write widgets intended for others 
to use in their applications? I suppose that people writing application 
programs wouldn't mind using boxes, grids and other container widgets.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

A possible future of the www.gtkmm.org website

[Kjell Ahlstedt via gtkmm-list]

There was a discussion about the www.gtkmm.org website in January. For 
instance

https://mail.gnome.org/archives/gtkmm-list/2022-January/msg7.html

There is now a Gnome issue at 
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/848 
about the gtkmm.org domain. Perhaps it will be possible to transfer 
ownership of the gtkmm.org domain to the Gnome Infrastructure team and 
have it automatically updated when the source code at 
https://gitlab.gnome.org/GNOME/gnomemm-website is updated.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: With set_event_compression, most recent motion event is held in waiting

[Kjell Ahlstedt via gtkmm-list]

Den 2022-05-26 kl. 14:07, skrev JLM via gtkmm-list:

Thanks for looking at this. I guess from what you say, you do not see
the problem. I understand, as I think it would become pretty obvious to
anyone for example running GIMP. So even if this isn't a problem
specific to my program, it may at least be a problem specific to my
environment.
But I do see the problem that you described. With event compression 
turned off, the last motion event is kept hidden somewhere in GTK until 
a key or a mouse button is clicked. I made the changes in gdkevents.c in 
order to find out if the missing motion event is held in GTK itself or 
in one of its dependencies.

I have written a bug report on GTK+ for now


https://gitlab.gnome.org/GNOME/gtk/-/issues/4946


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: With set_event_compression, most recent motion event is held in waiting

[Kjell Ahlstedt via gtkmm-list]

I made a few changes in gtk/gdk/gdkevents.c, 
_gdk_event_queue_handle_motion_compression(). 
gdk_frame_clock_request_phase (clock, 
GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS) at the end of the function is always 
called. Without event compression I get an output such as


276 motion 122.582:89.4453
277 motion 123.582:88.4453
278 motion 124.582:88.4453
279 motion 124.582:87.4453

Then when I press a mouse button:

(example:17002): Gdk-CRITICAL **: 19:11:02.499: 
gdk_window_get_frame_clock: assertion 'GDK_IS_WINDOW (window)' failed

280 button pressed 124.582:87.4453

(example:17002): Gdk-CRITICAL **: 19:11:02.587: 
gdk_window_get_frame_clock: assertion 'GDK_IS_WINDOW (window)' failed

281 button released 124.582:87.4453

The same coordinates as in the last motion event. No motion event when 
the mouse button is pressed.


The critical messages show that my changes of 
_gdk_event_queue_handle_motion_compression() is not the right solution, 
but the behavior shows (I believe) that the last motion event before the 
mouse click is available somewhere in GTK before the mouse is clicked.


Den 2022-05-24 kl. 03:40, skrev JLM via gtkmm-list:

I have managed to cobble together a program in C which does the same
thing and confirmed that it is not a specific GTKMM problem at least.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: With set_event_compression, most recent motion event is held in waiting

[Kjell Ahlstedt via gtkmm-list]

I thought I'd run your program and see what happens, but that's 
difficult without the drawarea.glade file.


What is it that you suspect is a bug? That you get an extra motion event 
with set_event_compression(false)? Or that you don't get it with 
set_event_compression(true)? It's hardly surprising that the number of 
motion events differ with and without event compression.


Den 2022-05-21 kl. 03:43, skrev Jason M'Sadoques via gtkmm-list:

I have a simple drawing area, and I have configured
set_event_compression(false). I am printing out motion and button
events, and I see while I move the mouse the motion events come out,
but then when I stop and press the mouse button, I get one more motion
event and then the button press event.

Now I can do this because I'm using a trackball, so it is easy to press
a button without incurring any further actual mouse motion.

When I comment out the line to set_event_compression, I do not see this
behavior. So instead when I press the mouse button, I just get a button
press, and the coordinates of that button press match exactly to the
last motion event.

I wonder if someone can either confirm it is a bug, or I really hope
that it is a problem I'm doing. I am using GTKMM 3.24.6.

Here is a simple example which I compiled with:
g++ -o drawtest $(pkg-config --cflags --libs gtkmm-3.0) drawtest.cpp
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Problem in creating a time_keeping application

[Kjell Ahlstedt via gtkmm-list]

Glib::Timer is not copyable. If your Time_Keeper class must be copyable, 
I'd suggest that you let it store a std::shared_ptr instead 
of a Glib::Timer.


Den 2022-05-22 kl. 01:20, skrev jeferson lemos via gtkmm-list:

I am having problems with as to Glib::Timer seems to be no copyable

on the code bellow

#ifndef _TIME_KEEPER_H_
#define _TIME_KEEPER_H_

#include 
#include 

class Time_Keeper
{
public:
void start_timer(){ /*timer.start();*/ };
void stop_timer(){ /*timer.stop();*/ };
void reset_timer(){ /*timer.reset();*/ };
std::string display_timer() { return "" /*( std::to_string(((int) 
(timer.elapsed()/3600)))+\

":"+std::to_string(((int) (timer.elapsed()/60)))+\
":"+std::to_string(timer.elapsed() ))*/; };
//const std::string hasheable (){ return (( const std::string) 
display_timer()); };

//Time_Keeper(){ start_time = Glib::DateTime::create_now_local(); };
//bool operator == ( Time_Keeper *t) { return t == this; };

protected:

private:
Glib::DateTime start_time;
Glib::TimeSpan elapsed_time;
//Glib::Timer timer;
};

#endif // _TIME_KEEPER_H_

if I try to uncomment the timer variable I immediately get the error
.../time_keeper/src/u-i-controller.cc:71:41: error: use of deleted 
function ‘Time_Keeper& Time_Keeper::operator=(const Time_Keeper&)’

71 |                 bind_time [position] = *time;
|                                         ^
In file included from .../time_keeper/src/u-i-controller.h:26,
from .../time_keeper/src/u-i-controller.cc:20:
.../time_keeper/src/time-keeper.h:26:7: note: ‘Time_Keeper& 
Time_Keeper::operator=(const Time_Keeper&)’ is implicitly deleted 
because the default definition would be ill-formed:


26 | class Time_Keeper
|       ^~~
.../time_keeper/src/time-keeper.h:26:7: error: use of deleted function 
‘Glib::Timer& Glib::Timer::operator=(const Glib::Timer&)’

In file included from /usr/include/glibmm-2.4/glibmm.h:158,
...
45 |   Timer& operator=(const Timer&) = delete;

It seems to be deliberately enforced for some reason, but is there 
some workaround?
I was trying to show a couple of timers on the interface, which 
requires managing objects




___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: How to use Pango::Context?

[Kjell Ahlstedt via gtkmm-list]

No, there is no bug report. I have fixed it at 
gitlab.gnome.org/GNOME/pangomm, branches pangomm-2-46, pangomm-2-48 and 
master.


It looks like this bug has existed for at least 14 years. Hasn't anyone 
used Pango::Context::get_font_map() before?


Den 2022-02-21 kl. 20:28, skrev phosit--- via gtkmm-list:

Thank you for the answer and the fix.
Is ther a bug report i can track?___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: How to use Pango::Context?

[Kjell Ahlstedt via gtkmm-list]

It's a bug in Pango::Context::get_font_map(). It should get its own 
reference to the font map, but it doesn't. Until the bug has been fixed 
in pangomm, you can add a reference yourself.


auto fontMap = context->get_font_map();
fontMap->reference();  // Temporary bug fix

Note that when you start using a fixed version of pangomm, the call to 
fontMap->reference() will cause a memory leak.


Den 2022-02-21 kl. 16:12, skrev phosit--- via gtkmm-list:

does the error occur if you do windows.reserve(2) before the
emplace_back()s?

Yes
__
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: when we can delete a class derived from Gtk::Window or others

[Kjell Ahlstedt via gtkmm-list]

Den 2022-02-18 kl. 18:55, skrev Klaus via gtkmm-list:


I tested you example and it works whenever the user closes the 
windows in the reverse

order from creation.


That it seems to work is known. The question is, is it the allowed way
to do this? If the Gtk::Window class performs more actions after hide()
and access data for the current class, the code has undefined behavior,
even if it works in the moment. I simply could not find any
documentation which gives me an idea what the window class perform on
close action.

Several of the example programs in the gtkmm tutorial delete a 
Gtk::Window in a "hide" signal handler. See e.g.

https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/blob/gtkmm-3-24/examples/book/menus/main_menu/exampleapplication.cc

https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/blob/gtkmm-3-24/examples/book/printing/advanced/printformoperation.cc

In the examples I've found, the deletion is not done by the window 
itself in an overridden default signal handler. It's done in a connected 
signal handler. I'm pretty sure it doesn't make a difference.


I would say it's safe to delete a Gtk::Window in a "hide" signal 
handler, default or connected. I ran the main_menu example with 
valgrind, both as it is on the website, and with "delete this" in an 
overridden default signal handler. valgrind did not report any illegal 
memory accesses.


Kjell

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: How to unblock bugfix, pipeline failed with unrelated error in gtk

[Kjell Ahlstedt via gtkmm-list]

Den 2022-02-16 kl. 22:25, skrev Baldvin Kovacs:


OK, so I'll wait :). Thanks!


  律

Baldvin


You don't have to wait. I've merged your merge request. Temporary 
problems with gtk don't matter.


Kjell
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: How to unblock bugfix, pipeline failed with unrelated error in gtk

[Kjell Ahlstedt via gtkmm-list]

Den 2022-02-16 kl. 15:02, skrev Baldvin Kovacs via gtkmm-list:

Hello,

I'm trying to send a merge request of a bugfix 
 in gtkmm, 
but the build pipeline fails with an unrelated error 
 in (or 
at least it seems so, the error is pasted to the bottom of this email).


What's the usual way to go about this? Should I notify owners of Gtk? 
By what channels? Or is it on me to track it down, get that fixed 
first, before I can propose my Gtkmm fix to be considered?


Thanks,
Baldvin

FAILED: subprojects/gtk/examples/application3/exampleapp3_resources.h
/usr/bin/glib-compile-resources 
../subprojects/gtk/examples/application3/exampleapp.gresource.xml 
--sourcedir ../subprojects/gtk/examples/application3/. --sourcedir 
../subprojects/gtk/examples/application3 --internal --generate 
--target subprojects/gtk/examples/application3/exampleapp3_resources.h
../subprojects/gtk/examples/application3/exampleapp.gresource.xml: 
Failed to close file descriptor for child process (Operation not 
permitted).


The latest gtkmm commits require gtk4 >=4.6.0, but that's not available 
from the distro that the CI uses.


Dependency gtk4 found: NO found 4.4.1 but need: '>= 4.6.0'

Gtk is then built as a subproject of gtkmm. The latest patch on gtk's 
main branch is used. Today gtk folks have added patches that make their 
own CI pipeline fail. For the time being, just accept that the latest 
gtk patches don't work. The gtk folks will find out, and fix it themselves.


Hopefully that latest version of some distro will soon include gtk 
4.6.0. Then it won't be built as a subproject.


Kjell
||___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Support service

[Kjell Ahlstedt via gtkmm-list]

Den 2022-02-14 kl. 20:50, skrev David Gasa i Castell via gtkmm-list:


I'd like to know, if possible, why some of my questions (and other 
users' as well), if so, are not properly answered and how to solve it.


Not enough people are working with gtkmm and the other *mm modules 
(glibmm, etc.). When I started contributing to these modules more than 
10 years ago, there were several other regular contributors. See also 
https://mail.gnome.org/archives/gtkmm-list/2021-February/msg3.html.


I did not give you a useful answer when you asked about drag in a 
Gtk::ListView, simply because I don't know how to do it. There are 
several examples with GtkListView among gtk's demo programs, but none of 
them does DnD. I suspect that it's not trivial. You can try to ask the 
GTK developers on https://discourse.gnome.org/c/platform/core. Gtkmm is 
just a C++ wrapper around most of GTK.




I should ask you to improve the support.
This is free and open software. You don't pay. No one is responsible for 
any support. Users of gtkmm can help each other. One user can answer 
another user's questions.


Is it possible to create a payment subscription quotes or on demand 
service in order to receive assistance ?


No


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Drag & Drop example code

[Kjell Ahlstedt via gtkmm-list]

Den 2022-02-09 kl. 13:51, skrev David Gasa i Castell via gtkmm-list:

Hi guys,

I'd need to understand how to use Drag & Drop facilities in Gtkmm-4.x 
to reorder GtkListItem(s) in a GtkListView.


Could you provide a simple (but complete) example code ?

Or maybe to complete the example code in 
https://github.com/GNOME/gtkmm/blob/master/demos/gtk-demo/example_listview_columnview.cc


--
David Gasa i Castell

There are drag examples in the gtkmm tutorial. None of them 
contains Gtk::ListView, though.


https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/master/examples/book/drag_and_drop
https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/master/examples/others/dnd
There is also a drag example with a TreeView, but it does not work.

The description at 
https://developer-old.gnome.org/gtkmm-tutorial/stable/chapter-draganddrop.html.en 
is not very useful. Like much of the tutorial, it has not been updated 
from gtkmm-3 to gtkmm-4. The source code is updated for gtkmm-4.


Kjell
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::ListView example request

[Kjell Ahlstedt via gtkmm-list]

Den 2022-02-03 kl. 11:28, skrev Pedro Vicente:

Hi,
In the Gtk::ListView (that should replace Gtk::TreeView) the example in
the Detailed Description is confusing to understand.
So I wanted to request an example.

Awaiting response,
Pedro Serrano


The confusing example in the Detailed Description is an excerpt from one 
of gtkmm4's demo programs. The complete source code is stored at 
https://gitlab.gnome.org/GNOME/gtkmm/-/blob/master/demos/gtk-demo/example_listview_applauncher.cc. 
It's included in every gtkmm4 tarball.


Kjell
___
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?

[Kjell Ahlstedt via gtkmm-list]

Den 2022-01-24 kl. 17:08, skrev Kjell Ahlstedt:

Den 2022-01-24 kl. 08:20, skrev Murray Cumming:

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


The custom domain instructions for gitlab.gnome.org is here:
https://gitlab.gnome.org/help/user/project/pages/custom_domains_ssl_tls_certification/index.md

I haven't yet studied it well enough to understand if it's something 
you (Murray) or I can do, or if it requires help from a Gnome GitLab 
administrator.



My understanding is that in order to redirect gtkmm.org you need
1. Access to gtkmm.org's server control panel to set up DNS records.
2. Maintainer or Owner role in the gnomemm-website GitLab project. See 
https://gitlab.gnome.org/help/user/permissions.md.
I've got Developer role. That's probably why I can't find any Settings > 
Pages menu item in the GitLab project.


I'd prefer not to get any domain ownership. I've intended for a long 
time to reduce my involvement in Gnome programming 
(https://mail.gnome.org/archives/gtkmm-list/2021-February/msg3.html). 
Sadly, no one else has entered the scene and started maintaining gtkmm 
and friends regularly.


Today I've upgraded the XML files in gnomemm-website/docs/C from 
DocBook 4.5 to 5.0. It should not affect the look of the web pages. 
There's no need to update www.gtkmm.org.


Kjell
___
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?

[Kjell Ahlstedt via gtkmm-list]

Den 2022-01-24 kl. 08:20, skrev Murray Cumming:

On Sun, 2022-01-16 at 19:18 +0100, Kjell Ahlstedt via gtkmm-list wrote:

Thewww.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


The custom domain instructions for gitlab.gnome.org is here:
https://gitlab.gnome.org/help/user/project/pages/custom_domains_ssl_tls_certification/index.md

I haven't yet studied it well enough to understand if it's something you 
(Murray) or I can do, or if it requires help from a Gnome GitLab 
administrator.


I'd prefer not to get any domain ownership. I've intended for a long 
time to reduce my involvement in Gnome programming 
(https://mail.gnome.org/archives/gtkmm-list/2021-February/msg3.html). 
Sadly, no one else has entered the scene and started maintaining gtkmm 
and friends regularly.


Today I've upgraded the XML files in gnomemm-website/docs/C from DocBook 
4.5 to 5.0. It should not affect the look of the web pages. There's no 
need to update www.gtkmm.org.


Kjell

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Does anyone know how to update the www.gtkmm.org website?

[Kjell Ahlstedt via gtkmm-list]

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: creating a Glib::OptionGroup

[Kjell Ahlstedt via gtkmm-list]

Den 2022-01-10 kl. 16:30, skrev phosit--- via gtkmm-list:

What is a god method of creating a OptionGroup?

The best option I see is to asign every member of Glib::OptionEntry and
then add it to the Glib::OptionGroup. Like so:

Glib::OptionGroup mainGroup;

Glib::OptionEntry ent;
ent.set_long_name("verbose");
ent.set_short_name('V');
ent.set_description("Set Verbosity level (0, 1, 2)");
ent.set_arg_description("LEVEL");
mainGroup.add_entry(ent, verbosityLevel);

and this for every entry.

This is to mutch code so i use the c-style. I would like  to use c++
features like std::vector and Glib::ustring instead of NULL terminated
arrays. Is ther a bether way of doing it?

No, there is no better way. There is a bunch of overloaded 
Gio::Application::add_main_option_entry() methods that take all the 
necessary parameters for creating a new Glib::OptionEntry. But there are 
no corresponding Glib::OptionGroup methods, and no Glib::OptionEntry 
constructor that takes all the necessary parameters (long_name, 
short_name, etc.).


See e.g. 
https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/blob/master/examples/book/application/command_line_handling/exampleapplication.cc


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Create C++ bindings of Advanced Gtk+ Sequencer

[Kjell Ahlstedt via gtkmm-list]

Appendix G in the gtkmm tutorial is the best description we've got.

https://developer-old.gnome.org/gtkmm-tutorial/4.0/
https://developer-old.gnome.org/gtkmm-tutorial/4.0/chapter-wrapping-c-libraries.html.en

It's not a very detailed description, I'm afraid. You probably also need 
to look at the source code of for instance glibmm or gtkmm. The tools 
that are used (gmmproc, h2def.py, etc.) are found in glibmm.


gobject-introspection is not used, probably because gmmproc and friends 
were first created before gobject-introspection existed. The C code must 
still be formatted much like it is in glib and gtk, otherwise the 
scripts that create .defs and *_docs.xml files will have problems 
interpreting the C code.


Regards
Kjell Ahlstedt

Den 2021-12-09 kl. 10:14, skrev Joël Krähemann via gtkmm-list:

hi all,

I am just curious about howto create C++ bindings of Advanced Gtk+
Sequencer. I would love to benefit from your experience.

The Advanced Gtk+ Sequencer framework has got GObject introspection
annotations. The involved libraries would be:

* libags.so
* libags_thread.so
* libags_server.so
* libags_audio.so
* libags_gui.so

https://www.nongnu.org/gsequencer/

Please tell me about the concepts of gtkmm and howto apply to Ags.

regards,
Joël

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Shall we keep supporting Autotools?

[Kjell Ahlstedt via gtkmm-list]

Glib, atk, pango and gtk4 have dropped Autotools support. They can only 
be built with Meson. Can we drop Autotools support for libsigc++, 
cairomm, glibmm, atkmm, pangomm, gtkmm, gtkmm-documentation and 
libxml++? Would anyone object?


I'm not sure about libxml++, because the underlying C library, libxml2, 
can't be built with Meson.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: SSL certificate error

[Kjell Ahlstedt via gtkmm-list]

Den 2021-10-12 kl. 16:05, skrev John Emmas:

On 12/10/2021 14:17, Kjell Ahlstedt wrote:
. If you just want to pull from gitlab.gnome.org, I suppose you can 
use https instead of ssl. In .git/config, change url = 
g...@gitlab.gnome.org:/GNOME/gtkmm to url = 
https://gitlab.gnome.org/GNOME/gtkmm.git


Thanks Kjell - https is what I'm already using. Did you mean that the 
other way around?


John

I thought you were using ssh. If you use https, the expired ssl 
certificate is perhaps on the server side, i.e. a problem at gnome.org. 
I tested by downloading a clone of gtkmm with https today. It succeeded. 
Could it have been a problem that has now been fixed?


Kjell

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: SSL certificate error

[Kjell Ahlstedt via gtkmm-list]

Den 2021-10-12 kl. 12:44, skrev John Emmas:
I haven't needed to access gnome/git repos for a while but I tried 
this morning and every repo gives me an error about an expired SSL 
certificate.  For example, here's what I see when trying to pull from 
gtkmm:-


 Fetching origin
 fatal: unable to access 'https://gitlab.gnome.org/GNOME/gtkmm/': 
SSL certificate problem: certificate has expired


I'm guessing I need to add / change something here?  But what..?

Thanks, John


I once got this email:

Hello Kjell Ahlstedt, your membership of the group gnomecvs has been 
automatically removed, due to inactivity.

For more information, please see the following email:
https://mail.gnome.org/archives/foundation-list/2014-March/msg00063.html

With cordiality,

the GNOME Accounts Team

It was a mistake. My gnome account was automatically restored after a 
short while. But you may find the link to the mailing list message 
interesting. If you just want to pull from gitlab.gnome.org, I suppose 
you can use https instead of ssl. In .git/config, change url = 
g...@gitlab.gnome.org:/GNOME/gtkmm to url = 
https://gitlab.gnome.org/GNOME/gtkmm.git Kjell


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Custom CellRendererText doesn't update cell size

[Kjell Ahlstedt via gtkmm-list]

Do you really have to override snapshot_vfunc() and call it explicitly? 
Isn't gtk's internal version good enough and called when you set 
property_text()? The CellrendererText will expand as necessary only if 
it's inserted in a container widget that allows it to expand.


On 2021-09-09 13:15, pedro.vice...@oncontrol-tech.com wrote:

Hi,
I'm trying to do a Cell Renderer that converts a std::deque into a 
string.

So I derivated the CellRendererText and override the snapshot_vfunc.
First I converted the deque to string, updated the property_text and 
called Gtk::CellRendererText::snapshot_vfunc to render the text.
On gtkmm3 it was working as intended, but on gtkmm4 it doesn't update 
the size of the cell and so the string in only partially shown.


Regards,
Pedro Serrano
___


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Deriving from interface implementation

[Kjell Ahlstedt via gtkmm-list]

Glib::ObjectBase is a virtual base class. The constructor of a virtual 
base class is called from the most derived class. When ModelImpl is the 
most derived class, its constructor calls 
Glib::ObjectBase(typeid(ModelImpl)). When Derived is the most derived 
class, Glib::ObjectBase(typeid(ModelImpl)) is not called. Instead 
ObjectBase's default constructor is called from Derived's constructor. 
That's not what you want in this case. You must call the right 
ObjectBase constructor from Derived's constructor, like


class Derived: public ModelImpl
{
    Derived()
    : Glib::ObjectBase(typeid(Derived)),
  ModelImpl() {}
};

Den 2021-08-04 kl. 12:15, skrev Sergey Smirnykh via gtkmm-list:

Hello!

I've run into the issue I can't resolve on my own. I have
a Gio::ListModel implementation and a (C++) class derived
from said implementation.

Calling G_IS_LIST_MODEL(gobj) on the implementation's gobj returns 1.
However, G_IS_LIST_MODEL(gobj) on the derived class's gobj returns 0.

How to make inheritance work? I've been unable to find any
guides/tutorials on this issue, hence the question.

The implementation is defined as follows:

 class Item { ... }

 class ModelImpl: public Gio::ListModel, public Glib::Object {
 public: ModelImpl(): Glib::ObjectBase(typeid(ModelImpl)),
 Gio::ListModel() {}
 virtual ~ModelImpl() = default;
 protected:
 std::vector items;
 GType get_item_type_vfunc() override {
 return Item::get_type();
 }
 guint get_n_items_vfunc() override {
 return items.size();
 }
 gpointer get_item_vfunc(guint position) override {
 if (position < items.size()) {
 return items[position]->gobj();
 }
 return nullptr;
 }
 };

And the derived class:

 class Derived: public ModelImpl {
 Derived(): ModelImpl() {}
 }

Thanks in advance!

Sergey Smirnykh
___
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

Re: activate signal for Entry

[Kjell Ahlstedt via gtkmm-list]

Den 2021-07-18 kl. 21:01, skrev Deep Majumder via gtkmm-list:

Hi everyone,
The Gtkmm book mentions that Entry can accept a signal handler for the 
"activate" signal. However, I found no method called "signal_activate" 
for the Entry class. What is this method actually called?

Warm regards,
Deep

Gtk::Entry::signal_activate() exists in gtkmm3, but it does not exist in 
gtkmm4. You can probably connect to 
Gtk::CellEditable::signal_editing_done() with the same result. 
Gtk::Entry implements the Gtk::CellEditable interface.


The gtkmm4 version of the gtkmm book has not been fully updated to 
describe gtkmm4. Some parts of it still describe gtkmm3. Mentioned here: 
https://developer.gnome.org/gtkmm-tutorial/stable/sec-this-book.html.en


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::ColumnView examples

[Kjell Ahlstedt via gtkmm-list]

Den 2021-07-04 kl. 20:12, skrev Andreas Persson via gtkmm-list:

David Gasa i Castell via gtkmm-list wrote:
Could you provide some examples (or maybe just one…) of the basic 
usage of Gtk::ColumnView (in Gtkmm-4.0) ?


Hi, I uploaded an example here: https://gitlab.gnome.org/-/snippets/2226

It might be unnecessarily complicated, I don't quite remember. It was 
something I wrote last year when I worked with the ColumnView binding.


/Andreas


One of gtk's demo programs uses GtkColumnView: Lists -> Settings
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/demos/gtk-demo/listview_settings.c
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/demos/gtk-demo/listview_settings.ui

It's not trivial to understand what a corresponding C++ code would look 
like. That demo shows more than GtkColumnView. As its name suggests, the 
main intention is to list available GSettings.


Andreas, it would be nice if you could convert your Gtk::ColumnView 
example to a demo program in gtkmm/demos/gtk-demo. Perhaps Lists -> 
ColumnView. If you have time, of course.


/Kjell

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Memory leak when drawing with pangomm/cairomm (MSYS2)

[Kjell Ahlstedt via gtkmm-list]

Den 2021-06-22 kl. 13:38, skrev 廖骏轩 via gtkmm-list:

I have just found out that the Windows version of my project has a massive 
memory leak, while on Linux it seems alright. It uses pangomm and cairomm to 
display text, and I believe it’s similar to the examples in the online book, 
“Programming with gtkmm4”. queue_draw() is called every 100 ms, and in a few 
minutes, the memory usage would reach several GB. If I don’t call queue_draw(), 
the memory used stays around 100 MB.
Does anyone know what caused the memory leak? Thanks！


I don't know what caused the memory leak, but I'd like to give you a few 
suggestions for trouble-shooting.


The C++ bindings (gtkmm, pangomm, etc.) have no or extremely little code 
that's not identical on Windows and Linux. In the first place, suspect 
one of the underlying C modules (gtk, pango, etc.).


Do you know if there's a similar memory leak with gtkmm3? If there's no 
memory leak with gtkmm3, suspect gtk4.


Remove more and more of the code, possibly until there's nothing left to 
draw for queue_draw(). If the memory leak disappears at some step, you 
may have found the function that leaks memory.


Is valgrind or a similar memory analyzer available on Windows? If so, it 
can probably tell you who allocates a huge amount of memory.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gcc 11 compatibility?

[Kjell Ahlstedt via gtkmm-list]

On 2021-05-19 09:24, Mike Liao wrote:
Thanks! I have manually changed all the bad constructors in those 
header files, and it works now. Hope the next release of glibmm will 
include those fixes in the repository :D

They are included in glibmm 2.66.1 and 2.68.1.


On 5/19/21 1:18 AM, Kjell Ahlstedt wrote:

Den 2021-05-18 kl. 17:51, skrev Mike Liao via gtkmm-list:
I've recently updated my gcc to version 11, and I can't compile my 
project under thec++20 standard.


Here is part of the errors gcc reports:

/usr/include/glibmm-2.68/glibmm/variant.h:910:24: error: expected 
unqualified-id before ‘)’ token

  910 |   Variant();
  |    ^
/usr/include/glibmm-2.68/glibmm/variant.h:971:25: error: expected 
unqualified-id before ‘)’ token

  971 |   Variant< Variant >();
  | ^
/
Does this have anything to do with some new rules introduced in c++20?

Yes, C++20 is stricter in some  respects, and gcc 11 is more C++20 
compliant than gcc 10. Glib::Variant has been updated in the git 
repository, but not yet in any released version of glibmm. See 
https://gitlab.gnome.org/GNOME/glibmm/-/merge_requests/50



___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gcc 11 compatibility?

[Kjell Ahlstedt via gtkmm-list]

Den 2021-05-18 kl. 17:51, skrev Mike Liao via gtkmm-list:
I've recently updated my gcc to version 11, and I can't compile my 
project under thec++20 standard.


Here is part of the errors gcc reports:

/usr/include/glibmm-2.68/glibmm/variant.h:910:24: error: expected 
unqualified-id before ‘)’ token

  910 |   Variant();
  |    ^
/usr/include/glibmm-2.68/glibmm/variant.h:971:25: error: expected 
unqualified-id before ‘)’ token

  971 |   Variant< Variant >();
  | ^
/
Does this have anything to do with some new rules introduced in c++20?

Yes, C++20 is stricter in some  respects, and gcc 11 is more C++20 
compliant than gcc 10. Glib::Variant has been updated in the git 
repository, but not yet in any released version of glibmm. See 
https://gitlab.gnome.org/GNOME/glibmm/-/merge_requests/50

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

(In)compatibility of gtkmm with cairomm, pangomm and atkmm

[Kjell Ahlstedt via gtkmm-list]

A reply to https://gitlab.gnome.org/GNOME/gtkmm/-/issues/97 and 
https://discourse.gnome.org/t/in-compatibility-of-gtkmm-with-cairomm-pangomm-and-atkmm/6370?u=raghavgururajanand


The gtkmm developers have not (yet) started using discourse.gnome.org. 
We still use the mailing list at https://mail.gnome.org/archives/gtkmm-list.


The mailing list post 
https://mail.gnome.org/archives/gtkmm-list/2020-December/msg00013.html
tries to explain the complicated relationships between the two sets of 
module versions.


> [1] Why is gtkmm-3.24.4 incompatible with cairomm-1.16.0, 
pangomm-2.48.0 and atkmm-2.36.0, as all of these are latest stable releases?


There are two sets of ABI-incompatible versions of glibmm, cairomm, 
pangomm and atkmm. It was decided long ago that the new versions should 
not have their major version numbers bumped up, because the underlying C 
modules (glib, cairo, pango and atk) have not released ABI-incompatible 
versions, and thus have not bumped their major versions. I'm not sure 
this was the best possible decision, but now we have to live it.


The last versions that will be compatible with gtkmm-3.y.z are 
glibmm-2.66.z, cairomm-1.14.z, pangomm-2.46.z and atkmm-2.34.z. (There 
is no atkmm-2.34.z yet. Perhaps there will never be. The maintenance of 
atkmm is really minimal.)


> [2] Will there be new release of gtkmm in 3.24 series, that will be 
compatible with cairomm-1.16.0, pangomm-2.48.0 and atkmm-2.36.0?


No, there will never be a gtkmm-3.y.z version compatible with 
libsigc++-3.y.z, glibmm-2.68.z, cairomm-1.16.z, pangomm-2.48.z and 
atkmm-2.36.z. They are compatible with gtkmm-4.y.z.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Problem building mm-common on MSYS2

[Kjell Ahlstedt via gtkmm-list]

On 2021-04-15 02:24, Oliver Niebuhr wrote:

On 14/04/2021 22:55, Oliver Niebuhr wrote:
[cut for readability]

I do not know if this is the Solution but I added 'sys.executable' and 
the Error Message went away:


result = subprocess.run([sys.executable, 'aclocal', '--print-ac-dir'],
  stdout=subprocess.PIPE, 
stderr=subprocess.DEVNULL,

  universal_newlines=True)

I have no Idea if this has any other Impact. I was just following an 
Example from Digital-Ocean after a Web search about Python and 
Parameters.


As no additional Files are getting installed (compared to when running 
into that Error), I assume the Installation itself was fine before 
already.


BTW: Do I need a mm-common Package for every bitness or can I use the 
x86_64 Package for x86 builds?


Thanks again for your time!

You need mm-common only if you will build any of the mm packages 
(sigc++, glibmm, gtkmm, etc.) with maintainer-mode=true. That's 
necessary if you build from the git repository. If you build from 
tarballs with maintainer-mode=false, mm-common is not necessary.


If Python's subprocess.run() can't be trusted in MSYS2, or in Windows in 
general, it's not a fatal bug when mm-common is built or installed. 
extra-install-cmd.py is not called, if Meson does not find aclocal. The 
problem for you is that Meson finds aclocal, but subprocess.run() in the 
Python script does not. But if there is a general problem with 
subprocess.run() in MSYS2, you may have trouble elsewhere when you build 
mm modules. subprocess.run() is used in several Python scripts. Perhaps 
you can avoid all the other subprocess.run() if you build from tarballs 
with maintainer-mode=false and build-documentation=false (default when 
building from tarballs).



___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: GTK4 and gtkmm4 on Arch - Question

[Kjell Ahlstedt via gtkmm-list]

You should have sent your questions to the gtkmm-list. That's usually 
better than sending to a specific person. More people get a chance to 
see the questions and reply to them.


If Arch Linux does not contain a gtkmm4 package, it's more difficult for 
you to test it. You will have to build some packages yourself, either 
from tarballs or from the git repositories. Building from tarballs is 
easier than building from the git repos. 
https://mail.gnome.org/archives/gtkmm-list/2020-December/msg00013.html 
shows what you need. All tarballs except the one for cairomm are stored 
at https://download.gnome.org/sources/. Cairomm tarballs are stored at 
https://www.cairographics.org/releases/. When you find tarballs with 
higher version numbers than the ones listed in msg00013.html, choose the 
higher numbered ones.


README files show how to build the tarballs. Build with Meson. That's 
easier than building with Autotools.


Should you wait until an gtkmm4 package is available in Arch Linux? I 
don't know. You can probably ask on some Arch Linux mailing list when 
that may happen. I once asked when it can be expected on Ubuntu Linux. 
The answer I got was that, with very few exceptions, a subroutine 
library is included in Ubuntu only if it is used by an application 
that's included in Ubuntu. I don't know if Arch Linux has the same policy.


Kjell

On 2021-04-14 13:16, Wieczorek Gabriela wrote:

Hello,my name is Gabrielle, sorry for my poor English.

I'm not sure where or who should i ask few things about using gtkmm4 
with gtk4.


So,i'm working on Linux Arch system,with xfce4 DE,i'm not expert or 
advanced programmer,


just averege user who like to read and try to writing code from time 
to time.


I was reading on gnome developers page that if i want to try creating 
new app in C/CPP


i should go and use GTK4 already, so installed gtk4 packages on my 
arch, but gtkmm4 is no available,


so i can't try examples from programming with gtkmm4 book.

I'm familiar with programming for web - html,css,sass,gulp,js, 
wordpress theming,


also tried to creating my own GTK3 theme for linux some time ago.

Now i just wanted to try some simple C++ by creating simple GTK4 app, 
but i'm not sure if i should downgrade to gtk3  now and stay with gtkmm3?


Or wait bit longer for gtkmm4?

I don't know what to do,sorry for botherin you,

best regards,

Gabrielle.

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Problem building mm-common on MSYS2

[Kjell Ahlstedt via gtkmm-list]

On 2021-04-14 08:11, Oliver Niebuhr wrote:
/util/meson_aux/extra-install-cmd.py 
C:/Dev/Sources/GTK4/mmcommon/x64/debug/share/aclocal'

--- stdout ---

--- stderr ---
Traceback (most recent call last):

  File "C:/Dev/MMCommonSrc/util/meson_aux/extra-install-cmd.py", line 
17, in 


    result = subprocess.run(['aclocal', '--print-ac-dir'],


FileNotFoundError: [WinError 2] The system cannot find the file specified


The installation of mm-common fails on line 17 of extra-install-cmd.py. 
I don't understand what the error message refers to ("the file 
specified"). extra-install-cmd.py is a very simple Python script that 
just prints a warning, if appropriate. The failing Python command is


  result = subprocess.run(['aclocal', '--print-ac-dir'],
  stdout=subprocess.PIPE, 
stderr=subprocess.DEVNULL,

  universal_newlines=True)

It would be fine if you could make some tests on your system. Run 
extra-install-cmd.py directly from the command line. It requires an 
argument, but the argument can be anything. It's just part of the 
warning that the script is supposed to print.


You will probably get the same FileNotFoundError again. Then try 
changing the script. Change the subprocess.run() command to


  result = subprocess.run(['aclocal', '--print-ac-dir'],
  capture_output=True,
  universal_newlines=True)

That would be an acceptable change that I can make in mm-common. I just 
don't understand why it would be necessary.


If capture_output=True also fails, you can try

  result = subprocess.run(['aclocal', '--print-ac-dir'],
  universal_newlines=True)

just to see what happens.

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Ten years with gtkmm, glibmm and other mm modules

[Kjell Ahlstedt via gtkmm-list]

About 10 years ago I started a new hobby: Making contributions to gtkmm 
and other mm modules. Along the way other contributors have decreased 
their share in the development of these modules. I have found myself 
adding the majority of new patches. That was never my intention, but I 
wanted to have a useful version of gtkmm4 when gtk4 became stable. That 
has happened now. There are stable versions of gtk4, gtkmm4 and all 
modules that gtkmm4 depends on.


In the future I intend to spend less time on mm modules than I've done 
the last few years. An opportunity for other C++ programmers to enter.


Don't misunderstand me. I have not been alone. Other persons have 
contributed. But I've done a greater part of the job than I intended. 
And still gtkmm4 and the corresponding version of gtkmm-documentation 
are not quite finished. Classes in gtk's gsk subdirectory have not been 
wrapped in C++ code. Neither have classes and methods that use 
structures from the graphene library. Should there be a C++ binding of 
graphene? graphenemm? Hopefully most users of gtkmm4 will not need the 
missing classes and methods urgently. It's always possible to use the C 
functions directly, although that's not what a C++ programmer would love 
to do.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Missing Header File ATKMMCONFIG.H

[Kjell Ahlstedt via gtkmm-list]

This looks related to atkmm issue 
https://gitlab.gnome.org/GNOME/atkmm/-/issues/2


With atkmm release 2.28.1 yet another include directory must be added to 
the list of directories where the compiler searches for include files. 
Something has not been updated, either in Fedora or in your own build 
system. Check with pkg-config:


pkg-config --cflags atkmm-1.6

There shall be two include directories for atkmm-1.6, one of them ending 
in atkmm-1.6/include. If there is, you need to reconfigure your build 
system to have compile commands updated with the new include directory.


If pkg-config does not list an atkmm-1.6/include directory, atkmm has 
not been properly updated in Fedora.


Den 2021-02-04 kl. 14:40, skrev mike lear via gtkmm-list:

Hello gtkmm list:
I am using gtkmm-3.0 on a fedora 33 x86_64 laptop. I wish to report a file
missing in the /usr/include/atkmm-1.6 sub directory.

My earlier version which is gmmproc 2.56.0 works fine.
But my latest download version gmmproc 2.64.3 fails as it call for
the file atkmmconfig.h to be included.  This files appears to be
missing from the build.

Previous build:  This version  atkmm-1.6 WORKS
This is the first few lines from the header file relation.h
// Generated by gmmproc 2.56.0 -- DO NOT MODIFY!
#ifndef _ATKMM_RELATION_H
#define _ATKMM_RELATION_H
#include 
#include 
...
#endif

Current build: Version atkmm-1.6 Fails with missing file atkmmconfig.h
This is the first few lines from the header file relation.h
Generated by gmmproc 2.64.3 -- DO NOT MODIFY!
#ifndef _ATKMM_RELATION_H
#define _ATKMM_RELATION_H
#include 
...
#endif
The missing file atkmmconfig.h is included in the following files in 
the atkmm

sub-directory:
action.h component.h document.h init.h range.h relation.h selection.h
stateset.h streamablecontent.h table.h wrap_init.h

I am not sure if this is specific to fedora or an actual bug.

Michael Lear

___
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

[Kjell Ahlstedt via gtkmm-list]

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 guess meson should check if this dependency is already installed 
instead of falling over during compilation. There is a .pc file for 
this package, so it should be simple to fix in meson.


gtkmm4 does not use Vulkan, but gtk4 does. It surprises me that the 
building of gtkmm4 failed because of a missing Vulkan package. Are you 
sure the failure was not in the compilation of a gtk4 file? There may be 
a bug in one or more meson.build files in gtk4. It looks like the Meson 
configuration of gtk4 checks if Vulkan is installed, but then tries to 
compile C files that include vulkan/vulkan.h (such as 
gdkvulkancontext.h) even if Vulkan is not installed.

___
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

[Kjell Ahlstedt via gtkmm-list]

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, Phil Wolff via gtkmm-list wrote:
The tutorial at 
https://developer.gnome.org/gtkmm-tutorial/4.0/chapter-working-with-source.html.en 
has a link to the gnome-love mailing list: 
http://mail.gnome.org/mailman/listinfo/gnome-love. The mailman there 
says "No such list /gnome-love"/




___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

First stable version of gtkmm-4.0 has been released

[Kjell Ahlstedt via gtkmm-list]

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 other C++ packages, 
parallel installable with similar older packages.


Columns in table:
A. ABI name of package used by gtkmm-4.0
B. Tarball name of latest version
C. ABIname of similar package used by gtkmm-3.0
ABI = Application Binary Interface; ABI names are the names of 
pkg-config's .pc files.


A. ABI name 4
B: Tarball name
C: ABI name 3
sigc++-3.0
libsigc++-3.0.6.tar.xz
sigc++-2.0
cairomm-1.16
cairomm-1.16.0.tar.xz
cairomm-1.0
glibmm-2.68
giomm-2.68
glibmm-2.68.0.tar.xz
glibmm-2.4
giomm-2.4
(atkmm-2.36)
(atkmm-2.36.0.tar.xz)
atkmm-1.6
pangomm-2.48
pangomm-2.48.0.tar.xz
pangomm-1.4
gtk4
gtk-4.0.0.tar.xz
gtk+-3.0
gdk-3.0
gtkmm-4.0
gtkmm-4.0.0.tar.xz
gtkmm-3.0
gdkmm-3.0

gtkmm-4.0 does not depend on atkmm. You don't need atkmm in order to 
build and run gtkmm-4.0.

There is no gdkmm-4.0 ABI.

All these packages can be built with Meson. If you build from git 
clones, you also need mm-common.


There is a version of the gtkmm tutorial that describes gtkmm-4.0, 
https://developer.gnome.org/gtkmm-tutorial/4.0


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Failure to add radio buttons to popup menu.

[Kjell Ahlstedt via gtkmm-list]

On 2020-12-09 08:55, Kjell Ahlstedt wrote:


Gtkmm supports glade, if gtk supports glade. Gtkmm just wraps gtk's C 
functions in C++ code. The glade file with a GtkDialog that you 
mention should be no problem for gtkmm. It's similar to the 
https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/gtkmm-3-24/examples/book/builder/basic 
example.


A glade file with GtkRadioMenuItem can probably also be used. If I had 
realized from the beginning that you're not interested in the kind of 
solution I gave you, I might have managed to get something working 
without touching the ui_info string. There is a limit to how much time 
I want to spend trying to answer your questions. That's a drawback 
with free open source code: When you get stuck, no one is responsible 
for answering your questions.


GtkRadioMenuItem can't be used together with GAction and GSimpleAction, 
and therefore it can't be used together with Gio::Action, 
Gio::SimpleAction, Gio::SimpleActionGroup. I had a look at gtk's source 
code and made some tests. When I replaced GtkRadioMenuItem by 
GtkCheckMenuItem, the signal handler was called, but of course the menu 
items didn't act as connected in a radio item group. GtkRadioMenuItems 
will perhaps work with the deprecated Gtk::RadioAction and Gtk::ActionGroup.


See also the gtk issue https://gitlab.gnome.org/GNOME/gtk/-/issues/2552

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Debug glibmm-CRITICAL

[Kjell Ahlstedt via gtkmm-list]

On 2020-12-15 07:31, Emil Nowak via gtkmm-list wrote:

Hello,
In my application from time to time I get "glibmm-CRITICAL" errors. They are
displayed on console.
I wonder how can I debug them.
So far I found that in glib there is env variable "G_DEBUG=fatal-criticals"
for that in Glib, but seems it doesn't affect Glibmm.

Is there anything similar in glibmm/gtkmm

I'm using:
Glibmm: 2.64.2
Gtkmm: 3.24.2
Run your application in a debugger, such as gdb, and set a breakpoint at 
calls to the g_log function. Check from where that function is called. 
There may be both interesting and uninteresting calls to g_log().
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Failure to add radio buttons to popup menu.

[Kjell Ahlstedt via gtkmm-list]

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 generate user interfaces.

Gtkmm supports glade, if gtk supports glade. Gtkmm just wraps gtk's C 
functions in C++ code. The glade file with a GtkDialog that you mention 
should be no problem for gtkmm. It's similar to the 
https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/gtkmm-3-24/examples/book/builder/basic 
example.


A glade file with GtkRadioMenuItem can probably also be used. If I had 
realized from the beginning that you're not interested in the kind of 
solution I gave you, I might have managed to get something working 
without touching the ui_info string. There is a limit to how much time I 
want to spend trying to answer your questions. That's a drawback with 
free open source code: When you get stuck, no one is responsible for 
answering your questions.



___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Failure to add radio buttons to popup menu.

[Kjell Ahlstedt via gtkmm-list]

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 been removed from gtk4.


On 2020-12-07 23:27, Carlo Wood wrote:

On Sun, 6 Dec 2020 16:39:42 +0100
Kjell Ahlstedt  wrote:


I combined ideas from the book/menus/main_menu and book/menus/popup
examples in gtkmm-documentation. Then it works. See attached files.

Thank you. So, the problem is that this doesn't work
with glade generated syntax?

It seems that the ui_info string that you used
causes a Gio::Menu to be created, while if I use
a glade generated format (aka, a file that I read
with m_refBuilder->add_from_file(...)) then
a Gtk::Menu is being created.

The latter is not working.

Can you make it work by loading the attached glade file?
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Failure to add radio buttons to popup menu.

[Kjell Ahlstedt via gtkmm-list]

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 work".

Most notably, the line

 refActionGroup->add_action_radio_string("radio",
 sigc::mem_fun(*this, ::on_menu_file_popup_radio),
 "'A'");

doesn't even cause the call back function to be called
when I click on the radio menu entry.

Can you please tell me what I do wrong and how it should
be done?

I reproduced my problem by editing
gtkmm-documentation/-/blob/gtkmm-3-24/examples/book/menus/popup

The cloned repository and commit can be found here:

https://gitlab.gnome.org/carlo.wood/gtkmm-documentation/-/commit/e106f79c78bba7ad265817a74897f09501d024db

If you clone my repository, please note that the change was
made to the gtkmm-3-24 branch (not master)!

Or you can copy the two changed files from here:

https://gitlab.gnome.org/carlo.wood/gtkmm-documentation/-/blob/gtkmm-3-24/examples/book/menus/popup/examplewindow.cc
https://gitlab.gnome.org/carlo.wood/gtkmm-documentation/-/blob/gtkmm-3-24/examples/book/menus/popup/examplewindow.h

Any pointers would be greatly appreciated.

Regards,
Carlo Wood
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
/* gtkmm example Copyright (C) 2002 gtkmm development team
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2
 * as published by the Free Software Foundation.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 */

#ifndef GTKMM_EXAMPLEWINDOW_H
#define GTKMM_EXAMPLEWINDOW_H

#include 

#include 

class ExampleWindow : public Gtk::Window
{
public:
  ExampleWindow();
  virtual ~ExampleWindow();

protected:
  //Signal handlers:
  bool on_button_press_event(GdkEventButton* button_event) override;

  void on_menu_file_popup_normal();
  void on_menu_file_popup_radio(Glib::ustring const& parameter);

  //Child widgets:
  Gtk::Box m_Box;
  Gtk::EventBox m_EventBox;
  Gtk::Label m_Label;

  Glib::RefPtr m_refBuilder;

  // One set of choices:
  Glib::RefPtr m_refChoice;

  std::unique_ptr m_pMenuPopup;
};

#endif //GTKMM_EXAMPLEWINDOW_H
/* gtkmm example Copyright (C) 2002-2013 gtkmm development team
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2
 * as published by the Free Software Foundation.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 */

#include "examplewindow.h"
#include 

ExampleWindow::ExampleWindow()
: m_Box(Gtk::ORIENTATION_VERTICAL),
  m_Label("Right-click to see the popup menu."),
  m_pMenuPopup(nullptr)
{
  set_title("popup example");
  set_default_size(200, 200);

  add(m_Box);

  //Add an event box that can catch button_press events:
  m_Box.pack_start(m_EventBox);
  m_EventBox.signal_button_press_event().connect(sigc::mem_fun(*this,
  ::on_button_press_event) );

  m_EventBox.add(m_Label);

  //Create actions:

  //Fill menu:

  auto refActionGroup =
Gio::SimpleActionGroup::create();

  refActionGroup->add_action("normal",
sigc::mem_fun(*this, ::on_menu_file_popup_normal));

  m_refChoice = refActionGroup->add_action_radio_string("radio",
sigc::mem_fun(*this, ::on_menu_file_popup_radio), "A");

  insert_action_group("examplepopup", refActionGroup);

  m_refBuilder = Gtk::Builder::create();

  //Layout the actions in a menubar and toolbar:
  Glib::ustring ui_info =
""
"  "
""
"  "
"Normal"
"examplepopup.normal"
"  "
"  "
"Radio 1"
"examplepopup.radio"
"  A"
"  "
"  "
"Radio 2"
"examplepopup.radio"
"  B"
"  "
""
"  "
"";

  try
  {
m_refBuilder->add_from_string(ui_info);
  }
  catch(const Glib::Error& ex)
  {
std::cerr << "building menus failed: " <<  ex.what();
  }

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

[Kjell Ahlstedt via gtkmm-list]

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 << (*iList)[m_Columns.m_col_name] << std::endl;
    ++iList;
  }
  m_refTreeModel->clear();
}

No segfault!

You should use a debugger, such as gdb, to find out where the segfault 
is generated.


/Kjell

On 2020-12-01 17:27, Phil Wolff via gtkmm-list wrote:

Consider this Gtk::ListStore (in a Gtk::ComboBox, if that matters):

    Gtk::TreeIter iList = m_refServModel->get_iter( "0" );
    while ( iList ) {
    std::cout << (*iList)[m_cServings.m_sStdServ] << 
std::endl;

    ++iList;
    }
    m_refServModel->clear ();

The while() loop correctly displays the several items in the list, but 
the clear() generates a segfault.


Any insight would be appreciated!


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::Builder::get_widget_derived() Issue on Fedora 33

[Kjell Ahlstedt via gtkmm-list]

You're on the right track. I built gtkmm with the -flto compile and link 
option (and gcc 9.3.0). Then Ahmet's test case does not work.


I then removed the redefiniton of G_GNUC_CONST and wrapped the call to 
Gtk::TextView::get_type() in a call to g_type_ensure() in wrap_init.cc. 
The test case then works even with LTO enabled.


I guess that with LTO the linker notices that the get_type() methods are 
declared with __attribute__((__const__)) (from the expansion of 
G_GNUC_CONST) in one compilation unit and then assumes that it's okay to 
optimize as if it were declared that way everywhere.


g_type_ensure() is safer than the redefinition of G_GNUC_CONST. I'll fix 
this in glibmm/tools/generate_wrap_init.pl.in. (wrap_init.cc is 
generated by generate_wrap_init.pl.) It will probably take quite some 
time before this fix is available in released versions of all affected 
mm packages. Meanwhile it would be fine if Fedora and other distros 
could build the mm packages without LTO.


On 2020-11-17 22:44, Andrew Potter wrote:

I believe this is caused by https://fedoraproject.org/wiki/LTOByDefault

I built the srpm and noticed that the get_type() calls were present in 
wrap_init.o but was missing from the .so


I added
%define _lto_cflags %{nil}
to the gtkmm .spec file and rebuilt--this disables LTO; the get_type() 
were then present in the .so


I've left a comment at Fedora's bug tracker for them to disable lto in 
mm packagesI've left a comment at Fedora's bug tracker for them to 
disable lto in mm packages. But if we used g_type_ensure() then LTO 
would be possible I think



___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::Builder::get_widget_derived() Issue on Fedora 33

[Kjell Ahlstedt via gtkmm-list]

wrap_init.cc contains the following lines:

// Disable the 'const' function attribute of the get_type() functions.
// GCC would optimize them out because we don't use the return value.
#undef  G_GNUC_CONST
#define G_GNUC_CONST /* empty */

This has so far made sure that the compiler does not optimize out the 
calls to the get_type() functions.
@Andrew, do you think this will not be so with very new compilers? I've 
used gcc 9.3.0.


Kjell

On 2020-11-17 09:37, Andrew Potter wrote:


On Tue, Nov 17, 2020 at 12:01 AM ahmet öztürk > wrote:


Is this a Gtkmm issue then? Fedora guys also think that it is an
upstream issue.
See:https://bugzilla.redhat.com/show_bug.cgi?id=1898054

But why does it only occur on Fedora 33?

Likely its due to a new optimization in gcc 10 which few other distros 
are using yet.
Since the GtkFoo::get_type() calls in wrap_init() are not using the 
return value, it makes sense to me that they are eligible for dead 
code elimination, as is suggested in the blog post. Since Gtkmm is 
calling these methods explicitly to ensure the GTypes are made known, 
I think fixing it in Gtkmm by adding g_type_ensure() is the path of 
least resistance.


@Andrew, I do not know how I am supposed to use
g_type_ensure(TVDerived::get_type()). I am not familiar with Gtk+
or GObject, I have only used Gtkmm, so far.


You can simply replace TVDerived dummy; with 
g_type_ensure(TVDerived::get_type()); in your example program.


For a more professional look, you can define an init() function that 
calls g_type_ensure() for all of your custom derived types and call it 
in main()--but I guess you should explicitly call 
Gtk::Main::init_gtkmm_internals() before your init() ala 
https://developer.gnome.org/gtkmm-tutorial/stable/sec-wrapping-initialization.html.en


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Enable / disable a Gio::SimpleAction.

[Kjell Ahlstedt via gtkmm-list]

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
 deprecated widgets first.

In other words, it seems that the usage of "", "" and 
"" etc.
is old-style, pre- GTK+ 3.


No, it seems that glade does not understand ,  and . 
(You did remove the double-quotes, I hope.) This format is used in many examples both in 
gtk3/gtkmm3 and gtk4/gtkmm4. It's certainly not old-fashioned.


Since the 'action' and 'target' attributes are important in order to get
the whole to work as a radio button, I need to know how one can do this
with glade.

Sorry, I know almost nothing about glade. I can't help you with 
questions about glade. Hope someone else can.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Enable / disable a Gio::SimpleAction.

[Kjell Ahlstedt via gtkmm-list]

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.
https://gitlab.gnome.org/GNOME/gtkmm/-/blob/gtkmm-3-24/demos/gtk-demo/example_menus.cc
The demo program uses Gtk::RadioMenuItem.

If you want to simplify the future upgrade of your program from gtkmm3 
to gtkmm4, I recommend that you look at the tutorial example in the 
first place. It does not use Gtk::RadioMenuItem. There are no 
specialized radio button classes or radio menu item classes in gtkmm4. 
(It's still possible to make GUIs with radio buttons and radio menu items.)


On 2020-10-06 15:47, Carlo Wood wrote:

I have another problem with the same popup menu: I need certain menu
entries to be radio actions (that is, only one can be selected at
a time, but there are multiple such groups in the single popup menu).

For example, I have:

Gtk::RadioAction::Group group_to_move;
m_refToMoveWhite_action = Gtk::RadioAction::create(group_to_move, "ToMoveWhite", 
"White to play");
m_refToMoveBlack_action = Gtk::RadioAction::create(group_to_move, "ToMoveBlack", 
"Black to play");

where the menu is read from a .glade file with Gtk::Builder, containing:

 
   
 True
 False
 PlacepieceMenu.ToMoveWhite
 White to play
 True
 True
   
 
 
   
 True
 False
 PlacepieceMenu.ToMoveBlack
 Black to play
 True
 True
   
 

Now I want a function to be called when I click these entries.

In the 2.4 code I had something like:

 m_refActionGroup->add_action(m_refToMoveWhite_action, sigc::mem_fun(*this, 
::on_menu_to_move_white));
 m_refActionGroup->add_action(m_refToMoveBlack_action, sigc::mem_fun(*this, 
::on_menu_to_move_black));

But that doesn't compile anymore. Because so many things got deprecated, the 
types of many variables
had to change and now I can't combine them anymore :/.

Ie, m_refActionGroup now has the type:

 Glib::RefPtr m_refActionGroup;

maybe that has to be Glib::RefPtr before I can add both 
Gio::SimpleAction's
and Gtk::RadioAction to it? The latter isn't derived from Gio:Action either 
though :/.

I am totally stuck on this. Also cannot find any example that shows how to do 
this.

I am just very confused about how all this is supposed to work. Before it 
seemed like that
if I wanted to make a big pop-up menu then EVERY entry in the menu had to be an 
action
and well all of the same group (that was using Gtk::UIManager). Now I'm using 
Gio::Action
and Gtk::Builder instead and I have no idea how to make it working again.

Carlo Wood



___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Enable / disable a Gio::SimpleAction.

[Kjell Ahlstedt via gtkmm-list]

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 Gtk::Action?  Something like


    Glib::RefPtr m_refActionGroup;
...
m_refActionGroup->get_action("PlacepieceBlackPawn")->set_sensitive(row 
!= 0 && row != 7);


Gtk::ActionGroup and Gtk::Action are deprecated in gtkmm 3.x and removed in 
gtkmm 4.x.

How do you add the Gio::SimpleAction to the Gio::SimpleActionGroup? I suppose 
you have a

Glib::RefPtr refPlacepieceBlackPawn = ..
or a
m_refActionGroup->add_action("PlacepieceBlackPawn"); that returns a 
Glib::RefPtr. 

Then it would be easy to save that Glib::RefPtr, so you 
don't need lookup_action().
If you prefer lookup_action(), this should work in gtkmm 3.x, but not in gtkmm 
4.x:

auto simple_action = 
Glib::RefPtr::cast_dynamic(m_refActionGroup->lookup_action("PlacepieceBlackPawn"));

Shall be

auto simple_action = Glib::RefPtr
::cast_dynamic(m_refActionGroup->lookup_action("PlacepieceBlackPawn"));


if (simple_action)
  simple_action->set_enabled(row != 0 && row != 7);


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Enable / disable a Gio::SimpleAction.

[Kjell Ahlstedt via gtkmm-list]

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 m_refActionGroup;
...
m_refActionGroup->get_action("PlacepieceBlackPawn")->set_sensitive(row 
!= 0 && row != 7);


Gtk::ActionGroup and Gtk::Action are deprecated in gtkmm 3.x and removed in 
gtkmm 4.x.

How do you add the Gio::SimpleAction to the Gio::SimpleActionGroup? I suppose 
you have a

Glib::RefPtr refPlacepieceBlackPawn = ..
or a
m_refActionGroup->add_action("PlacepieceBlackPawn"); that returns a 
Glib::RefPtr. 

Then it would be easy to save that Glib::RefPtr, so you 
don't need lookup_action().
If you prefer lookup_action(), this should work in gtkmm 3.x, but not in gtkmm 
4.x:

auto simple_action = 
Glib::RefPtr::cast_dynamic(m_refActionGroup->lookup_action("PlacepieceBlackPawn"));
if (simple_action)
  simple_action->set_enabled(row != 0 && row != 7);

 


On 2020-10-04 19:30, Carlo Wood wrote:

In gtkmm 2.x I had,

 Glib::RefPtr m_refActionGroup;

...

 m_refActionGroup->get_action("PlacepieceBlackPawn").set_sensitive(row != 0 
&& row != 7);

With gtkmm 3.x it seems that I am forced to do:

 
static_cast(m_refActionGroup->lookup_action("PlacepieceBlackPawn").get())->set_enabled(row
 != 0 && row != 7);

Any other attempt (that would look at lot more sane and logical) gives a compile
error in a gtkmm header - or maybe I'm missing something?

The most logical thing would be for 'Gio::SimpleActionGroup::lookup_action' to 
return
a Glib::RefPtr, in which case I could do just:

  m_refActionGroup->lookup_action("PlacepieceBlackPawn")->set_enabled(row != 0 
&& row != 7);

The builtin cast of Glib::RefPtr isn't working, aka

 Glib::RefPtr action = 
m_refActionGroup->lookup_action("PlacepieceBlackPawn");

Neither is,

 
static_cast>(m_refActionGroup->lookup_action("PlacepieceBlackPawn"))->set_enabled(row
 != 0 && row != 7);

How am I supposed to get my Gio::SimpleAction back?

Carlo

PS lookup_action return a Gio::Action, which is a base class and doesn't have 
the set_enabled method.
___
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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/ 



Basically what I want is to have my custom node widgets on a "canvas" 
so I can be able to move them by dragging them. If anyone knows 
Blender's node editor, it should also be possible to pan with middle 
mouse button and also zoom.


The Gtk::Layout component seems the right one when it comes to put 
nodes at specific location on the interface. I also want to draw a 
custom grid so this so the documentation seems adapted :

/
/
/Infinite scrollable area containing child widgets and/or custom drawing./

Now the "infinite scrollable area" concept interest me because I want 
to be able to move on the node tree. The documentation says that I can 
just put the layout into a Gtk::ScrolledWindow and it supports 
scrolling natively.


Most of the documentation in gtkmm has been copied from GTK (formerly 
GTK+). The description of Gtk::Layout is more or less a copy of the 
documentation of GtkLayout. I don't understand why it's said that the 
scrollable area is infinite. As far as I know all widgets have finite 
size. The size can be large, much larger than a normal screen, but not 
infinite. I think you'd better ask the GTK people. They don't use gnome 
mailing lists any more. Their discussions have moved to discourse.gnome.org.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: FlowBox::get_child_at_pos() seems missing

[Kjell Ahlstedt via gtkmm-list]

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.




___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Documentation for gstreamermm?

[Kjell Ahlstedt via gtkmm-list]

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.)


You must use doxygen 1.8.11 or earlier when you create a tarball to be 
published on developer.gnome.org. This is an old problem in 
Infrastructure/library-web that never seems to be fixed.

See https://gitlab.gnome.org/Infrastructure/library-web/-/issues/12

On 2020-08-11 21:43, Marcin Kolny via gtkmm-list wrote:
Sorry, forgot to attach link to the documentation: 
https://developer.gnome.org/gstreamermm/1.4/




Mailtrack 
 
	Sender notified by
Mailtrack 
 
11.08.20, 20:42:59 	



wt., 11 sie 2020 o 20:42 Marcin Kolny > napisał(a):



Hi Sid,
Because of some reason the documentation for latest release wasn't
published. For now you can use the one for 1.4 and in the meantime
I'll have a look why that wasn't published for the newest release.


Mailtrack


Sender notified by
Mailtrack


11.08.20, 20:41:42  


wt., 11 sie 2020 o 17:47 Sid Spry mailto:s...@aeam.us>> napisał(a):

https://developer.gnome.org/gstreamermm/stable/

It's blank?
___
gtkmm-list mailing list
gtkmm-list@gnome.org 
https://mail.gnome.org/mailman/listinfo/gtkmm-list



-- 
Marcin Kolny




--
Marcin Kolny

___
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

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

[Kjell Ahlstedt via gtkmm-list]

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:

Hi all,

I did
https://developer.gnome.org/gtkmm-tutorial/stable/sec-drawing-clock-example.html.en
which worked.

Then I changed main.cc to:

#include "clock.h"
#include 
#include 
#include 

int main(int argc, char** argv)
{
auto app = Gtk::Application::create(argc, argv, "org.gtkmm.example");

Gtk::Window win;
win.set_title("Cairomm Clock");

Gtk::Grid m_grid;
Clock c;
m_grid.add(c);
win.add(m_grid);
c.show();
m_grid.show();

return app->run(win);
}

But this just gives a totally empty window. The clock is gone.
How can I fix this?

Carlo
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Merging UI strings into Gtk::Builder?

[Kjell Ahlstedt via gtkmm-list]

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 =
""
"  "
""
...
""
"  "
"";

  m_refBuilder = Gtk::Builder::create();
  m_refBuilder->add_from_string(ui_info);
  m_refBuilder->add_from_string(ui_info2);   auto object = 
m_refBuilder->get_object("menu-linuxchess");
  auto gmenu = Glib::RefPtr::cast_dynamic(object);
  if (gmenu)
  {
auto subobject = m_refBuilder->get_object("xyz");
auto gsubmenu = Glib::RefPtr::cast_dynamic(subobject);
if (gsubmenu)
  gmenu->append_submenu("SomeLabel", gsubmenu);
  }

On 2020-07-27 15:50, Carlo Wood wrote:

Hi,

the documentation at

https://developer.gnome.org/gtkmm/stable/classGtk_1_1Builder.html#ae3520ee31a98ac30b728f93522de8df5

says: "Parses a string containing a GtkBuilder UI definition and merges
it with the current contents of the builder."

But when I try this:

   Glib::ustring ui_info =
 ""
 "  "
 ""
...
 ""
 "  "
 "";

   Glib::ustring ui_info2 =
 ""
 "  "
 ""
...
 ""
 "  "
 "";

   m_refBuilder = Gtk::Builder::create();
   m_refBuilder->add_from_string(ui_info);
   m_refBuilder->add_from_string(ui_info2);

Then the last line *replaces* the content of m_refBuilder.
Nothing is merged, I just get a menu with the definition
from ui_info2.

How can I do this?
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Please help (core dump)

[Kjell Ahlstedt via gtkmm-list]

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 
https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/blob/gtkmm-3-24/examples/book/menus_and_toolbars/examplewindow.cc


I think that's what you can do. Create a Gio::SimpleActionGroup. Add 
your actions to it. Insert it in your widget with Gtk::Widget's 
insert_action_group() method. In the call to insert_action_group() you 
choose what prefix to use in the ui file.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Please help (core dump)

[Kjell Ahlstedt via gtkmm-list]

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 `add_action` above is to that class.

Can someone tell me what I'm doing wrong?

Carlo

Gio::ActionMap is an interface. That's why its constructor is protected. 
An interface can't be instantiated by itself. It must be implemented by 
a class which can be instantiated. If you really must implement 
Gio::ActionMap in your class (which I doubt), there is one or (probably) 
two errors.


First, interfaces must come before the widget class in the list of base 
classes.


class LinuxChessboardWidget : public Gio::ActionMap, public 
cwmm::ChessPositionWidget

This is opposite to what's done in gtkmm's classes that wrap gtk classes.

Second, your constructor must call a special Glib::ObjectBase constructor that 
registers your class with its own GType in glib's GType system. For instance

LinuxChessboardWidget(..) : Glib::ObjectBase("myWidgetClass") . // Or 
whatever you want to call it.

This is an unusual way of using Gio::ActionMap. I don't know if these are the 
only necessary changes. Much more common is to use one of the classes that 
already implement Gio::ActionMap: Gio::SimpleActionGroup, Gtk::Application (via 
Gio::Application) or Gtk::ApplicationWindow.

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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 22:20, Rodolfo Ribeiro Gomes via gtkmm-list wrote:

Hello.

I'm creating a plugin for glade in order to be able to create 
interfaces using custom C++ widgets and edit its properties via glade.


Everything is (finally) working here. My problem now is how to 
properly initialize gtkmm without using the deprecated 
Gtk::Main::init_gtkmm_internals().
As it's a plugin, I have no reason to create an 
Gtk::Application-derived class/object…




___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Parsing custom-typed properties from Glade file

[Kjell Ahlstedt via gtkmm-list]

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:

    none

On 2020-07-22 07:00, Rodolfo Ribeiro Gomes via gtkmm-list wrote:

Hello, everyone.

I created a custom widget that has a Glib::Property of an enum type.
Glib::Property property_type_;

When I try to load from a glade file, I got this error message:

Gtk-WARNING **: 01:43:34.849: Failed to set property 
gtkmm__CustomObject_widget_color_slider.type to 1: Could not parse '1' 
as a glibmm__CustomBoxed_N6studio11ColorSlider4TypeE


Here is the xml property line:
            1

How can I properly parse the property tag contents ?



___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Please help

[Kjell Ahlstedt via gtkmm-list]

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 
https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/gtkmm-3-24/examples/book/menus_and_toolbars


The examples in the master branch (as opposed to the gtkmm-3-24 branch) 
are for gtkmm4, which is still very unstable, and not always fully working.


On 2020-07-22 10:27, Carlo Wood wrote:

Hi list,

for more than a week I've been trying to find a good example, but
failed.

Can someone please point me to a "hello world" example that uses
the latest gtkmm3 standards and that has a simple menu bar with
the following content:

.---
| File | Mode
.---

Where 'File' has the entries:

  Open, Save, Quit

and 'Mode' has the entries:

  'Edit position'
  'Edit game'
  --separator--
  'Show candidates'


I could explain where I all searched and what I all found and
why that doesn't explain how to do this etc, but well. All I
want is just a working example :(.

Thanks,
Carlo
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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* cobject, const 
Glib::RefPtr )

   : GtimerGui(cobject, builder)
   {
   }

I haven't tested anything like that, but I think it will work.

Kjell

On 2020-07-04 01:48, Liomar da Hora via gtkmm-list wrote:

Hello
I'm creating an app with gtkmm using Gtk :: Builder according to the 
book and I can make the app work.
I am now intending to derive this class which is already derived from 
Gtk :: ApplicationWindow.
How do I start the constructor of the base class it has 
(BaseObjectType * cobject, and const Glib :: RefPtr  & 
builder) in the derived class?


Ex:
## example.h ##

class GtimerGui : public Gtk::ApplicationWindow
{
public:
GtimerGui(BaseObjectType* cobject, const Glib::RefPtr& 
builder);

 ~GtimerGui();
Gtk::ApplicationWindow *main_window;
Glib::RefPtr sp_FileBuilder;
};

## example.cpp ##

GtimerGui::GtimerGui(BaseObjectType* cobject, const 
Glib::RefPtr )

: Gtk::ApplicationWindow(cobject), sp_FileBuilder(builder)
{
}

GtimerGui::~GtimerGui()
{
}
## Main.cpp ###

nt main (int argc, char *argv[])
{
   auto app = Gtk::Application::create (argc, argv, "liomar.org.example");
   auto refFileBuilder = Gtk::Builder::create();
   try
   {
 
refFileBuilder->add_from_file("/home/suporte/Projeto_2019/GTimer/gtimer.glade");
  }
   catch(const Glib::FileError )
   {
  std::cerr << "FileError: " << ex.what() << std::endl;

   }
   catch(const Glib::MarkupError& ex)
   {
  std::cerr << "MarkupError: " << ex.what() << std::endl;
   }
   catch(const Gtk::BuilderError& ex)
   {
  std::cerr << "BuilderError: " << ex.what() << std::endl;
   }
   GtimerGui *gtimer = nullptr;
   refFileBuilder->get_widget_derived("m_main_window", gtimer);
   if(gtimer)
   {
    app->run(*gtimer);
    }
   delete gtimer;
   return 0;
}

# Derived_Class.h #
class GtimerController : public GtimerGui
{
public:
 GtimerController();
 ~GtimerController();
};

# Derived_Class.cpp 
GtimerController::GtimerController()
{
}

GtimerController::~GtimerController()
{
}

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Update data in Gtk::ListStore

[Kjell Ahlstedt via gtkmm-list]

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 
https://gitlab.gnome.org/GNOME/gtkmm-documentation/-/tree/gtkmm-3-24/examples/book/treeview/editable_cells.

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Meson and Autotools, or only Meson?

[Kjell Ahlstedt via gtkmm-list]

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 gtkmm-3.0 can now be built with meson. If you work 
with a local git clone, you can build with meson after having pulled in 
the latest changes.The meson support is not yet included in any released 
tarballs.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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 directly 
in `main()` then things are working. At first, I thought there must be 
a `Gtk::wrap_init()` somewhere already in gtkmm but I can't find it, 
so the other possibility is maybe a build system error and a left over 
build artifact somewhere. Maybe? In any case, to summarize, my 
understanding is that:


1. I used _CLASS_GOBJECT which generates a Glib::wrap returning a 
`Glib::RefPtr` instead of _CLASS_GTKOBJECT which generates Glib::wrap 
returning a raw pointer. This may or may not have contributed to the 
particular problem, as perhaps some type/overload resolution somewhere 
depended on this. Or it was a latent error that wasn't involved in 
this particular problem.
2. Lacking a `wrap_init`, I was not calling `Glib::wrap_register`, 
which sounds like the most likely culprit
3. Even after I generated `wrap_init()`, it apparently wasn't getting 
called. Possibly due to some link-order issue or a stale build 
artifact or something.


Gtk::wrap_init() is called from Gtk::Main (deprecated) and from 
Gtk::Application.


Have you created your own Gtk::wrap_init(), containing everything the 
standard Gtk::wrap_init() contains, plus your own Glib::wrap_register() 
call? In that case I suppose there are two Gtk::wrap_init() functions, 
one in libgtkmm-3.0 and another one in your lib file. Which one will the 
linker select?


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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 command line seems to 
work, and generates a reasonable .h file.


~~~
M4PATH=/usr/lib/x86_64-linux-gnu/glibmm-2.4/proc/m4:/usr/lib/x86_64-linux-gnu/atkmm-1.6/proc/m4:/usr/lib/x86_64-linux-gnu/pangomm-1.4/proc/m4 
/usr/lib/x86_64-linux-gnu/glibmm-2.4/proc/gmmproc -I 
/usr/lib/x86_64-linux-gnu/gtkmm-3.0/proc/m4 panzoomarea mm mm

~~~

I should have realized that gmmproc must be able to find atkmm's and 
pangomm's m4 files. They are included from convert_gtkmm.m4. gmmproc 
usually works well if all its input is correct, but it's not always good 
at telling what's wrong when some input is wrong or missing.


So, now we're back at your first question: Why does the dynamic_cast to 
Gtk::PanZoomArea* fail?


You said in a previous post that you execute

   Glib::wrap_register(gtk_panzoom_area_get_type(),
   _Class::wrap_new);

That's necessary. Still it looks like Glib::wrap_auto() and 
Glib::wrap_create_new_wrapper() wrap a GtkPanZoomArea in a 
Gtk::DrawingArea. I don't understand why.


Perhaps you can double-check that Glade and GtkBuilder really give you a 
GtkPanZoomArea, and not just a GtkDrawingArea. You've said that


   GtkPanZoomArea* panzoom_ =
   GTK_PANZOOM_AREA(builder->get_object("overhead-view")->gobj());

works. I don't know if GTK_PANZOOM_AREA() checks the type, or if it just 
casts unconditionally.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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 panzoomarea mm mm


But I don't expect that to make a difference.

You can add a --debug argument to the gmmproc command. Some temporary 
files are then saved. You will probably find them in the /tmp directory.


Kjell

On 2020-05-03 02:07, Josh Bialkowski wrote:
Thanks Kjell, you have a good eye. I tried making the change to 
`_CLASS_GTKOBJECT` but I'm not sure what else needs to change. On my 
system `class_gtkobject.m4` is installed at 
`/usr/lib/x86_64-linux-gnu/gtkmm-3.0/proc/m4`, so I tried the 
following execution of gmmproc but the generated .h file is mostly empty:

~~~
M4PATH=/usr/lib/x86_64-linux-gnu/gtkmm-3.0/proc/m4:/usr/lib/x86_64-linux-gnu/glibmm-2.4/proc/m4 
/usr/lib/x86_64-linux-gnu/glibmm-2.4/proc/gmmproc -I 
/usr/lib/x86_64-linux-gnu/glibmm-2.4/proc/m4 -I 
/usr/lib/x86_64-linux-gnu/gtkmm-3.0/proc/m4 panzoomarea mm mm

~~~

The generated `panzoomarea.h` looks broken:
~~~
// Generated by gmmproc 2.56.0 -- DO NOT MODIFY!
#ifndef _TANGENT_GTKUTIL_MM_PANZOOMAREA_H
#define _TANGENT_GTKUTIL_MM_PANZOOMAREA_H


#include 
#include 

// clang-format off


// clang-format on

#include 
#include 

namespace Gtk {


#endif /* _TANGENT_GTKUTIL_MM_PANZOOMAREA_H */
~~~

here is the full `panzoomarea.hg`:
~~~
// clang-format off
_DEFS(tangent/gtkutil/mm, tangent)
_PINCLUDE(gtkmm/private/drawingarea_p.h)
_PINCLUDE(tangent/gtkutil/mm/private/hack.h)
// clang-format on

#include 
#include 

namespace Gtk {

class PanZoomArea : public Gtk::DrawingArea {
  _CLASS_GTKOBJECT(PanZoomArea, GtkPanZoomArea, GTK_PANZOOM_AREA,
                   Gtk::DrawingArea, GtkDrawingArea)

 public:
  _CTOR_DEFAULT

 public:
  // _WRAP_METHOD(void get_offset(double offset[2]), 
gtk_panzoom_area_set_offset);
  // _WRAP_METHOD(void get_offset(double offset[2]), 
gtk_panzoom_area_set_offset);


  _WRAP_METHOD(double get_scale(), gtk_panzoom_area_get_scale);
  _WRAP_METHOD(void set_scale(double scale), gtk_panzoom_area_set_scale);
  _WRAP_METHOD(double get_scale_rate(), gtk_panzoom_area_get_scale_rate);
  _WRAP_METHOD(void set_scale_rate(double rate),
               gtk_panzoom_area_set_scale_rate);

  // TODO(josh): can't wrap a signal whose default handler has a different
  // name than the name of the signal.
  _WRAP_SIGNAL(bool area_motion(GdkEventMotion* event), "area-motion");
  _WRAP_SIGNAL(bool area_button(GdkEventButton* event), "area-button");

// clang-format off
#m4 _CONVERSION(`CairoContext*',`const ::Cairo::RefPtr< 
::Cairo::Context>&',`::Cairo::RefPtr< ::Cairo::Context>(new 
::Cairo::Context($3, false /* has_reference */))')
#m4 _CONVERSION(`const ::Cairo::RefPtr< 
::Cairo::Context>&',`CairoContext*',`($3)->cobj()')
  _WRAP_SIGNAL(bool area_draw(const ::Cairo::RefPtr< 
::Cairo::Context>& cr),

               "area-draw");
  // clang-format on

  _WRAP_PROPERTY("offset-x-adjustment", Glib::RefPtr);
  _WRAP_PROPERTY("offset-y-adjustment", Glib::RefPtr);
  _WRAP_PROPERTY("scale-adjustment", Glib::RefPtr);
  _WRAP_PROPERTY("scale-rate-adjustment", Glib::RefPtr);
  _WRAP_PROPERTY("active", bool);
  _WRAP_PROPERTY("pan-button", int);
  _WRAP_PROPERTY("demo-draw-enabled", bool);
};

}  // namespace Gtk
~~~

Is there something else I need to make the `_CLASS_GTKOBJECT` macro work?

Thanks for the help,
Josh


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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 a widget.
_CLASS_GTKOBJCT() is defined in gtkmm/tools/m4/class_gtkobject.m4. You 
won't find it in glibmm.


Don't know if this is the only error.

Kjell

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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 of the dependencies 
mentionend by [1] seem not to be released yet (pangomm-2.44, 
cairomm-1.16, atkmm-2.30). Perhaps it would be necessary to build them 
from git master, but I think I read something about ABI 
incompatibility, which would make it even more complicated.


So, is it just too early to give gtkmm4 a try? If not, I would be glad 
to have something like a guide about how to get started.


(btw, a gtkmm matrix room would be great. The closest thing I found is 
a #c++ irc channel on GIMPnet. Maybe I missed something?)


Thanks a lot
Martin

[1] 
https://developer.gnome.org/gtkmm-tutorial/3.97/sec-installation-dependencies.html.en



Building gtkmm4 from released packages is almost impossible, and 
certainly not recommended. If you want to give it a try, build from git. 
I recommend that you use jhbuild. And be prepared for compilation errors 
when you come to gtkmm4. Gtk4 is constantly changing. Only rarely is 
gtkmm4 totally compatible with gtk4. See also 
https://mail.gnome.org/archives/gtkmm-list/2020-January/msg9.html. 
(The lists of latest released versions there are not quite up to date.)


Is it too early to give gtkmm4 a try? Probably, unless you can accept 
more build problems than usual. You can have a look at the example 
programs in the gtkmm-documentation module in git's master branch. They 
can give some hints as to the differences between gtkmm3 and gtkmm4.


Kjell

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: mmification of gspell

[Kjell Ahlstedt via gtkmm-list]

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 on callbacks are unfortunate, and some of the style 
strikes me as odd, but that's a great effort/start nonetheless and 
hopefully goes on.




Interesting. I didn't know about this cppgir.

When I mentioned gobject-introspection in a previous post, I was 
thinking about the mkolny/use-mmgirgenerator branch in glibmm's git 
repo. Now I've looked a bit deeper into it, and Marcin Kolny's 
mmgirgenerator is less ambitious than cppgir. It's an alternative way of 
generating the .defs files that gmmproc uses. See 
https://github.com/loganek/mmgirgenerator.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: mmification of gspell

[Kjell Ahlstedt via gtkmm-list]

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 code, instead of generating it
from gobject-introspection like in other languages, is there any reason
for that?
I don't know for sure, but I think gobject-introspection did not exist 
when glibmm and friends were first created. Then no one has taken the 
time to learn gobject-introspection and to convert everything. I think 
there once was an attempt to generate glibmm from gobject-introspection, 
but it was not finished.

I’d be interested in creating such a library if no one else already has
something, do you have any pointer for where to start from?  The API
surface is small enough I could do it from scratch, but it would most
likely integrate better taking your advices. :)

Thanks!

[1] https://inkscape.org/
[2] https://gitlab.com/inkscape/inkscape/-/merge_requests/1756
[3] https://wiki.gnome.org/Projects/gspell


There are some instructions in the gtkmm tutorial, appendix G: 
https://developer.gnome.org/gtkmm-tutorial/stable/chapter-wrapping-c-libraries.html.en. 
It's not completely up-to-date. It assumes that you will build with 
Autotools. I suppose you prefer Meson.


mm-common contains the skeletonmm directory with files you can start 
with. The skeletonmm project contains files for building with Meson. If 
you decide to use it, I recommend that you clone mm-common from the git 
repo with the latest commits.



___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Meson and Autotools, or only Meson?

[Kjell Ahlstedt via gtkmm-list]

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 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.
I have changed the default warning level to /min/, except when a tarball 
is created and tested. (/ninja dist/ corresponds to /make distcheck/.) 
That's how autotools builds work.



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.


Other comments have made me believe that we ought to keep the autotools 
support until most common distros contain mm-common 1.0.0 or higher. 
(Building with meson in maintainer mode requires mm-common >= 1.0.0.)
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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 

https://developer.gnome.org/gtkmm-tutorial/stable/chapter-keyboardevents.html.en 




You shall set the 'after' parameter to false in the call the connect().
https://developer.gnome.org/glibmm/stable/classGlib_1_1SignalProxy.html#a0bee9dba36374339ab19ec34f288613e 






Yes, I know that this can happen and set my handlers now "before" the
others. What makes me wonder is that it looks that the default handler
has changed behavior. Or had I myself programmed some unlucky side
effects? :-)

Thanks for your detailed answer/link list!

Regards
 Klaus


Almost all default handling of signals is done in gtk, not in gtkmm. If 
something has changed, the change is probably in gtk. In order to find 
out what has changed, you need to know which version of gtk you used 
before, and which version you use now. And also which type of widget you 
see the change in. Different widgets can of course handle signals 
differently.


This is a kind of change that can very well happen from one release to 
the next, at least if the minor version number has changed. (Example: 
some_pkg 2.14.1: 2 = major, 14 = minor, 1 = micro version number)


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Determining widget type

[Kjell Ahlstedt via gtkmm-list]

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 fails: Gtk-CRITICAL: 08:51:12.080: gtk_label_get_label: 
assertion 'GTK_IS_LABEL (label)' failed


So the primary message widget isn't a Gtk::Label. How do I determine 
what it is?



Is your dialog a MessageDialog? If it is, use get_message_area() instead 
of get_content_area().

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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 retval = Gtk::Window::on_key_press_event( event );
    std::cout << "Retval from native win function:" << retval <<
std::endl;

    return false;
    }
};

As we see, if cursor keys are going into the function, retval is true
which stops following handlers to see the keys.

Every handler which was introduced with
"win.signal_key_press_event().connect" will not any longer executed.

That Gtk::Window "eats" the cursor keys is new. Compiled the same
program some weeks ago the cursor keys where also present in the later
on dynamically registered handlers.

OK, can workaround by simply overriding all the window handlers...

Regards
 Klaus


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
https://developer.gnome.org/gtkmm-tutorial/stable/chapter-keyboardevents.html.en 



You shall set the 'after' parameter to false in the call the connect().
https://developer.gnome.org/glibmm/stable/classGlib_1_1SignalProxy.html#a0bee9dba36374339ab19ec34f288613e

Kjell

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: mm-common and mm-common-get

[Kjell Ahlstedt via gtkmm-list]

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
debian:sid(https://packages.debian.org/sid/all/mm-common/filelist),
ubuntu:devel(https://packages.ubuntu.com/focal/all/mm-common/filelist)
and
fedora(
https://fedora.pkgs.org/31/fedora-armhfp/mm-common-0.9.12-4.fc31.noarch.rpm.html
)

I am trying to use a  docker image and the image has no mm-common-get.
Meson aborts because it can't find the script. Are you aware about
this? I file a bug report to debian. May be they know something.

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Meson and Autotools, or only Meson?

[Kjell Ahlstedt via gtkmm-list]

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 mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Meson and Autotools, or only Meson?

[Kjell Ahlstedt via gtkmm-list]

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. 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.
You're right. I haven't thought of that, I must confess. In Autotools 
builds the default value is 'min'. What do you say about default value 
'max'? That will enable the same warnings as 'fatal', but the warnings 
will not be treated as errors.

  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.

We can keep the Autotools support until cairomm, atkmm and gtkmm have 
got Meson support.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Meson and Autotools, or only Meson?

[Kjell Ahlstedt via gtkmm-list]

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-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?



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. 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.


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Meson and Autotools, or only Meson?

[Kjell Ahlstedt via gtkmm-list]

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-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.

How about ninja dist?
https://mesonbuild.com/Creating-releases.html

Yes, what about ninja dist? What do you mean? It should work with the 
listed packages. Have you found that it doesn't? Or is your question a 
way of saying that I should have used ninja dist instead of make 
distcheck in recent releases?


Kjell

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: goocanvasmm and gtkmm4

[Kjell Ahlstedt via gtkmm-list]

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 time. Gtk4 is still changing rapidly. I'm trying to 
keep gtkmm4 updated to fit with the latest changes in gtk4, but I only 
rarely succeed. My guess is that goocanvasmm-3 will need an extensive 
update.


Kjell

On 2020-03-04 20:44, Klaus Rudolph wrote:

I see in the mailing list that gtkmm4 is coming... :-)

Will goocanvasmm-2 also work with upcoming gtkmm4? Maybe is there a new
release like goocanvasmm-3? Can anyone test if it still compiles within
gtkmm4.

Regards
 Klaus
___


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: how to get key press event in goocanvasmm

[Kjell Ahlstedt via gtkmm-list]

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 does not handle the signal. If the child handles the 
signal, and returns /true/ from its signal handler, there's no hope for you.


You can read about event signals in the gtkmm tutorial, 
https://developer.gnome.org/gtkmm-tutorial/stable/chapter-keyboardevents.html.en 
and 
https://developer.gnome.org/gtkmm-tutorial/stable/sec-xeventsignals.html.en


If on_key_press_event() is not called there's another possibility. 
Instead of overriding the default signal handler, connect another signal 
handler. (It won't do any difference if one of m_canvas's children 
handles the signal.)


bool on_canvas_key_press_event(GdkEventKey* event)
{ ... }
MyCanvas()
{
  signal_key_press_event().connect(sigc::mem_fun(*this, 
::on_canvas_key_press_event), false);

}

Note /false/ in connect().

I recommend that you replace Gtk::Main by Gtk::Application, unless you 
use a very old version of gtkmm. Gtk::Main has been deprecated since 2012.


/Kjell

On 2020-02-14 18:51, Klaus Rudolph wrote:

Is it possible to receive key press events in canvas?

The following signal handler is not called inside goocanvas. It compiles fine 
but it is not called if a key is pressed.


Exmaple:


Glib::RefPtr root;

class MyCanvas: public Goocanvas::Canvas
{
 double scale = 1;

 bool on_key_press_event( GdkEventKey* event ) override
 {
 std::cout << "on_key_press_event" << std::endl;
 return true;
 }

};

int main(int argc, char* argv[])
{
 Gtk::Main app(, );
 Goocanvas::init("example", "0.1", argc, argv);

 Gtk::Window win;

 MyCanvas m_canvas;
 m_canvas.set_size_request(640, 480);
 m_canvas.set_bounds(0, 0, 800, 800);
 root = m_canvas.get_root_item();

 //

 Glib::RefPtr outer = Goocanvas::Ellipse::create( 
100,100,20,20);
 outer->property_line_width() = 5;
 outer->property_stroke_color() = "red";
 outer->property_fill_color()="blue";
 root->add_child( outer );

 win.add( m_canvas);
 win.show_all_children();


 Gtk::Main::run(win);
 return 0;
}
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

gtk4 and gtkmm-4.0

[Kjell Ahlstedt via gtkmm-list]

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 packages from the unstable series, and been totally confused. No 
wonder, the situation /is/ confusing.


The stable series:
_pkg-config mod-name__Latest released version__Git branch_
sigc++-2.0    2.10.2 libsigc++-2-10
cairomm-1.0   1.13.1   cairomm-1-14
glibmm-2.4    2.62.0   glibmm-2-62
pangomm-1.4   2.42.0   pangomm-2-42
atkmm-1.6 2.28.0   atkmm-2-28
gtkmm-3.0 3.24.2   gtkmm-3-24

Packages from these series are compatible with gtk+-3.0. Apart from 
cairomm-1.0, they have even minor version numbers.


The unstable series, which has caused so much confusion, is (sometimes) 
compatible with gtk4, which is still very unstable. Both ABI and API are 
constantly changing. Classes and functions can be deleted or modified.


The unstable series:
_pkg-config mod-name__Latest released version__Git branch__Tarball 
compatibility_

sigc++-3.0    3.0.2 (stable)   master
cairomm-1.16  1.15.5   master
glibmm-2.60   2.59.1   master
glibmm-2.62   2.61.1   master
glibmm-2.64   2.63.1   master
pangomm-2.44  2.43.1   master    glibmm 2.59.1
atkmm-2.30    2.29.1   master glibmm 2.59.1
gtkmm-4.0 3.95.1   master glibmm 2.61.1, 
gtk4 3.96.0


The NEWS files of the unstable releases contain the sentence: /Distro 
packagers should probably not package this yet./ The only reason I can 
see to use these unstable versions now is if you want to prepare for 
using gtk4 and gtkmm-4.0. And then you're better off if you build from 
the tips of the master branches in the git repo. It's difficult or 
impossible to find tarballs of all these packages that can be used 
together with each other and with a gtk4 tarball.


What makes these unstable versions so confusing is probably that 
cairomm, glibmm, pangomm and atkmm break ABI without increasing the 
major version number. That's because the underlying C packages, cairo, 
glib, pango and atk, do not break ABI.


Kjell Ahlstedt

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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
ExampleApplication::create_window() and
ExampleApplication::on_window_hide().


Thanks Kjell!

What I see is, that the hide signal is delegated to some "other"
instance which calls the delete.


window->signal_hide().connect(sigc::bind(sigc::mem_fun(*this, 


    ::on_window_hide), window));

 void ExampleApplication::on_window_hide(Gtk::Window* window) {
delete window; }

My question still is: Is it safe to delete the "own" window the the
"own" signal handler and which signal handler is best to use for the
call to delete. Is it either on_hide() or on_delete_event( 
GdkEventAny* );


Thanks!
 Klaus


I haven't tested, but I think you can override on_hide() and/or 
on_delete_event() and "delete this;" there. Which one is called might 
depend on how the window is hidden. on_hide() is called if the window is 
hidden by pressing a button that calls hide(). I'm uncertain which 
function is called if the window is closed by pressing the icon with a 
cross, usually in the upper right-hand corner of the window.


Kjell


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Kjell Ahlstedt via gtkmm-list]

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, Klaus Rudolph wrote:

Hi Daniel,



anyway, if you need to, if you new a window somewhere, then you can
connect to its ::delete-event and delete there via a captured pointer,
being sure to return true so GTK does not then try to do anything with
the dead win.


OK, but no need to capture it as it is "this" in that case or I am wrong?





free(this) is so wildly wrong.


Yea!!! :-) Don't programmed in C for many years. No idea why I put
that to the sample as a comment...


delete(this) would also be wrong: in the dtor because it would
cause an infinite loop...


But it is not the dtor, it is in the sig handler for the delete event.
Is that the safe way?

Regards
 Klaus


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: custom TreeModel

[Kjell Ahlstedt via gtkmm-list]

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 your result data 
structure and not by duplicating the nodes in the treeview itself. 
What if the input-output schema of your library is fixed? or suppose 
that you're porting it to gtk as an alternative to another gui? People 
will struggle with linking their library to the gtk treeview; or in 
any case I certainly had a hard time finding out how to get this 
working. Yes, this way of adressing the data certainly is complicated, 
but that makes an example all the more welcome, no? There is no way 
around this kind of custom code, if you want to avoid duplicating your 
data, or if your data is constantly changing, for instance.


I also tend to get lost in the documentation for gtk(mm), and for 
instance I just did not notice the examples in 
gtkmm-documentation/examples/book/custom/custom_treemodel . So an 
additional example in the gtkmm/demos does not look superfluous to me.


On the other hand, I don't want to impose, and if you feel there is no 
place for my example in the gtkmm demos, then so be it. People really 
desperate for an example will now find it in the mailinglist at 
"/Date/: Mon, 16 Dec 2019 23:10:45 +0100", I guess...


happy new year,
Danny.

-Original Message-

*Date*: Mon, 23 Dec 2019 13:23:20 +0100
*Subject*: Re: custom TreeModel
*Cc*: gtkmm-list@gnome.org 
*To*: danny >
*From*: Kjell Ahlstedt >


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 more interfaces 
quite unusual? And a bit more complicated than most of the demos? 
There is no corresponding program in gtk/demos. All existing C++ demos 
in gtkmm correspond to C demos in gtk.


Kjell


___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: custom TreeModel

[Kjell Ahlstedt via gtkmm-list]

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 more interfaces 
quite unusual? And a bit more complicated than most of the demos? There 
is no corresponding program in gtk/demos. All existing C++ demos in 
gtkmm correspond to C demos in gtk.


Kjell

On 2019-12-22 11:06, danny via gtkmm-list wrote:

hello gtkmm,

so how do I continue with this? I feel that it would be really handy 
to add an example such as the one below to the gtkmm demos subdir.


I was struggling with this myself some years ago for a gtk2 program 
where the data were already established (and constantly changing) 
outside the gui in a separate structure.


Copying the data into the treeview model, as the existing demo 
programs do, is obviously not the ideal solution.


the other example in gtkmm-documentation 
 
keeps is very helpful, but it does not show subdirs...


regards, Danny.

On Mon, Dec 16, 2019 at 2:10 PM danny via gtkmm-list 
mailto:gtkmm-list@gnome.org>> wrote:

hi

well, actually, I did not find the example you are referring to. I 
probably did when I was working with the original gtk2 program, though.


so I have come up with this:
(gtkmm-3.22.3/demos)

--
/* Tree View/Tree Store
 *
 * The GtkTreeStore is used to store data in tree form, to be
 * used later on by a GtkTreeView to display it. This demo builds
 * a simple list of nodes in memory and displays it in the GtkTreeStore.
 *
 */

...
--

I'm not sure, though, if I really understand the purpose of
virtual bool Gtk::TreeModel::iter_parent_vfunc  (   


this function finds a parent for the given child, right? but why 
would that be needed, if a child can only be arrived at from a parent 
node in the first place?


regards, Danny.




___
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

Re: custom TreeModel

[Kjell Ahlstedt via gtkmm-list]

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 
https://gitlab.gnome.org/GNOME/gtkmm-documentation/tree/gtkmm-3-24/examples/others/treemodelcustom 
? I don't know if it's a good example. Most programs under the 
examples/others directory are not maintained.


Kjell

On 2019-12-12 09:37, danny via gtkmm-list wrote:


indeed! that seems to get me on my way! thanks!

if/when I get this working: would you be interested in adding this to 
the gtkmm demo programs?


regards, D.

 *



___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list