This is Inclusion-Idea in view mode; [Up]
Date: Sun 11-Nov-1991 23:26:00 From: S3LMGEB@SAE.TOWSON.EDU (Eric Bennett) Subject: Inclusion Idea What do y'all think about loadable modules for objects which you could include inside another type of document? It would be neat to be able to drag MyFavorite.diagram into a paper I was working on, have it put in properly and then be able to adjust the diagram as though it were in the Diagram! program. Or if I am doing my paper in (something Edit-like) and want to put in one formula in TeX I could create a small .tex file and then drop it into my document where it would be properly imaged and positioned. Or better yet to create a blank one and enter the TeXt in an inspector panel. It could work like this: An Inclusions directory in {~/Library, /LocalLibrary,/NextLibrary} would contain file wrappers like TeX.inclusion. That would contain a .o file defining nessessary object types, a .nib file with an inspector for this type of inclusion, and a data file relating one or more file extensions with this inclusion as well as RTF keywords and pasteboard types. The application using InclusionTexts would contain a manager object which would scan these data files on startup and make nessessary calls. When a file/object of the correct type was pasted/dropped into the Text, it would contact that manager. The manager would load the object file and inspector .nib if they hadn't been already, then message an object thus created, passing it the data. It would then provide a view to be placed in the text. The loaded code could either handle the dropped object itself or start/contact the appropriate app to handle the mechanics. Inclusions for NeXT default types would have simple cropping/scaling options and would probably be handled completely by the loaded code. The object could still be opened in its default app using a button on the inspector. The Inclusion Inspector's inspector selector (oh my!) would have a New Inclusion position. That inspector would allow you to create a blank of any inclusion type; You could then either enter data directly into the view or enter it through the inspector (which might be several inspectors for a given inclusion type). Some inclusion ideas: standard types like .tiff, .eps, .ps, .sound would have inspectors with display options, cropping, scaling, and plaintext editor for {e}ps. TeX types .tex and .dvi for putting in occasional formulas (could support matching TeX font to current font in use) .rtf, .rtfd for putting in snippets of text in another color/style, boxes for tables or quotes. Inclusions designed to contain other inclusions and have boarder/spacing options Perhaps a sufficiently complex text subclass could allow in-line inclusions for non-standard text (like Arabic) An inclusion for files with video/animation information A .nib inclusion which (by some magic) lets you put controls into your documents to make changes or run shell commands. What do you think? My grasp of NextStep is loose at best but it seems to me like a workable inter-application way to provide hypertext-like features. Fire away! Eric Eric Bennett Nifty quote s3lmgeb@sae.towson.edu under construction...
Date: Sun 14-Nov-1991 19:38:31 From: ksbrain@zeus.UWaterloo.ca (Kevin Brain) Subject: Re: Inclusion Idea In article <DCA3ADAD4040926F@TOE.TOWSON.EDU> S3LMGEB@SAE.TOWSON.EDU (Eric Bennett) writes: > > What do y'all think about loadable modules for objects which you could > include inside another type of document? I agree it is a great idea. I've been considering this for weeks now, and I've arrived at roughly the same general outline: loadable modules, located in specific directories, that an application would load in order to create the image of an included document. The advantage is that I could drop an 'encapsulated' Diagram! or Create document into the middle of my WriteNow document, and still be able to edit it as a Diagram! or Create document later. It is not important for the loadable module to be able to edit the imbedded document. It just has to image it. Mainly, it would respond to the message image in the given view. (It should also respond to 'hilight', to perhaps redraw with a shaded background when selected.) If the user double-clicked within the imbedded view, the imbedded document would be opened in the appropriate NeXTstep app, just as double-clicking the document's icon in the Workspace Manager would do. There's really little point in putting a lot of editing functionality in 'Inclusion Inspectors'. We have multi-tasking - let's just use the full application! The goal is to be able to drag and drop anything into anything else, without ever losing any editability. Do this right, and we'll soon be able to drag gifs and animations into the next Writenow. Providing this functionality would require a class that dynamically loads the 'imaging' modules, and some conventions stating where the modules are located and what methods the modules must respond to. Also, 'encapsulated' document formats should contain a certain minimum file header, giving information such as the bounding box. Ideally, NeXT would specify these conventions, but this isn't absolutely essential. The NeXT developer community and a few forward-thinking companies could establish a standard and start providing this functionality even before 3.0 is available. Ideally, NeXT could (perhaps in 3.0??) completely eliminate the necessity of using modules. Through inter-application messaging, Create, for example, could image (and edit-in-place) the imbedded document while it is still in WriteNow. This could be implemented in a way very similar to the way 'Services' are currently implemented. Applications could publish to the system what 'Imaging' it is able to do. Then, other applications could message the application to have it image an imbedded document. The image could be passed back to the requesting application as a bitmap or eps image. I'd love to hear people's ideas about this. I think this is one of the most promising ways for NeXT to keep their edge in ease-of-use. Kevin Brain Department of Systems Design, University of Waterloo
Date: Sun 13-Nov-1991 15:00:51 From: ddj@zardoz.club.cc.cmu.edu (Doug DeJulio) Subject: Re: Inclusion Idea > What do y'all think about loadable modules for objects which you > could include inside another type of document? It would be neat to be > able to drag MyFavorite.diagram into a paper I was working on, have it > put in properly and then be able to adjust the diagram as though it > were in the Diagram! program. This would be great. The Andrew Tool Kit already does this sort of thing under X11 (and wm too), and has been doing it for years. That's probably the main reason that I feel that ATK has better multimedia support than the NeXT does. You can drop a spreadsheet view or a graph or an animated sequence into a mail message, and instead of a little icon you get the whole object, fully displayed and "live". An early demo message included a picture of a piano that would let you press its keys to produce tones on an IBM-RT speaker. On top of all this, the file format is a byte stream rather than a directory. It doesn't appear that there are technical barriers to doing this. We've just got to talk NeXT into it.
Date: Sun 20-Nov-1991 03:51:52 From: davidfe@microsoft.com (wax cantalope) Subject: Re: Inclusion Idea In article <1991Nov14.193831.6472@watserv1.waterloo.edu> ksbrain@zeus.UWaterloo.ca (Kevin Brain) writes: >In article <DCA3ADAD4040926F@TOE.TOWSON.EDU> S3LMGEB@SAE.TOWSON.EDU (Eric >Bennett) writes: >> >> What do y'all think about loadable modules for objects which you could >> include inside another type of document? > > >I agree it is a great idea. I've been considering this for weeks now, and I've >arrived at roughly the same general outline: loadable modules, located in >specific directories, that an application would load in order to create the >image of an included document. The advantage is that I could drop an >'encapsulated' Diagram! or Create document into the middle of my WriteNow >document, and still be able to edit it as a Diagram! or Create document later. >It is not important for the loadable module to be able to edit the imbedded >document. It just has to image it. > > ... > >I'd love to hear people's ideas about this. I think this is one of the most >promising ways for NeXT to keep their edge in ease-of-use. I'm afraid this is something that NeXT can't be the first to offer for a general platform. The Object Linking and Embedding design being pushed by Microsoft for Windows and Mac is already out the door in the latest version of the apps. Even the low-end stuff. It operates pretty much how you've described it except for dragging the original object into the hosting document. A simple double-click calls up the object serving program for any editing. This isn't a case of "Ha Ha - we beat you to it" either as I've just purchased a NeXT for doing stuff at home so I have no real preference for Windows. I'm just letting you know what already exists on other platforms (and future versions will have vast improvements) so you can move on to the next useful design. david...
Date: Sun 23-Nov-1991 07:02:19 From: slugg@mouthers.ogi.edu Subject: Re: Inclusion Idea In article <1991Nov20.035152.15820@microsoft.com> davidfe@microsoft.com (wax cantalope) writes: > I'm afraid this is something that NeXT can't be the first to offer for a > general platform. The Object Linking and Embedding design being pushed by > Microsoft for Windows and Mac is already out the door in the latest version > of the apps. Even the low-end stuff. It operates pretty much how you've > described it except for dragging the original object into the hosting > document. A simple double-click calls up the object serving program for any > editing. You can drag-drop too, but an icon representing the object is used to display what you dropped (this is called a 'Package' in Microsoft OLE parlance).
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.