Loosing the Activity window after displaying a OpenFile dialog box

[Erik Garrison]

On Wed, Dec 17, 2008 at 12:37:55PM +0530, shivaprasad javali wrote:
> Hi ,
>   In the application that I am developing for the XO there is a Open button
> which displays an Open File dialog box and lets you choose which file to
> open in the activity. But when I click on the button and the dialog box is
> displayed, I loose my application window and I come back to the Sugar home
> screen after choosing  a file to open.
> 
>    The thing works perfectly on a normal Fedora machine and it's only when I
> am running on the OLPC that I loose the application window. I can see that
> the Activity is still running if I go to terminal activity and type in ps
> -A, but there is no window for my application.
> 
>    Could anyone think of what the problem might be? Is the window manager
> for sugar different from a normal Fedora distibution. If so how?

Yes.  The window manager used by Sugar is Matchbox, which has only a
limited concept of floating windows (it appears only transient windows
are rendered as floating and the rest get their own full screens).

This is an issue that in theory is not problematic, or only minorly so,
but in the practice of software development can be quite a pain.

Perhaps you should set the WM_TRANSIENT_FOR property on the OpenFile
dialog?  Below is the section from the ICCCM describing this property.

Note that Sugar doesn't have any concept of files from the UI-level so
unless you are opening a view into the journal users will not be able to
find anything interesting.

I hope this is helpful.  Without access to your source I am just
guessing.

Best,
Erik


from http://tronche.com/gui/x/icccm/sec-4.html

4.1.2.6. WM_TRANSIENT_FOR Property
The WM_TRANSIENT_FOR property (of type WINDOW) contains the ID of
another top-level window. The implication is that this window is a
pop-up on behalf of the named window, and window managers may decide not
to decorate transient windows or may treat them differently in other
ways. In particular, window managers should present newly mapped
WM_TRANSIENT_FOR windows without requiring any user interaction, even if
mapping top-level windows normally does require interaction. Dialogue
boxes, for example, are an example of windows that should have
WM_TRANSIENT_FOR set.

It is important not to confuse WM_TRANSIENT_FOR with override-redirect.
WM_TRANSIENT_FOR should be used in those cases where the pointer is not
grabbed while the window is mapped (in other words, if other windows are
allowed to be active while the transient is up). If other windows must
be prevented from processing input (for example, when implementing
pop-up menus), use override-redirect and grab the pointer while the
window is mapped. 

Erik