! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Mailwatch plugin does not save the folder preferences of an IMAP account
Status:
RESOLVED: FIXED
Product:
Xfce4-mailwatch-plugin
Component:
General

Comments

Description Moritz Heiber editbugs 2006-12-06 18:44:59 CET
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: 

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 ;-).

Reproducible: Always

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

Actual Results:  
The plugin does not remember i.e. save the configuration changes

Expected Results:  
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.
Comment 1 Brian J. Tarricone (not reading bugmail) 2006-12-06 21:12:48 CET
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.
Comment 2 Moritz Heiber editbugs 2006-12-06 21:56:50 CET
The logfiles are here:

http://foo-projects.org/~moe/firststart.txt
http://foo-projects.org/~moe/secondstart.txt

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)).
Comment 3 Brian J. Tarricone (not reading bugmail) 2006-12-06 22:07:36 CET
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.
Comment 4 Nick Schermer editbugs 2007-01-17 21:21:10 CET
If you add some code like this:

/* drop all the groups in the rc file before writing */
gchar **groups;
guint n;
groups = xfce_rc_get_groups (rc);
for (n = 0; groups[n] != NULL; ++n)
    xfce_rc_delete_group (rc, groups[n], TRUE);
g_strfreev (groups);

before writing the rc file, everything will be cleared.
Comment 5 Brian J. Tarricone (not reading bugmail) 2007-01-17 21:49:49 CET
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:

n_newmail_boxes=3
newmail_box0=foo
newmail_box1=bar
newmail_box2=quux

Then you remove 'bar' from the list in the GUI.  It gets saved and looks like this:

n_newmail_boxes=2
newmail_box0=foo
newmail_box1=quux
newmail_box2=quux

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.
Comment 6 Kemal Ilgar Eroglu 2007-12-25 21:15:28 CET
Hi,

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 */
  if (conffile)
    fclose(conffile);

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.
Comment 7 Kemal Ilgar Eroglu 2007-12-25 21:19:41 CET
By the way, I'm using XFCE 4.4.1 here, with Gtk+2 v2.10, Glib2 v2.12.12.
Comment 8 Brian J. Tarricone (not reading bugmail) 2008-08-30 08:45:24 CEST
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?

Bug #2647

Reported by:
Moritz Heiber
Reported on: 2006-12-06
Last modified on: 2011-02-26

People

Assignee:
Brian J. Tarricone (not reading bugmail)
CC List:
1 user

Version

Version:
1.1.0 or older
Target Milestone:
1.1.0 or older

Attachments

Additional information