X-Windows/Motif: Multihost multiwindows navigation. - Xwindows

This is a discussion on X-Windows/Motif: Multihost multiwindows navigation. - Xwindows ; Hello everybody. A customer has the following scenario: Several separate VMS hosts H1, H2, ... Hn each running its own copy of a large Motif client application, consisting of several toplevel windows. All hosts H1...Hn have displays on a single ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: X-Windows/Motif: Multihost multiwindows navigation.

  1. X-Windows/Motif: Multihost multiwindows navigation.

    Hello everybody.

    A customer has the following scenario:

    Several separate VMS hosts H1, H2, ... Hn each running its own
    copy of a large Motif client application, consisting of several toplevel
    windows.

    All hosts H1...Hn have displays on a single X-server (which happens to
    be one of them). The assignment is now to implement a function, which
    allows the operator to select all windows originating from one single
    host Hx and make them visible, and at the same time making the windows
    from all the other hosts invisible (or iconized).

    It is not an option to modify the large Motif client application.

    The systems run a variety of VMS and Motif versions:

    Some run OpenVMS V7.3-1 with Motif V1.3-0
    Some run OpenVMS V7.3 with Motif V1.2-6
    Some run OpenVMS V7.2 with Motif V1.2-5

    Window management is done using 'mwm' and the 'old-style' desktop.

    By inspecting the WM_CLIENT_MACHINE property of the windows, it
    is possible to find out, where a particular window originates from. This
    leaves the problem of implementing the functions 'make this window visible'
    and 'make this window invisible'.

    I have explored the following avenue:

    A client window has as its immediate parent a decoration window owned
    by 'mwm'.

    It is possible to iconize the client by

    1. Sending (with XSendEvent) an MB1 ButtonPress event to the 'mwm' parent window
    (this causes the 'mwm' parent window to take focus).
    2. Sending (with XSendEvent) an F9 KeyPress event to the 'mwm' window.

    This causes 'mwm' to make the client window and its own decoration window
    invisible (xwininfo reports IsUnmapped on the client window and IsUnviewable
    on the decoration window). Also, a window containing an icon representing
    the iconized client becomes visible.

    It is possible to normalize the client by

    1. Sending (with XSendEvent) an MB1 ButtonPress event to the icon window.
    2. Sending (with XSendEvent) an F5 KeyPress event to the icon window.


    A major problem with this approach is, that I have found no readily apparent
    way of identifying which icon window belongs to which client - presumably 'mwm'
    maintains an internal list of 'client window'-'icon window' associations, but
    this list seems to be unavailable to the outside world.

    The question is of course now: Does anyone have suggestions about how I
    can solve this problem? Either by pointing out a way of identifying the
    icon window belonging to a given client, or by suggesting an entirely
    different approach (don't be shy, anything will be appreciated).

    Best regards
    Jesper Naur

  2. Re: X-Windows/Motif: Multihost multiwindows navigation.

    Jesper Naur wrote:
    >Hello everybody.
    >
    >A customer has the following scenario:
    >
    >Several separate VMS hosts H1, H2, ... Hn each running its own
    >copy of a large Motif client application, consisting of several toplevel
    >windows.
    >
    >All hosts H1...Hn have displays on a single X-server (which happens to
    >be one of them). The assignment is now to implement a function, which
    >allows the operator to select all windows originating from one single
    >host Hx and make them visible, and at the same time making the windows
    >from all the other hosts invisible (or iconized).
    >
    >It is not an option to modify the large Motif client application.
    >
    >The systems run a variety of VMS and Motif versions:
    >
    >Some run OpenVMS V7.3-1 with Motif V1.3-0
    >Some run OpenVMS V7.3 with Motif V1.2-6
    >Some run OpenVMS V7.2 with Motif V1.2-5
    >
    >Window management is done using 'mwm' and the 'old-style' desktop.
    >
    >By inspecting the WM_CLIENT_MACHINE property of the windows, it
    >is possible to find out, where a particular window originates from. This
    >leaves the problem of implementing the functions 'make this window visible'
    >and 'make this window invisible'.
    >
    >I have explored the following avenue:
    >
    >A client window has as its immediate parent a decoration window owned
    >by 'mwm'.
    >
    >It is possible to iconize the client by
    >
    >1. Sending (with XSendEvent) an MB1 ButtonPress event to the 'mwm' parent window
    > (this causes the 'mwm' parent window to take focus).
    >2. Sending (with XSendEvent) an F9 KeyPress event to the 'mwm' window.
    >
    >This causes 'mwm' to make the client window and its own decoration window
    >invisible (xwininfo reports IsUnmapped on the client window and IsUnviewable
    >on the decoration window). Also, a window containing an icon representing
    >the iconized client becomes visible.
    >
    >It is possible to normalize the client by
    >
    >1. Sending (with XSendEvent) an MB1 ButtonPress event to the icon window.
    >2. Sending (with XSendEvent) an F5 KeyPress event to the icon window.
    >
    >
    >A major problem with this approach is, that I have found no readily apparent
    >way of identifying which icon window belongs to which client - presumably 'mwm'
    >maintains an internal list of 'client window'-'icon window' associations, but
    >this list seems to be unavailable to the outside world.
    >
    >The question is of course now: Does anyone have suggestions about how I
    >can solve this problem? Either by pointing out a way of identifying the
    >icon window belonging to a given client, or by suggesting an entirely
    >different approach (don't be shy, anything will be appreciated).
    >
    > Best regards
    > Jesper Naur


    Generally speaking, I would advise against trying to simulate user input
    by sending synthetic events. It often turns out to be fragile, and a
    cause of trouble later on.

    The ICCCM gives the proper procedure, viz

    Normal->Iconic -- send a WM_CHANGE_STATE message to the root window
    Iconic->Normal -- map the client window

    This leaves the problem of filtering the client windows for deciding
    how they are treated, but you already have a good start on that. Remember
    that the windows belonging to an iconized application still exist: they
    simply are not mapped, and thus are still visible to XQueryTree.


+ Reply to Thread