On 3/12/02 at 3:44 AM Marcel Kilgus wrote: > After the Hove show some of us went to a pub and discussed a bit about > the future of the QL. On the drive home I talked some more with Jochen > and in the end we decided to take the development of SMSQ/E into our > (well, probably mainly my) hands...
[Ideas] > WMAN still can't use the extended colours. Fortunately all WMAN routines > and data blocks related to colour use 16 bit wide values, the upper 8 > bits are just never used. Therefore I defined a new colour format: > > %00000000cccccccc handle colour exactly like before > %00000001pppppppp use lower byte as palette index > %00000010pppppppp use lower byte as system palette index > %00000011gggggggg use lower byte as gray scale value > %1rrrrrgggggbbbbb 15 bit RGB value > > The system palette is an idea found on other operating systems to give > applications a common look. The system palette is an excellent idea, the minor question is gow to define it initially (defauklt values). I have my doubts about the gray scale value palette. Perhaps a fixed color definition could be a good idea instead, and if so, use something like the Aurora color set. It's simple and all systems capable of 256 colors can reproduce it. That way programs can have a unified 'shorthand' color table when needed. Further ideas: I have no problem with the GUI because it does not necesairly have anything to do with WMAN. I do agree that the look is way behind the times, and the biggest problem here is again documentation (as in lack of) that would point to a way to change it. OTOH, a relatively limited number of concurrent colors used in the GUI has it's advantages. I can think of MANY things that would be on my 'most wanted list' way before a nice multicolour 3D GUI. 'Under' the GUI there has to be solid substance. The matter of window saves using the deepest color definition regardless of how many colors are actually used is one of the more serious, and probably very complex issues. IMHO the MODE command still needs to have effect in high color screen mode. Actually, ideally, the 'screen' moda nd the 'application' mode should be separate, especially now that there is hardware with screen modes capable of concurrently showing all lesser modes. As discussed in aprevious mail, a program using 4 colors (even if they are from a palette of 65536) using 16BPP save areas is quite absurd, especially as the VAST majority of programs really don't need more than a couple simultaneous colors. I believe that the solution to this problem also includes the solution to programs continuing to produce screen output even when burried. Slave blocks are a big problem. As far as I can understand, they really need to stay in some form - with a limited number as the linear table search is what really slows things down so imensely. Also, the real problem in limiting the slave blocks is that the table start and length are effectively 'hardcoded' because they are derived from pointers to other structures. I wonder if an alternative way of limiting the number of slave blocks would be to attack the basic area movement rules. If basic couldbe moved along with the top of the common heap and not necesairly only when it changes size. Although, I have a feeling that this will expose more 'hardwired' pointers :-( Nasta
