Created attachment 74258 [details] [review]
Tentative patch to fix this

This could be completely bogus.  I'm new to Gnome internals and have only a novice's understanding of how things go together, but this could be the problem if the suggested correction is correct.

The above patch works for me.

Still happening with GNOME 2.16.1, Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/evolution/+bug/65167

I'm not sure the patch is correct, it changes the widget for th mbox, mh, Maildir option and you might want to pick a mbox file

*** Bug 356908 has been marked as a duplicate of this bug. ***

I don't think changing the glade file is quite enough, when I patched the glade file with the abover correction I was still unable to proceed forward. The issue of files over folders is pointless anyway as even when selecting an mbox file the next button still doesn't become sensitive. There appears to be a few bugs which are part of this.

Indeed it isn't enough (though it did work). 

This would require modification to camel to make work properly, as camel just tells evo that it needs a path, it dosen't specify a file or folder.

We could modify evo to have path / file entry with a regular text box, but thats not a very userfriendly solution.

Should a bug be filed with GTK to have a file or folder chooser dialog added to the toolkit? This could be complicated to implement however, handling double clicks in the file/folder list and select operations this could end up being a user interface nightmare for GTK. 

Another solution would be to have a checkbox or radio button to select a mbox folder or mbox file, the chooser button changing depending on the selected option.

Does anyone know what the other bugs are relating to the prevention of moving forward in the process? I think that all of these issues should be catalogued here. 

PS. I don't actually need this functionality anymore but will keep upto date with the bug in case the problem that previously arose (re: thunderbird) does again.

Created attachment 75608 [details] [review]
Hacky patch

Another hack for fixing this, slightly more appropriate than changing the glade file. Still not perfect.

*** Bug 355202 has been marked as a duplicate of this bug. ***

Note that attachment #78002 [details] in bug #383842 is similar to the original proposed patch here but also fixes the width of the button.

I think a cleaner solution to the mbox problem is to break the "Standard Unix mbox spool or directory" server type choice into two separate choices (one for "spool", one for "directory").  Then add a new GtkFileChooserButton widget to the glade file.  Set the open mode for one as GTK_FILE_CHOOSER_ACTION_OPEN and the other as GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER, and have the "mbox spool" and "mbox directory" choices display the appropriate widget.

*** Bug 383842 has been marked as a duplicate of this bug. ***

Gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=133504

*** Bug 369381 has been marked as a duplicate of this bug. ***

*** Bug 416960 has been marked as a duplicate of this bug. ***

*** Bug 371185 has been marked as a duplicate of this bug. ***

*** Bug 428622 has been marked as a duplicate of this bug. ***

*** Bug 315391 has been marked as a duplicate of this bug. ***

from bug 315391:
Evo bug. If you want users to pick a directory, use SELECT_FOLDER mode.

Still happens with evolution 2.10.0 - why is this trivially to fix bug still around ???

It's not trivial to fix _correctly_.

Evolution uses the same file chooser widget to select MH-format mail directories, Maildir-format mail directories, standard UNIX mbox spools, and standard UNIX mbox directories.  The problem is that three of those cases require the file chooser widget to use GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER (pick a folder), the other requires GTK_FILE_CHOOSER_ACTION_OPEN (pick a file).  Unfortunately, Evolution's configuration design makes it difficult to switch the widget to the appropriate file selection mode on the fly.

So by simply switching the mode, you either fix three cases and break one, or fix one case and break three.  My patch chooses the lesser of two evils, but it would still be a regression for those using mbox spools.

