pinkas@hobbit.intel.com (Israel Pinkas ~) (02/07/89)
I am porting an application that currently uses serial graphics terminals
for graphics. Occasionally, the program needs to display a large quantity
of text, and switches the terminal to text mode (and hides the graphics).
In porting this application, the power that be decided that the mechanism
we would use would be to raise the xterm from which the application was
invoked and display the text. (We use the WINDOWID environment variable to
determine the correct xterm.)
The calling sequence is:
XSelectInput(disp, xterm_win, ExposureMask | StructureNotifyMask);
XRaiseWindow(disp, xterm_win);
do {
XWindowEvent(disp, xterm_win,
ExposureMask | StructureNotifyMask, &rep);
} while ((rep.type != ConfigureNotify) ||
(rep.type == Expose && rep.xexpose.count == 0));
XSelectInput(disp, xterm_win, NoEventMask);
This works fine when there is no window manager, or with uwm. However,
every other window manager that I have (dxwm, twm) reparents the xterm. As
a result, the XRaiseWindow() has no affect on the xterm window, and I hang
in the loop.
Is there any way to accomplish what I am trying to do. This port is fairly
short lived, so having the application create and manage it's text window
is not feasible. (We use the same code for an escape to shell, so we
cannot accomplish everything by having a window that we write text to.)
-Israel
--
--------------------------------------
Disclaimer: The above are my personal opinions, and in no way represent
the opinions of Intel Corporation. In no way should the above be taken
to be a statement of Intel.
UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cad001!pinkas
ARPA: pinkas%cad001.intel.com@relay.cs.net
CSNET: pinkas@cad001.intel.comdshr@SUN.COM (David Rosenthal) (02/07/89)
> I am porting an application that currently uses serial graphics terminals > for graphics. Occasionally, the program needs to display a large quantity > of text, and switches the terminal to text mode (and hides the graphics). > > In porting this application, the power that be decided that the mechanism > we would use would be to raise the xterm from which the application was > invoked and display the text. (We use the WINDOWID environment variable to > determine the correct xterm.) There is another point to be considered here. No interface that depends on application control over the stack order of top-level windows can be guaranteed to work with all window managers. The ICCCM specifies the way in which a client can REQUEST a change in stack order. But stack order, like window size and placement, is under window manager control. There is no guarantee that the window manager will honor the request for a change in stack order. Indeed, there are window managers (tiled ones, for example) for which the request has no meaning. Once the window managers catch up with the ICCCM, one would expect that most of them would attempt to satisfy the request, but there would be no guarantee. In other words, if you build the application the way you suggest, you will have to ensure that it is run with a specific window manager, and probably with a specific window manager configuration file (such as .uwmrc), in order to ensure that the window manager policy you depend on will be in effect. Once again, it is important to observe that X provides no guarantee of portability or inter-operability. The use of X makes it easier to provide both, but you cannot simply assume that something that works on your workstation with your window manager will automatically work on all workstations and with all window managers. That is the reason for the conventions (restrictions) set out in the ICCCM, and for the techniques set out in our Usenix paper on the choice of Visuals. There are many other areas yet to be covered in which portability problems may arise - one obvious example is the question of running out of resources on X terminals. David.
klee@daisy.UUCP (Ken Lee) (02/08/89)
In article <PINKAS.89Feb6133558@hobbit.intel.com> pinkas@hobbit.intel.com (Israel Pinkas ~) writes: > >In porting this application, the power that be decided that the mechanism >we would use would be to raise the xterm from which the application was >invoked and display the text. (We use the WINDOWID environment variable to >determine the correct xterm.) According to the ICCCM (which is supported by the X protocol), only the window manager should be able to raise and lower top-level windows, such as xterm, unless they (anti-socially) request OverrideRedirect. Thus, you probably can't do what you want with existing window managers and clients (xterm). You might try, however, hacking a version of xterm that sets OverrideRedirect and forking this from your client. You can then manage this window as if it was a client sub-window. The user interface will be inconsistent with other clients, but that's the price of hacking. Ken Lee -- klee@daisy.uucp Daisy Systems Corp., Interactive Graphics Tools Dept.
colas@mirsa.inria.fr (Colas NAHABOO) (02/10/89)
From article <PINKAS.89Feb6133558@hobbit.intel.com>, by pinkas@hobbit.intel.com (Israel Pinkas ~): > > In porting this application, the power that be decided that the mechanism > we would use would be to raise the xterm from which the application was > ... > > This works fine when there is no window manager, or with uwm. However, > every other window manager that I have (dxwm, twm) reparents the xterm. As > a result, the XRaiseWindow() has no affect on the xterm window, and I hang > in the loop. GWM (Generic Window Manager) handles this case (raise/lower in absolute and relative to another window). GWM has been selected on the OSF Catalog distribution and a version fully implementing the ICCCM should be ready for the X11R4 release. Colas NAHABOO BULL Research FRANCE -- Koala Project (GWM X11 Window Manager) Internet: colas@mirsa.inria.fr Surface Mail: Colas NAHABOO, INRIA - Sophia Antipolis, 2004, route des Lucioles, 06565 Valbonne Cedex -- FRANCE Voice phone: (33) 93.65.77.71