Re: Alternative to sigc::mem_fun

I still don't see the problem. There is an overload that takes a reference instead and should be in each case. So, for *sigc::mem_fun * *(* *T_obj * * *_A_obj*, *T_return(T_obj2::*)(T_arg1, T_arg2) * *_A_func* *)* you should substitute *sigc::mem_fun * *(* *T_obj & * *_A_obj*,

Re: Capturing modifier keys in a TextBuffer

The glibmm SignalProxy takes a 2nd argument indicating whether to connect after, which defaults to true https://developer.gnome.org/glibmm/2.52/classGlib_1_1SignalProxy.html#a0bee9dba36374339ab19ec34f288613e ___ gtkmm-list mailing list

Re: Alternative to sigc::mem_fun

On 19 June 2018 at 13:58, Compro Prasad via gtkmm-list wrote: > The doc of sigc::mem_fun suggest to use something else which takes > arguments as reference instead of pointer and also mem_fun is > deprecated. > A link to the docs you're referring to would be useful. By my reading, it <

Re: Alternative to sigc::mem_fun

> The poster is confusing sigc::mem_fun() with std::mem_fun(). How do you know? Everything seems like a delberate reference to the sigc:: template so far, just missing the availability of the other overload. For posterity, I'll point out that the sigc:: one can't always be replaced by some other

Re: Cells height problem

That may be related to https://gitlab.gnome.org/GNOME/gtk/issues/12 ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Capturing modifier keys in a TextBuffer

Not sure, but I think that is the wrong question, since I would imagine the textbuffer should only care about what text is in it, not how the text got there. What widget are you using with the text buffer? Probably you should check the keyboard state there instead.

Re: Capturing modifier keys in a TextBuffer

On 22 June 2018 at 14:43, Daniel Boles wrote: > hmm, you might need to connect before the default handler if you didn't > already, to intercept the state, then return false so it can carry on doing > what it normally does. > I should clarify that I didn't really think about whether that's the

Re: Capturing modifier keys in a TextBuffer

hmm, you might need to connect before the default handler if you didn't already, to intercept the state, then return false so it can carry on doing what it normally does. ___ gtkmm-list mailing list gtkmm-list@gnome.org

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

On Wed, 24 Oct 2018 at 16:11, Kjell Ahlstedt wrote: > It will take a several days, or even a few weeks before I get to > releasing gtkmm. I'll start with its dependencies (libsigc++, glibmm, > pangomm, atkmm). > I raised an MR on GitLab for a few cleanups and an improved test of Glib::ustring

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

If we agree to merge Gtk::make_managed(), then the patch I have in an MR on GitLab will make gtkmm-documentation 3.24 more interesting, as it includes updates about that! Based on what you said on GitLab, I guess you're happy to merge those, but I'd like to get feedback on the documentation MR

Re: Dead links to documentation

Yes, clearly the new releases of 3.22 and/or 3.24 just suffer from the same problem (3.22 does not work, and stable is either that or 3.24), and it's going to keep happening and become more of a problem until someone fixes it. Either way, there is a bug for it (see below), and unfortunately all of

Re: how to make comboboxes not to respond to mouse wheel up and down

Probably you should connect to .signal_scroll_event() before the default handler and return TRUE to stop it from being called. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: how to make comboboxes not to respond to mouse wheel up and down

...which is because the events are really received by the Button internal to the ComboBox, which you don't have access to, not the outer ComboBox itself, which is just a passive Bin. ___ gtkmm-list mailing list gtkmm-list@gnome.org

Re: changing cursor

Why not show what you tried... On Fri, 11 Jan 2019 at 02:30, Marty Moore wrote: > Hi All, > > I'm stuck trying to: > > a. change the cursor. > > b. trying to change cursor size. > > I can change the cursor using a mix of gdk3 and gdkmm code, but it's > messy. What is the proper way to change

Re: changing cursor

On Fri, 11 Jan 2019 at 21:28, Marty Moore wrote: > // the following code workds > guint *w, *h; > Glib::RefPtr display = > GLW->get_display(); > Glib::RefPtr win = > GLW->get_window(); > > Glib::RefPtr cursor = > Gdk::Cursor::create(display,

Re: Change application theme

Look at documentation for Gtk::Settings and its properties :gtk-theme-name and :gtk-prefer-dark-theme, and try using them to set the win32 theme. You may find it's unmaintained and buggy though. You can do custom theming; search for Gtk::StyleContext, Gtk::CssProvider, etc.

Re: Sockets (Client/Server)

