Re: I'd like to know an architectural decision

I know such problems as:
- there is an ugly mechanism to reflect widgets state on realization.
The most problem code is "glade_widget_show_idle (...) { ...
glade_widget_show ... }   glade_widget_show (...) { ... g_idle_add
(glade_widget_show_idle ... }". It grabs the idle event. Of course,
you can just replace g_idle_add with g_timeout_add, but it would be
just a workaround. IMHO, glade_widget_show shouldn't do any actions
with GUI, but other functions should do that instead (like
gtk_widget_realize, gtk_widget_map do in GtkWidget);
- there are too many actions in glade_app_project_add e.g
glade_widget_show calling and setting current project;
- "glade_design_layout_add (...) { ... gdk_window_lower
(layout->priv->event_window); }" as an example of gdk usage where it's
unwanted.

On Sat, May 3, 2008 at 5:06 AM, Tristan Van Berkom
<[email protected]> wrote:
>  Ok Im not familliar with any well known hangs at anjuta startup, but I'll
>  try to clarify something for you.
>
>  Object properties are an interface to the object, a realized widget should
>  not be a prerequisite of setting an object property, if there are bugs in
>  some objects that is an issue. A widget object needs to use the proper
>  flags (i.e. GTK_WIDGET_REALIZED(), GTK_WIDGET_MAPPED()) to
>  operate correctly and at times deffer execution until realize time.
>
>  Bottom line, objects should react well to property settings, and with
>  widgets it can get tricky, Im not aware of any serious bugs in widgets
>  in gtk+ in this regard, if you know any such bugs, please share them
>  with us ;-)
-- 
Regards,
Pavel
_______________________________________________
Glade-devel maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/glade-devel