Dec 14 2018
Hello, I very busy lately. I hope I will have more time to finish this task, during the holidays.
Nov 19 2018
There's Prefs::createNewColor() in eventviews/src/prefs.cpp, looks like that might be it?
Nov 15 2018
Sory for the delay, I distro hopped from arch to openSuSe and I have some trouble with building from source with openSuSe (libkleo and some other dependencies don't want to build). And I also have trouble finding where the color is generated (the calendar is generated in korganizer:src/akonadicollectionview.cpp, but I have trouble finding when and where the color is set).
Nov 9 2018
BTW, here is the official Breeze color palette: https://hig.kde.org/style/color/default.html
Ok I will look into that :)
@ognarb uh, sorry, I haven't seen the notification about your last comment. Yeah, going for some more pastel color to better fit Plasma/Breeze color theme would be nice. Maybe the entire default color generator could be improved - I honestly don't know much about where the colors come from in KOrganizer :-)
Nov 4 2018
@dvratil Do you have some other improvement suggestion? I was thinking about changing the default color to a pastel green color (#BAED91) but otherwise I don't know that can be improved anymore.
Nov 3 2018
Oct 30 2018
I was looking at this task to learn how akonadi work and akonadiconsole crash directly after choosing a instance. It is a know bug? Should I create a bug report?
Oct 27 2018
Oct 23 2018
I would say let's treat the HiDPI problem as a standalone issue, the painting code should probably take font metrics into account, instead of hardcoded arbitrary constants :)
@repinc interesting, but I don't have a HiDPI screen to test. I read in the internet that using QRectF,QPointF instead of QRect and QPoint should improve the situation. So I'm changing most of the occurence of QRect and QPoint. I also found out that the item height is hardcoded in function of MonthCell::topMargin to an height of 18px, but I have not idea how to access the pixel ratio.
Oct 22 2018
@dvratil here is the screenshot
@ognarb That sounds like a good idea: you can use it to get information about background and foreground colors and calculate some reasonable color palette from that.
@dvratil Do you think, it's a good idea to use QStyle for the color. Because for the moment it's difficult to choose a color palette that look good with breeze, breeze dark and some other themes. And then add button to activate this feature, so that someone can also choose the color manually like before.
@repinc, could you please attach a screenshot?
Oct 21 2018
There is another thing to look into with with month view rendering. It looks like it does not respect the DPI and does not look quite right on HiDPI screens. The bars ae just too narrow and height does not react to larger font size.
Oct 17 2018
@dvratil I not really good with choosing color. But with some input from the VDG, I can probably change the default color. I will first work on the day/hour lines.
Flat items and less rounded corners are already in git master (for 18.12). We can wait for the improvements in the color palette to be done first, then blog about the whole task if you want.
How much of this has already landed? I only blog about things that are actually in.
Oct 16 2018
Month and agenda items in KOrganizer are now flat with less-rounded corners, thanks to @ognarb! The work has landed on master (for 18.12 release)
I think it's perfect now, so from my side, this is good to go. I don't think this kind of change belongs to a bugfix release, so I'll push this to master (for 18.12 release).
I fixed it :)
- remove border for begin and end of weeks
Oct 15 2018
No worries, hope your exams went well :)
Oct 14 2018
Sorry for the late update, I had exams. So I rewrote this differential a little bit and removed some change.
Fix some code
Revert some change
Oct 11 2018
Oct 9 2018
Another thing I just noticed: You use border width 1 unconditionally, when it was 2 unconditionally before.
Oct 8 2018
I think Denis has explained it better than I did - the margin and borders on 21st and 22nd break the effect of the continuous event - that's what I was concerned about.
The margin helps to immediately grasp that the event starts/ends on that day, just like the radius. I think there should be a margin iff there is a radius.
I think it would be easier if we change the meaning and/or name of isBeginItem and isEndItem. So that:
The smaller radius and bigger margin looked better, I'd revert to that.
Fix some margin problem
Thanks. With the small radius, it still feels like it's hard to distinguish between an event that ends on Sunday and an event that continues to next week - could you try removing the margin in this case, so that the event seemingly goes out of the screen to make it more obvious that it spans multiple days?