It is hard to distinguish between color scheme resources just by their names. Imagine we will have dozens and even thousands of them. When ColorScheme resource is added we can generate an image that shows its primary and secondary colors. We can create a small image as a pie chart and larger images like a colorschemedesigner preview square that shows all primary and secondary colors.
Implementation details:
ColorScheme class must implement ResourceImage interface
create a GenColorSchemeImageServlet that generates png (or jpeg) images for a given ColorScheme resource URI. This servlet should then issue PUT to upload generated images to the ColorScheme resource and after that set its originalImage, mediumImage, etc. properties.
add NotificationPhase handler that will submit GenColorSchemeImageServlet as a delayed job.
would it be possible for the image to be of a RL >>
would it be possible for the image to be of a RL or ROP mock up instead of the CSD square? This way a catalogue of images could be viewed quickly without having to know what SecondaryColorB_1 means allowing users to see instantly how the scheme will look.
we decided that the person who created the color >>
we decided that the person who created the color scheme will create and upload the screenshot for some Lablz page that demos that scheme. This will allow us to build a Color schemes gallery today and polish the UI for switching between schemes.
Later on we may find a way to create a screenshot automatically. There is no pure Java solution for server-side page screenshots that I am aware of, so it is a bit messy. But it is possible.
This has 3 key purposes. 1 It would be a cross re>>
This has 3 key purposes.
1 It would be a cross reference for users showing which color variant goes with which css class.
2 A RL of the scheme colors sorted by screen row position would give the user a quick rough look at the scheme (heading, menu, search, title, text, row background 1 and 2 etc).
3 Maybe the user can adjust the colors in this resource instead of using the 3rd party tool.
Could this form the basis of moving all css elements into classes?
we had to handle two caseslight and dark schemes >>
we had to handle two cases
light and dark schemes required different mapping.
This I suppose can be made static by splitting each scheme into two - light and dark.
contrast adjustments.
If color scheme had low contrast (discovered by the luminosity delta) we dynamically compensate to increase the contrast. This can not be done in a static way.
The mapping code it manageable and can be quite easily augmented by Java developers. Other than that I do not believe we should allow users to change individual colors inside a color scheme. This messes up balance of colors which is the whole purpose of the color scheme. So the barrier to entry here in restricting modification of the mapping to developers is a good thing.
But may be I am missing something here. What is the need that you are referring to? Can you provide an example? If you see the case when the mapping is imperfect let Alexander know and he should fix it. In fact I see a set of imperfections still and they are being fixed now.
My initial reason for this was thinking of how a >>
My initial reason for this was thinking of how a user would relate the 15 colours in primary and secondary to all the places on screen that it would affect, hence the original comment.
The library of images should give a user enough help.