margaret@ms.uky.edu (toe_sucker in the dark) (01/07/88)
This might be a stupid question, but how do I check if a window
is an Icon?
Thanks,
Margaret
--
Malgorzata Marek ARPA: margaret@ms.uky.edu
UUCP: {uunet,cbosgd}!ukma!margaret
-- What did you do with that chair? BITNET: margaret@UKMA.BITNET
-- Chair? I ate it. CSNET: margaret@ms.uky.csnetdshr@SUN.COM (David Rosenthal) (02/05/88)
> This might be a stupid question, but how do I check if a window > is an Icon? This is not a stupid question. A draft conventions document will (I hope) be available with R2 which explains the client's view of window management. Among other things, it explains how in the future (once window managers have been converted to adhere to the conventions) you can find out if you are open or iconic. At present, there is no good method. David.
oj@apollo.uucp (Ellis Oliver Jones) (02/07/88)
>> How do I check if a window >> is an Icon? You can find out whether your window is mapped or not via Xlib's XGetWindowAttributes request. Being unmapped is not, strictly speaking, exactly the same thing as being iconized. However, if you're inquiring about a top level window mapped by you (by some request or toolkit operation in your program), but never unmapped by you, it's a safe bet that the window manager unmapped it. If all you want to know is whether to refrain from drawing because your window's unmapped, this is a winning strategy. If you're using Xlib instead of the toolkit (you are? fie!) you can easily solicit events using StructureNotifyMask and keep track of MapNotify/UnmapNotify events. /oj
dshr@SUN.COM (David Rosenthal) (02/07/88)
> You can find out whether your window is mapped or not via Xlib's > XGetWindowAttributes request. Being unmapped is not, strictly speaking, > exactly the same thing as being iconized. However, if you're inquiring > about a top level window mapped by you (by some request or toolkit > operation in your program), but never unmapped by you, it's a safe bet > that the window manager unmapped it. If all you want to know is whether > to refrain from drawing because your window's unmapped, this is a > winning strategy. This is misleading, not to say wrong. Almost all window managers will re-parent your top-level window to be a child of a window belonging to the window manager. When the WM iconifies you, it will unmap its own window, causing your top-level to be mapped but unviewable (because its parent is unmapped). Thus, you will never find your top-level unmapped, even when you are iconic. With R2, there will be a manual called the "Inter-Client Communications Conventions Manual". Although it will still be a draft, it will be pretty close to the way things will eventually turn out. It explains how to find out if you are iconic reliably (examine the WM_STATE property on your top-level window, window managers must maintain this and you can get PropertyNotify events on it when they change it). There is much more in the manual (its currently 22 pages) about how you relate to window managers and also to the selection service. Unfortunately, it will take time for these conventions to be finalized and blessed, and more time still for existing window managers, toolkits, and so on to be upgraded to adhere to them. In the meantime, things will be frustrating because there may be no clear recommendation on what to do, or because there is a clear recommendation but it doesn't work yet. In some cases, resolving these problems involves experimentation, because the implications of some of these conventions in circumstances like the window manager crashing are difficult to predict. We are trying to resolve these problems as fast as possible, and in the meantime we are supplying the manual in draft form to explain what is already pretty certain. Many of these issues were thrashed out in a sideline meeting at the recent X conference. David.
SMILEY@LL.ARPA (08/18/88)
We need to get a copy of the source code of the Sun distribuiton
of X Windows v11. Can you send this?
L. Smiley
SMILEY@LL.ARPA (10/06/88)
Can anybody tell us anything about where we might get an X vdi for a Sun with GKS?
SMILEY@LL.ARPA (10/17/88)
Has anyone heard of an X VDI for GKS? I saw a diagram in an article about The X Window System (1986, Association for Computing Machinery). It was a system structure diagram, part of which showed a GKS library above an X VDI above an X library. I think it was in reference to X10. Does anyone have any idea what I'm talking about? Was this something in X10? Is it available for X11? Was it a figment of my imagination? Any comments on this subject would be much appreciated.
grogers@m.cs.uiuc.edu (10/18/88)
This was originally posted in August ...
=============== Software Availability Announcement ===============
The department of Computer Science and the Graphics Workstation
Research Group would like to announce the availability of the XGKS
graphics library. At this time it is available only to educational
institutions and only for use for internal research and instructional
purposes.
XGKS is a full implementation of the ANSI standard Graphical Kernel
System for use within the X Window System. XGKS provides for two
dimensional graphics using ANSI standards within the generally accepted
standard X window system. This software has been in use for
approximately nine months within the C.S. department for both research
and instructional purposes and has been rigorously tested.
Highlights
----------
* Full support for ANSI Standard GKS (level 2C)
* Support for color and monochrome displays
* Runs within the X Window System
* Support for multiple windows and displays
* Efficient implementation
* Rigorously tested
* Hides complexity of window system programming
Output Primitives
-----------------
* Polylines (control over color, width, and style)
* Markers (color, size, style)
* Text (fully transformable, color, 9 font styles)
* Polygons (application defined color patterns and colors)
* Cell Arrays (transformable pixel arrays)
Input Devices
-------------
* Locator (tracking cross, rubberband line or box)
* Choice (menus or function buttons)
* Stroke (point streams)
* Valuator (range indicators)
* Pick (selection of output primitives)
* String (keyboard input)
XGKS supports all six logical input devices through the use of a mouse
and keyboard.
Storage
-------
* Segments (runtime storage of output pickable primitives)
* Metafiles (longterm file storage of graphical objects)
In addition to the standard segment facility of GKS, XGKS provides
storage of non-segment output primitives. This frees the application
from the complexity of window system management.
XGKS has been thoroughly tested on an IBM RT running Berkeley Unix, and
has been ported to the Encore Multmax and Sun workstation. This
software is available immediately from the department of Computer Science.
For additional information contact:
Greg Rogers
University of Illinois at Urbana-Champaign
Department of Computer Science
1304 W. Springfield Ave.
Urbana, IL 61801
(217) 333-6174
UUCP: {pur-ee,convex,inhp4}!uiucdcs!grogers
ARPA: grogers@cs.uiuc.edu
CSNET: grogers%uiuc@csnet-relayclyne@redcloud.ucar.edu (John Clyne) (08/15/89)
This should not be too hard to do but I haven't been able to figure out a simple solution: I want to have a generic warning routine, call it display_warning(), that when invoked will popup and display a warning message (under the Xt instrinics) and require the user to select a proceed or cancel button. The problem is that I want display_warning() to return a value depending on the user's selection. How do I get display_warning() to wait until a selection has been made before returning?. display_warning() also needs to know which selection has been made and indicate this in the return. Is there a simple way to due this? thanks much - jc John Clyne (clyne@ncar.ucar.edu) c/o National Center for Atmospheric Research P.O. Box 3000 Boulder, Colorado 80307 (303) 497-1236 %%% Its a small world. But I wouldn't want to paint it %%% S. Wright %%% %%%
converse@EXPO.LCS.MIT.EDU (Donna Converse) (08/16/89)
> I want to have a generic warning routine, call it display_warning(), > that when invoked will popup and display a warning message > (under the Xt instrinics) and require the user to select a proceed or > cancel button. The problem > is that I want display_warning() to return a value depending on the > user's selection. How do I get display_warning() to wait until a selection > has been made before returning?. I think the programming model for control flow needs to be changed from a computational one to an event driven model. The user is out there doing stuff that causes your program to get notification of events. Your program cannot control or anticipate the order of events, or the timing between events. Instead, your code is a collection of responses to events, with callbacks and client data and some global variables as "chewing gum and paperclips" holding it all together. When you (the application programmer) popup the warning, you can't block at the next line of code waiting for the user to press a button. You probably already understand this, at least intuitively. Consider how the application processes events -- XtAppMainLoop, usually. After you popup the warning, let the control return to the main loop. Otherwise, what is going to process the event of the user pushing a button in the popup? The problem of knowing which button was pressed can be solved by registering a different callback procedure with each button in the popup, or by giving each button different data to pass to a single callback. The confirm callback can actually do the body of the computation, the work requested. Donna Converse converse@expo.lcs.mit.edu
mlm@odi.com (Mitchell Model) (08/16/89)
In article <3982@ncar.ucar.edu> clyne@redcloud.ucar.edu (John Clyne) writes: This should not be too hard to do but I haven't been able to figure out a simple solution: I want to have a generic warning routine, call it display_warning(), that when invoked will popup and display a warning message (under the Xt instrinics) and require the user to select a proceed or cancel button. The problem is that I want display_warning() to return a value depending on the user's selection. How do I get display_warning() to wait until a selection has been made before returning?. display_warning() also needs to know which selection has been made and indicate this in the return. Is there a simple way to due this? One way is to do the following after XtPopup(shell, XtGrabExclusive): flag = True; while (flag) ProcessOneEvent(XtDisplay(shell)); return result; with: void ProcessOneEvent(display) Display *display; { static XEvent event; XNextEvent(display, &event); XtDispatchEvent(&event); } There's a further trick, though: your callback functions have to set result, popdown shell, and set flag to false. There are various ways to do this, all awkward, including global variables and packaging up stuff like this into a record that you provide as the client_data for the callback. Here's the complete code for a Yes/No confirmation widget. I originally took this code from contrib/hacks/xpostit/confirm.c then hacked it up to wait for user response as well as add some other features my application needed (in particular warping the cursor back to where it was before the confirmation popped up). Thanks to David Curry, xpostit author, for xpostit: a really useful utility and a source of well-structured, commented, and X-instructive code. Mitchell L Model Director, HeadStart Program Object-Design, Inc. One New England Park Burlington MA 01803 (617) 270-9797 mlm@odi.com ============================================================================== /* confirm -- copied from $x/contrib/hacks/xpostit/confirm.c and xpostit.h then modified to be simpler -- not use callbacks, just return true or false */ /* mlm: 5-17-89 added wait loop 3-17-89 changed to just return Bool 3-16-89 added toplevel to ConfirmIt arg list, to make this completely independent */ #include <X11/Xlib.h> /* for Bool, etc. */ #include <X11/StringDefs.h> #include <X11/Intrinsic.h> #include <X11/Label.h> #include <X11/Command.h> #include <X11/Shell.h> #include <X11/Form.h> #include <stdio.h> #include "confirm.h" #include "xutil.h" /* from xpostit.h */ #define SetArg(which, val) XtSetArg(args[nargs], (which),\ (XtArgVal) (val)); nargs++ typedef struct _result { Bool *popflg, *var; int root_x, root_y; Window root; Widget shell; } *Result; static Result MakeResult(shell, popflg, resultvar, root, root_x, root_y) Bool *popflg, *resultvar; Window root; int root_x, root_y; Widget shell; { Result rec = (Result) malloc(sizeof(struct _result)); rec->popflg = popflg; rec->var = resultvar; rec->root = root; rec->root_x = root_x; rec->root_y = root_y; rec->shell = shell; return rec; } /* ARGSUSED */ /* * ClearConfirm - get rid of the confirmation box. */ /* ARGSUSED */ void ClearConfirm(w, val, result) Widget w; Bool val; Result result; { Display *display = XtDisplay(w); XtPopdown(result->shell); XtDestroyWidget(result->shell); *result->popflg = False; *result->var = val; XWarpPointer(display, None, result->root, 0, 0, 0, 0, result->root_x, result->root_y); } /* ARGSUSED */ static void Yes(w, result, call_data) Widget w; Result result; caddr_t call_data; /* unused */ { ClearConfirm(w, True, result); } /* ARGSUSED */ static void No(w, result, call_data) Widget w; /* unused */ Result result; caddr_t call_data; { ClearConfirm(w, False, result); } #define btnsepr 8 static void adjust(label, yes, no) Widget label, yes, no; { Arg args[2]; int nargs; int labelwidth, yeswidth, btnborder, btnwidth; if (!label) labelwidth = 0; else { nargs = 0; SetArg(XtNwidth, NULL); XtGetValues(label, args, 1); labelwidth = args[0].value; } nargs = 0; SetArg(XtNwidth, NULL); SetArg(XtNborder, NULL); XtGetValues(yes, args, 2); yeswidth = args[0].value; btnborder = args[1].value; btnwidth = (labelwidth-btnsepr-4*btnborder)/2; if (btnwidth < yeswidth) btnwidth = yeswidth; nargs = 0; SetArg(XtNwidth, btnwidth); XtSetValues(yes, args, 1); XtSetValues(no, args, 1); } /* * Confirm - put up a window asking for confirmation. */ Bool Confirm(toplevel, prompt) Widget toplevel; char* prompt; { static Arg args[4]; register int nargs; static Bool inited = False; Bool poppedup=False, result=False; static Widget shell, form, label, yes, no; static int root_x, root_y, child_x, child_y, buttons; static Window root, child; static Result resultrec; inited = False; /* recreate each time for now */ /* * Find out where the mouse is, so we can put the confirmation * box right there. */ XQueryPointer(XtDisplay(toplevel), XtWindow(toplevel), &root, &child, &root_x, &root_y, &child_x, &child_y, &buttons); /* * If we need to construct the confirmation box do that, * otherwise just reset the position and callbacks and * put it up again. */ if (!inited) { nargs = 0; SetArg(XtNx, root_x); SetArg(XtNy, root_y); SetArg(XtNinput, True); shell = XtCreatePopupShell("Confirm", transientShellWidgetClass, toplevel, args, nargs); nargs = 0; form = XtCreateManagedWidget("form", formWidgetClass, shell, args, nargs); if (!prompt) label = NULL; else { nargs = 0; SetArg(XtNlabel, prompt); SetArg(XtNborderWidth, 0); label = XtCreateManagedWidget("prompt", labelWidgetClass, form, args, nargs); } nargs = 0; if (prompt) { SetArg(XtNfromVert, label); SetArg(XtNvertDistance, 12); } yes = XtCreateManagedWidget("yes", commandWidgetClass, form, args, nargs); nargs = 0; SetArg(XtNfromHoriz, yes); SetArg(XtNhorizDistance, btnsepr); if (prompt) { SetArg(XtNfromVert, label); SetArg(XtNvertDistance, 12); } no = XtCreateManagedWidget("no", commandWidgetClass, form, args, nargs); adjust(label, yes, no); XtRealizeWidget(shell); inited = True; } else { /* * Reset the confirmation box position. */ nargs = 0; SetArg(XtNx, root_x); SetArg(XtNy, root_y); XtSetValues(shell, args, nargs); } resultrec = MakeResult(shell, &poppedup, &result, root, root_x, root_y); XtAddCallback(yes, XtNcallback, Yes, resultrec); XtAddCallback(no, XtNcallback, No, resultrec); XtPopup(shell, XtGrabExclusive); poppedup = True; while(poppedup) ProcessOneEvent(XtDisplay(shell)); return result; } #undef btnsepr -- Mitchell L Model Director, HeadStart Program Object-Design, Inc.
mlm@odi.com (Mitchell Model) (08/16/89)
A couple of adjustments to the code I just posted for a confirm
widget:
First of all, it includes confirm.h, which is just:
#include <X11/StringDefs.h>
#include <X11/Intrinsic.h>
#include <X11/Shell.h>
Bool Confirm(/* toplevel, msg */);
and I'm not sure whether all of these are really needed or are left
over from an earlier stage of evolution.
It includes stdio.h, which it doesn't need (it probably once did).
It includes xutil.h, which is my collection of x hacks from which
ProcessOneEvent was taken. Replace that include with the definition
of ProcessOneEvent given above. I don't think it uses anything else
from my xutil.
More importantly, I neglected to incorporate a solution to the
"window-manager menu shows through dialog box" bug I asked about last
week. I received a reply to that query which leads to the following
simple fix to code like the above:
put somewhere:
static String CatchButtonTranslation = "<BtnDown>,<BtnUp>:\n";
put before form = XtCreateManagedWidget("form", ...)
SetArg(XtNtranslations,
XtParseTranslationTable(CatchButtonTranslation));
There may well be other problems, in which case send mail and I might
be able to help.
--- Mitchell Model
--
Mitchell L Model
Director, HeadStart Program
Object-Design, Inc.duanev@kauai.ACA.MCC.COM (Duane Voth) (08/17/89)
In article <8908151941.AA26642@expo.lcs.mit.edu>, converse@EXPO.LCS.MIT.EDU (Donna Converse) writes: > > > I want to have a generic warning routine, call it display_warning(), > > that when invoked will popup and display a warning message > > (under the Xt instrinics) and require the user to select a proceed or > > cancel button. The problem > > is that I want display_warning() to return a value depending on the > > user's selection. How do I get display_warning() to wait until a selection > > has been made before returning?. > > I think the programming model for control flow needs to be changed from a > computational one to an event driven model. The user is out there doing > stuff that causes your program to get notification of events. Your program > cannot control or anticipate the order of events, or the timing between > events. Instead, your code is a collection of responses to events, with > callbacks and client data and some global variables as "chewing gum and, > paperclips" holding it all together. I ran into this same problem. A function like display_warning() forces the user to focus his attention on a very specific point. The application is basically helpless until the user deals with the warning. In addition, the warining popup focuses input thus severely restricting the kinds of "application" events that occur. So why force returning all the way back to the main event handler. Bottom line is: the application code looks MUCH nicer if a function like display_warning() can return a 1 or a 0. The way I did this is as follows: #define WAITING 0 #define PROCEED 1 #define CANCEL 2 static int warning_response; proceed_button_callback() { warning_response = PROCEED; } cancel_button_callback() { warning_response = CANCEL; } display_warning() { XEvent event; /* popup warning window... */ warning_response = WAITING; while (warning_response == WAITING) { XtAppNextEvent(appContext, &event); XtDispatchEvent(&event); } /* popdown and cleanup */ return(warning_response); } Clean, efficient, functional. duane -- --- duane voth duanev@mcc.com ---- ALL systems are arbitrary! --- effectiveness is the measure of Truth --
janssen@holmes (Bill Janssen) (08/17/89)
The one problem with the approach that converse@EXPO.LCS.MIT.EDU suggests is that the display_warning() routine will return from the warning-box creation routine prematurely. To get around this, recursively call the main loop, and have the callback for the button return from the recursive call when pressed, thereby returning to the code in display_warning(), and then return from display_warning with the appropriate value. Bill -- Bill Janssen janssen.pa@xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
dean@osf.osf.org (Dean Anderson) (08/17/89)
In article <2523@arisia.Xerox.COM> janssen@holmes (Bill Janssen) writes: >The one problem with the approach that converse@EXPO.LCS.MIT.EDU suggests >is that the display_warning() routine will return from the warning-box >creation routine prematurely. To get around this, recursively call the >main loop, and have the callback for the button return from the recursive >call when pressed, thereby returning to the code in display_warning(), and Recursively call XtMainLoop? How do you propose to get XtMainLoop to return? (Without using setjmp) I think the point of what Donna Converse was originally trying to say has been missed. Instead of trying to force flow of control, you should adopt a model in which the program takes actions in response to "external" events whose order the program has no control over. For example, If you want to force the user to respond to a dialog, try popping up the dialog menu with a pointer grab. When the user responds, take whatever action is necessary in the callback (possibly save the response data for use in modifying the actions for other events, etc). Motif includes facilities for modal dialog widgets which do exactly what it is I think that you want to do: Make the user respond before any further processing within the application. Dean Dean Anderson | Views Expressed do not represent those of dean@osf.org uunet!osf.org!dean | either my employer or myself! OPEN Software Foundation |
aparisi@BBN.COM (Corporal Jones) (08/18/89)
Actually, there may be a very good reason to nest an event loop. Say you need to implement a command-driven style of interaction within a toolkit application. I know we are trying to avoid this at all costs in the Brave New World of the future, but there are some large, monolithic, command-driven applications out there that people are converting to X. Often a first step in the conversion is to provide GUI front ends to a subset of the functionality, and provide a command-driven escape hatch (for example, a DECWindows Command widget) for the non-converted functionality. In this scenario, the application will want the main thread to be blocked on a command read until a command is actually entered. The way to do the block is to nest an event loop (NOT XtMainLoop, naturally-- as you said, how will it return?) in the procedure that does the read from the command widget. The event loop would terminate when a command is entered. (It probably detects this using a semaphore that is set by the command widget's commandEntered callback). Tony Parisi BBN Software Products Cambridge, MA
schoeller@lbduck.dec.com (Dick Schoeller) (08/19/89)
In article <8908180033.AA00450@expo.lcs.mit.edu>, aparisi@BBN.COM (Corporal Jones) writes: > Actually, there may be a very good reason to nest an event loop. > > Say you need to implement a command-driven style of interaction within a > toolkit application. I know we are trying to avoid this at all costs in > the Brave New World of the future, but there are some large, monolithic, > command-driven applications out there that people are converting to X. > Often a first step in the conversion is to provide GUI front ends to a > subset of the functionality, and provide a command-driven escape hatch (for > example, a DECWindows Command widget) for the non-converted functionality. > > In this scenario, the application will want the main thread to be blocked > on a command read until a command is actually entered. The way to do the > block is to nest an event loop (NOT XtMainLoop, naturally-- as you said, > how will it return?) in the procedure that does the read from the command > widget. The event loop would terminate when a command is entered. (It > probably detects this using a semaphore that is set by the command widget's > commandEntered callback). > Command driven applications are the easiest to port to event driven (after all, events are just graphical commands 8^{). There is really no need to go through all the above mess about blocking and multiple threads. There is usually no reason to use some other looping structure than XtMainLoop either. The simplest approach is to take the routines that would have been called in response to the original command and put them in the callback for the applicable widget. If there are any operations which have not been moved to a specific widget, you simply parse them out in the callback from a command entry widget. The applications that ARE hard to deal with in the X Toolkit are AST driven applications or application driven users. These are the situations where XtMainLoop falls short. (Esp. AST driven since Xt is not AST re-entrant). Dick Schoeller | schoeller@gvriel.enet.dec.com Digital Equipment Corporation | 508-493-1670 129 Parker Street, PKO3-1/H21 | Maynard, MA 01754-2571 | This author has no opinions to disclaim!
janssen@holmes (Bill Janssen) (08/19/89)
In article <445@paperboy.OSF.ORG>, dean@osf (Dean Anderson) writes: >In article <2523@arisia.Xerox.COM> janssen@holmes (Bill Janssen) writes: >>... >>creation routine prematurely. To get around this, recursively call the >>main loop, and have the callback for the button return from the recursive >... >Recursively call XtMainLoop? How do you propose to get XtMainLoop to >return? (Without using setjmp) I think the point of what Donna >... Well, I confess that I don't use the vanilla XtMainLoop. My callback routines return a boolean which indicates to the event dispatcher whether or not to return from the event dispatching loop. Thus my pop-up confirmers can pop up the widget and call the event dispatching loop. When the event loop returns, the application knows that the pop-up structure contains the appropriate state (having been stored there by the callback for the pop-up, which returned "return-from-event-loop" to the event dispatching routine). This is equivalent to the schemes being posted here and there, except that the user does not have to re-write the event dispatching loop for each confirmer. In addition, my dispatcher also looks for input on other streams, not just the X stream, so that the whole application is not locked up just because the interface is. There are objections to this approach, along the lines of "The user should not be able to do anything until the confirmer has been dealt with." I think that is the worst kind of wrong-headed thinking, probably due to inexperience with confirmer systems. The user should be able to investigate the environment before making an informed response to the confirmer. This means that they should be able to pop up windows, look at files, etc. I'll agree that there needs to be some attention focussing method, so that the confirmer doesn't get forgotten, but it should *never* block other input. On the other hand, I can imagine an implementation of a blocking confirmer that uses a re-entrant dispatching loop... Bill -- Bill Janssen janssen.pa@xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
phil@goldhill.COM (08/22/89)
There are cases where the user should not be allowed to do anything except respond to the popup. I have popup's that block all input in the case when a malloc has failed - the popup is to notify the user that such a condition has arisen and inform them that cleanup is about to occur and that a "safe" state in the application is to be returned to. I also have popups that don't block all other processing and are "well behaved" with respect to other users of the server. The fact that conditions arise with varying degrees of severity indicates that atleast two types of popups are needed and should be planned for when building and designing the UI for an application. Phil Stanhope Gold Hill Computers, Inc. Cambridge, MA. phil@goldhill.com
janssen@ARISIA.XEROX.COM (Bill Janssen) (08/23/89)
> *Excerpts from mail: 22-Aug-89 help (with a popup prompt d..* > *phil@goldhill.com (891)* > The fact that conditions arise with varying degrees of severity indicates > that atleast two types of popups are needed and should be planned for > when building and designing the UI for an application. Yes, I'm not really as dogmatic as I tend to sound on that issue. Though I still wouldn't use the pop-up mechanism to block, but would rather have the `block-input-from-user' function packaged by itself, independent of the pop-ups, so that the ``severe'' case you mention would be handled by: BlockUserInput(); PopUpMessage ("Environment trashed. Unwinding."); rather than PopUpMessageBlocking(""Environment trashed. Unwinding."); Note that BlockUserInput() only blocks events that come from the user, such as keystrokes and mouse-strokes. The Expose events that cause the pop-up to be painted go through just as they normally would. A tougher trick is to block input only on windows that were created *before* the critical event occurred, but not on later-created windows. For this, some kind of stack in the event-dispatcher is needed. The timestamp in the MapNotify event of a newly-created window could be used, or the client could use XSendEvent to send an event through that window, and use that timestamp, when the window is registered with the event-dispatcher. Then BlockUserInput() would push a timestamp (where does it get it? from the server again?) onto an input-blocking stack, and only user events on windows with later timestamps than the head of the stack would be allowed to dispatch to their windows' event handlers. Bill -- Bill Janssen janssen.pa@xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (08/24/89)
> From: phil@goldhill.com > There are cases where the user should not be allowed to do anything > except respond to the popup. Perhaps, but I don't think this is it. The only case where I can see any excuse for hijacking all user input is when the entire window system, not just one application, is threatening to be unusable. For example, a window manager popping up an alert "ill-behaved application on the rampage, do you want to XKillClient or let it run?". > I have popup[']s that block all input in the case when a malloc has > failed - the popup is to notify the user that such a condition has > arisen and inform them that cleanup is about to occur and that a > "safe" state in the application is to be returned to. So why force the user to respond? There's nothing they can do about it; why not simply make *your application* freeze until the popup is responded to? I certainly know I might well want to switch to another window and look at a doc file, or run gcore...or perhaps even trash the whole program. I would be most annoyed if I had to go find a terminal and log in again to get a chance to look at something - probably enough so that I'd either trash the program entirely or fix it before proceeding further. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
fred%euler@dogwood.atl.ga.us (Fred Fenimore) (10/10/89)
Sirs, I am interested in getting on your list but do not know what to do. Can you help me or direct me to someone who can? Thanks in advance, Fred Fenimore
rs0thp@rohmhaas.COM (Dr. Tom Pierce) (01/30/91)
Please send help on the mailing list
vu2070@bingvaxu.cc.binghamton.edu (Leonard Borowski) (03/07/91)
Hello, I need some help badly. You see the problem is, I want to start programming in the x-windows protocol, whatever that means. Essentially, I want to learn how to create a window(s) and work use graphics in that window while I am programming in C. I'd like the input/output of the graphics of that screen controlled by both the mouse and the keyboard. The problem is, that no one here at my school seems to be able to help me, or at the very least send me in the right direction. The documentation on x-windows seems to be pretty scarce here. My guess is that I merely need to know what library files to access and what commands are available to me. If anyone out there has any info to help me I would greatly appreciate it. I plan to do all my programming on a SPARC station 1 that uses SunOS 4.1 and I run X11R4, if more info is needed please ask, and thanx in advance. Len
ppluzhni@composer.helios.nd.edu (paul pluzhnikov) (05/02/91)
How to detect mouse double clicks under X ? My manuals seem to mention just ButtonPress/Release ... I would greatly appreciate your help in mail to ppluzhni@bach.helios.nd.edu
aipdc@castle.ed.ac.uk (Paul Crowley) (05/27/91)
In article <9105261240.AA00552@techunix.technion.ac.il> merdd01@techunix.technion.ac.il (david degani) writes: >help You missed out a semicolon on line 1,135. Trust me. ____ \/ o\ Paul Crowley aipdc@castle.ed.ac.uk \ / /\__/ Part straight. Part gay. All queer. \/
herrmann@cony.gsf.de (Guenther Herrmann) (06/14/91)
help