Collapse GtkOffscreenWindow code into GtkWindow:offscreen property



Hi,
    I've been wanting to write a somewhat trivial patch for
GtkWindow to collapse the GtkOffscreenWindow code completely
as a property of GtkWindow (GtkWindow:offscreen).

The rationale is shamelessly and completely for Glade; here's
our story:

We've been using a hack for the longest time to embed toplevel
widgets into our workspace area by explicitly parenting the 
window when catching the window's "realize" signal, and then
unsetting the GTK_TOPLEVEL flag at the same time, yes it was
an ugly and evil hack and even involved some tweaking for
some subclasses such as stopping emission from signals
such as "hierarchy-changed" and "screen-changed"... 

Now we need an alternative since GTK_WIDGET_SET/UNSET_FLAGS() is
removed and there is no way to evilly unset the GTK_TOPLEVEL flag.

So our options are now slim, 2 ways of doing things properly 
present themselves:

    a.) Just dont use real instances of GtkWindow classes in Glade
	and use some in-house virtual "mock" classes to do the job.

	This would be a reasonable idea except that it means we would
	need to mock up every single GtkWindow subclass and make it look
	like a real fontselectiondialog or colorselectiondialog or
	aboutdialog etc etc, furthermore we would need to manually
	create the access points to add children to the internal
	widget "slots" (such as the dialog action-area and vbox etc.).

    b.) Render the GtkWindow offscreen and paint it into the workspace
	and then send some events to the widgets manually.

Needless to say, we're choosing option 'b'.

So Juan Pablo has been writing up a patch that connects to all
GtkWindow's "realize" signal (for windows that go into the workspace)
and instead of fooling with the toplevel flag and such... we're
just going to feed it an offscreen GdkWindow.

However this is bound to have some kinks and problems and it still
feels like a hack (a quick look at gtkoffscreenwindow.c will reveal
that GtkWindows like to make some few exception for when they are
rendered offscreen).

The obvious solution is to offload that hackish solution to GTK+
as a proper feature of GtkWindow and close the book on this hacky stuff.

So (after my long-winded explanation) my proposal is that we drop
GtkOffscreenWindow all together (err, or deprecate it if that's too
late) and just simply expose a boolean "offscreen" property on
the GtkWindowClass; writing the patch will be a simple matter of
adding the property and doing everything a GtkOffscreenWindow would
do in its class vfuncs depending on the truth of GtkWindow:offscreen.

Are there any objections to this change ?

Cheers,
         -Tristan




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]