Re: woo
- From: Nat Friedman <nat nat org>
- To: Miguel de Icaza <miguel gnu org>
- Cc: gnome-components-list gnome org
- Subject: Re: woo
- Date: 30 Jul 1999 18:56:56 -0400
Miguel de Icaza <miguel@gnu.org> wrote:
>
> > La la la.
> >
> > Dude, problem is, the activation/deactivation for embeddables is
> > yucky. We should think about it.
>
> Yes, I agree. I hvae not yet studied the cases. And you are probably
> closer to that than I am. Any ideas?
Well, there are a number of things that have to be considered:
The ViewFrame has to ask the View to activate itself, and the
View can respond by notify the ViewFrame that it has or has not been
activated. The ViewFrame, upon learning that an View has been
activated or deactivated, will cover or uncover the View, accordingly.
This two-step process is necessary so that an View can refuse to be
uncovered. However, this introduces an asymmetry: an Embeddable
shouldn't be able to refuse to lose focus. Plus, we get two round
trips per View focus change (one round trip to deactivate view #1; one
to activate view #2).
Currently, I am doing in-place Embeddable activation with a
verb. I am not sure if this is the right thing to do; I am somewhat
inclined to think that verbs should be reserved for popup-menu verb
items [1], and that we should provide a special GNOME::View method for
activation and deactivation.
I am also currently using a double-click on the
GnomeViewFrame's wrapper to trigger in-place activation. This is done
in a somewhat hackneyed way right now. With your permission, I'd like
to make a double-click on the wrapper trigger a GnomeViewFarme signal
emission, which an application can capture and deal with as
appropriate.
The way things work right now is that some helper routines
handle passing the in-place activation verb to the embedded GnomeView.
I think this sucks. It would be better, I think, to relegate more of
the functionality to the container author, like so (code written in
mail buffer; ignore spurious errors):
GnomeViewFrame *active_view_frame = NULL; /* container-global */
static void
init_view_frame (GnomeViewFrame *view_frame)
{
.
.
.
gtk_signal_connect (view_frame, "activation_request",
activation_request_cb);
gtk_signal_connect (view_frame, "view_activated", view_activated_cb);
.
.
.
}
/* Gets called when the user double clicks on a ViewFrame's wrapper */
static gint
activation_request (GnomeViewFrame *view_frame)
{
if (active_view_frame != NULL)
deactivate_view (active_view_frame);
active_view_frame = NULL;
activate_view (view_frame);
return FALSE;
}
static void
deactivate_view (GnomeViewFrame *view_frame)
{
GNOME_View view;
GtkWidget *wrapper;
view = gnome_view_frame_get_view (view_frame);
/* This could be done with a GNOME::View method, too. */
GNOME_View_do_verb (view, "bonobo_view_inplace_deactivate", &ev);
wrapper = gnome_view_frame_get_wrapper (view_frame);
gnome_wrapper_set_covered (GNOME_WRAPPER (wrapper), TRUE);
}
static GnomeViewFrame *
activate_view (GnomeViewFrame *view_frame)
{
GNOME_View view;
view = gnome_view_frame_get_view (view_frame);
/* This could be done with a GNOME::View method, too. */
GNOME_View_do_verb (view, "bonobo_view_inplace_activate", &ev);
}
/*
* Gets called when the View notifies the ViewFrame that it would like
* to be activated or deactivated.
*/
static gint
view_activated_cb (GnomeViewFrame *view_frame, gboolean activated)
{
if (active_view_frame != NULL) {
g_warning ("view_activated_cb: There is already an active "
"view!\n");
return FALSE;
}
if (activated) {
GtkWidget *wrapper;
wrapper = gnome_view_frame_get_wrapper (view_frame);
gnome_wrapper_set_covered (GNOME_WRAPPER (wrapper), FALSE);
active_view_frame = view_frame;
} else if (active_view_frame == view_frame) {
deactivate_view (view_frame);
active_view_frame = NULL;
}
return FALSE;
}
Note that, in the above code, the ViewFrame's View is _always_
covered when the View is deactivated, but only uncovered if the View
acknowledges its activation. This is, I think, an important
asymmetry.
In the above code, deactive_view() and activate_view() could
potentially be made GnomeViewFrame methods. In fact, I think it would
be a good idea.
So, Migatron, comments?
Nat
[1] Incidentally, I have added the dual-string support for verbs on my
local copy; one for the translated copy and one for the untranslated
"key" copy. I don't like the idea of using a number as a verb ID at
all.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]