I'd also point out that Gtk::Socket and ::Plug are deprecated in GTK 3 and removed in GTK 4, so probably no one should start writing new code with them, unless completely unavoidable. X11 programs poking at each other's windows and whatnot is not a future-proof way to do things, hence the removal.

Re: Unable to pass additional argument to signal handling function

On Tue, 19 Feb 2019 at 08:42, Kjell Ahlstedt via gtkmm-list < gtkmm-list@gnome.org> wrote: > If you want to pass a widget to a signal handler, I suggest you pass a widget > pointer. > > I'm curious why? Other than, I guess, that being more familiar than std::reference_wrapper, but I find the

Re: Unable to pass additional argument to signal handling function

On Thu, 21 Feb 2019 at 19:24, Радомир Хаџић wrote: > 2019-02-18 15:15 GMT+01:00, Daniel Boles via gtkmm-list < > gtkmm-list@gnome.org>: > >> The error I'm getting is that there is no such function. > > > > About which function? Anyway, please show all the code. A

Re: Unable to pass additional argument to signal handling function

I also suspect you'll need to pass that as std::ref(*this), otherwise I think sigc++ will assume you want a copy, which is unlikely to end well. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Unable to pass additional argument to signal handling function

> The error I'm getting is that there is no such function. About which function? Anyway, please show all the code. As written, you haven't proven that the function *does* exist! And the code you posted doesn't match any in the link you showed. ___

Re: API-Reference is missing

This is already reported at https://gitlab.gnome.org/Infrastructure/library-web/issues/12 (among 10s of other duplicates in an issue list that it seems no one is maintaining) ___ gtkmm-list mailing list gtkmm-list@gnome.org

Re: API-Reference is missing

Btw, if anyone in this latest thread doesn't know yet, you can substitute 3.20 into the URLs for documentation pointing at 3.22/3.24/stable and usually set something that's *almost* relevant, although 3.20 is increasingly old. Failing that, hopefully your package manage installed the

Re: Pixel size of primary monitor?

On Wed, 13 Feb 2019 at 14:55, Peter Weber via gtkmm-list < gtkmm-list@gnome.org> wrote: > Glib::RefPtr primary_monitor = > window->get_screen()->get_display()->get_primary_monitor(); > if (primary_monitor) { > Gdk::Rectangle monitor_size; > primary_monitor->get_geometry(monitor_size); >

Re: Removing text from ComboBoxText

...and if you aren't confident enough to debug, the way to get help is to provide a minimal test case that reproduces the problem, so that others can try to do that for you. Anyway, it looks like gtkmm is behaving just fine here, so I suspect something is going on between your callback and the

Re: Gtk::Switch problem, not being able to handle the signal state_set

You're welcome! I hadn't consciously realised GtkSwitch had both :active and :state to be honest. The latter is for delayed state changes, so if you just need a simple switch, you should be able to leave the ::state-set handler alone and observe changes on either of those properties, because they

Re: Cross-coupling comboboxes

>>> *Now, using the TreeModel and passing iterators, I get a shed load of Gtk-CRITICAL **: 12:24:08.859: gtk_tree_store_get_path: assertion 'iter->user_data != NULL' failed interspersed with my own debug report of invalid iters passed to on_combo_changed() I don't think this is connected

Re: Cross-coupling comboboxes

It's not particularly clear what's going on. Posting the minimal code required to reproduce this on a pastebin and linking it would be great. Are you taking an iterator into the model, then clearing the model, then trying to use the former iterator again? That definitely won't end well, I don't

Re: Cross-coupling comboboxes

> What appears to happen, which I wasn't expecting, is the m_refTreeModel->clear(); call invokes the combobox signal_changed handler for every row? yeah, gtk_combo_box_model_row_deleted() does that if the reference to the previous active_row is now invalid, and i presume sets the active model to

Re: Cross-coupling comboboxes

> There may be a better fix. It would be nice if calling clear() on the > model didn't invoke the signal_changed of BOTH comboboxes 328 times each Blocking the signal is another way to do it. That may or may not have any quantitative difference in speed (from sigc not having to call your

Re: Cross-coupling comboboxes

> AFAICT the "blocking" has to be > applied per-signal, so I need to keep track of all the connection > instances for all the comboboxes, yes? Yeah, I often forget that glibmm/gtkmm use Glib::SignalProxy rather than sigc::signal. The former will need you to retain and un/block the individual

Re: Removing text from ComboBoxText

The sure fire way to figure out what is going on is always to make complete use of the debugger, i.e. in this case to get and analyse a backtrace. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Removing text from ComboBoxText

so do a backtrace and see where that null string is coming from. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Removing text from ComboBoxText

Yes, it simply not valid to construct an std::string, and hence nor a Glib::ustring, from a nullptr. So if any code in gtkmm is not converting a C nullptr string to a C++ "", that's a bug. > Returns the currently active string in *combo_box*, or nullptr if none is selected. Saying nullptr in

Re: Removing text from ComboBoxText

> Sometimes it works just fine, but when i restart my application and try again it fails ! so check the value of `index` in all cases, and tell us what those values are. Maybe it's -1 when this fails and remove_text() might not handle that (I didn't check the GTK code). Or just use a debugger and

