Bug 2243 - put state configuration in a file separate from ~/.clawsrc
Summary: put state configuration in a file separate from ~/.clawsrc
Status: NEW
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Other (show other bugs)
Version: 3.7.6
Hardware: PC Linux
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2010-08-09 14:04 UTC by Dieter Plaetinck
Modified: 2010-08-22 12:46 UTC (History)
0 users

See Also:


Attachments

Description Dieter Plaetinck 2010-08-09 14:04:43 UTC
Hi,
when one looks at ~/.clawsrc, you can see that it contains:
1) settings defined/configured by the user
2) variables tracked by claws itself

I suggest to separate these 2.
Why? -> If you keep your home directory in a version controlled directory, you want to track your data and configuration.  So you add ~/.clawsrc to your repository so you can track your config.  But everytime you use claws, it will update ~/.clawsrc and store some state information like window sizes and positions.  This causes ~/.clawsrc to show up in things like `git status`, and it makes it harder to commit specific -wanted- changes.
It becomes especially hard when you use claws on multiple pc's and you want to share the config over them.  My pc's have different screen sizes so even when I autocommit these changes, I get a "ping pong" effect of irrelevant (to me) changes.  If the window sizes etc would be in a separate file, everybody would still be able to do what he did before, and people who use version control will be happier.

PS: this ticket does not interfere with ticket 2037 ("Claws Mail does not use XDG Folders").  Even if you follow the xdg spec, both "config from user" and "state" are topics which are stored in the .config directory when using xdg.  So you could still do the same splitup as suggested here.

Dieter
Comment 1 Ricardo Mones 2010-08-10 09:38:17 UTC
You can do it yourself, imagine for example a wrapper for claws-mail:

cd ~/.claws-mail/ # not really needed, just to avoid long paths below :)
test -f shareable || ./split-cm-rc clawsrc shareable local # first time
./merge-cm-rc shareable local > clawsrc
/usr/bin/claws-mail
./split-cm-rc ./clawsrc ./shareable ./local

This way you only need to sync shareable. Of course creating the split and merge scripts is left to you. I think perl and python have good ways to deal with ini-style files like clawsrc.
Comment 2 Holger Berndt 2010-08-10 09:49:06 UTC
I think he has a point, though. Having state saving cruft and config options at the same place is not ideal.
Comment 3 Ricardo Mones 2010-08-22 12:31:30 UTC
What is state and what is config depends on user's usage of the variables, and surely whatever division you make somebody could argue the opposite because of their own reasons.

Windows positions can be state for people with different screen sizes across desktops, but can be config for people with same screen sizes across desktops. Other could want positions to be config but sizes to be state...

If the point exists, it's very weak :)
Comment 4 Dieter Plaetinck 2010-08-22 12:46:35 UTC
@Ricardo: as you can see in my original post, I make the difference based on what the user explictly configures vs what claws does on its own.

Nowhere in claws is there a configuration setting for "make the claws window this big, or put it the window in this location".  It just happens automatically.  There is no way to be sure if the user considers this information state or configuration.

I see your point, but I don't see the problem with it.  If a user considers window size or position to be configuration then he will have no problem with the suggested approach anyway, and he can just commit the file into his VCS (if he uses a VCS)

Alternatively, you could make a checkbox in the claws configuration like "store window size/position into configuration?" if the user selects yes, you know he explicitly wants to track it in his config.  if the user selects no, you can consider it state information and track it in the separate file

Note You need to log in before you can comment on or make changes to this bug.