hsgj@batcomputer.tn.cornell.edu (Dan Green) (11/10/87)
I have heard implications that there may be a new version of the Amiga OS being worked on. In the off hopes that this is really true, and that changes have not yet been finalized, here are three suggestions for new features for the Intuition Library. I hope these are not construed as flames on the existing product, but instead as possible enhancements for a future product. 1) Make Iconify a standard window system gadget. Window iconifying, pioneered by DME and intuitionized by WordPerfect, is a very handy feature. Currently, you can do it yourself by building a gadget and putting it in the top border, and converting all GADGETUP events in it to SizeWindow calls. However this means you have to manage repainting your window. If this was a system gadget, when the window was in smart_refresh mode, Intuition would know not to throw out the border if the window was iconified to a smaller size. For example: The + and - define the window that the user Normal Iconified sees. In the Iconified picture, the S are +-----+ +-+SSSS chunks of smart_refresh memory that Intuition | | +-+SSSS would hold on to, so that when the window | | SSSSSSS was un-iconified (eg brought back to normal size) +-----+ SSSSSSS the program would not have to repaint the window. In this case, iconifying would be completely transparent to the application. A NEWSIZE idcmp would still have to be issued, but the application could ignore it if necessary. I don't think this would break any existing code, because no existing code sets the (hypothetical) WINDOWICONIFY flag, so no existing code would have such windows. New programs would benefit immensely, though. 2) Force CloseScreen() to close any windows open in its screen. This has a lot of potential applications. For example, say you are running VT100 in its own screen, and would like a clock on the screen. You would write a clock program that would open its window on the Top Screen being displayed. The clock would function until it got a CLOSEWINDOW event, in which case it would close its window and exit. Currently, if you did this but then the VT100 application closed the screen, clock would have a window with no bitmap memory and bad things would happen. If instead, CloseScreen() sent CLOSEWINDOW idcmp's to any open windows on its screen, and then waited until these windows all closed, then you could easily do these DA type things without fear of losing your bitmap. Again, this would break no existing code, as current applications all close their windows before closing their screen, anyways. 3) Have a DEPTH parameter for OpenWindow calls. This would break code, but bear with me... I have an application that opens a 4 bitplane interlaced screen. On this screen are 4 windows. One is a drawing window and needs the color. The other three, however, are just text windows and only need to be one bitplane (eg black/white) deep. I am using smart_refresh for all windows, which means that Intuition has to keep a lot of 4 bitplane memory allocated to buffer these overlapping windows. I would like to be able to specify that these windows are only using the top bitplane, and then Intuition would only keep 1 plane of memory allocated to buffer the windows, resulting in much less ram wasted. I realize I could use simple_refresh and do all the buffering myself, but that's really not as good, because if my program is busy "computing" and cannot look at the IDCMP stream, then I don't see that my window needs to be redrawn. If Intuition handles this then it is all transparent and looks nice. Smart_refresh windows are fantastic(!!!) but I'd like to set the depth to conserve memory. A couple of unrelated notes: o I remember a while ago someone mentioned that to find out if a given screen was in Interlace or not, they looked at the screen height, and if it was >200 then that implied interlace. Someone else responded that they better check for >256 in the case that their software was running on PAL systems. What I have been doing is checking: if (screen->ViewPort.Modes & LACE) screen_is_interlaced. o Likewise to find the number of colors a given screen will support, you can do: numcolors = (1 << screen->Bitmap.Depth) I am not sure if these two methods are the best way of doing these checks, but they seem to work... -- Dan Green -- ARPA: hsgj@tcgould.tn.cornell.edu UUCP: ihnp4!cornell!batcomputer!hsgj BITNET: hsgj@cornella
john13@garfield.UUCP (John Russell) (11/12/87)
In article <2873@batcomputer.tn.cornell.edu> hsgj@batcomputer.tn.cornell.edu (Dan Green) writes: > >2) Force CloseScreen() to close any windows open in its screen. Right on. Maybe in the far future, even a way to automatically move windows between screens - my terminal program's screen is closing, so it switches my clock and editor windows back onto the Workbench screen (all screens same dimension and depth of course) and sends them an IDCMP NEWSCREEN message (which they can safely ignore if they want to, or maybe ToFront or ToBack themselves). This assumes a system-sanctioned method of getting those extra windows there in the first place tho'. What about putting an option into programs to let you specify the screen name it should open the window on, and then not telling anyone about it until Intuition handled CloseScreen() correctly (1/2 :-) ? >3) Have a DEPTH parameter for OpenWindow calls. This would break >code, but bear with me... I have an application that opens a 4 bitplane >interlaced screen. On this screen are 4 windows. One is a drawing >window and needs the color. The other three, however, are just text >windows and only need to be one bitplane (eg black/white) deep. Have you thought of opening an interlaced deep screen from 0,0 to 640,300 and a mono (possibly noninterlaced) screen from 0,301 to 640,400? That's assuming you don't need to do major resizing and dragging. Otherwise I imagine the Layers library has these things... if not, what advantages does it offer over the window functions? John -- "Go to the rostrum and confess. We will tell you what to say." -- Tellinstin,st
hsgj@batcomputer.UUCP (11/13/87)
In article <4204@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: >>3) Have a DEPTH parameter for OpenWindow calls. This would break >>code, but bear with me... I have an application that opens a 4 bitplane >>interlaced screen. On this screen are 4 windows. One is a drawing >>window and needs the color. The other three, however, are just text >>windows and only need to be one bitplane (eg black/white) deep. > >Have you thought of opening an interlaced deep screen from 0,0 to 640,300 and a >mono (possibly noninterlaced) screen from 0,301 to 640,400? That's assuming >you don't need to do major resizing and dragging. Otherwise I imagine the >Layers library has these things... if not, what advantages does it offer over >the window functions? > >John This is a good idea, but for the application I have in mind one monochrome window is a 'pallette' that is vertical. Now if I could have horizontal side by side screens then maybe your suggestion would work... I haven't looked at the layers library stuff because I'm not sure if using it and Intuition would be wise (eg arranging something by calling layers directly might screw up some internal structs in Intuition). This is just a hypothesis. Anyways, the advantage of having depth-settable windows is simply to conserve the off-screen smart-refresh area that Intuition maintains. Actually if Intuition uses FAST ram when buffering windows then conserving the memory is not that important. If it uses CHIP for that purpose, then buffering becomes very important -- Three of my windows consume 3/4 of the screen area each (they are overlapped). Now the screen is 640x400x4 = 128K. 3/4 of this is 96K, which means that Intuition is keeping at least 96 * 2 or 192K of refresh-buffered windows, while displaying 128K of screen consisting of the third and fourth window. That is a total of 320K for screen stuff alone. Now if those buffered windows were only 1 plane, they'd only take up 24K, and the total ram usage would be 24 * 2 + 128 = 176K. That is MUCH more reasonable then 320K. That is why I want a depth paraemeter on windows. PS - Before anyone construes this as flamage, let me assure you that I am not criticizing anything and am just stating a wish. The above- mentioned program has a switch so you can specify interlace or not and the number of planes; thus if you have a shortage of ram you just don't get a lot of colors or screen real estate. This prog, by the way, will be free as it is being done under educational auspices, but do not hold your breath. The superbowl will come and go before this sees the light of day... -- Dan Green -- ARPA: hsgj@tcgould.tn.cornell.edu UUCP: ihnp4!cornell!batcomputer!hsgj BITNET: hsgj@cornella
eric@hector.UUCP (Eric Lavitsky) (11/13/87)
Aye, this is a good idea. Sun is doing it on their newer machines. On an
8 bit frame buffer, they open up interactive text layers as one bit plane
deep. It would be nice if the Amiga layers system could be extended to
handle this. Then we'd get the benefit of faster text in our CLI windows
while being on a >1 bit plane screen rather than having to do it in a
seperate screen...
NEWCLI FROM file DEPTH n
can the blitter efficiently support this? I'd love to be able to open such
windows myself on my own custom screens...
Eric
ARPA: lavitsky@topaz.rutgers.edu "Lithium is no longer available
UUCP: ...{wherever!}ulysses!eric on credit..."
...{wherever!}rutgers!topaz!eric - from Buckaroo Banzai
SNAIL: 34 Maplehurst Ln, Piscataway, NJ 08854john13@garfield.UUCP (11/14/87)
-- In article <3162@ulysses.homer.nj.att.com> eric@hector (Eric Lavitsky) writes: >Aye, this is a good idea. But the copper cap'n, she canna take it much longer :-). [ speculating about 1-bitplane con: windows on multicolour screens ] > NEWCLI FROM file DEPTH n Hey, I'm still waiting for NEWCLI FROM file SCREEN screenname. But I wonder if the same way that jimm adds screen bitplanes in Dropshadow, you could lock some layers, free some bitmaps, adjust a depth paramater(?), make the screen again, and it would work just like that. Intuition seems to be remarkably intelligent about behaving sanely under whatever constraints you care to put it under; note that you can use MWB to put CLI windows on a 1-bitplane screen. Think I might just try that. John -- "The Amiga doesn't really multitask because... because... because when two programs try to write to the printer at the same time, it crashes!" -- who WAS that masked ST owner? (honest to God this is what he thinks)