User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
For me the folder preferences of an email account are not saved at all anymore. Once I create the configuration for a server it stays that way (like, we do it once, we do it right ;-).
Steps to Reproduce:
1. Create new account with the plugin
2. Check a few folders to inclusion in the mail watching process
3. Try to deselect one of the folders to exlude them from being checked for new email
The plugin does not remember i.e. save the configuration changes
The changes oughta be saved.
This is Xfce from svn running the latest available version of the panel and the plugin against GTK+-2.10.6 compiled with gcc 3.4.6.
I can't see any reason why this doesn't work... I added some debugging info, though. Can you svn up and compile with --enable-debug=yes? Then start the panel from a terminal, open up the mailwatch prefs dialog, mess with the new mail folders, and then close out *all* the settings dialogs. Attach the output here. If you want, also glance at ~/.config/xfce4/panel/mailwatch-*.rc to see what's getting saved. If there's more than one, you'll have to look in panels.xml to find the correct ID # for the config file.
The logfiles are here:
Now, the situation at 'firststart' is as follows: Three folders are being monitored. During the session I uncheck one of them (here it is lunar-commits). I exit all the preferences dialogs and I end the session.
So we advance to secondstart: There should only be two folders selected with the profile 'Doppio' yet that is not the case (debug output tells us that the plugin indeed reads three folders from the configuration and not just two).
I checked on the configuration in between starts and it had the old values assigned to the account (as if they had never been saved; yes, I made sure I took the right one (given the name appeared in the debug output)).
Gah, I think I know why. The XfceRc stuff doesn't clear out the file before writing new values, so if you *remove* an entry, it doesn't actually get removed, it just doesn't get written.
Except that I would think that, since the n_newmail_folders param gets updated correctly, and folders 0 through (n_newmail_folders-1) get rewritten, then even if there was something with a higher index, it wouldn't get read. Not sure about that, though. I need to check on it, but I don't have time right now.
If you add some code like this:
/* drop all the groups in the rc file before writing */
groups = xfce_rc_get_groups (rc);
for (n = 0; groups[n] != NULL; ++n)
xfce_rc_delete_group (rc, groups[n], TRUE);
before writing the rc file, everything will be cleared.
Right, it's worth a try, but I don't think that's the problem. Take this for example. Say the current contents are something like this:
Then you remove 'bar' from the list in the GUI. It gets saved and looks like this:
So the contents of the file aren't quite correct, but because *every* newmail_box# entry, as well as the n_newmail_boxes entry is re-saved when even one of them changes, even if there are extra entries, they won't be used.
I'm the author of the xfce4-timer-plugin and while working on a new version I realized that this bug affects my plugin, too. With timer plugin version 0.5.1, you can reproduce it as follows:
1) Add a few alarms in the preferences, say, with names a,b,and c, with that order. Close the preferences window.
2) Reopen the preferences and remove the first entry a, close the pref. window.
3) Restart the panel (or start a new XFCE session).
Result: The alarm list will list three entries: b,c and c.
Expected result: List only b and c.
I agree with Brian's post #3, it appears that the rc file isn't cleared before writing. So the "tail" from a longer previous version keeps sticking out, as explained in post #5.
My workaround for this in timer plugin version 0.6 is to do
conffile = fopen(file,"w"); /* this is the rc file */
before saving the configuration, so that the old contents are cleared.
This behaviour/bug could be resulting from the Glib functions to which XFCE relies on. In any case, I think this is certainly not the desired outcome and deserves a bugfix/workaround.
By the way, I'm using XFCE 4.4.1 here, with Gtk+2 v2.10, Glib2 v2.12.12.
Ok, I think I finally figured this out. It looks like even tho it reads the n_newmail_boxes param from the rc file, it doesn't actually use it for anything, so if there are stale entries in the file, they'll still get added to the list even if their index is greater than should be accepted because of n_newmail_boxes.
Can someone test current svn trunk and verify?