Re: mouse button event and gtkmm-4.0

[Andrew Potter via gtkmm-list]

On Mon, Sep 26, 2022 at 10:17 AM Duncan Duncan via gtkmm-list <
gtkmm-list@gnome.org> wrote:

> Could someone explain how to get  event key mouse ?
>
>
Hi,
A question on the list a couple months ago prompted me to make this github
gist:

https://gist.github.com/talisein/f4f80167fa21f329f3db06a2730746f5

In short, you need a Gtk::GestureClick event controller. The current gtkmm
documentation is at
https://gnome.pages.gitlab.gnome.org/gtkmm/classGtk_1_1GestureClick.html

Unfortunately google doesn't like returning the gitlab pages links yet.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Problem with sorting ColumnView

[Andrew Potter via gtkmm-list]

The documentation at
https://docs.gtk.org/gtk4/method.ColumnView.get_sorter.html suggests you
need a SortListModel

On Tue, Aug 23, 2022 at 4:32 AM Jackson Campolattaro via gtkmm-list <
gtkmm-list@gnome.org> wrote:

> Hello,
>
> I'm trying to use the Gtk ColumnView to show a custom ListModel in sorted
> order. I noticed that when I set a simple sorter for a column and then sort
> by that column, the order isn't changed. The UI allows me to switch between
> ascending and descending, but doing so doesn't reverse the list.
>
> I've created a simplified example, which is supposed to show the file
> paths in the current directory in alphabetical order, but doesn't:
>
> #include 
>> #include 
>>
>> class MyWindow : public Gtk::Window {
>> private:
>>
>> Glib::RefPtr> _listModel;
>> Glib::RefPtr _selectionModel;
>>
>> Gtk::ColumnView _columnView;
>>
>> public:
>> MyWindow() {
>>
>> _listModel = Gio::ListStore::create();
>> _selectionModel = Gtk::SingleSelection::create(_listModel);
>> _columnView.set_model(_selectionModel);
>>
>> auto files =
>> Gio::File::create_for_path(".")->enumerate_children();
>> Glib::RefPtr fileInfo;
>> while ((fileInfo = files->next_file())) {
>>
>> _listModel->append(Gio::File::create_for_path(fileInfo->get_name()));
>> }
>>
>> auto _factory = Gtk::SignalListItemFactory::create();
>> _factory->signal_setup().connect([](auto listItem) {
>>
>> listItem->set_child(*Gtk::make_managed("Placeholder!"));
>> });
>> _factory->signal_bind().connect([](auto listItem) {
>> auto data =
>> std::dynamic_pointer_cast(listItem->get_item());
>> auto label = dynamic_cast> *>(listItem->get_child());
>> if (data && label) {
>> label->set_text(data->get_path());
>> label->set_xalign(0);
>> }
>> });
>>
>> auto column = Gtk::ColumnViewColumn::create("File Paths",
>> _factory);
>> _columnView.append_column(column);
>>
>> column->set_sorter(Gtk::StringSorter::create(
>> Gtk::ClosureExpression::create([](auto
>> item) {
>> auto data =
>> std::dynamic_pointer_cast(item);
>> return data->get_path();
>> })
>> ));
>> _columnView.sort_by_column(column, Gtk::SortType::ASCENDING);
>>
>> set_child(_columnView);
>> };
>> };
>>
>> int main(int argc, char *argv[]) {
>> auto app = Gtk::Application::create("org.gtkmm.examples.base");
>> return app->make_window_and_run(argc, argv);
>> }
>>
>
> Perhaps this is a bug, but before I report it I wanted to make sure I'm
> not doing something wrong.
>
> Thanks,
>
> Jackson
> ___
> 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: initialize `background-image` with a resource file

[Andrew Potter via gtkmm-list]

On Tue, Aug 23, 2022 at 10:44 AM Master via gtkmm-list 
wrote:

> The problem is that I dont know how to tell the `background-image` inside
> the style provider to "get the image from resource" instead of "file"
> please help me.
>
Hello,
You can set background image to a resource like:
background-image: url("resource:///org/custom/example/sonbg.jpg");
Of course, you must define a gresource xml (Here, I've used the gresource
prefix org/custom/example, but you will want to use your own namespace),
compile it with glib-compile-resources and include it in your build system
appropriately.

This is detailed in the GResource documentation at
https://docs.gtk.org/gio/struct.Resource.html or in the gtkmm documentation
at
https://gnome.pages.gitlab.gnome.org/glibmm/classGio_1_1Resource.html#details

I have a toy application on github that does this if you need a more
concrete example. The C++ code in
https://github.com/talisein/mikuexpocountdown/blob/main/src/window.h loads
the CSS from a resource, and that css references the gresources in
https://github.com/talisein/mikuexpocountdown/tree/main/res
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: [gtkmm4] Help on DrawingArea plus Mouse Activity

[Andrew Potter via gtkmm-list]

The base gtk documentation will be more informative on how to use the
toolkit in general.
Specifically,
https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-gtkwidget-event-signals
covers how to change event handling.

The relevant event controllers: GestureClick, GestureStylus, GestureDrag
are talked about on this discourse post:
https://discourse.gnome.org/t/handling-both-gesturestylus-and-gesturedrag-for-stylus/9217/7

I decided to learn about this myself, so I reimplemented the example from
that post in gtkmm. I hope it is helpful for you:

https://gist.github.com/talisein/f4f80167fa21f329f3db06a2730746f5
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Unparenting from GtkWidget "destroy"

[Andrew Potter via gtkmm-list]

On Fri, Jul 8, 2022 at 11:10 AM Baldvin Kovacs 
wrote:

>
> The one I linked in the original email follows well the pattern I have:
> https://github.com/baldvin-kovacs/gtkmm-destroy-demo/blob/main/gtkmm-destroy-demo.cc
> . Now I added the #if to make it compile and run without the exposed
> destroy signal.
>
>
Oh I see, sorry; when I first clicked I thought it was just an update to
the examples folder of gtkmm.


> The key to avoid this is to never use the parenting/unparenting of widget
> from C++ code. So as long as you inherit from Box, or a similar container,
> you're good. Then the unparenting is handled in C-land.
>
>

It seems you're right; unparent() is suggested to be called from dispose,
and dispose is not exposed in glibmm. sigc++'s add_destroy_notify_callback
is definitely too late. Widget's destroy signal has existed prior to gtk4
but I see the gtkmm bindings are not wrapping it; nor is the signal
explicitly ignored, so I'm not sure why.
Beyond exposing the destroy signal, another approach might be adding a
virtual dispose method if there is some known problem with sigc++ at this
point in the object lifecycle.

Maybe Kjell knows there is a good reason to not expose signal destroy /
dispose in gtkmm? If so you'd have to settle for subclassing a container,
but otherwise I'd prefer all signals to be available.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Unparenting from GtkWidget "destroy"

[Andrew Potter via gtkmm-list]

On Fri, Jul 8, 2022 at 9:26 AM Baldvin Kovacs 
wrote:

> Andrew Potter  ezt írta (időpont: 2022. júl. 8., P,
> 17:30):
>
>>
>>
>> On Fri, Jul 8, 2022, 4:01 AM Baldvin Kovacs via gtkmm-list <
>> gtkmm-list@gnome.org> wrote:
>>
>>>
>>> 2. Expose the destroy signal handler, and document that one needs to
>>> unparent children both from that, and in the destructor.
>>>
>>
>> Is this a new warning? My initial thought is this should be a feature of
>> Gtk::manage rather than making everybody hook destroy to unparent.
>>
>
> Not really new:
>
> 08d644c4a53 (Timm Bäder 2016-12-07 14:05:34 +0100  7558)
> g_warning ("Finalizing %s %p, but it still has children left:",
> 08d644c4a53 (Timm Bäder 2016-12-07 14:05:34 +0100  7559)
>gtk_widget_get_name (widget), widget);
>
> My hypothesis about why this didn't bother people so far: up until
> recently the normal style even in the core Gtk was to inherit from Box (see
> for example GtkColorChooserWidget). Recently there was a lot of cleanup and
> widgets nowadays directly inherit from GtkWidget. That is the pattern I was
> attempting to follow in my own application as well (it is cleaner: it
> doesn't expose internal implementations through public inheritance, namely,
> that the internal structure of the widget is a box).
>
> Out of the two custom widget examples
> in gtkmm-documentation/examples/book/custom one is a custom widget which
> does painting (and has no child widgets), and the other is using C++
> destructor based destruction mechanism. I assume that not many people were
> trying to do custom widgets _and_ using them in a managed manner.
>

Can you share an example? Is your custom widget implemented in C owned by
something wrapped in gtkmm? Are you focused on gtk3 or gtk4?  I know I've
made some custom widgets and not seen this warning, though I'm not certain
they derived from Widget; I recall there is quite a bit of care put into
handling containers. Gtk4 also got rid of Gtk::Container so the details of
exactly how you're eliciting this will be helpful.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Unparenting from GtkWidget "destroy"

