Always on Top

[Odenthal, James P]

________________________________

From: xfce-bounces at xfce.org on behalf of Olivier Fourdan
Sent: Sun 11/19/2006 10:42 AM
To: XFCE general discussion list
Subject: Re: Always on Top



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


James,

Odenthal, James P wrote:
>>>> However in XFCE 4.2.2, wmxf4;  The visibility event is working; but the
>>>> gtk_window_present() seems to have no effect. The window that I need
>>>> always on top remains under the other dialog.
>
> Note that I can't get the visibility-notify to work (that's why I'd like
> to get your sample code), but gtk_window_present() does properly raise
> and focus the window in both xfwm4 4.2 and 4.4 here (see attached sample
> code that raise the window on enter event, ie, move the pointer inside
> the window and it gets raised).
> =================================================
>
> Many many thanks.  We are not alone.
>
> I use Glade to build from a rather large project we just sent offshore to get "linux'd".  Hard for me to quickly make a small test program.  But I will; and I wanted to say thanks for the lifeline. The offshore group provided us with a developement box running FC4/Gnome/Metacity. Our Target OS is a LinuxFromScratch built in-house by our linux guru, who just left.  

It's ok, no problem, you can safely forget about the test program.

> To get visibility to work,....I selected an event mask; and Glade adds: 
>
>     gtk_widget_set_events(widget,GDK_VISIBILTY_NOTIFY_MASK). Perhaps the ENTRY_MASK is set by default?

Oh, right. BTW, the problem is not with visibility-notify but rather
with gtk_window_present() not raising the window.

Does the attached program works for you? It does work properly here. But
I'm not using gtk+-2.6 bit gtk+-2.10 so there might some difference.

If not, does calling gdk_window_raise(widget->window) work?

HTH,
Cheers,
Olivier.
================================

Calling gdk_window_raise() instead of gtk_window_present() made no difference with my fully-loaded dialogs.  Still get visibilty events; but the window I am trying to raise remains under.  With my Metacity setup, the obscured dialog does rise. 

I tried simple dialogs.  With Glade I created a window with 2 simple dialogs.  Both Meta and xfwm4 allowed raising and/or presenting.   I used a visibility_event to trigger raising (or presenting).   With two dialogs at same "above" setting, I could keep one dialog atop by calling GDK_raise() or gtk_present() as visibility event reported.

As I recall, freedesktop.org  has a hierarchy of stacking: Desktop, Below, Neither, Above, with Transient_for on top.  Maybe both my fully-loaded dialogs are transient_for; and I just don't know it?  Maybe the transient_for states are clobbering the raise(), present() commands in LFS/XFCE/xfwm4; but not FC4/Gnome/Metacity?   

Some other Xfwm / Metacity deltas:

xfwm: I can maximize() dialogs.                                                          Metacity: Did not respond to maximize() of a dialog.

xfwm: Scrolling gives visibility_events:  1 on scroll;  and 0 on unscroll.     Meta: Events nothing on scroll.  Then a invisible(2)/visible(0) event pair when unscrolling!?

It's probably some preference.  As you suggested transient_for().  API mentioned transient_for() hidden in some convenience function.  Example: new_dialog_with_buttons().  Not used in my glade interface.c output.   Transient_for may dominate my above,  below, or present hints.   I think gtk can read back transient_for state.. 

Then again the language in APIs about window managers is disconcerting.  No commands, just hints.  It was good hear present() can work if done right.

I appologize for my slow response.  Only a few weeks on Linux.  Target has no network, flash mounting is sporadic.   

Thank you for your patient efforts.

JimO

=======================




This message (including any attachments) contains confidential 
and/or proprietary information intended only for the addressee.  
Any unauthorized disclosure, copying, distribution or reliance on 
the contents of this information is strictly prohibited and may 
constitute a violation of law.  If you are not the intended 
recipient, please notify the sender immediately by responding to 
this e-mail, and delete the message from your system.  If you 
have any questions about this e-mail please notify the sender 
immediately.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 7386 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce/attachments/20061119/4453c156/attachment.bin>