FileChooserDialog constructors taking backend argument

Hello, About this commit: https://git.gnome.org/browse/gtkmm/commit/?id=bd97e557771cdce23bdc815288db2ffdd8c083c9 Clearly these constructors could not actually achieve their stated purpose in GTK+ 3, as the backend functionality was removed already then. In case anyone was trying to use these in

Re: utf8 and Glib::ustring

On 22 March 2017 at 08:52, John Emmas wrote: > Forgive my ignorance - this'll probably be obvious to some of you... > > Suppose I've got a simple character string, like this:- > > const char* my_str = "Hello World"; > > I can assign it to a Glib::ustring very

Fwd: FileChooserDialog constructors taking backend argument

On 27 March 2017 at 12:50, Kjell Ahlstedt <kjell.ahlst...@bredband.net> wrote: > Den 2017-03-26 kl. 23:15, skrev Daniel Boles: > >> Hello, >> >> About this commit: https://git.gnome.org/browse/g >> tkmm/commit/?id=bd97e557771cdce23bdc815288db2ffdd8c083c9 &g

Fwd: New versioning scheme in gtk+. And in gtkmm?

On 23 March 2017 at 15:09, Chris Vine wrote: > One point is that version 3.90 has still not been reached. gtk+ still > seems stuck on gtk+-3.89, notwithstanding that gnome-3.24 has now come > out. > I don't think there is any relation between GNOME releases and the

Re: gtkmm 3.24 or new API in gtkmm 3.22?

I would agree with Dieter. But by all indications I've seen, there specifically will not be any GTK+ versions beyond 3.22. The idea is that 3.22 is the v3 version of 2.24 - the final 'minor' release of its kind, which will now only receive an arbitrary number of point releases, until its LTS ends.

Re: GTKMM/C++11: How to create a custom composite widget out of other widgets?

On 22 January 2017 at 14:17, Bill William wrote: > > (Afterthoughts: I was wondering if C++ has a way to implicitly convert > from one class type, example a composite widget type, to another class, > example Gtk:Widget&, simply by placing the class object in the context of

Re: Closing a Gtk::MessageDialog

You should be calling Dialog::run(), not using the Dialog as a main window. That is not how Dialogs are intended to be used. So I wouldn't be surprised if the close button does not have its intended effect without the nested main loop of Dialog::run() to process it. Though I've never tried what

Re: gtkmm: Pixbuf::get_pixels()

The copy is done as follows, to support copy-on-write: * This function will cause an implicit copy of the pixbuf data if the * pixbuf was created from read-only data. https://git.gnome.org/browse/gdk-pixbuf/tree/gdk-pixbuf/gdk-pixbuf.c#n674 I thought as long as the apparent functioning of

Re: New versioning scheme in gtk+. And in gtkmm?

On 22 March 2017 at 10:04, Chris Vine wrote: > It is possible I am wrong (the original naming proposals were changed > and I may have missed something) but I do not think there is ever > intended to be a 3.23/24. As I understand it, 3.22 has become like > 2.24: it

Re: builder gio::resource problem

Another bug in either the email or the real procedure is the missing > at the end of the gresource.xml file ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Detect scrollbar change due to user interaction

signal_change_value is the one that exists to validate/apply/reject user attempts to change the value of the Range ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Segmentation fault in simple-netaid

On 2 April 2017 at 10:33, aitor_czr wrote: > Well..., in the following video, > I think you forgot to post the link to this video. > the status icon still persists after closing the application, because the > hide() action of the right click popup menu still was not

Fwd: Detect scrollbar change due to user interaction

then maybe signal_scroll_event() ? If you first confirm all of the things you have tried and why they didn't work for you, it will save us having to suggest things you have already discounted. ___ gtkmm-list mailing list gtkmm-list@gnome.org

Re: builder gio::resource problem

On 9 April 2017 at 21:42, Marty Moore wrote: > > resource.c: gresource.xml example_builder.ui > $(COM P_RES) --target=$@ --sourcedir=$(DIR) --generate-source $< > Is this another typo? There should not be a space in the variable name. That would explain this... make -k >

Re: gtkmm 3.24 or new API in gtkmm 3.22?

On 5 April 2017 at 15:00, Murray Cumming wrote: > On Sat, 2017-04-01 at 09:22 +0200, Kjell Ahlstedt wrote: > > I agree with Diether and Daniel: Let's do as gtk+ does, even though > > they break the rules. > > OK. Then I don't object anymore. Thanks for being patient. Feel

Re: gtkmm 3.24 or new API in gtkmm 3.22?

On 16 April 2017 at 13:31, Murray Cumming wrote: > We have not released glibmm 2.52.0 yet (a version of glibmm-2.24). It's > still unstable - the latest release is 2.51.6. Theoretically it should > have been released already, but we didn't do that due to the GTK+4 >

Give multi-child containers a convenience Container::add(std::initializer_list) [and maybe ctor] ?

I don't know about you, but often I just want to create a Container, add a bunch of child Widgets to it, add it to a window or something, and forget about it. We then get repetitive code like this: box.add(foo); box.add(bar); box.add(bongo); Way back when, I had a wrapper class around

Re: Should an iterator be valid after appending to a Glib::ustring?

On 14 March 2017 at 14:29, Krzysztof Piecuch via gtkmm-list < gtkmm-list@gnome.org> wrote: > What about ustring.end() iterator? I think it's obvious that it's > invalidated each time we change the string's length (unless it's done in > some *very clever* way). > It's a thing no reserve()-ation

