Hello,

so I'm working on the events/holidays integration into
Plasma calendar and one thing I'd like to get some advice
on is the coloring of the day in the calendar grid if it
contains an event. If you open the Plasma calendar
and move a mouse over the grid, you can see the
highlight color at 0.4 opacity. So now it just needs
another color to mark the days containing an event.

Currently what I have is the Plasma theme highlight
color (#3DAEE6), took into the HSL model and the
Hue is rotated 30 degrees. That should hopefully
ensure that the theme text color would still be
readable on such background (plus the color would
also be at 0.4 opacity level, I think).

So my question to you guys knowledgable about
colors is - is +30 degrees hue good enough rotation?
Will it work with all colors? Will it give good color
combinations? Or would you recommend different
value or different approach?

I don't know much about colors, but does it have to be a different color to mark the existence of an event?

How about something like this:


One event on the 13th and 24th, two events on the 29th, and three (or more) events on the 8th.

True, it doesn't have to be a color. But I feel like background
color would keep it the cleanest (and simplest), especially
since we already use the background alteration to mark
"today" and "selected" day. So I believe the bg color for
events would simply keep in line with the current stuff.

mck182 wrote:True, it doesn't have to be a color. But I feel like background
color would keep it the cleanest (and simplest), especially
since we already use the background alteration to mark
"today" and "selected" day. So I believe the bg color for
events would simply keep in line with the current stuff.

I actually kind of line the idea of an alternate cue to colourisation. One thing I've seen on my phone calendar is small ticks on the left side of each day, vertically positioned according to the time the events start. Maybe not as clean, but highly functional. Also, with ticks we can use different colours for different types of events; orange could be holidays, green for reminders, etc.

Hmm...well those ticks look like broken graphics
or broken pixels

I was also thinking about putting a little triangle
in the bottom-right corner...?

Kver wrote:

mck182 wrote:True, it doesn't have to be a color. But I feel like background
color would keep it the cleanest (and simplest), especially
since we already use the background alteration to mark
"today" and "selected" day. So I believe the bg color for
events would simply keep in line with the current stuff.

I actually kind of line the idea of an alternate cue to colourisation. One thing I've seen on my phone calendar is small ticks on the left side of each day, vertically positioned according to the time the events start. Maybe not as clean, but highly functional. Also, with ticks we can use different colours for different types of events; orange could be holidays, green for reminders, etc.

Hardly recognizable.

The ticks on the left are much more functional, but they're really tiny and hard to tell apart without concentrating...

How about just a number then, indicating the number of appointments during that day?

And thinking about the alternate color:
I think that isn't really a good idea. Unless we can propose several distinct colors for types or numbers of appointments. I easily have appointments every single day, and that would simply change the regular color of my calendar. It's a rather sparsely used calendar where there is much value in having a different color for days with or without appointments, IMO.

The ticks especially lack contrast (value to close to the background)

Shifting the hue will not damage foreground contrast if that is gained by the value (black or white text) and 60° will skip color collisions, but
- hue changes on low value or or saturation are barely notable (gray remains gray on any temperature)
- 60° is red, yellow, green, cyan, blue, magenta; because of the asymetric luminance, notably yellow can be used as contrast to red (and green), ie. the user may highlight by red on yellow or yellow on green - in that case you're running into a black cat in the dark. In case this isn't in a hot loop, calculate the contrast and rotate in the other direction in doubt.

I thought there was a contrast testing function somewhere in KDE, but in doubt you can use

Code: Select all

bool
FX::haveContrast(const QColor &a, const QColor &b)
{
    int ar,ag,ab,br,bg,bb;
    a.getRgb(&ar,&ag,&ab);
    b.getRgb(&br,&bg,&bb);

    int diff = (299*(ar-br) + 587*(ag-bg) + 114*(ab-bb));

    if (qAbs(diff) < 91001)
        return false;

    diff = (299*qAbs(ar - br) + 587*qAbs(ag - bg) + 114*qAbs(ab - bb)) / 300;

    return (diff > 300);
}