Re: Glib::RefPtr

[Phil Wolff <adiabat centurylink net>]

Bad news, 'cause rebuilding is really slow, and copying or serializing 
would be much faster.

I wasn't paying much attention to the callback because it didn't appear 
to be the problem, but modifying the example accordingly does effect a cure.

I have used Gtk::Stack in another application, but I had completely 
forgotten it. I'll give it a shot.

Thanks for the assist!

On 10/08/2017 09:30 AM, Daniel Boles wrote:
> I've taken a look at this and think it's intentional and fairly clear:
>
>   * GTK+ and gtkmm both refer to the slot as "a slot that creates
>     widgets". i.e. creates, for the FlowBox's consumption. Not a slot
>     that returns a reference to a widget that already existed for some
>     other purpose.
>   * GtkFlowBox does   gtk_flow_box_forall (GTK_CONTAINER (box), FALSE,
>     (GtkCallback) gtk_widget_destroy, NULL);
>
> So, I think your original conclusion, that the widgets must always be 
> rebuilt, was correct.
>
> As for the question about copying them, I'm afraid that can't work, as 
> far as I know; relatively few GObjects maintain all their state as 
> properties, often keeping essential info in private structs, so unless 
> the C class provides a copy/clone method, that can't be done. Not that 
> I think it'd help much here anyway - you'd just be copying instead of 
> deleting/recreating.
>
> Perhaps you can instead build all the FlowBoxes, one for each model, 
> then just show the one that's currently relevant. e.g. using Gtk::Stack
>
>
>
>
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list

--
It is better to have tried and failed than to have failed to try, but 
the result's the same.
   — Mike Dennison