siegel@endor.harvard.edu (Rich Siegel) (07/08/89)
I have been considering the issue of remembering state information about documents - in particular, text-only files that are edited by a text editor. I'd like to remember the state of a document, such as font, size, and tab settings; window position and size; scrollbar positions; selection range, and option settings. I could remember this state information as a resource in the document itself - this is an approach that MPW takes. The problem is that it's not conceptually "clean" to write information to a document without warning. Also, some people object to having resources in their text-only documents for reasons of their own - I don't care either way in particular. Another approach is to not remember the document state, but to instead remember the application state - which documents were open, and their states. This info could be written into a "Resume Foobar" document, in the same fashion that Excel and More II do. My objection to that is that the resume document is never where I want it to be; I rarely open the application folder, the system folder is an undesirable place to put such a document, and that leaves the desktop. Does anyone have any recommendations? I realize that this will probably come down to a matter of personal preference, but opinions are welcome. -Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel I classify myself as a real developer because my desk is hip-deep in assembly-language listings and I spend more than 50% of my time in TMON. ~~~~~~~~~~~~~~~
ksitze@nmsu.edu (360) (07/09/89)
In article: <siegel@endor.harvard.edu's message of 8 Jul 89 03:31:02 GMT> Rich is talking about where to save a resume document. This can be done in several ways (the program might implement all of them). 1) Allow a user to set a 'resume' folder that automatically gets all resume documents for any project being worked on. 2) If the resume folder has not been chosen or is missing (or is not implemented), check to see if the user opened a file to get in the program, and if so, default to the folder that file resides in. This way, whenever the user wants to 'play around' with that file again, the resume document is right there waiting. Of course, if the user sets a resume folder while working on the project, the resume document would go there instead of in the working file's folder. 3) If the user opened the application to enter the program, place the resume document in the applications folder. If the user doesn't have write access to the application folder (or to any of the other above mentioned folders), plop the resume document in the system folder or the desk top. (I'd definantly use this if #2 was implemented) You might want to provide an option box to the user so (s)he can configure things however they want, of course anything set here will override the above. -- +--------------------------------------------------------------------+ | From the Macintosh of: Kevin L. Sitze. This is ME: ksitze@NMSU.edu | +------------------------------------------------------+-------------+ | The difference between intelligence and stupidity is | Is this | | that intelligence has a limit. -- anonymous | better? | +------------------------------------------------------+-------------+
lippin@skippy.berkeley.edu (The Apathist) (07/11/89)
Recently siegel@endor.harvard.edu (Rich Siegel) wrote: > > I have been considering the issue of remembering state information >about documents - in particular, text-only files that are edited by a text >editor. I'd like to remember the state of a document, such as font, size, >and tab settings; window position and size; scrollbar positions; selection >range, and option settings. I'm in favor of using the resource fork for this information. Keeping a separate file for these things clutters up the file system, and the user would be forced to keep track of the second file as he rearranges, removes, or backs up the original document. On the other hand, I'm not in favor of the way some programs will write this information without my permission. I often will open documents just to read them, scoll down to the bottom, and leave them there. If the scroll position is saved, then the next time I want to read it, I have to scroll back to the top. And, even worse, the file modification date has been changed, just by my reading the file. I think the appropriate way to go is to ask before saving these changes, with an alert similar to, but worded diffreently from, the usual "save changes" alert. If the document itself is changed, just use the standard alert, and save all the information if the user says "yes." Of course, there are some (e.g., Leonard) who think this would be an inconvenience to the user. For them, and for people who just like their windows to come up in the standard place every time, I'm willing to have a program-wide option for saving state information, with values in {always,never,ask first}. On a slightly related issue, does it bother anyone else that most programs will put a preferences file in the system folder even when the user hasn't given any preferences? I think that if there's been no change from the default, there's no reason to make the file. --Tom Lippincott lippin@math.berkeley.edu "Man, you ain't got class, you got linoleum!" --Corky Siegel
tim@hoptoad.uucp (Tim Maroney) (07/11/89)
There's one sticky bit to all this state information mess that has yet to be mentioned. If you store this information for plain text files, you will have to fake the modification date. Consider this -- you open a C source file, scroll around in it, and close it. This causes the position resource to be updated in the file's resource fork, and the modification date becomes the present. Now when that file is checked against its object code, it looks as if it's out of date and needs to be recompiled. There's a similar problem on other kinds of files, but the misleading modifcation dates are only visible to a human. Still, just opening a file and moving around in it should *not* change the apparent modification date. This is easily solved on the Mac OS by setting the mod date field in a FileParam and calling PBSetFInfo. MPW does exactly this with its state resources. But this operation may not be implemented on files on a network file system on a non-Mac OS. For instance, only the super-user can change file dates on UNIX. The server may be set up to let you do this, or not. It would be better in some ways if there were an OS call that stashed this positional information with files on request without touching the mod date, but if you think about it, that also creates some problems on remote non-Mac file systems. I don't have a solution -- I think the positional resource makes a lot of sense for other reasons, a lot more sense than an application-specific state saver. I just thought these issues should be aired. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "Yet another piece of evidence that it's a Communist society which is being presented as good, but which we probably would not want to live in." -- Ken Arromdee on rec.arts.startrek, on the Federation's Red Menace