Goal:I want to implement the next algorithm:1. Mouse click on one of the images.2. Hiding all the structure of the 4X4 grid.3. Showing the clicked image on the area of the 4x4 grid.* And all the way back as well.

Problem:Since the inner structure of each cell is complex, I would like to do the next:1. Attach the existing structure to a new container.2. Hide the existing 4x4 grid.3. Show the new created image.

Question:1. Is it possible?2. Can´t it cause memory freeing problems? (One container frees the widget, and then there will be a segmentation fault when the other one will try to do the same).

The answer is yes. For example I often have GtkAdjustments bound to multiple spin buttons so that adjusting one will adjust the other automatically.However your program doesn't seem to necessitate the use of having it in two containers at the same time. There can be memory problems. Gtk uses reference counting to decide when to destroy a widget. Each time a widget is instantiated (e.g. when I add a spin button and assign a common GtkAdjustment) the reference count goes up by 1 and goes down when it is destroyed. When it reduces to zero it is removed from memory. Now if you destroy the table then all contents will be destroyed. You can avoid having the cell contents removed from memory by using g_object_ref and then g_object_unref once you've restored the table again.Another way is to design a custom widget for your table using cairo and GtkDrawingArea, then you can design in just the signals you need as well as your own funky dynamic behaviour.

First, answer to the guestion in the title of the topic (Can a GtkWidget be contained by 2 containers?) is no. Widget can be only child of one parent.

As for GtkAdjustment, it can be referenced from several widgets because a) it's not a widget (it is derived from GtkObject and in GTK+-3 it is directly derived from GObject) and b) there is no parent-child relationship with widget-adjustment.

The answer is yes. For example I often have GtkAdjustments bound to multiple spin buttons so that adjusting one will adjust the other automatically.However your program doesn't seem to necessitate the use of having it in two containers at the same time. There can be memory problems. Gtk uses reference counting to decide when to destroy a widget. Each time a widget is instantiated (e.g. when I add a spin button and assign a common GtkAdjustment) the reference count goes up by 1 and goes down when it is destroyed. When it reduces to zero it is removed from memory. Now if you destroy the table then all contents will be destroyed. You can avoid having the cell contents removed from memory by using g_object_ref and then g_object_unref once you've restored the table again.Another way is to design a custom widget for your table using cairo and GtkDrawingArea, then you can design in just the signals you need as well as your own funky dynamic behaviour.

Dear Paul,

First I wanted to thank you for your answer.The second thing is that it is not very clear to me.Of course you have given me 3 different directions, and this is already a lot :), but if you have time to explain it more clearly, I would be grateful.

Thanks for the correction tadeboro,as to more information (I thought there was only two):1. Using the table: Ok ou want to destroy the cell structure of the table in order to focus on just one cell, but doing so will dereference and thus remove from memory all your images. So first call g_object_ref on each of your images and then do the gtk_widget_destroy on the table contents (the images remain in memory and can thus be addressed without seg faults)

2. Custom widget: far to involved for me to even begin to start describing here. There's a tutorial on the gtk website that discusses how to create customised widgets. In this case you would set up a drawing area (where you draw NxM images for the frame preview case and just the 1 for the focused case -- they are not widgets in this case so you don't have to worry about memory concerns) and signals for detecting mouse clicks (which well then detect which cell the click occured in and change to focus). The advantage to customisation is that you can add dynamic behaviour like have a zoom transition in the change as well as having the NxM images scroll rather than replace. Having cairo doing the drawing makes applying image editing very easy. Customisation is a fair bit of work; your main aim I'd imagine woud be to get it up and running at the moment; but if you're going to be continually improving this for a while and adding new features, eventually you're going to run into some problem that needs customisation.

Who is online

Users browsing this forum: Google [Bot] and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum