Colour Picker

(Of course the Red in the Colour Picker isn’t &FF00, it’s &DD00, but that’s another matter.)

An RGB hexadecimal triplet, backwards because it’s

Backwards would be BGR…

And then one comes to specify colours in web pages and it’s all the other way around (logical R then G then B). ;-)

Oh, wait, isn’t there some form of CSS that uses a single hex digit for each colour?
[edit: found it https://www.quackit.com/css/color/values/css_hex_color_notation_3_digits.cfm]

some form of CSS that uses a single hex digit for each colour

Yup, giving you 512 colours instead of the 16 million from BBGGRRxx (whether you write it big- or little-endian…)

Backwards would be BGR…

Indeed. Hence &FF00 being Red, not Green 8~)

Clarity… my excuse is that (a) this isn’t a Technical Manual, and (b) it’s ten years since I was a tech auth… 8~) …but the substance of what we’re on about is the same…

In the app I’m working on at the moment I use a &F0F0F000 mask so that colours picked using the percentages don’t have to be spot on, which is effectively the same thing as that 512 colour CSS thing.

I can now reveal the particular reason I’d like a Colour Picker with a few (not too many!) new colours: Version 2.00 of !XP1ReDraw, ready today, would benefit enormously from it. See http://clive.semmens.org.uk/RISCOS/index.php?XP1ReDraw

I would like to see a universal colour picker that supports the various colour depths. Maybe with a little bit of customization thrown in to suit the way you work. This would mean a standard setup for new users and not something different in paint, draw and any other app that wants to be different.

Another feature which would be nice to have in the ColourPicker would be the ability to enter #RRGGBB notation as used in CSS and also to see what the #RRGGBB form of a colour is. It’s a pain converting from percentages of RGB.

Been looking at the PRMs on the subject of the Colour Picker. Before I start writing my own…one piece of information I need that I’ve not spotted yet: I presume the Colour Picker SWIs are vectored? If they are, can I intercept them like I can intercept (some, originally not all, but is that still the case?) others? If I can, I think I can write a colour picker, that will sit like a little app on the icon bar, from which it could be switched on and off (returning control to the Colour Picker module when off) or quitted. It would open a window very like the existing colour picker when !Draw, !Paint or whatever app requested one.

This would be enormously useful in combination with !Draw and my !XP1ReDraw, and possibly with other apps too. If I do it, I’ll take on board some of the other suggestions on this thread. Particularly Matthew’s one just above this! (Except that RISCOS uses, as Rick keeps pointing out, BBGGRR00 not RRGGBB…bigendian…littlendian…)

Hmm. The Colour Picker SWIs don’t appear to be vectored. At least, if they are, I’ve not spotted the documentation of it. I presume it would be a smaller job for someone with the necessary knowledge & skills to insert vectors into the Colour Picker SWIs, than to edit the Colour Picker in the way suggested. It would also be less disruptive for anyone who didn’t want the changes I want, and more flexible for anyone who did want my (or any other) changes.

What about using Druck’s !ARMalyser and disassemble the ‘C’ module.
Then run it through ObjAsm – and add your mods there.
If you can assemble ARM 26bit – then 32bit is not much different – except you use the ARM code MSR cpsr_cxsf,#flag_Number to set the flags.

ie You can use MSR cpsr_f,#&10000000 ;v %1<<28

note the interrupt flags are in a different place 26/32bit

What about using Druck’s !ARMalyser and disassemble the ‘C’ module. Then run it through ObjAsm – and add your mods there.

We’re talking about upgrades to a component of the OS, here, not some lost application with no source code.

If you can assemble ARM 26bit – then 32bit is not much different […] the interrupt flags are in a different place 26/32bit

Fuxache – I wrote the book about the differences. I know better than most (apart from people who actually do it every day) what’s involved. I’m not scared of assembly language at all. But as Steve says, this a component of the OS, not a lost app with no source code. The source is in C though, which is not in my area of expertise.

“Adding my mods” to uncommented assembly language produced by disassembling the module would be a damn sight harder than rewriting the entire thing in Assembly language – whereas adding my mods to nicely documented C would be a reasonable thing to do, and far less work. If I was a C programmer.