[Andrew Potter via gtkmm-list]

On Fri, Jul 8, 2022, 4:01 AM Baldvin Kovacs via gtkmm-list <
gtkmm-list@gnome.org> wrote:

>
> 2. Expose the destroy signal handler, and document that one needs to
> unparent children both from that, and in the destructor.
>

Is this a new warning? My initial thought is this should be a feature of
Gtk::manage rather than making everybody hook destroy to unparent.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: With set_event_compression, most recent motion event is held in waiting

[Andrew Potter via gtkmm-list]

On Mon, May 23, 2022 at 9:15 AM JLM via gtkmm-list 
wrote:

> I have updated my test. Now you don't have to press a mouse button, but
> you can press a keyboard key instead. The problem isn't that I am
> seeing extra events, the problem is that the extra event seems to be
> hiding, or stuck in a backend/library queue.
>

The issue is probably even lower than GTK. Maybe libinput? Did you look at
the timestamp of the events?

https://wayland.freedesktop.org/libinput/doc/latest/timestamps.html

The above link suggests some events are delivered out of order
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: SSL certificate error

[Andrew Potter via gtkmm-list]

On Wed, Oct 13, 2021 at 12:12 AM Kjell Ahlstedt via gtkmm-list <
gtkmm-list@gnome.org> wrote:

> I thought you were using ssh. If you use https, the expired ssl
> certificate is perhaps on the server side, i.e. a problem at gnome.org. I
> tested by downloading a clone of gtkmm with https today. It succeeded.
> Could it have been a problem that has now been fixed?
>
> Kjell
>
It looks like gnome.org's certificate is from Let's Encrypt which had a
root expiry recently. Updating your system's trusted CA certificates may
resolve the issue. If you are using an uncommon git client, perhaps its SSL
library is not interpreting cross-signed certificates incorrectly.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Failure to add radio buttons to popup menu.

[Andrew Potter via gtkmm-list]

On Tue, Dec 8, 2020 at 7:24 AM Carlo Wood  wrote:

> On Tue, 8 Dec 2020 08:41:58 +0100
> Kjell Ahlstedt  wrote:
>
> > I don't know if it works with a file that glade has written.
>
> That sounds like you don't support glade. I am confused, because
> I thought that glade was the defacto standard that Gnome wants
> users to generate user interfaces.
>

Glade does not support GMenu/GMenuModel, see the first item in their TODO:
https://gitlab.gnome.org/GNOME/glade/-/blob/master/TODO

Your original code was defining a GMenu/Gio::Menu, which Kjell fixed up.

Your new glade generated GtkMenu xml could work, but you'd need to rewrite
the driving c++ code to expect those items to be GtkMenuItems. Additionally
you probably need to Gtk::RadioMenuItem::set_group as it seems undefined in
glade's xml.

I recommend reading:
https://developer.gnome.org/GMenu/
https://wiki.gnome.org/HowDoI/GAction
https://blogs.gnome.org/christopherdavis/2020/11/19/glade-not-recommended/
https://www.gnome.org/news/2020/11/gtk-at-the-heart-of-gnome/ (new UI
design tool on the way)

A bug?
>
As gtkmm is just a binding, in a case like this you'd need to show
something working in straight C but failing in C++.

I think you should accept Kjell's solution. If you really want a GtkMenu
created via GtkBuilder then another simple solution would be to use Kjell's
xml but add a GtkMenu with its model set to Kjell's GMenu.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::Builder::get_widget_derived() Issue on Fedora 33

[Andrew Potter via gtkmm-list]

I believe this is caused by https://fedoraproject.org/wiki/LTOByDefault

I built the srpm and noticed that the get_type() calls were present in
wrap_init.o but was missing from the .so

I added
%define _lto_cflags %{nil}
to the gtkmm .spec file and rebuilt--this disables LTO; the get_type() were
then present in the .so

I've left a comment at Fedora's bug tracker for them to disable lto in mm
packagesI've left a comment at Fedora's bug tracker for them to disable lto
in mm packages. But if we used g_type_ensure() then LTO would be possible I
think
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::Builder::get_widget_derived() Issue on Fedora 33

[Andrew Potter via gtkmm-list]

On Tue, Nov 17, 2020 at 6:51 AM Kjell Ahlstedt 
wrote:

> wrap_init.cc contains the following lines:
> #undef  G_GNUC_CONST
> #define G_GNUC_CONST /* empty */
>
Oh, right. I see this in Fedora's rpm debug source. I also see the calls to
Gtk::TextView::get_type in the debug source. However, when I objdump -C -S
/usr/lib64/libgtkmm-3.0.so.1.1.0 I see the calls are definitely not made
from Gtk::wrap_init (I've included a snippet of the end of the objdump
below.

I split the TVDerived class into a separate source and header file and made
an init() function that calls TVDerived::get_type(), undef'd G_GNU_CONST
and compiled it to a shared library... but actually the undef is working;
when undef'd the get_type() call is made and the gtkmm type gets printed
out. If I don't undef then the get_type call is not made and only
GtkTextView gets printed.

So... I guess this isn't a simple problem to verify the root cause. I think
I'll need to build gtkmm from source, capture the exact compiler and linker
parameters etc... I'll try this weekend.


objdump output, the tail end of Gtk::wrap_init has the last wrap_register,
but no e.g.  jmpq   60e0 :

   Glib::wrap_register(gtk_window_group_get_type(),
_Class::wrap_new);
  32d1d1:   e8 9a cd ed ff  callq  209f70

  32d1d6:   48 8b 35 1b 7e 11 00mov0x117e1b(%rip),%rsi#
444ff8 
  VolumeButton::get_type();
  Widget::get_type();
  Window::get_type();
  WindowGroup::get_type();

} // wrap_init()
  32d1dd:   48 83 c4 08 add$0x8,%rsp
  Glib::wrap_register(gtk_window_group_get_type(),
_Class::wrap_new);
  32d1e1:   48 89 c7mov%rax,%rdi
  32d1e4:   e9 a7 75 ee ff  jmpq   214790

  32d1e9:   90  nop
  32d1ea:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)

0032d1f0 :
AccelKey::AccelKey(const Glib::ustring& accelerator, const Glib::ustring&
accel_path)
  32d1f0:   41 55   push   %r13
: path_(accel_path)
  32d1f2:   4c 8d 6f 08 lea0x8(%rdi),%r13
AccelKey::AccelKey(const Glib::ustring& accelerator, const Glib::ustring&
accel_path)
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::Builder::get_widget_derived() Issue on Fedora 33

[Andrew Potter via gtkmm-list]

On Tue, Nov 17, 2020 at 12:01 AM ahmet öztürk  wrote:

> Is this a Gtkmm issue then? Fedora guys also think that it is an upstream
> issue. See:https://bugzilla.redhat.com/show_bug.cgi?id=1898054
>
But why does it only occur on Fedora 33?
>

Likely its due to a new optimization in gcc 10 which few other distros are
using yet.
Since the GtkFoo::get_type() calls in wrap_init() are not using the return
value, it makes sense to me that they are eligible for dead code
elimination, as is suggested in the blog post. Since Gtkmm is calling these
methods explicitly to ensure the GTypes are made known, I think fixing it
in Gtkmm by adding g_type_ensure() is the path of least resistance.

@Andrew, I do not know how I am supposed to use
> g_type_ensure(TVDerived::get_type()). I am not familiar with Gtk+ or
> GObject, I have only used Gtkmm, so far.
>

You can simply replace TVDerived dummy; with
g_type_ensure(TVDerived::get_type()); in your example program.

For a more professional look, you can define an init() function that calls
g_type_ensure() for all of your custom derived types and call it in
main()--but I guess you should explicitly call
Gtk::Main::init_gtkmm_internals() before your init() ala
https://developer.gnome.org/gtkmm-tutorial/stable/sec-wrapping-initialization.html.en
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::Builder::get_widget_derived() Issue on Fedora 33

[Andrew Potter via gtkmm-list]

I think the cause is the G_GNUC_CONST annotation on TextView::get_type().

When I step through the code on Fedora 33, in Gtk::wrap_init, all the
wrap_registers happen, but the function just returns, skipping the calls to
e.g. TextView::get_type()

Ahmet can use g_type_ensure(TVDerived::get_type()) rather than default
constructing the class.

I think the best fix would be to wrap all the GtkFoo::get_type() calls in
Gtk::wrap_init with g_type_ensure. See
https://blogs.gnome.org/mcatanzaro/2015/09/14/your-_get_type-function-is-not-g_gnuc_const/

On Sun, Nov 15, 2020 at 11:56 PM ahmet öztürk via gtkmm-list <
gtkmm-list@gnome.org> wrote:

