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 Gtk

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

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 widgets); > Gtk::Box::pack_start(std::initializer_

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 struct/clas

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 http://stackoverflow.com/questions/22895

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

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

On 13 March 2017 at 21:46, Daniel Boles 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 it does > I really m

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 can

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 > needing a different c

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 the

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 you

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 will be maintained for some tim

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 development of GTK+ 4. As far

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 easily:- > > Glib::ustrin

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

Fwd: FileChooserDialog constructors taking backend argument

On 27 March 2017 at 12:50, Kjell Ahlstedt 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 >> >> Clearly these con

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

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: 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 implemented. I > added thi

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 free to > add API in the

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: 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 > target=resource.c

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

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

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 not aware of any API/AB

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 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 > confusion. We should release 2

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 keeping the new-style

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 glade and GTKMM would get

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. > 4. constexpr int constant

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 too. Try it: enum MyPlainEnum: u

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

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 type. There are cases then exactly

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 cast_dynam

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 necessity standard layout

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

On 10 May 2017 at 20:24, Daniel Boles 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 all the angles. > Sor

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 > semantic restrictions and behav

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 hierarc

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 where

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: Making use of move semantics?

On 22 May 2017 at 11:23, Jonathan Wakely 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 >> their arguments - onl

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 enum, wouldn't > it require s

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 cleaner

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

Re: Replacing pointers with references for output parameters

On 24 May 2017 at 17:23, Daniel Boles 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 able to return a Gtk::INPUT_ERROR, so tha

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 hi

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 l

Re: M4-converting gsize to std::size_t

On 29 May 2017 at 15:32, Murray Cumming 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 to > > std::size_t? Do y

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: https://stackoverflow.com/questions/8649018/what-is-the-difference-between-ssize

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: https://git.gnome.org/browse/glibmm/commit/?h=glibmm-2-52&id=f81107735d04569d6a9bd1bf473980f3ef1f1e01

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

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 not depend on gtkmm. > If

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 >==26534==at 0x

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

(sorry for the spam) On 20 June 2017 at 22:43, Daniel Boles wrote: > > meaning that the returned Application is not referenced, and can be > double-freed > specifically, if I'm right, it IS double-freed, plus you try to use it after the 1st free: - you instantiate an un

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

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: Gtk::Application::get_default segfault on exit

On 21 June 2017 at 20:34, Daniel Boles 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 anything with it :P

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

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 allowed to > > change a byte at will you would be able

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

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

On 28 June 2017 at 10:47, Jonathan Wakely 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 > > the auto would

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

On 28 June 2017 at 10:51, Daniel Boles 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 fact, that definitely sound

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 where

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

On 5 July 2017 at 12:49, Murray Cumming 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 example I came up a

gtkmm-list@gnome.org

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 referenc

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

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 objec

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: 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 gtkmm-list@

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

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 s

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 your many messages indicating that you thi

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

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 documentati

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 C++ API expects a string.

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

On 25 July 2017 at 16:02, Daniel Boles 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.54, but it may not always be so

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, in that usually you can

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: https://developer.gnome.org/glibmm/stable/classGlib_

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 your problem is that you

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 the time, and decided to

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

You never move iter beyond children.begin(). ___ 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 gtkmm-list@gno

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: " Now 'Songs' is th

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

For people to suggest a fix, it might help if you explain what you think is broken ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: subclassing glarea

Could you link to the discussion that you mentioned? My guess is that it wasn't a bug report, as I can't find any. My guess is also that if you found that past discussion but couldn't find anything later confirming that it's been fixed, then it hasn't. I don't see how it could be bad to submit a b

Re: subclassing glarea

Hey Marty - thanks, that's useful info. I can't speculate on whether it's related to the problem you're seeing, but it doesn't have the same behaviour, so quite possibly not... Can you post a minimal version of your code, which does compile, but doesn't display anything as you expect? _

Re: Tree View with Tree Model where sub items have their own columns / different structure

What are X, Y, and Z meant to be? Do you mean that you want child items to have different column types from their parents? ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Tree View with Tree Model where sub items have their own columns / different structure

Sure, but that to me is not an issue of the columns (data types of each row), but rather just how you convert a path to its position within the tree, and how nodes are indented relative to each other. The columns will all have the same type, in this case text (and maybe an icon, etc.). Put another

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 the

Re: gtkmm 3.24 or new API in gtkmm 3.22?

On 15 September 2017 at 11:34, Murray Cumming 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+ has no plans for versions &

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: GStreamermm and GitHub

GNOME is aware of the ageing nature of its infrastructure and therefore is moving to GitLab. Nautilus has already moved to the new self-hosted instance. I don't think GIR and C++ are really compatible, though it would certainly be nice to have some more modern basis than m4 macros. :) But I'm prob

  1   2   3   >