Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!sun-barr!rutgers!cbmvax!peter From: peter@cbmvax.commodore.com (Peter Cherna) Newsgroups: comp.sys.amiga.programmer Subject: Re: Sharing layers.library with intuition Message-ID: <17398@cbmvax.commodore.com> Date: 11 Jan 91 17:33:15 GMT References: <1991Jan11.001055.2055@mintaka.lcs.mit.edu> Reply-To: peter@cbmvax.commodore.com (Peter Cherna) Organization: Commodore, West Chester, PA Lines: 82 In article <1991Jan11.001055.2055@mintaka.lcs.mit.edu> rjc@wookumz.ai.mit.edu (Ray Cromwell) writes: > > Hi. I've been doing some experimenting lately and started designing >an alternative 'window' system to intuition. I don't intend it >as a replacement, or even to distribute it, so please no debates. >(although it would be nice to have a few alternative GUI's on the >Amiga, e.g. Xwindows, Motif) > > Ok, so what is the proper way to 'share' a screen with intuition? You cannot perform direct layers operations in an Intuition screen, in general. Basically, you have two choices: 1. Create your own viewport (graphics.library equivalent of the visible-slice of a screen), and do your own layers operations on that. 2. Create borderless Intuition windows, and use Intuition and graphics rendering in those. You can use RMBTRAP to catch menu buttons. I will warn you that you are headed into very tricky territory, and you'll want to be very careful about deadlocks and race conditions. > I was thinking of some neat looks for my 'simulated' windows once >I get past this hurdle, such as having the MenuBar/Menus pull down >from the window title(inside the window) instead of at the top of the screen. >(the menus would also support huge menu bars by making them superbitmaps, and >having a scrollup/down menuitem as standard. I also want to hack in some >window effects like masked windows, windows that explode/collaspe [like Mac], >and wipes/effects.) Some of those effects have been hacked on top of Intuition, with varying degrees of success, robustness, and compatibility. >For Commodore gurus, why is LayersBase only a LONG(APTR) I assumed it >would atleast keep a simple structure, say, to store its internal >damage lists? Why does graphics/intuition keep pointers laying around >to other library bases? (such as in IntuitionBase) Shouldn't >the system libraries abide the same rules we do, and open other >libraries to obtain their bases instead of performing inter-library >rom-jumping? (ok, i'm making a huge assumption here since I haven't >disassembled them.) LayersBase (and parts or all of other library bases) are private. This means we don't tell you what's in there, because we don't want you reading or writing those fields. We have good reasons in mind, such as compatibility and reliability. All Amiga ROM libraries call OpenLibrary() to get library pointers. They do this during their "init" time. The result of OpenLibrary() is then stashed in the library base for reference. That's very legal. Remember, for a library, its library base corresponds well to the global data area of a regular program. So IntuitionBase keeping a pointer to LayersBase is the same as you defining a global called LayersBase. >Finally 2 more question. (cause I'm curious) >1)How do graphics library/icon library implement icons/bobs? >Are they layers, or are they implemented seperately? Read up about the gels subsystem of graphics in the RKMs. Implementing gels on a shared screen like the Workbench is tricky, and there is some special deadlock avoidance code to help. >2) In a rough estimate, how many lines of source code does >the entire OS take up? (1.3/2.0) and what compiler/system >is it developed on? Unix, Vax, or Amiga? Here's a rough figure for Intuition, which is about 1/5 of the 2.0 ROM: 55000 lines of code, about 1.4 megabytes worth. Since Intuition is mostly C, it has proportionately less lines of code than other modules that are in assembler. No small potatoes... Most of the modules in the ROM are compiled or can be assembled on the Amiga. A few of the big ones are compiled on a Sun. Porting modules is a lot of work and tends to introduce bugs, so there is some advantage to keeping modules Sun-built. Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"