Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!osiris.cso.uiuc.edu!goldfain From: goldfain@osiris.cso.uiuc.edu Newsgroups: comp.lang.smalltalk Subject: Re: comp.lang.smalltalk Message-ID: <12100009@osiris.cso.uiuc.edu> Date: 31 May 88 05:23:00 GMT References: <26@eva.uu.se> Lines: 62 Nf-ID: #R:eva.uu.se:26:osiris.cso.uiuc.edu:12100009:000:3746 Nf-From: osiris.cso.uiuc.edu!goldfain May 31 00:23:00 1988 I too am interested in color smalltalk on the Mac II, but haven't any project I'm currently working on that will justify spending much time on it. I'm away from the Mac right now, but here is a summary of what I have noticed. 1) To get started, the fileIn Color-Example has some examples. There are primitives to do the 2 key things: (a) set the colors in the "palette" (although an immense number of distinct colors are evidently possible - far more than the human eye can distinguish - as is typical of color PCs these days, only a small number can simultaneously be plotted on the screen, through the use of a color table. On my Mac II, I can only have a table of 256 entries.) (b) plot a "color form" on the display, where each such form has "bitsperpixel" bits at each location specifying which color table entry to use at that dot. (See class ColorDevice.) 2) Now if you want to create a multi-colored Browser View, for example, you have to replace everything in that code that creates or modifies a Form, to instead create a color form. (As a primitive step you can hack on Forms like they do in the examples mentioned above. More elegant is to create a parallel class ColorForm and teach it how to do all the things that Forms can do. Or just some of the things, to keep the task within reason.) Finally, you will need to have all code that plots a Form to instead make the primitive call to plot a ColorForm. There is less of this than one might think - here is where the modularity of the system design can shine. 3) Also, one needs some code to run at the outset that insures the color table is the way you like it when you start up Smalltalk, or after you've done something else, your pretty sky blue Browser label may have turned a sickly puce! 4) After all of that is working, you can finally add modifications to the Browser MVC triad that turn a label green, or the scroll bar to three colors, or whatever. But keep in mind that this whole thing will likely run a bit slower and will definitely consume more memory (8 times as much with a 256-color palette) as the black and white image. So you may not want all that power everywhere. CAVEAT: This implementation programme is my own concept of how to go about this. I am only a "junior Smalltalk hacker", and have only looked around the color classes for a few hours. So there might be a much better way. All I have done is step 3 and a beginning of step 1. One nice application for all of this on the Mac would be to have a "yellow button region" (visible in yellow) on all CodeViews, that responds to unmodified mouseclicks by popping up the yellow button menu. That is the only one of the three that is really inconvenient on a Mac II with its one-button mouse. I would think a band on the right edge of the view would be a nice place for it. I can post my code to do step 3, and what I have for step 1, if anybody is interested. If anyone does some more of the above, or has any other color Smalltalk code they're proud of, I'll be happy to beta-test it for you. (:-) That is to say, I'd love it if somebody else did this for me! Mark Goldfain arpa: goldfain@osiris.cso.uiuc.edu US Mail: Mark Goldfain (A lowly student at)--> Department of Computer Science University of Illinois at U-C 1304 West Springfield Avenue Urbana, Illinois 61801