GNOME Bugzilla – Bug 300336
Request, --novfolder command line flag
Last modified: 2008-05-06 11:23:48 UTC
We are getting a high number of people that think that vFolders are duplicate email messages and they are deleting them quite often. We are requesting a command line --novfolder that hides that whole section on the folder list so they don't even see them. They aren't being used, and most people don't even know what they are. Duplicate virtual email messages is beyond the skillset of most 'business' users.
a little bit related to bug 263236; adding vfolders keyword, confirming.
*** Bug 348360 has been marked as a duplicate of this bug. ***
Created attachment 97114 [details] [review] proposed evo patch for evolution; I'm so sorry, but I renamed that parameter to '--disable-vfolder', to keep consistent with previous similar parameters (similar by name and function to disable something). When disabled, and someone calls some functions (those I found) in UI something related to vfolders, then vfolders will be loaded for you (aka 'run on demand'). Other possibility is to disable/hide menu options for vfolders, but I think it is not what we want. To Reviewer: There is only one thing I'm not sure about, and it is how to properly propagate command line setup from main.c to mail-component.c. I did it with defined global variable in main.c and 'extern' it in mail-component.c. It works, but I've a feeling that it is not the best way here. Any suggestions about this very appreciated, except of use gconf (it's ugly in this case and doesn't make sense to me).
Hmm, I dont think extern is a nice way to do this. Though ugly, GConf solution is better. But the ideal thing should be there should be a way the Shell tells the component about the command line values. May be another API by Shell can do this directly where it can tell all the components about the options and the component can decide to act upon or not. (Similar to HandleURI implementation where the shell tells the individual components to handle the uri like mailto:// etc.
I see no reason to make this a command-line option. I think a menu item (View -> Hide Search Folders) would work better. A sysadmin could tweak the default value through GConf.
I agree, it can be better with an option like "Show virtual folders after start", but not in the menu, it's nothing to be changed after start/initialized vfolder support. Doing this should be very hard from my point of view.
I think a preference entry w/Gconf might be better.
Created attachment 97272 [details] [review] proposed evo patch 2 for evolution; OK, added new option in '/apps/evolution/mail/display/enable_vfolders' and UI option in Edit->Preferences->Mail Preferences, tab "General", section "Message Display". Also note that my statement about "enable on demand" still applies. I also noticed, when scheme installation failed (and it did in my case), then search folders are disabled by default (I'm mentioning it here only because it can surprise someone like me).
I don't think the General tab of the Mail Preferences can handle any more options. It barely fits on a 1024x768 display as it is, and is unusable at 800x600.
Yes, but nothing fits better, unfortunately.
I suggest we defer this feature, then, until we free up some space in the Preferences dialog. Being unable to fit the preferences on even a 1024x768 display is a pretty major usability regression, not to mention embarrassing.
OK, with respect to bug 213660, we should create new Tab for alarm preset which will free necessary space for this bug. Sounds good for you? (I will try to do that 213660 if approved.)
I agree with Mbarnes. Johnny when is your new mail cleanup patch getting in? That would free up a lot.
Does this mean that, if we create a vfolder, it will be loaded automatically?
Yes, it should be (in case I didn't forget to add appropriate code in the place where it is created) :)
New mail notify patch (bug 492702) from Milan is in.
srag, ping
Milan, then go ahead and commit it. Make sure to announce ui/strings.
Committed to trunk. Committed revision 34775. String changes announced. If the scheme fails to install, then the search folders will be disabled. I just hope it will not make many bugs from trunk users :)
srag, can this please be added to the GNOME Roadmap? for me it is an important new feature because this can drastically improve performance, i assume?
As a note: We have been on Evolution for 3+ years and people still delete messages from vFolders thinking they are duplicates. This is a huge help for us.
Andre, you sure? I see that this is useful but may not be a big thing to be added to the roadmap. Of course it would be part of my release notes of the dot release as well as the final release. If you are very keen on that, then fine. What say?
*if* you know about the performance (i haven't tested) *and* if it remarkably improves performance, it should be listed imho. also, dave gave a much better example why this also could be very interesting for admins of large deployments (yes, gnome gets professional(TM)). just add it i'd say, the release notes gang will decide anyway whether to take it or not. :)
ok :). Will add it.
*** Bug 331434 has been marked as a duplicate of this bug. ***
*** Bug 346867 has been marked as a duplicate of this bug. ***