I for one am in favor of a rewrite in assembly, it would get rid of some C code in the OS, always a good thing in my book.

Two reasons against, so far as I’m concerned: (1) It would be a lot more work than modifying the C, and (2) I don’t agree that getting rid of C code in the OS would be a good thing. Updating C for a new CPU is a matter of recompiling; updating assembly is more work.

See RISC OS 3 PRM5a-555 through PRM5a-578

That’s what I’ve been looking at, of course. But I wouldn’t think of writing a complete replacement for the existing colour picker – just unplug it and put mine in when I wanted to use it with !Draw, and then unplug mine and reinitialized the existing one. I’d only implement the parts !Draw actually uses, and only the RGB model at that.

Fuxache – I wrote the book about the differences.

fx: mic drop

I for one am in favor of a rewrite in assembly,

Yes, you for one as a party of one. The war between raw assembler and some sort of ‘language’ was fought in the ‘80s, lost in the ’90s, and now assembler is only really used where there’s no better choice.

As for rewriting it in assembler, be my guest…

Star Commands:
*ModeList

Actually, that’s *ModelList (two ’L’s).

You’re asking for a list of colour models, not modes.

Since you said you are not very good with svn the documentation for everything is here:

CVS, not SVN.

Plus, while he may not be an expert at finding stuff in CVS (neither am I, I tend to look in my local source copy t find stuff and then know where it is in the CVS…), I’m quite sure he can click a link, like this one that is a link to the same document.

Looking through the documentation, I don’t see why a “remember some sort of past colours” or “have a list of named colours” cannot be added completely transparently to the application. The Colour Picker gives the user a way of choosing a colour. How it does so is of no relevance to the callee, only that after a period of time has passed (user interaction), it returns some sort of code representing the chosen colour.
For all the app cares, ColourPicker is actually an app that fetches an image from a webcam in Toronto, averages the pixels in the area of the image that is the sky, and returns that colour.

I also note, as is not even remotely surprising in RISC OS, a complete lack of anything resembling calibration. ;-)

(assembly good, C cast to the past, for me and some others).

I’m going to call you on that. Please name those people who would prefer to throw away C and revert to doing everything in assembly.

Indeed, let me go further and ask you to please name those people who prefer assembly after several breaking changes of ARM processor instruction behaviour and support in recent times (meaning varying degrees of work for an assembler programmer and, frankly, practically nothing except a recompile for a C programmer).
I mean, it’s not as if we’re paid by the hour around here…

Are you going to provide yours for download so that others can use it?

If I make one, of course I’ll provide it for download. I provide all my stuff for download if it’s remotely presentable. But it’s pretty unlikely I will write a colour picker, now I’ve looked at the nature of the job. If someone else feels like doing it I’ll be a very happy man.

Looking through the documentation, I don’t see why a “remember some sort of past colours” or “have a list of named colours” cannot be added completely transparently to the application.

That’d be fine if it was my own application I wanted to add it to. But it’s not: I want to add it to !Draw.

There are other languages other than just assembly and C. Do you think that C is the only High Level Language?
There are two people in this thread that do not like C, both of which prefer BASIC V over any other for most things. I mentioned assembly as that is the offer he made.

In the context of writing components for the operating system, yes. Your choice is pretty much assembler or C. Even the bits in BASIC are using BASIC as an assembler.

Remember, I’m not talking “writing any sort of software”, I’m talking very specifically about replacing a part of the operating system…

Many have cast C away in favor of other languages

Indeed, and most of those languages are not available on RISC OS and none of them are supported as something OS components can be created with.

And you already have two examples of people who prefer High Level Languages that are not C.

True, but one does not create modules in BASIC. Again, I was referring specifically to writing replacements for parts of the operating system. C is old, many people deride it for various reasons (some justified, some less so), at any rate there are better options. But not for writing parts of RISC OS – FFS, we don’t even have a sane C++ option in that respect.

You will notice that I recommended the alternative of writing the module in BASIC V and compiling with ABC, which can be done

Partially. BASIC does not have multiple entry points, so I believe an ABC module can either provide SWIs or provide *commands. I’m not aware of it being able to do both, unless there’s something I’m missing in the available documentation (the most recent of which basically advises against using ABC for modules!).

