On Fri, 14 Jun 2013, 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.
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?
beware of scope creep for a GSoC project, keep things small enough to succed
with (hopefully the student sticks around afterwords, so other stuff can be done
later :-)
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.
DBUS also can't be used for a remote X connection.
* 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).
it's reasonable to default based on the environement, but have a place to select
it (in theory the KDE/Gnome/etc freedesktop coordinated addressbooks will all
share data, but that's just theory)
Most users don't change environments very much, so most of them can leave it on
autodetect and never have a problem
David Lang
