On Mon, 1 Jul 2002 18:32:40 +0200 (CET) Vadim Zeitlin <[EMAIL PROTECTED]> wrote:
> But I do want to have several search folders. I just don't think they > should appear in the tree. Anyhow, here is what I propose: > > 1. add a radio/choice control to the search dialog with the following > choices: > a) select matching messages > b) append the results to the global "Search results" folder > c) open a new "search results" (notice the small 's' :-) folder > > 2. after search: > a) if no messages are found, nothing is done > b) if only one message is found I'd rather go directly to it > and not do anything else, but I don't know how to present > such choice in the GUI (as a separate checkbox "only if more > than one match"?) > c) otherwise we do what the user has chosen > > 3. the global "Search results" folder appears in the folder tree, saved > to disk (in the format above) and its properties may be edited as for > any other folder > > 4. the temporary "search results" folders don't appear in the tree but > use > the options of the folder being searched (what to do when searching > multiple folders?) and are _not_ saved to the disk I dont quite understand why vfolders is such a big problem. Allow me to summarise the issue, and if I have misunderstood something then please let me know. Herein also lies my proposals. The first issue is whether we should have a global folder or some other arrangement. This depends on what the vfolder should be used for. Personally, I canīt see a real need for it for anything else than as search type folders. A vfolder is most usefull as an information collation folder, and therefore it should not have the same abilities as a normal folder. Consequently, the most logical thing is to have it as a global folder. now should that be a global foler in its own window or part of the tree, Iīll get back to that in issue 3. Secondly its a question of whether a vfolder should be static or dynamic. That is something that can be argued in depth, but when used as a search folder it should be static, i.e. it isnīt synchronised with the searched folders or anything like that if they change. There is one exception which is that the user should be allowed to perform certain administrative operations on the search result, such as deleting messages, moving them to other folders or being able to read them. In other words a user usually performs a search for some messages because he wants to perform one or several of the forementioned operations, to e.g. clean up a folder or just to find a message. Thirdly, there is the question of where the search folder should get its properties from, how the properties should be stored and where the folder should exist. As a global search folder the most natural is that it should have its own set of behaviour, which doesnīt neccessarily mean it should behave like a normal folder, allthough it could. Therefore it should exist under the root of the server node in the tree (which would also be its path). Wether it is visible or not, is another question. Because, I can see that it could be beneficial to allow the user to "store" the search results and allow him to move to other folders and then go back to the results of the search. But it could also be implemented as just a search window showing the results, and then allow the user to move between the result window and the main M window. The latter is probably the easiest, and we could still store the result when the window is closed, so the user can get go back in a search history when he opens the search window again. I think I covered the most important parts in here. going back to Vadims forementioned suggestion, I dont really see a need for 1 or 2 as a procedural step when performing a search, because when it comes to 1,3 and 4 I would suggest sticking to just one solution either a global search or a temporary search. When it comes to 2, i would say dont do any of them, just let the user interactively do what he wants to do. This is much easier to implement and also creates a more coherent and *predictable* behaviour. And finally, 1a; donīt see why that is needed at all. This was quite a long mail, but I finally got there in the end. -- Thomas Finneid email: [EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
