0

I'm currently writing a plugin for a GTK+ Software (Pidgin). I haven't worked with GTK before, so I'm only somewhat familiar with how objects work from the documentation.

I'm creating a few thousand buttons with images on them (smileys) and storing them in a doubly linked list. Then, on user request, a portion of these buttons is showed on a dialog, organized in hboxes and vboxes. As soon as the user closes the dialog, it gets destroyed and so do the hboxes, vboxes, buttons and images. But I don't want the buttons and its images to be destroyed since I'm trying to keep them in the doubly linked list to be able to quickly show them again.

What I tried:

  • Creating extra references to the buttons using g_object_ref() or g_object_ref_sink(). This did not change anything.
  • Connecting to a "delete" signal which is supposed to be called before finalization. This signal isn't emitted though.

Edit: I also checked the GObject.ref_count field, and it's not going to zero. So that's not the cause of the problem.

I'd be grateful for any hints on how to keep the buttons from being destroyed as efficiently as possible

Felix S
  • 101
  • 2
  • remove them from the dialog before destroying it and keep a reference to them with g_object_ref. Anyway, keeping thousands of icons and widgets in memory doesn't seem a good idea. – José Fonte Aug 11 '17 at 13:52
  • this seems like a lot of overhead to remove them from the dialog one by one to stop them from being deleted. Memory is not an issue, the smileys are only around 2KB each so even keeping 10 000 in memory will only take up about 20MB. – Felix S Aug 11 '17 at 14:03
  • If they are on a list, just iterate and call the remove function/method from gtk container – José Fonte Aug 11 '17 at 14:06
  • 1
    What about keeping the pixbufs and recreate the buttons? Or wrap methods on a class and do some lazy loading? There are some approaches... – José Fonte Aug 11 '17 at 14:09
  • They're not directly on the dialog, but inside hboxes and vboxes, so I would probably have to reverse that whole process and "unparent" everything. I also thought about the pixbuf approach but I just couldn't imagine that there is no simple way to keep an object from self-destroying. – Felix S Aug 11 '17 at 14:13
  • ok, so reparenting them to a dummy container when the dialog gets destroyed works. Thanks so far, but I'm still hoping there is a way without having to iterate them again – Felix S Aug 11 '17 at 14:22
  • 1
    There must be a way to avoid destruction. If i have more time later i'll try to check further. – José Fonte Aug 11 '17 at 14:25
  • @Felix: the overhead of GtkWidget creation itself is pretty massive (and they might use more memory than you think): it might be useful to re-evaluate the design if you need to create thousands of them in the first place... – Jussi Kukkonen Aug 12 '17 at 08:41
  • I'm essentially recreating the normal smiley-selection window which takes about 2 seconds to open up each time with 2500 smileys. So I'm trying to trade memory for execution time here, because loading them all each time is extremely slow. Even if it takes another 1KB for all the data structures in a GtkWidget (which sounds like a lot to me), it would occupy 30 MB for 10k smileys which I think is not an issue. – Felix S Aug 12 '17 at 12:02

0 Answers0