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

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 **: 15:22:32.72

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 https://mail.gnome.org/m

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: 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 ma

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: 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 for

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 thre

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

Re: Invoking GTK main thread from other threads

from your readme: > GTK# and other gtk bindings supply a method to callback to the main thread, which gtkmm does not. I'm pretty sure it does. Or rather, GLib does, and GTK uses the GLib main loop, and glibmm/gtkmm wrap both of those. You simply connect to Glib::signal_idle(), passing a callback

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 https://mail

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

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 t

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

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

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 compil

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 odd,

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 don

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: 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: 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: 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 b

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 t

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*

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 only

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: 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. > > *gt

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

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

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 list

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

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 actuall

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

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, gtk_widget_get_st

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

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: 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 Gtk::Application

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: > Hi

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 ap

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 w

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: > g_dbus_connection_signal_unsubscr

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 20

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: 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 2.62

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 i

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

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)

> I don't know why Widget::draw() is protected. Perhaps someone misunderstood it, and thought that it draws from the cairo context to the widget, instead of the other way. Yeah, it doesn't seem like it's 'protecting' anything by not being usable publicly. Can the access specifier perhaps be change

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 order

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 conte

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 understoo

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 bu

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 widge

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: * We

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 gtkmm__CustomT

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

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

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

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 construc

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 handl

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 handler),

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 t

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 th

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 w

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 row

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 rest

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

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 docu

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

> 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

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: 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 signal

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: 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: 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 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 co

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 lat

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

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 documentation

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: 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 https://mail.gnome.org/mailman/

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, Gdk::C

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 https://mail.gnome.org/

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: 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 t

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: 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 in

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 and

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 gtkmm-list@gnome.o

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 ri

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 https://mail.gnome.org/mailman/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: 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: 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

  1   2   >