Re: Gtk::Switch problem, not being able to handle the signal state_set

*your* signal handler might not fire, because you're connecting after the default handler (vfunc), which probably returns true to block any further handlers. if you pass false for the after argument of Signal.connect(), your handler will probably get called. but it still won't be the right

Re: Gtk::Switch problem, not being able to handle the signal state_set

from the doc: "The signal_state_set() signal on GtkSwitch is emitted to change the underlying state. It is emitted when the user changes the switch position. The default handler keeps the state in

Re: Cross-coupling comboboxes

>>> This is implemented by calling the set_active with the result of get_active_row_number. Because the content of those combo boxes has got rather voluminous, I now want to convert them to hierarchical. So the ...Text version is no good and I'm using a ComboBox with a TreeStore behind it. The

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

Thanks for testing it anyway! I wondered also if one could register properties in ExtraClassInit, but delay applying until them wrapping with wrap_new()*, i.e. have C++ actually reflect whatever values were set... but that seems like it might be too much work, even if possible. ( * if I

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

Short of having to write an underlying class in C, is there any way to have custom derived widgets with custom Glib::Property, and set those custom properties through a Gtk::Builder .ui? Presuming the answer is no, because the properties are only registered with GType when the instance is

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

I *feel* like I already tried that, since it was the easy route: - installing properties in C++ instance constructor, - constructing a dummy instance to register the type, and then - loading from a Builder .ui ...and got an error something like > Invalid property ID 1 for

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

So far the only thing I've managed to get working is to use ExtraClassInit to do all the property installation and get/set handling in C... looking a bit like this, assuming a derived GtkButton called Button2, with a new property called :style-class. I think the crux of the problem is 2fold: *

Re: the Example in section "Glade and Gtk::Builder"

I don't know where you were looking exactly, but the HTML documentation as currently available on developer.gnome.org has a link titled Source Code that goes here: https://gitlab.gnome.org/GNOME/gtkmm-documentation/tree/gtkmm-3-24/examples/book/builder/basic and basic.glade is present therein.

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

for posterity, it looks like someone else has had the same questions but didn't get much further: https://mail.gnome.org/archives/gtkmm-list/2010-April/msg00095.html >>> First is that before I load the glade file I have to call the constructor by creating an object of my problematic custom

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

> for posterity, it looks like someone else has had the same questions but didn't get much further: That user was also using wrap_register() to have code called when glibmm wraps the C instances. I know next to nothing about that - but I wonder if it's at all possible that it could be used with

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

On Mon, 10 Jun 2019 at 15:52, Kjell Ahlstedt wrote: > On 6/10/19 10:25 AM, Daniel Boles via gtkmm-list wrote: > > Do you think it would be possible, or worth thinking about, to add ways > to do this > > It's probably possible, but I don't know how difficult it will be. I

Re: Disabling right-click behaviour of SpinButton

not sure of the finer details in GTK 2, but you can certainly try connecting a signal handler to button presses, before the default handler, then do nothing and return TRUE if it's a right-click to disable this feature (which i didn't even know about to be honest...) that would knock out the

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

Thanks for the thoughts! I've written it all up as an Issue on GitLab for consideration: https://gitlab.gnome.org/GNOME/gtkmm/issues/49 ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

Well, calling into the underlying C is always an option until gtkmm/glibmm supports what you want. However, for someone using gtkmm, it's not a preferred one, nor is it necessarily practical depending on what you're doing. That said, I've never found anything bad enough to want to switch to Qt.

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

I have a small widget that can be a drag/drop source/sink. When it's dragged, I want it to be the drag-icon, so you can see that you're dragging that particular widget (and its particular label, etc.) However, Gtk::Widget::draw(Cairo::RefPtr const&) is protected in gtkmm, so it seems that in

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

