First of all, sorry for not replying before but I have only received most of the messages in this thread yesterday evening -- and I'm not even sure that I have them all although I think so as I can follow its internal logic without any unexpected jumps (which is more than can be said about most other, complete, threads anyhow :-)
On Sat, 28 Jun 2003 12:24:02 +0200 (CEST) Robert Vazan <[EMAIL PROTECTED]> wrote: RV> On Mon, 23 Jun 2003 09:47:42 +0200 Xavier Nodet <[EMAIL PROTECTED]> wrote: RV> RV> > On Sat, 21 Jun 2003 20:35:46 +1000 (E. Australia Standard Time) Mark RV> > Livingstone <[EMAIL PROTECTED]> wrote: RV> > RV> > > <renaming folder leaves stale filters> RV> > RV> > Such a code already exists but is only used when moving a folder (menu RV> > entry Folder->Move) in the tree, and is most probably still buggy. RV> > However, the needs are the same, so this code should be used when RV> > renaming the folders too. RV> RV> I looked at renaming code and IMHO it isn't the right thing and it will RV> never be. I just don't like the idea that whenever I add some control RV> with folder name, I have to add renaming code too. I'd like to question this fundamental assumption -- why not? Provided that there is one place in the code where we do it what's wrong with calling some Profile::OnFolderRename(old, new)? RV> The usual solution to renaming vs. references problem is to use RV> identifiers. Renaming is then done by pointing the identifier to RV> another location and all references to the identifier can be left RV> intact. It's a nice solution but before applying it I'd like to know which problem does it solve ;-) RV> Now the question is how to fit identifiers into Mahogany. Using RV> generated numbers looks ugly in configuration file. Yes. BTW, in answer to your other message in this thread: plain text config is not just a by product of using wxConfig, I do like using plain text for everything as debugging is much simpler with it and I'd like to keep it. The only problem is that it's so inefficient :-( RV> More specifically, when fodler is moved, instead of physically moving RV> all properties, it gets MovedTo=<new location> property. I think you already agreed on [not doing] this with Xavier but, anyhow, this simply won't work. And we definitely shouldn't build even more intelligence/complications in Profile, it's already too complicated (and it must be as fast as possible!). RV> The whole thing is a bit complicated as there are many names: name in RV> folder tree, physical folder name, references, Imap server folder, and RV> now the identifier. Currently there are 2 names: 1. folder name in the tree 2. mailbox name which is also IMAP/NNTP folder/newsgroup name for the folders of that type It could be a good idea to add 3. internal name which would be initially the same (1) but never be changed unlike (1), i.e. when the folder is renamed we just change either its Mailbox or Name properties, not its group name (as far as I understand this is what Xavier proposed, right?). It would make the new code simpler so I'm tempted to do it but the problem is that all existing references to (1) in the code (and there are a lot of them) should be checked and modified if they really must refer to (3) and not to (1). There is clearly scope for lots of new interesting bugs here so before doing it I'd like to be sure that we really need it. To summarize, here is what I think about the proposal to add (3): + code will be simpler (and so less buggy) internally - names in config won't correspond to the names on screen - big changes needed, risk of new bugs Anything else? Thanks, VZ ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
