headers
Pali Rohár | 18 Jun 2013 17:33
Picon

Addressbook interface for qt plugins

Hello,

I'm sending first version of qt plugin interface for Addressbook. I reused
src/Gui/AbstractAddressbook.h and I think that Trojita 
GUI only needs additional functions for opening addressbook manager (now called from menu: IMAP -->
Address Book) and 
function for opening add/edit window for new/existing contact (now called from button near "From" and
"To" field in email). 
Because KAddressbook has own dialogs/windows, it is better to use native KDE application for KDE plugin.

And about interface for password storage, please look at my last email in "Using QtKeychain" thread.

#ifndef ADDRESSBOOK_INTERFACE
#define ADDRESSBOOK_INTERFACE

#include <QtPlugin>

class QString;
class QStringList;

class AddressbookInterface {

public:
    virtual ~AddressbookInterface() {}

    /**  <at> short Returns a list of matching contacts in the form "[Name <]addy <at> mail.com[>]"
     *
     * - Matches are case INsensitive
     * - The match aligns to either Name or addy <at> mail.com, ie. "ja" or "jkt" match
     *   "Jan Kundrát <jkt <at> gentoo.org>" but "gentoo" does not
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Krammer | 16 Jun 2013 15:08
Picon
Favicon

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mildred Ki'Lya | 14 Jun 2013 15:11
Picon
Favicon

Tags: how to be notified when the SELECT command is completed?

Hi,

I finally started doing something instead of just examining. The code is 
available in the tags branch in: 
git://git.mildred.fr/pub/mildred/trojita.git (and for some reason, my 
cgit front-end cannot accessthis new repository, I'll have to look at it)

What i did is create a TreeView containing tags. When a mailbox is 
selected, the TagListModel (a new class I created) is populated with 
TreeItemMailbox::syncState.

The problem is that I only get the syncState in cache, and not the 
latest version. When I first select a mailbox, I get an empty list.i 
have to deselect it and re-select it to get the actual tag list.

the signal comes from the mailbox tree view, and is sent to the 
TagListModel::setMailbox (I took inspiration from MsgListModel that also 
changes when a mailbox is selected). And in setmailbox, I directly take 
the TreeItemMailbox::syncState::flags list to get the list of tags.

Why isn't there a signal in TreeItemMailbox to notify when the SELECT 
command has completed?

How would you do things?

Thanks,

Mildred
(Continue reading)

Permalink | Reply | 1 comment |
headers
Guido Berhoerster | 12 Jun 2013 19:02

PREFIX/bin/libbe.contacts.a in git

Hi,

the current git version installs PREFIX/bin/libbe.contacts.a,
what is that about? Should I file a bug?
--

-- 
Guido Berhoerster
Permalink | Reply | 2 comments |
headers
Vayu | 12 Jun 2013 16:29

Help for new user

I just found Trojita and have some questions.

Currently when I change the layout, upon quitting and restarting all my changes are lost.  Some of the things
I want it to remember are which columns to view on the message list as well as resizing and expanding the
message view so that there is no message shown until I open in a new window. Also I'd like it to remember the
general size and layout of the windows.
Is there a way to have Trojita save my layout and viewing preferences?

Is there a way to have loading images set to automatic?

Thanks much,
Joseph
Permalink | Reply | 27 comments |
headers
Jan Kundrát | 6 Jun 2013 14:03

Replying to mailing list messages with a Reply-To going to another address

Hi,
there's a bug report [1] complaining that Ctrl+R on a message from a mailing list but with a Reply-To
pointing elsewhere replies to the list, not to the Reply-To address.

This can be changed so that a Reply-To overrides List-Post when activating "reply by guess". However, that
would not be much consistent with messages to MLs which do not have Reply-To, as Ctrl-R would still respond
to the MLs in this case, not just to the author. That could, of course, be changed as well, but I'm not
terribly inclined to do so simply because the whole point of "reply by guess" is to, well, guess what to do
based on a set of heuristics. I really like Ctrl-R going to mailing lists. "You could always press Ctrl-L to
reply to list" is not a great answer because one could always press Ctrl-Shift-A to use a private reply.

I start to believe that having the buttons for changing the reply type within the actual composer would be
best here (like a combobox "Reply goes to the ML", "Replying privately", "Replying to all but me",
"Respondents picked by hand") is the only reasonable way to go which would make more users happy.

Or do we want a checkbox in the settings for what Ctrl-R shall do, like "take a guess (preferring mailing
lists and group replies)", "reply to all recipients but me", "reply to everybody", "try to produce a
private reply"?

Or do we want both?

And who's gonna write that patch? :)

Cheers,
Jan

[1] https://bugs.kde.org/show_bug.cgi?id=320816

--

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pali Rohár | 5 Jun 2013 15:53
Picon

GSoC: Integrate Trojita to KDE

Hello,

in this Google Summer of Code I'd like to integrate Trojita into 
KDE. This means support for KWallet, KAddressBook, dbus, mailto:, 
... and also integration to Kontact (like KMail).

I think that it should be possible to compile Trojita without KDE 
dependencies, so first is needed to decide how to use KDE API.

I see two possible solutions:

1) Use #ifdef to enable/disable KDE code at compile time

2) Create qt library plugin(s) with KDE API which can be called 
from Trojita at runtime - if plugin(s) will be available

What do you think? What is better, or do you have any other idea?

--

-- 
Pali Rohár
pali.rohar <at> gmail.com
Permalink | Reply | 62 comments |
headers
Jan Kundrát | 30 May 2013 20:27

Moving bugs to KDE's bugzilla

Hi,
in an effort to make bug reporting a little bit easier for users, the issue tracking has moved to KDE's bugzilla.

From now on, please report bugs and features at [1]. If you'd like to receive the bug spam^H^Htraffic,
please add "trojita-bugs <at> kde.org" to the list of users you're watching and make sure the appropriate
checkboxes are all ticked.

If someone would like to volunteer in moving of the existing reports in Redmine to KDE's bugzie, such a
heroic effort would be strongly and loudly applauded :).

Cheers,
Jan

[1] https://bugs.kde.org/enter_bug.cgi?product=trojita&format=guided

--

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
Permalink | Reply | 0 comments |
headers
Mildred Ki'Lya | 28 May 2013 19:03
Picon
Favicon

Re: Finalizing support for tags in Trojita

I continued thinking and ...

Le Thursday, May 23, 2013 3:22:57 PM CEST, Mildred Ki'Lya a écrit :
>
> So, at first, I wanted to make a special 2nd item as child of a
> mailbox to put the tags, I'd now rather make another column.
> What do you think of the idea?
>

this seems the way to go, but I would rather avoid fetching the same 
message multiple times (once for the complete mailbox and once for the 
list of messages in a tag). And i'd like to fetch the complete mailbox 
when we are only requesting a specific tag. Ideally, the IMAP SEARCH 
command should only request the flag we want to display.

I wouldwant to see:

     y321 SEARCH RETURN (ALL) KEYWORD xxx

In MailboxTree.cpp, we would need different flavours of TreeItemMsgList. 
The one TreeItemMsgList would work just as now, fetching all messages. 
It would be augmented to allow partial fetching of messages given a 
criteria. Possibly, the TreeItemMessage children should be indexed by 
the IMAPUID.

We would also have a new class TreeItemTagMsgList that wouldbe a proxy 
around TreeItemMsgList and fetch only messages of the giventag.

Then, it's only a matter of hooking up one TreeItemTagMsgList for each 
flag in the mailbox, possibly in a TreeItemTagList, accessedusing
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jan Kundrát | 27 May 2013 01:39

Re: visual fixes for Trojita

Hi Mark, sorry for not responding earlier -- once a mail marked with "needs attention" scrolls out of my
sight, it's just effectively gone :(. I'm also writing to the ML in hopes that people who might care more
about the visual side of things will get involved.

On Thursday, 9 May 2013 06:45:18 CEST, Mark Constable wrote:
> It would be great if trojita could offer custom font settings per pane and just 
> leave the system settings for the surrounding "chrome".

I pushed a patch weeks ago which shall, hopefully, fix this -- Trojita will now respect your KDE settings for
the monospace font size.

I agree that it "would be cool" to have a button for changing the fonts for everything, but I'd prefer someone
else to contribute that.

Is the current git version working good enough for you regarding the font sizes?

I've also just fixed the sizing of windows and columns within the message list.

> Another one I notice is that the text link color doesn't seem 
> to be supported.

That has been fixed some time ago as well.

> If the trojita subject was larger on the left and the Tags icon to it's right with From, To and Date values
lined up
> vertically I think would be an improvement. That's the kind of "low hanging fruit"
> I should dive in and investigate, but I'm in the middle of writting a PHP control
> panel thingie for my day job.

Well, patches are most certainly welcome. You'll see that we're using a simple QLabel for showing the whole
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jan Kundrát | 27 May 2013 01:37

Re: Replacing QNAMWebView in QtQuick2

On Sunday, 26 May 2013 22:31:08 CEST, Matt Richardson wrote:
> I am happy to do the work but I need some help understanding what
> QNAMWebView does and how it handles message parts so that I can start to
> replace it. Any help at all would be fantastic.

The only interesting thing are the custom network schemes (and disabling any other scheme as well -- you
don't want spam to fetch images from unique URLs because that would enable them to track you and verify your
e-mail address).

The end result should reuse Imap::Network::MsgPartNetAccessManager::createRequest (see
src/Imap/Network/MsgPartNetAccessManager.cpp to understand what it's doing).

For others on this list, this is the relevant part of our earlier conversation:

> Digging further, it looks like the Qt5's WebView ships with support for 
> custom URL schemes at least -- see [4] and the patches linked from there 
> [5], [6]. This looks like something which can serve as a foundation for now. 
> I've sieved through the WebKit2 sources and it looks like the 
> QQuickNetworkReply *could* be the thing which we're looking for -- but it 
> will need quite some coding to tie it with Trojita's QNetworkAccessManager. 
> It also remains to be seen whether it works well when invoked in an 
> asynchronous manner.
>
> [4] https://bugs.webkit.org/show_bug.cgi?id=74933
> [5] https://bug-74933-attachments.webkit.org/attachment.cgi?id=121376
> [6] https://bug-74933-attachments.webkit.org/attachment.cgi?id=120038

Hope this helps. If something is not clear, just ask.

Cheers,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane