SLMYQ@USU.BITNET (04/17/88)
I have yet another idea for 1.x. Actually two.
First, provide a public message port that receives WBStartup messages. Its
support code would just free the message, unload the SegList, etc. just like
Workbench does. That way programs which start their own Workbench processes
could just point the ReplyPort to this and don't worry about when the program
exits. It would have to be in Kickstart, not Workbench, because if Workbench
isn't loaded and someone starts a Workbench-type process...
Second, this one may be a not-so-easy one, but here it is. Supply an extra
window type, called SUPERTEXT. It would have a buffer like SuperBitMap
which holds text instead of graphics. Internally it would be a simple
refresh layer which would automatically be refreshed by Intuition. The
buffer's size would be big enough to hold an entire screen of the selected
font. Oh, and make sure it's nice and fast. It would be nice for text-only
windows like the CLI or editors. The style might change (underline etc) -
the character's style might be stored in an extra "style byte" in the
buffer. The font can't change though.
Bryan Ford (SLMYQ@USU.BITNET)peter@sugar.UUCP (Peter da Silva) (04/18/88)
In article <8804170428.AA23977@jade.berkeley.edu>, SLMYQ@USU.BITNET writes: > First, provide a public message port that receives WBStartup messages. Its > support code would just free the message, unload the SegList, etc. just like > Workbench does. That way programs which start their own Workbench processes > could just point the ReplyPort to this and don't worry about when the program > exits. This doesn't need to wait for 1.x. I'm going to have a port like this in my "Launch" utility... real soon now. > It would have to be in Kickstart, not Workbench, because if Workbench > isn't loaded and someone starts a Workbench-type process... How about having it started in startup-sequence? If a program doesn't find its port when it wants to start up a workbench process it can just do an "Execute("l:launch-daemon", 0, 0);" first. > Second, this one may be a not-so-easy one, but here it is. Supply an extra > window type, called SUPERTEXT... A good idea. I was thinking of doing this for my console device replacement, but I've gotten disillusioned about that. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
mp1u+@andrew.cmu.edu (Michael Portuesi) (04/18/88)
Excerpts from: 17-Apr-88 Suggestions SLMYQ@USU.BITNET (1186) > Second, this one may be a not-so-easy one, but here it is. Supply an extra > window type, called SUPERTEXT. It would have a buffer like SuperBitMap > which holds text instead of graphics. Internally it would be a simple > refresh layer which would automatically be refreshed by Intuition. The > buffer's size would be big enough to hold an entire screen of the selected > font. Oh, and make sure it's nice and fast. It would be nice for text-only > windows like the CLI or editors. The style might change (underline etc) - > the character's style might be stored in an extra "style byte" in the > buffer. The font can't change though. > > Bryan Ford (SLMYQ@USU.BITNET) Perhaps the "correct" thing to do is to provide a text management package similar to what is available in the Macintosh. I fail to see why fonts should not be allowed to change style or size. Basically all you're asking for is a souped-up Console window. Even though Console windows are nice in that they allow lots of plain, vanilla programs to be ported to the Amiga, they are a bane in that programmers are tempted to use them in lieu of the powerful features supported by Intuition (hence why many Amiga word processors cannot support multiple font sizes and styles). Providing simple, easy-to-use support for these features would invite more programmers to use them and to "do the job right" with their applications. --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"
SLMYQ@USU.BITNET (04/19/88)
>> Second, this one may be a not-so-easy one, but here it is. Supply an extra >> window type, called SUPERTEXT... > >Perhaps the "correct" thing to do is to provide a text management package >similar to what is available in the Macintosh. > >I fail to see why fonts should not be allowed to change style or size. >Basically all you're asking for is a souped-up Console window. Even though >Console windows are nice in that they allow lots of plain, vanilla programs to >be ported to the Amiga, they are a bane in that programmers are tempted to use >them in lieu of the powerful features supported by Intuition (hence why many >Amiga word processors cannot support multiple font sizes and styles). >Providing simple, easy-to-use support for these features would invite more >programmers to use them and to "do the job right" with their applications. I think you're missing the point. This window would be the same kind of thing as a SuperBitmap window, except the superbitmap would be a text buffer which is MUCH shorter than a bitmap the whole screen size. I find many programs, including the CLI, DME, and most text-oriented programs always use smart refresh windows, which takes up mucho mem. If they're going to just use the same font anyway, why not do it efficiently? AmigaBASIC does it that way, although it's rather slow. This would have another advantage over normal smart refresh windows. Since it's somewhat the same as SuperBitmap, when the user sizes the window smaller, and then makes it bigger again, all the text is still there, unlike smart refresh windows. Three good uses for this I see are the CLI, text editors ("plain" text files - no fonts anyway), and terminal emulators, especially those which operate on the Workbench screen. None of them ever change fonts, although they might change styles. Oh, I forgot to explain why you can't change fonts. It's the same reason you can't change pixel sizes in the same screen (without the copper). All the "cells" have to be the same size. I agree, a good set of text manipulation routines would be very nice, but that is something completely different. Bryan Ford (SLMYQ@USU.BITNET)
dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/20/88)
:as a SuperBitmap window, except the superbitmap would be a text buffer which :is MUCH shorter than a bitmap the whole screen size. I find many programs, :including the CLI, DME, and most text-oriented programs always use smart :refresh windows, which takes up mucho mem. If they're going to just use the :same font anyway, why not do it efficiently? AmigaBASIC does it that way, :although it's rather slow. This would have another advantage over normal A SMART_REFRESH window only takes up memory (compared to a SIMPLE_REFRESH window) when it is obscured by other windows. Most of us use SMART_REFRESH windows for the following reasons: -You can use ScrollRaster() with SMART. There are problems with SIMPLE. -SMART windows are much faster than SIMPLE windows when it comes to resizing/depthcontrol/moving them. -Since the program must refresh SIMPLE windows, if you've got a lot of SIMPLE windows around things get *real* slow on said operations. -Handling REFRESH events is a bitch, and slow, and I have gotten used to instant response. In addition to all of that, I have a vested interest in defending DME, since I wrote it. If you are worried about memory use, simply iconify DME's window(s). As long as the window you are working on is completely visible, it takes no extra memory. -Matt