jnh@ece-csc.UUCP (Joseph Nathan Hall) (05/06/88)
Hi there. I'm sure many of you are aware that X-for-VMS is now in beta testing, and is scheduled to be released later this year. I have to admit, though, that I'm a little surprised by the dearth of comments re what I think is a significant (if not exciting) addition to the X fold ... -- v v sssss|| joseph hall || 201-1D Hampton Lee Court v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 v sss || the opinions expressed herein are not necessarily those of my -----------|| employer, north carolina state university . . . . . . . . . . .
carson@tron.UUCP (Dana Carson) (03/04/89)
Please respond to the address below or post as this looks like it might be of general interest. If mail to that address fails respond to me. ------------ We, like many other organizations, have a home-brewed accounting system which asks the interactive user for an account (charge) number at login, validates it and then stuffs the process header & control region. We have a slight problem under DECwindows... Once the user logs in thru the Username/Passowrd dialog box, we have written an application which pops up and gets the account number. If it's valid, we're all set. If not, we have a problem: We'd normally logout the user at this point if it were a terminal or terminal window. If we log out this "user", we have logged out the session manager -- not a good idea! Since it takes privs (CMKRNL among others) to restart the manager (and most of our users don't have CMKRNL - imagine that!) we need a way to allow them (since by this time the process is their context, not SYSTEM) to restart it. Initially we thought we could get away with writing an INSTALLed program which would run the DECW$STARTLOGIN.EXE process via a LIB$DO_COMMAND - doesn't work since the privs are gone by the time the CLI gets control - likewise LIB$RUN_PROGRAM. It's not obvious whether some hack using LIB$FIND_SYMBOL will accomplish what we need -- Has anybody come up with a way around this problem?? This is the command procedure we started with in SYS$MANAGER:DECW$SYLOGIN: $ set nocontrol_y $ on ERROR then continue $ set noon $ set proc/name=DECWSYLOGIN ! so that the user's process name will start off $ ! ! as the username $ run ACC$:DECW_ACCLOGIN $ if $STATUS then goto GOOD_ACCOUNT ! If bad account then $ stop DECW$WINMGR ! Must stop window manager $ run ACC$:RUN_DECW$STARTLOGIN ! Start login box process $ logout/brief ! Logout this process $ GOOD_ACCOUNT: $ set proc/name=DECWSESSIONMGR $ set working_set/quota=200 $ set on $ set nocontrol_y Thanks for any suggestions, -- Al Sorrell Westinghouse VAX Support Group Baltimore, Md. Internet address: VSG%Plaza.dnet%tron.UUCP@umbc3.UMBC.EDU
clyne@redcloud.ucar.edu (John Clyne) (03/04/89)
Does anyone know how to change the DECwindows environment so the keyboard focus follows the mouse. I.e. you don't have to click in the window to type in it. Thanks in advance - jc John Clyne (clyne@bierstadt.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 %%% %%%
rr@csuna.cs.uh.edu (Ravindran Ramachandran) (08/11/89)
In article <JV.89Aug10154556@mhres.mh.nl> jv@mh.nl (Johan Vromans) writes: >In article <2703@decuac.DEC.COM> avolio@decuac.dec.com (Frederick M. Avolio) writes: > >| You can set a font set size by putting this in either >| /usr/lib/X11/app-defaults/DXterm (for system-wide default) or in your >| own .Xdefaults. >| >| DXterm*main.terminal.fontSetSeletion: 0 >| >| which will give you the larger fonts. > >From my 'dxterm(1X)' documentation: > >| fontSetSelection: Specifies which font is set to use. Specify zero for >| little and 1 for big. The default is 1. > >Which is right? > > Johan I don't know why the manuals are different, but having the value as suggested by Fredrick seems to work. As the poster of the original request for having a larger font on the system, let my re-clarify my question. I had found out how to get the terminal window to have a larger font, by using the customize window utilities. However, the problem was when I started up other windows, like emacs, the postscript previewer, and the session manager, the fonts seemed to be too small for anything but a microscope. Having used a SUN before, with its defaults editor (wherein you can specify what fonts, etc.), the method by which you have to specify things for the DECwindows characteristics seemed a major pain in the ... head. I guess those are the drawbacks of using a new and better protocol? Anyway, I had got a response from Mr. Ted (Mellon?) on how to get to customize the other fonts. No system-wide default, but a .Xdefaults entry. The only problem with this was when trying to customize using the session manager's options. With a normal font, the popup menu for changing the color (say, background) would fit within the display. However, with other fonts that window slided out of reach of the mouse, and could not be moved either. As the 'save', 'dismiss' buttons were now out of reach, the session manager basically went on hold. Solution: Kill the dxsession on node :0. Basically, commit hara-kiri. If you still want the stuff I'll tell you how to change the font. But please input a standard disclaimer for myself and for the person who told me how to do this. -- Ravi. ------------------------------------------------------------------------------- | Ravindran Ramachandran Internet : rr@cs.uh.edu | System Administrator : ramachandran@uh.edu | TCSUH, 617 SR1 CSNET : rr@houston.edu | University of Houston BITNET : coschmd@uhvax1.bitnet | 4800, Calhoun | Houston, TX - 77204. ------------------------------------------------------------------------------- Disclaimer : The opinions mentioned here are purely my own (most of the time); however, sometimes my opinions are not THAT pure.
avolio@decuac.dec.com (Frederick M. Avolio) (08/11/89)
I am right. The doc is wrong. AT least that is how it works on my workstation. Fred
jv@mh.nl (Johan Vromans) (08/11/89)
In article <2703@decuac.DEC.COM> avolio@decuac.dec.com (Frederick M. Avolio) writes: | You can set a font set size by putting this in either | /usr/lib/X11/app-defaults/DXterm (for system-wide default) or in your | own .Xdefaults. | | DXterm*main.terminal.fontSetSeletion: 0 | | which will give you the larger fonts. From my 'dxterm(1X)' documentation: | fontSetSelection: Specifies which font is set to use. Specify zero for | little and 1 for big. The default is 1. Which is right? Johan -- Johan Vromans jv@mh.nl via internet backbones Multihouse Automatisering bv uucp: ..!{mcvax,hp4nl}!mh.nl!jv Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62944/62500 ------------------------ "Arms are made for hugging" -------------------------
ccl@scampi.sc-scicon.COM (Charmaine Lee) (10/31/89)
Can someone tell me if it is true that DECWindows will support multiscreen in VMS version 5.3? If so, is the hardware supporting multiscreen? Charmaine Lee ccl@scampi.sc-scicon.com
ccl@scampistac-scicon.COM (Charmaine Lee) (10/31/89)
Can someone tell me if it is true that DECWindows will support multiscreen in VMS version 5.3? If so, is the hardware supporting multiscreen? Charmaine Lee ccl@scampistac-scicon.co
tp@mccall.com (Terry Poot) (10/19/90)
I'm starting to feel real stupid, because I'm sure what we want to do is doable, but after reading the docs, I don't know how. I'll try to keep this breif. (Apologies if my terminology is off, I'm new to this, and I'm not the programmer actually doing this, I'm helping him). We are trying to convert an application from VWS to DECwindows. We grabbed some sample code that comes with DECwindows, and have managed to do a pretty good job of making it work using Xlib (making it fast enough will be a chore, and comes later). We saved one feature of our application for last. The application used 2 windows, one the terminal emulator it was run from and one a graphics window. It toggled back and forth between these under program control. My thought was to use the toolkit. We would combine the application windows into one window, using widgets to implement the different functions. The command window widget appears to do exactly what we want in handling the terminal window. I figured we would use a window widget (since that is the only one that supports graphics) as our graphics window. Now the problem: the only callback in the window widget is an expose callback. This would be fine for a static graphic display, but this is an _interactive_ graphics application. The user can grab objects and move them, or select them and then by hitting various keyboard keys, he does various operations on them (for the curious, the application places pattern pieces on a printing plate). I have no idea how to accomplish this. When I was reading the introductory docs, I assumed that when it said the window widget supports graphics, that meant I would have full access to pointer, button, and keyboard events, as well as things like leave and enter window and expose. But the only one it seems to give me is expose. Now I know I could get the window id from the widget and draw on it with Xlib. I don't know if that is supported (i.e. would I somehow subvert the toolkit by doing it). What I can't see any way of doing is getting events that occur in the graphics window. I've read the guide to writing DECwindows applications (skipping the sections on widgets irrelevant to our application), and looked up the window widget in the toolkit routines reference manual. What am I missing? Please don't _just_ tell me what book to buy (though such hints are also appreciated), this is a small town, and I don't have time to order it and wait for it to arrive before solving this problem). Bonus question (assuming the above problem is solvable): how do I manage which widget controls the keyboard? I'd like the command window to give the focus back to the graphics window any time the user hits return, and I'd also like the graphics window to be able to give the focus to the command window (though that is less essential). I don't want the user to have to click on the graphics window to move the focus, since that click would likely have meaning to our application (depending on where he did it). Thanks very much in advance for any help. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
murphy@ufp.dco.dec.com (Rick Murphy) (10/19/90)
In article <1990Oct18.180103@mccall.com>, tp@mccall.com (Terry Poot) writes: >We are trying to convert an application from VWS to DECwindows. ... >Now the problem: the only callback in the window widget is an expose callback. >This would be fine for a static graphic display, but this is an _interactive_ >graphics application. The user can grab objects and move them, or select them >and then by hitting various keyboard keys, he does various operations on them >(for the curious, the application places pattern pieces on a printing plate). Use the translation mechanism. For example, compile a translation table containing <Btn1Down>: your-routine() and add the compiled translations to the window widget's argument list when you create it. You can use the translation mechanism to handle callbacks for mouse actions, keystrokes, and so forth. Should be adequate to handle whatever you need. >Bonus question (assuming the above problem is solvable): how do I manage which >widget controls the keyboard? XtCallAcceptFocus(widget-to-get-the-focus, ×tamp) -Rick -- Rick Murphy, WA1SPT/4 DEC Washington ULTRIX Resource Center Domain: murphy@ufp.dco.dec.com -or- murphy@ufp.enet.dec.com Bang: decwrl!ufp.enet!murphy Ding: (301) 306-2985 Disclaimer: This nonsense came from an AI program written in TECO. Ignore it.
asente@adobe.com (Paul Asente) (10/23/90)
In article <1990Oct18.180103@mccall.com> tp@mccall.com (Terry Poot) writes: >Now the problem: the only callback in the window widget is an expose callback. >This would be fine for a static graphic display, but this is an _interactive_ >graphics application. The user can grab objects and move them, or select them >and then by hitting various keyboard keys, he does various operations on them >(for the curious, the application places pattern pieces on a printing plate). > >I have no idea how to accomplish this. What you want to do is to install some additional translations on the window widget. These translations would be for the events you want to handle and would bind to actions that you provide in your application. >Please don't _just_ tell >me what book to buy (though such hints are also appreciated), this is a small >town, and I don't have time to order it and wait for it to arrive before solving >this problem). May I suggest "X Window System Toolkit" by me and Ralph Swick; Chapter 7 is devoted to the translation mechanism. You can order it through DEC Direct; the order number is EY-E757E-DP (I have no idea how quick this might be, but since you're in a small town it's probably the easiest way). XUI is more-or-less R3 based so you should pay attention to the R3 compatibility footnotes. >Bonus question (assuming the above problem is solvable): how do I manage which >widget controls the keyboard? The first think to try is XtCallAcceptFocus; pass it the widget you want to have the focus and the time stamp from the event that made you decide to take focus (hopefully this is available to you; in XUI there's no real good way to get the time stamp otherwise). However, the window widget might not be willing to take the focus, since it doesn't expect keyboard events normally. If this is the case, you can use XSetInputFocus on the window widget's window. -paul asente New address! asente@adobe.com ...decwrl!adobe!asente