Then why are you using C and not gpc Pascal or BASIC V?

Oh my…

• Because both are useless for OS components?
• Because BASIC is slow as it is interpreted.
• Because the ABC compiler is not only far less smart than Norcroft, it’s also decades out of date with respect to basic RISC OS features (it doesn’t even understand GCOL r,g,b yet, and that was introduced with the RiscPC).
• Because I bloody hate Pascal.
• Because I know C.

Pick any or all of the above.

That is not what I said, as explained earlier in this post.

Please focus – this discussion is not regarding “what’s the best language” or “what’s easiest for writing stuff in”, it is very specifically talking about options for writing or rewriting a part of the operating system. In this respect, to make something that behaves like the existing incarnation, your only sensible options are C or assembler. You will note that the entire operating system is written using one or other of those two options.

So if you still believe, in the specific context of writing operating system level code that “(assembly good, C cast to the past, for me and some others)”, then I will ask you again to name the others who would prefer to replace the C in RISC OS with assembler. You will find most of us (a proper huge majority, not a brexit majority) think exactly the opposite. Because time and history and experience have amply demonstrated the difficulties of maintaining large amounts of code written in assembler.

I have never done callback callers in BASIC though it should be doable.

BASIC does not lend itself to that sort of thing. I did start to write a list of reasons why, but instead I’ll leave that “as an exercise for the reader”.

maybe more because debuging a binary compiled from C is more of a headach than one from assembly

Really? Well, I suppose it is if you put up with the eccentricities of DDT.

My preferred method is just to construct a string and toss it at DADebug.

Look, I’ll even give you the code.

At program start, we look to see if DADebug exists. If it is, we define DADWriteC to be a pointer to a function (the one in DADebug), and set “debugokay” to TRUE to flag that debugging is available.

void debug(char *msg, ...)
{
   static char debugmsg[256] = ""; // static so always available
   va_list argptr;
   int     cnt;
   int     len;

   if ( !debugokay )
      return;

   if (strlen(msg) > 255)
      return; // too long!

   va_start(argptr, msg);
   len = vsnprintf(debugmsg, 255, msg, argptr);
   // should probably check len != 0 so
   // we don't have a useless cnt here...
   for (cnt = 0; cnt < len; cnt++)
   {
      if (debugmsg[cnt] == '\n')
         DADWriteC('\r'); // Every LF needs a CR prefix

      DADWriteC(debugmsg[cnt]);
   }
   va_end(argptr);

   return;
}

And then, wherever I need some debugging info output…

  debug("MyFunc: this = %d, that = %d, theother = %d\n", this, that, theother);

I dread to think what sort of equivalents would be necessary in assembler. Please feel free to post a routine that does the same things with the same degree of flexibility and isn’t twenty pages long. I’ll refer you to _swix as a nice example of something simple getting complicated when expressed in assembler.

Maybe a nicer more modern high level language would allow me to get stuff done even quicker. Don’t think I’m advocating C in preference to everything else. I’m simply advocating it in preference to using assembler. I can get stuff done. I can concentrate on the program. I don’t need to be bogged down by the minutae… oh hell, now I’m repeating stuff I’ve already said…

To add a follow-up:

Please feel free to post a routine that does the same things with the same degree of flexibility and isn’t twenty pages long. I’ll refer you to _swix as a nice example of something simple getting complicated when expressed in assembler.

I have no doubt that _swix written in C or my debug function won’t be every bit as clunky when disassembled, or quite likely even worse. The difference here is that I’m not looking at the assembler, I’m working with and maintaining readable higher level code, not low level assembler. Indeed, the only times I should need to delve into assembler is for debugging tricky problems (like zero page access if it isn’t obvious where/why/how) and for making veneers for SWI calls that don’t already have friendly function incarnations.

Maybe you don’t like, understand, or care for the debug() function I posted above. It is, at least, more readable (and maintainable) than this:

