non inplace components (was: DDJ article) (long !!)

[Nat Friedman <nat nat org>]

Mathieu Lacage writes:
 > 1) gnome-client-site.c.patch
 > This patch changes what i think is a wrong behaviour:
 > originally, size_allocate signals sent to the wrapper were sent to 
 > the embeddable component through the CORBA interfaces.
 > I added handling of the size_request signal and made sure that the 
 > signals sent to the component were REALLY aimed to the component's
 > widget by cnnectiong the handlers to the wrapper->bin.child widget
 > instead of wrapper.

    Yup, this is an obvious bug.  I have changed things a bit so that
we now actually keep a handle to the GtkSocket we use to embed the
component; we should attach the signals there.  Thanks for the patch.

 > 2) others file patches.
 > I think these should NOT be applied now. We should first agree on an API
 > to handle NON_IN_PLACE components.

    Ok.

 > Here is my proposal:
 > The patches only implement partially this proposal and should not 
 > be considered as applyable: this is test stuff i used to play with
 > the folowing ideas.
 > ----------------proposal-------------------------
 > in GnomeWrapper:
 > change gnome_wrapper_set_covered and gnome_wrapper_is_covered to
 > gnome_wrapper_set_state and gnome_wrapper_get_state

    I still don't know why we need to use a wrapper for non-in-place
components.  We can just forego it and use the GtkSocket directly.
Alternately, we could use an always-uncovered wrapper for that case.

    It's just that the wrapper only makes sense in the in-place
scenario.

 > Why ? Because the wrapper must have at least 3 states to know how to 
 > paint the window of the embeddable
 > GNOME_WRAPPER_COVERED -> non activated component
 > GNOME_WRAPER_COVERED_PAINT -> non inplace activated component
 > GNMOE_WRAPPER_UNCOVERED_PAINT -> inplace activated component
 > Basically, when the component is inplace and activated, we uncover the 
 > cover to let events pass through and we paint the border.
 > When the component is not inplace and activated, we do not uncover the
 > cover and we paint on the whole cover.

    I don't understand the meaning of the "_PAINT" suffix.  What's
wrong with having two flags on the wrapper:

    #1: The draw-border-or-not flag:
      void gnome_wrapper_set_border_visibility (GnomeWrapper *wrapper, gboolean draw_border)
      gboolean gnome_wrapper_get_border_visibility (GnomeWrapper *wrapper)

    #2: The are-you-active flag:
      void gnome_wrapper_set_covered (GnomeWrapper *wrapper, gboolean covered)
      gboolean gnome_wrapper_get_covered (GnomeWrapper *wrapper)

This very clearly separates the two pieces of data you want to express 
with the states you proposed.

    But it doesn't change my feeling that the wrapper is not necessary 
in the non-inplace case :-)

 > in GnomeViewFrame:
 > gnome_view_frame_set_covered should be replaced by 
 > gnome_view_frame_activate and gnome_view_frame_deactivate

    Yes, I have made a change like this.  I'm sorry for the delay in
committing my changes.  Our network access has been sporadic here.

 > Why ? because the set_covered semantics are no longer valid when you take
 > into account noninplace components (see discussion of the proposed API for
 > the wrapper). It is however possible to keep the current API for this and 
 > do nasty things inside the bonobo code to make it work but... well... 
 > not really nice.

    Yup, I agree completely.

 > in GnomeEmbeddable
 > gnome_embeddable_new should be added one more parameter which is used to
 > say whether we are creating a noninplace component or not
 > ----------------proposal-------------------------
 > 
 > If ppl agree to do this, i can write a nice clean patch to
 > implement it.

    I don't think I agree with this part.  I think a GnomeEmbeddable
can have multiple views, some of them in-place, some of them
non-inplace.  What do you think?

Amicalement,
Nat