riddle@emory.uucp (Glenn T. Barry) (10/12/87)
I have a question regarding that "other" hypertext program, Guide. Actually the question is probably more generic, but my application is to Guide. When Guide opens, the default window does not fill the entire screen. If I adjust the window using either the grow boxes in the bottom right or the zoom box in the upper right, and then save the document, the change in window size is not saved and when openned the next time, the document will once again need to be adjusted. My question is: can I use Resedit to change the parameters for the dimensions of the default window so that when my guide document is openned the window will automatically fill the entire screen? I am preparing a document for use by students on campus, some of whom may be Mac novices, and I would like to maximize the space available for use while minimizing the dependence on the student to resize the window. Any help would be appreciated. I have used Resedit but am not an expert so please give specific instructions. Thanks. -- Larry Riddle | gatech!emory!riddle USENET Emory University | riddle@emory CSNET,BITNET Dept of Math and CS | riddle.emory@csnet-relay ARPANET Atlanta, Ga 30322 | (404) 727-7922 AT@T
gardner@prls.UUCP (Robert Gardner) (10/12/87)
In article <2272@emory.uucp> riddle@emory.uucp (Glenn T. Barry) writes: >When Guide opens, the default window does not fill the entire screen. Many early programs used WIND resources to specify new window locations and sizes, but unfortunately they aren't general-purpose enough to use effectively with variable-sized monitors. It seems a new resource-type or redefinition of WIND would be helpful (which GetNewWindow() would use). For instance, if the window coordinates are negative they could be interpreted as offsets from the screenbits.bounds. Then, creating a window that fills the screen with a few pixels of space would use (0,0,-2,-2) or something. Most programs these days (I suspect) calculate window sizes on the fly from screenbits.bounds or stuff the old size/location in the document somewhere. It seems that a nice, general-purpose, user-modifiable technique is needed now that screen sizes are not fixed. Robert Gardner
oster@dewey.soe.berkeley.edu (David Phillip Oster) (10/13/87)
Apple feels that it is important to let the user choose the settings
for new windows.
If you look at the section of Apple's User Interface Guidlines where
MultiFinder is discussed, you will see that Apple now expects
applications programs to store, with each document, where it was on
the screen. That way, when the user opens the document again, it will
show up on the same place on the screen. (The application has to check
that window size and position are reasonable for the current display,
since the user may have created the file on a machine with a big
display and moved it to a machine with a small display.) The current
version of the Finder does this.
In my programs, I give each of my documents a resource: Type=WIND
ID=128, and update it each time the user saves the file. I'd like to
see this convention catch on. When the user creates a new document,
its position comes from a resource Type=WIND ID=128 in the program
itself. This resource gets updated whenever the user does a Close or
Save. When the user wants a new window, this window gets used for its
initial position. (If there already is a window on that spot, I adjust
the position of the new window slightly before showing it to the
user.)
My newer programs are compatible with networks and multiple users.
They keep special files, called Stationery Pads (as per the tech note
on AppleShare compatiblity) that hold settings like the initial
position, font, size, and even contents of documents. If you open a
stationery pad, you get an new, untitled copy of the pad that is a
document. (like tearing the top sheet off a real, paper pad.) To
change the setting of a stationery pad, you must explicitly set up a
document the way you want and do a "Save As Stationery Pad."
All of this is detailed in my article: How to Write a TEXT editor,
part II, Data File compatibility, coming soon.
--- David Phillip Oster --A Sun 3/60 makes a poor Macintosh II.
Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edugardner@prls.UUCP (Robert Gardner) (10/14/87)
In article <21256@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >Apple feels that it is important to let the user choose the settings >for new windows. > >In my programs, I give each of my documents a resource: Type=WIND >ID=128, and update it each time the user saves the file. There are a few situations I can think of where this doesn't seem practical. One is programs that don't create documents (terminal emulators and games, for instance). Another is programs that have non-document windows, such as tool palettes. Should these be moved every time a window is open or activated? Finally, suppose a user edits a document in one section of the screen, quits, comes back later and starts editing a different document in a different section of the screen and wishes to open the original document for reference. Should it really come up in the old position? Or should it come up near the current document? Similarly, what if you open a document created by a different application that uses the WIND convention given here? Where should it come up? Maybe these complaints are easy to solve, but it's fun to throw mud in the water! Robert Gardner