> Hi Kjell,
>
> Thank you for the response. I tried your suggestion and the outputs were
> exactly as you guessed. So, this seems like a Fedora specific issue. I will
> be filing a bug report there.
>
> Kjell Ahlstedt , 15 Kas 2020 Paz, 15:19
> tarihinde şunu yazdı:
>
>> On 2020-11-14 14:56, ahmet öztürk via gtkmm-list wrote:
>> > Hi all,
>> >
>> > On Fedora 33, derived widgets does not seem to be constructed properly
>> > by Gtk::Builder::get_widget_derived(). The reason I think so is that
>> > the overridden methods are not called for these widgets. Apart from
>> > that everything seems normal. No error message or anything.
>> >
>> > I attached a sample code with a very simple case to replicate this
>> > problem. on_button_press_event() is never called for the derived widget.
>> >
>> > I have also noticed that if a dummy instance of the derived widget is
>> > created separately (using another constructor) before calling
>> > Gkt::Builder::add_from_string(), then the widget created by Builder
>> > also works normally.
>> >
>> > Please note that this may not occur on all distributions. e.g. I know
>> > that it does not occur on Arch Linux.
>> >
>> > Does anybody know if this a Fedora 33 specific issue or is it due to a
>> > recent update in Gtkmm that is only affecting Fedora for now?
>> >
>> The issue does not occur on Ubuntu 20.04 with the latest gtk+3 and
>> gtkmm3 from the git repo.
>>
>> It looks as if the gtkmm__GtkTextView class has not been registered in
>> the GType system before get_widget_derived() is called. That should have
>> been done by Gtk::wrap_init() which is called from
>> Gtk::Application::create().
>>
>> You can test if I'm right. Add
>> std::cout << "GType name: " <<
>> G_OBJECT_TYPE_NAME(m_TextView->gobj()) << std::endl;
>> after the call to get_widget_derived(). When the overloaded function is
>> not called, I suspect that the output will be
>> GType name: GtkTextView
>> When you've uncommented TVDerived dummy;, and everything is okay, the
>> output is probably
>>GType name: gtkmm__GtkTextView
>>
>> If I'm right, it looks like a Fedora specific issue. It can't be due to
>> a recent update in gtkmm (I've tested with the very latest one), unless
>> there is some Fedora specific update.
>>
>> ___
> 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: Cannot Initialize GValue with type 'gfloat'

[Andrew Potter]

On Sun, Apr 17, 2016 at 11:40 AM, Cole Bush  wrote:
> Glib-GObject-WARNING **: /file/path/gvalue.c:181: cannot initialize GValue
> with type 'gfloat', the value has already been initialized as 'gfloat'

Looks like Gst::ValueList::get() calls Glib::Value::init() which
should only be done once. Since you are in a loop, it is done more
than once. Looks like the glibmm doesn't have g_value_unset() wrapped.
You can put g_value_unset(mag.gobj()) at the top of your loop. Or you
can put the the GLib::Value mag declaration at the top of your
loop.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm Monitoring IO example

[Andrew Potter]

On Fri, Sep 25, 2015 at 8:02 AM, Chris Vine  wrote:
> On Fri, 25 Sep 2015 15:13:48 +0200
> Kjell Ahlstedt  wrote:
>> When I tested the input example program on my dual-core PC, I got the
>> same result: The CPU load on one of the cores is 100% after something
>> is written to the fifo. Most of the relevant code is in glib. I don't
>> know all details, but this is what I found:
>>
>> Before anything is written to the fifo, the program waits at
>> read_fd = open("testfifo", O_RDONLY);
>> without using much CPU time (perhaps no time at all).
>> Once the fifo contains data to read, open() returns, and the program
>> enters the main loop at
>> app->run();
>
> Assuming we are talking about a unix-like system, it certainly isn't.
> glib will either call poll() or select() and block in a separate i/o
> thread, and I think it is poll() which it uses.  Neither should busy
> wait, assuming the waiting input is correctly extracted from the file
> descriptor which has become ready.

The problem is that there is an Glib::IO_HUP event constantly
generated on the fifo once the first writer disconnects (the first
echo).

I guess this stackoverflow answer describes the problem:
https://stackoverflow.com/questions/22021253/poll-on-named-pipe-returns-with-pollhup-constantly-and-immediately

So basically glib's call to poll() is always returning immediately
because it is sensitive to IO_HUP. I can't find an obvious way to make
it insensitive to this signal.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Gtk::Treeview colour only 2 rows of alls rows

[Andrew Potter]

On Fri, Aug 28, 2015 at 7:28 AM, Alfredo Pons alfredo.p...@gmail.com wrote:
 I want colour only 2 rows of alls rows of a Gtk::Treeview in gtkmm3,
 but I not find good examples in internet about this.

I think you will have to either (1) add each column with a custom
cellrenderer or (2) use normal cellrenderers but use
Gtk::TreeViewColumn::set_cell_data_func().

If the background color of the row can be derived from the state of
the object a cellrenderer is drawing, you can use (1). Otherwise use
(2).

Example for (1):
I have a project that has a custom cellrenderer for a single column. A
lot of the code around it is needlessly complex, so try to only look
at the cellrenderer bits if you can!
https://github.com/talisein/mal-gtk/blob/master/src/gui/fancy_label.cpp
lines 103-138 shows defining a custom CellRendererText that changes
the background color based on the value of the text (ignore the
render_vfunc, you don't want rounded edges).
https://github.com/talisein/mal-gtk/blob/master/src/gui/anime_list_view.cpp
lines 244-255 show how to add the cellrenderer to the ListView (very
simple).
A screenshot of the result (type column)
https://raw.githubusercontent.com/talisein/mal-gtk/master/images/animelist.jpg

Instructions for (2):
You can use Gtk::TreeViewColumn::set_cell_data_func(). Basically in
your GtkTreeCellDataFunc, use the GtkTreeIter* to figure out what
color the row should have, and set the background_rgba property on the
passed GtkCellRenderer appropriately. I think you will also have to
set the normal property (e.g. set the 'text' property for a
CellRendererText).
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: C++11: Deprecate Glib::Threads

[Andrew Potter]

On Wed, Aug 26, 2015 at 1:20 PM, Murray Cumming murr...@murrayc.com wrote:
 I'm starting to learn about the new concurrency APIs in C++11. I wonder
 if we could soon deprecate Glib::Threads, which wraps the glib threads
 API. Thoughts?
 https://developer.gnome.org/glibmm/stable/group__Threads.html

Keep in mind Reader/Writer locks are only in C++14; do the current
major distros stable versions have a GCC new enough that users could
update their code to avoid the depreciation warning?

 Maybe we'd want to reimplement Glib::Dispatcher, which has no
 corresponding API in glib, using C++11 concurrency APIs instead of
 Glib::Threads.

I'd be interesting in seeing what a Dispatcher API with promise/future
etc would look like, but I don't think there is anything that would
replace the pipe mechanism to signal the GMainLoop; so rather than
reimplementing it you might just be adding some new methods? Or am I
missing something? I doubt you mean to add an idle handler to
std::for_each(begin(futures_list), end(futures_list), [](auto
future){ if (future_status::ready ==
future.wait_for(duration::seconds(0))) { ... } })
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: C++11 features, move semantics?

[Andrew Potter]

On Sat, Aug 1, 2015 at 7:49 AM, Hubert Figuière h...@figuiere.net wrote:
 On 31/07/15 03:16 AM, Murray Cumming wrote:
 Does anyone see any need for this in gtkmm?

 In theory, I guess we could make Gtk::Widget movable but not copyable,
 so we could do things like this sometimes:


 I believe making Gtk::Widget movable (but not copyable) has a benefit
 and could be implemented without too much confusion if we are able to
 deal with moved Gtk::Widget properly - ie let the programmer know of
 the error (like when attenmpting to perform something with a Gtk::Widget
 no longer valid since we move it).

I'd also like to see a movable Widget. It's not something I'd need
every day, but
it is really nice to have the flexibility to do a little more
unorthodox things when you
need to.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

std::auto_ptr deprecation warning in libstdc++ 5.1

[Andrew Potter]

Hi everybody,

As you probably know, std::auto_ptr got deprecated in the C++11
standard and is scheduled for removal in C++17. After upgrading to
Fedora 22, I see that g++ is now issuing a warning when it sees use of
std::auto_ptr. Unfortunately there is one in glibmm's objectbase.h:

In file included from /usr/include/glibmm-2.4/glibmm/object.h:29:0,
 from /usr/include/giomm-2.4/giomm/simpleaction.h:27,
 from application.cpp:19:
/usr/include/glibmm-2.4/glibmm/objectbase.h:215:13: warning:
‘templateclass class std::auto_ptr’ is deprecated
[-Wdeprecated-declarations]
 static std::auto_ptrThreads::Mutex extra_object_base_data_mutex;
 ^
In file included from /usr/include/c++/5.1.1/memory:81:0,
 from /usr/include/glibmm-2.4/glibmm/objectbase.h:32,
 from /usr/include/glibmm-2.4/glibmm/object.h:29,
 from /usr/include/giomm-2.4/giomm/simpleaction.h:27,
 from application.cpp:19:
/usr/include/c++/5.1.1/bits/unique_ptr.h:49:28: note: declared here
   templatetypename class auto_ptr;
^

I don't think this is fully resolvable until the next ABI/API break
(which maybe we should think about in the 2017 timeframe?), but in the
meantime, does anyone have a clever idea to hide this particular
warning without disabling -Wdepreciated-declarations altogether? Or
maybe we can make some ABI-compatible Glib::auto_ptr ?
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: How do I construct object paths and signatures?

[Andrew Potter]

On Fri, Dec 5, 2014 at 12:24 AM, Jonatan Pålsson
jonatan.pals...@pelagicore.com wrote:
 Hi list,

 I'm writing some D-Bus code using Glibmm, and I would like to construct
 object paths and signatures, but I can't figure out how to construct them.

Hi,
You can use the static method
Glib::VariantStringBase::create_object_path() and create_signature()

See 
https://developer.gnome.org/glibmm/stable/classGlib_1_1VariantStringBase.html#af0fc3a17ced885820fba0d0303c075fb
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Question about glibmm/Glib::ustring::format

[Andrew Potter]

On Sun, Feb 9, 2014 at 4:14 AM, Waitman Gobble uzi...@da3m0n8t3r.com wrote:
 Program received signal SIGABRT, Aborted.
 [Switching to Thread 803006400 (LWP 100327)]
 0x000801e313ba in kill () from /lib/libc.so.7
 (gdb) bt
 #0  0x000801e313ba in kill () from /lib/libc.so.7
 #1  0x000801e30069 in abort () from /lib/libc.so.7
 #2  0x0008016ce7da in ?? () from /lib/libcxxrt.so.1
 #3  0x00080085de68 in Glib::ConvertError::throw_func(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1
 #4  0x00080086ed2f in Glib::Error::throw_exception(_GError*) ()
from /usr/local/lib/libglibmm-2.4.so.1
 #5  0x00080087bcc2 in Glib::ustring::FormatStream::to_string() const ()
from /usr/local/lib/libglibmm-2.4.so.1
 #6  0x00401de0 in Glib::ustring::formatstd::__1::ios_base
 (std::__1::ios_base), std::__1::__iom_t5, double(std::__1::ios_base (
 const)(std::__1::ios_base), std::__1::__iom_t5 const, double const) (
 a1=@0x401e50: {std::__1::ios_base (std::__1::ios_base )} 0x401e50
 std::__1::fixed(std::__1::ios_base), a2=..., a3=@0x7fffd860:
 3.1428571428571428)
 at /usr/local/include/glibmm-2.4/glibmm/ustring.h:1158
 #7  0x00401696 in main () at testglib.cpp:9
 (gdb)

The code works fine for me, but I'm on Linux.
FormatStream::to_string() has plenty of #ifdefs so its not entirely
obvious what's happening.

Can you catch the exception and print out the Glib::Error::what() ?

Thanks.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Connecting to Configure signal event

[Andrew Potter]

On Wed, Nov 27, 2013 at 11:18 AM, a vis.314...@gmail.com wrote:
 On 11/27/2013 12:59 PM, Kjell Ahlstedt wrote:
 2013-11-26 22:37, a skrev:
 On 11/26/2013 08:33 AM, Kjell Ahlstedt wrote:
 2013-11-26 05:09, a skrev:
 Here is the small program where the Gtk::Entry does not increase when window
 increases.

 //Example.cc

 ExampleWindow::ExampleWindow()
 : m_VBox(Gtk::ORIENTATION_VERTICAL),
   m_HBox_entry(Gtk::ORIENTATION_HORIZONTAL),
   m_Label(Label)
 {
   set_size_request(200, 100);
   set_title(Gtk::Entry);

   add(m_VBox);

   m_HBox_entry.set_halign(Gtk::ALIGN_CENTER);

If the HBox alignment is not set to Gtk::ALIGN_FILL (as it is by
default), the box will only be the minimum required sized for its
children.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: widget for data graph

[Andrew Potter]

On Sun, Nov 24, 2013 at 11:44 AM, Kevin Brightwell
kevin.brightwe...@gmail.com wrote:
 On Sun, Nov 24, 2013 at 2:42 PM, Renato Merli merli.ren...@gmail.com
 wrote:
   Does anyone know ready widget for data presentation ? bar / lines /etc ?

You might try to reuse GNOME Power Manager's graph widget. It's in C,
and looks like it only does points and lines, though.

https://git.gnome.org/browse/gnome-power-manager/tree/src
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: gtkmm 3 on Windows (Win32)

[Andrew Potter]

On Mon, Oct 28, 2013 at 6:49 AM, Murray Cumming murr...@murrayc.com wrote:
 There are now finally official binaries of GTK+ 3 for Windows,
 and it seems like there's a good chance that they will be maintained:
 http://www.gtk.org/download/win32.php

 So is there anyone here who would like to update the gtkmm Windows
 binaries?

The guy who's taken charge of maintaining the Windows binaries has
made gtkmm binaries in the past: http://www.tarnyko.net/en/?q=node/23

Maybe you should reach out to him, he probably just needs commit
access to gtkmm.org

 However, maybe, like GTK+, we don't want an actual installer anymore. Or
 at least, we could keep that for later.

Seems logical to mirror however GTK+ is distributed, since it will be
a dependency anyways.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Missing Icons from Widgets...

[Andrew Potter]

On Wed, Oct 16, 2013 at 1:11 AM, Glus Xof gtg...@gmail.com wrote:
 Hi guys,

 Probably, I'm a little lost, sorry... but I think that you should know
 something about these icons that appear in wigets (like Gtk::Entry,
 Gtk::SpinButton...) and since this last release Gtkmm 3.10.0 they figure as
 missing.

This likely stems from a change in GTK+. There is a very long
discussion on the gtk-devel mailing list starting here:

https://mail.gnome.org/archives/gtk-devel-list/2013-October/msg00051.html

Long story short, for now you'll need to manually set the
always-use-image and always-show-image properties on buttons and menus
respectively to get your icons back.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Memory leaks

[Andrew Potter]

You are using gtkmm correctly.

This isn't a gtkmm bug but is in at-spi. I fixed a similar bug for
them before (#688363). I'd suggest filing a bug report with a patch on
product at-spi if you can.

On Wed, Oct 2, 2013 at 10:07 PM, Norman Goldstein norm...@telus.net wrote:
 I have searched through the past year, and there are several posts about
 memory leaks in gtkmm/gtk+. However, I am not clear as to what the
 recommendation is.  I am using gtkmm30 on fedora 18 x86 32-bit.
 I built and ran a standard piece of sample code:

 #include gtkmm.h
 int main(int argc, char *argv[])
 {
   Glib::RefPtrGtk::Application app =
 Gtk::Application::create(argc, argv,
   org.gtkmm.examples.base);

   Gtk::Window window;
   window.set_default_size(200, 200);

   return app-run(window);
 }// main

 * Is there a clean-up routine I should also be invoking? 

 Valgrind gave the following summary:

 ==24123== LEAK SUMMARY:
 ==24123==definitely lost: 280 bytes in 28 blocks
 ==24123==indirectly lost: 0 bytes in 0 blocks
 ==24123==  possibly lost: 747,922 bytes in 6,535 blocks
 ==24123==still reachable: 413,852 bytes in 7,213 blocks
 ==24123== suppressed: 0 bytes in 0 blocks
 ==24123== Reachable blocks (those to which a pointer was found) are not
 shown.
 ==24123== To see them, rerun with: --leak-check=full --show-reachable=yes
 ==24123==
 ==24123== For counts of detected and suppressed errors, rerun with: -v
 ==24123== ERROR SUMMARY: 1085 errors from 1085 contexts (suppressed: 0 from
 0)

 Here is the first definitely lost report:

 ==24123== 8 bytes in 1 blocks are definitely lost in loss record 1,936 of
 7,107
 ==24123==at 0x4008FAF: malloc
 (/builddir/build/BUILD/valgrind-3.8.1/coregrind/m_replacemalloc/vg_replace_malloc.c:270)
 ==24123==by 0x44FF50DB: standard_malloc
 (/usr/src/debug/glib-2.34.2/glib/gmem.c:85)
 ==24123==by 0x44FF5481: g_malloc
 (/usr/src/debug/glib-2.34.2/glib/gmem.c:159)
 ==24123==by 0x476A8C06: droute_path_add_interface
 (/usr/src/debug/at-spi2-atk-2.6.2/droute/droute.c:234) (=)
 ==24123==by 0x476B0845: spi_initialize_selection
 (/usr/src/debug/at-spi2-atk-2.6.2/atk-adaptor/adaptors/selection-adaptor.c:262)
 ==24123==by 0x476A333D: atk_bridge_adaptor_init
 (/usr/src/debug/at-spi2-atk-2.6.2/atk-adaptor/bridge.c:907)
 ==24123==by 0x41D4C3C2: _gtk_accessibility_init
 (/usr/src/debug/gtk+-3.6.4/gtk/a11y/gail.c:831)
 ==24123==by 0x41BAA546: post_parse_hook
 (/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:733)
 ==24123==by 0x44FFB429: g_option_context_parse
 (/usr/src/debug/glib-2.34.2/glib/goption.c:2001)
 ==24123==by 0x41BAAAE7: gtk_parse_args
 (/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:952)
 ==24123==by 0x41BAAB73: gtk_init_check
 (/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:991)
 ==24123==by 0x41BAABB3: gtk_init
 (/usr/src/debug/gtk+-3.6.4/gtk/gtkmain.c:1046)

 I installed the debuginfo packages to get the source file information.
 The leak is occurring at droute.c (indicated by the arrow, above):

 pair = g_new (PropertyPair, 1); //= Line 234
 pair-get = properties-get;
 pair-set = properties-set;
 g_hash_table_insert (path-properties, str_pair_new (itf, prop),
 pair); //==

 The first arrow is where pair is allocated.  It gets stored into a hash
 table at the 2nd arrow.
 Either there is a duplicate insertion that is not being managed (deleting
 the original insertion), or
 the table is not being destroyed, or it is being destroyed but not managing
 its data.

 Most likely, I don't know the clean way of shutting down a gtkmm/gtk+
 session.






 ___
 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

Fwd: Re: What is the minimum number of lines to update a gui window without user clicking a button

[Andrew Potter]

I missed the list in my last reply, so I'm copying it here for the record.
In addition to using a cancelable I changed CallbackDispatcher to use a
recursive mutex so gui_print can be called from the main thread as well.

While providing such an in depth example to L. James maybe goes against the
learn-the-fundamentals-and-help-yourself culture, I'd just like to have a
final answer and close the thread after a month and 100+ messages.

-- Forwarded message --
From: Andrew Potter agpot...@gmail.com
Date: Aug 20, 2013 11:22 AM
Subject: Re: What is the minimum number of lines to update a gui window
without user clicking a button
To: L. D. James lja...@apollo3.com
Cc:

 On Tue, Aug 20, 2013 at 6:01 AM, L. D. James lja...@apollo3.com wrote:
  When clicking on the close button to cancel the operation the gui window
  dims ad become non-responsive... locked up.  That is a problem, in that
some
  of the programs might only take seconds or minutes to complete.

 I designed it that way because I didn't know if it was safe to have
 your blocking operation terminated suddenly; instead it ensures that
 your blocking operation runs until it fully completes. If it is safe
 to stop at any point then you can remove thread_cleanup() from
 Example::~Example(). Otherwise it is best to periodically check in the
 blocking operation whether the window has been closed.
 Gio::Cancellable can be used for this.

 // Example 6
 #include gtkmm.h
 #include unistd.h
 #include queue

 class CallbackDispatcher {
 public:
 CallbackDispatcher() {
 dispatcher.connect(sigc::mem_fun(this,
 CallbackDispatcher::on_dispatch));
 }

 typedef sigc::slotvoid Message;
 void send(Message msg) {
 Glib::Threads::RecMutex::Lock lock(mutex);
 queue.push(msg);
 dispatcher();
 }

 private:
 /* CallbackDispatcher may not be copied, so we must hide these
  * constructors. */
 CallbackDispatcher(const CallbackDispatcher);
 CallbackDispatcher operator=(const CallbackDispatcher);

 Glib::Threads::RecMutex mutex;
 std::queueMessage queue;
 Glib::Dispatcher dispatcher;

 void on_dispatch() {
 Glib::Threads::RecMutex::Lock lock(mutex);
 while (!queue.empty()) {
 queue.front()();
 queue.pop();
 }
 }
 };

 class Example {
 private:
 Glib::RefPtrGtk::Application app;
 Gtk::Windowwin;
 Gtk::TextView  tv;
 Glib::RefPtrGtk::TextBuffer  tb;
 CallbackDispatcher callback_dispatcher;
 Glib::Threads::Thread *thread;
 Glib::RefPtrGio::Cancellable cancellable;

 /* Appends str to the textbuffer. Like all methods that use the
  * Gtk namespace, it is not safe to call from another thread. */
 void gui_print_cb(const Glib::ustring str) {
 tb-insert(tb-end(), str);
 }

 /* Provides threadsafe access to gui_print_cb() */
 void gui_print(const Glib::ustring str) {
 sigc::slotvoid slot = sigc::bind(sigc::mem_fun(this,
 Example::gui_print_cb), str);
 callback_dispatcher.send(slot);
 }

/* This function is called on a separate thread so as to avoid
 * blocking GTK+'s main loop.
 */
 void blocking_operation() {
 /* This simulates a blocking process */
 sleep(5);
 gui_print(5% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(15% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(35% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(55% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(75% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(95% complete.\n);
 if (cancellable-is_cancelled()) return;

 sleep(5);
 gui_print(100% complete.\n);

 /* When the process is finished, we notify the GTK+ Main Loop by
  * using the dispatcher */
 callback_dispatcher.send(sigc::mem_fun(this,
 Example::blocking_operation_finished));
 };

 /* This function is called on GTK+'s main loop via a
  * Glib::Dispatcher */
 void blocking_operation_finished() {
 cleanup_thread();
 gui_print(Operation finished.\n);
 };

 void cleanup_thread() {
 /* We must call Glib::Threads::Thread::join() in order to
  * correctly clean up the resource. */
 if (thread) {
 thread-join();
 thread = NULL;
 }
 }

 public:
 ~Example() {
 /* This will prevent the Window from being closed while
  * the blocking operation is ongoing. */
 cancellable-cancel();
 cleanup_thread();
 }

 Example(int argc, char *argv[]) :
 app(Gtk::Application::create(argc, argv

Re: What is the minimum number of lines to update a gui window without user clicking a button

[Andrew Potter]

Adding these methods to the Example class show how you can use a local
helper function. The downside is you having an extra method lying
around and remembering to use the right one in the right context; in
C++11 you could get rid of gui_append_mainloop() by using a lambda.

Edit: This uses the approach Gavin just suggested. He's right in that
I probably should have used that approach in the first place.

// Extra methods for Example 5
/* Append to the textbuffer in a thread UNsafe manner. Should only
 * be used on the Main Loop. */
void gui_append_mainloop(const Glib::ustring str) {
Glib::ustring text =  tb-get_text();
text += \n + str;
tb-set_text(text);
}

/* Threadsafe access to gui_append_mainloop */
void gui_append(const Glib::ustring str) {
callback_dispatcher.send(sigc::bind(sigc::mem_fun(this,
Example::gui_append_mainloop), str));
}
// Extra methods for Example 5
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: What is the minimum number of lines to update a gui window without user clicking a button

[Andrew Potter]

Mr. James,
This reply has 3 examples. The last time I sent you a complete
solution you never indicated how it was insufficient, so please be
sure read this entire message.

The minimum amount of lines to use a TextView:

//== Example 1 Begin //
#include gtkmm.h

int main(int argc, char *argv[]) {
Glib::RefPtrGtk::Application app =
Gtk::Application::create(argc, argv, com.example);
Gtk::Window win;
Gtk::TextView tv;

tv.get_buffer()-set_text(Hello world);
win.add(tv);
win.show_all();
app-run(win);
return 0;
}
//== Example 1 End //

In your previous emails you have been expressing a desire to output
the result of some long-lasting process to your window. As your
problem was posed to the list it was a contrived problem that had no
simple solution. Most GUI programs start operations by having the user
interact with the window, either by pressing a button or selecting a
menu item.

Nonetheless, I have created another example program that performs a
blocking operation in thread and changes the value of a TextView when
the operation is finished. Note that in the quest for minimality I am
utilizing some features of Gtkmm and C++ that are rarely shown in
beginner examples (such as the ref-to-pointer and sigc::ref()).

This example is 34 lines with no comments or whitespace. But I have
gone ahead and added comments.

//== Example 2 Begin //
#include gtkmm.h
#include unistd.h /* for sleep() */

void cleanup_thread(Glib::Threads::Thread *thread) {
/* We must call Glib::Threads::Thread::join() in order to
 * correctly clean up the resource. */
if (thread) {
thread-join();
thread = NULL;
}
}

/* This function is called on a separate thread so as to avoid
 * blocking GTK+'s main loop.
 */
void blocking_operation(Glib::Dispatcher dispatcher) {
/* This simulates a blocking process */
sleep(10);

/* When the process is finished, we notify the GTK+ Main Loop by
 * using the dispatcher */
dispatcher();
}

/* This function is called on GTK+'s main loop via a
 * Glib::Dispatcher */
void blocking_operation_finished(const Glib::RefPtrGtk::TextBuffer tb,
 Glib::Threads::Thread *thread) {
cleanup_thread(thread);
tb-set_text(Operation finished.);
}

int main(int argc, char *argv[]) {
Glib::RefPtrGtk::Application app =
Gtk::Application::create(argc, argv, com.example);
Gtk::Window win;
Gtk::TextView tv;
Glib::RefPtrGtk::TextBuffer tb = tv.get_buffer();
Glib::Dispatcher dispatcher;
Glib::Threads::Thread *blocking_operation_thread = NULL;

/* Because I'm not using a class to encapsulate the above objects
 * and the methods (to keep it simple), I need to create
 * functors that are bound with these local variables.
 *
 * Note sigc::ref() is used here. Without it sigc::bind would try
 * to copy the dispatcher in this scope. We do not need to use
 * sigc::ref() on tb because RefPtr is a copyable pointer.
 */
sigc::slotvoid op_functor = sigc::bind(blocking_operation,
sigc::ref(dispatcher));

sigc::slotvoid op_finished_functor =
sigc::bind(blocking_operation_finished,
  tb,

sigc::ref(blocking_operation_thread));

/* The dispatcher will be used when the operation has finished.
 * Here we set the function the dispatcher will call on the main
 * thread -- a.k.a. GTK+'s Main Loop.
*/
dispatcher.connect(op_finished_functor);

/* Create a worker thread to perform the blocking_operation
 * function.
 */
blocking_operation_thread = Glib::Threads::Thread::create(op_functor);

/* Now set the text in the buffer.
 */
tb-set_text(Operation started.);

win.add(tv);
win.show_all();
app-run(win);

cleanup_thread(blocking_operation_thread);
return 0;
}
//== Example 2 End //

If one accepts the slight textual overhead of using a class, I have
provided another solution. This allows more straightforward use of
slots/functors, utilizing only sigc::mem_fun().

This example is 46 lines with no comments or whitespace.
//== Example 3 Begin //
#include gtkmm.h
#include unistd.h /* for sleep() */

class Example {
private:
Glib::RefPtrGtk::Application app;
Gtk::Windowwin;
Gtk::TextView  tv;
Glib::RefPtrGtk::TextBuffer  tb;
Glib::Dispatcher   dispatcher;
Glib::Threads::Thread *thread;

   /* This function is called on a separate thread so as to avoid
* blocking GTK+'s main loop.
*/
   void blocking_operation() {
/* This simulates a blocking process */
sleep(10);

/* When the process is finished, we notify the GTK+ Main Loop by
 * using the dispatcher */
dispatcher();
};

/* This function is called on GTK+'s main loop via a
 * 

Re: What is the minimum number of lines to update a gui window without user clicking a button

[Andrew Potter]

dispatcher() causes the function blocking_operation_finished() to be
called, which in turn calls Glib::Threads::Thread::join(). join() will
block the GTK+ main loop until the thread has completely finished
(i.e. blocking_operation() has returned).

Calling dispatcher() more than once means that
blocking_operation_finished() will be called more than once. I hope
you can understand why that is wrong.

Here is the next step in our example series. I have chosen to abstract
the ability to send parameters a function on the main thread through
the use of the CallbackDispatcher class. Its usage is simple: create a
functor that accepts zero arguments and pass it to send(). That
functor will be executed on the main loop.

A zero argument functor may be created from any function by using sigc::bind.

I have also chosen to use a Gtk::Label for this example, so as to
sidestep the issue of bug 495762.

Using a custom wrapper around Glib::Dispatcher to teach a newbie is,
perhaps, bad etiquette. But the utility of this wrapper in sending
progress back to the main loop has been so great in my experience that
I can't resist.
//== Example 4 Begin //
#include gtkmm.h
#include unistd.h /* for sleep() */
#include queue

class CallbackDispatcher {
public:
CallbackDispatcher() {
dispatcher.connect(sigc::mem_fun(this,
CallbackDispatcher::on_dispatch));
}

typedef sigc::slotvoid Message;
void send(Message msg) {
Glib::Threads::Mutex::Lock lock(mutex);
queue.push(msg);
dispatcher();
}

private:
/* CallbackDispatcher may not be copied, so we must hide these
 * constructors */
CallbackDispatcher(const CallbackDispatcher);
CallbackDispatcher operator=(const CallbackDispatcher);

Glib::Threads::Mutex mutex;
std::queueMessage queue;
Glib::Dispatcher dispatcher;

void on_dispatch() {
Glib::Threads::Mutex::Lock lock(mutex);
while (!queue.empty()) {
queue.front()();
queue.pop();
}
}
};

class Example {
private:
Glib::RefPtrGtk::Application app;
Gtk::Windowwin;
Gtk::Label label;
CallbackDispatcher callback_dispatcher;
Glib::Threads::Thread *thread;

void report_progress(const Glib::ustring str) {
callback_dispatcher.send(sigc::bind(sigc::mem_fun(label,
Gtk::Label::set_text), str));
}

   /* This function is called on a separate thread so as to avoid
* blocking GTK+'s main loop.
*/
void blocking_operation() {
/* This simulates a blocking process */
sleep(5);
report_progress(5% complete.);

sleep(5);
report_progress(15% complete.);

sleep(5);
report_progress(35% complete.);

sleep(5);
report_progress(55% complete.);

sleep(5);
report_progress(75% complete.);

sleep(5);
report_progress(95% complete.);

sleep(5);
report_progress(100% complete.);

/* When the process is finished, we notify the GTK+ Main Loop by
 * using the dispatcher */
callback_dispatcher.send(sigc::mem_fun(this,
Example::blocking_operation_finished));
};

/* This function is called on GTK+'s main loop via a
 * Glib::Dispatcher */
void blocking_operation_finished() {
cleanup_thread();
label.set_text(Operation finished.);
};

void cleanup_thread() {
/* We must call Glib::Threads::Thread::join() in order to
 * correctly clean up the resource. */
if (thread) {
thread-join();
thread = NULL;
}
}

public:
~Example() {
/* This will prevent the Window from being closed while
 * the blocking operation is ongoing. */
cleanup_thread();
}

Example(int argc, char *argv[]) :
app(Gtk::Application::create(argc, argv, com.example)),
label(),
thread(NULL)
{
win.add(label);
win.show_all();
}

void run() {
/* Create a slot to the blocking_operation() member function
 * to pass to Glib::Threads::Thread::create().
 */
sigc::slotvoid op_functor = sigc::mem_fun(this,
Example::blocking_operation);

/* Create a worker thread to perform the blocking_operation
 * function.
 */
thread = Glib::Threads::Thread::create(op_functor);

/* Now set the text in the buffer.
 */
label.set_text(Operation started.);

app-run(win);
}
};

int main(int argc, char *argv[]) {
Example example(argc, argv);

example.run();
return 0;
}
//== Example 4 End //


On Sat, Aug 10, 2013 at 5:39 AM, L. D. James lja...@apollo3.com wrote:
 I may be able to eventually figure out how to do it from your example, but
 at present it doesn't appear to have the ability to append text, except for
 an initial text and one addition.

Re: How to update both the Console and the GTKMM gui window after running other functions

[Andrew Potter]

On Thu, Aug 1, 2013 at 7:24 AM, Jonas Platte jonaspla...@myopera.com wrote:
 Am 01.08.2013 16:11, schrieb L. D. James:
 // sample code begin
 // -
 String updatetext = About to run a process that might take an hour... sit
 back and wait...\n;
 System.out.printl(updatetext);
 textArea.append(updatetext);
 int count = 0;
 TimeUnit.SECONDS.sleep(3600); // Scanning all the local and network hard
 drives for files larger than 1 gig
 // Scanning all the local and network hard drives for files larger than 1
 gig
 updatetext = The scan has completed with   count   files found;
 System.out.println(updatetext);
 textArea.append(updatetext);
 // -
 // sample code end
Your Java code appears to be broken according to standard GUI design
principals in that the GUI will not respond to events during your
blocking operation.

Here is the same broken code in C++:
#include gtkmm.h
#include iostream
#include unistd.h

void run_first(Gtk::Label label) {
label.set_text(Starting blocking operation);
std::cout  Starting blocking operation  std::endl;
sleep(5);
label.set_text(The scan has completed);
std::cout  The scan has completed  std::endl;
}

int main(int argc, char *argv[]) {
Glib::RefPtrGtk::Application app =
Gtk::Application::create(argc, argv, com.example);
Gtk::Window win;
Gtk::Label label;
Gtk::Button btn(Start);
Gtk::Box box(Gtk::ORIENTATION_VERTICAL);
box.add(label);
box.add(btn);

btn.signal_clicked().connect(sigc::bind(sigc::ptr_fun(run_first),
sigc::ref(label)));
label.set_text(Program started.);
std::cout  Program started.  std::endl;
win.add(box);
win.show_all();
app-run(win);

return 0;
}

Notice that it will not run as expected, the Starting blocking
operation text is never shown in the label because control is never
passed back to the main loop so that the text may be rendered and
drawn on screen. Here is a program that allows the Starting blocking
operation text to actually be painted, but it still incorrectly
blocks the main loop:
void run_second(Gtk::Label label) {
sleep(5);
label.set_text(The scan has completed);
std::cout  The scan has completed  std::endl;
}

void run_first(Gtk::Label label) {
label.set_text(Starting blocking operation);
std::cout  Starting blocking operation  std::endl;

Glib::signal_timeout().connect_seconds_once(sigc::bind(sigc::ptr_fun(run_second),
sigc::ref(label)),1);
}

This is still, however, not correct program design. Blocking
operations should not be performed in the main loop. Glib provides a
wide host of facilities for asynchronous file and network I/O. If glib
does not provide sufficient facility for you, you may use threads to
perform blocking operations. However, you must keep in mind you may
not update the GUI from a separate thread.

Here is a complete example:
#include gtkmm.h
#include iostream
#include unistd.h

class MyClass
{
public:
MyClass(Gtk::Label *label, Gtk::Button *button) : m_label(label),
m_button(button), m_thread(NULL) {
m_dispatcher.connect(sigc::mem_fun(this,
MyClass::blocking_operation_finished));
};

~MyClass() {
if (m_thread)
m_thread-join();
}

void start_operation() {
m_button-set_sensitive(false);
m_label-set_text(Starting blocking operation);
std::cout  Starting blocking operation  std::endl;
m_thread = Glib::Threads::Thread::create(sigc::mem_fun(this,
MyClass::blocking_operation));
}

private:
void blocking_operation() {
sleep(5);
m_dispatcher();
};

void blocking_operation_finished() {
m_thread-join();
m_thread = NULL;
m_button-set_sensitive(true);
m_label-set_text(The scan has completed);
std::cout  The scan has completed  std::endl;
}

Gtk::Label *m_label;
Gtk::Button *m_button;
Glib::Threads::Thread *m_thread;
Glib::Dispatcher m_dispatcher;
};

int main(int argc, char *argv[]) {
Glib::RefPtrGtk::Application app =
Gtk::Application::create(argc, argv, com.example);
Gtk::Window win;
Gtk::Label label;
Gtk::Button btn(Start);
Gtk::Box box(Gtk::ORIENTATION_VERTICAL);
MyClass myClass(label, btn);

box.add(label);
box.add(btn);
btn.signal_clicked().connect(sigc::mem_fun(myClass,
MyClass::start_operation));
label.set_text(Program started.);
std::cout  Program started.  std::endl;
win.add(box);
win.show_all();
app-run(win);

return 0;
}

I strongly recommend you read the Gtkmm tutorial:
https://developer.gnome.org/gtkmm-tutorial/unstable/index.html
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: How to update both the Console and the GTKMM gui window after running other functions

[Andrew Potter]

On Thu, Aug 1, 2013 at 9:52 AM, Alan Mazer alan.s.ma...@jpl.nasa.gov wrote:
 P.S.  I don't know why it doesn't take arguments either, but one can work
 around that with globals and a mutex.

There's actually a really nice solution I've been using lately. It
uses C++11, but it can be rewritten using only glib/sigc++.

class CallbackDispatcher {
public:
CallbackDispatcher(const CallbackDispatcher) = delete;
CallbackDispatcher operator=(const CallbackDispatcher) = delete;

CallbackDispatcher() {
m_dispatcher.connect(sigc::mem_fun(*this,

CallbackDispatcher::on_dispatch));
};

templatetypename Fn
void operator()(Fn fn) {
std::lock_guardstd::mutex lock(m_mutex);
m_msgs.push(std::forwardFn(fn));
m_dispatcher();
}

private:
typedef std::functionvoid () Callback;

std::queueCallback m_msgs;
mutable std::mutex   m_mutex;
Glib::Dispatcher m_dispatcher;

void on_dispatch() {
std::lock_guardstd::mutex lock(m_mutex);
while (!m_msgs.empty()) {
m_msgs.front()();
m_msgs.pop();
}
}
};


Usage:

void my_fun(Param one, Param two) {
  // Whatever should be run in main loop
}

void my_threaded_fun() {
// This is running on a separate thread
Param one, two;
callbackDispatcher(std::bind(my_fun, one, two));
// The bound function is added to the callback_dispatchers queue, the
dispatcher is called. In the main loop eventually the queue is served
and the callback is called with the bound parameters!
}

What's nice about this pattern is that you only need one dispatcher
for any number of callbacks.

Also its nice to just throw a lambda in there..
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: New widgets to wrap in gtkmm

[Andrew Potter]

On Fri, Jul 26, 2013 at 4:27 AM, Murray Cumming murr...@murrayc.com wrote:
 GTK+ 3.9/10 has several new widgets that we have not yet wrapped in
 gtkmm. Volunteers are welcome, please.

 https://developer.gnome.org/gtk3/unstable/GtkListBox.html
 https://developer.gnome.org/gtk3/unstable/GtkPlacesSidebar.html
 https://developer.gnome.org/gtk3/unstable/GtkRevealer.html
 https://developer.gnome.org/gtk3/unstable/GtkSearchBar.html
 https://developer.gnome.org/gtk3/unstable/GtkStack.html

Sure, I'll do GtkStack. I'll keep going in reverse order unless anyone
else pipes up.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: What does the file extension .hg mean?

[Andrew Potter]

Hi John,
Tarnyko has been doing a lot of work with GTK on Windows lately. You
might be interested in this recent post of his:
http://www.tarnyko.net/en/?q=node/23
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Re: Send a message using Gio::Dbus

[Andrew Potter]

On Thu, Mar 7, 2013 at 6:50 AM, Yoann LE BARS yo...@le-bars.net wrote:

  /* Proxy connected to D-Bus. */
 Glib::RefPtrGio::DBus::Proxy proxy;

 Try Glib::RefPtrGio::DBus::Proxy proxy = Gio::DBus::Proxy::create_for_
bus_sync(Gio::DBus::BUS_TYPE_SESSION,
org.gnome.ScreenSaver,
/org/gnome/ScreenSaver,
org.gnome.ScreenSaver);
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Send a message using Gio::Dbus

[Andrew Potter]

On Wed, Mar 6, 2013 at 6:06 PM, Yoann LE BARS yo...@le-bars.net wrote:

 initialised. The thing is, I do not have a clue on how to initialise the
 proxy in a proper way. Also, connection initialisation does not seem
 quite right. Actually, I am not sure I am not using a completely wrong
 approach.

 Can someone help me out this?

You'll want to use Glib::DBus::Proxy::create_for_bus_sync() (the async
version is fine too)
https://developer.gnome.org/glibmm/2.34/classGio_1_1DBus_1_1Proxy.html#a275770db372ac7becfea4bb5fc2e9154

Then use proxy-call() or call_sync(). I guess you need a tuple variant
with two strings, and you'll get a variant with just the cookie in it back.

Glib::VariantGlib::ustring app_name =
Glib::VariantGlib::ustring::create(MyApp);
Glib::VariantGlib::ustring reason =
Glib::VariantGlib::ustring::create(Playing movie);
std::vectorGlib::VariantBase vec;
vec.push_back(app_name);
vec.push_back(reason);
Glib::VariantContainerBase bundle =
Glib::VariantContainerBase::create_tuple(vec);
Glib::VariantContainerBase result = proxy-call_sync(..., bundle, ...);
Glib::VariantBase child = result.get_child(0);
Glib::Variantunsigned int cookie;
try {
cookie = Glib::Variantunsigned int::cast_dynamic(child);
} catch (std::bad_cast e) {}

Although there's probably no reason to take apart the result, since for the
UnInhibit you'll just shove 'result' right back into proxy-call_sync().

I have a class that uses the dbus notification interface here:
https://github.com/talisein/Horizon/blob/master/src/notifier.cpp
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: How to update the content of a tree view

[Andrew Potter]

On Sat, Feb 23, 2013 at 9:39 AM, John Tall mjta...@gmail.com wrote:

 However, every now and then the progress bars has to be updated and
 this is where I don't follow. I don't get how I should do to properly
 update the value of a specific row.


I would put a pointer to your job object in the TreeModel set up a
Glib::signal_timeout. In the timeout, iterate through your treemodel and
use
iter-get_value(columns.job)-get_progress();

Be sure to disconnect the signal_timeout when there are no jobs in progress.
And you should only have one of these timeouts, even if you have several
jobs
running.

Using signal_timeout for updating progress bars usually results in a much
smoother looking result--especially in this case, where you do have to
iterate
through on average half the treemodel for each update. Its up to you to
choose
a sensible period. 50 ms might be sensible for a job that completes in
under a
minute. Using signal_timeout().connect_seconds() might be more reasonable if
you're sure it will take more than a minute.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: g_hash_table

[Andrew Potter]

On Fri, Feb 22, 2013 at 11:41 PM, John Emmas john...@tiscali.co.uk wrote:

 Today I downloaded the latest source code, assuming that g_hash_table
 would be implemented by now but it still seems to be missing.  I just
 wondered if there's a reason?  Isn't 'g_hash_table' suitable for
 incorporating into glibmm or is it just waiting on the TODO list?

 This isn't a criticism BTW.  I'm just curious to know why it's missing.


I'm not a maintainer, but FWIW:
When glib might return a GList or something, Glibmm transforms it into a
std::vector
or other STL container. I don't think any of the Glib containers are
wrapped; if you are
thinking of using a GHashTable and are working in Glibmm, you should
probably just
use a std::map or std::unordered_map.

If one wanted to wrap GHashTable, I imagine the maintainers would want to
see
iterators and everything else you would expect from an STL container, which
turns into
a much less trivial wrapping. And the end result is something that's
already in the STL...
at least in C++11 or C++03 TR1.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: FilenameCompleter

[Andrew Potter]

On Thu, Jan 17, 2013 at 7:54 AM, Edwin van Leeuwen ed...@tkwsping.nlwrote:

 I'm trying to use Gio::FilenameCompleter to implement simple tab
 completion within my app, but seem to be unable to make it work. I have
 attached a simple example. I tried with many different initial_terms (i.e.
 /hom in the example), but always get 0 results. Am I missing something?


You probably need to connect to signal_got_completion_data() and only query
get_completions() in/after the callback. I suspect you'll need to have a
MainLoop going, so your minimal example won't work.

By the way, if you have pkg-config you can compile a little easier with g++
`pkg-config --libs --cflags glibmm-2.4` file.cc
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Thoughts on Variant creation

[Andrew Potter]

I've been thinking about how we create variants in glibmm and why its more
of a pain than in C. The common case ultimate goal of variants is to throw
a data structure into a tuple. In C, you can use g_variant_new() and a
format string, and hand it pointers to your hard data. 1 method returns the
desired result if you don't need to build a container variant.

However, currently in glibmm you have to call a ::create() method for each
individual data element before you can call create_tuple(). It is
relatively cumbersome for nontrivial tuples.

There are a lot of possible solutions, but I have no idea which is the
best. We could make a really bare wrapper g_variant_new() that passes all
the arguments through and just Glib::wrap()s the result into a
Glib::VariantContainerBase. Or, we could parse the format string ourselves
and call the appropriate ::create() methods.

Maybe we could break ground with a C++11 std::tuple constructor. It'd be
really, really nice if you could just:

auto vtuple = VariantContainerBase::create_tuple({(int) item1, (float)
item2, (std::map) item3});

Thoughts?

Also, what is the motivation to provide only ::create() methods and not do
a constructor, e.g.:

int i = 5;
Variantint vint(i);

Thanks for your time
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Construct Glib::VariantContainerBase for container of container types?

[Andrew Potter]

On Fri, Dec 21, 2012 at 3:12 PM, Phong Cao phongv...@phongvcao.com wrote:

 For example, what should a{sv} be implemented as in
 Glib::VariantContainerBase? Should it be
 Glib::Variantstd::vectorstd::mapGlib::ustring, Glib::VariantBase  ?

Disclaimer, all examples below are untested :)

Right now it seems that you can only create arrays of basic types (int,
float, strings) with Glibmm. To create an array of variants, you'll need to
call a C function:

std::vectorstd::mapGlib::ustring, Glib::VariantBase my_maps; // given
const gsize n_children = my_maps.size();
GVariant**  vmap_array = g_malloc(sizeof(GVariant*) * n_children );

for( gsize i = 0; i  n_children; ++i ) {
  Glib::Variantstd::mapGlib::ustring, Glib::VariantBase  v =
Glib::Variantstd::mapGlib::ustring, Glib::VariantBase ::create(
my_maps[i] );
  vmap_array[i] = v.gobj_copy();
}

GVariant *vcarray = g_variant_new_array(g_variant_get_type(vmap_array[0]),
vmap_array, n_children);
Glib::VariantContainerBase varray = Glib::wrap(vcarray);
for (gsize i = 0; i  n_children; ++i)  g_variant_unref(vmap_array[i]);
g_free(vmap_array);

Note that if you only need to process such a variant that is passed to you
from DBus (i.e. the music player created the array of maps and you just
want to get the maps) then you don't need to use C:
Glib::VariantContainerBase varray; // This was a variant passed to us. You
might need to use ::cast_dynamic() if all you have is a VariantBase
for (gsize i = 0; i  varray.get_n_children(); ++i) {
Glib::VariantBase vbase = varray.get_child(i);
Glib::Variantstd::mapGlib::ustring, Glib::VariantBase  vmap =
Glib::VariantBase::cast_dynamicGlib::Variantstd::mapGlib::ustring,
Glib::VariantBase (vbase);
std::mapGlib::ustring, Glib::VariantBase my_map = vmap.get();
// Now do whatever you want with my_map
}


 I also wonder how I can implement structure types, such as (b(oss))? I
 did take careful look at Glib::VariantContainerBase reference, but I don't
 see anywhere talking about DBus structure types.

That's a tuple. You can use Glib::VariantContainerBase::create_tuple():

Glib::Variantbool vbool;
Glib::VariantBase objectpath;
Glib::VariantGlib::ustring s1, s2;
std::vectorGlib::VariantBase v1, v2;
v1.push_back(objectpath); v1.push_back(s1); v1.push_back(s2);
Glib::VariantContainerBase inner_tuple
=Glib::VariantContainerBase::create_tuple(v1);
v2.push_back(bvool);
v2.push_back(inner_tuple);
Glib::VariantContainerBase tuple =
Glib::VariantContainerBase::create_tuple(v2);


Actually it appears Glibmm doesn't have a way to create the Object Path
Variant type. So you'd have to do that in C...

To be very honest, doing work with Variants in C is often easier.

 Thank you for reading and answering my question! Merry Christmas!

Merry Christmas!
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Construct Glib::VariantContainerBase for container of container types?

[Andrew Potter]

On Fri, Dec 21, 2012 at 5:47 PM, Andrew Potter agpot...@gmail.com wrote:

 Actually it appears Glibmm doesn't have a way to create the Object Path
 Variant type. So you'd have to do that in C...


My bad, you can use Glib::VariantStringBase::create_object_path()
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Adding Diffrent Gtk::CellRenderer in different rows of same column in Gtk::TreeView

[Andrew Potter]

On Tue, Nov 20, 2012 at 11:59 PM, Andrew E. Makeev and...@solvo.ru wrote:

 Look at sources of renderers you would to use (GTK) and implement their
 code in your custom renderer (with GTKMM functions).


While this might be fun to learn from, is there a software engineering
principal that would encourage this? Composing what you need out of the
building blocks lets you use all that GTK code, plus all the bugfixes and
maintenance for the life of the library, for the cost of a few bytes of
pointers. An honest question, I'm new to this :)
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: Adding Diffrent Gtk::CellRenderer in different rows of same column in Gtk::TreeView

[Andrew Potter]

I would make a custom cellrenderer that, given the column data, and for
render_vfunc() simply decides what type of row it is going to be
and returns whatever render() returns from an internal cellrenderer that
does the right thing for the row.

I have an example for subclassing CellRenderer here [1]. Just take what it
does and instead of adding the two cellrenderers together, just choose one
based on the property.


On Tue, Nov 20, 2012 at 3:26 AM, Gitanshu Mehndiratta
gitansh...@gmail.comwrote:



 -- Forwarded message --
 From: Gitanshu Mehndiratta gitansh...@gmail.com
 Date: Tue, Nov 20, 2012 at 12:02 PM
 Subject: Re: Adding Diffrent Gtk::CellRenderer in different rows of same
 column in Gtk::TreeView
 To: gtkmm-list@gnome.org


 Any body has any clue. i have attached screenshots of a application which
 does the same.

 Any help will be appreciated.

 Thanks,
 Gitanshu



 On Mon, Nov 19, 2012 at 5:09 PM, Gitanshu Mehndiratta 
 gitansh...@gmail.com wrote:

 Dear All,


 I want to add different widgets (combo,Text,spin button,checkbox) in
 different rows of same column for Gtk::TreeView.

 I know how to add one widget in a column for all rows of a Gtk::TreeView
 but how to do the above case.

 Thanks,
 Gitanshu




 ___
 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

Glib::Variant leaks

[Andrew Potter]

Is anybody actually using the glibmm variant stuff? I'm serializing a
complex variant and end up losing ~30 megabytes every time [1]

I'm on Gtkmm 3.4, but I've run this test case in jhbuild:

#include glibmm/variant.h

int main() {
{
std::vectorgint64 ints;
 ints.push_back(2);
Glib::VariantContainerBase vints = Glib::Variant std::vectorgint64
::create(ints);
 ints.clear();
}

return 0;
}

Valgrind reports:
==2369== LEAK SUMMARY:
==2369==definitely lost: 2 bytes in 1 blocks
==2369==indirectly lost: 0 bytes in 0 blocks
==2369==  possibly lost: 4,032 bytes in 7 blocks
==2369==still reachable: 5,595 bytes in 14 blocks

Am I not supposed to call ::create() like this?

Thanks.

[1] https://github.com/talisein/Horizon/blob/master/src/image_cache.cpp
ImageData::get_variant()
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list