Re: [trojita] Re: Loading external resources [was: Re: Help for new user]
On Sunday, 2013-06-16, Thomas Lübking wrote: > On Sonntag, 16. Juni 2013 03:19:05 CEST, David Lang wrote: > > Almost all of those clients render all the HTML, including > > remote images, by default. > > Errr... just tried thunderbird - it actually does *exactly* what i > suggested (no, i did not know how it acts, otherwise i would have brought > that point in) and asks me whether i want to download that content (and > offers to always do so for messages from that sender, what's a > questionable strategy, though). There seems to be no option to enable that > globally. > > Can you point any MUA that by default renders external content (ideally not > containing the word "outlook" - MS used to enable ActiveX in mails...)? KMail has a global setting to enable this but does not check it by default. By default it displays an option inline at the top of each mail which contains external references. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
[trojita] Re: GSoC: Integrate Trojita to KDE
On Friday, 14 June 2013 22:19:10 CEST, David Lang wrote: DBUS also can't be used for a remote X connection. That's true, but something I can live with -- it's part of a desktop integration, an optional feature which doesn't work when run remotely. For those five people in the world who do all of the following: - run their MUA remotely, - have their web browser running locally, - got their DE integration bits far enough to be able to use Trojita's mailto: capabilities even though the .desktop file is on the remote side, please just set your mailto handler to do something like `ssh remotehost trojita --mailto $@`, or come up with a patch adding a proper plugin for you. For those who google this five years in future wondering why such a common setup just won't work with Trojita: patches are still welcome :). Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
[trojita] Re: GSoC: Integrate Trojita to KDE
On Saturday, 15 June 2013 17:05:34 CEST, Pali Rohár wrote: here is my updated GSoC plan with timeline: Hi Pali, thanks for sending this. It's a good plan with related tasks coming after each other, but there's a problem -- you've planned to do the Trojita-specific work in July while I'm away and Kevin is around, and the KDE-specific bits in August when I'm finally available. Could you please change these so that: - design the interfaces for plugins during the next week (that is, June 17 - 21), - put as much KDE-specific work as possible into July, - work on the patch for merging the threading/sorting either during June (after the plugin API is done and approved by the team) or in August, - work on generating notifications about unread mail (not the actual method of delivery to the user or the Kontact summary widget, these can come earlier) only in August when I'm around (it's an IMAP-specific code after all)? I fully trust Thomas and Caspar to be able to provide a good review of the Trojita side of things, and Kevin to be able to comment on the general sanity of the code as well; it's just that I'd like to utilize the resources reasonably. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
[trojita] Re: Loading external resources [was: Re: Help for new user]
On Sonntag, 16. Juni 2013 10:03:32 CEST, Kevin Krammer wrote: KMail has a global setting to enable this but does not check it by default. By default it displays an option inline at the top of each mail which contains external references. Do you happen to know whether there's been a similar discussion on introducing this feature (so we could learn from that argumentation)? Cheers, Thomas
Re: [trojita] Re: GSoC: Integrate Trojita to KDE
On Sunday 16 June 2013 12:14:44 Jan Kundrát wrote: > On Saturday, 15 June 2013 17:05:34 CEST, Pali Rohár wrote: > > here is my updated GSoC plan with timeline: > Hi Pali, > thanks for sending this. It's a good plan with related tasks > coming after each other, but there's a problem -- you've > planned to do the Trojita-specific work in July while I'm > away and Kevin is around, and the KDE-specific bits in August > when I'm finally available. > > Could you please change these so that: > > - design the interfaces for plugins during the next week (that > is, June 17 - 21), - put as much KDE-specific work as > possible into July, - work on the patch for merging the > threading/sorting either during June (after the plugin API is > done and approved by the team) or in August, - work on > generating notifications about unread mail (not the actual > method of delivery to the user or the Kontact summary widget, > these can come earlier) only in August when I'm around (it's > an IMAP-specific code after all)? > > I fully trust Thomas and Caspar to be able to provide a good > review of the Trojita side of things, and Kevin to be able to > comment on the general sanity of the code as well; it's just > that I'd like to utilize the resources reasonably. > > Cheers, > Jan Hello, it is a bit hard to reorder some parts. KDE code needs ipc/dbus, working and implemented plugin interface, maybe also cmdline args like mailto... But I tried it and here is updated timeline: 17.6 - 23.6 * design qt interfaces for trojita desktop plugins (class with pure virtual functions) for addressbook, passwords, ... * idea is to have desktop (e.g KDE) code separated in external qt plugin (implementing above interface) * have loaded only one plugin per category which provides desktop support (addressbook, passwords, ...) and plugin could be choosed in GUI 24.6 - 30.6 * change trojita code to use functions from loaded plugins * move internal password code into trojita plugin (and drop internal addressbook for now, it will be ported in august) 1.7 - 7.7 * add dbus for IPC and single application instance support * make it possible to compile trojita also without dbus (not all platforms support dbus) * support for command line arguments (only deliver them to running instance, no parse support yet) 8.7 - 21.7 * create KDE plugin using above interface which implement kaddressbook and kwallet support * for kaddressbook use kabc or akonadi * for kwallet use directly dbus or kwallet library or Qt Keychain library 22.7 - 4.8 * create new kpart plugin for kdepim which render trojita GUI into Kontact * create new build target for plugin, use existing trojita GUI classes and include window/widgets to kpart plugin 5.8 - 18.8 * work on kde code * merge option "show messages in threads" and "sorted by threading" into one and show it in "sorting" menu * add support for parsing command line arguments, add mailto: support * move internal trojita addressbook code into new trojita plugin (possible static linked into trojita as "fallback" plugin) 19.8 - 8.9 * add support for notifications via dbus and kde/freedesktop notification system * add (unread) mail information to kontact summary widget * notification integration between trojita imap code, kpart plugin and notification system * fix possible problems with kpart plugin (integration with kaddressbook, kontact, ...) 9.9 - 23.9 * final steps, code cleanup, bug fixing... Just one note: This Tuesday I have (my last June) exam. So today and tomorrow I'm studing group and algebra theory and probably I will not have time for Trojita these days. But I'm trying to read and answer emails. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [trojita] Re: GSoC: Integrate Trojita to KDE
On Sunday, 2013-06-16, Pali Rohár wrote: > it is a bit hard to reorder some parts. KDE code needs ipc/dbus, working > and implemented plugin interface, maybe also cmdline args like mailto... I don't think either D-Bus or cmdline handling is required for Kontact integration, nor for addressbook data access. > But I tried it and here is updated timeline: > > 17.6 - 23.6 > * design qt interfaces for trojita desktop plugins (class with pure virtual > functions) for addressbook, passwords, ... * idea is to have desktop (e.g > KDE) code separated in external qt plugin (implementing above interface) * > have loaded only one plugin per category which provides desktop support > (addressbook, passwords, ...) and plugin could be choosed in GUI > > 24.6 - 30.6 > * change trojita code to use functions from loaded plugins > * move internal password code into trojita plugin (and drop internal > addressbook for now, it will be ported in august) > > 1.7 - 7.7 > * add dbus for IPC and single application instance support > * make it possible to compile trojita also without dbus (not all platforms > support dbus) * support for command line arguments (only deliver them to > running instance, no parse support yet) That block is relatively independent, i.e. could also be done after the next two. > 8.7 - 21.7 > * create KDE plugin using above interface which implement kaddressbook and > kwallet support * for kaddressbook use kabc or akonadi > * for kwallet use directly dbus or kwallet library or Qt Keychain library Sounds reasonable. However, since Jan will want to be involved when it comes to the keychain decisions, you might want to do this block after the next one. > 22.7 - 4.8 > * create new kpart plugin for kdepim which render trojita GUI into Kontact > * create new build target for plugin, use existing trojita GUI classes and > include window/widgets to kpart plugin Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: [trojita] Re: Loading external resources [was: Re: Help for new user]
On Sunday, 2013-06-16, Thomas Lübking wrote: > On Sonntag, 16. Juni 2013 10:03:32 CEST, Kevin Krammer wrote: > > KMail has a global setting to enable this but does not check it by > > default. By default it displays an option inline at the top of each mail > > which contains > > external references. > > Do you happen to know whether there's been a similar discussion on > introducing this feature (so we could learn from that argumentation)? I don't know, but I think it likely to have happend at some point. Must have been many, many years ago, way before I got involved in PIM development. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: [trojita] Re: GSoC: Integrate Trojita to KDE
On Sunday 16 June 2013 13:56:05 Kevin Krammer wrote: > On Sunday, 2013-06-16, Pali Rohár wrote: > > it is a bit hard to reorder some parts. KDE code needs > > ipc/dbus, working and implemented plugin interface, maybe > > also cmdline args like mailto... > > I don't think either D-Bus or cmdline handling is required for > Kontact integration, nor for addressbook data access. > > > > > 1.7 - 7.7 > > * add dbus for IPC and single application instance support > > * make it possible to compile trojita also without dbus (not > > all platforms support dbus) * support for command line > > arguments (only deliver them to running instance, no parse > > support yet) > > That block is relatively independent, i.e. could also be done > after the next two. > I think no. Kontact kpart plugin needs to know if standalone trojita binary is already running... And for this I'd like to use already implemented dbus trojita api. > > 8.7 - 21.7 > > * create KDE plugin using above interface which implement > > kaddressbook and kwallet support * for kaddressbook use > > kabc or akonadi * for kwallet use directly dbus or kwallet > > library or Qt Keychain library > > Sounds reasonable. However, since Jan will want to be involved > when it comes to the keychain decisions, you might want to do > this block after the next one. > I think using Qt Keychain library for kwallet support should be decided earlier... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [trojita] Using QtKeychain
On Friday 14 June 2013 20:46:04 Kevin Krammer wrote: > On Friday, 2013-06-14, Pali Rohár wrote: > > I think that QtKeychain is still young project, there could > > be packaging problems and my goal is to have kwallet > > support. > > It has been around for quite some time (~2 years) and it has > KWallet support. > > > So I think using stable kwallet library will be better for > > now. Kwallet code will be in separate plugin, which means > > it will be possible to create QtKeychain plugin later > > without problems. > > One thing to understand when it comes to KWallet is that KDE > will transition to the freedesktop.org Secret Service API at > some point, keeping KWallet's API for compatibility, but > being capable of using any Secret Service daemon > implementation. > > Thus using an abstraction like QtKeychain, which has already > proven to be able to abstract KWallet and the Mac OS X > Keychain is likely to be adaptable to the Secret Service > system as well, potentially making it transparent when the > switch happens. > > The Secret Service API is, IIRC, already provided by GNOME's > secure storage service gnome-keyring. > > Cheers, > Kevin Ok, so if I choose QtKeychain for implementing gsoc kwallet support, there could be problem with packaging. But benefit is support for Apple & Gnome. If I choose kwallet library directly, there will be no packaging problems, but it does not support Gnome secure storage yet. But in future there could be one. There could be another problem with QtKeychain library. Similar to contacts. If user change desktop QtKeychain can use another password storage (e.g kwallet is not running but secure storage yes). -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [trojita] Re: GSoC: Integrate Trojita to KDE
On Sunday, 2013-06-16, Pali Rohár wrote: > On Sunday 16 June 2013 13:56:05 Kevin Krammer wrote: > > On Sunday, 2013-06-16, Pali Rohár wrote: > > > it is a bit hard to reorder some parts. KDE code needs > > > ipc/dbus, working and implemented plugin interface, maybe > > > also cmdline args like mailto... > > > > I don't think either D-Bus or cmdline handling is required for > > Kontact integration, nor for addressbook data access. > > > > > 1.7 - 7.7 > > > * add dbus for IPC and single application instance support > > > * make it possible to compile trojita also without dbus (not > > > all platforms support dbus) * support for command line > > > arguments (only deliver them to running instance, no parse > > > support yet) > > > > That block is relatively independent, i.e. could also be done > > after the next two. > > I think no. Kontact kpart plugin needs to know if standalone > trojita binary is already running... And for this I'd like to use > already implemented dbus trojita api. If I understand correctly then single instance support doesn't exist at all right now. So not having it for the Kontact integration doesn't change anything. It might even be slightly beyond the scope of the GSoC proposal, because it is not related to Kontact or KDE integration but a new generic feature for Trojita. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: [trojita] Re: Loading external resources [was: Re: Help for new user]
On 16/06/13 07:02, Thomas Lübking wrote: > Can you point any MUA that by default renders external content (ideally not > containing the word "outlook" - MS used to enable ActiveX in mails...)? The iOS email client loads remote content automatically by default. I don't know how many people read their email on their iPhones but I'm assuming the number eclipses the number of people using desktop clients like Thunderbird and Evolution. A lot of email clients have a "Load remote images" button, but then used to go on to load certain types of remote content *before* that button is clicked because of design flaws. This is why I created: https://emailprivacytester.com/ -- Mike Cardwell https://grepular.com/ http://cardwellit.com/ OpenPGP Key35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 signature.asc Description: OpenPGP digital signature
[trojita] Integration Features
Hi all, I think orthogonal to the timetable for the GSoC about KDE integration, the question about priority/usefulness of various integration points should be discussed. For example: wallet/keychain integration is probably something that most users don't really care about. They care about save password storage and having applications gather their credations from there as transparent as possible. In my personal experience the only passwords I ever lookup manually are for web URLs and there I find it annoying to have to look into my wallet and into Firefox. But that is because you sometimes need to re-login and auto-form-completion didn't work. I never have to do that for any of my email related things, because login is handled through protocols and doesn't stop to work now and then. One thing I as a user care alot about is programs that produce data (or download it, which is the case for email attachments) allow easy access to my most common locations. In case of a Qt program in a KDE session that is done by Qt (it loads the KDE file dialog which knows all my "places"). Another thing I care about is launching applications for documents. If I click a link/attachment I want the same program to open regardless of in which program I click the link. Again this should be taken care of sufficiently by Qt's QDesktopServices. Something that does do notifications (which I understand is not yet the case for Trojita anyway), it should be doing it the right way. For email programs I care about using my addressbook. Mostly for lookup of course, but ideally now and then also for adding. I guess nice to have is shortcuts and icons, the latter again mostly covered by QIcon::fromTheme() with icons from resources as fallback. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