00008F1C : debu : 75626564 : STRVCB  R6,[R2,#-1380]!
00008F20 : g... : 00000067 : ANDEQ   R0,R0,R7,RRX
00008F24 : ...ÿ : FF000008 : ; func: debug
00008F28 : .À á : E1A0C00D : MOV     R12,R13
00008F2C : ..-é : E92D000F : STMDB   R13!,{R0-R3}
00008F30 : pØ-é : E92DD870 : STMDB   R13!,{R4-R6,R11,R12,R14,PC}
00008F34 : .°Lâ : E24CB014 : SUB     R11,R12,#&14       ; =20
00008F38 : AÏMâ : E24DCF41 : SUB     R12,R13,#&0104     ; =260
00008F3C : ..\á : E15C000A : CMP     R12,R10
00008F40 : ŒF.K : 4B00469A : BLMI    &0001A9B0                              ; call: CLib
00008F44 : AßMâ : E24DDF41 : SUB     R13,R13,#&0104     ; =260
00008F48 : ..™â : E28D0004 : ADD     R0,R13,#4
00008F4C : .. ã : E3A01000 : MOV     R1,#0
00008F50 : .  ã : E3A02000 : MOV     R2,#0
00008F54 : .0 ã : E3A03000 : MOV     R3,#0
00008F58 : .@ ã : E3A04000 : MOV     R4,#0
00008F5C : .P ã : E3A05000 : MOV     R5,#0
00008F60 : .` ã : E3A06000 : MOV     R6,#0
00008F64 : .à ã : E3A0E000 : MOV     R14,#0
00008F68 : .À ã : E3A0C009 : MOV     R12,#9
00008F6C : ~@ è : E8A0407E : STMIA   R0!,{R1-R6,R14}
00008F70 : .À\â : E25CC001 : SUBS    R12,R12,#1
00008F74 : üÿÿ. : 1AFFFFFC : BNE     &00008F6C
00008F78 : üm.å : E51F6DFC : LDR     R6,&00008184
00008F7C : ..ی : E5801000 : STR     R1,[R0,#0]
00008F80 : ..„å : E5960000 : LDR     R0,[R6,#0]
00008F84 : ..Pã : E3500000 : CMP     R0,#0
00008F88 : .... : 0A00001A : BEQ     &00008FF8
00008F8C : ..ό : E59B0004 : LDR     R0,[R11,#4]
00008F90 : ºF.ë : EB0046BA : BL      &0001AA80                              ; call: CLib
00008F94 : ÿ.Pã : E35000FF : CMP     R0,#&FF            ; ="ÿ"
00008F98 : ...⇓ : 8A000016 : BHI     &00008FF8
00008F9C : ..⇑â : E28B1008 : ADD     R1,R11,#8
00008FA0 : ..™å : E58D1000 : STR     R1,[R13,#0]
00008FA4 : .0 á : E1A0300D : MOV     R3,R13
00008FA8 : ..™â : E28D0004 : ADD     R0,R13,#4
00008FAC : ÿ. ã : E3A010FF : MOV     R1,#&FF            ; ="ÿ"
00008FB0 : . ό : E59B2004 : LDR     R2,[R11,#4]
00008FB4 : .H.ë : EB00480A : BL      &0001AFE4
00008FB8 : .P á : E1A05000 : MOV     R5,R0
00008FBC : ..Pã : E3500000 : CMP     R0,#0
00008FC0 : ...Ú : DA00000C : BLE     &00008FF8
00008FC4 : ..™â : E28D0004 : ADD     R0,R13,#4
00008FC8 : . Ðç : E7D02004 : LDRB    R2,[R0,R4]
00008FCC : ..Rã : E352000A : CMP     R2,#&0A            ; =10
00008FD0 : .. . : 03A0000D : MOVEQ   R0,#&0D            ; =13
00008FD4 : .à . : 01A0E00F : MOVEQ   R14,PC
00008FD8 : .ð„. : 0596F004 : LDREQ   PC,[R6,#4]
00008FDC : ..™â : E28D0004 : ADD     R0,R13,#4
00008FE0 : ..Ðç : E7D00004 : LDRB    R0,[R0,R4]
00008FE4 : .à á : E1A0E00F : MOV     R14,PC
00008FE8 : .ð„å : E596F004 : LDR     PC,[R6,#4]
00008FEC : .@✘â : E2844001 : ADD     R4,R4,#1
00008FF0 : ..Tá : E1540005 : CMP     R4,R5
00008FF4 : òÿÿº : BAFFFFF2 : BLT     &00008FC4
00008FF8 : p¨.é : E91BA870 : LDMDB   R11,{R4-R6,R11,R13,PC}

True, but one does not create modules in BASIC.

Well. The sole function of the BASIC in the download here is to recreate¹ the module.

Mind you that’s a typical “I can use BASIC Assembler to do this without spending on the DDE” instance. There are instances around that create the code in memory and run it without saving (as I recall) which is more like a module in BASIC (ish)

¹The author would probably prefer that you ignore the definition of the SVC_Mode as 3 when used in a 32bit module.
The page says: “All of these programs should now be Iyonix compatible”

Edit Before Rick or whoever asks, I was looking for a keyboard driven mouse mover to avoid grabbing the mouse every five seconds while testing key shortcuts and what looked to be the most promising actually crashed and took Transient and sometimes the Filer with it.

Well. The sole function of the BASIC in the download here is to recreate the module.

Syntax error: that is creating a module with BASIC, not a module in BASIC.

prefer that you ignore the definition of the SVC_Mode as 3 when used in a 32bit module.

Hmm, I saw something similar a few weeks ago. Some nice 32 bit code to deal with the processor mode. I think it was IRQ downgrade to SVC. MRS of CPSR, everything looked good, until it did some AND and OR magic to set the mode, but only altered the lowest two bits. It would work, as RISC OS pretty much only exposes the four modes always known, but this sort of logic is akin to always driving on the right as everybody always drives on the right. It’s good until it’s broken and then it’s horribly wrong…

Syntax error: that is creating a module with BASIC, not a module in BASIC.

I did say:

typical “I can use BASIC Assembler to do this without spending on the DDE”

until it did some AND and OR magic to set the mode, but only altered the lowest two bits.

Would that be something like:

MRS     R9,CPSR
BIC     R1,R9,#&1F
ORR     R1,R1,#SVC_Mode

Where SVC_Mode = 3

I’ve been having a good look at the Colour Picker source. It is of course in C, so much of it is fairly impenetrable gobbledegook to me, but I can roughly see what’s going on. It reminded me how flexible the picker really is – and I went off to take a look at Paint, which I use so rarely these days I’d forgotten about the way it uses the colour picker in 16 colour and 256 colour modes (I presume that is the OS colour picker, not a private colour picker of Paint’s own – I’ve not chased down the parts of the picker source responsible for it). Draw uses the 16 million colour picker (RGB, HSV or CMYK) regardless of current screen mode.

So now I know more clearly what I’d like in the way of an upgrade, and what it probably involves. For me, as I’ve suspected all along, implementing it would involve one hell of a steep learning curve.

I think there’d be three alternative ways of achieving my desiderata, one prettier than the others but probably requiring more work – in particular, a bit of work in Draw as well as in the picker.

1) A new option in the picker to produce a dialogue similar to the ones Paint uses in 16 or 256 colour modes, with more than 16 but less than 256 colours (probably 32?), together with an ability in Draw to use that dialogue instead of the one it currently uses; or

2) An increase in the number of colours presented in the dialogue(s) that Draw uses – maybe to 24 or 30 colours, there being no magic about the particular number but that being three rows of eight or ten colours, which would fit easily in the existing dialogues (or at least into the RGB one). That might be achieved by increasing the number of “standard desktop colours” although of course that wouldn’t fit nicely into 16 colour modes; more likely it would simply be a set of standard colours for modes with greater numbers of colours, possibly a set that the user could edit (presumably with the ability to reset to defaults, and the option to save a file of the current set to reload later). I’ve been taking a look at “web-safe colours” and probably some such set would be an appropriate default.

3) A new “colour model” that isn’t really a colour model at all, but simply a way of getting at that simple 32 (or whatever) dialogue mentioned in option (1) – which probably wouldn’t involve fiddling with Draw, as the choice of colour model is made in the picker, not in Draw.

A fourth option might be to edit Draw to be able to use the dialogue that Paint uses in 256 colour modes. This might be the simplest option, but the result wouldn’t be ideal from my point of view: 256 is too many colours, too easy to mistake one for another. (So far as I’m concerned, Draw is a draughtsman’s tool, not primarily an artist’s. You need a good range of distinct colours, not a continuum.)

IF anyone with the necessary skills feels like implementing any of these options, I shall be a VERY happy man; if not, I might have a go at implementing the third option myself, or possibly the second. But might is the operative word there: I think it’s a hell of an undertaking so far as I’m concerned. More or less “learning C”…and shelling out £50 for a copy of the DDE (I have the BASIC DDE, many thanks to David Feugey, but not the C version).

It reminded me how flexible the picker really is – and I went off to take a look at Paint, which I use so rarely these days I’d forgotten about the way it uses the colour picker in 16 colour and 256 colour modes (I presume that is the OS colour picker, not a private colour picker of Paint’s own – I’ve not chased down the parts of the picker source responsible for it).

I’ve already explained why Paint uses these different colour selectors: it’s nothing to do with screen mode, and everything to do with the fact that some sprites don’t support arbitrary colours because they use old modes.

Paint uses the standard OS Colour Picker to select the colours included in the 16 and 256 colour selectors.

Draw uses the 16 million colour picker (RGB, HSV or CMYK) regardless of current screen mode.

Again, nothing to do with screen mode: Draw uses 24-bit colour all the time, so there’s no need for palletised colour selection.

If you’re going to do anything, upgrade the Colour Picker to allow more preset colours (options 2 or 3 in your list). Changing Draw to use a restricted pallette when the underlying file uses 24-bit colours sounds like a retrograde step!

I wonder whether 27 colours might be easiest; that would cover all combinations of red, green and blue each “off, low or high” (3^3 = 27).

With that said, I haven’t looked to see what sorts of colours this actually produces; they might be prettier if chosen by hand (and then you could go for 32).

Edit: You’d probably want the 27/32 colours to be a superset of the 16, so this probably isn’t actually a great idea!

it’s nothing to do with screen mode,

Except that when you’re in a 256 colour mode, paint won’t allow you to choose the 24-bit colour dialogue for a new sprite, it only lets you choose 2, 4, 16 or 256 colour selectors. I presume that when you’re in 16 colour modes it won’t let you pick the 256 colour selector, but I don’t have any modes with less than 256 colours so I can’t check that.

Draw uses 24-bit colour all the time

Yes, I’m well aware of that. Even when your screen can’t actually display them, which is entirely fair enough.

Changing Draw to use a restricted pallette when the underlying file uses 24-bit colours sounds like a retrograde step!

Agreed – the only reason I’d do that would be if it was the easy thing to implement. I’m not thinking of offering this as a replacement for the colour picker supplied with the OS, not if I implement it myself. I can’t hope to match the quality and flexibility of the current picker. It would be a pluggable alternative module for use in particular circumstances.

I wouldn’t want to see Draw unable to use the existing colour picker! I’d only want the option to restrict it temporarily, and that only if I can’t have a bigger set of preset colours in the current picker.

You’d probably want the 27/32 colours to be a superset of the 16

Definitely!

they might be prettier if chosen by hand

Got to admit I’ve already done that for my own system, and an inspection of the innards of !XP1ReDraw will reveal the ones I use (but have disabled for the public offering). It’s not exactly the prettiest set; it’s a superset of the 16 standard desktop colours, chosen partly for being distinct enough to identify easily, and partly for being easy to pick using the percentage system offered by the RGB model on the current colour picker. The bottom four bits of each colour are masked off so you don’t have to be precise when picking – that wouldn’t be necessary of course when only using a standard set of colours in the colour picker.

I’d suggest an immediately helpful (and easy to implement) mod would be to print the HTML hex code #RRGGBB in contrasting colour in the sample colour swatch.

We could help further by, in RGB mode, having a pair of radio buttons to switch between percentage and underlying value.

Rather than having a uselessly large set of colour swatches to pick from, how about a drop-down list to select the colour set displayed therein, e.g. Window Manager standard, HTML greys, HTML reds…

None of the above would need an API change.

One could then augment that by allowing colour sets to be uploaded to the dialogue box, such as those already in use in the current document to help consistent selection, and for those suggested by, or in use anywhere in, the calling application (so you could load a Draw document as colour template with all the colours you want to use in any other drawing loaded).