The proper solution (comment #10) will require some Camel hacking.

*** Bug 433652 has been marked as a duplicate of this bug. ***

Created attachment 89056 [details] [review]
proposed patch 1/2

for evolution;

Created attachment 89057 [details] [review]
proposed patch 2/2

for evolution-data-server;

milan: could you try to stick to the coding guidelines?

if (){  should be:  if () {

also, there's no need to use braces if the if-statement only has one statement/line under it.

e.g.:

if (bool) {
   statement;
}

should be written as:

if (bool)
   statement;


it is, however, acceptable to use {}'s if you have something like these:


if (bool) {
   /* comment */
   statement;
}

or

if (bool) {
   statement;
} else {
   statement;
   statement;
}


(e.g. if the else-clause has more than a single line, it's nicer to also brace the then-clause - I'm just really strict about code style, it's a pet peve of mine - I can't help it)


anyways, other than style, the first patch looks fine.


as far as the second patch, the spoolfile uri is going to break existing user configurations. I don't think you need to change the protocol string, I think it'll Just Work if you leave it as "spool".


I guess the approach (adding a PATH_FILE bit) is fine (I can't think of a better solution).

Jeff, that's fine with coding style, I'm not still sure how to type correctly for evo. I'll correct it tomorrow.

The more worst thing is, it will not "Just Work", I've got a warning message that I'm trying register second provider for same protocol, and then I could see only one option in account editor, not both. So I decided to choose a name like this. But there could be some better name or solution. I realized now, "spool "? (A space at the end.)

ah, right. *smack* should have thought of that problem.

as far as using "spool ", that is probably a bad idea because it wouldn't conform to the syntax grammar for URIs.

hmm...

ok, this might be a usability no-no, but... what if we had:

PATH_FILE
PATH_DIR


Maildir would specify PATH_DIR. spool would specify PATH_FILE | PATH_DIR.

the ui could, if both bits are set, provide some UI radio button or checkbox or something that would signal to the filechooser dialog what type of path to expect.

would this work?

yes, it could. It's mentioned also in comment #7. My first approach got only less work, you know ;) I will try to extend that dialog and rutines in such way.

BTW, with that single line block with if-s, there is a rule that you never know what is hidden after a statement. It could be a function, but it could be a macro too, and that macro would contain more statements, and also other if-s, or it could be other block and so on. So it's safer to put into block even these sigle lines, much more when there is an else clause. I think it's Borland(r) Together(r) or some similar product, where code validation claim on such statements.

but there are no such macros in the gnome stack that are multiple statements that are not already wrapped in {}'s

gnome has a rule that if a macro is to contain multiple statements, that it use G_STMT_START { } G_STMT_END

Created attachment 89117 [details] [review]
proposed patch 1/2

for evolution-data-server;

Created attachment 89119 [details] [review]
proposed patch 2/2

for evolution;

I'm not sure if I did it in proper way, maybe there is other/better way how to do this. There is also one thing, about which I know but don't know how to solve properly, and it is: when you choose "Standard Unix mbox spool and directory" and you choose "select file" and then you change "Server type" on "Local delivery" (for example) then file choose button's action is changed properly to select directories, but the "OK" button is disabled. I've a feeling that there is some easiest way how to make this work than paste calling of any callback into on change callback of that server-type-combo. That could be trivial, but I don't know Camel enough to do it.

*** Bug 444181 has been marked as a duplicate of this bug. ***

*** Bug 447213 has been marked as a duplicate of this bug. ***

this is a blocker to me, as it blocks some basic functionality.

This bug is still in 2.11.3.

One request for the future:

If you have a solution in Gnome which is not the best but WORKS - DO NOT throw it out before you have a BETTER one! This was the case also with a menu editor for Gnome - there was a working solution which you throw out before having a new solution. And the result was: for some Gnome releases there was no menu editor at all - please correct me if I'm wrong.

If you write you had a text line for inserting a path manually that's better than using a solution which is NO solution. With current chooser I cannot use my maildir folder with thousands of e-mails...

Okay, after speaking with Varadhan... I think I've reconsidered your first approach as perhaps a better solution than my radio button idea.

My only change would be to make "spool://" refer to the spool files (your patch made it refer to spool directories) and make a new "spooldir://" for spool directories, instead, and use a PATH_DIR instead of PATH_FILE (this means MH and Maildir would need a slight update, but that's trivial)


as far as migration... there used to be a hook in the code to check version and call a "migration" code-path if needed... so it could scan for "spool://" accounts and stat() the path component, if it is a dir, just change the uri to spooldir://


Sorry about the back-and-forth, Milan.

Created attachment 90199 [details] [review]
proposed patch 1/2

for evolution-data-server;

added new flags CAMEL_URL_PART_PATH_DIR and CAMEL_URL_NEED_PATH_DIR and also added this CAMEL_URL_NEED_PATH_DIR to almost all local providers (except spool_file_provider).

Created attachment 90200 [details] [review]
proposed patch 2/2

for evolution;

using CAMEL_URL_NEED_PATH_DIR flag in editor; also migrating with versions 2.11.x and lower as Jeff suggested.

I think I should push this to 2.11.5. Varadhan/Matthew can one of you review and approve it?

One minor nit in the evolution patch:

"g_file_test (filename, G_FILE_TEST_IS_DIR)" is an easier way to test if a file is a directory than messing around with stat().

Otherwise it looks like a nice, clean solution.  Great job!  I'll build and test this for myself and then approve the patches if all goes well.

http://developer.gnome.org/doc/API/2.0/glib/glib-File-Utilities.html#g-file-test

If it will works for you, please change it then, it may be better then me to resubmit a "whole" patch. I will try to remember this, thanks for pointing me here, I only copied this from evolution-data-server's spool provider.

Poke 2.11.6?

there is a work around for this by editing:

.gconf/apps/evolution/%gconf.xml

during config inside evolution set to anyfilename.

exit evolution and whatever gconf sets that file.

*** Bug 463840 has been marked as a duplicate of this bug. ***

Milan, I'm having trouble installing a local Evolution build at the moment.  Your patches look good so I'm approving them in hopes of getting them in for Monday, but please give them a final round of testing before you commit.

e-d-s part committed to trunk. Committed revision 7943.
evo part committed to trunk. Committed revision 33995.

in evo part I only changed call to 'stat' with call to 'g_file_test' as Matt suggested in comment #39.

radhika: this probably requires a doc update?

"Standard Unix mbox spool file or directory" changed to "Standard Unix mbox spool file" and "Standard Unix mbox spool directory", right?

Is  

"Standard Unix Mbox Spool or Directory:If you want to read and store e-mail in the mail spool on your local system, choose this option. You need to provide the path to the mail spool you want to use. For configuration instructions, see “Local Configuration Options” on page 15."

should be changed to

Standard Unix mbox spool file and Standard Unix mbox spool directory:If you want to read and store e-mail in the mail spool on your local system, choose this option. You need to provide the path to the mail spool you want to use. For configuration instructions, see “Local Configuration Options” on page 15.

.............???

or 

Standard Unix mbox spool file:If you want to read and store e-mail in the mail spool on your local system, choose this option. You need to provide the path to the mail spool file you want to use. For configuration instructions, see “Local Configuration Options” on page 15.

Standard Unix mbox spool directory:If you want to read and store e-mail in the mail spool directory on your local system, choose this option. You need to provide the path to the mail spool directory you want to use. For configuration instructions, see “Local Configuration Options” on page 15.

(In reply to comment #47 and #48)

> Standard Unix mbox spool file:If you want to read and store e-mail in the mail
> spool on your local system, choose this option. You need to provide the path to
> the mail spool file you want to use. For configuration instructions, see
> “Local Configuration Options” on page 15.
> 
> Standard Unix mbox spool directory:If you want to read and store e-mail in the
> mail spool directory on your local system, choose this option. You need to
> provide the path to the mail spool directory you want to use. For configuration
> instructions, see “Local Configuration Options” on page 15.

i hope without the four typos.

??? 4 typos?

yes.

*** Bug 474745 has been marked as a duplicate of this bug. ***

*** Bug 485640 has been marked as a duplicate of this bug. ***

*** Bug 487596 has been marked as a duplicate of this bug. ***

*** Bug 489770 has been marked as a duplicate of this bug. ***

*** Bug 490333 has been marked as a duplicate of this bug. ***

*** Bug 493552 has been marked as a duplicate of this bug. ***

I can now **create** an account using a Unix spool file, using the entry "Standard Unix mbox spool file", but evolution doesn't receive any mail from it.  My $MBOX, /var/spool/mail/jonrysh, does in fact contain mail, some quite recent.  Clicking "Send / Receive", causes the progress box to flash for about 200 msec, but no mail is incorporated into the Evolution system.  

Questions:

(1) In the past, I was able to get Evolution working by editing the control file containing the location for the spool file from which the mail was to be fetched, but I am unable to remember the control file's location, and can't find in.  (And foolishly failed to make notes.)  Can anyone tell me where this control file is located?

(2) Is there any convenient way to get Evolution to log debug information?  evolution --debug doesn't record much.

Thanks - jon

Jonathan:
1) run gconf-editor and go to /apps/evolution/mail/accounts
2) http://www.gnome.org/projects/evolution/bugs.shtml#envvar

Thanks very much for the pointers.


I'm not familiar with gconf-editor, but it seems to indicate that the Unix spool file is set as follows:
   ...<url>spool:///var/spool/mail/jonrysh</url>...
which looks reasonable.  In my account:
$ echo $MAIL
/var/spool/mail/jonrysh


Running "CAMEL_DEBUG=all evolution >& evo.log" produces a large amount of output; the good part of which may be the following:
...
Thread 40a00950 >
Get folder info(0xacc3b0:spool:///var/spool/mail/jonrysh, '<null>') =
  uri: spool:///var/spool/mail/jonrysh#INBOX
  full_name: INBOX
  flags: 0000004a
  uri: spool:///var/spool/mail/jonrysh#.%23evolution/Trash
  full_name: .#evolution/Trash
  flags: 00000cf2
  uri: spool:///var/spool/mail/jonrysh#.%23evolution/Junk
  full_name: .#evolution/Junk
  flags: 000010f2
< 40a00950 >
Thread 42803950 >
CamelStore('mbox:/home/jonrysh/.evolution/mail/local'):get_folder('Inbox', 0) = 0x72ad10
< 42803950 >
Thread 40a00950 >
...

Evolution is still not picking up any mail.

It works for me, even in the log I have the spool:// listed more than in one thread, but I think it doesn't matter. Can you check, if you do not have any filter or something selected? When I added there new account, then new account appeared on the left of mail list, and when I expand it and click on "Inbox", then I see a mail, which is stored there. The mail doesn't appear under "On This Computer". (just in case)

*** Bug 502721 has been marked as a duplicate of this bug. ***

*** Bug 515676 has been marked as a duplicate of this bug. ***

*** Bug 432455 has been marked as a duplicate of this bug. ***

*** Bug 546884 has been marked as a duplicate of this bug. ***