Hi,
sorry if I was not clear,
On Sun, Feb 10, 2008, Matthew Allum wrote:
> Hi;
>
> On Sat, 2008-02-09 at 15:36 +0100, Johan Bilien wrote:
> >
> > > also, setting a foreign window for the stage must call
> > > clutter_actor_realize() on the stage to recreate the GL context, so
> > > reparenting inside an overridden realize will not work even if it were
> > > possible.
> >
> > Will it not then reparent the foreign window, which would be the
> > expected behavior I think?
> >
>
> Clutter will just query the foreign window for basic attributes and then
> create its GL context for it. It wont do any re-parenting or much else
> for the foreign window as thats the job of who ever 'owns' that window.
> Note, currently Clutter really needs a real window (and therefor more
> importantly a GL context) to initialise correctly in querying GL
> capability's.
Sure
> Could you explain a little more about what your trying to do here ? Is
> it related to the GTK widget ?
I want to make the stage's window a child of the Composite overlay
window, so I can have a clutter-based X compositor.
I am currently doing:
clutter_actor_realize (stage);
clutter_window = clutter_x11_get_stage_window (CLUTTER_STAGE (stage));
XReparentWindow (clutter_x11_get_default_display (),
clutter_window,
overlay_window,
0, 0);
and it works just fine, but when cleaning up I thought of making it a
bit more generic and avoid manually realizing the stage. The natural way
seemed to subclass the stage with
G_DEFINE_TYPE (OverlayStage, overlay_stage, ClutterStageGLX);
or
G_DEFINE_TYPE (OverlayStage, overlay_stage, ClutterStageEGL);
and have something like
static void
overlay_stage_realize (ClutterActor *actor)
{
Window clutter_window;
CLUTTER_ACTOR_CLASS (hd_stage_parent_class)->realize (actor);
clutter_window = clutter_x11_get_stage_window (CLUTTER_STAGE
(stage));
XReparentWindow (clutter_x11_get_default_display (),
clutter_window,
overlay_window,
0, 0);
}
Connecting to ::show would probably work, only it would reparent after
mapping which could cause a glitch. Connecting to Ebassi's proposed
::realize would work.
But I can think of other cases where it would seem natural to subclass
the stage. If you are writing a higher-level toolkit Foo on top of
clutter you might want to have the FooWindow be a subclass of the stage.
Perhaps the backend specific things in the stage could be kept in the
backend object, by having things like:
static void
clutter_stage_realize (ClutterActor *actor)
{
backend->realize_stage (backend, CLUTTER_STAGE (actor));
}
--
Johan Bilien
<[EMAIL PROTECTED]>
--
To unsubscribe send a mail to [EMAIL PROTECTED]
