| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
I have a question on window stacking order.
My customer has one big drawing window in one application shell
and a dialog box as a child of second toplevel shell.
The dialog box is the control panel which contains nice things like
color selection, line style, fill style, text size ...
Whenever he has selected an action he can go to the drawing screen
and draw the object.
Unfortunately, the moment he gives one click in the drawing window
the window pops up in front covering the dialog box. In decwindows
normal behaviour. Now, he would want that the dialog box shell remained
in front of the drawing shell so that the user does not always have to look
for the dialog box whenever he wanted to select a new action ( a dialog
box probably hidden by some other windows from concurrent applications).
Is there any possibity to implement this using some window configuration
parameters - or communication with the window manager ?
The user himself should be allowed to move the dialog shell to another
part of the screen (but still keeping it in front of the drawing shell).
I was thinking of putting override_redirect to the dialog box shell
window, but wouldn't that prevent users even from dragging the window
to another screen location ?
Thanks,
Dominique
By the way, they definitely don't want to put the dialog box options
into the main window, because they really need the entire screen
for editing graphics (they don't want to put scrolling in the
graphics window - yet).
PS. This note was posted in decwindows_programming (at least I tried
but I cannot access the conference - moved ?)
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1559.1 | "sticky" | SDSVAX::SWEENEY | I was focused when focus wasnt cool | Fri Oct 13 1989 10:11 | 13 |
The DECwindows window manager has a not-well documented feature to
support the interaction where "click to focus" doesn't automatically
raise the window.
This feature is enabled from the keyboard by shift/MB1 in the "lower
window" icon in the title bar. The resource is DwtNsticky (DwtAppl.h)
and XtNsticky (vendor.h) and it applies to the vendor structure in the
shell widget. This of course, applies to the shell with the drawing
and not the dialog box.
And by the way, advocates of Open Look really tout the fact that it's
far easier to "pin-up" their menus and dialog boxes.
| |||||
| 1559.2 | hope it works with decwrite | 1SHOT::HOULE | Steve, NM is the future! | Wed Oct 18 1989 17:27 | 4 |
I sure hope this works for decwrite. With small screens it has been annoying to use the change pop-ups (e.g. text attributes) If this isn't in the decwrite documentation it should be! | |||||
| 1559.3 | Why wouldn't it? | EPIK::BUEHLER | The status quo is what you make of it. | Fri Oct 20 1989 11:28 | 22 |
>I sure hope this works for decwrite. With small screens it has been annoying to
>use the change pop-ups (e.g. text attributes) If this isn't in the decwrite
>documentation it should be!
If you're referring to the 'sticky windows' feature, then, yes, it
works for DECwrite. I don't know of a way to disable the feature
except by eliminating the push-to-back icon under software control.
And I'd suggest that you not pin up the dialog boxes, but rather pin up
the document and leave the dialogs alone. This works quite well,
allowing you to move between the overlapping document and dialog
without the annoying popping and repainting that constantly happens if
you don't pin anything up.
It shouldn't be in the DECwrite documentation because it's just another
standard feature of DECwindows. Another window system may not have
this feature.
Please refer to the product as DECwrite, not decwrite. Thanks.
John
| |||||