This patch tries to show what virtual folders could be in Claws Mail. First at all, an IMPORTANT note! Do not change an existing folder's type containing messages to 'virtual'! In general, please backup your mail folders and the claws' configuration directory, or better, use an alternate configuration and a mail folder dedicated to tests. This is probably obvious, but it's always better to make it clear! I've not noticed any problem nor encountered any loss of mails but I'm myself an early user of claws and I may have missed important things. Also please note that I've tested it on MH folders only (no imap, no news), and on linux only. I've attached two versions of it: - virtual_folder.patch: a full patch including patch #, since the patch guidelines state that "The patch should not depend on other patches." - virtual_folder.req_independent_quicksearch.patch: one incremental patch, depending on patch #2249 (I include them both as it may help read it without the stuff coming from #2249) After applying it, virtual folders can be created this way: - create a new folder - look at its properties and change the Folder Type from "Normal" to "Virtual" Since I'm not a GUI expert at all, I simply bound the search request to the folder name. The request should be put at the end of the folder name, using the form: ':<folder>:<type>:<request>:<recursive>' (don't forget the first ':') following the same syntax as the remote command --search exposed in the previous messages, with an additional ':' at the beginning. For example: - for unread mails, folder's name can be: "My unread mails :Mail:E:unread:y" (remove quotes) - for matching a color: "Important stuff :Mail:E:colorlabel 2:y" - finding messages with 'claws-mail' in the subject, in a given directory, non recursively: "#:mh!Mailbox!inbox:S:claws-mail:n' (note the difference with the --search remote command: / are forbidden in folders'names so they are replaced by '!' here) etc. Some notes about what has been done: - if you change a mail in a virtual folder, the original mail is changed: if you delete it, it deletes it for real. If you move it, it moves the original message. If tags are added or removed, it is made on the original one, etc. - The icon is changed to the 'draft' icon. - Renaming a virtual folder to update the search request does not update it immediately for now; just select an other one than re-select the virtual folder to update it. - Virtual folders cannot be moved (this is to avoid strange behaviour that are not solved yet) - You cannot revert a virtual folder to a normal folder from within the interface. However if you want to do so, just close Claws, edit folderlist.xml and change 'virtual' to 'normal'. - Messages cannot be moved into a virtual folder. That's it! I'd be really glad to here what you think about that, if it could be of some interest and if it does, about the way it has been coded and how it can be improved and continued. I obviously would have lots of questions in that case! -- S
Created attachment 887 [details] Full, standalone patch (including the patch #2249)
Created attachment 888 [details] Incremental patch, requires #2249
Hi, First, I've not looked much at the code itself, though it needs polishing for sure, at least in format ;-) so my comments are mainly from a user's point of view. The hack seems to work, though I've tested only with small folders. With the unread mails example a very curious thing occurs, clicking on mails only marks read the half more or less: click on one, opens and marks it read, click on next opens but still appears as unread, click on next, does it well, click on next opens but still bold. It happens both with mouse and with 'n' key (next), but not when you use space key, which is able to mark all read as opened. These strange interactions should be fixed. As some actions (like reading mails on the unread virtual folder) can alter folder content some method to invoke folder refreshing would be required (menu option to be able to bound a keyboard shortcut preferred). Currently you have to change to another folder and go back as you said, and renaming should trigger that too, you said too :) The GUI for creating the folders doesn't really need to be complicated: a "Create" button in the quick search bar could be all you need. By pressing it the current quick search expression would be transformed to suit the required format (like the s,/,!, in folder paths). It probably should gather some other info with the already existing dialogs, like folder name or where to put it in the folder tree. The GUI for edition can be done the same way, using the existing quicksearch, maybe changing background to another colour to reflect you're editing a virtual folder. The "Create" virtual folder button would be changed to "Update" to allow finishing the process. Of course the virtual folders should use a new pixmap, not drafts one, but you already know that :) Moving messages into a virtual folder should be also forbidden in the move dialog, not only in drag-n-drop. Maybe not showing the virtual folders in the tree. So, keep the good work! I think this is a good start and after polishing can be a great and simple virtual folder implementation.
I've not read this patch in details yet (let's first get #2249 in !), but I don't think this is the good way to implement virtual folders. Going the folder-plugin way would be, imho, much better. It would separate virtual folders from real folders both in the code and in the GUI, and it would greatly help reducing interaction between these rather specific folders and global folder-managing code. Also, the functional choice of allowing moves and deletions seem tricky to me. Allowing flag changes (unread, mark, tags) (and updating the source mail) is a good thing, but these folders should contain a list of emails matching a given rule, they should not allow to delete or move emails that are, in reality, search results.
Hi, Thanks to both of you for your comments! @Ricardo: "clicking on mails only marks read the half more or less" -> really strange, I do not have this behaviour, everything is fine on my side... I like the idea of re-using the quick search bar for editing the folder's property, I keep that under my pillow :) @Colin about the deletion & move feature: I'd really like to be able to do that, but I understand one can expect a virtual folder to be read-only in that respect; we can imagine that if is implemented, it will be disabled by default (or else, I can also leave with a patch apart for that). Now on the most important topic: I understand that implementing it in the core vs. in a plugin is an important design point --I'm discovering the project and I admit that I did not think about going the plugin way. Before continuing the work, and since you're both members of the dev.team, I guess that you need to discuss this, so I'll wait for something like an "official" recommendation :) BTW speaking of plugins, I did not find any documentation on them: is there a doc. somewhere describing the general principles, how to bootstrap a plugin etc., or should I dig in the plugins code? -- S
Hi S
*** Bug 2713 has been marked as a duplicate of this bug. ***
*** Bug 2814 has been marked as a duplicate of this bug. ***
Also new to claws-mail, I agree with comment 4 that it should be a plugin. Besides keeping claws leaner, it would make the code a lot more maintainable. Someone suggested that it was a bad idea to be able to delete an email in a virtual folder. (That it should be read-only.) Myself I can see advantages to being able to delete. But if one can make a list from a search that allows delete, that would mostly satisfy that need. Particularly if one can save the search. (Like can be done in bugzilla.) My 2 ¢ :)
FWIW: there's an ongoing effort to provide this as a plugin, more info: http://lists.claws-mail.org/pipermail/devel/2014-June/001143.html
[SPAM REMOVED]
*** Bug 4092 has been marked as a duplicate of this bug. ***
*** Bug 4261 has been marked as a duplicate of this bug. ***