Hello, On Friday 14 June 2013 16:30:16 Jan Kundrát wrote: > Hi Pali, > thanks for your plan. In general, it looks good, even though I > have a couple of comments on this. > > First of all, the timeframe is missing. I agree that it's > great to first decide on *what* to do and only file the > detailed timeline later on, so I'm adding this for the sake > of completeness. >
Yes, I have some timeframe written, but it could be changed if something from list is going changed... > Second, some of the tasks are defined in a rather high-level > way. For example, the "create new kpart plugin for kdepim > which render trojita GUI into Kontact" is a good first step, > but I was hoping for something more integrated, i.e. using > Kontact's facilities for notiffying about new mails, etc > (assuming there is something like that in Kontact). This will > very likely have rather far-reaching consequences for > Trojita; proper hooks for actually discovering new messages > will have to be provided, facilities for providing really > persistent references to messages (nope, QPeristentModelIndex > is not enough here) might be needed, etc. What is you opinion > about this -- do you consider it something which you'd like > to investigate, or something out-of-scope for the GSoC? > Kontact has summary kpart plugin which showing new (unread) mails. But I do not know if it can be extended without patching it... @Kevin, do you know if this is hardcoded for kmail? Or is there API for using kontact summary plugin (adding new mails)? Kmail has own taskbar icon and notifications reporting directly to KDE plasma. There is some dbus signal (but again kmail specific) org.kde.kmail /KMail org.kde.kmail.kmail.unreadCountChanged And I do not know nothing more about notifications for new mails. @Kevin, is there something other? > Comments for the rest are inline. > > > * add dbus for IPC and single application instance support > > I'm not sure whether DBUS is what we want here. In my opinion, > the single-instance support is required for acting as the > mailto: URL hander in a system, and implementing the > single-instance-app on top of DBUS means that Windows/Mac > won't get this functionality. I don't care about Windows and > Mac that much, but I'd at least like to see some discussion > about whether the QtSingeApplication is enough or whether > DBUS is better, and why. > QtSingeApplication is not part of official Qt releases, so it will be needed to include full QtSingeApplication source code to Trojita... Lot of linux desktop and also KDE applications using dbus for this single instance and dbus library is part of qt. And for kpart plugin dbus will be needed, so I think it could be easier to use dbus also for communication with running instance. But maybe single instance support code can be in separate class and if somebody will need support also for windows/mac, it could be possible to implement it... > > * have loaded only one plugin which provides desktop support > > (addressbook, passwords, ...) and plugin could be choosed in > > GUI > > My first reaction to this is that the plugin should probably > be chosen based on what environemnt the application is > running in, but perhaps it's wrong (it would certainly be a > bit weird if the user suddenly "loses" her addresbook when > switching from KDE to something else, for example). > Yes it will be wrong if user switch to another desktop and loose all passwords, contacts, etc. Autodetection could be used when Trojita starting first time and will ask user what to use. But it still should be possible to choose plugin(s) in configuration dialog. > > * move addressbook, password, ... code into "internal" > > trojita plugin (which will be statically linked into > > trojita as "fallback" plugin) > > This is a low-level technical issue appropriate for a > discussionabout a particular patch, when it's ready, but why > not have it as yet another plugin? Perhaps to make sure that > at least some functionality is there even if no plugins could > be found? > It will be another plugin. And because qt support both static and also dynamic plugins, it can be compiled as user/distributor want... > Also please keep in mind that the current address book is tied > into the abook implementation rather tightly. This is > something to be aware of when designing the interface; > perhaps the GUI part of abook management could be offloaded > to a given plugin after all? > I think it will be better to move addressbook GUI into plugin. For KDE plugin, this allows to use KDE addressbook application (and possible also version integrated into Kontact). > > * create new kpart plugin for kdepim which render trojita > > GUI into Kontact > > Notifications? Providing some kind of a persistent identifier > so that Kontact can "attach" mails to e.g. events in a > calendar? Perhaps that's impossible without pretending to be > an akonadi backend, in which case it's out of a table, but > still worth a discusssion. > If it is not necessary, I would like not to use akonadi. And I do not know if there is some Kontact API which not using akonadi... > I agree with Kevin's mail later in this thread where he is > strongly in favor of async interfaces -- these are harder to > write, but provide huge benefits. > Here with async interfaces, do you mean to use Qt signals/slots for jobs and not to use blocking exec() functions? > So, the proposal looks good, and I'm interested in your > answers and, when that phase is done, in a timetable of when > you think you'll be able to have the individual pieces > finished. > > Sorry for not responding earlier, got busy at work, fell ill > and received a shine new camera :) -- that's too many > distractions in a single week. I hope this will get better on > my side now. > > Cheers, > Jan -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
