chris@goedel.uucp (Chris White) (02/17/89)
Has anyone thought about how to implement a facility for capturing
the state of windows in NeWS? Having a command like "toolplaces" in SunView
is convenient because you don't have to reshape your windows each time you
start up.
The other half of this problem is not having a ".suntools" type
file for NeWS -- this has been discussed before, but the problem is that
there is no uniform way of telling a program that you want the main window
to have a particular size and location.
One solution might be to have each Unix process which has a NeWS window
respond to a set of queries from outside the process. There must be a way
to cycle though each of your running NeWS programs to make this work though.
It would probably be inefficient for each process to listen for these
relatively uncommon events -- perhaps we could use signals. But then what
do we do about pure NeWS programs (no C code). These are completely inside
of the NeWS server, so how could they respond to outside process queries?
A more sophisticated functionality would be to have state saved has on the
Macintosh. Much more information is preserved acrossed sessions than in
Sunview. Could this be implemented by rewriting or subclassing LiteWindow?
An even more sophisticated system would allow the copying of windows (and
their program state if application-supported). Imagine being able to copy
a terminal emulator and have the CShell state also duplicated...In fact,
the entire desktop could be thought of as a MacDraw-type program,
allowing duplication and grouping of anything on the screen.
Okay, I'm rambling on. I guess what I'm saying is I'd like to see some
discussion of these window system design ideas.
Chris White
Software Engineer
Applied Logic Systemsfrode@m2cs.uu.no (Frode Odegard) (02/28/89)
This should be possible. In fact, provided one has a decent library used by the applications on the client side, one should be able to save and restore THE WHOLE DESKTOP like in Smalltalk. GNU Emacs has some nice code that it uses for loading faster. It will load the ELISP code into its data segment and then produce a core dump of itself. Then this core dump is converted into a new executable which has all the ELISP stuff preloaded (minus user ELISP files, of course, I'm only talking about the basic editor code here). If one could also save info about the call chain, a RESUME would be in reach. We have the problem with limbo descriptors of course, but that's what the "decent library" is all about.... I expect the library would also have to talk to NeWS to save/restore what ever the client had going over there. If the client only goes trough The Nice Library for doing graphics (farewell, extensibility ;->), the graphics wouldn't be a problem either. Comments from Real Unix Hackers? [I'm just a Modulean, I write my own operating systems ;-)] - Frode -- | Frode L. Odegard |"The world is coming to an end! Repent and| | Modula-2 CASE Systems |rm /bin/cc" | | NORWAY (EUROPE) | | | Email: frode@m2cs.uu.no | |
throopw@agarn.dg.com (Wayne A. Throop) (03/02/89)
> frode@m2cs.uu.no (Frode Odegard) > GNU Emacs has some nice code that it uses for loading faster. It > will load the ELISP code into its data segment and then produce a core > dump of itself. Then this core dump is converted into a new executable > which has all the ELISP stuff preloaded [...] > Comments from Real Unix Hackers? [I'm just a Modulean, I write my > own operating systems ;-)] Well, clearly Frode is using some meaning of "nice" with which I am totally unfamiliar. This one little hack contributes somewhere between two-thirds and three-quarters of the difficulty in porting GNU Emacs. If instead of producing a core dump, it write exactly the data elements needed in the form of a C module to compile and link in with a "generation II" editor executable, the code would be more portable, more maintainable, and in all ways better than it is now. IMHO. Hmpf. -- The LISP programmer knows the value of everything but the cost of nothing. --- Alan J. Perlis Wayne Throop <the-known-world>!mcnc!rti!xyzzy!throopw