On Sun, 30 Jun 2002 23:22:34 +0200 (Romance Daylight Time) Vadim Zeitlin <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Jun 2002 11:03:44 +0200 (CEST) Thomas Finneid > <[EMAIL PROTECTED]> wrote: > > TF> Could you give some examples of the problems you face with searching > ? > > The problem is not with the searching itself, but with the impossibility > to do anything with the results: just try searching for something in a > folder containing 1000 messages. Mahogany will gladly tell you that it > has > found (and selected in the list control) 8 matching messages -- and then > let you to [try to!] find them among the 1000 ones. This is really as > user > unfriendly as it gets. I agree. > TF> I have never used it because I have found that it doesn`t work very > well. > > Hmm, I don't know of any bugs in searching per se, please let me know of > any. Well, the problem I noticed, as far as I remeber, was that it never found anything or if it did it had nothing to do with what I was searching for. But I will have a look at it tomorrow to see if I can understand how it works better, and then get back to you with any inconsistencies or bugs I find. > TF> By virtual folders, you mean a folder that shows selected content > from > TF> other, real, folders? or perhaps as Ujwal called it, "Views"? > TF> Is there any thing more to virtual folders than this? > > There are 2 possibilities here and my question, in fact, was which one > did > we need: > > 1. a virtual folder contains a (static) list of pointers to the messages > in the other folders -- this is well suited to the "search results" > window and is easy to implement > > 2. a virtual folder is defined by a "filter" (!= existing M filters) > which > tells it to select all matching messages from some other folder(s): > the > problem here is that when the other folders are updated, this one > should > be updated as well which creates all kinds of new problems. As a search folder it doesīt need to be updated, because the result is typically only viewed for a couple of minutes. Having change synchronisation between a real folder and a search forlder is unecessary, in my opinion. But if it is used for more than search folder the of course it should be able to synchronise with the real folder. I would say go for solution 1, but think of solution 2 while doing it because generality is allways good, IMHO. And we could then easily extend it later, if need be. Allthough I canīt see, at the moment, any real need for virtual folders for anything except search type folders. But in the future it might be that we find that other types of mail list displays might beneficially use virtual folders with filters. > TF> First of all, that depends on how well M can multitask, but also how > well > TF> the mail server can. > > No, there will be anyhow only one search operation going on at any > moment > (until M is multi threaded, but this is a different story alltogether). > But > with only one search results folder you wouldn't be able to search first > in > folder A and then in folder B -- the results of the second search would > overwrite the results of the first one. OK. I understand. > TF> Virtual folders in itself sounds like a good idea, but there are some > TF> consequences. If it is only used for search results, or rather > collating > TF> information without allowing the user to modify the collection, > > We could make them read only at first but allowing the user to modify > the > message flags and even delete them doesn't seem to be difficult to > implement (deleting them will only delete the "alias", the message would > still stay in the original folder). > > TF> then the issues arenīt too difficult. > > Maybe, but I still don't see which options should it use. Remember, > options in M means a Profile object, i.e. a path in the config. What path > should a virtual folder have if it doesn't appear in the folder tree? Or > does it? Sorry, I am not up to date on that stuff, could you explain in more detail what you mean by this and how it affects the selected solution? -- 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