Difference between revisions of "KDE PIM/Meetings/PIM Autumn 2013 meeting"
|Line 158:||Line 158:|
* triple room: 80 EUR (incl. breakfast)
* triple room: 80 EUR (incl. breakfast)
* quadruple room: 101 EUR (incl. breakfast)
* quadruple room: 101 EUR (incl. breakfast)
Revision as of 15:57, 11 November 2013
- 1 Topics
- 1.1 Projects
- 1.2 Discussions
- 1.2.1 Mark Gaiser
- 1.2.2 Dan Vrátil
- 1.2.3 John Layt
- 1.2.4 Add your discussion topic here
- 1.3 Presentations
- 2 Agenda
- 3 Meeting Notes
- 4 Blogs
- 5 Organization
QML Calendar components - write and modify support
I started working on those first in a very crude form during the October 2012 PIM sprint. At that time it was a proof of concept to see if - ultimately - KOrganizer could be re-written using QML.
In the March of 2013 PIM sprint i basically started all over with some help of a few other folks to get real QML components in a not so hacky manner. Those components - while still very hacky - proved to be very powerful already. By the time i'm writing this, the components can do all the reading stuff and work very well.
During the next sprint i plan to fully implement:
- Creation of new events trough QML
- Modifying events through QML
- Port the components to Qt 5/KF5 if akonadi can run there already.
Akonadi Server-side Change Recording
Effort to move change recording from client side to server, using database to record notifications and replacing DBus by new ASAP command (IMAP IDLE-like)
On the sprint, I want to
- Present the change in more depth (if anyone will be interested)
- Discuss details of the protocol extension
- Do a live demo (if I manage to make it work at least a bit until then)
- Continue hacking!
Dedicated GMail resource
I've been talking about this for more than a year, maybe now is the right time to finally start hacking on it. GMail web interface has replaced regular folders by tags and you can assign multiple tags to a single email. The tags are exposed via IMAP as regular folders, which means that when you assign two tags to an email, the email will appear in KMail in two folders, but in Akonadi it will be stored as two different items (so flags etc. are not shared). Google have their own IMAP extension that allows uniquely identify the email within the entire account. The plan is to store all emails in the Inbox folder, make the tag folders virtual collections and link emails from inbox into these the tags.
I need to talk to Kevin Ottens about some changes in the IMAP resource to be able to share as much code as possible and will have to implement the Google-specific IMAP extension, either directly to KIMAP or somehow make KIMAP extensible (subject to discussion)
Performance of mixedmaildir resource
I hear a lot of complaints about poor performance of this resource. It's a bit sad, given that it was forced on users during migration from KMail 1. They now have to live with this resource that is slow and difficult to migrate away from to maildir or mbox. I think the biggest bottleneck there (and this actually affects maildir and mbox resources too) is that they don't use incremental item retrieval. So I'd like to take a look into this and see whether it's even technically possible to use incremental retrieval with file-system based resources and what else could be optimized there.
Where should akonadi bases QML components live?
It's surprisingly difficult to find a right place to put akonadi QML components. Once can argue for kdepim-runtime since QML is runtime stuff. One can also argue for kdelibs since it's basically still a library only in QML. I'd like to discuss this and make a final decision.
The march 2013 PIM sprint had quite a bit of discussion for the next KHolidays version. The idea is to have it as an Akonadi resource. I'd like to discuss this forther and make a first draft implementation for this. I can't do this alone and will need John Layt and someone else that knows how to make akonadi resource to get started.
KDE PIM to Qt5/frameworks
(don't know if i keep this item, i might remove it later) Slowly but steady key KDE parts are moving towards Qt5 with the frameworks initiative. I think it's time to start porting the KDE PIM stack to Qt5/frameworks. This affects the following git repositories:
- kdepim (no work thus far?)
- kdepim-runtime (no work thus far?)
- kdepimlibs (has a frameworks branch, status?)
- akonadi (already compiling on Qt5, done?)
Synchronizing data between multiple Akonadi instances
This interesting proposal came from one of my colleagues. The idea is to have one heavy-duty Akonadi server with all the resources and agents running on your server/home PC. There would also be a "synchronization agent" running there, which would be pushing changes (over network) to a lightweight Akonadi server (no resources, only the "synchronization agent" running there, receiving and uploading changes to the "master" server) running on a tablet or smartphone (so with limited HW resources).
- run Akonadi-based applications on underpowered devices without draining too much battery
- synchronization problems, conflicts
KDE PIM and KF5
Probably discuss what we have to do and how much work it actually requires, maybe try to come up with a veeery tentative schedule?
- Akonadi - done (maybe do Akonadi 2 and drop all the backward-compatibility stuff?)
- KDEPIM Libs are sort-of frameworkized already, right? It would be great to see most of it in Tier 1 to allow easy adoption by Qt projects (Qt PIM libraries would just be pure awesome). Good opportunity to drop KCal and all the deprecated stuff from libakonadi (and elsewhere)
- KDE PIM Runtime - just port that, I guess
- KDE PIM - a milestone for merging Akregator2 ? :D No, seriously: maybe we could use this opportunity to talk to someone about UI, simplify it (without removing features!) and polish it.
A major impact on PIM using Qt5/KF5 is the new QTimeZone support in QDateTime and KTimeZone/KDateTime/KLocale being moved to kde4support. This means the removal of all references to these K* classes from our api and code. Such a significant break in api is the chance to clean up other issues the api and libs may have, then break them up into frameworks. This is a lot of work, especially regression testing, and should probably be targeted for a KF 5.2 timeframe. Also need to decide when to put PIM 4 into LTS and move dev to KP5?
- Need to document any split planning same as we did for kdelibs -> kf5, may need separate sprint early 2014?
- Port kdepimlibs to Qt5/KF5 code after KF5 preview release?
- Remove deprecated/old api and code
- Separate out all generic Qt-only PIM libs as Frameworks
- See if any need left for kdepimlibs, or rename, e.g. kde-akonadi-integration?
For KF5 / KDEPIM 5 I would like to kill off KHolidays and implement KHolidays2:
- Define a new open file format using JSON, convert existing data files
- Create a generic C-based library like libical?
- Create a generic Qt-based library based on existing api
- Create an Akonadi resource (how to query what files/countries/languages are available?)
- Will need to depend on Qt 5.3 release to get Calendar System support
What can we do to improve PIM support in Plasma 2? Mark's QML work will be useful there, but what else?
- Major issue still that Plasma Calendar will start-up Akonadi just to find there are no calendar resources configured.
- DataEngines should be re-worked/re-named from AkonadiEngine to more generic MailEngine, etc
- Need to add collection support and config to DataEngines
- Need to support adding events in Plasma
- Perhaps have first-run wizard to add calendar resources?
- What else?
Continued work on adding better support to QLocale in Qt 5.3, including Calendar Systems. Ask me about how many different plans we've been through now :-)
Add your discussion topic here
- Porting Akonadi to Qt5/KF5. Where are we? What needs to be done?
- Porting Akonadi to Qt5/KF5. Where are we? What needs to be done? (part 2 if needed)
- PIM LIBS API/ABI requirements for KF5. What can we break? (Ping Sergio on irc)
Other notes will go here
Picking a suited time for the sprint is done on this doodle link.
The sprint will take place in Red Hat office in Brno, Czech republic.
You can fly directly to Brno from London Standsted (Ryanair), Eindhoven (Wizz Air) or Moscow (UTair Aviation). From the airport take bus 76 (or N89 if you arrive at night) to the main train station. Buy the 60-minutes ticket for 25 CZK (~1 EUR) (or 90 minutes for ~1.4 EUR directly at the driver)
If you can't fly directly to Brno, we recommend flying to Vienna and then taking a bus. There is a Student Agency bus going every 2-3 hours right from the airport terminal and it goes directly to Brno centre. You need to book a seat in the bus, please do it as soon as possible on http://www.studentagency.eu/ (Wien -> Brno). The journey takes about 2 hours and the ticket is 17 EUR (and there is a touch screen in front of every seat where you can watch a movie or listen to music. Also you get a free hot beverage and Czech newspaper)
Of course you can fly to Prague too. You have to take the Airport Express bus to get from the airport to the main train station. The bus goes every 20 minutes, it takes about 45 minutes and the fair is 2.5 EUR (you can buy ticket at the driver). From the main train station you can either take an Euro City train (goes every hour, takes 2 hours 40 minutes and costs 8 EUR), or use metro to get to Florenc (one station) and from there take Student Agency bus to Brno (book your tickets here as soon as possible: http://www.studentagency.eu/ (Praha->Brno)). The bus takes 2.5 hours and costs 8.20 EU.
If you live close enough you can also take Euro City train from Berlin (7.5 hours), Vienna (2 hours) or Budapest (4 hours).
In Brno you can take trolleybus, bus or tram to get around the city. You can buy a ticket in yellow machines that are at most stops. If you find yourself at a stop without the yellow machine, try to look around as they are sometimes hidden behind a corner, or you can buy the ticket from driver (but they are more expensive).
For you only two tickets are relevant: 15 minutes (the cheapest one) for 20 CZK (~0.7 EUR) or 60 minutes (the second cheapest) for 25 CZK (~1 EUR). You can change as many time as you want. If you are not sure whether you can make it in 15 minutes, better buy the 60 minutes one. That's enough time to get you almost across the entire city and it's not that much expensive.
At night there are night buses going every 30 minutes (from 23:00 till 05:00). All nigh lines meet at 25 and 55 minutes past the hour and they all leave at the half hour or hour from the main train station. The tickets and prices are the same.
To get to the Red Hat office (and to the hotel) from the main train station, take tram number 12 in direction Technologický Park and get out at station Červinkova (20 minutes journey). At night take night line number 99, same direction, same station.
The Red Hat offices are right at the station. The sprint will take place in the second building (orange one with red top), which is behind the white one. Entrace is on the right side. Go up to 4th floor and ring the bell or ring the number that will be printed at the door, someone will come to open. If you feel lost, you can ask at reception in both buildings and they will direct you.
We recommend booking a room in the A Sport Hotel. It's just 5 minutes walk from the office, it's quite cheap and it's very nice. If you want to book the room yourself, please do it as soon as possible (if you want to share the room with someone, you have to arrange it yourself). For the rest (if you tick "need accommodation" on sprints.kde.org) we will book the rooms (and you just pay when you leave).
The prices are
- single room: 46 EUR (incl. breakfast)
- double room: 59 EUR (incl. breakfast)
- triple room: 80 EUR (incl. breakfast)
- quadruple room: 101 EUR (incl. breakfast)
To get to the hotel, follow the instructions how to get to the venue. When you get off the tram at the "Červinkova" station, return a few meters back to a crossroad and turn left to "Červinkova" street and go downhill. Then cross the parking lot on the left side, go through the gate and after couple meters you will see the hotel building on you left side.