Re: I'd like to know an architectural decision

On Sat, May 3, 2008 at 7:40 AM, Pavel Kostyuchenko <[email protected]> wrote:
> I know such problems as:

Ah, "In Glade" you mean !?

Im sorry I did not find your original post to be very clear.

First of all, we are a small team so I cannot emphasize enough how
GREAT it would be if you were to help out a little even if only to iron out
some of these rough edges you are pointing out.

Secondly, for me to be able to provide you with more useful information,
and for me to understand you better - you must please just state your
mission with glade, you say you are encountering these problems, what
exactly are you trying to do ?

>  - 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);

Agreed, I introduced the one time idle (which is IMO more stable than a timeout)
when I made glade show the first widget in a project inside the workspace at
project load time.

The real root of this problem is that gtk+ does not support embedding
of toplevel
windows, the best way to deal with this would be to rally for support
in gtk+ and
provide patches to gtk+ to this effect, other than that there may be a
way to work
around the idle approach and make it all work synchronously, but it would also
be a hack and as they say "if its not broke dont fix it" :)

>  - there are too many actions in glade_app_project_add e.g
>  glade_widget_show calling and setting current project;

Really what should be dealt with here, is the concept of the current
project, it might be best to get rid of the "active project" concept all
together and externalize that to the frontend (i.e. glade3 or anjuta).

That way the frontend could decide how many workspaces to show, side by
side or in notebook tabs. The Palette and Inspector widgets need to have
a project set, in theory that is the only need for an active project.

>  - "glade_design_layout_add (...) { ... gdk_window_lower
>  (layout->priv->event_window); }" as an example of gdk usage where it's
>  unwanted.

Yes well, reffer to my first comment ;-)

Thanks for taking the time to review and comment on our code :)

Cheers,
                    -Tristan
_______________________________________________
Glade-devel maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/glade-devel