After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 513951 - Centralize where Evolution's user data directory is defined
Centralize where Evolution's user data directory is defined
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: general
2.22.x (obsolete)
Other Linux
: Normal enhancement
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2008-02-02 20:15 UTC by Matthew Barnes
Modified: 2008-03-13 14:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch (20.16 KB, patch)
2008-02-02 20:15 UTC, Matthew Barnes
accepted-commit_after_freeze Details | Review
Patch based on Matthews, but with a static dirname and additional GConf Error checking (27.66 KB, patch)
2008-03-02 14:22 UTC, Tobias Mueller
reviewed Details | Review
Patch w/o g_assert()s (27.41 KB, patch)
2008-03-02 14:59 UTC, Tobias Mueller
committed Details | Review

Description Matthew Barnes 2008-02-02 20:15:06 UTC
Just some light refactoring work for something that was bothering me today.

There should be exactly one place in the code where we define where to put user data (currently $HOME/.evolution), so I added a new e-util function to provide that location:


  const gchar * e_get_user_data_dir (void)  [1]


I also changed the various xxx_component_peek_base_directory() functions to return a more useful result.  Whereas before they all returned the same as e_get_user_data_dir(), now they return a component-specific base directory:


  addressbook_component_peek_base_directory() : "$HOME/.evolution/addressbook"
  calendar_component_peek_base_directory()    : "$HOME/.evolution/calendar"
  mail_component_peek_base_directory()        : "$HOME/.evolution/mail"
  memos_component_peek_base_directory()       : "$HOME/.evolution/memos"
  tasks_component_peek_base_directory()       : "$HOME/.evolution/tasks"


The rest of the code has been adapted appropriately.


[1] cf. g_get_user_data_dir()
http://library.gnome.org/devel/glib/unstable/glib-Miscellaneous-Utility-Functions.html#g-get-user-data-dir
Comment 1 Matthew Barnes 2008-02-02 20:15:57 UTC
Created attachment 104274 [details] [review]
Proposed patch
Comment 2 Srinivasa Ragavan 2008-02-05 13:47:36 UTC
Target for 2.24. 

Looks fine otherwise.
Comment 3 André Klapper 2008-03-02 01:10:40 UTC
also see bug 519767 - would this fix bug 519767?
Comment 4 Matthew Barnes 2008-03-02 01:48:40 UTC
I don't think it will solve bug #519767 outright, but it might make the patch to fix it a little cleaner.
Comment 5 Matthew Barnes 2008-03-02 13:48:48 UTC
Muelli correctly pointed out that the 'dirname' variable in my e_get_user_data_dir() function should be static.  Good catch!
Comment 6 Tobias Mueller 2008-03-02 14:21:27 UTC
:)

So I cooked up a patch where the dirname is static. Also there is additional GConf error checking which has been in my working copy for long. I hope I didn't mess up other things ;-)
Comment 7 Tobias Mueller 2008-03-02 14:22:37 UTC
Created attachment 106384 [details] [review]
Patch based on Matthews, but with a static dirname and additional GConf Error checking
Comment 8 Matthew Barnes 2008-03-02 14:48:53 UTC
Remove the g_assert() statements, but looks fine otherwise.
Comment 9 Tobias Mueller 2008-03-02 14:59:00 UTC
I removed g_assert() from calendar/gui/migration.c and composer/e-msg-composer.c, so here comes the new patch.
Comment 10 Tobias Mueller 2008-03-02 14:59:42 UTC
Created attachment 106389 [details] [review]
Patch w/o g_assert()s
Comment 11 Matthew Barnes 2008-03-02 15:22:27 UTC
Great, thanks.

I noticed you moved the 'dirname' variable outside of e_get_user_data_dir(), which isn't necessary.  Static variables can live happily inside functions; their values persist across calls.  In this case it would be slightly better for the variable to live inside the function just to ensure that e_get_user_data_dir() is the only way to get the value.  But not a big deal, I'm just nitpicking.

Approved for post-2.22.0 release.
Comment 12 Matthew Barnes 2008-03-11 00:37:23 UTC
Bumping version to a stable release.
Comment 13 Matthew Barnes 2008-03-11 15:22:01 UTC
Committed to trunk (revision #35175).
Comment 14 Alban Browaeys 2008-03-12 11:54:22 UTC
This commit leads to a segfault on my station :
Program received signal SIGSEGV, Segmentation fault.

Thread 3061462848 (LWP 3730)

  • #0 g_object_new_valist
    from /usr/lib/libgobject-2.0.so.0
  • #1 g_object_new
    from /usr/lib/libgobject-2.0.so.0
  • #2 mail_component_peek
    at mail-component.c line 1239
  • #3 mail_component_peek_base_directory
    at mail-component.c line 1247
  • #4 mail_config_init
    at mail-config.c line 379
  • #5 mail_config_get_accounts
    at mail-config.c line 808
  • #6 em_folder_tree_model_init
    at em-folder-tree-model.c line 294
  • #7 g_type_create_instance
    from /usr/lib/libgobject-2.0.so.0
  • #8 ??
    from /usr/lib/libgobject-2.0.so.0
  • #9 ??
  • #10 ??
No symbol table info available.



reverting to 35173 fix it.

Regards
Alban
Comment 15 Milan Crha 2008-03-12 12:07:48 UTC
right, see bug #521959
Comment 16 Matthew Barnes 2008-03-12 12:35:56 UTC
Fixed mail regressions in revision 35179.
Comment 17 Milan Crha 2008-03-13 10:02:03 UTC
Should also get rid of these:
em-folder-tree.c: In function 'em_folder_tree_new':
em-folder-tree.c:569: warning: implicit declaration of function 'e_get_user_data_dir'
em-folder-tree.c:569: warning: passing argument 1 of 'em_folder_tree_model_new' makes pointer from integer without a cast
em-format-html.c: In function 'em_format_html_get_type':
em-format-html.c:257: warning: implicit declaration of function 'e_get_user_data_dir'
em-format-html.c:257: warning: initialization makes pointer from integer without a cast
Comment 18 Matthew Barnes 2008-03-13 14:43:41 UTC
Yes, good catch.  Feel free to commit a fix.
Comment 19 Milan Crha 2008-03-13 14:57:49 UTC
Fixed in revision 35186.