pds@quintus.UUCP (Peter Schachte) (12/22/87)
> Has anyone else noticed that the Workbench is a rudimentary Object-Oriented > system? > Anyone know if this curious parallel to Object-Orientedness was deliberate? > Is the Workbench modeled after some other, more complete O-O environment? Sure. The workbench, of course, is a rip-off of the Mac user interface. This was a rip-off of the Xerox Star (now called viewpoint) document processing system. Star, I believe, grew out of work done at Xerox PARC, and was impelmented in some sort of object-oriented language. Smalltalk also came out of Xerox PARC. I'm not sure how closely related the development of Smalltalk and Star were. > > There is a possible, kludgy way of expanding the capabilities of the existing > Workbench. Please tell me if I'm way off base, but wouldn't it be possible > to create a new device that looks for all the world like a disk, but does > something else? Disks automatically get icons on the Workbench and get > messages when other icons are "fed into" its icon or drawer. I was thinking > of using this fact to kludge-up a "printer" icon for the Workbench. It > would be a device that looks like a disk and so therefore gets an icon on > the 'Bench, but whenever it received "Write" i/o requests, it would forward > them to the printer device (or PAR or SER). That, in fact, is how you printed a document in the Star environment: you just dragged the document icon onto the printer icon. Worked great. The problem with what you suggest is that different word processors have different file format conventions, mostly not pure ascii. So just sending the contents of the file, byte by byte, to the printer device wouldn't be at all right. What you really want it to do is to "send a print message" to the file. This might mean firing up a printing program specific to that file that would do all the right things. So, my (first) question to the people who know what they're doing: would it be possible to put into an icon (I guess in the .info file) the name of a print program, and then have a simple, general way to "send a message" to the file, firing up that program? Given this, could you write some code that would put up an icon on the screen (like the disk icons, in that it wouldn't be in any drawer) that could tell when an icon had been dragged onto it, and have this "send" the right "message"? And is it possible to write a "tool" (I think that's the right word) that can tell when an icon is dragged onto it? I'm not worried about inheritance for now. A related issue: is it possible to have a different set of menus and menu items for different file icons? Then, as long as you could do the first thing I asked for above, you could at least have a "print" menu item appear in some menu when you had selected a printable file. This would give a great degree of user extendability to the workbench. I don't use the workbench, I usually use shell (thanks, guys, it's great), but I'd rather use a mouse-and-icons style of interaction if it were better supported. It would have to be pretty good to beat a good keyboard-based shell, but I think such a beast is possible. I wish I had one! I hope these aren't stupid questions. I haven't looked terribly closely at the workbench. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
peter@sugar.UUCP (Peter da Silva) (12/29/87)
In article ... pds@quintus.UUCP (Peter Schachte) writes: > The problem with what you suggest is that different word > processors have different file format conventions, mostly not pure > ascii... > What you really want it to do > is to "send a print message" to the file. This might mean firing up a > printing program specific to that file that would do all the right > things. What you really want to do is write a tool called "print" that looks up "PRINTER" in the ToolTypes array and fires off the named program when you shift-double-click it. Then we want to beat C= into implementing the drop-an-icon-onto-a-tool method of firing off programs. THEN you want to get C= to allow you to snapshot icons onto the workbench, so they're automatically there when you boot up. THEN get them to allow you to drag windows off-screen so you can actually get to the workbench when you need to. > I hope these aren't stupid questions. I haven't looked terribly > closely at the workbench. The workbench is about 25% of a great tool. The more people ask stupid questions (not saying yours are, or that mine aren't) the more likely C= is to fix that sucker up. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
pds@quintus.UUCP (Peter Schachte) (12/30/87)
> What you really want to do is write a tool called "print" that looks up > "PRINTER" in the ToolTypes array and fires off the named program when > you shift-double-click it. Then we want to beat C= into implementing the > drop-an-icon-onto-a-tool method of firing off programs. Sounds great! Another thing that would be really useful is to have a COPY tool that is invoked when someone drags an icon into a drawer. This would be necessary for someone to bundle files into groups with a single icon. E.g., a text file and a backup version of it. > THEN you want to get C= to allow you to snapshot icons onto the workbench, so > they're automatically there when you boot up. THEN get them to allow you to > drag windows off-screen so you can actually get to the workbench when you need > to. Snapshotting icons onto the screen would be really useful. I'm not so sure about (partially) off-screen windows. It's not something I've ever wanted. If it's put in, it should be as an option. What I would find more useful is if icons were more like windows, in that windows could be pushed behind them. Could be confusing if you pushed a directory window behind an icon, but, as an option, I would find it very helpful. Being able to iconify any window would also be helpful, probably best of all. I'm still (eagerly) waiting for this hack to show up on comp.sources.amiga. > The workbench is about 25% of a great tool. The more people ask stupid questions > (not saying yours are, or that mine aren't) the more likely C= is to fix that > sucker up. Amen. I hope 1.3 (or at least 1.4) fixes some of these shortcomings. I know it's traditional for programmers to eschew icons and such for development purposes, but I think many might be converted if the other 75% of the workbench were there. It works as it is, but it really needs LOTS more generality. -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
shf@well.UUCP (Stuart H. Ferguson) (01/02/88)
Article 12299 of comp.sys.amiga: |> Has anyone else noticed that the Workbench is a rudimentary Object-Oriented |> system? | |Sure. The workbench, of course, is a rip-off of the Mac user interface. |This was a rip-off of the Xerox Star (now called viewpoint) document |processing system. Star, I believe, grew out of work done at Xerox ... Ah, Xerox, of course. Should have known. I only noticed the object orientedness of the Workbench after I started reading "SMALLTALK-80 The Language and its Implementation," by the folks at Xerox PARC. |> [ I talk about possibly using a "fakedisk.device" to get more power into |> the existing Workbench. A "printer" icon, for example ...] | ...What you really want it to do |is to "send a print message" to the file. This might mean firing up a |printing program specific to that file that would do all the right |things. |> What you really want to do is write a tool called "print" that looks up |> "PRINTER" in the ToolTypes array and fires off the named program when |> you shift-double-click it. Then we want to beat C= into implementing the |> drop-an-icon-onto-a-tool method of firing off programs. | |Sounds great! Another thing that would be really useful is to have a |COPY tool that is invoked when someone drags an icon into a drawer. |This would be necessary for someone to bundle files into groups with a |single icon. E.g., a text file and a backup version of it. Hmmm. The problem with the "ToolTypes" method is having a standard way of doing "interprocess communication." Certainly every word processor has a "Print"-like menu item or items, but how many have a way to receive a "print" MESSAGE? The only path I can see is to adopt/establish a standard (with all that implies) method for interprocess communication. One message passing standard is the device IO request blocks, but this would mean having everything look like a device, even word processors, which seems a little strange. AREXX supposedly provided a method for interprocess communication that might be standardized - anyone have more info on that? The best but hardest choice is to make the Workbench the full object oriented system it was meant to be. Since this model requires that the objects interact by passing messages, and the objects are implemented as tasks, some standard way of intertask message passing would be a given. Needless to say, I think this is the way to go. |A related issue: is it possible to have a different set of menus and |menu items for different file icons? Then, as long as you could do the |first thing I asked for above, you could at least have a "print" menu |item appear in some menu when you had selected a printable file. This |would give a great degree of user extendability to the workbench. Yes, this would be great. This would be following the object oriented path to its logical end, since the icon-specific menu items are just the set of "messages" that that object can respond to. The Workbench does this already, to a limited extent by disabling (ghosting) innappropriate menu items for the currently selected icon. The "Empty Trash" item, for example, is only enabled while a "Garbage"-type icon is selected. It would then be possible to have user-programmed icons hanging around on the Workbench that could get their own menu selections on the Workbench screen when selected. My hypothetical "Printer" icon could be controlled directly from the Workbench by making it an object that responds to some messages that are added to the Workbench menus, such as "Stop," "Start," "Abort," "Flush Buffer," or whatever control messages would be useful for a print spooler. |> The workbench is about 25% of a great tool.... | |I know it's traditional for programmers to eschew icons and such for |development purposes, but I think many might be converted if the other |75% of the workbench were there. It works as it is, but it really |needs LOTS more generality. I really think it's closer than that. *Most* of the design is geared towards an object oriented approach already - just a little eyes-open redesign would be needed to put in the necessary hooks for user expandability. Once that's there, the Amiga programming community will be able to fill in any blanks. They've (or *You've* :-) done it already with the other expandable parts of the system with such gems as ConMan, rrd's, shells, and Ewhac-hacks :-). Stuart Ferguson Action by HAVOC
peter@sugar.UUCP (Peter da Silva) (01/03/88)
Firstly, I'm about 80% ready to ship a beta version of a new directory utility. This one is called "Browser", and emulates the workbench, except that ALL files are displayed (no, no icons are used). I'm still tryiung to decide whether to give it away or sell it. Any input? In article ... pds@quintus.UUCP (Peter Schachte) writes: > > THEN you want to get C= to allow you to snapshot icons onto the workbench, so > > they're automatically there when you boot up. THEN get them to allow you to > > drag windows off-screen so you can actually get to the workbench when you need > > to. > Snapshotting icons onto the screen would be really useful. I'm not so > sure about (partially) off-screen windows. It's not something I've > ever wanted. If it's put in, it should be as an option. Of course it'd be an option. If you never dragged your windows off the screen, you'd never know it was there. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
peter@sugar.UUCP (Peter da Silva) (01/05/88)
In article <4883@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes: > |> What you really want to do is write a tool called "print" that looks up > |> "PRINTER" in the ToolTypes array and fires off the named program when > |> you shift-double-click it. Then we want to beat C= into implementing the > |> drop-an-icon-onto-a-tool method of firing off programs. > > Hmmm. The problem with the "ToolTypes" method is having a standard way of > doing "interprocess communication." Certainly every word processor has a > "Print"-like menu item or items, but how many have a way to receive a > "print" MESSAGE? You're getting a little complex, here. The basic object that the workbench operates on is NOT the message. The basic object is the file (executable or otherwise). PRINTER will have to do a GetDiskObject() of each of its WBArgs, look up the ToolTypes array for a PRINTER tool with FindToolType, and execute the command found there. You'd also have to write a couple more utilities. (1) a program that sets the PRINTER up in the ToolTypes array. (2) a couple of programs to do certain default sorts of printing. For example, DPAINT files are ILBMs. So you'd have a PRINTILBM program. Then you'd put this in the ToolTypes array: PRINTER=PrintILBM If this takes off, you can convince EA and cohorts to start providing a set of small programs with all their programs: PRINTER=Dpaint:Printer VIEWER=Dpaint:Viewer EDITOR=Dpaint:dPaint As an added bonus it's MUCH quicker to load a specialised tool than to load dPaint and send a PRINT;filename message. ALSO, my browser program (a version of Workbench for programmers who don't care much about icons) will allow you to set up a TOOLS menu item, based on a file called s:Browser.Tools that looks like: View ASCII;Workbench;sys:System/More View ILBM;CLI;c:uShow $* So when you select "View ASCII" from the TOOLS menu, it'll pass the files you selected to sys:System/More in its WBArgs. When you select "View ILBM", it'll pass them to uShow in its CLI command line. When you get your printer tool set up, you can then add: Print;Workbench;sys:PRINTER -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
pds@quintus.UUCP (Peter Schachte) (01/06/88)
In article <1342@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > Firstly, I'm about 80% ready to ship a beta version of a new directory > utility. This one is called "Browser", and emulates the workbench, except > that ALL files are displayed (no, no icons are used). I'm still tryiung > to decide whether to give it away or sell it. Any input? Well of course we'd RATHER get it for free.... In what way does it emulate the workbench? To what extent will it let you work without a CLI? > In article ... pds@quintus.UUCP (Peter Schachte) writes: > > Snapshotting icons onto the screen would be really useful. I'm not so > > sure about (partially) off-screen windows. It's not something I've > > ever wanted. If it's put in, it should be as an option. > > Of course it'd be an option. If you never dragged your windows off the screen, > you'd never know it was there. No, no. That doesn't make it an option. It would be pretty easy to inadvertently drag a window off screen. There should be a global option (set in startup-sequence or, better, preferences) that would enable/disable partially offscreen windows. When I'm moving windows, I often slam them around counting on intuition to keep them on screen. Allowing offscreen windows would mean I couldn't do that anymore. If you're talking about an add-on program like conman or some such, fine. No problem. But if it's built into workbench (as was requested when this discussion started), it should be an option. And the default should probably be off (for backward compatibility). -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
shf@well.UUCP (Stuart H. Ferguson) (01/11/88)
In article <something> Peter da Silva writes: |In article <4883@well.UUCP>, shf@well.UUCP (Stuart H. Ferguson) writes: |> |> What you really want to do is write a tool called "print" that looks up |> |> "PRINTER" in the ToolTypes array and fires off the named program when |> |> you shift-double-click it. Then we want to beat C= into implementing the |> |> drop-an-icon-onto-a-tool method of firing off programs. |> |> Hmmm. The problem with the "ToolTypes" method is having a standard way of |> doing "interprocess communication." Certainly every word processor has a |> "Print"-like menu item or items, but how many have a way to receive a |> "print" MESSAGE? | |You're getting a little complex, here. | |The basic object that the workbench operates on is NOT the message. The basic |object is the file (executable or otherwise). Granted. |If this takes off, you can convince EA and cohorts to start providing a set |of small programs with all their programs: | | PRINTER=Dpaint:Printer | VIEWER=Dpaint:Viewer | EDITOR=Dpaint:dPaint Yeah, given the existing Workbench, this seems like the only way to implement this sort of thing. Each object -- in this case a DiskObject -- knows how to do something to itself (i.e. print, view or edit itself) by being provided with a pointer to its "method." The "method" varies depending on the type of DiskObject. Sounds like there might be some overhead in redundant code in alot of the "small programs." A super-wiz-bang desktop publishing program, for example, would have a lot of modules that would have to be included in each of the viewer, printer and editor programs. The editor would have to load files, format them, print them (would you really want to start a separate program just to print your file?) and display them (it's WYSIWYG, isn't it? :-). The printer would have to load, format and print files. The viewer would have to load, format and display files. |As an added bonus it's MUCH quicker to load a specialised tool than to load |dPaint and send a PRINT;filename message.... Not to mention hunting for your key disk :-). Although having several programs that do simalar things could take up a lot of disk space. (It's the old trade-off, size vs. speed). I admit, though, the difference between dPaint and uShow makes the small extra disk space pay off mightily in speed. Also, for data files without the advantage of an IFF standard, the versions of the different tools could be a source of dificulties. Suppose you had version 3 of the editor but version 2 of the viewer? | ... ALSO, my browser program (a version |of Workbench for programmers who don't care much about icons) will allow you |to set up a TOOLS menu item ... Sounds like a good idea. I would suggest you make it possible to provide paths for searching for tools rather than having to specify "c:uShow". |When you get your printer tool set up, you can then add: | Print;Workbench;sys:PRINTER This is the kind of simple expandability I would like for the standard Workbench! I like your thinking. If only the Workbench designers had been thinking that way. |-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)
4526P@NAVPGS.BITNET ("LT Scott A. Norton, USN") (01/15/88)
> >Sounds like there might be some overhead in redundant code in alot of the >"small programs." A super-wiz-bang desktop publishing program, for >example, would have a lot of modules that would have to be included in each >of the viewer, printer and editor programs. The editor would have to load >files, format them, print them (would you really want to start a separate >program just to print your file?) and display them (it's WYSIWYG, isn't >it? :-). The printer would have to load, format and print files. The >viewer would have to load, format and display files. Two observations: First, this is how WordPerfect's printer works. It runs as a separate task, invoked either by the main WP or by the user. It is an excellent approach, and doesn't seem to incur too much overhead from the possibly duplicated code. Second, and more hopefully, the Amiga shared libraries avoid the problem of redundant modules. Just put all the common modules of the "Big City Desktop Publishing Plus!" program in the BCDTPP.library. Except for task overhead, which is small on the Amiga, the total memory usage will be almost the same if you fire up all the component modules compared to the original monolithic program. And if you only use one of the modules, you save. >-- > Stuart Ferguson (shf@well.UUCP) > Action by HAVOC (shf@Solar.Stanford.EDU) LT Scott A. Norton, USN Naval Postgraduate School Monterey, CA 93943-5018 4526P@NavPGS.BITNET 4526P@NPS.ARPA ( I think its on line now )