[directfb-dev] Re: how to raise windows to the top?

[a40e8119bbddbe7b3d281db117f19b32@interlinx.bc.ca]

On Sat, Jul 20, 2002 at 10:58:46AM +0200, Sven Neumann wrote:
> Hi,

Hi Sven,

> a40e8119bbddbe7b3d281db117f19b32@interlinx.bc.ca writes:
> 
> > I could try that.  Can I not simply grab
> > GTK_WIDGET(TransDialog)->window right after calling
> > gtk_widget_show(TransDialog) though?
> 
> no, you can't. widget->window is a NULL pointer until the widget is
> realized.

I realize (no pun intended) that, which is why I wrapped all of my
widget->window stuff with a "if (GTK_WIDGET(widget)->window)", (right
after my gtk_widget_show(widget)) and put a fprintf in there to make
sure it was happening reliably.  It was.  But even though
widget->window was not NULL (realized), trying to use either (and
both) of:

  gdk_window_set_modal_hint(GTK_WIDGET(widget)->window, TRUE);

  gdk_window_raise(GTK_WIDGET(widget)->window);

did not result in the window being raised on top of the mplayer
display/window/layer.  The dialog _was_ on top of the Gtk window stack
however.  The:

  gdk_window_set_opacity (GTK_WIDGET(widget)->window, 0.6);

was working just fine (I could see the dialog being transparent after
I stopped mplayer) however so the GdkWindow was available and valid.

> This doesn't happen when you call gtk_widget_show();

Which I did and did say.  I left that part from my previous message
quoted at the top of this one.

> gtk_widget_show() only sets the visibility property of the widget and
> maps it in case the parent widget is already mapped.

But the widget I passed to gtk_widget_show was the top level window of
the dialog.

> You could use
> gtk_widget_realize() to force realization but that's considered bad
> style. The correct solution is to do such stuff in a "realize" signal
> handler.

OK, so I have the following signal handler for the realize signal on
the dialog:

void
on_TestDialog_realize                  (GtkWidget       *widget,
                                        gpointer         user_data)
{

  if (GTK_WIDGET(widget)->window) {
    gdk_window_set_modal_hint(GTK_WIDGET(widget)->window, TRUE);
fprintf(stderr, "raising translucent dialog\n");
    gdk_window_raise(GTK_WIDGET(widget)->window);
    gdk_window_set_opacity (GTK_WIDGET(widget)->window, 0.6);
  }

}

But still no joy.  It raises the dialog to the top of the Gtk windows,
but not on top of the mplayer (the other app) window.

Perhaps I should use a very simple directfb test application to test
that I can raise a directfb window on top of the window of another
application (like mplayer) before trying to do this with gtk.  At
least then I would know a bit more about looking into directfb/gdk and
seeing why it's not happening.  I know zilch about writing directfb
apps though.  Maybe one of the examples could be contorted with little
hassle to be a test.

> it seems that gtk-list or gtk-app-devel-list would be even more
> appropriate but let's continue this thread where it started.

Except that my only problems are how gtk is interacting with the
directfb gdk layer.  I would not 

> > To stay slightly on topic for this list though, it should be possible
> > for the windows of one app to ask to be raised above those of another
> > app with the multi-application core though, right?
> 
> yes.

Is there perhaps some way that mplayer's directfb implementation is
done that is preventing other applications from raising a window on
top of it?  Is there any way using directfb that an application can
command the top spot in window stacking and disallow any other
application to put a window on it?

b.

-- 
Brian J. Murrell

Attachment: pgp00018.pgp
Description: PGP signature