On Mon, 10 Jun 2019 at 08:44, Kjell Ahlstedt wrote: > On 6/9/19 11:04 AM, Daniel Boles via gtkmm-list wrote: > > Short of having to write an underlying class in C, is there any way to > > have custom derived widgets with custom Glib::Property, and set those > > custom pro

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

A related question here is: How can we ensure the derived type is registered with GObject before GtkBuilder would need it? Will a simple g_type_ensure( g_type_from_name("gtkmm__Custom_Whatever") ) work? I imagine not, as the GObject class won't exist until C++ constructs the first instance, right?

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

That all looks incredible! Thanks so much for putting all that work in - hugely appreciated. Does "Using derived widgets" in the doc book need updated here too? I didn't see it being amended. Right now it says: > Of course you won't see the exact appearance and properties of your derived widget

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

I'll at least go to the gtkmm-documentation directory and see whether inspiration hits. :-) You're probably right about it being new and for the next minor release only. I guess fewer users would like to depend on a point release within 2.60 anyway, when it's much easier to say just 'at least

Re: Changing gtkmm application theme

and property_gtk_application_prefer_dark_theme() I could've sworn I saw this 2 weeks ago. Maybe I'm precognitive now! On Tue, 16 Apr 2019 at 17:52, Phil Wolff via gtkmm-list < gtkmm-list@gnome.org> wrote: > Have a look at Gtk::Settings, specifically > Gtk::Settings::property_gtk_theme_name().

Re: changing the content of a model/view/store at run time

if you think you have to use c api, you're almost certainlt doing it wrong. why? does the c++ wrapper not provide remove() ? On Sat, 10 Aug 2019, 16:28 pcr, wrote: > I have changed from a tree store to a list store now, and I have working > code, except for the last line in this call back used

Re: changing the content of a model/view/store at run time

also, check whether removing invalidates iterators, in which case you cant just iterate naively like that but would need to get a valid iterator back from the erase call, as iirc someone already indicated earlier On Sat, 10 Aug 2019, 16:30 Daniel Boles, wrote: > if you think you have to use c

Fwd: Debugging widgets

-- Forwarded message - From: Daniel Boles Date: Wed, 18 Sep 2019, 20:48 Subject: Re: Debugging widgets To: sounds like you just never initialised gtk via an application or gtk_init() On Wed, 18 Sep 2019, 20:45 Pavlo Solntsev via gtkmm-list, < gtkmm-list@gnome.org> wrote: >

Re: Overloading mouse events in a ProgressBar

yup, that sounds about right. only in GTK 4 will that change and all widgets be able to receive all events. ...although also there, it is encouraged more to use gestures and whatnot, and the events that remain have proper API instead of poking around directly in event structures. On Wed, 7 Aug

Re: Trapping Glib critical error messages

run with G_DEBUG=fatal-criticals or -warnings or etc to taste On Wed, 7 Aug 2019, 23:50 Phil Wolff via gtkmm-list, wrote: > GLib-GObject-CRITICAL **: 15:30:09.453: g_object_unref: assertion > 'G_IS_OBJECT (object)' failed > GLib-GIO-CRITICAL **: 15:30:09.453: >

Re: "Need placeholders to add children" Error

You need to provide more info than that, like which versions of gtkmm and WebKit being used. To me this sounds like you are using gtkmm master, based on GTK master i.e. GTK 4, instead of gtkmm-3 based on GTK 3. Which you probably don't want at this point.

Re: Debugging widgets

Hi Pavlo, On Thu, 19 Sep 2019 at 04:26, wrote: > Thanks Daniel for the tip. > I tried gtk_init() but it looks like it is not enough for mm version. > Right, I was half awake, and really meant Gtk::Main::init() or whatever the mm wrapping of that C function is. However, using a

Re: Gtk::GLArea throws "Couldn't find current GLX or EGL context.\n"' on unrealizing

If so, that needs reported on the GTK bug tracker, not the gtkmm mailing list. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::GLArea throws "Couldn't find current GLX or EGL context.\n"' on unrealizing

Thanks for posting the solution. If the demo as written in the gtkmm repo is crashing, please file a bug on the gtkmm repo with all the relevant info from this thread. Likewise if you have modified the code but all signs are that it should still work.

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

