Re: mouse button event and gtkmm-4.0

[Daniel Boles via gtkmm-list]

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?

[Daniel Boles via gtkmm-list]

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.722: g_object_unref: assertion
> 'G_IS_OBJECT (object)' failed
>
> This is the code, the error ocours even without the uncomented code:
>
> #include 
> #includs thee 
> #include 
>
> class Window: public Gtk::Window
> {
> public:
> Window()
> {
> this->show();
> this->set_child(this->text);
>
> auto context = this->text.create_pango_context();
> auto fontMap = context->get_font_map();
> //  auto fontList = fontMap->list_families();
> //  auto buffer = this->text.get_buffer();
> //  auto iter = buffer->get_iter_at_offset(0);
> //  for(const auto& fam : fontList)
> //  {
> //  iter = buffer->insert(iter,
> //  fam->get_name() + '\n');
> //  }
> //  }
>
> private:
> Gtk::TextView text;
> };
>
> auto main() -> int
> {
> std::vector windows;
> auto app = Gtk::Application::create();
>
> app->signal_activate().connect([&]
> {
> auto& w0 = windows.emplace_back();
> app->add_window(w0);
> auto& w1 = windows.emplace_back();
> app->add_window(w1);
> });
>
> return app->run();
> }
> ___
> 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 CellRendererText doesn't update cell size

[Daniel Boles via gtkmm-list]

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/mailman/listinfo/gtkmm-list

Re: Gtk::Label text Orientation

[Daniel Boles via gtkmm-list]

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 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 makes available).
>
> *
> https://gitlab.gnome.org/GNOME/gtk/-/commit/db4b1d28f53c30e8d4d555775cece1cc8aefdcf3
> **
> https://gitlab.gnome.org/GNOME/gtk/-/commit/db4b1d28f53c30e8d4d555775cece1cc8aefdcf3
>
>
> On Wed, 25 Aug 2021 at 10:58, Pedro Sousa via gtkmm-list <
> gtkmm-list@gnome.org> wrote:
>
>> Hello,
>>
>> I am trying to change the text orientation for a Gtk::Label to vertical.
>>
>> Using Gtkmm3 we could do it with
>>
>> Gtk::Label tab;
>> tab.set_angle(90);
>>
>> but in Gtkmm4 this function does not exist.
>>
>> Can you tell me the substituting function to change the text orientation?
>>
>> Regards,
>>
>> Pedro Sousa
>>
>> ___
>> 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: Gtk::Label text Orientation

[Daniel Boles via gtkmm-list]

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

*
https://gitlab.gnome.org/GNOME/gtk/-/commit/db4b1d28f53c30e8d4d555775cece1cc8aefdcf3
**
https://gitlab.gnome.org/GNOME/gtk/-/commit/db4b1d28f53c30e8d4d555775cece1cc8aefdcf3


On Wed, 25 Aug 2021 at 10:58, Pedro Sousa via gtkmm-list <
gtkmm-list@gnome.org> wrote:

> Hello,
>
> I am trying to change the text orientation for a Gtk::Label to vertical.
>
> Using Gtkmm3 we could do it with
>
> Gtk::Label tab;
> tab.set_angle(90);
>
> but in Gtkmm4 this function does not exist.
>
> Can you tell me the substituting function to change the text orientation?
>
> Regards,
>
> Pedro Sousa
>
> ___
> 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: Memory leak when drawing with pangomm/cairomm (MSYS2)

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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 any case
where the slot is not created by a call to sigc::mem_fun() which represents
a method of a class deriving from sigc::trackable.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Invoking GTK main thread from other threads

[Daniel Boles via gtkmm-list]

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 thread in which a main loop
runs should call Glib::SignalIdle::connect(),
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Invoking GTK main thread from other threads

[Daniel Boles via gtkmm-list]

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-safe, if the slot represents a non-static method of a class
deriving from sigc::trackable
,
and the slot is created by sigc::mem_fun()
,
connect_once()

should only be called from the thread where the SignalIdle

object's MainContext

runs. You can use, say, boost::bind() or, in C++11, std::bind()

or a C++11 lambda expression instead of sigc::mem_fun()

.

That makes enough sense and still leaves plenty cases for which it'll
definitely be safe.

but for connect(), we have the unconditional:

> This method is not thread-safe. You should call it, or manipulate the
returned sigc::connection

object, only from the thread where the SignalIdle

object's MainContext

runs.

I would expect the same condition(s) to apply to connect() as to
connect_once() - since AFAIK, all the once version does is just disconnect
itself automatically - but I might just be missing some obvious reason why
this can't be the case. And now I feel like maybe I've had this discussion
in the past...!

Anyway, I mentioned it because I have had the usual crashy behaviour
symbolic of trying to access widgets in threads other than the main one, in
my own projects, and wrapping the code doing said accesses in a lambda run
in SignalIdle has always fixed it. Maybe I've just been lucky so far?

Thoughts/corrections to me from those more experienced at doing
multi-threading with gtkmm are welcome.
___
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.

[Daniel Boles via gtkmm-list]

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.gnome.org/mailman/listinfo/gtkmm-list

Re: Please help (core dump)

[Daniel Boles via gtkmm-list]

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

Re: FlowBox::get_child_at_pos() seems missing

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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

Re: Builder create_from_file throwing exception

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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),
>   Gtk::DrawingArea(Glib::ConstructParams(panzoomarea_class_.init())) {}
>


iirc for Builder to work with derived widgets, ObjectBase() needs called
with a type name or id. but not sure it explains dynamic_cast failing, so
i'll defer to someone more experienced now!
___
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

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

