- User Since
- Apr 12 2015, 7:56 AM (192 w, 2 d)
Sun, Dec 16
I've recently run into the same problem on Akonadi on Windows, ended up allowing C++17 on Windows only and shipping a C++14-compatible implementation of C++17 optional in 3rdparty. Maybe we could just get rid of the optional in this agent until we can switch to C++17 proper. I hate not having it, but it's just one or two occurrences here and probably not worth the magic to satisfy all compilers.
Sat, Dec 15
Thu, Dec 13
Tue, Dec 11
Mon, Dec 10
Sun, Dec 9
Wed, Dec 5
Tue, Dec 4
Sat, Dec 1
Mon, Nov 26
Hi @mlaurent - check dev/agent-configuration branch in akonadi.git, dev/agent-config branch in kdepim-runtime.git and dev/agent-configuration in kmail.git. Drop me an email if you have any question, I'm not much on IRC these days :-(
Thu, Nov 22
Hey. I won't be able to get to this within the next couple weeks, so you can finish this if you want. I already have a branch with most of the agents and resources in kdepim-runtime ported, I'll push it for review when I get to my other computer so you don't have to do everything over again. The main reason I was delaying pushing this was that I wanted to port as many agents as possible first to see if the API in akonadicore was well designed and usable, I think I had some unpushed changes to the API as well. I'll drop you an email with details when I get to it :-)
Tue, Nov 20
Mon, Nov 19
There's Prefs::createNewColor() in eventviews/src/prefs.cpp, looks like that might be it?
Change qWarning() to qCWarning(AKONADISERVER_LOG) before committing, but otherwise, it can go in. Thanks!
Profiles were supposed to allow various screen layouts per single setup, for instance, if you have your monitor and TV both connected to your PC, you may want to have "Monitor", "Monitor+TV" and "TV-only" profiles. The idea was to have a combobox in the KCM that would allow you to quickly switch between those profiles without having to fiddle with the rest of the GUI every time. IIRC we did not agree with @afiestas on this feature back then, so it remained disabled (should've been on a branch instead of #ifdefs on master, I admit that ) and while I was still working on kscreen, I never got around to actually finish it and push it.
Nov 14 2018
Nov 9 2018
@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
This is kinda dangerous: if the RIDs are duplicated, we cannot know if all the matching Items are just multiple instance of the same Item: they can be two completely different Items, accidentally having the same RID stored in the DB. In such a situation, this patch will correctly update the content of the rightful RID owner, but destroy the content of the Item with the broken RID.
Nov 2 2018
If you stored the entire path to the collection (hierarchical remote ID), then you would have a unique identifiers for collections based on RID
Nov 1 2018
Definitely keep (and should not require any work):
Looks good now, thank you!
Looking good. Thanks for your work so far!
In thin particular case it's OK to merge now - you fixed what Laurent asked for and there's hardly anything else in this patch to complain about :-)
I would say that the ModelSpy should even be created on the stack because the way it is now it leaks from one test run to another (this is only destroyed after all tests methods are executed).
Hmm, technically those methods (slots) are accessed from another class, so they /should/ be public or, preferably, the connect statements should be in the Private class. Also, you can probably now remove the Q_PRIVATE_SLOT declarations form IncidenceTreeModel header file.
Oct 31 2018
Nice catch, thanks for the patch! Ship it to the stable branch, please (Applications/18.08)
Oh, sorry for that! And you are right, we should have more tests to cover this :( Many thanks for diving into Akonadi to find this.
Oct 28 2018
@poboiko hi Igor, how's the progress on this? Do you need any help?
Oct 25 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 :)
Looking pretty good so far. Nice job!
Oct 22 2018
@mlaurent what do you think about this?
@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.
The storage library should remain inside of the akonadi.git repository (just another folder in the /src dir). The library will be internal to Akonadi (so we won't even install it or its headers), and we will only want to use it in tools that all live inside of the akonadi repo - we definitely don't want some other party running direct SQL queries against our database behind our backs :-)
@repinc, could you please attach a screenshot?
Oct 21 2018
Let's just improve the wording a little, rest of the code looks OK now.