On Thu, 5 Sep 2002 13:25:33 +0200 (Romance Daylight Time) Vadim Zeitlin
<[EMAIL PROTECTED]> wrote:
VZ> On Thu, 5 Sep 2002 12:32:30 +0200 Xavier Nodet <[EMAIL PROTECTED]> wrote:
VZ> XN> I already implemented a draft of the 'Moving folder' feature. As
VZ> XN> I mostly did that while I could not read this list, I did it 'my way'
VZ> XN> and it does not include the 'change folder ordering' feature
VZ> As I understand now, these operations are really quite independent, so
VZ> it's ok.
VZ> XN> Current status
VZ> XN> --------------
VZ> XN>
VZ> XN> 1. There is a 'Move' command in the folder menu. It allows you to choose
VZ> XN> the folder you want as new parent for the moved folder.
VZ> Ok. Did you manage (or tried) to get DND to work?
I did not even try. I thought it would not be difficult to add once the
rest is ok, and I do not know anything about DnD.
VZ> XN> 2. It is not able to move a folder that has sub-folders.
VZ> This seems like a rather serious limitation as I'd expect this to be the
VZ> most useful feature, in fact (you can rather easily move one folder
VZ> manually, doing it for a whole hierarchy isn't as simple).
I fully agree, and I should have said that this is not working *yet*.
I guess that the code as it is now must be fully reworked to handle
moving hierarchies. As an example, we would have to first create all the
copies, and only then delete the old folders (from the leaves to the
root of the moved hierarchy).
I guess this code is in a 'prototype' state, for now.
VZ> Another useful thing would be to able to move several folders at once.
VZ> For this we should have multiple selections in the tree though -- this is
VZ> not difficult, but it would confuse lots of existing code I'm afraid.
So I'm not sure this is should be done.
VZ> XN> I don't know how NNTP and NEWS folder work, so moving them is
VZ> XN> disabled.
VZ> I think you could enable it because there is nothing to do at cclient
VZ> level anyhow (you can't move news groups...). OTOH, it doesn't matter that
VZ> much.
Will see later.
VZ> XN> For IMAP folders, the RENAME command is not sent yet so
VZ> XN> this is also disabled.
VZ> Actually, maybe it could be made even more powerful than simply moving the
VZ> folders on the same server. For example, right now I'd really like to
VZ> switch from Free IMAP server I use to my own one (because I regularly run
VZ> out of their (small) quota) and it would be nice if I could simply create
VZ> an entry for the new IMAP server in my folder tree and move all my existing
VZ> folders there.
But then I guess this involves moving each and every message one by one,
no ?
VZ> XN> Note that, for IMAP folders, I suppose that we could move the root
VZ> XN> folder of the server (when moving hierarchies is supported). Then no
VZ> XN> RENAME command is needed for this or any of its sub-folders.
VZ> Yes, but we'd have to copy all the messages.
I was actually thinking to the following situation: one wants to put all
its IMAP hierarchy under, say, another group folder where several IMAP
hierarchies would be seated because, e.g., they are personnal v.s. work.
E.g. going from
All Folders
IMAP on Free
INBOX
SENT
IMAP on somewhere else
INBOX
SENT
To
All Folders
Personnal
IMAP on Free
INBOX
SENT
IMAP on somewhere else
INBOX
SENT
This does not require any message copying, but only some modifications
in MFolders and their profiles.
VZ> XN> How it works
VZ> XN> ------------
VZ> XN>
VZ> XN> This is done by creating a new MFolderFromProfile object with the
VZ> XN> correct name (i.e. the full path of the target + the name of the moved
VZ> XN> folder). Then I loop over all the entries in the profile associated with
VZ> XN> the old folder, and create the same intries in the profile of the new
VZ> XN> folder, while disabling the environment variables expansion.
VZ> Looks very good!
VZ> XN> Questions
VZ> XN> ---------
VZ> XN>
VZ> XN> 1. Do you think that create new-delete old idea is a good one ?
VZ> It's the only one I can think of to be honest. As long as you don't move
VZ> the folder itself (i.e. physically move the messages), I don't see any
VZ> problems with it. When/if we do need to move the messages there could be
VZ> some nasty race conditions with this but we're not there yet.
VZ> BTW, do you update the filters using the old folder name to the new one
VZ> after moving?
Oh, I forgot. I will do that. I now understand why it took so little time for
me to code :)
VZ> XN> 2. I have a problem to update the folder cache, which means that I must
VZ> XN> close (and re-open) the moved folder to get it to display its number
VZ> XN> of messages.
VZ> XN>
VZ> XN> My understanding is that I can't create a new entry in the cache
VZ> XN> because the MFolder instance for the old folder is not deleted yet
VZ> XN> when I try to do that, but I did not look at this problem carefully
VZ> XN> yet.
VZ> Sorry, I don't see why shouldn't you be able to do it: simply using
VZ> MfStatusCache::GetStatus(oldname) and UpdateStatus(newname) should do the
VZ> trick, shouldn't it?
I will try.
VZ> XN> 3. Should I commit now ? I guess I should because:
VZ> I think you should :-) I probably won't be able to work on this myself
VZ> right now but it shouldn't do any harm neither.
Wilco (when filters update are done).
--
Xavier Nodet
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." - Benjamin Franklin, 1759.
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Mahogany-Developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mahogany-developers
