I'd like to know an architectural decision

In a certain sense, any visual GTK+ widget may be considered
as having
model/view structure: GtkWidget/descendants have some
properties that
are realized by using GDK (or others). As I've noticed,
there is a lot
of code using both model and view functions and causing many
problems
e.g. well known bug that hangs Anjuta on startup.
For now I have two options:
- minimize any actions until widgets are realized;
- if possible, make operations independent from GUI and GUI
will
realize them when it exists.
So, I suggest you to have your own option and I'd like to
know it,
because in the very near future I'm going to make changes in
the code
and it's hard to do for now because the code is so
intricate.

-- 
Regards,
Pavel
_______________________________________________
Glade-devel maillist  -  Glade-devellists.ximian.com

http://lists.ximian.com/mailman/listinfo/glade-devel

On Fri, May 2, 2008 at 10:17 PM, Pavel Kostyuchenko
<shprotxgmail.com> wrote:
> In a certain sense, any visual GTK+ widget may be
considered as having
>  model/view structure: GtkWidget/descendants have some
properties that
>  are realized by using GDK (or others). As I've
noticed, there is a lot
>  of code using both model and view functions and
causing many problems
>  e.g. well known bug that hangs Anjuta on startup.
>  For now I have two options:
>  - minimize any actions until widgets are realized;
>  - if possible, make operations independent from GUI
and GUI will
>  realize them when it exists.
>  So, I suggest you to have your own option and I'd like
to know it,
>  because in the very near future I'm going to make
changes in the code
>  and it's hard to do for now because the code is so
intricate.

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 

Cheers,
                            -Tristan
_______________________________________________
Glade-devel maillist  -  Glade-devellists.ximian.com

http://lists.ximian.com/mailman/listinfo/glade-devel

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
<tristan.van.berkomgmail.com> 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  -  Glade-devellists.ximian.com

http://lists.ximian.com/mailman/listinfo/glade-devel

On Sat, May 3, 2008 at 7:40 AM, Pavel Kostyuchenko
<shprotxgmail.com> 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  -  Glade-devellists.ximian.com

http://lists.ximian.com/mailman/listinfo/glade-devel

On Sat, May 3, 2008 at 8:18 PM, Tristan Van Berkom
<tristan.van.berkomgmail.com> wrote:
>  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 ?

http://code.google.com/soc/2008/gnome/a
ppinfo.html?csaid=671C4A49E54095D0
And now I'm trying only to use glade in anjuta but it
doesn't work
well, so I think at least the most important issues should
be fixed.

>  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.

That's good until somebody else uses idle too like Anjuta
does.

>  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" 

And what about GtkPlug?

-- 
Regards,
Pavel
_______________________________________________
Glade-devel maillist  -  Glade-devellists.ximian.com

http://lists.ximian.com/mailman/listinfo/glade-devel

And one more: I think you should change g_idle_add to
g_timeout_add as
soon as possible, because Anjuta hangs. I hope we will find
a better
solution later but now the simple solution is needed.

-- 
Regards,
Pavel
_______________________________________________
Glade-devel maillist  -  Glade-devellists.ximian.com

http://lists.ximian.com/mailman/listinfo/glade-devel

On Sun, May 4, 2008 at 5:52 PM, Pavel Kostyuchenko
<shprotxgmail.com> wrote:
> And one more: I think you should change g_idle_add to
g_timeout_add as
>  soon as possible, because Anjuta hangs. I hope we will
find a better
>  solution later but now the simple solution is needed.

The g_idle_add() does not conflict with anything, its a
timeout for
the first idle moment
and as such is more stable then adding any timeouts.

Sorry I didnt clarify that immediately, I was writing an
email to that
effect when my
internet connection died.

Cheers,
               -Tristan
_______________________________________________
Glade-devel maillist  -  Glade-devellists.ximian.com

http://lists.ximian.com/mailman/listinfo/glade-devel

The problem is that it conflicts in fact. After anjuta has
added its
idle handler, glade adds it's own handler, which appears to
be called
earlier than anjuta's handler, then (because main window
isn't
realized still) adds itself as idle handler and appears to
be called
earlier again. In that way it adds itself to the idle
handlers
infinitely.

On Sun, May 4, 2008 at 11:56 PM, Tristan Van Berkom
<tristan.van.berkomgmail.com> wrote:
>  The g_idle_add() does not conflict with anything, its
a timeout for
>  the first idle moment
>  and as such is more stable then adding any timeouts.
-- 
Regards,
Pavel
_______________________________________________
Glade-devel maillist  -  Glade-devellists.ximian.com

http://lists.ximian.com/mailman/listinfo/glade-devel

Ok after looking at the code again I see the possibility of
recursion,
dont see what would make it hang
though, the idle handler should just queue another idle
handler until
the widget is actually realized.

Rather, what should be done here is instead of using an
idle,
g_signal_connect_after() to the "realize"
signal of the layout that we are waiting to be realized.

At any rate, if this is a bug for you then please, please
file it in bugzilla.

Thankyou,
                   -Tristan

On Sun, May 4, 2008 at 6:08 PM, Pavel Kostyuchenko
<shprotxgmail.com> wrote:
> The problem is that it conflicts in fact. After anjuta
has added its
>  idle handler, glade adds it's own handler, which
appears to be called
>  earlier than anjuta's handler, then (because main
window isn't
>  realized still) adds itself as idle handler and
appears to be called
>  earlier again. In that way it adds itself to the idle
handlers
>  infinitely.
>
>  On Sun, May 4, 2008 at 11:56 PM, Tristan Van Berkom
>
> <tristan.van.berkomgmail.com> wrote:
>
> >  The g_idle_add() does not conflict with anything,
its a timeout for
>  >  the first idle moment
>  >  and as such is more stable then adding any
timeouts.
>  --
>  Regards,
>  Pavel
>
_______________________________________________
Glade-devel maillist  -  Glade-devellists.ximian.com

http://lists.ximian.com/mailman/listinfo/glade-devel

I had made a patch for all mentioned bugs before I wrote a
message to
anjuta mailing list, but something new appears to be broken
after that
patch, so I thought I should discuss all that bugs before
submitting
the patch. The patch has g_idle_ad replaced with
"realized" signal,
but for unknown reason I need to call {container_remove,
container_add, show_all} two times else graphical designer
window
appears to be not usable.

On Mon, May 5, 2008 at 12:53 AM, Tristan Van Berkom
<tristan.van.berkomgmail.com> wrote:
> Ok after looking at the code again I see the
possibility of recursion,
>  dont see what would make it hang
>  though, the idle handler should just queue another
idle handler until
>  the widget is actually realized.
>
>  Rather, what should be done here is instead of using
an idle,
>  g_signal_connect_after() to the "realize"
>  signal of the layout that we are waiting to be
realized.
>
>  At any rate, if this is a bug for you then please,
please file it in bugzilla.
-- 
Regards,
Pavel
_______________________________________________
Glade-devel maillist  -  Glade-devellists.ximian.com

http://lists.ximian.com/mailman/listinfo/glade-devel