I suspect this might have been asked and discredited already, so if it has, apologies and link me :) In gtk/src/widget.hg we have: ``` _WRAP_METHOD(Glib::RefPtr get_style_context(), gtk_widget_get_style_context, refreturn) _WRAP_METHOD(Glib::RefPtr get_style_context() const,

Re: custom TreeModel

please show the rest of the class declaration, including what/how it inherits, and how you instantiate it. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Fwd: Unable to set background color for button

-- Forwarded message - From: Daniel Boles Date: Wed, 4 Mar 2020, 18:27 Subject: Re: Unable to set background color for button To: Klaus Rudolph that is another typical 'gotcha'. you need to unset the background-image, or just set the shorthand background property instead of

Re: Unable to set background color for button

On Wed, 4 Mar 2020, 18:35 Klaus Rudolph, wrote: > > > > see C GTK docs for CSS node/class info. i can't recall whether gtkmm's > > doc conversion preserves that section. > > Can you point me to the docs? I searched a lot but did not find it. > just search for the C class name, e.g. *GtkButton*

Re: Unable to set background color for button

search for *gtk css properties* and gtk* css overview* and you will find the general stuff. these are also in the installed documentation with the lib. then if you think there are gaps there, chances are it will be documented for CSS generally and not specific to GTK. individual widgets are not

Re: Unable to set background color for button

yes they do: """ Deprecated: 3.16: This function is not useful in the context of CSS-based rendering. If you wish to change the way a widget renders its background you should use a custom CSS style, through an application-specific Gtk::StyleProvider

Re: Unable to set background color for button

gotchas will probably be found by checking what the default theme does. that'll be gtk/themes/Adwaita/_common.scss in the Git repository. you can either work with/over those, or if you really wanted just write your own theme... or unset props for entire widgets before theming them. it's probably

Re: goocanvasmm and gtkmm4

the point is that more volunteers or paid devs are needed to keep these things up to date. the surest way to make it usable is to contribute. anyway, gtk and gtkmm 3 won't be goint anywhere for a while. gimp hasnt even moved to 3 yet. so there is absolutely no need or imho point in rushing to 4.

Re: Fetching gtkmm custom css style properties

color is a normal css property, not a widget style property. use the right api for that. there is get_property() and iirc maybe even get_color(). don't use widget style properties in new code because they are removed in gtk 4. ___ gtkmm-list mailing

Re: Fetching gtkmm custom css style properties

-- Forwarded message - From: Daniel Boles Date: Wed, 19 Feb 2020, 10:31 Subject: Re: Fetching gtkmm custom css style properties To: Mohith Manoj Oh, sorry. What you want is not Object.get_property but rather StyleContext.get, but the latter is not wrapped in gtkmm yet. So you

Re: Fetching gtkmm custom css style properties

you can just type any property name though. the argument is just a string. the symbols in the header are just macros and not exhaustive. glad to help. have fun! On Wed, 19 Feb 2020, 11:23 Mohith Manoj via gtkmm-list, < gtkmm-list@gnome.org> wrote: > viola... that gets the wheel rolling. > >

Re: Fetching gtkmm custom css style properties

in the example code. But to > get a property like 'border-top-left-radius' or 'border-right-color' there > is no direct API and we are dependent on something like > Gtk::StyleContext::get_style_property, but since this doesn't work we have > our hunting hat on. > > On Wed, Feb 19, 20

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

-- Forwarded message - From: Daniel Boles Date: Fri, 3 Jan 2020, 20:17 Subject: Re: Where to free dynamic allocated widgets, generated within signal handlers To: Klaus Rudolph it's not clear to me why the destructor would not be called in your example. i didn't test it.

Re: Gtk::Orientable

in gtkmm 3, Gtk::SpinButton does not implement Gtk::Orientable, and cannot because adding that would break ABI in a stable release. so, you must do this by calling the C API yourself. that should be wrapped behind type-safe helper functions. here is a working example (C++17, but that isn't

Re: Glib::Property and read / write settings

I would first make your property member a Glib::Property_ReadOnly so that errors are caught at compile time by C++. I don't know whether maybe it ignores the Glib::PARAM flags or overrides them. Yes, GLib emits ::notify with the property name as the detail, e.g. notify::my-new-prop. However, I

Re: Glib::Property and read / write settings

Re others writing your property: (a) how is it declared and (b) how are they accessing it. Just showing its constructor call is not enough. Re notification, use .signal_changed(). iirc you might need to make a PropertyProxy from the property and then call it on that.

Re: mmification of gspell

On Thu, 16 Apr 2020, 04:18 Pavlo Solntsev via gtkmm-list, < 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

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

should test whether this is gtkmm specific or occurs in base GTK, and if the latter then open an issue on their GitLab ___ 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

How does your generated constructor look? Does it register the new type with GObject? ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

-- Forwarded message - From: Daniel Boles Date: Fri, 1 May 2020, 22:31 Subject: Re: Cannot `dynamic_cast` custom wrapped widget from Gtk::Builder To: Josh Bialkowski On Fri, 1 May 2020, 22:29 Josh Bialkowski via gtkmm-list, < gtkmm-list@gnome.org> wrote: > > Everything

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

Does it change if you construct a dummy instance before building, instead of just calling get_type() ? ___ 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

On Fri, 1 May 2020, 23:40 Josh Bialkowski, wrote: > It looks like it does, I'm pretty sure this happens in the > `panzoomarea_class_.init()` call: > ~~~ > PanZoomArea::PanZoomArea() > : // Mark this class as non-derived to allow C++ vfuncs to be skipped. > Glib::ObjectBase(nullptr), >

Re: Invoking GTK main thread from other threads

That said, it's equally possible I am wrong and SignalIdle technically is not thread-safe. I can't really make sense of the wording in the docs... for connect_once(), we have: > Because sigc::trackable is not

Re: Invoking GTK main thread from other threads

Or maybe it's not so bad, since I usually only need to do things once, when the main thread resumes, and that sounds OK. Phew! :-D > The connect*_once() variants, Glib::SignalIdle::connect_once(), Glib::SignalTimeout::connect_once(), Glib::SignalTimeout::connect_seconds_once(), are thread-safe

Re: Invoking GTK main thread from other threads

Yeah, that doc did it for me: it seems that sigc++ makes glibmm less thread safe than GLib itself here. So I have some rewriting to do! Thanks for the links and discussion :-) > Although glib is itself thread-safe, any glibmm wrappers which use libsigc++ will not be. So for example, only the

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

Great catch! I guess due to the clock having no min size request, but the window letting it fill anyway. If so, another fix could be to request a minimal size with clock.set_size_request(w, h). ___ gtkmm-list mailing list gtkmm-list@gnome.org

Re: FlowBox::get_child_at_pos() seems missing

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: Builder create_from_file throwing exception

Check that your Inkscape function returns a valid filename. If it doesn't, figure out why that is, e.g. whether the file is installed to the right place (or compiled into the resource properly). I don't think there's enough info to implicate gtkmm here nor for readers to really speculate.

Re: Builder create_from_file throwing exception

You can debug it to find out. The quoted exception stated clearly that your code is somehow invoking an std::string constructor with a nullptr, which is illegal. Since Glib::ustring contains an std::string, it might be a ustring causing this. Debug to find out where a null pointer is arising and

Re: Please help (core dump)

On Sun, 26 Jul 2020, 20:21 Carlo Wood, wrote: > > I'm not sure what you mean with doing > > LinuxChessboardWidget(..) : Glib::ObjectBase("myWidgetClass") > > since Glib::ObjectBase is a base class of Gio::ActionMap, > I can't call that from LinuxChessboardWidget no? > yes, you can: research

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

Yeah, it's probably a C lib, and ASan or Val/MemGrind should be able to identify leaks pretty well. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::Label text Orientation

GTK4 removed the :angle property *. Unfortunately the reasoning wasn't documented in the commit message, nor is it mentioned in the migration guide **, so the question of how or whether it can be replaced is a topic (or perhaps bug) for the GTK project, not gtkmm (as gtkmm can only wrap what GTK

Re: Gtk::Label text Orientation

2nd link was wrong: ** https://docs.gtk.org/gtk4/migrating-3to4.html On Sun, 29 Aug 2021 at 12:25, Daniel Boles wrote: > GTK4 removed the :angle property *. Unfortunately the reasoning wasn't > documented in the commit message, nor is it mentioned in the migration > guide **, so the question

Re: Custom CellRendererText doesn't update cell size

Better show the code... Anyway I would think that drawing and sizing would be separate, so you probably also need to override measure() or whatever it ended up being called in GTK4. ___ gtkmm-list mailing list gtkmm-list@gnome.org

Re: How to use Pango::Context?

does the error occur if you do windows.reserve(2) before the emplace_back()s? On Mon, 21 Feb 2022, 14:30 phosit--- via gtkmm-list, wrote: > Hello > I try to list the awailable font-families. > If I open and close multiple windows ther is a critical error: > GLib-GObject-CRITICAL **:

Re: mouse button event and gtkmm-4.0

You want Gtk::Gesture and its subclasses. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

  1   2   >