-- 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 compiles, but when I change the above code to:
>
> ~~~
> Gtk::PanZoomArea panzoom_;
> builder->get_widget("overhead-view", panzoom_)
> ~~~
>
> the member is assigned nullptr and I see the following errors printed to
> stderr:
>
> ~~~
> : CRITICAL **: 13:53:12.873: Gtk::Builder::get_widget(): dynamic_cast<>
> failed.
> ~~~
>


Did you miss an asterisk in that declaration? get_widget() wants a pointer
as argument.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: mmification of gspell

[Daniel Boles via gtkmm-list]

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, but that's a great effort/start nonetheless and hopefully goes on.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Glib::Property and read / write settings

[Daniel Boles via gtkmm-list]

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't think glibmm wraps this, or at least
I can't see how. So you might need to add a bit of C to glue it to your
general handler for property changes.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Glib::Property and read / write settings

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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.


On Fri, 6 Mar 2020, 08:34 Klaus,  wrote:

> Am 06.03.20 um 09:07 schrieb Kjell Ahlstedt:
> > 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.
> >
>
> Thanks for your answer! But it sounds a bit horrible as I work on a very
> large application which is fully based on goocanvasmm. If this will not
> be supported any longer, years of work will be dropped. Is this the
> point to move to a more stable gui toolkit instead continuing and hope
> there will be any support? That is a very cost intensive decision!
>
> Regards
>   Klaus
>
> ___
> 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: Unable to set background color for button

[Daniel Boles via gtkmm-list]

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 best to avoid that though!
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Unable to set background color for button

[Daniel Boles via gtkmm-list]

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 the place for general info on how to use CSS, so
that's why you don't see that stuff there.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Unable to set background color for button

[Daniel Boles via gtkmm-list]

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*

https://developer.gnome.org/gtk3/stable/GtkButton.html


Thanks for the hint of "first unset..." . Is unsetting image done also
> with css or is that a method call?
>

in CSS. either add a line

*background-image: none*

or use the shorthand *background:* instead of *background-color:* as that
will achieve the same effect
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Fwd: Unable to set background color for button

[Daniel Boles via gtkmm-list]

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

the default theme applies a background-image gradient, and image overrides
color.

see C GTK docs for CSS node/class info. i can't recall whether gtkmm's doc
conversion preserves that section.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Unable to set background color for button

[Daniel Boles via gtkmm-list]

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
 and
a CSS style class. You can also override the default drawing of a widget
through the Gtk::Widget::signal_draw()
signal,
and use Cairo