Re: Give multi-child containers a convenience Container::add(std::initializer_list) [and maybe ctor] ?

Another idea for the pile: struct GridAttachItem { Gtk::Widget& widget; int x; int y; int w; int h; }; void Grid::attach( std::initializer_list ); This illustrates another point, that the inability to have containers of references is subverted if the reference is part of a

Re: Compiling gtkmm

On 10 March 2017 at 12:47, Krzysztof Piecuch via gtkmm-list < gtkmm-list@gnome.org> wrote: > Thank you for you answer, I'm trying to compile it with ./autogen.sh. > I don't really know which I want - I *think* I should contribute to master > if I want to introduce new stuff to the library, but I

Re: Give multi-child containers a convenience Container::add(std::initializer_list) [and maybe ctor] ?

On 10 March 2017 at 14:58, Kjell Ahlstedt wrote: > I don't think it has been considered, and certainly not rejected. It's a > good idea. > Cool! > A lot of details can be discussed. There could be > > Gtk::Container::add(std::initializer_list

Re: How to produce a 'New Line' in GtkTextView ?

I suspect this not being parsed as an escape sequence for a newline is to do to with Glib::ustring (and perhaps the underlying C GLib methods) using Unicode, and not parsing that sequence as an escape in a Unicode context. This speculation is mostly based on

Re: Compiling gtkmm

On 10 March 2017 at 12:32, Krzysztof Piecuch via gtkmm-list < gtkmm-list@gnome.org> wrote: > Hi guys, it's my first time contributing here. My name's Chris and I > wanted to implement ustring method which fixes non-unicode ustrings (any > particular reason it's not yet implemented?) > > Anyway, I

Re: Should an iterator be valid after appending to a Glib::ustring?

It is a general concept of C++ that iterators are invalidated by various modifying operations, and the API should usually specify which operations do and do not invalidate iterators. In this case, if ustring itself does not stipulate, you should check the Standard C++ documentation for

Re: Should an iterator be valid after appending to a Glib::ustring?

On 13 March 2017 at 21:46, Daniel Boles <dboles@gmail.com> wrote: > This is a pretty obvious "no". If the operation can cause a reallocation, > that's a very strong hint, so if the container does not explicitly state > that it does NOT invalidate iterators then

Re: Detecting deprecated function usage

not sure right now about warnings, but I know you can outright remove marked deprecated features - and hence convert them to errors - at the preprocessor stage by defining GTKMM_DISABLE_DEPRECATED ___ gtkmm-list mailing list gtkmm-list@gnome.org

Re: libgdamm in debian

I can't add much to this, except my sincere wish that Glom were packaged in Debian. ;) It looks fantastic, but every time I try to build it myself, I run out of steam about 1/3rd of the way in due to how many dependencies it requires. (I suppose now that Ubuntu is going full GNOME, I guess I might

Re: gtkmm 3.24 or new API in gtkmm 3.22?

On 14 April 2017 at 17:52, Murray Cumming wrote: > > Glib 2.51/52 is meant to just target glib 2.51/52, with no API or ABI > break. glibmm-2.54 is the ABI-breaking API, which will be used with > gtkmm-4.0. It's not impossible that this will change again, I'm afraid. > > I'm

Re: enums that are really just sets of constants

On 19 April 2017 at 09:37, Murray Cumming wrote: > However, some of the C enums that we wrap are actually meant to be > integer constants, so it seems that we cannot and should not use "enum > class" for these. So I wonder what is the most "modern C++" way to do > this while

Re: Re: scroll a tree view to sepcific row

You never move iter beyond children.begin(). ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: scroll a tree view to sepcific row

A TreeRow is a TreeIter https://developer.gnome.org/gtkmm/stable/classGtk_1_1TreeRow.html So you can use get_path(Tree) and just pass the TreeRow as the parameter. https://developer.gnome.org/gtkmm/stable/classGtk_1_1TreeModel.html#a090a3d092d3b9876c6965d8bf79ba780

Re: scroll a tree view to sepcific row

I meant get_path(TreeIter) ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Re: scroll a tree view to sepcific row

Besides, although you could add the missing increment, there's no need; if you know you have enough rows, you can just index into children using operator[]. Also, why does row2 exist? It's not used for anything. ___ gtkmm-list mailing list

Re: Re: Re: Re: scroll a tree view to sepcific row

Great, you're welcome! ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Re: Re: scroll a tree view to sepcific row

On 16 August 2017 at 08:43, Klaus Rudolph wrote: > Gtk::TreePath p1("8:"); > m_TreeView.scroll_to_row( p1, 0); > > compiles but did nothing. Is my syntax for the string invalid or must it > be converted before? > The syntax is invalid, AFAICT. The same page explains:

Re: Customizing Colors and Adding Border to the Container widgets

This is also too vague a question to do much with. But you could simply Google *GTK+ CSS* and learn about how to use CSS for this. That is the recommended mechanism and supports most of the common CSS functionality. ___ gtkmm-list mailing list

Re: Regarding Changing Background Color of the Window

- It is no use to tell us you are getting errors without telling us what those are; few people will want to compile your code for you with no hints - override_background_color() et al are deprecated. It's possible your build disables deprecated symbols, but then we can't see your build

Re: Accessing combo box text

You only connect the signal handler that does the print, if the Builder returned a non-null pointer. Have you checked whether the Builder actually returns a non-null pointer, i.e. successfully looks up the widget with name Product_Combo to m_combo!? I would recommend, as always, assert()ing that

Re: Transparent Window

"I am failing" How? What did you try? What was the error? You are failing to give any useful info when making posts asking for help... They have all been very vague so far. Transparency is just another thing that is best done on the CSS side, using opacity on the relevant node (check the GTK+ dev

Re: Accessing combo box text

You are failing how? What is the error? Please, try to post questions that give readers a bare minimum of info to work with. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Regarding creating Directory in gtkmm

A quick search indicates to me that you can construct a Gio::File holding the desired name of the new directory https://developer.gnome.org/glibmm/stable/classGio_1_1File.html#a1b1a4553b226689d50b9525488223e25 and then call make_directory() to actually create it

Re: Gtk::Entry::set_icon_from_icon_name(nullptr) segmentation fault

The documentation is auto generated from the C documentation, which does not always work very well, especially for conversions from char* to Glib::ustring as you saw. Did you try just passing an empty string? That's usually how you need to mentally translate "nullptr". I wonder if the

Re: Gtk::Entry::set_icon_from_icon_name(nullptr) segmentation fault

On 25 July 2017 at 16:02, Daniel Boles <dboles@gmail.com> wrote: > what does not have a constructor from std::nullptr_t is Glib::RefPtr in > glibmm 3. > Oops, I meant glibmm 2.4, i.e. the stable ABI, as used by gtkmm 3. The current development version of the next ABI is 2

Re: Gtk::Entry::set_icon_from_icon_name(nullptr) segmentation fault

On 25 July 2017 at 15:20, Martijn Otto via gtkmm-list wrote: > I had not thought of trying an empty string, though it's good to know that > this is the usual answer to nullptr's that have become objects. > It's the usual answer for where the C API specifies NULL and the

Re: Gtk::Entry::set_icon_from_icon_name(nullptr) segmentation fault

Besides, to unset the icon, rather than manipulating a set() overload into unsetting, why not just call unset_icon() ? ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::Entry::set_icon_from_icon_name(nullptr) segmentation fault

On 26 July 2017 at 08:20, Martijn Otto via gtkmm-list wrote: > I must admit I had missed that function, after reading the > documentation describing the usage of a "nullptr" to clear the image I > assumed that was the GTK way of doing things. > Well, yeah, it's *a* way,

Returning sigc::signal by value from a const method?

I'm wondering about this for a project I'm writing. Would this be considered bad style? It's certainly possible (as signal is copyable, and many mm classes return it by value from non-const methods), but is it bad design for any reason? My line of thought is that the signals only observe the

Re: Returning sigc::signal by value from a const method?

As an aside, since realising that providing any form of full access to a signal gives external users the ability to emit() it, clear() it, etc. - I am considering moving to a model whereby I only expose signals via a method like this: sigc::connection signal_whatever_connect(signal_whatever_type

Re: Accessing combo box text

On 22 July 2017 at 12:07, wrote: > Hi All, > > I am getting message like this after stop debugging. "gtkmm-CRITICAL **: > gtkmm: object `Product_Combo' not found in GtkBuilder file." Please help. > > Thanks > Deepak > Well? Is it in the ui file? Despite

Connecting signal to destruction of an object - or - self-destructing handlers

How/can I receive an event when some object of my choice is destroyed, so that I can take appropriate action? Here's an example I came up against lately. I should probably refactor the code so I don't need to do things this way... but it illustrates the question quite well. I have a ComboBox

Fwd: Connecting signal to destruction of an object - or - self-destructing handlers

On 5 July 2017 at 12:49, Murray Cumming <murr...@murrayc.com> wrote: > On Tue, 2017-07-04 at 09:44 +0100, Daniel Boles wrote: > > How/can I receive an event when some object of my choice is > > destroyed, so that I can take appropriate action? > > > > Here's an ex

Uses for passing RefPtr as const

In some cases when a signal handler takes a RefPtr const&, it only ever needs to observe the object, so it would seem simpler to pass a normal const& reference. What's the normal reason for passing a RefPtr const&? To me it would express 'This thing is reference counted, and you can add a

Re: Fwd: Connecting signal to destruction of an object - or - self-destructing handlers

Thanks for pondering anyway! I'm glad I came up with a better way to do this. :D It's more complex on the (S)CSS side, but avoids shenanigans with StyleContext in widget code. ___ gtkmm-list mailing list gtkmm-list@gnome.org

Re: Why do Glib::ustring::operator[] and at() return values, not references?

On 28 June 2017 at 10:47, Jonathan Wakely <gt...@kayari.org> wrote: > On 28 June 2017 at 09:39, Daniel Boles wrote: > > But the main drawback I could think of is this: It would change semantics > > for anyone currently using auto some_character = non_const_ustring[N], as &

Re: Why do Glib::ustring::operator[] and at() return values, not references?

On 28 June 2017 at 10:51, Daniel Boles <dboles@gmail.com> wrote: > Yeah, I thought about that briefly but forgot by the time I was writing > the email. I wonder whether sigc::trackable can help here, although maybe > that's getting too complex to be worthwhile. > In fac

Re: C++/Gtkmm/XML compared to C#/WPF/XAML

Just for emphasis On 27 April 2017 at 14:09, Bill William wrote: > really wish gtkmm would specific an XML language for specifying the > instantiation of gtkmm GUI objects without the need of glade > It does. It's called Gtk::Builder (i.e. GtkBuilder). > Really wish

Re: Pointer casting related question

On 7 August 2017 at 14:59, Chris Vine wrote: > A static cast will carry out pointer adjustment when traversing an > inheritance graph to account for multiple inheritance or a vtable. It > is reinterpret cast which will not. > Indeed, thanks. I was only half-thinking at

Re: Pointer casting related question

use Glib::RefPtr::cast_dynamic(source_refptr) or cast_static if you can guarantee that the cast is valid, does not require adjustment for multiple/virtual inheritance, and don't want the (probably insignificant) overhead of a checked cast. see:

Re: Pointer casting related question

On 7 August 2017 at 13:55, gustav iv wrote: > Hi, > > After a compilation trying of a sockets example code ( > https://goo.gl/ddDE8u), some errors gone.. and among them, a the pointer > casting related one that I cannot solve by myself. > It looks to me like the root of

Fwd: Replacing old C-style casts with static|reinterpret_cast?

On 10 May 2017 at 20:51, Chris Vine wrote: > > I don't have any recommended reading I am afraid. The ability to use C > casts to cast from derived to private base is required by these words > in §5.4/4 of C++14, in describing the behaviour of C casts: "The same >

Fwd: Replacing old C-style casts with static|reinterpret_cast?

On 10 May 2017 at 17:45, Nicklas Karlsson wrote: > > Murray mentioned on a Bugzilla that replacing these with static_cast<> is > > always good. > > I think static_cast<> is very clear with what happens, data should not be > changed just intepreted as the wanted

Replacing old C-style casts with static|reinterpret_cast?

Murray mentioned on a Bugzilla that replacing these with static_cast<> is always good. Is the same true for cases where we need reinterpret_cast<> ? That is semi frequent because GTK+ types are opaque even to us, so converting pointers cannot use static_cast<> as the latter cannot verify that

Is it safe to static_cast<> Glib::VariantBase to a derived type?

e.g. in a signal handler that receives a VariantBase that I know is of a specific type (e.g. because I registered that type on the action) It seems to be working for me, so far, but I feel like I might be skipping some GLib magic and living on borrowed time... such as the added stuff in

Re: Replacing old C-style casts with static|reinterpret_cast?

On 10 May 2017 at 20:15, Chris Vine wrote: > > You can use reinterpret_cast when casting between C types which employ > "C style" inheritance (that is, where the "parent" is a struct which is > the first member of the "child" struct). This is because C structs are > of

Re: Replacing old C-style casts with static|reinterpret_cast?

On 10 May 2017 at 20:24, Daniel Boles <dboles@gmail.com> wrote: > > Do you have any recommended reading on the cases which C casts can handle, > and adjust as required, but reinterpret_cast<> cannot? That was surprising > to me as I thought the C++ casts could cover

Re: Gtk::Application::get_default segfault on exit

On 20 June 2017 at 22:22, David Mugnai wrote: > but it segfaults when closing the window (in app->run()) if > "Gtk::Application::get_default();" has been called. > [...] Valgrind reports several invalid reads, this is the first one: > >==26534== Invalid read of size 8 >

Re: Gtk::Application::get_default segfault on exit

That patch was included in glibmm 2.50.1, released on 2017-04-04. So if you have an older version, it's almost certainly that. What version do you have there? (It'll also be in glibmm 2.52, the new but API-fluid stable branch, although a stable release of that has not been made yet.)

Re: Gtk::Application::get_default segfault on exit

On 20 June 2017 at 22:56, David Mugnai wrote: > Excerpts from Daniel Boles's message of June 20, 2017 11:47 pm: > >> That patch was included in glibmm 2.50.1, released on 2017-04-04. So if >> you >> have an older version, it's almost certainly that. What version do you >> have >>

Re: Gtk::Application::get_default segfault on exit

On 21 June 2017 at 20:34, Daniel Boles <dboles@gmail.com> wrote: > > (Obviously you can't use an unnamed temporary for this...) > Well, you could, but it would still be pointless to call the function in the first place if you never do anyt

Re: Gtk::Application::get_default segfault on exit

Of course, you can both work around this until your distro gets the new version of glibmm, by manually adding a the_refptr->reference() before it gets destroyed. If your source might be build on arbitrary machines, then this workaround could be made conditional on the glibmm version using a macro.

Re: Why do Glib::ustring::operator[] and at() return values, not references?

On 24 June 2017 at 19:12, Chris Vine wrote: > On Sat, 24 Jun 2017 19:08:36 +0100 > Chris Vine wrote: > > > It is because UTF-8 is a multibyte encoding, and any one character may > > require between 1 and 5 bytes to represent it. If you were

Why do Glib::ustring::operator[] and at() return values, not references?

Title says it all really. I had to use an std::string in one place because I needed to modify it quickly and with less hassle than using .replace() - and Glib::ustring won't let me get a reference to perform such modification. The documentation states "No reference return; use replace()

Fwd: enums that are really just sets of constants

On 23 May 2017 at 15:12, Kjell Ahlstedt wrote: > > I don't understand how you can have, for instance > void f(ResponseType r); > if ResponseType is an uninstantiable class. If ResponseType is the name of > a class, and you want to treat it as if it were the name an

Re: Replacing pointers with references for output parameters

On 24 May 2017 at 17:23, Daniel Boles <dboles@gmail.com> wrote: > Also, in the case of SpinButton::signal_input(), it should return a bool, > but it currently returns a plain int. I guess it was hastily wrapped, way > back when. > Ah. It is documented as being ab

Re: Replacing pointers with references for output parameters

Also, in the case of SpinButton::signal_input(), it should return a bool, but it currently returns a plain int. I guess it was hastily wrapped, way back when. ___ gtkmm-list mailing list gtkmm-list@gnome.org

Re: Replacing pointers with references for output parameters

OK, I'll take a look, and compare to functions/signals that currently already convert pointers to references where appropriate. Another notable case where pointers are received in callbacks are where GdkEvent structures are used, but I presume that will not be an issue once the new Event class

M4-converting gsize to std::size_t

There are a few uses of the GLib typedef gsize in glibmm et al. I presume it would be safe to provide an M4 conversion from this to std::size_t? Do you think that would be good? To me, it seems nicer to use the C++ standard type. ___ gtkmm-list mailing

Re: Replacing old C-style casts with static|reinterpret_cast?

Murray and Kjell: Any thoughts on the prospect of replacing C style casts with reinterpret_cast where appropriate? Chiefly, when converting between opaque (and thus not static_castable, and also probably breaking aliasing rules...) pointers to GObjects at different levels of the inheritance

Re: Making use of move semantics?

On 22 May 2017 at 11:23, Jonathan Wakely <gt...@kayari.org> wrote: > On 21 May 2017 at 10:36, Daniel Boles wrote: > >> I still occasionally find myself reflexively std::move()ing strings into >> glibmm/gtkmm functions that I unconsciously see as taking ownership of &

Making use of move semantics?

I still occasionally find myself reflexively std::move()ing strings into glibmm/gtkmm functions that I unconsciously see as taking ownership of their arguments - only to realise it makes no difference because all of them take strings as const&. This made me wonder whether there are any cases

Re: Making use of move semantics?

On 21 May 2017 at 14:29, Murray Cumming wrote: > > We've already used move/r-value-references in several places, but not > for string arguments. > > I guess we might start taking std::string_view with C++17 instead of > std::string and this might largely take care of this. >

Re: M4-converting gsize to std::size_t

On 29 May 2017 at 15:32, Murray Cumming <murr...@murrayc.com> wrote: > On Fri, 2017-05-26 at 22:11 +0100, Daniel Boles wrote: > > There are a few uses of the GLib typedef gsize in glibmm et al. > > > > I presume it would be safe to provide an M4 conversion from this

Re: M4-converting gsize to std::size_t

gssize makes me wonder: it's supposed to be equivalent to ssize_t, but that's a POSIX thing, not a C/C++ one. We would probably get away with using std::ptrdiff_t, but I'm not sure anything is strictly guaranteed here:

Re: Compile/link errors with glibmm-2.4 build using jhbuild

Hm, the undefined references do not occur when building without LTO. I'm using g++. I wonder if this might be a bug with the compiler/linker itself somehow. Though I don't think any relevant packages have been updated recently, so it seems unlikely. ___

Compile/link errors with glibmm-2.4 build using jhbuild

Before, I was getting a missing symbol at runtime for this: Gio::ActionMap::add_action(Glib::ustring const&, sigc::slot const&) This was perhaps due to needing this fix that I just committed:

Re: Compile/link errors with glibmm-2.4 build using jhbuild

On 1 June 2017 at 10:59, Kjell Ahlstedt wrote: > I pulled your latest patches from the glibmm-2-52 branch and built it > successfully with g++. > > There is both Gio::Application in glibmm and and Gtk::Application in > gtkmm, but there is only Gtk::TreeModel. Glibmm does

Re: enums that are really just sets of constants

On 6 May 2017 at 18:23, Nicklas Karlsson wrote: > I think C-style enums lack possibility to specify how many bits should be > used for storage which is useful then decoding from some kind of raw data. No, the underlying type can also be specified for plain enums

Re: enums that are really just sets of constants

On 4 May 2017 at 15:24, Kjell Ahlstedt wrote: > Have we decided what to do? According to other posts in this thread there > are 4 possibilities: > > 1. Old-style enums inside a class. > 2. constexpr int constants inside a class. > 3. Old-style enums inside a namespace. >

Replacing pointers with references for output parameters

Some things like Gtk::SpinButton::signal_input() still take pointers in order to write output parameters. In this case, there's a double* new_value, which users must write back to with the converted value represented by whatever string was typed in: *new_value = get_value(blah) It would be

Re: Why do Glib::ustring::operator[] and at() return values, not references?

I wonder, would anyone be interested in adding a proxy class, to be returned by operator[] and .at() on a non-const ustring, which would provide operator gunichar() and operator=()? It would then hold a reference to the string and the index with which it was instantiated, and delegate to

Re: gtkmm 3.24 or new API in gtkmm 3.22?

On 15 September 2017 at 11:34, Murray Cumming <murr...@murrayc.com> wrote: > On Fri, 2017-09-15 at 11:29 +0100, Daniel Boles wrote: > > Sorry if it was already discussed - I feel like it probably was, but > > can't see it right now. > > > > Even though GTK+

Re: gtkmm 3.24 or new API in gtkmm 3.22?

Sorry if it was already discussed - I feel like it probably was, but can't see it right now. Even though GTK+ has no plans for versions > 3.22, couldn't gtkmm branch and have an 'almost-stable' gtkmm-3-24, etc of its own for changes that are fairly innocuous, but which you still don't want in

Re: TreeModel

It would certainly help if you show an excerpt of what kind of data you currently add, and how. Then we can figure out how to make that into something loopable. Generally, though, I think the idea would be that you would define a struct containing the data you want to insert, then loop over a set

Re: Glib::RefPtr

If you want to keep the models around, then you should keep a RefPtr to them around, so that you hold an extra reference to stop them being destroyed. FlowBox should only destroy the binding, not the model itself; if the latter occurs, it must be a result of you not having kept a reference to the

Re: Glib::RefPtr

How do you create m_pFrame, and what do you do with it between creating it and finding it to be 0? It sounds to be like you might be Gtk::manage()ing it and then adding it to a container, in which case, that container sinks the floating reference and takes over ownership completely. If so, you'd

Re: Glib::RefPtr

Well, there is always operator->() ... but what kind of object are you wanting to copy? There's a good chance it doesn't have the right semantics for that. Most mm objects are not copyable, just movable. (And most GObjects aren't copyable either; properties are not the only state they hold.)

Re: Glib::RefPtr

I've taken a look at this and think it's intentional and fairly clear: - GTK+ and gtkmm both refer to the slot as "a slot that creates widgets". i.e. creates, for the FlowBox's consumption. Not a slot that returns a reference to a widget that already existed for some other purpose. -

Re: Glib::RefPtr

On 8 October 2017 at 16:59, Phil Wolff wrote: > I have neglected to mention the slot argument: > > m_pFlowBox->bind_list_store ( m_refCurrentModel, sigc::mem_fun ( > *this, ::OnContentCreate () ) ); > For clarity: the invalid function call () on the

Re: Glib::RefPtr

Cool, hope you figure out something that works! ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Glib::RefPtr

I suppose another option is that you would setup all the widgets you need, manually add them to the FlowBox (no model-binding), and update their attributes as you detect changes in the model. It could be very manual, but maybe worth it if performance is otherwise less than you want to accept.

  1   2   3   >