I am moving a thread here because it needs a different title and location
One of my biggest gripes with RW is the corruption of colours that occurs when you use a colour picker. The issue is a MacOS bug that remains unfixed year after year. However, because RW only has the MacOS picker then there is no easy way around this.
The issue is that if you enter #0F76ED into the picker, it can in certain circumstances, be corrupted into #005EE3.
There is a neat solution in Source (and BWD stacks) which is the ability to use a CSS Background and that provides an easy and accurate way to create a BG colour. So in this case if you want to use a colour such as #0F76ED, you could paste:
background-color: #0F76ED;
into the Custom CSS
6 Likes
Nice touch !!
iām not sure iād call monitor color calibration a bug, but whatever ā glad you found a workaround that works for you. :-)
1 Like
@isaiah The issue is not a direct monitor calibration issue, this is a bug, in that when an event occurs, using the eye dropper seems to trigger this event, colours entered into the MacOS colour picker are corrupted when RW+Stacks build the code. In other words the MacOS colour system passes a corrupted colour to Stacks. The Stacks colour well, will display a colour that when it is checked in the picker will match what was entered as a hex number, but the colour passed to stacks IMHO, is corrupted. This is nothing to do with picking a corrupted colour due to screen calibration.
See the video below where you can see the same hex colours are used produce a visibly different shade of blue.
Entering this hex colour as user code or using the method outlined in this post avoids this colour corruption the previewing or publishing. So if you enter a value such as #0F76ED as CSS, this exact value will be used in the code. Itās a big issue if you care about colours and is one of the main reason that nearly every serious Mac App uses itās own picker IMO.
I should also say that I use Autodesk Graphics which has itās own picker and also an option to use the MacOS picker. I can create the same issue using the MacOS picker, but the solution in Graphic, is to use the Graphic picker.
An ideal workaround for this MacOS bug for Stacks users, would be to add an additional way to enter colours as Hex or rbga in addition to the existing colour well. Maybe a project for the weekend:)
1 Like
I donāt see any corruption of colours in the rendered Stacks page code. (If you use the eye dropper on the colour well then it will continuously change because of the calibration issue / bug / behaviour / whatever, but just typing in a value gives me what I expect on the published page).
If I enter #0F76ED into the Hex Colour # then my page renders a colour of rgb(15,118,237) which is undoubtedly correct. It would therefore seem to me that I get what I expect in this circumstance.
I was going to comment on the use of the word āfinallyā as you have been able to do this with SectionsPro backgrounds PasteCSS function since 2016. To mention this though would be petty and so I wonāt. :)
2 Likes
The colour system works perfectly right up to the point when the Apple_lets_fek_with_the_colour_toggle is toggled by some event. There is anecdotal evidence that the event is triggered by using the MacOS Picker Eyedropper to āpickā a screen colour, but there may be other things that trigger it. After that event, the corruption continues until reset with a Mac reboot. You can see the colour corruption in my video above which was filmed after the event.
Not petty at all. It was more of a finally in a framework sort of way and more for the attention of Source users and those of fragile disposition unwilling to make the leap into the BWD world.
Such people should stay away from not only RapidWeaver but the entity that is the internet.
1 Like
Oh it was extremely petty but I couldnāt resist. Iām now hitting myself around the face with a barbed colour picker.
2 Likes
To me your example looks to be a plain vanilla description of what color calibration is intended to do. Try clicking on the gear/cog icon and choosing a different profile. Maybe set to generic RGB and see if that has some impact on the ābugā ā Iām betting it does. š
You are focusing on the word eye dropper. I am not picking up a colour from something I see on the screen. I am not in colour sampling or collection mode here. I am entering a hash followed by the 6 hex characters in the only way possible to do this in stacks using the colour well. The hex code I enter is then being corrupted. I could even remove the monitor and do this if I was able to repeat the mouse movements. If I reboot my Mac (with the same monitor and profile) the issue will be corrected until the event occurs again.
i am reasonably certain i understand what you are doing.
Iām afraid weāre going to have to agree to disagree here. this is exactly how the apple color picker is intended to work. however unclear that intended purpose is ā and it is very very unclear.
You are far from the first person to suggest this is a bug. I doubt you will be the last.
again, Iād like to suggest choosing RGB in the cog menu. Or even better, download Scala Color, I think itās free, and it provides a color picker that tends to make these bugs/misunderstandings a bit clearer. No one in the Mac development world has a deeper understanding of color than Marc Edwards. My guess is that he built Scala Color exactly to solve the disagreement we are having right now. Scala Color is a plugin to the apple color pallets so you can use it in RW.
Yes I have Scala. Using Scala to enter colours as an rbga by entering the characters, makes no difference.
See the video below showing a live preview changing the colour between the same rbga colour entered into the stacks colour well and then directly by CSS. Again you can see the change in the blue BG colour.
Again I should stress that I am not doing any colour picking, i.e. I am not sampling a colour on the screen using the eye dropper. I already know the colours I want and I just want to enter them into a stack.
Remembered this post over on Weavers space
https://community.weavers.space/content/perma?id=118456
see the post by Joe
Suggested Skala/Scala (donāt know if thereās a difference) does cause colour corruption
As Isaiah says, this is a MacOS/colour profile thing, I described it in the post pmjd linked to, itās not limited to RW, the problem exists in ALL MacOS apps that use the system colour picker.
The only way around it it for RM to develop their own picker (Ā£Ā£Ā£] that operates solely within RW.
Youāll note that Photoshop, Afinity, Pixelmator donāt use the system colour picker, they each have their own that doesnāt sample the colour ON SCREEN but sample the underlying structure of the image/file to return the value.
Do a g search for āApple color picker wrongā and look at the dates for the results, this isnāt a new thing, in fact itās a fantastically old one ā¦
Also dump Skala, it was good but Appleās security updates have made it not only useless but dangerous as it can cause loops than can only be exited by terminating the host app (RW) in Activity Monitor.
That WS post started off describing the same issue that I mentioned at the top of this thread, but turned into a discussion on what colour picker to use to pick colours from a screen. The issue here is nothing to do with picking or sampling or collecting a colour from a screen. Itās about entering a colour as a hex or rbga value into stacks to use that colour.
Sorry, as you mentioned using Skala I thought it might be useful information as it triggered a memory about corrupting colours.
1 Like
@Webdeersign try it without using the Skala color panel.
If I set a color via hex in the Skala panel and then look at the CSS with developer tools, the color is given a different (incorrect) RGB value in the CSS rule.
If I use the built-in RGB slider panel and type in the hex color value, the CSS is created with the correct RGB values. Note that you need to change to a different color (if the color had been entered via Skala) otherwise it doesnāt trigger an update.
@DLH I donāt use Skala and only created a video to show Isaiah really that Skala wasnāt a solution. Over the past few years I have tried many pickers and the result when entering a hex or rbga colour directly into stacks has not changed once the issue is triggered. I use Sip to pick colours and this has so far not triggered the problem.
Also this ābugā only occurs after some event triggers it and once it is triggered, from then on, colours entered as hex into stacks are corrupted. Using the picker to pick a colour from the screen is reported to trigger this even, which has been my experience but I suspect other apps using their own eye dropper to pick a colour from the screen also triggers this problem.
Restarting RW doesnāt fix the issue. This is an issue for stacks because the only normal way to enter a colour is to enter a hex colour in the MacOS colour system and then drag that colour into the stacks colour well.
@pmjd No need to apologise. I just wanted to focus on the issue of entering a hex colour into stacks using a know hex colour.
@Webdeersign, I guess my MBP isnāt currently triggered!
I wanted to test this as consistent colors is important, and I was seeing the issue you are reporting when I entered the hex color in the Skala panel, but not when entered in the RGB panel. At first it was intermittent, but that was because I had pasted the hex in the RGB panel which already had the color set from Skala. I had been using Skala to paste hex colors. Itās coming off my mac!
I thought maybe you were seeing what I was. Appreciate the heads up.