Summary: | Virtual folders | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Claws Mail (GTK 2) | Reporter: | Sébastien Bigaret <sebastien.bigaret-clawsmail> | ||||||
Component: | UI/Folder List | Assignee: | users | ||||||
Status: | NEW --- | ||||||||
Severity: | enhancement | CC: | clawsmail, fbl, inka007, removed-gdpr, wcenter01-claws | ||||||
Priority: | P3 | ||||||||
Version: | 3.7.7 | ||||||||
Hardware: | PC | ||||||||
OS: | Linux | ||||||||
Attachments: |
|
Description
Sébastien Bigaret
2010-08-24 00:16:41 UTC
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. *** 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. *** |