Architechture for GTK+3 C applications

I am developing an GTK+ application in a embedded processor. I am using Glade for UI development. GTK is very easy and a powerful tool for application development. Thanks for the continuous support by this forum. In my application, i have almost around 9 screens which i create as a separate fixed for each screen in glade. I will be creating a window in my code and will be adding the fixed in my window using gtk_container_add(). To change the screens with button press, i used to do gtk_container_remove() followed by gtk_container_add() with the new screen (fixed).

1.Is this a right way to change screens?
2.Is there any architectures to be followed while developing gtk+ applications for better memory management?


That’s fine, you can change the screens that way. Or you could use a GtkStack.

Hi @lb90,
Thanks for your quick reply. While changing the screens in this way, I can see that the memory increases when a new screen is called and when all the screens are opened atleast once, the memory stays stable. So i think that the memory of all fixed are stored in ram.
1.Is my view correct?
2.Can I unreference a screen by using g_object_unref() when a screen is changed? But while unreferencing, when the screen is called next time,I could see only blank screen. Can you suggest me a way to do this in a optimized way to use less memory?

Thanks and regards,

To destroy widgets you should call gtk_widget_destroy

Here’s one way to do it:

change_window_child_widget (GtkWidget *window,
                            const gchar *resource_path,
                            const gchar *glade_id)
  GtkBuilder *builder = NULL;
  GtkWidget *current_child = NULL;
  GtkWidget *new_child = NULL;

  current_child = gtk_bin_get_child (GTK_BIN (window);
  if (current_child) {
    gtk_widget_destroy (current_child);
    current_child = NULL;

  builder = gtk_builder_new_from_resource (resource_path);
  new_child = GTK_WIDGET (gtk_builder_get_object (builder,
  gtk_container_add (GTK_CONTAINER (window), new_child);

  g_object_unref (builder);

Using a GtkStack you load all ‘screens’ at startup, when creating the window:

const int NUM_SCREENS = 3;

typedef struct {
  const gchar *resource_path,
  const gchar *glade_id,
} screen_info_t;

GtkWidget *window;
screen_info_t screen_infos[NUM_SCREENS] = {
  {"org/myapplication/screens/a.ui", "fixed_a"},
  {"org/myapplication/screens/b.ui", "fixed_b"},
  {"org/myapplication/screens/c.ui", "fixed_c"},

GtkWidget *window;
GtkWidget *stack;

window_create ()
  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  stack = gtk_stack_new ();
  gtk_container_add (GTK_CONTAINER (window), stack);

  for (int i = 0; i < NUM_SCREENS; i++) {
    GtkBulder *builder = gtk_builder_new_from_resource (screen_infos[i].resource_path);
    gtk_stack_add_named (GTK_STACK(stack),
                         GTK_WIDGET (gtk_builder_get_object (builder, screen_infos[i].glade_id)),
    g_object_unref (builder);

Then, whenever you want to change the screen, call:

gtk_stack_set_visible_child_name (GTK_STACK (stack), "fixed_c");

It supports screen transitions like fade / slide etc.

Generally speaking, if you are working in an memory limited environment its best to be as stable as possible. If something is going to load several pages of controls then you might as well do it all at once and leave them in RAM (assuming they all fit). Creating them and deleting them might be lots of busy work for the memory manager without making a significant difference to the peak RAM of your program.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.