to
draw a specific color, regardless of the CSS style.
"""
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Fetching gtkmm custom css style properties

[Daniel Boles via gtkmm-list]

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.
>
> *gtk_style_context_get* works. However, there are only 10 style
> properties defined in gtkstylecontext.h that we can retrieve this way and
> not all the style properties listed in Gtk-Inspector. For example there is
> a single definition for border radius as,
> #define GTK_STYLE_PROPERTY_BORDER_RADIUS "border-radius"
> While Gtk-Inspector lists one radii for each of the four corners. Which
> makes sense because in cases where you have linked buttons inside a button
> box (with 'linked' style class added), individual corners needs to be
> manipulated depending on the position of the button in the group and
> whether they are vertically stacked or horizontally.
>
> Anyway this is a good starting point. Many thanks to Daniel Boles.
> This post in Stackoverflow confirms the findings.
>
> https://stackoverflow.com/questions/47371967/getting-objects-out-of-a-gvalue
>
>
>
>
>
> *Please consider the Environment before printing this e-mail.*
>
> The information contained in this message (including any attachments) is
> confidential and may be privileged or otherwise protected from disclosure.
> If you are not the intended recipient, you must not copy this message or
> attachment or disclose the contents to any other person.  If you have
> received this transmission in error, please notify the sender immediately
> by return e-mail and permanently delete this message and any attachments
> from your system.  Any dissemination, use, review, distribution, printing
> or copying of this message in whole or in part is strictly prohibited.
> Please note that e-mails are susceptible to change.
>
> *SKANRAY* *(including its group of companies)
> shall not be liable for any omission or error in the message, improper or
> incomplete transmission of the information contained in this communication
> or for any delay in its receipt or damage to your system. * *SKANRAY*
> *(or its group of companies) does not guarantee
> that the integrity of this communication has been maintained or that this
> communication is free of viruses, interceptions or interference.*
> ___
> 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: Fetching gtkmm custom css style properties

[Daniel Boles via gtkmm-list]

-- 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 would have to use C code, something like

auto opacity = double{};
gtk_style_context_get(styleContext->gobj(), styleContext->get_state(),
"opacity", , NULL);

you may need to cast the state too, but you get the idea i hope :-) this
can be hidden in a helper function, made into a template, etc.





On Wed, 19 Feb 2020, 10:24 Mohith Manoj via gtkmm-list, <
gtkmm-list@gnome.org> wrote:

> Sorry I felt a bit dumb at this point, so I though I'll try all
> combinations. Following code is executed on a button press from a custom
> widget derived from Gtk::ToggleButton.
>   int nValue;
>   Glib::RefPtr refStyleContext =
> get_style_context();
>
>   refStyleContext->get_property("color", nValue);
>   refStyleContext->get_property("css-color", nValue);
>
>   refStyleContext->get_style_property("color", nValue);
>   refStyleContext->get_style_property("css-color", nValue);
>
>   get_property("color", nValue);
>   get_property("css-color", nValue);
>
> All six lines threw warnings as below.
>
>
>
>
>
>
>
>
>
>
>
> *(TV_UI:21972): GLib-GObject-WARNING **: 15:49:20.480:
> g_object_get_is_valid_property: object class 'GtkStyleContext' has no
> property named 'color'(TV_UI:21972): GLib-GObject-WARNING **: 15:49:20.480:
> g_object_get_is_valid_property: object class 'GtkStyleContext' has no
> property named 'css-color'(TV_UI:21972): Gtk-WARNING **: 15:49:20.480:
> ../../../../gtk/gtkstylecontext.c:1796: widget class
> 'gtkmm__GtkToggleButton' has no style property named 'color'(TV_UI:21972):
> Gtk-WARNING **: 15:49:20.480: ../../../../gtk/gtkstylecontext.c:1796:
> widget class 'gtkmm__GtkToggleButton' has no style property named
> 'css-color'(TV_UI:21972): GLib-GObject-WARNING **: 15:49:20.480:
> g_object_get_is_valid_property: object class 'gtkmm__GtkToggleButton' has
> no property named 'color'(TV_UI:21972): GLib-GObject-WARNING **:
> 15:49:20.480: g_object_get_is_valid_property: object class
> 'gtkmm__GtkToggleButton' has no property named 'css-color'*
>
>
>
>
>
> *Please consider the Environment before printing this e-mail.*
>
> The information contained in this message (including any attachments) is
> confidential and may be privileged or otherwise protected from disclosure.
> If you are not the intended recipient, you must not copy this message or
> attachment or disclose the contents to any other person.  If you have
> received this transmission in error, please notify the sender immediately
> by return e-mail and permanently delete this message and any attachments
> from your system.  Any dissemination, use, review, distribution, printing
> or copying of this message in whole or in part is strictly prohibited.
> Please note that e-mails are susceptible to change.
>
> *SKANRAY* *(including its group of companies)
> shall not be liable for any omission or error in the message, improper or
> incomplete transmission of the information contained in this communication
> or for any delay in its receipt or damage to your system. * *SKANRAY*
> *(or its group of companies) does not guarantee
> that the integrity of this communication has been maintained or that this
> communication is free of viruses, interceptions or interference.*
> ___
> 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: Fetching gtkmm custom css style properties

[Daniel Boles via gtkmm-list]

it doesnt work because those are CSS properties, which are not widget style
properties.

use get_property("css-prop-name", dst_value)


On Wed, 19 Feb 2020, 09:51 Mohith Manoj via gtkmm-list, <
gtkmm-list@gnome.org> wrote:

> Of course... get_color() works as we have seen 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, 2020 at 12:27 PM Daniel Boles via gtkmm-list <
> gtkmm-list@gnome.org> wrote:
>
>> 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
>> gtkmm-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>>
>
>
>
> *Please consider the Environment before printing this e-mail.*
>
> The information contained in this message (including any attachments) is
> confidential and may be privileged or otherwise protected from disclosure.
> If you are not the intended recipient, you must not copy this message or
> attachment or disclose the contents to any other person.  If you have
> received this transmission in error, please notify the sender immediately
> by return e-mail and permanently delete this message and any attachments
> from your system.  Any dissemination, use, review, distribution, printing
> or copying of this message in whole or in part is strictly prohibited.
> Please note that e-mails are susceptible to change.
>
> *SKANRAY* <http://www.skanray.com>*(including its group of companies)
> shall not be liable for any omission or error in the message, improper or
> incomplete transmission of the information contained in this communication
> or for any delay in its receipt or damage to your system. * *SKANRAY*
> <http://www.skanray.com>*(or its group of companies) does not guarantee
> that the integrity of this communication has been maintained or that this
> communication is free of viruses, interceptions or interference.*
> ___
> 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: Fetching gtkmm custom css style properties

[Daniel Boles via gtkmm-list]

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

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

[Daniel Boles via gtkmm-list]

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

free(this) is so wildly wrong. firstly, things allocated with new must be
deallocated with delete. free() is only for things from malloc(). secondly,
delete(this) would also be wrong: in the dtor because it would cause an
infinite loop... and anywhere because an object should never assume what
mode of allocation it uses (there might be niche cases, but this isn't one).
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::Orientable

[Daniel Boles via gtkmm-list]

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

finally, I would suggest an email subject that is a sentence, not just one
of the nouns that is (or in this case, is not!) involved in your question
:-)

```cpp
#include 
#include 
#include 

static void
set_orientation(Gtk::SpinButton& spinButton, Gtk::Orientation const
orientation)
{
auto const gtk_orientable = GTK_ORIENTABLE( spinButton.gobj() );
auto const gtk_orientation = static_cast(orientation);
gtk_orientable_set_orientation(gtk_orientable, gtk_orientation);
}

static void
on_activate(Glib::RefPtr const& application, Gtk::Window&
window)
{
auto& spinButton = *Gtk::make_managed();
set_orientation(spinButton, Gtk::ORIENTATION_VERTICAL);

window.add(spinButton);
window.show_all();
application->add_window(window);
}

auto
main() -> int
{
auto const application = Gtk::Application::create("org.djb.test");
auto window = Gtk::Window{};
application->signal_activate().connect( [application, ]{
on_activate(application, window); } );
return application->run();
}
```
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: custom TreeModel

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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_style_context, refreturn, constversion)
```

Should the const version return a RefPtr to a `const StyleContext`? I feel
like perhaps it should.

If we have the style context, we can change how the widget is drawn, which
is arguably quite a non-const thing to do with something whose main purpose
is to be displayed :-)
___
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

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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 is the preferred way now anyway. :-)


> Instead, I called Gtk::Application::run() and it works. The code is
> follow:
>
> auto app = Gtk::Application::create("mytest");
> Gtk::Box box;
> app->run();
> BOOST_TEST(box.get_homogeneous() == false);
>
> I also substituted Gtk::Box with my custom widget and everything seems
> works just fine.
>

Great! Probably the run() isn't even needed, as I think the creation of the
GtkApplication will suffice to initialise things far enough that you can
instantiate widgets and read/write properties.

Of course, if you want to test stuff that requires widgets to actually be
realised, etc., then you will indeed need to pack them into a toplevel and
run the application in order to make that happen.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Fwd: Debugging widgets

[Daniel Boles via gtkmm-list]

-- 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,
>
> I am trying to understand how to debug a widget. I am trying to do
> something like this. This is just a test.
>
> Gtk::Box box;
> BOOST_TEST(box.get_homogeneous() == true);
>
> I get the following error:
>
> (process:25274): Gtk-CRITICAL **: 14:36:20.149:
> _gtk_css_lookup_resolve: assertion '(((__extension__ ({ GTypeInstance
> *__inst = (GTypeInstance*) ((provider)); GType __t =
> ((_gtk_style_provider_private_get_type ())); gboolean __r; if (!__inst)
> __r = (0); else if (__inst->g_class && __inst->g_class->g_type == __t)
> __r = (!(0)); else __r = g_type_check_instance_is_a (__inst, __t); __r;
> }' failed
>
> (process:25274): GLib-GObject-CRITICAL **: 14:36:20.149:
> g_object_set_data_full: assertion 'G_IS_OBJECT (object)' failed
>
> (process:25274): Gtk-ERROR **: 14:36:20.149: ../../checkout/gtk+-
> 3/gtk/gtkstylecontext.c:348:gtk_style_context_init: Can't create a
> GtkStyleContext without a display connection
>
> Since Gtk::Box is not a top level widget is has no CSS styles
> associated with it. What would be the best practice to add CSS styles
> (ctor?) and eventually, how to debug a widget? I assume, we don't need
> to call any show() methods.
>
> Thanks.
> -Pavlo
>
> ___
> 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: changing the content of a model/view/store at run time

[Daniel Boles via gtkmm-list]

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 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 when a radio button
>> is clicked in order to erase the list store and replace it with another at
>> run time:
>>
>>   void ExampleWindow::on_rb2_clicked()
>>  {
>> std::cout << "rb2 clicked" << std::endl;
>>
>> typedef Gtk::TreeModel::Children type_children;
>> type_children children = liststore1->children();
>> type_children::iterator iter;
>> for(iter=children.begin(); iter!=children.end(); ++iter)
>>gtk_list_store_remove (*liststore1,*iter);
>>
>> }
>>
>> The compiler message I get is
>>
>> test3.cc: In member function ‘void ExampleWindow::on_rb2_clicked()’:
>> test3.cc:104:27: error: no match for ‘operator*’ (operand type is
>> ‘Glib::RefPtr’)
>> gtk_list_store_remove (*liststore1,*iter);
>>
>> So my question is, I suppose, what is the proper syntax for using
>> gtk_list_store_remove ???
>> On 8/8/19 3:46 PM, pcr wrote:
>>
>> I'm trying to learn how to iterate over model rows in a manner similar to
>> the code segment in section 9.3 of the gnome gtkmm tutorial.  Consider me a
>> newbie; the "something" I want to do below is delete/clear/erase a row -
>> really all rows so I can display a new set of rows in response to a user
>> action like changing a radio button.  But I haven't been able to do it.
>> Here is the snippit from section 9.3:
>>
>> typedef Gtk::TreeModel::Children type_children; //minimise code length.
>> type_children children = refModel->children();
>> for(type_children::iterator iter = children.begin();
>> iter != children.end(); ++iter)
>> {
>>   Gtk::TreeModel::Row row = *iter;
>>   //Do something with the row - see above for set/get.
>> }
>> *I'm also confused by the following comment I found on line; I don't see how 
>> this can work with the above code either. *
>> iterator Gtk::TreeStore:erase(const iterator& iter)
>>  Returns an iterator to the next row or end() if there is none"
>>
>> I hope you can help me .  Thanks, PCR
>>
>>
>>
>> ___
>> gtkmm-list mailing 
>> listgtkmm-list@gnome.orghttps://mail.gnome.org/mailman/listinfo/gtkmm-list
>>
>> ___
>> 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: changing the content of a model/view/store at run time

[Daniel Boles via gtkmm-list]

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 when a radio button
> is clicked in order to erase the list store and replace it with another at
> run time:
>
>   void ExampleWindow::on_rb2_clicked()
>  {
> std::cout << "rb2 clicked" << std::endl;
>
> typedef Gtk::TreeModel::Children type_children;
> type_children children = liststore1->children();
> type_children::iterator iter;
> for(iter=children.begin(); iter!=children.end(); ++iter)
>gtk_list_store_remove (*liststore1,*iter);
>
> }
>
> The compiler message I get is
>
> test3.cc: In member function ‘void ExampleWindow::on_rb2_clicked()’:
> test3.cc:104:27: error: no match for ‘operator*’ (operand type is
> ‘Glib::RefPtr’)
> gtk_list_store_remove (*liststore1,*iter);
>
> So my question is, I suppose, what is the proper syntax for using
> gtk_list_store_remove ???
> On 8/8/19 3:46 PM, pcr wrote:
>
> I'm trying to learn how to iterate over model rows in a manner similar to
> the code segment in section 9.3 of the gnome gtkmm tutorial.  Consider me a
> newbie; the "something" I want to do below is delete/clear/erase a row -
> really all rows so I can display a new set of rows in response to a user
> action like changing a radio button.  But I haven't been able to do it.
> Here is the snippit from section 9.3:
>
> typedef Gtk::TreeModel::Children type_children; //minimise code length.
> type_children children = refModel->children();
> for(type_children::iterator iter = children.begin();
> iter != children.end(); ++iter)
> {
>   Gtk::TreeModel::Row row = *iter;
>   //Do something with the row - see above for set/get.
> }
> *I'm also confused by the following comment I found on line; I don't see how 
> this can work with the above code either. *
> iterator Gtk::TreeStore:erase(const iterator& iter)
>   Returns an iterator to the next row or end() if there is none"
>
> I hope you can help me .  Thanks, PCR
>
>
>
> ___
> gtkmm-list mailing 
> listgtkmm-list@gnome.orghttps://mail.gnome.org/mailman/listinfo/gtkmm-list
>
> ___
> 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: Trapping Glib critical error messages

[Daniel Boles via gtkmm-list]

run with G_DEBUG=fatal-criticals or -warnings or etc to taste


On Wed, 7 Aug 2019, 23:50 Phil Wolff via gtkmm-list, 
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_unsubscribe: assertion 'G_IS_DBUS_CONNECTION
> (connection)' failed
>
> I'm getting these messages seemingly at random in a program I'm working
> on. Can someone tell me the Glib g_ function that prints these
> messages so I can trap them to get a traceback?
>
> ___
> 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: Overloading mouse events in a ProgressBar

[Daniel Boles via gtkmm-list]

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 2019, 05:09 Rob Pearce,  wrote:

> On 06/08/2019 14:50, Phil Wolff via gtkmm-list wrote:
> > I'm deriving from Gtk::ProgressBar in order to track mouse events
> > within the widget. The only callback that executes is on_map(). Can
> > anyone tell me what vital (and likely obvious) operation I've failed
> > to include?
> >
> I don't know if this still applies on GTK3 but on earlier versions ISTR
> that display widgets (like progress bar) usually aren't sensitive to
> mouse events because they have no reason to be. On X11 that also means
> they don't have the necessary X type. You have to wrap them in an event
> box and hook up to that instead.
>
> HTH,
>
> Rob
>
> ___
> 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: "Need placeholders to add children" Error

[Daniel Boles via gtkmm-list]

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

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

[Daniel Boles via gtkmm-list]

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

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

[Daniel Boles via gtkmm-list]

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 in Glade, but you can specify its location and child widgets
and the properties of its gtkmm base class

We probably want to add that by manually editing the .ui file, it's now
possible to set derived-class properties, albeit of course they are still
not available to set/see visually in Glade of course.

***

I suppose technically this is simply a new feature, which was previously
missing. But it might be seen as a big omission in retrospect, as it could
plug a real gap in the ability to use custom widgets nicely (for those who
prefer declarative properties in .ui to programmatic poking in .cpp).

So, when does a missing feature become so conspicious as to perhaps qualify
as a bug? I'll let you decide. :-)
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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.
:-P So I'd be interested in what you were doing that required that, if you
feel like elaborating.
___
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)

[Daniel Boles via gtkmm-list]

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

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

[Daniel Boles via gtkmm-list]

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 to draw the widget onto a
surface that I can then set as drag-icon, I must do:

```
auto const allocation = m_box_label.get_allocation();
auto const surface = Cairo::ImageSurface::create(
  Cairo::FORMAT_ARGB32, allocation.get_width(), allocation.get_height() );
auto const cairoContext = Cairo::Context::create(surface);
gtk_widget_draw( reinterpret_cast( m_box_label.gobj() ),
cairoContext->cobj() );
dragContext->set_icon(surface);
```

Is there any better way that I didn't think of, any way to make this nicer
in gtkmm, or is it just a fact of life at this point? (Since gtkmm-3 is
stable and master is probably very different here.)
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Disabling right-click behaviour of SpinButton

[Daniel Boles via gtkmm-list]

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 context menu in the entry region though. i don't
know if there'll be a way to figure out where the click landed and only do
it if it was on the + or - button.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

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 understood its purpose right, which I might not have )
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

> 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 builder->get_objects() in
order to ensure everything gets wrapped, and custom code in the registered
wrap_new() function to apply the derived properties? However, it seems that
user didn't get that to work, if I understood correctly.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

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 widget. I don't like it and I
can't find a way around. I marked that place in the source with ///!!! in
main_form.cpp

Second is that my properties are loaded in the glade file but they are not
set to the default value and when I change them from glade I can't get the
new values. I marked the place where I try connecting a signal again with
///!!! in area.cpp

>>>

Basically, it seems that we can't do what I hoped with glibmm/gtkmm, except
by writing a pile of C to glue it properly onto the core GOBject
functionality - at which point it's probably best either to go full C or to
use a binding that has better integration for creating custom GObjects (and
that's before we start thinking about GtkBuilder templates!)

I still want to keep writing C++, but I guess most of the programmatic
widget-packing noise will have to remain... I'm not sure that hoisting out
only the bits that don't require derived widgets or new properties would be
worth doing, given that I'd end up with a mixture of paradigms; it's
probably best to stick to one only, even if that's the worst one! (at least
I can keep telling myself that'll avoid the overhead of parsing XML...)
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

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 can't handle such properties in C++ because they need to work with C
layers like GtkBuilder, which will never run a C++ constructor or signal or
etc.
 * We need to handle them using the good old C [gs]et_property vfuncs,
otherwise the base G_OBJECT_WARN_INVALID_PROPERTY_ID() gets hit.

with the result being that I think the best we can currently do is some
hybrid of C/C++, where the properties must be implemented in C and then
just wrapped later in C++ for easier consumption.

This is arguably still a bit nicer than doing the whole lot in C, but it
remains to be seen whether it's sustainable enough to be worthwhile, i.e.
whether the benefit of being able to shift programmatic ui generation into
Builder definitions outweights having to add the layer of C boilerplate to
every class.

Of course, I might still be missing something obvious - so I'd definitely
welcome corrections or proof-of-concepts contrary to what I've said/shown
so far!


```c
class ExtraClassInit_Button2: public Glib::ExtraClassInit {
public:
  ExtraClassInit_Button2()
  : Glib::ExtraClassInit(class_init, nullptr, instance_init)
  {}

private:
  enum { PROP_0, PROP_STYLE_CLASS, PROP_COUNT };

  static GParamSpec* s_paramSpecs[PROP_COUNT];

  static void
  class_init(void* const g_class, void* const class_data)
  {
s_paramSpecs[PROP_STYLE_CLASS] = g_param_spec_string(
  "style-class", "Style Class", "a CSS style class",
  "", G_PARAM_READWRITE);

auto gObjectClass = G_OBJECT_CLASS(g_class);
gObjectClass->set_property = _property;
gObjectClass->get_property = _property;
g_object_class_install_properties(gObjectClass, PROP_COUNT,
s_paramSpecs);
  }

  static void
  set_property(GObject* const object, unsigned const property_id,
   const GValue* const value, GParamSpec* const pspec)
  {
switch (property_id) {
  case PROP_STYLE_CLASS: {
auto const str = g_value_get_string(value);
set_style_class(GTK_WIDGET(object), str);
break;
  }

  default:
G_OBJECT_WARN_INVALID_PROPERTY_ID(object, property_id, pspec);
}
  }

  static void
  set_style_class(GtkWidget* const widget, char const* const str)
  {
if (!str) {
  return;
}

auto const styleContext = gtk_widget_get_style_context(widget);
gtk_style_context_add_class (styleContext, str);
  }

  static void
  get_property(GObject* const object, unsigned const property_id,
   GValue* const value, GParamSpec* const pspec)
  {
switch (property_id) {
  case PROP_STYLE_CLASS:
g_value_set_string(value, "oops not implemented yet");
break;

  default:
G_OBJECT_WARN_INVALID_PROPERTY_ID(object, property_id, pspec);
}
  }
};
```
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

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__CustomType_Button2 property name "color"

as my trivial example (I don't really want a Button:color property... don't
panic or excommunicate me please)

However, I'll double-check later whether that does/doesn't work, and post a
sample of what I've tried in any case.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

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 don't
> volunteer, at least not for the foreseeable future.
>

Of course! Nor do I, yet... but we'll see how this goes :-)


> If such properties can be added, could they still be used with
> Glib::PropertyProxy, or does it require its target property to have been
> fully created by Glib::Property?
>
> _WRAP_PROPERTY("visible", bool) in Gtk::Widget generates the code
>
> Glib::PropertyProxy Widget::property_visible()
> {  return Glib::PropertyProxy(this, "visible"); }
> Glib::PropertyProxy_ReadOnly< bool > Widget::property_visible() const
> {  return Glib::PropertyProxy_ReadOnly(this, "visible"); }
>
> If custom properties are registered like glib/gtk+ register properties, I
> see no reason why similar code should not work for the custom properties.
>
Yeah, that was my hope. Since all the Proxy cares about is the instance
(C++, from which it can get the C gob() ) and property name, hopefully it
doesn't care and will work just as well here.


Thanks for the ideas so far. I'll see how this goes. If anyone else has any
thoughts, I'd be interested of course.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

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? Then it would seem we must instead create a dummy C++
instance (and ensure it isn't optimised out) before trying anything that
would require GObject to know about it...

Excuse me if these are basic questions, but I've only just started thinking
about non-trivial subclassing in glibmm/gtkmm. Previously I've either used
composition or done trivial subclassing (no extra properties, etc.). So,
while I'm relatively comfortable with how GObject registers classes and
their features, I'm still figuring out how glibmm layers on top of that!
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

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 properties through a Gtk::Builder .ui?
> >
> > Presuming the answer is no, because the properties are only registered
> > with GType when the instance is constructed - not when the class is
> > constructed, which GtkBuilder won't do anyway if it's C++ - is there
> > any way this could possibly work in future, or discussion I can read?
> >
> I think this has not been possible previously, but what about
> Glib::ExtraClassInit, available since glibmm 2.60.0? Do you think it
> will help? It makes it possible to add code to the class init func in
> your custom widget. If you register properties in the class init func,
> like C classes do, you shall probably not use Glib::Property<>, but
> rather code that resembles what _WRAP_PROPERTY() generates.
>


Thanks! I kind of forgot this had gotten arrived in a stable release (but
was otherwise wondering if I could trick GObject into doing it anyway!)

I imagine this can probably work, so I'll give it a shot. Do you think it
would be possible, or worth thinking about, to add ways to do this (and
probably custom signals) in C++? It would be nice if we could add
properties and signals to the class without having to go into C (or rather,
by having glibmm do that for us). Properties especially, to make them
usable with GtkBuilder .ui files as mentioned.

If such properties can be added, could they still be used with
Glib::PropertyProxy, or does it require its target property to have been
fully created by Glib::Property?
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

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 constructed - not when the class is constructed,
which GtkBuilder won't do anyway if it's C++ - is there any way this could
possibly work in future, or discussion I can read?

Basically, I'd like to move a tonne of code that does widget packing and
property-setting out of .cpp files into .ui files, but it doesn't really
seem worth doing if the added properties of my custom widgets would all
need set/get through .cpp files still. I'd like to move everything that
could be expressed statically/declaratively to .ui files, or nothing. I
don't think moving only the base Widget bits to .ui but having to keep the
rest in .cpp is better overall, but worse.

So far I can derive a subclass of e.g. Gtk::Button, add whatever
Glib::Property, and see/change its value in the GTK Inspector. Even this
isn't very well documented; it doesn't seem to be included in the main
gtkmm doc book at all, for instance, so we might want to fix that.

Anyway, this registers properties per-instance when the C++ constructor is
called, so GtkBuilder doesn't actually apply the values of custom
properties, and the GTK Inspector gives warnings about invalid property IDs
when you try to check/change customer properties in a .ui

I'm guessing this has been discussed and just can't be done, but I'd just
like to check anyway.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Cross-coupling comboboxes

[Daniel Boles via gtkmm-list]

> 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 handler connections, whereas the latter would've let you do all
at once. I guess it makes sense; we don't normally want to have to block
everything including GTK/GLib's own handlers.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Cross-coupling comboboxes

[Daniel Boles via gtkmm-list]

> 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), but it might well lead to nicer handler code if you don't have to
check for all the abnormal conditions, by simply blocking so it's never
called in such cases instead.

Another idea I have is to unset the model from the ComboBoxes before
clearing the model, then reassociate it with them afterwards. That might
result in only notify::model being emitted, rather than all the ::changed.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Cross-coupling comboboxes

[Daniel Boles via gtkmm-list]

> 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
the nearest still-valid one, and so on, etc.

another way around this might be to block the signal while you clear the
model.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Cross-coupling comboboxes

[Daniel Boles via gtkmm-list]

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

In that case you probably should indeed use either TreePath or :active-id,
since those are only instructions how to get to the right place in an
equivalent model - rather than being intrinsically tied to the validity of
the original state of the same model, like iterators are. That said, even
path/ID probably only work if, after you clear and rebuild for whatever
unclear reason, the item you want to reselect has the same path/ID (or
you're happy to select a different item that now has that path/ID).
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Cross-coupling comboboxes

[Daniel Boles via gtkmm-list]

>>>









*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
with the coupling. If I comment out the forward coupling call it makes
little difference. I've also tried calling unset_active() before the
clear() but it didn't help.*
>>>

Yep:

```
G_DEBUG=fatal-criticals gdb ./your_exe
run
bt
```
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Cross-coupling comboboxes

[Daniel Boles via gtkmm-list]

>>>
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 number
obviously no longer works, so...
>>>


I don't know if GTK+ 2 had these, but as of GTK 3, I would look into
property :active or :active-id (ensuring rows have values for those of
course). You could continue syncing them manually, if you need or simply
want to, or alternatively you could automate it via GLib's bind_property().
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Removing text from ComboBoxText

[Daniel Boles via gtkmm-list]

...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
of the code, e.g. if the captured widget pointer becomes invalidated or
etc. (It's not at all clear why it gets the string locally and never uses
it, but that shouldn't be a problem.) There's no point trying to guess when
we can't see the rest of the code.


On Wed, 29 May 2019 at 11:45, Daniel Boles  wrote:

> 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

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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 documentation like this is simply wrong, because it gets
auto-translated from C but we don't change that to "" as we should (and I
opened a bug for). That might be easier said than done though.

Basically, any C nullptr should be mapped to a C++ empty string, and if
it's not somewhere, there's probably a bug in the wrapping.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Removing text from ComboBoxText

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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

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

[Daniel Boles via gtkmm-list]

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

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

[Daniel Boles via gtkmm-list]

*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 to use to simply observe when the
state changes, because this signal is intended for changing the
implementation of how/when state changes are applied, not observing the
state.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

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 sync with the Gtk::Switch::property_active()

property"

that is: the point of this signal is to control how the state changes, not
listen for said changes. if you override that default handler, it probably
won't do what you expect. also, you're not connecting before that default,
hence why you don't see any printout.

checking for changes on the property as you proposed is correct, I think.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Changing gtkmm application theme

[Daniel Boles via gtkmm-list]

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().
>
> On 4/16/19 9:45 AM, Mohamed Khalil BOUJDARIA via gtkmm-list wrote:
> >
> > Hey list,
> >
> > Can someone please provide an example on how to customize gtkmm app
> > theme.
> > I am trying to set it it to use Adwaita dark instead of default light
> > theme.
> >
> > Thanks
> >
> > ___
> > gtkmm-list mailing list
> > gtkmm-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtkmm-list
> --
> I am better able to retract what I did not say than what I did.
> — Ibn Gabirol
> ___
> 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: Change application theme

[Daniel Boles via gtkmm-list]

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

Re: Sockets (Client/Server)

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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. 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.
>
> bind. But I don't think that's important now since I've lost the code
> anyway. Maybe I was supposed to include some file?
>

Obviously. <*sigc*++/bind.h> or IIRC adaptors.h collects this and other
stuff together if you want.
___
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

[Daniel Boles via gtkmm-list]

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 latter increasingly useful to
express semantics and avoid the perils of pointers.

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

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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

Re: API-Reference is missing

[Daniel Boles via gtkmm-list]

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
into /usr/share/doc alongside the main package, or has a separate doc
package available.


On Thu, 14 Feb 2019 at 04:23, Compro Prasad via gtkmm-list <
gtkmm-list@gnome.org> wrote:

> I am also frustrated with the documentation available for gtkmm. I
> have to instead look into gtk docs and try to guess the equivalent
> gtkmm code. If possible I could also help in doing anything necessary
> or automating the whole process document generation.
>

Documentation *is* largely generated, and usually people complain about
that instead because the generation (A) is inherently limited because not
every C concept can be 100% accurately transformed to a C++ wrapping
mechanistically and/or (B) said automation doesn't have all the features
that it in theory could (but which I don't see Merge Requests for! ...yes,
including from myself.)

I presume you've seen the gtkmm tutorial (in the gtkmm-documentation
project). If there are specific things you are frustrated with, then you
can submit an Issue or - better - Merge Request on GitLab to request or add
examples for that. Otherwise, it's unclear what you want fixed, or where
you think *more* automation could help (rather than hinder), so general
frustrations don't really provide an indication of what could be improved.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Pixel size of primary monitor?

[Daniel Boles via gtkmm-list]

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);
> // adapt size
> width = monitor_size.get_width() / 1.8;
> height = monitor_size.get_height() / 2;
> }
>
> This works on X11 and Windows, but not on Wayland! I've get a nullptr and
> the defaults for width/height are used instead.
>


See https://gitlab.gnome.org/GNOME/gtk/issues/1028 "No monitor reported as
primary by GDK under Wayland"
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: API-Reference is missing

[Daniel Boles via gtkmm-list]

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/listinfo/gtkmm-list

Re: changing cursor

[Daniel Boles via gtkmm-list]

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::CROSSHAIR);
> win->set_cursor(cursor);
>
> // the folling code  doesn't work
> gdk_display_get_maximal_cursor_size(
> display->gobj(),  w, h);
>
> No idea on how to change the cursor size yet. I've set the cursor size of
> my gnome cusor to 64 or so, but it doesn't affect the gdk cursor that I've
> created above.
>


Can you define "doesn't work"? Are `w` and `h` not set to a valid cursor
size?

but then maybe that's the real point: if you're trying to *set* the size,
why call *get*_maximal_cursor_size()?
___
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

[Daniel Boles via gtkmm-list]

...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/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

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 the cursor in gtkmm3?
>
> Secondly, that is the proper way to change the cursor size? I need large
> cursors, but can't find any info on this topic.
>
>
> Please point me in the right direction. A working example would be
> wonderful.
>
> Thank you.
>
> Marty
>
> ___
> 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: Dead links to documentation

[Daniel Boles via gtkmm-list]

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
us just posting "me too" doesn't help fix that.

This seems to require someone from the GNOME documentation site helping out
the gtkmm team, because they haven't conclusively figured out the problem
or a fix, otherwise the bug would be resolved:
https://gitlab.gnome.org/GNOME/glibmm/issues/26

In terms of a quick workaround The latest gtkmm docs that work are 3.20;
substitute "3.20" for "stable" in any doc URLs, and hope the old docs are
still accurate enough, or just read the header Doxygen documentation. For
glibmm, the substitution for stable will be 2.52 I would guess (at least
that's what I most recently used).
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

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 glibmm - not important, but would be nice to get reviewed
before the next release.

Maybe it's the kind of thing I could just push, but I erred on the side of
caution (for once!)
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

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

[Daniel Boles via gtkmm-list]

If we agree to merge Gtk::make_managed(), then the patch I have in an MR on
GitLab will make gtkmm-documentation 3.24 more interesting, as it includes
updates about that!

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 a final go-ahead for
the actual code one before I push.

There are a few relatively minor improvements that we have made in master
but weren't approved for gtkmm-3-22, which would be nice to pick to
gtkmm-3-24 while we have the chance. I'll try to dig those up and ping the
bugs or submit MRs to get confirmation on whether they're deemed suitable.
The one that comes to mind right now is Gtk::Window::show_uri(), which has
no gtkmm wrapping in v3 right now.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Capturing modifier keys in a TextBuffer

[Daniel Boles via gtkmm-list]

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

Re: Capturing modifier keys in a TextBuffer

[Daniel Boles via gtkmm-list]

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 right
way to do it... but if you can make it work, it seems simplest.

Deriving and overriding the default handler vfunc could achieve the same
thing since obviously you replace the base one and then can choose to chain
up after your added stuff, or even replace it altogether. It may or may not
be worth the hassle though.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Capturing modifier keys in a TextBuffer

[Daniel Boles via gtkmm-list]

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/listinfo/gtkmm-list

Re: Capturing modifier keys in a TextBuffer

[Daniel Boles via gtkmm-list]

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

Re: Cells height problem

[Daniel Boles via gtkmm-list]

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

[Daniel Boles via gtkmm-list]

> 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 alternative, since it uses sigc::trackable to auto-disconnect
the handler if the object is a trackable and goes out of scope.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Alternative to sigc::mem_fun

[Daniel Boles via gtkmm-list]

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


*T_return(T_obj2::*)(T_arg1) * *_A_func*

*)*


These are immediately adjacent in the docs:
https://developer.gnome.org/libsigc++/stable/group__mem__fun.html#ga0df7af9f32990cc624c4bb60782b4f78

or did I miss something else and this doesn't work for you somehow?
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Alternative to sigc::mem_fun

[Daniel Boles via gtkmm-list]

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 <
https://developer.gnome.org/libsigc++/stable/group__mem__fun.html> says Please
use the version that takes the object by reference instead.
which means that it provides alternatives that accept references, and you
should use those overloads instead of the older ones taking a pointer.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list