- User Since
- Apr 12 2015, 7:56 AM (184 w, 2 h)
Fri, Oct 19
Thu, Oct 18
Wed, Oct 17
Minor nitpicks, otherwise looks good.
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.
Tue, Oct 16
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).
This has to go to master because of the string change, so it will be available in 18.12. We'll push this for you if you don't have commit access.
I don't know if this is a good thing or not - there's still the window decoration and mouse pointer size that you would need to take into account, so just moving the window arbitrary amount of pixels left/right/above/below the cursor may or may not be enough based on user's window decorations theme, cursor size and DPI settings.
Thanks for the patch! Just a minor nitpick, otherwise it looks good.
Mon, Oct 15
No worries, hope your exams went well :)
Sun, Oct 14
Hi Scarlett. The official stable Flathub Flatpak is on Flathub github: http://github.com/flathub/org.kde.kontact
Thu, Oct 11
Looks good, thanks!
Sorry for the delay, I had a hard time matching your changes in the logic to the original code :) looks good though. Thanks.
Tue, Oct 9
Mon, Oct 8
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.
So maybe we could pass some additional flag when creating the MonthGraphicsItem in MonthItem::updateMonthGraphicsItems() - this code is aware of the full even length, so it could simply pass an additional flag saying whether the event continues on next week (or started in the previous week, or both) and the painting code could handle that completely separately, like avoiding the border and margin on the respective side. What do you think?
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 them in this case, so that the event seemingly goes out of the screen to make it more obvious that it spans multiple days?
Thanks for digging into the POP3 resource, Chris!
There seems to be a regression compared to the previous version when drawing events that span multiple weeks - in the original version the event is not rounded on week end and week start, while on your screenshot it appears the event has round corners on Sunday and Monday. Can you look into it?
Sun, Oct 7
KMailTransport is a PIM library in the first place. PIM already depends on WebEngine, so I'm not much in favor of this change, sorry.
What other components outside of Kontact/KDE PIM depend on KMailTransport?
Sat, Oct 6
Fri, Oct 5
Looks sensible. Thanks.
Thu, Oct 4
Wed, Oct 3
No problem, the codebase is similar enough that if you code against the 18.08 branch the patches should apply on master without any big issues. If you don't have commit access (or even if you do and can't test against master), we can check and apply the patch for you :)
I'm fine with a separate diff for month view, I just didn't know from the top of my head which parts of the code are shared between those views.
Also, does this affect only the Agenda view (day/week view), or the month view as well? We should probably fix both, otherwise it will look weirdly inconsistent...
Tue, Oct 2
Looks nice, thanks for looking into this!
Cool! Just tried playing around with the test app a little, looks pretty good :)
Mon, Oct 1
Sat, Sep 29
Isn't the URI just an Akonadi ID? That should be enough to retrieve the Item from the ETM manually (build ID-only Item with Item::formUrl() and pass it to EntityTreeModel::modelIndexForItem() which will give you QModelIndex for the actual fully-populated Item) - for the editor and viewer you want to manipulate the Akonadi Item anyway, not the KContacts::Contact itself.
Fri, Sep 28
We don't really participate in GSOC/SOC/etc.. I don't want to speak for @mlaurent, but from my side, we simply don't have the time and manpower to manage it. And the topic of GSOC and similar projects never even came up on any PIM meeting.
@obogdan We are definitely fine with this, but we need help with it. I'm willing to keep the appimage up-to-date, as long as the updates are trivial (like updating tarball names and checksums), but I'd welcome someone from the community to help us with this (testing, solving issues, etc.)
Oh, cool! I'd very much prefer if we had a Kontact appimage instead of kmail/korganizer/.... as it helps to sell the brand of Kontact as a whole.
Thu, Sep 27
Because it was no longer needed (fully replaced by Akonadi and IMAP resource), it was duplicating a lots of code from KIMAP library and no-one was interested in porting it and maintaining it.
However, unlike IMAP slave, the kiomail requires users to use Akonadi and have their email accounts configured there - at which point interfacing with Akonadi directly might more optimal :-)