Just checked in a couple more changes to keyboard navigation (my specialty). You can now change the focus of the message in the message list by holding down control when using arrow key navigation. It looks great in Firefox, but not so great in IE. If there are any CSS wizards out there that want to take a look at this, feel free. The new class used is in mail.css (#messagelist tr.focused td).
Also there were two bugs that I fixed. The first was that after you deleted (or moved) a message if you used the arrow keys to navigate you would still "select" the invisible message. That invisible message is now properly skipped. The second is that upon moving a message the next message was not selected. It now is.. unless it was the last message in the list. I'll address that ASAP.
-Charles
On Tue, 25 Apr 2006 14:26:07 -0400, Charles McNulty charles@charlesmcnulty.com wrote:
Just checked in a couple more changes to keyboard navigation (my specialty). You can now change the focus of the message in the message list by holding down control when using arrow key navigation. It looks great in Firefox, but not so great in IE. If there are any CSS wizards out there that want to take a look at this, feel free. The new class used is in mail.css (#messagelist tr.focused td).
Also there were two bugs that I fixed. The first was that after you deleted (or moved) a message if you used the arrow keys to navigate you would still "select" the invisible message. That invisible message is now properly skipped. The second is that upon moving a message the next message was not selected. It now is.. unless it was the last message in the list. I'll address that ASAP.
-Charles
Naturally in making these changes I created a handful of other bugs. The largest of which was that you couldn't delete or move multiple messages. this is now fixed in CVS. Also, moving or deleting the last message now behaves a bit more predictably by selecting the previous message. I ignore the fact that a couple of seconds later a new message appears beneath it. I'm not convinced that that needs to be fixed. Finally I fixed a bug where if you switch folders/mailboxes you lost all keyboard support. Not sure if I introduced that bug recently or if it's older, but it's fixed now
-Charles
On Wed, 26 Apr 2006 13:12:24 -0400, Charles McNulty charles@charlesmcnulty.com wrote:
On Tue, 25 Apr 2006 14:26:07 -0400, Charles McNulty charles@charlesmcnulty.com wrote:
Just checked in a couple more changes to keyboard navigation (my specialty). You can now change the focus of the message in the message list by holding down control when using arrow key navigation. It looks great in Firefox, but not so great in IE. If there are any CSS wizards out there that want to take a look at this, feel free. The new class used is in mail.css (#messagelist tr.focused td).
sourceforge's webcvs doesn't show any of these changes. did you guys swap to subversion or another repository???
Auke
On Thu, 27 Apr 2006 16:50:21 +0000, Auke Kok sofar@foo-projects.org wrote:
sourceforge's webcvs doesn't show any of these changes. did you guys swap to subversion or another repository???
Auke
There appears to be an issue with the WebCVS. There have been a number of changes submitted sucessfully to the CVS, which are there, but nothing has appeared as changed in WebCVS for a little over a month now.
--
Andrew
On Thu, 27 Apr 2006 13:30:40 -0700, Andrew Fladmark afladmark@orbital-web.com wrote:
On Thu, 27 Apr 2006 16:50:21 +0000, Auke Kok sofar@foo-projects.org wrote:
sourceforge's webcvs doesn't show any of these changes. did you guys
swap
to subversion or another repository???
Auke
There appears to be an issue with the WebCVS. There have been a number of changes submitted sucessfully to the CVS, which are there, but nothing has appeared as changed in WebCVS for a little over a month now.
oh the joy that is sourceforge CVS!
I'll try pulling it instead - but usually I visually examine first.
Auke
Andrew Fladmark wrote:
On Thu, 27 Apr 2006 16:50:21 +0000, Auke Kok sofar@foo-projects.org wrote:
sourceforge's webcvs doesn't show any of these changes. did you guys swap to subversion or another repository???
Auke
There appears to be an issue with the WebCVS. There have been a number of changes submitted sucessfully to the CVS, which are there, but nothing has appeared as changed in WebCVS for a little over a month now.
I received this response from SF, when I inquired about a different project CVS status:
Per the notice on the site status page, the CVS sync between developer and anonymous CVS hosts is currently disabled. This is due to some potential data corruption issues on the developer CVS host. We are trying to keep the data sources separate for now, to ensure the highest levels of data integrity (we have multiple possible sources of good data to fix the corruption from, including the anonymous CVS hosts, nightly tarballs, tape backups and user's own working copies).
Please keep an eye on the site status page for further updates to this issue:
Cheers,
I've just finished changes to a pretty significant change to the way RC handles deleted mail, and I wanted to run it past y'all before I comitted it. First I'll describe the existing process, then I'll describe how I changed it.
Now: Overview: if mail can be moved to the Trash folder it is, otherwise it is immediately and irrevokably deleted. Specifics: 1)If trash mailbox is defined and you are not deleting something from within the trash folder mail is moved to the trash folder 2)If no trash mailbox is defined mail is deleted immediately and permenantly 3)If you delete something from within the trash folder it is deleted permanantly. 4)If a message has been flagged as deleted (from some other program) it has a default style of shaded out, and there is no ability to undelete it. It acts just like all other mail
My changes: Overview: If there is a Trash folder nothing changes (mostly). If there isn't a trash folder defined messages are flagged as deleted
- If you have a Trash folder defined nothing should be noticeably
different. 2) If you don't have a trash folder defined messages are flagged as deleted and the deleted style is applied to them. By default the deleted style will be "display: none" meaning they will disappear and things will appear to have not changed 3) If you change the deleted style to be striked out, or greyed out (for instance), they will be visible and there will be a little trash can icon in the same column as the "unread" icon column. Clicking on the Trash icon toggles the deleted status
I will be doing more testing and cleaning up my code tomorrow. I'm feeling pretty good about these changes at the moment. The default behavior will be identical in almost all situations, and if in the future we want to change the default behavior, it's as easy as changing the mail.css file. It introduces the ability to undelete messages, and in general makes the code a little cleaner and more modular IMO. (In particular the deletion logic is now all centralized in a delete_messages function, instead of scattered about between the delete_message, command() and move_messages() functions.
Any comments? Suggestions?
-Charles
Charles McNulty wrote:
I've just finished changes to a pretty significant change to the way RC handles deleted mail, and I wanted to run it past y'all before I comitted it. First I'll describe the existing process, then I'll describe how I changed it.
[ Change message deletion behavior to mark as deleted rather than mark and purge directly if no designated Trash folder. ]
Any comments? Suggestions?
Using IMAP's seperate mark-for-deletion and purging features moves RC toward feature completeness and helps anyone who runs a corporate mail system with a full retention policy. We run modified IMAP servers with the normal purge function replaced with a garbage collector; however, it's far easier allowing the user to unflag messages still in the folder than it is to manually pull them out of a hidden folder or archive database.
- The "move to trash" vs. "mark deleted" should be a per user
configurable option.
- Display of deleted messages should be a toggle (menu, button, etc.)
easily accessible from the mail folder.
- Messages marked for deletion can be "undeleted" by the user.
These are features common in a number of the major mail clients.
It would seem to me that use of css styles to control display of deleted messages would not play well with other mail folder functions which probably need a very clear notion of the contents of the message list, a message position in the list, and the visible window on the list, but perhaps my understanding of how the styles would be utilized is incomplete.
John Dennis wrote:
- The "move to trash" vs. "mark deleted" should be a per user
configurable option.
In a sense it is, in that it's controlled by the existence of the Trash folder defined in the config option. No Trash folder = mark deleted. That said, a whole lot of things should be user configurable, but I think the best strategy would be to create a framework for this rather than just adding a new preference for every new feature. In other words I agree but I don't think that it's enough - alone - to hold up the feature.
- Display of deleted messages should be a toggle (menu, button, etc.)
easily accessible from the mail folder.
Easily done by dynamically changing the deleted style.
- Messages marked for deletion can be "undeleted" by the user.
done.
These are features common in a number of the major mail clients.
It would seem to me that use of css styles to control display of deleted messages would not play well with other mail folder functions which probably need a very clear notion of the contents of the message list, a message position in the list, and the visible window on the list, but perhaps my understanding of how the styles would be utilized is incomplete.
Yes, that's a distinct possibility. The message position is handled differently depending on where you are. If you're looking at a message it looks for env.next_uid which is defined directly from PHP's message index. If you're navigating the list, it looks at a function I wrote that checks the hidden status of the row and skips it if it's not there. I'll look into the message count issues ASAP. I've just been cleaning out all of my debug code and such.
-Charles
On another related note, can I get some opinions and examples from other software as to whether the 'new' status is preserved when a message is flagged as deleted? Thunderbird removes the new status on deletion. Is this standard? Should this be default for RC?
-Charles
On Fri, 2006-04-28 at 12:23 -0400, Charles McNulty wrote:
On another related note, can I get some opinions and examples from other software as to whether the 'new' status is preserved when a message is flagged as deleted? Thunderbird removes the new status on deletion. Is this standard? Should this be default for RC?
"new" is defined to have both the RECENT and UNSEEN flag.
I don't see how its possible for an UNSEEN message to have the DELETED property applied to it. Therefore when a message is deleted removing "new" seem correct.
To the best of my knowledge Evolution, Outlook, and Thunderbird all operate this way.
Charles McNulty wrote:
On another related note, can I get some opinions and examples from other software as to whether the 'new' status is preserved when a message is flagged as deleted? Thunderbird removes the new status on deletion. Is this standard? Should this be default for RC?
-Charles
It works like that for Thunderbird, Outlook, and Outlook Express.... I thought that New was unseen.... so wouldn't that mean that if you've deleted it, how can you have not seen it (at least the subject)? Just an opinion.
Brett Patters - Roundcube Forum Admin wrote:
It works like that for Thunderbird, Outlook, and Outlook Express.... I thought that New was unseen.... so wouldn't that mean that if you've deleted it, how can you have not seen it (at least the subject)? Just an opinion.
Good enough for me. I will make the change such that deleted messages are also marked as SEEN.
-Charles
On Apr 28, 2006, at 9:48 AM, Brett Patters - Roundcube Forum Admin
wrote:
Charles McNulty wrote:
On another related note, can I get some opinions and examples from
other software as to whether the 'new' status is preserved when a
message is flagged as deleted? Thunderbird removes the new status
on deletion. Is this standard? Should this be default for RC?-Charles
It works like that for Thunderbird, Outlook, and Outlook
Express.... I thought that New was unseen.... so wouldn't that mean
that if you've deleted it, how can you have not seen it (at least
the subject)? Just an opinion.
The exception to this is if you group-erase a selection of mails.
You might select all and delete, or select more than you wanted to
and delete. If some of that selection was off the screen you wont
even have seen the subject lines.
That would be an argument for preserving the unseen status of emails
that haven't been specifically selected and displayed, when deleting.
-- Mark Edwards
On Fri, 28 Apr 2006, Mark Edwards wrote:
On Apr 28, 2006, at 9:48 AM, Brett Patters - Roundcube Forum Admin wrote:
Charles McNulty wrote:
On another related note, can I get some opinions and examples from other software as to whether the 'new' status is preserved when a message is flagged as deleted? Thunderbird removes the new status on deletion. Is this standard? Should this be default for RC?
It works like that for Thunderbird, Outlook, and Outlook Express.... I thought that New was unseen.... so wouldn't that mean that if you've deleted it, how can you have not seen it (at least the subject)? Just an opinion.
The exception to this is if you group-erase a selection of mails. You might select all and delete, or select more than you wanted to and delete. If some of that selection was off the screen you wont even have seen the subject lines.
I don't know what the default behavior is in other mail clients,
but if I mark something deleted, I want the bolded mailbox to go away, so I can tell when there is new stuff. If you delete a message that you didn't read, that is your problem, don't do that. What do you want to happen in the majority (in my case, all) of the time? Have it go away and not bother me any more.
Jon Daley wrote:
On Fri, 28 Apr 2006, Mark Edwards wrote:
The exception to this is if you group-erase a selection of mails. You might select all and delete, or select more than you wanted to and delete. If some of that selection was off the screen you wont even have seen the subject lines.
I don't know what the default behavior is in other mail clients, butif I mark something deleted, I want the bolded mailbox to go away, so I can tell when there is new stuff. If you delete a message that you didn't read, that is your problem, don't do that. What do you want to happen in the majority (in my case, all) of the time? Have it go away and not bother me any more.
actually, default behavior for mail clients that mark as deleted rather than move the message to the trash folder is to leave it marked as unread. they are different statuses that have nothing to do with each other. what you're talking about is combining the "delete" function with the "mark as read" function. they are separate for a reason. what you're saying is when you "mark as deleted" you also want to "mark as read" which could be a user option, but not one that is by default because they are not the same.
Randy Noval wrote:
actually, default behavior for mail clients that mark as deleted rather than move the message to the trash folder is to leave it marked as unread. they are different statuses that have nothing to do with each other. what you're talking about is combining the "delete" function with the "mark as read" function. they are separate for a reason. what you're saying is when you "mark as deleted" you also want to "mark as read" which could be a user option, but not one that is by default because they are not the same.
Which mail clients? I can only test with Thunderbird, but without a doubt it marks deleted messages as "seen" and futhermore does not restore the "unseen" flag if you undelete a message. I think a perfectly rational argument could be made for both cases, and that it depends solely on how you use/interpret the "new" flag. For some the act of deleting a message is enough to mark it as seen. To use an analogy, if I throw away a piece of snail mail unopened and my girlfriend asks me if I've seen it, my response would be "yeah, I saw it, and I threw it away."
In any case, given my opinion that it could go either way, I'm more interested in the consensus of other clients. Given a scenario where there are two "right" answers, I'd prefer to program the more popular "right" answer.
-Charles
Charles McNulty wrote:
Randy Noval wrote:
actually, default behavior for mail clients that mark as deleted rather than move the message to the trash folder is to leave it marked as unread. they are different statuses that have nothing to do with each other. what you're talking about is combining the "delete" function with the "mark as read" function. they are separate for a reason. what you're saying is when you "mark as deleted" you also want to "mark as read" which could be a user option, but not one that is by default because they are not the same.
Which mail clients? I can only test with Thunderbird, but without a doubt it marks deleted messages as "seen" and futhermore does not restore the "unseen" flag if you undelete a message. I think a perfectly rational argument could be made for both cases, and that it depends solely on how you use/interpret the "new" flag. For some the act of deleting a message is enough to mark it as seen. To use an analogy, if I throw away a piece of snail mail unopened and my girlfriend asks me if I've seen it, my response would be "yeah, I saw it, and I threw it away."
In any case, given my opinion that it could go either way, I'm more interested in the consensus of other clients. Given a scenario where there are two "right" answers, I'd prefer to program the more popular "right" answer.
-Charles
I don't think it's a matter of what's right. Perhaps a dive into the RFCs could help us here. I don't know what to look for but the RFC can be seen here (IMAP 4v1): http://rfc.sunsite.dk/rfc/rfc2060.html Not sure if that will help anyone or not. But it doesn't mention anything about the UNSEEN flag or whatever being set or unset during deletion. At least not from what I see....
But I have no idea how to look at that .... :)
~Brett
In answer to some of the other questions about whether hiding the message when it hasn't been moved or permenantly deleted will mess other things up, the answer unfortunatly is that it will. The message count in the bottom and also the retrieving of new messages to maintain the proper number of messages in the list would both be borked by this.
This is a pretty critical issue, and one that I don't think is easily addressed. Therfore, I'm changing my proposal such that I now believe that the default style for deleted messages should not be hidden, but should instead be greyed or struck-out.
The hiding of messages seemed like a good idea because it preserved the status-quo, visually speaking, but it already required a couple of non-ideal work-arounds (read: minor cludge), and I don't think fiddling with the messagecount to account for stylesheets is a good idea.
So in conclusion, if you do not have a Trash folder defined, deleted messages will be flagged for deletion and will appear in that folder with a visible style such as greyed or line-through. The whole make delete-flagged messages invisble is a bad idea, I now believe.
-Charles
Charles McNulty wrote:
Which mail clients? I can only test with Thunderbird, but without a doubt it marks deleted messages as "seen" and futhermore does not restore the "unseen" flag if you undelete a message. I think a perfectly rational argument could be made for both cases, and that it depends solely on how you use/interpret the "new" flag. For some the act of deleting a message is enough to mark it as seen. To use an analogy, if I throw away a piece of snail mail unopened and my girlfriend asks me if I've seen it, my response would be "yeah, I saw it, and I threw it away." In any case, given my opinion that it could go either way, I'm more interested in the consensus of other clients. Given a scenario where there are two "right" answers, I'd prefer to program the more popular "right" answer.
-Charles
Thunder bird works as I described. Take a bunch of emails that are not read (i.e. still bold), highlight them all and delete them. they all move to the trash folder unread (i.e. the trash folder now has unread messages). good old terminal mail clients like mutt and pine do the same thing. there are separate flags for seen (i.e. read) and mark as deleted. for example in mutt, if you were to check your email after doing the described action above, you would see a bunch of emails in your inbox marked as deleted but not marked as read (there is no "unseen" flag). below are the flags allowed by the RFC, marking a message as deleted should do only that, other markings should be controlled by separate functions (unless explicitly optioned otherwise by the user).
2.3.2. Flags Message Attribute
A list of zero or more named tokens associated with the message. A
flag is set by its addition to this list, and is cleared by its
removal. There are two types of flags in IMAP4rev1. A flag of
either type may be permanent or session-only.
A system flag is a flag name that is pre-defined in this
specification. All system flags begin with "\". Certain system
flags (\Deleted and \Seen) have special semantics described
elsewhere. The currently-defined system flags are:
\Seen Message has been read
\Answered Message has been answered
\Flagged Message is "flagged" for urgent/special attention
\Deleted Message is "deleted" for removal by later EXPUNGE
\Draft Message has not completed composition (marked as a
draft).
\Recent Message is "recently" arrived in this mailbox. This
session is the first session to have been notified
about this message; subsequent sessions will not see
\Recent set for this message. This flag can not be
altered by the client.
If it is not possible to determine whether or not
this session is the first session to be notified
about a message, then that message SHOULD be
considered recent.
If multiple connections have the same mailbox
selected simultaneously, it is undefined which of
these connections will see newly-arrives messages
with \Recent set and which will see it without
\Recent set.
On Fri, 28 Apr 2006, Randy Noval wrote:
Thunder bird works as I described. Take a bunch of emails that are not read (i.e. still bold), highlight them all and delete them. they all move to the trash folder unread (i.e. the trash folder now has unread messages). good old terminal mail clients like mutt and pine do the same thing. there are separate flags for seen (i.e. read) and mark as deleted.
Yes, this is true in pine, but I never noticed because pine only
has one column to show deleted and unseen status, and deletion overrides the unseen. Also, pine doesn't bold folders that have unseen messages in it, so I am not distracted by it, whereas in RC, it annoys me that there is a bolded trash folder.
Randy Noval wrote:
Thunder bird works as I described. Take a bunch of emails that are not
:) It works as I described too! Wild! The option that determines it is Tools->Account Settings->Server Settings->"When I delete a message" if you change it to "Mark it as deleted" you'll be seeing what I'm seeing, which is that Thunderbird loses the "seen" flag.
My patch will make it perform exactly like Thunderbird, except that instead of a preference determining the behavior, the presense of the Trash folder determines it. When a message is moved to the Trash folder Seen status is maintained. When a message is marked as deleted, Seen status is lost.
-Charles
Charles McNulty wrote:
Randy Noval wrote:
Thunder bird works as I described. Take a bunch of emails that are not
:) It works as I described too! Wild! The option that determines it is Tools->Account Settings->Server Settings->"When I delete a message" if you change it to "Mark it as deleted" you'll be seeing what I'm seeing, which is that Thunderbird loses the "seen" flag.
My patch will make it perform exactly like Thunderbird, except that instead of a preference determining the behavior, the presense of the Trash folder determines it. When a message is moved to the Trash folder Seen status is maintained. When a message is marked as deleted, Seen status is lost.
-Charles
No, you're combining behaviors and removing the user's option to choose. For example, on the default install of thunderbird (what most people will use), that setting is not checked, though it is an option. An option is what it should remain because those features are functionally separate. If you don't want to be annoyed, you can change the option, but it makes no sense to combine functions for what should be a user determined preference. Just because it can work like you describe doesn't mean that it should be the default behavior.
Randy Noval wrote:
Charles McNulty wrote:
Randy Noval wrote:
Thunder bird works as I described. Take a bunch of emails that are not
:) It works as I described too! Wild! The option that determines it is Tools->Account Settings->Server Settings->"When I delete a message" if you change it to "Mark it as deleted" you'll be seeing what I'm seeing, which is that Thunderbird loses the "seen" flag.
My patch will make it perform exactly like Thunderbird, except that instead of a preference determining the behavior, the presense of the Trash folder determines it. When a message is moved to the Trash folder Seen status is maintained. When a message is marked as deleted, Seen status is lost.
-Charles
No, you're combining behaviors and removing the user's option to choose. For example, on the default install of thunderbird (what most people will use), that setting is not checked, though it is an option. An option is what it should remain because those features are functionally separate. If you don't want to be annoyed, you can change the option, but it makes no sense to combine functions for what should be a user determined preference. Just because it can work like you describe doesn't mean that it should be the default behavior.
Okay, so since we're talking options... why can't we just say this:
If there's a trash folder: Move to trash folder If there's not a trash folder: Mark as deleted
Now, a user-preference (checkbox) will define whether to mark it as "seen"/"read" or not. If it's checked, mark it read. If not, leave it as new.
Is that not an option?
Randy Noval wrote:
No, you're combining behaviors and removing the user's option to choose.
Agreed! Just like Thunderbird!
For example, on the default install of thunderbird (what most people will use), that setting is not checked, though it is an option. An
And in a default install of RC, most users will have a Trash folder defined (and the config will already be pointing at it) and again, RC will perform exactly the same as TB - maintaining the unread status and moving the message to the Trash folder.
RC is in desperate need of both a system for user options, and a point and click install process, but in the meantime what I'm advocating for (and programming) is increased functionality (ability to undelete messages when there isn't a Trash folder) and consistency with other e-mail clients.
-Charles
On Fri, 28 Apr 2006 15:54:44 -0400, Brett Patters - Roundcube Forum Admin brett@roundcubeforum.net wrote:
Okay, so since we're talking options... why can't we just say this:
If there's a trash folder: Move to trash folder If there's not a trash folder: Mark as deleted
This is exactly how it will work.
Now, a user-preference (checkbox) will define whether to mark it as "seen"/"read" or not. If it's checked, mark it read. If not, leave it as new.
Is that not an option?
Well, it's not an option in TB (that I can find, anyway), and while I'm not opposed to that as an option in RC per se, I think "configuation creep" can be a problem. That said, it's no skin off my neck, and I was already thinking of adding an option to allow "immediate delete" instead of "flag for delete" so I guess it's not a big deal to add another one.
These would be in the configuation file of course, not in the "Personal Settings" section.
-Charles
On Fri, 28 Apr 2006 15:18:00 -0400 (EDT), Jon Daley roundcube@jon.limedaley.com wrote:
Yes, this is true in pine, but I never noticed because pine only has one column to show deleted and unseen status, and deletion overrides the unseen. Also, pine doesn't bold folders that have unseen messages in it, so I am not distracted by it, whereas in RC, it annoys me that there is a bolded trash folder.
I find this very handy (folders with unseen mails in bold).
On Sat, 29 Apr 2006, Martin Marques wrote:
I find this very handy (folders with unseen mails in bold).
Yes, I agree, for the inbox, but not for the trash.
I guess there are lots of people who want it both ways, so I guess it will end up being an explicit configuration option - the problem with that is that RC gets more confusing for the user.
Okay, at long last here is the patch. I believe this is the final version (containing all of your helpful suggestions)
There are three new options:
read_when_deleted = TRUE by default (emulating Thunderbird) if true messages will be marked as read when they are deleted. if set to false messages will preserver their read/unread status
flag_for_deletion = TRUE by default. If set to true messages will be flagged for deletion rather than deleted outright IF AND ONLY IF there is no Trash folder present
javascript_config = array('read_when_deleted', 'flag_for_deletion') This is an array of options that will be available in javascript. To reference them in Javascript simply call: this.env.flag_for_deletion (for instance)
Deleting messages will now behave thusly: If you have a Trash folder: Messages will always go into the Trash folder and will maintain their read/unread status
If you do not have a Trash Folder: If you are not in the Trash folder AND flag_for_deletion = TRUE Messages will be flagged for deletion If read_when_deleted = TRUE message will be set to SEEN If you are in the Trash folder OR flag_for_deletion = FALSE Messages will be deleted immediately.
I think that's about it! Let me know if you have any problems with the patch.
-Charles
? delete.patch ? log ? config/db.inc.php ? config/main.inc.php ? logs/error.log ? program/js/DP_Debug.js ? program/js/diff.patch ? temp/733216469445435dd61a9e ? temp/894471295445435a64469d ? temp/ae8f4077551837a4ccf4a06f9ea3d3d3 Index: index.php =================================================================== RCS file: /cvsroot/roundcubemail/roundcubemail/index.php,v retrieving revision 1.38 diff -b -B -c -r1.38 index.php Index: config/main.inc.php.dist =================================================================== RCS file: /cvsroot/roundcubemail/roundcubemail/config/main.inc.php.dist,v retrieving revision 1.28 diff -b -B -c -r1.28 main.inc.php.dist *** config/main.inc.php.dist 13 Apr 2006 18:23:48 -0000 1.28 --- config/main.inc.php.dist 1 May 2006 15:38:15 -0000
*** 132,137 **** --- 132,146 ---- // This will make the application run slower $rcmail_config['skip_deleted'] = FALSE;
- // Set true to Mark deleted messages as read as well as deleted
- // False means that a message's read status is not affected by marking it as deleted
- $rcmail_config['read_when_deleted'] = TRUE;
- // When a Trash folder is not present and a message is deleted, flag
- // the message for deletion rather than deleting it immediately. Setting this to
- // false causes deleted messages to be permanantly removed if there is no Trash folder
- $rcmail_config['flag_for_deletion'] = TRUE;
- // path to a text file which will be added to each sent message // paths are relative to the RoundCube root folder $rcmail_config['generic_message_footer'] = '';
*** 180,185 **** --- 189,196 ---- // default sort order $rcmail_config['message_sort_order'] = 'DESC';
// list of configuration option names that need to be available in Javascript.
$rcmail_config['javascript_config'] = array('read_when_deleted', 'flag_for_deletion');
/***** try to load host-specific configuration *****/
Index: program/include/main.inc
RCS file: /cvsroot/roundcubemail/roundcubemail/program/include/main.inc,v retrieving revision 1.50 diff -b -B -c -r1.50 main.inc *** program/include/main.inc 13 Apr 2006 18:23:44 -0000 1.50 --- program/include/main.inc 1 May 2006 15:38:15 -0000
*** 317,322 **** --- 314,323 ---- $javascript = "var $JS_OBJECT_NAME = new rcube_webmail();\n"; $javascript .= "$JS_OBJECT_NAME.set_env('comm_path', '$COMM_PATH');\n";
- foreach ($CONFIG['javascript_config'] as $js_config_var){
$javascript .= "$JS_OBJECT_NAME.set_env('$js_config_var', '" . $CONFIG[$js_config_var] . "');\n";- }
- if (!empty($GLOBALS['_framed'])) $javascript .= "$JS_OBJECT_NAME.set_env('framed', true);\n";
Index: program/include/rcube_imap.inc
RCS file: /cvsroot/roundcubemail/roundcubemail/program/include/rcube_imap.inc,v retrieving revision 1.34 diff -b -B -c -r1.34 rcube_imap.inc *** program/include/rcube_imap.inc 27 Mar 2006 19:07:13 -0000 1.34 --- program/include/rcube_imap.inc 1 May 2006 15:38:15 -0000
*** 934,951 ****
// set message flag to one or several messages
! // possible flgs are: SEEN, DELETED, RECENT, ANSWERED, DRAFT function set_flag($uids, $flag) { $flag = strtoupper($flag); $msg_ids = array(); if (!is_array($uids)) ! $uids = array($uids);
! foreach ($uids as $uid) $msg_ids[$uid] = $this->_uid2id($uid);
! if ($flag=='UNSEEN') $result = iil_C_Unseen($this->conn, $this->mailbox, join(',', array_values($msg_ids))); else $result = iil_C_Flag($this->conn, $this->mailbox, join(',', array_values($msg_ids)), $flag); --- 934,954 ----
// set message flag to one or several messages
! // possible flags are: SEEN, UNDELETED, DELETED, RECENT, ANSWERED, DRAFT function set_flag($uids, $flag) { $flag = strtoupper($flag); $msg_ids = array(); if (!is_array($uids)) ! $uids = explode(',',$uids);
! foreach ($uids as $uid) { $msg_ids[$uid] = $this->_uid2id($uid);
}
! if ($flag=='UNDELETED') ! $result = iil_C_Undelete($this->conn, $this->mailbox, join(',', array_values($msg_ids))); ! else if ($flag=='UNSEEN') $result = iil_C_Unseen($this->conn, $this->mailbox, join(',', array_values($msg_ids))); else $result = iil_C_Flag($this->conn, $this->mailbox, join(',', array_values($msg_ids)), $flag); Index: program/js/app.js =================================================================== RCS file: /cvsroot/roundcubemail/roundcubemail/program/js/app.js,v retrieving revision 1.40 diff -b -B -c -r1.40 app.js *** program/js/app.js 24 Apr 2006 16:15:16 -0000 1.40 --- program/js/app.js 1 May 2006 15:38:16 -0000
*** 29,34 **** --- 28,34 ---- this.gui_objects = new Object(); this.commands = new Object(); this.selection = new Array();
this.last_selected = 0;
// create public reference to myself rcube_webmail_client = this;
*** 118,124 **** { msg_list_frame.onmousedown = function(e){return rcube_webmail_client.click_on_list(e);}; this.init_messagelist(msg_list); ! this.enable_command('markread', true); }
// enable mail commands
--- 118,124 ---- { msg_list_frame.onmousedown = function(e){return rcube_webmail_client.click_on_list(e);}; this.init_messagelist(msg_list); ! this.enable_command('toggle_status', true); }
// enable mail commands
*** 288,313 ****
this.use_arrow_key = function(keyCode, mod_key, msg_list_frame) {
var scroll_to = 0;
var last_selected_row = this.list_rows[this.last_selected];if (keyCode == 40) { // down arrow key pressed
! var new_row = last_selected_row.obj.nextSibling;
! while (new_row && new_row.nodeType != 1) {
! new_row = new_row.nextSibling;
! }
if (!new_row) return false;
scroll_to = (Number(new_row.offsetTop) + Number(new_row.offsetHeight)) - Number(msg_list_frame.offsetHeight);
} else if (keyCode == 38) { // up arrow key pressed
! var new_row = last_selected_row.obj.previousSibling;
! while (new_row && new_row.nodeType != 1) {
! new_row = new_row.previousSibling;
! }
if (!new_row) return false;
scroll_to = new_row.offsetTop;
} else {return true;}
! if (mod_key != CONTROL_KEY)
! this.select_row(new_row.uid,mod_key);
if (((Number(new_row.offsetTop)) < (Number(msg_list_frame.scrollTop))) ||
((Number(new_row.offsetTop) + Number(new_row.offsetHeight)) > (Number(msg_list_frame.scrollTop) + Number(msg_list_frame.offsetHeight)))) {
--- 288,304 ----
this.use_arrow_key = function(keyCode, mod_key, msg_list_frame) {
var scroll_to = 0;
if (keyCode == 40) { // down arrow key pressed
! new_row = this.get_next_row();
if (!new_row) return false;
scroll_to = (Number(new_row.offsetTop) + Number(new_row.offsetHeight)) - Number(msg_list_frame.offsetHeight);
} else if (keyCode == 38) { // up arrow key pressed
! new_row = this.get_prev_row();
if (!new_row) return false;
scroll_to = new_row.offsetTop;
} else {return true;}
! this.select_row(new_row.uid,mod_key,true);
if (((Number(new_row.offsetTop)) < (Number(msg_list_frame.scrollTop))) ||
((Number(new_row.offsetTop) + Number(new_row.offsetHeight)) > (Number(msg_list_frame.scrollTop) + Number(msg_list_frame.offsetHeight)))) {
*** 355,360 **** --- 346,352 ----
this.message_rows[uid] = {id:row.id, obj:row,
classname:row.className,
deleted:this.env.messages[uid] ? this.env.messages[uid].deleted : null, unread:this.env.messages[uid] ? this.env.messages[uid].unread : null, replied:this.env.messages[uid] ? this.env.messages[uid].replied : null};
*** 370,376 ****
{
msg_icon.id = 'msgicn_'+uid;
msg_icon._row = row;
! msg_icon.onmousedown = function(e) { rcube_webmail_client.command('markread', this); };
// get message icon and save original icon src
this.message_rows[uid].icon = msg_icon;
--- 362,368 ----
{
msg_icon.id = 'msgicn_'+uid;
msg_icon._row = row;
! msg_icon.onmousedown = function(e) { rcube_webmail_client.command('toggle_status', this); };
// get message icon and save original icon src
this.message_rows[uid].icon = msg_icon;
*** 731,739 ****
case 'delete':
// mail task
! if (this.task=='mail' && this.env.trash_mailbox && String(this.env.mailbox).toLowerCase()!=String(this.env.trash_mailbox).toLowerCase()) ! this.move_messages(this.env.trash_mailbox); ! else if (this.task=='mail') this.delete_messages(); // addressbook task else if (this.task=='addressbook') --- 723,729 ----
case 'delete':
// mail task
! if (this.task=='mail') this.delete_messages(); // addressbook task else if (this.task=='addressbook')
*** 750,756 **** this.move_messages(props); break;
! case 'markread': if (props && !props._row) break;
--- 740,746 ---- this.move_messages(props); break;
! case 'toggle_status': if (props && !props._row) break;
*** 761,769 **** { uid = props._row.uid; this.dont_select = true;
// toggle read/unread
! if (!this.message_rows[uid].unread) flag = 'unread'; }
--- 751,760 ---- { uid = props._row.uid; this.dont_select = true; // toggle read/unread ! if (this.message_rows[uid].deleted) { ! flag = 'undelete'; ! } else if (!this.message_rows[uid].unread) flag = 'unread'; }
*** 1111,1117 **** if (!this.in_selection_before) { var mod_key = this.get_modifier(e); ! this.select_row(id,mod_key); }
if (this.selection.length)
--- 1102,1108 ---- if (!this.in_selection_before) { var mod_key = this.get_modifier(e); ! this.select_row(id,mod_key,false); }
if (this.selection.length)
*** 1139,1145 ****
// unselects currently selected row
if (!this.drag_active && this.in_selection_before==id)
! this.select_row(id,mod_key);
this.drag_start = false;
this.in_selection_before = false;
--- 1130,1136 ----
// unselects currently selected row
if (!this.drag_active && this.in_selection_before==id)
! this.select_row(id,mod_key,false);
this.drag_start = false;
this.in_selection_before = false;
*** 1213,1218 **** --- 1204,1228 ---- /********* (message) list functionality *********/ /*********************************************************/
- // get next and previous rows that are not hidden
- this.get_next_row = function(){
var last_selected_row = this.list_rows[this.last_selected];var new_row = last_selected_row.obj.nextSibling;while (new_row && (new_row.nodeType != 1 || new_row.style.display == 'none')) {new_row = new_row.nextSibling;}return new_row;- }
- this.get_prev_row = function(){
var last_selected_row = this.list_rows[this.last_selected];var new_row = last_selected_row.obj.previousSibling;while (new_row && (new_row.nodeType != 1 || new_row.style.display == 'none')) {new_row = new_row.previousSibling;}return new_row;- }
- // highlight/unhighlight a row this.highlight_row = function(id, multiple) {
*** 1259,1265 ****
// selects or unselects the proper row depending on the modifier key pressed ! this.select_row = function(id,mod_key) { if (!mod_key) { this.shift_start = id; this.highlight_row(id, false); --- 1269,1275 ----
// selects or unselects the proper row depending on the modifier key pressed ! this.select_row = function(id,mod_key,with_mouse) { if (!mod_key) { this.shift_start = id; this.highlight_row(id, false);
*** 1270,1275 **** --- 1280,1286 ---- break; } case CONTROL_KEY: { this.shift_start = id;
if (!with_mouse) this.highlight_row(id, true); break; }
*** 1283,1289 **** --- 1294,1302 ---- } } }
if (this.last_selected != 0) { this.set_classname(this.list_rows[this.last_selected].obj, 'focused', false);} this.last_selected = id;
this.set_classname(this.list_rows[id].obj, 'focused', true);};
this.shift_select = function(id, control) {
*** 1388,1393 **** --- 1401,1407 ---- // list messages of a specific mailbox this.list_mailbox = function(mbox, page, sort) {
this.last_selected = 0; var add_url = ''; var target = window;
*** 1526,1531 **** --- 1540,1549 ---- if (this.message_rows[id].obj) this.message_rows[id].obj.style.display = 'none'; }
next_row = this.get_next_row();prev_row = this.get_prev_row();new_row = (next_row) ? next_row : prev_row;this.select_row(new_row.uid,false,false); } var lock = false;
*** 1541,1550 **** this.http_request('moveto', '_uid='+a_uids.join(',')+'&_mbox='+escape(this.env.mailbox)+'&_target_mbox='+escape(mbox)+'&_from='+(this.env.action ? this.env.action : ''), lock); };
! ! // delete selected messages from the current mailbox ! this.delete_messages = function() ! { // exit if no mailbox specified or if selection is empty if (!(this.selection.length || this.env.uid)) return; --- 1559,1565 ---- this.http_request('moveto', '_uid='+a_uids.join(',')+'&_mbox='+escape(this.env.mailbox)+'&_target_mbox='+escape(mbox)+'&_from='+(this.env.action ? this.env.action : ''), lock); };
! this.permanently_remove_messages = function() { // exit if no mailbox specified or if selection is empty if (!(this.selection.length || this.env.uid)) return;
*** 1566,1574 **** --- 1581,1620 ---- this.message_rows[id].obj.style.display = 'none'; } }
next_row = this.get_next_row();prev_row = this.get_prev_row();new_row = (next_row) ? next_row : prev_row;this.select_row(new_row.uid,false,false); // send request to server this.http_request('delete', '_uid='+a_uids.join(',')+'&_mbox='+escape(this.env.mailbox)+'&_from='+(this.env.action ? this.env.action : ''));}
// delete selected messages from the current mailbox
this.delete_messages = function()
{// exit if no mailbox specified or if selection is emptyif (!(this.selection.length || this.env.uid))return;// if there is a trash mailbox defined and we're not currently in it:if (this.env.trash_mailbox && String(this.env.mailbox).toLowerCase()!=String(this.env.trash_mailbox).toLowerCase())this.move_messages(this.env.trash_mailbox);// if there is a trash mailbox defined but we *are* in it:else if (this.env.trash_mailbox && String(this.env.mailbox).toLowerCase() == String(this.env.trash_mailbox).toLowerCase())this.permanently_remove_messages();// if there isn't a defined trash mailbox and the config is set to flag for deletionelse if (!this.env.trash_mailbox && this.env.flag_for_deletion) {this.mark_message('delete');next_row = this.get_next_row();prev_row = this.get_prev_row();new_row = (next_row) ? next_row : prev_row;this.select_row(new_row.uid,false,false);// if there isn't a defined trash mailbox and the config is set NOT to flag for deletion}else if (!this.env.trash_mailbox && !this.env.flag_for_deletion) {this.permanently_remove_messages();}return;};
*** 1588,1600 **** { id = this.selection[n]; a_uids[a_uids.length] = id;
// 'remove' message row from list (just hide it)if (this.message_rows[id].obj)this.message_rows[id].obj.style.display = 'none'; } } // mark all message rows as read/unread var icn_src; for (var i=0; i<a_uids.length; i++)
--- 1634,1657 ---- { id = this.selection[n]; a_uids[a_uids.length] = id; } }
switch (flag) {case 'read':case 'unread':this.toggle_read_status(flag,a_uids);break;case 'delete':case 'undelete':this.toggle_delete_status(flag,a_uids);break;}// send request to serverthis.http_request('mark', '_uid='+a_uids.join(',')+'&_flag='+flag);};// set class to read/unread
this.toggle_read_status = function(flag, a_uids) { // mark all message rows as read/unread var icn_src; for (var i=0; i<a_uids.length; i++)
*** 1627,1637 **** this.message_rows[uid].icon.src = icn_src; } }
! // send request to server ! this.http_request('mark', '_uid='+a_uids.join(',')+'&_flag='+flag); ! };
/*********************************************************/
--- 1684,1731 ---- this.message_rows[uid].icon.src = icn_src; } }
- }
! // mark all message rows as deleted/undeleted
! this.toggle_delete_status = function(flag, a_uids) {
! if (this.env.read_when_deleted) {
! this.toggle_read_status('read',a_uids);
! }
!
! var icn_src;
! for (var i=0; i<a_uids.length; i++)
! {
! uid = a_uids[i];
! if (this.message_rows[uid])
! {
! this.message_rows[uid].deleted = (flag=='undelete' ? false : true);
!
! if (this.message_rows[uid].classname.indexOf('deleted')<0 && this.message_rows[uid].deleted)
! {
! this.message_rows[uid].classname += ' deleted';
! this.set_classname(this.message_rows[uid].obj, 'deleted', true);
!
! if (this.env.deletedicon)
! icn_src = this.env.deletedicon;
! }
! else if (!this.message_rows[uid].deleted)
! {
! this.message_rows[uid].classname = this.message_rows[uid].classname.replace(/\s*deleted/, '');
! this.set_classname(this.message_rows[uid].obj, 'deleted', false);
!
! if (this.message_rows[uid].unread && this.env.unreadicon)
! icn_src = this.env.unreadicon;
! else if (this.message_rows[uid].replied && this.env.repliedicon)
! icn_src = this.env.repliedicon;
! else if (this.env.messageicon)
! icn_src = this.env.messageicon;
! }
if (this.message_rows[uid].icon && icn_src)this.message_rows[uid].icon.src = icn_src;}}}
/*********************************************************/
*** 2656,2662 **** var rowcount = tbody.rows.length; var even = rowcount%2;
! this.env.messages[uid] = {replied:flags.replied?1:0, unread:flags.unread?1:0};
var row = document.createElement('TR');
--- 2750,2757 ---- var rowcount = tbody.rows.length; var even = rowcount%2;
! this.env.messages[uid] = {deleted:flags.deleted?1:0, ! replied:flags.replied?1:0, unread:flags.unread?1:0};
var row = document.createElement('TR');
*** 2666,2673 **** if (this.in_selection(uid)) row.className += ' selected';
! var icon = flags.unread && this.env.unreadicon ? this.env.unreadicon : ! (flags.replied && this.env.repliedicon ? this.env.repliedicon : this.env.messageicon);
var col = document.createElement('TD');
col.className = 'icon';
--- 2761,2769 ---- if (this.in_selection(uid)) row.className += ' selected';
! var icon = flags.deleted && this.env.deletedicon ? this.env.deletedicon: ! (flags.unread && this.env.unreadicon ? this.env.unreadicon : ! (flags.replied && this.env.repliedicon ? this.env.repliedicon : this.env.messageicon));
var col = document.createElement('TD');
col.className = 'icon';
Index: program/js/common.js
RCS file: /cvsroot/roundcubemail/roundcubemail/program/js/common.js,v retrieving revision 1.7 diff -b -B -c -r1.7 common.js Index: program/lib/imap.inc =================================================================== RCS file: /cvsroot/roundcubemail/roundcubemail/program/lib/imap.inc,v retrieving revision 1.18 diff -b -B -c -r1.18 imap.inc *** program/lib/imap.inc 27 Mar 2006 19:06:30 -0000 1.18 --- program/lib/imap.inc 1 May 2006 15:38:17 -0000
*** 1468,1474 ****
function iil_C_ModFlag(&$conn, $mailbox, $messages, $flag, $mod){ if ($mod!="+" && $mod!="-") return -1;
- $fp = $conn->fp; $flags=array( "SEEN"=>"\Seen",
--- 1468,1473 ---- Index: program/steps/mail/func.inc =================================================================== RCS file: /cvsroot/roundcubemail/roundcubemail/program/steps/mail/func.inc,v retrieving revision 1.32 diff -b -B -c -r1.32 func.inc *** program/steps/mail/func.inc 6 Apr 2006 17:35:04 -0000 1.32 --- program/steps/mail/func.inc 1 May 2006 15:38:22 -0000
*** 390,395 **** --- 390,397 ---- $zebra_class = $i%2 ? 'even' : 'odd';
// set messag attributes to javascript array
if ($header->deleted)$js_row_arr['deleted'] = true; if (!$header->seen) $js_row_arr['unread'] = true; if ($header->answered)
*** 394,402 **** $js_row_arr['unread'] = true; if ($header->answered) $js_row_arr['replied'] = true;
- // set message icon
! if ($attrib['unreadicon'] && !$header->seen)
$message_icon = $attrib['unreadicon'];
else if ($attrib['repliedicon'] && $header->answered)
$message_icon = $attrib['repliedicon'];
--- 396,405 ----
$js_row_arr['unread'] = true;
if ($header->answered)
$js_row_arr['replied'] = true;
// set message icon
! if ($attrib['deletedicon'] && $header->deleted)
! $message_icon = $attrib['deletedicon'];
! else if ($attrib['unreadicon'] && !$header->seen)
$message_icon = $attrib['unreadicon'];
else if ($attrib['repliedicon'] && $header->answered)
$message_icon = $attrib['repliedicon'];
*** 456,461 **** --- 459,466 ----
if ($attrib['messageicon'])
$javascript .= sprintf("%s.set_env('messageicon', '%s%s');\n", $JS_OBJECT_NAME, $skin_path, $attrib['messageicon']);
- if ($attrib['deletedicon'])
if ($attrib['unreadicon']) $javascript .= sprintf("%s.set_env('unreadicon', '%s%s');\n", $JS_OBJECT_NAME, $skin_path, $attrib['unreadicon']); if ($attrib['repliedicon'])$javascript .= sprintf("%s.set_env('deletedicon', '%s%s');\n", $JS_OBJECT_NAME, $skin_path, $attrib['deletedicon']);
*** 510,521 **** $a_msg_cols[$col] = $cont; }
$a_msg_flags['unread'] = $header->seen ? 0 : 1;
$a_msg_flags['replied'] = $header->answered ? 1 : 0;
if ($header->deleted)$a_msg_flags['deleted'] = 1;- $commands .= sprintf("this.add_message_row(%s, %s, %s, %b, %b);\n", $header->uid, array2js($a_msg_cols),
--- 515,523 ---- $a_msg_cols[$col] = $cont; }
$a_msg_flags['deleted'] = $header->deleted ? 1 : 0; $a_msg_flags['unread'] = $header->seen ? 0 : 1; $a_msg_flags['replied'] = $header->answered ? 1 : 0; $commands .= sprintf("this.add_message_row(%s, %s, %s, %b, %b);\n", $header->uid, array2js($a_msg_cols),
Index: program/steps/mail/mark.inc
RCS file: /cvsroot/roundcubemail/roundcubemail/program/steps/mail/mark.inc,v retrieving revision 1.2 diff -b -B -c -r1.2 mark.inc *** program/steps/mail/mark.inc 28 Sep 2005 22:28:04 -0000 1.2 --- program/steps/mail/mark.inc 1 May 2006 15:38:22 -0000
*** 21,35 ****
$REMOTE_REQUEST = TRUE;
! $a_flags_map = array('read' => 'SEEN', 'unread' => 'UNSEEN');
if ($_GET['_uid'] && $_GET['_flag'])
{
$flag = $a_flags_map[$_GET['_flag']] ? $a_flags_map[$_GET['_flag']] : strtoupper($_GET['_flag']);
$marked = $IMAP->set_flag($_GET['_uid'], $flag);
!
! if ($marked)
{
$mbox = $IMAP->get_mailbox_name();
$commands = sprintf("this.set_unread_count('%s', %d);\n", $mbox, $IMAP->messagecount($mbox, 'UNSEEN'));
--- 21,36 ----
$REMOTE_REQUEST = TRUE;
! $a_flags_map = array('undelete' => 'UNDELETED', ! 'delete' => 'DELETED', ! 'read' => 'SEEN', 'unread' => 'UNSEEN');
if ($_GET['_uid'] && $_GET['_flag']) { $flag = $a_flags_map[$_GET['_flag']] ? $a_flags_map[$_GET['_flag']] : strtoupper($_GET['_flag']); $marked = $IMAP->set_flag($_GET['_uid'], $flag); ! if ($marked != -1) { $mbox = $IMAP->get_mailbox_name(); $commands = sprintf("this.set_unread_count('%s', %d);\n", $mbox, $IMAP->messagecount($mbox, 'UNSEEN')); Index: skins/default/mail.css =================================================================== RCS file: /cvsroot/roundcubemail/roundcubemail/skins/default/mail.css,v retrieving revision 1.19 diff -b -B -c -r1.19 mail.css *** skins/default/mail.css 4 Apr 2006 21:41:22 -0000 1.19 --- skins/default/mail.css 1 May 2006 15:38:22 -0000
*** 446,451 **** --- 446,457 ---- background-color: #CC3333; }
- #messagelist tr.focused td
- {
- border-bottom: thin dotted;
- border-top: thin dotted;
- }
- #messagelist tr.selected td a.rcmContactAddress { color: #FFFFFF;
Index: skins/default/templates/mail.html
RCS file: /cvsroot/roundcubemail/roundcubemail/skins/default/templates/mail.html,v retrieving revision 1.11 diff -b -B -c -r1.11 mail.html *** skins/default/templates/mail.html 23 Mar 2006 22:32:47 -0000 1.11 --- skins/default/templates/mail.html 1 May 2006 15:38:23 -0000
*** 46,51 **** --- 46,52 ---- summary="Message list" messageIcon="/images/icons/dot.png" unreadIcon="/images/icons/unread.png"
- deletedIcon="/images/icons/folder-trash.png"
repliedIcon="/images/icons/replied.png"
attachmentIcon="/images/icons/attachment.png" />
</div>
Auke Kok wrote:
On Thu, 27 Apr 2006 13:30:40 -0700, Andrew Fladmark afladmark@orbital-web.com wrote:
On Thu, 27 Apr 2006 16:50:21 +0000, Auke Kok sofar@foo-projects.org wrote:
sourceforge's webcvs doesn't show any of these changes. did you guys
swap
to subversion or another repository???
Auke
There appears to be an issue with the WebCVS. There have been a number of changes submitted sucessfully to the CVS, which are there, but nothing has appeared as changed in WebCVS for a little over a month now.
oh the joy that is sourceforge CVS!
as of today, when I CVS up I still do not get any new changes (I actually did a cvs up -r HEAD to make sure I'm not on some weird tag).
cvs2cl.pl shows the last commit seen:
2006-03-27 21:00 roundcube
* skins/default/templates/login.html: Fixed XHTML validation issue
that's over 5 weeks old.
can someone explain this? it's really frustrating that we can't see what is happening =)
Auke
Auke Kok wrote:
Auke Kok wrote:
On Thu, 27 Apr 2006 13:30:40 -0700, Andrew Fladmark afladmark@orbital-web.com wrote:
On Thu, 27 Apr 2006 16:50:21 +0000, Auke Kok sofar@foo-projects.org wrote:
sourceforge's webcvs doesn't show any of these changes. did you guys
swap
to subversion or another repository???
Auke
There appears to be an issue with the WebCVS. There have been a number of changes submitted sucessfully to the CVS, which are there, but nothing has appeared as changed in WebCVS for a little over a month now.
oh the joy that is sourceforge CVS!
as of today, when I CVS up I still do not get any new changes (I actually did a cvs up -r HEAD to make sure I'm not on some weird tag).
cvs2cl.pl shows the last commit seen:
2006-03-27 21:00 roundcube
* skins/default/templates/login.html: Fixed XHTML validationissue
that's over 5 weeks old.
can someone explain this? it's really frustrating that we can't see what is happening =)
Auke
Sourceforge CVS anonymous servers are apparently having issues.... it's been discussed before.... Not sure what the deal is, but SF has a very high load to deal with...
Brett Patters - Roundcube Forum Admin wrote:
Auke Kok wrote:
Auke Kok wrote:
On Thu, 27 Apr 2006 13:30:40 -0700, Andrew Fladmark afladmark@orbital-web.com wrote:
On Thu, 27 Apr 2006 16:50:21 +0000, Auke Kok sofar@foo-projects.org wrote:
sourceforge's webcvs doesn't show any of these changes. did you guys
swap
to subversion or another repository???
Auke
There appears to be an issue with the WebCVS. There have been a number of changes submitted sucessfully to the CVS, which are there, but nothing has appeared as changed in WebCVS for a little over a month now.
oh the joy that is sourceforge CVS!
as of today, when I CVS up I still do not get any new changes (I actually did a cvs up -r HEAD to make sure I'm not on some weird tag).
cvs2cl.pl shows the last commit seen:
2006-03-27 21:00 roundcube
* skins/default/templates/login.html: Fixed XHTML validationissue
that's over 5 weeks old.
can someone explain this? it's really frustrating that we can't see what is happening =)
Auke
Sourceforge CVS anonymous servers are apparently having issues.... it's been discussed before.... Not sure what the deal is, but SF has a very high load to deal with...
which is inacceptable and utterly frustrating development if you ask me - for the same reason I took all my projects away from SF 3 years ago and they still haven't fixed it.
so
do you guys need a svn server? I'm already maintaining one for +- 12 projects so I can take on the load, willing to do the useradmin and cvs2svn conversion etc etc.
/me dusts off the dev cvs login he has somewhere
Auke
Auke Kok wrote:
Brett Patters - Roundcube Forum Admin wrote:
Sourceforge CVS anonymous servers are apparently having issues.... it's been discussed before.... Not sure what the deal is, but SF has a very high load to deal with...
which is inacceptable and utterly frustrating development if you ask me
- for the same reason I took all my projects away from SF 3 years ago
and they still haven't fixed it.
so
do you guys need a svn server? I'm already maintaining one for +- 12 projects so I can take on the load, willing to do the useradmin and cvs2svn conversion etc etc.
/me dusts off the dev cvs login he has somewhere
which doesn't work because I can't write the lock (I'm not in the roundcube dev group obviously, only in others).
guys, I'm almost begging you here, please ditch sourceforge or start posting cvs snapshots on a weekly (?) basis, so we can actually *attempt* to follow development of roundcube and feedback.
Cheers,
Auke
On Mon, 01 May 2006 21:23:12 -0700, Auke Kok sofar@foo-projects.org wrote:
Auke Kok wrote:
Brett Patters - Roundcube Forum Admin wrote:
Sourceforge CVS anonymous servers are apparently having issues.... it's been discussed before.... Not sure what the deal is, but SF has a very high load to deal with...
which is inacceptable and utterly frustrating development if you ask me
- for the same reason I took all my projects away from SF 3 years ago
and they still haven't fixed it.
so
do you guys need a svn server? I'm already maintaining one for +- 12 projects so I can take on the load, willing to do the useradmin and cvs2svn conversion etc etc.
/me dusts off the dev cvs login he has somewhere
which doesn't work because I can't write the lock (I'm not in the roundcube dev group obviously, only in others).
guys, I'm almost begging you here, please ditch sourceforge or start posting cvs snapshots on a weekly (?) basis, so we can actually *attempt* to follow development of roundcube and feedback.
Cheers,
Auke
Alternatively, move to the SourceForge SVN servers? They appear to be working quite well now, and definitely better than their anonymous CVS since the hardware failure they had :)
Just an idea.
-
Alan Briolat -
Andrew Fladmark -
Auke Kok -
Brett Patters - Roundcube Forum Admin -
Charles McNulty -
Darren Pilgrim -
David Collantes -
John Dennis -
Jon Daley -
Mark Bucciarelli -
Mark Edwards -
Martin Marques -
Randy Noval