GNOME Bugzilla – Bug 596108
Should use XDG locations for storing configuration files
Last modified: 2010-09-20 10:56:22 UTC
The configuration files for orca are currently located in ~/.orca/, while freedesktop XDG standards[1] tell to use ~/.config/orca/ instead. [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
We have a task to refactor the way we handle Orca's settings in general. One thing we want to do is allow them to be first class script objects rather than the odd way we're handling them globally (bug #570650). Another is to tie into GNOME's setting infrastructure better (e.g., use gconf). When we address those tasks, we can revisit this one (e.g., moving to gconf would make this bug go away).
Created attachment 163315 [details] [review] Patch for moving the Orca's config files to the fdo ones As long as Orca is moving into a more generic and organized setting system at bug #619398 , we don't need to move all the settings to where Freedesktop.org recommends, but as they say at the bug some customization stuff aren't suitables for GConf/GSettings pair of keys based systems. That's why we still need to have a set of user directories and files, but we also need to move them to XDG_DATA_HOME, as Freedesktop.org and GNOME recommends: * http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html * http://live.gnome.org/GnomeGoals/XDGConfigFolders I've added a patch for fixing that. I've also changed the comment at the code related to the old path ~/.orca, so they now are pointing to XDG_DATA_HOME/orca. This XDG_DATA_HOME can be redefined by the distribution or the user, but it's transparent to Orca. By default the XDG_DATA_HOME is pointing to ~/.local/share/, so the new user's config directory would be ~/.local/share/orca. If this patch is accepted we'll need to create another one for updating the Orca's documentation because at this moment there are some references about the ~/.orca directory.
Review of attachment 163315 [details] [review]: Thanks for doing this Juanje! Looks good, tests fine -- once you move your settings from the old location to the one, anyway. :-) And makes Orca suck less as a citizen. :-) I am wondering, however.... Could you be persuaded to add a tiny migration step into the mix? 1. At this stage in the game, we have users pulling the unstable version (themselves, or through their distro) who don't read the Orca list frequently (or at all). This change is going greet (slap) them with a Preferences dialog, and a loss of all their Orca-wide and app-specific settings -- until they work out what they need to do. Once they do work that out, it's no big deal of course. Unless: 2. Right now, this early in the cycle, we've got folks actively using both the stable and the unstable branches. Stable branch will continue to look in $HOME/.orca; new branch XDG_DATA_HOME/orca. From the user perspective, it's kind of a drag to have to maintain two sets of settings. 3. As we've seen in recent list discussion, change isn't fun. :-P :-P Therefore, if there were a way to ease this transition (relocating files on behalf of the user? adding a symbolic link so that stable and unstable versions could use a single set of preferences?), I think that would be highly desirable. Thoughts?
(In reply to comment #3) > Review of attachment 163315 [details] [review]: > > Thanks for doing this Juanje! Looks good, tests fine -- once you move your > settings from the old location to the one, anyway. :-) And makes Orca suck less > as a citizen. :-) > > I am wondering, however.... Could you be persuaded to add a tiny migration step > into the mix? Sorry, I totally forgot the migration part. I know this is important one and we should deal carefully with it. > 1. At this stage in the game, we have users pulling the unstable version > (themselves, or through their distro) who don't read the Orca list frequently > (or at all). This change is going greet (slap) them with a Preferences dialog, > and a loss of all their Orca-wide and app-specific settings -- until they work > out what they need to do. Once they do work that out, it's no big deal of > course. Unless: > > 2. Right now, this early in the cycle, we've got folks actively using both the > stable and the unstable branches. Stable branch will continue to look in > $HOME/.orca; new branch XDG_DATA_HOME/orca. From the user perspective, it's > kind of a drag to have to maintain two sets of settings. > > 3. As we've seen in recent list discussion, change isn't fun. :-P :-P Indeed :-) > Therefore, if there were a way to ease this transition (relocating files on > behalf of the user? adding a symbolic link so that stable and unstable versions > could use a single set of preferences?), I think that would be highly > desirable. > > Thoughts? I think the problem (the same we are dealing at the new Orca's settings manager migration) is just the first time you launch the new version. Well, actually if you like to change by hand the conffiles and they are moved there is another issue... We could easily do the way you say, but I think people will be having old system forever then. And perhaps updates or user's errors could break the links and make it inconsistent. It hasn't to happen, but it could be. Maybe we could check for the old config dirs, migrate them (if they exist) and then show a notification to the user, so the user knows his/her settings are now in another directory. Obviously all the documentation has to be updated, so if the new user (even the old one) want to change things, the help will be pointing to the new place. What do you think about it?
> Sorry, I totally forgot the migration part. I know this is important one and we > should deal carefully with it. Thank you. > We could easily do the way you say, but I think people will be having old > system forever then. Not necessarily. > And perhaps updates or user's errors could break the links > and make it inconsistent. It hasn't to happen, but it could be. At the moment, we've already got a fragile settings situation: If there's an error writing out the file, Orca spits up the next time it launches. This strikes me as an interesting possibility: > Maybe we could check for the old config dirs, migrate them (if they exist) and > then show a notification to the user, so the user knows his/her settings are > now in another directory. I especially like it when I consider, say, the Ubuntu user going from Lazy Lemur to Mighty Mouse. Because in that situation, the user should be told, and the user is presumably not going to be running the old Lazy Orca version. I also think what we could do is when we get close to the 3.0 release, say 2.31.9, it's perfectly reasonable to do a flag day announcement on the Orca list that the brave new world has arrived, and that settings living in $HOME/.orca would be moved to the new location. When we do this one-time move, I think perhaps we should consider leaving a backup copy of what we moved (e.g. $HOME/.orca.bak). Just in case. However, today, right now, I think it is too early to make a permanent location move ("All your .orca are belong to us"?) because users are actively using both the gnome-2-30 branch and master. Therefore, we could go a couple of ways on this (possibly more, but two spring to my mind at the moment): 1. Add in a temporary solution to easy the transition. 2. Not commit this change until we get closer to the 3.0 release. > Obviously all the documentation has to be updated, so if the new user (even the > old one) want to change things, the help will be pointing to the new place. Indeed. And localized along with the text for the message box you propose.
(In reply to comment #5) > > Sorry, I totally forgot the migration part. I know this is important one and we > > should deal carefully with it. > > Thank you. > > > We could easily do the way you say, but I think people will be having old > > system forever then. > > Not necessarily. I know, but you know there is a lot of people wo doesn't like changes or are just lazy or they just won't remember it, so it's possible that some of them won't change the old way and we had to deal with it just in case. > > And perhaps updates or user's errors could break the links > > and make it inconsistent. It hasn't to happen, but it could be. > > At the moment, we've already got a fragile settings situation: If there's an > error writing out the file, Orca spits up the next time it launches. > > This strikes me as an interesting possibility: > > > Maybe we could check for the old config dirs, migrate them (if they exist) and > > then show a notification to the user, so the user knows his/her settings are > > now in another directory. > > I especially like it when I consider, say, the Ubuntu user going from Lazy > Lemur to Mighty Mouse. Because in that situation, the user should be told, and > the user is presumably not going to be running the old Lazy Orca version. > > I also think what we could do is when we get close to the 3.0 release, say > 2.31.9, it's perfectly reasonable to do a flag day announcement on the Orca > list that the brave new world has arrived, and that settings living in > $HOME/.orca would be moved to the new location. Sounds good to me :) > When we do this one-time move, I think perhaps we should consider leaving a > backup copy of what we moved (e.g. $HOME/.orca.bak). Just in case. It's very reasonable and I think this should be also notificated, so the user can get back the old config if it crash or someting. > However, today, right now, I think it is too early to make a permanent location > move ("All your .orca are belong to us"?) because users are actively using both > the gnome-2-30 branch and master. Therefore, we could go a couple of ways on > this (possibly more, but two spring to my mind at the moment): Yes, I guess if someone is using, both the move is not very good idea... > 1. Add in a temporary solution to easy the transition. Ok, now I see the link solution you pointed out before makes sense as a temporary solution for those who are using both branches... Well, there is also another possibility. We could add a flag to the master version so you can run the new Orca with the old userPrefsDir without check or move the directory. Something like: $ orca --old-config or $ orca -o And Orca will use the ~/.orca directory without checks or moves. In fact, this flags could be actived by default until the 3.0 release. Thoughts? > 2. Not commit this change until we get closer to the 3.0 release. > > > Obviously all the documentation has to be updated, so if the new user (even the > > old one) want to change things, the help will be pointing to the new place. > > Indeed. And localized along with the text for the message box you propose. About the notification I was wondering if it's better a dialog or a actual notification (libnotify). I'm not sure the a11y support of the notification system and the messages. A notification from the desktop will be less intrusive, but also a dialog could get more the user's attention. I'm not quite sure which one would be the best...
(In reply to comment #6) > $ orca --old-config > or > $ orca -o > > And Orca will use the ~/.orca directory without checks or moves. > In fact, this flags could be actived by default until the 3.0 release. > > Thoughts? If my choice is that, or no interim transition, I'd live with the flag. However, what happens if the user is using {master,gnome-2-30}, gets into the Preferences dialog, changes a setting, saves it, and then later on uses {gnome-2-30,master}? Won't he/she then have to make the same change again? > About the notification I was wondering if it's better a dialog or a actual > notification (libnotify). I'm not sure the a11y support of the notification > system and the messages. Notifications last time I checked: * Are not focusable or navigable and hence cannot be reviewed * Are Of temporary duration * Are often cut-off by other events which interrupt their presentation I hear what you're saying about intrusive, but for important information which is to be presented to a user who is blind and presented only once,.... I think that notifications are far less accessible than a dialog/message box.
May I give my 2 cents here? I don't think the user should know anything about the internals of the program (what is ~/.orca? most people don't know about it, and they shouldn't maybe! this is Gnome, not KDE, remember? ;-P). Besides, I only think you need to warn the user if you just don't find the most correct solution to this problem. But I think I have an idea that would work for everybody without overcomplicating things: do a 2 stage-deploy of this feature. Let me elaborate: - Create a patch(A) for orca that: a) When loading the program, checj if the XDG-location and the old location exist: pick the newest one and copy its contents to the other place, to have both settings duplicated. b) Whenever orca needs to write to the file, duplicate the writes too again. - Push it to master. - Release a stable version that contains this change. - Create a 2nd patch (B) that does the following things: a) Removes previous changes done in (A). b) Makes orca check at load time if the config files exist: b.1) If both exist (old and new location), pick the newest one and copy the contents of it to the XDG location, and remove the one on the old location. b.2) If only the old one exists, move it to the XDG location, and use that location for reading and writing. b.3) If only the new one (XDG) exist, proceed like normally, read and write there. - Push it to master. - Release a stable version that contains this change. - Forget about this issue and sleep well :) This way everybody's happy because it's not likely that someone goes 2 stable versions backwards. And you don't have to bug the user telling him anything about config files! or weird flags. (But it's good that this gets documented somewhere, just in case.)
(In reply to comment #7) > (In reply to comment #6) > > > $ orca --old-config > > or > > $ orca -o > > > > And Orca will use the ~/.orca directory without checks or moves. > > In fact, this flags could be actived by default until the 3.0 release. > > > > Thoughts? > > If my choice is that, or no interim transition, I'd live with the flag. > > However, what happens if the user is using {master,gnome-2-30}, gets into the > Preferences dialog, changes a setting, saves it, and then later on uses > {gnome-2-30,master}? Won't he/she then have to make the same change again? The meaing of having this flag is to be used by those users who are changing from one version to another. If the flag is used, the files won't be moved and both versions (gnome-2-30,master) will looking for its settings at ~/.orca directory. Once you are sure that you are going to use just the new version, you won't use the flag and the migration will happend. That's why I was suggesting to set the flag as active by default until the final release, so the users won'r forget accidentally to use the flag and get the preferences moved. I know I'm not explaining myself very clear (I think is because I'm starving..), but maybe these user cases will help: * Peter is a brave betatester and Orca user. He likes to test all the new features at master so he can report bugs. * Peter launch the gnome-2-30 Orca version then the preferences dialog and changes some keybindings. The changes will be stored (as always) at ~/.orca/user-settings.py. * Now Peter likes to test the new flavor, so he launch the master Orca version with -o flag, so he can keep using the old ~/.orca directory. And, actually, Orca will read the settings from ~/.orca/*. * After some testing he decides to change some voice settings at the preferences dialog. When he finish it Orca will save the changes again on ~/.orca/user-settings.py [few months later...] * Today has been released the new Orca version on Peter's distribution so he will update to the new version and removed the old one. * Peter has (just) the new version and launch it (without the -o flag). Orca detects an old configuration so migrates to the new order world and notificates to Peter about this migration of files. > > About the notification I was wondering if it's better a dialog or a actual > > notification (libnotify). I'm not sure the a11y support of the notification > > system and the messages. > > Notifications last time I checked: > > * Are not focusable or navigable and hence cannot be reviewed > * Are Of temporary duration > * Are often cut-off by other events which interrupt their presentation > > I hear what you're saying about intrusive, but for important information which > is to be presented to a user who is blind and presented only once,.... I think > that notifications are far less accessible than a dialog/message box. I was guessing that but I had to ask because for usability purposes GUI apps try to avoid annoying dialogs that pops to the user face. But I think you are rigth in this case.
> I know I'm not explaining myself very clear (I think is because I'm > starving..), but maybe these user cases will help: And I know I'm not either. I've been up since 12:30 AM, it's now just past 6:30 PM. So FWIW, what I'm trying to say is this: * These settings should be moved to the new location * I think the settings should be moved there immediately so that we don't have last minute surprises/bugs. (I don't see why we would in this case, but stranger things have been known to happen.) * I think we need a way to prevent this move from impacting the user Therefore, I was thinking that this could be accomplished via a symbolic link or some other similar solution. However, if you think this flag is the way to go, that's fine. > But I think you are rigth in this case. I suppose one out of two ain't bad. ;-)
Note to self: Implications for regression test harness? (Juanje: Given how sleepy I am atm, I didn't want to forget this. So I'm jotting it down. If the harness needs a corresponding change, I'm happy to do it. So no worries there. Only worry is my being an airhead and spacing it out entirely. ;-) )
(In reply to comment #8) > May I give my 2 cents here? > > I don't think the user should know anything about the internals of the program > (what is ~/.orca? most people don't know about it, and they shouldn't maybe! > this is Gnome, not KDE, remember? ;-P). In fact, it seems like they do. I mean. I don't and most of the users probably don't, but as far as I see at the maillist and the documentation, it's quite common to create some customizations that you can't make through the GUI, just using the user scripts. The notification is important for those users which has important customizations and could be get lost otherwise. > Besides, I only think you need to warn the user if you just don't find the most > correct solution to this problem. > > But I think I have an idea that would work for everybody without > overcomplicating things: do a 2 stage-deploy of this feature. > > Let me elaborate: > > - Create a patch(A) for orca that: > a) When loading the program, checj if the XDG-location and the old location > exist: pick the newest one and copy its contents to the other place, to have > both settings duplicated. > b) Whenever orca needs to write to the file, duplicate the writes too again. Hummmm... this could complicate more the patch because there are some points where the files (actually there are a few directories and a few files) can be written and we'd have to make the sync at all those points each time. > - Push it to master. > - Release a stable version that contains this change. > - Create a 2nd patch (B) that does the following things: > a) Removes previous changes done in (A). > b) Makes orca check at load time if the config files exist: > b.1) If both exist (old and new location), pick the newest one and copy the > contents of it to the XDG location, and remove the one on the old location. > b.2) If only the old one exists, move it to the XDG location, and use that > location for reading and writing. > b.3) If only the new one (XDG) exist, proceed like normally, read and write > there. > - Push it to master. > - Release a stable version that contains this change. > - Forget about this issue and sleep well :) Sorry, but I don't really see this solution simplier. Maybe I'm missing something but I see more steps and more checks. > This way everybody's happy because it's not likely that someone goes 2 stable > versions backwards. And you don't have to bug the user telling him anything > about config files! or weird flags. (But it's good that this gets documented > somewhere, just in case.) I'm afraid that to tell the user where is his/her config files is not so unnecessary. As I said before, there are some users that need (or just want) to change or add some customizations which can be added just by hand in those files, so the user needs to know if they are being moved.
(In reply to comment #10) > > I know I'm not explaining myself very clear (I think is because I'm > > starving..), but maybe these user cases will help: > > And I know I'm not either. I've been up since 12:30 AM, it's now just past 6:30 > PM. So FWIW, what I'm trying to say is this: > > * These settings should be moved to the new location > > * I think the settings should be moved there immediately so that we don't have > last minute surprises/bugs. (I don't see why we would in this case, but > stranger things have been known to happen.) > > * I think we need a way to prevent this move from impacting the user Totaly agree. > Therefore, I was thinking that this could be accomplished via a symbolic link > or some other similar solution. However, if you think this flag is the way to > go, that's fine. I think the symbolic link is good solution, but I'm just worried about something or someone break the links and then Orca will start to mess with the configs. Let's make a deal ;-) I'll write some code for testing the solution I've proposed (the flag one) as proof of concept, if you test it with both versions (gnome-2-30, master) and everything works fine, I'll finish the patch with that approach, if not, I'll write the symbolic link one. Deal? ;-) > > But I think you are rigth in this case. > > I suppose one out of two ain't bad. ;-) You know you have much more scored ;-)
(In reply to comment #13) > Let's make a deal ;-) > I'll write some code for testing the solution I've proposed (the flag one) as > proof of concept, if you test it with both versions (gnome-2-30, master) and > everything works fine, I'll finish the patch with that approach, if not, I'll > write the symbolic link one. > > Deal? ;-) Sure.
(3.0 Planning Spam-o-rama. Sorry!)
Created attachment 166543 [details] [review] Patch for moving the Orca's config files to the fdo ones. This is a new one. Sorry for the delay, the patch was almost ready time ago but I wanted to finish it (actually with a second patch which is coming later). This patch is quite similar to the previous one but if there is a ~/.orca directory already, Orca won't change it. The check is just a temporary until the next version be released, so people who is working with the previous version and this one can use both witht the same user's preference directory (~/.orca). The next patch will add a command line option for migrate the old directory (~/.orca) to the new one (XDG-DATA-HOME/orca) so if someone want to try just this version or later the configs will be moved to the new one place. In case Orca runs on a fresh installation (the simpliest scenario), by default Orca will create the files in XDG-DATA-HOME/orca.
Created attachment 166544 [details] [review] Migration from ~/.orca to XDG-DATA-HOME option This patch add a new command line option to Orca (-m, --migrate-config) to move the user's preference files from ~/.orca to XDG-DATA_HOME/orca. If the option is not passed Orca won't touch the current config directory. I didn't add the pop-up dialog because the change just will happen if the user ask with this option. The idea is to remove this option after the new release is launched and maybe make the migration automatically. I let this wxtra option and the old config by default so the betatesters who has both versions (stable and HEAD) can be using them with no inconsistent configs.
Review of attachment 166543 [details] [review]: Looks good to me. Thanks Juanje! Some comments on your comments. :-) (In reply to comment #16) > This patch is quite similar to the previous one but if there is a ~/.orca > directory already, Orca won't change it. Sounds good. > The check is just a temporary until the next version be released, so people who > is working with the previous version and this one can use both witht the same > user's preference directory (~/.orca). To be clear: When you say that "the check is just temporary," do you mean that in a later release, we will just move things from ~/.orca to the xdg location if the xdg location doesn't yet exist (which I'm fine with). Or do you mean that you'll remove this check: userPrefsDir = os.path.join(os.environ["HOME"], ".orca") +if not os.path.exists(userPrefsDir): If you mean the latter, a user upgrading to the latest Orca via his/her distro will lose all of his/her settings. That would suck. I think what we want to do is not *remove* the check as we get closer to 3.0, but rather flip-flop the check. In other words: Today: Do what you have in this patch (i.e. check for the existence of $HOME/.orca. If it is found, do nothing special unless the user had started Orca with -m or --migrate-config introduced in patch #2). Down the road (I'm thinking 1 Sept for 2.31.91): Check for XDG_DATA_HOME/orca. If it is not found and if there is a $HOME/.orca, automatically move the contents of $HOME/.orca to XDG_DATA_HOME/orca. Does this make sense? Or am I missing something? Anyhoo, like I said I'm good with this patch as it currently stands. Therefore please commit it to master.
Review of attachment 166544 [details] [review]: # Translators: this is the Orca command line option to tell Orca to + # move the user's preferences files from the old ~/.orca to the new + # XDG-DATA-HOME. + # + print "-m, --migrate-config " +\ + _("Move the user's preferences from ~/.orca to XDG-DATA-HOME.") So if this is just temporary and will be removed within a little over a month, should it really be marked for translation? Please unmark it. On a related note, there is a translator note for -u which states that the location is ~/.orca. While the exact location in which the preferences are stored is likely irrelevant to the translation, we should at least attempt to keep things correct and current. Therefore, would you mind updating that translator note while you're making the above change? Thanks! On another related note (directly more at Ale), we'll need to update the Orca documentation (part of the GNOME Desktop A11y Guide. Let's do that (and just deal with it once) when Javi's settings/profiles work gets committed. + if opt in ("-m", "--migrate-config"): + from xdg.BaseDirectory import xdg_data_home + userPrefsDir = os.path.join(xdg_data_home, "orca") + oldUserPrefsDir = os.path.join(os.environ["HOME"], ".orca") + if os.path.exists(oldUserPrefsDir): + os.renames(oldUserPrefsDir, userPrefsDir) + If you do the above, here's what happens when the user has opted to migrate to the xdg location: 1. $HOME/.orca gets moved to XDG_DATA_HOME/orca 2. This bit of code kicks in: http://git.gnome.org/browse/orca/tree/src/orca/orca.py#n2092 3. You've not updated settings.userPrefsDir from $HOME/.orca so a new, empty folder gets created there. 4. The existence of this newly-created $HOME/.orca results in the relocated settings to be ignored. Instead the original/old location is used instead. But there are no settings there, so the user is tossed into the Orca Preferences dialog. This will continue to occur until the newly-created $HOME/.orca has been manually removed by the user. If the user instead opts to re-set up his/her settings, they will get written to $HOME/.orca. I'm surprised you didn't run up against this issue when testing. Regardless, I believe what you need is this change: oldUserPrefsDir = os.path.join(os.environ["HOME"], ".orca") if os.path.exists(oldUserPrefsDir): os.renames(oldUserPrefsDir, userPrefsDir) + settings.userPrefsDir = userPrefsDir That solves the problem for me anyway.... If it does for you as well, please make these changes and then feel free to commit. Thanks!
(Sorry to be spammy. Juanje, once both changes have been committed to master, please explain the nature of the changes to the orca-list. Thanks!)
(In reply to comment #18) > Review of attachment 166543 [details] [review]: [...] > (In reply to comment #16) [...] > To be clear: When you say that "the check is just temporary," do you mean that > in a later release, we will just move things from ~/.orca to the xdg location > if the xdg location doesn't yet exist (which I'm fine with). Or do you mean > that you'll remove this check: > > userPrefsDir = os.path.join(os.environ["HOME"], ".orca") > > +if not os.path.exists(userPrefsDir): > > If you mean the latter, a user upgrading to the latest Orca via his/her distro > will lose all of his/her settings. That would suck. I was thinking more about just about to release or a bit earlier. > I think what we want to do is not *remove* the check as we get closer to 3.0, > but rather flip-flop the check. In other words: > > Today: Do what you have in this patch (i.e. check for the existence of > $HOME/.orca. If it is found, do nothing special unless the user had started > Orca with -m or --migrate-config introduced in patch #2 [details]). > > Down the road (I'm thinking 1 Sept for 2.31.91): Check for XDG_DATA_HOME/orca. > If it is not found and if there is a $HOME/.orca, automatically move the > contents of $HOME/.orca to XDG_DATA_HOME/orca. > > Does this make sense? Or am I missing something? Yes, actually I was thinking something like that. I didn't explain well myself. The temporary thing was more about the command line option. But of course, we need to flip-flop (I like this word :-P) the check. > Anyhoo, like I said I'm good with this patch as it currently stands. Therefore > please commit it to master. Thanks, I will :-)
(In reply to comment #19) > Review of attachment 166544 [details] [review]: > > # Translators: this is the Orca command line option to tell Orca to > + # move the user's preferences files from the old ~/.orca to the new > + # XDG-DATA-HOME. > + # > + print "-m, --migrate-config " +\ > + _("Move the user's preferences from ~/.orca to XDG-DATA-HOME.") > > So if this is just temporary and will be removed within a little over a month, > should it really be marked for translation? Please unmark it. You are so right. I didn't think about it... I was trying to do it in th same way that the other options, but cleary it's not the same. I'll change it. > On a related note, there is a translator note for -u which states that the > location is ~/.orca. While the exact location in which the preferences are > stored is likely irrelevant to the translation, we should at least attempt to > keep things correct and current. Therefore, would you mind updating that > translator note while you're making the above change? Thanks! Sure :-) > On another related note (directly more at Ale), we'll need to update the Orca > documentation (part of the GNOME Desktop A11y Guide. Let's do that (and just > deal with it once) when Javi's settings/profiles work gets committed. Ok, I'll keep it in mind. [...] > 3. You've not updated settings.userPrefsDir from $HOME/.orca so a new, empty > folder gets created there. [...] My bad :-/ I was testing the previous patch and part of this one time ago, but wasn't finished. Today I decide to finish the patch and I try it this part, but I've deactivated the a11y on my desktop week ago (perfomance reasons) and I thought the setup dialog was because of that. I was confident about my previous tests and I didn't try reloading the gnome sesion :-/ Sorry. > I'm surprised you didn't run up against this issue when testing. Regardless, I > believe what you need is this change: > > oldUserPrefsDir = os.path.join(os.environ["HOME"], ".orca") > if os.path.exists(oldUserPrefsDir): > os.renames(oldUserPrefsDir, userPrefsDir) > + settings.userPrefsDir = userPrefsDir Yeah, this makes sense... > That solves the problem for me anyway.... If it does for you as well, please > make these changes and then feel free to commit. I'll change it and test it (properly this time) again, and I will commit. Thanks :-)
(In reply to comment #22) > (In reply to comment #19) > > Review of attachment 166544 [details] [review] [details]: [...] > > I'm surprised you didn't run up against this issue when testing. Regardless, I > > believe what you need is this change: > > > > oldUserPrefsDir = os.path.join(os.environ["HOME"], ".orca") > > if os.path.exists(oldUserPrefsDir): > > os.renames(oldUserPrefsDir, userPrefsDir) > > + settings.userPrefsDir = userPrefsDir I did change this but I put your line outside the 'if'. This way if someone has already migrated and by mistake run again Orca with '-m' the settings.userPrefsDir will have the right value. I was testing and if you run twice (or more) 'orca -m' the second will get the same error you had before, because the oldUserPrefsDir doesn't exist so Orca won't entry into the 'if'.
(In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #19) > > > Review of attachment 166544 [details] [review] [details] [details]: > [...] > > > I'm surprised you didn't run up against this issue when testing. Regardless, I > > > believe what you need is this change: > > > > > > oldUserPrefsDir = os.path.join(os.environ["HOME"], ".orca") > > > if os.path.exists(oldUserPrefsDir): > > > os.renames(oldUserPrefsDir, userPrefsDir) > > > + settings.userPrefsDir = userPrefsDir > > I did change this but I put your line outside the 'if'. This way if someone has > already migrated and by mistake run again Orca with '-m' the > settings.userPrefsDir will have the right value. Won't it anyway? It does for me. Even if I run Orca -m again. Because in settings.py, you had made this change: userPrefsDir = os.path.join(os.environ["HOME"], ".orca") if not os.path.exists(userPrefsDir): from xdg.BaseDirectory import xdg_data_home userPrefsDir = os.path.join(xdg_data_home, "orca") Thus, in the condition which I believe you are describing, the location in settings.userPrefsDir would not exist and thus settings.py would set settings.userPrefsDir to the xdg-based location. Then the code in orca.py would do it's thing, oldUserPrefsDir doesn't exist, settings.userPrefsDir is already the xdg-based location. Therefore isn't what you're doing redundant? (Harmless mind you, but redundant?) > I was testing and if you run twice (or more) 'orca -m' the second will get the > same error you had before, because the oldUserPrefsDir doesn't exist so Orca > won't entry into the 'if'. I'm not discounting the error you describe and I believe you're seeing it. But I don't understand why you are seeing it, nor why I cannot reproduce it. I'd be curious should you care to provide more detail; but I'll get over it if you do not. :-) This change seems fine.
As part of my curiosity in trying to reproduce the scenario you describe and get the results you describe, I came across a related bug that we should decide what to do with and then fix. Consider a user who took the leap and migrated, but is still on occasion using the stable (2.30.2) Orca. As a result, this user would wind up with settings in both locations. Which is fine. Now the user accidentally or intentionally does 'orca -m': Traceback (most recent call last):
+ Trace 222983
os.renames(oldUserPrefsDir, userPrefsDir)
rename(old, new)
And Orca does not start, but instead usage notes are displayed. Silently. So.... I'm not sure what the RightThing(tm) to do here is: On the one hand, the '-m' redux could've been an accident; but on the other hand, the user might want to re-merge (i.e. maybe as a result of changing a bunch of settings in the stable branch and not wanting to have to re-change them in the unstable branch). Regardless, the one thing we should not do is spit up a traceback and remain silent.
(In reply to comment #24) [...] > > I did change this but I put your line outside the 'if'. This way if someone has > > already migrated and by mistake run again Orca with '-m' the > > settings.userPrefsDir will have the right value. > > Won't it anyway? It does for me. Even if I run Orca -m again. Because in > settings.py, you had made this change: > > userPrefsDir = os.path.join(os.environ["HOME"], ".orca") > > if not os.path.exists(userPrefsDir): > from xdg.BaseDirectory import xdg_data_home > > userPrefsDir = os.path.join(xdg_data_home, "orca") > > Thus, in the condition which I believe you are describing, the location in > settings.userPrefsDir would not exist and thus settings.py would set > settings.userPrefsDir to the xdg-based location. Then the code in orca.py would > do it's thing, oldUserPrefsDir doesn't exist, settings.userPrefsDir is already > the xdg-based location. Therefore isn't what you're doing redundant? (Harmless > mind you, but redundant?) Well... I've re-testing it with pdb to see what is happening under the hood and with the line inside the 'if', settings.userPrefsDir is pointing to ~/.orca all the time. It doesn't change to the xdg-based location. I've also noticed that with the line inside the if or with no line, after the first run with '-m' a empty ~/.orca directory is created. So next time this will exist and orca will believe that the config location is the old one. If I put the line after the if (outside) and I check the settings.userPrefsDir, it is changed to xdg-data-home/orca and no one empty ~/.orca diretory is created. > > I was testing and if you run twice (or more) 'orca -m' the second will get the > > same error you had before, because the oldUserPrefsDir doesn't exist so Orca > > won't entry into the 'if'. > > I'm not discounting the error you describe and I believe you're seeing it. But > I don't understand why you are seeing it, nor why I cannot reproduce it. I'd be > curious should you care to provide more detail; but I'll get over it if you do > not. :-) This change seems fine. I could check this issue few times before the commit, but now I can't reproduce either. Anyway, the change fix the empty ~/.orca directory (which I can reproduce right now).
(In reply to comment #25) > As part of my curiosity in trying to reproduce the scenario you describe and > get the results you describe, I came across a related bug that we should decide > what to do with and then fix. > > Consider a user who took the leap and migrated, but is still on occasion using > the stable (2.30.2) Orca. As a result, this user would wind up with settings in > both locations. Which is fine. Now the user accidentally or intentionally does > 'orca -m': > > Traceback (most recent call last): > File "/usr/lib/python2.6/dist-packages/orca/orca.py", line 1991 in main > os.renames(oldUserPrefsDir, userPrefsDir) > File "/usr/lib/python2.6/os.py", line 199 in renames > rename(old, new) > OSError: [Errno 39] Directory not empty > > And Orca does not start, but instead usage notes are displayed. Silently. Yes, I saw it. When I was testing as I said at the comment 26 when I got the empty ~/.orca and I ran Orca with '-m' and then without '-m', this message show up to me. The was when I realized that the empty ~/.orca was being created. > So.... I'm not sure what the RightThing(tm) to do here is: On the one hand, the > '-m' redux could've been an accident; but on the other hand, the user might > want to re-merge (i.e. maybe as a result of changing a bunch of settings in the > stable branch and not wanting to have to re-change them in the unstable > branch). Regardless, the one thing we should not do is spit up a traceback and > remain silent. Agree. I'm not sure what to do with the config, but it can't spit up a traceback... I suggest to use a 'try:' and if some error is raised then show to the user a message like this one. "It seems like you try to migrate your preferences but the new location is not empty. Probably it was already migrated, please check it before to try again." Well, something better but you got the idea. What do you think?
(In reply to comment #27) > I suggest to use a 'try:' and if some error is raised then show to the user a > message like this one. > "It seems like you try to migrate your preferences but the new location is not > empty. Probably it was already migrated, please check it before to try again." > > Well, something better but you got the idea. > What do you think? At the time I mentioned flip-flopping, I didn't realize os.renames() would spit up a traceback if the new location wasn't empty. Seeing that it does, if you were to do as you describe now, that would solve the interim situation. When we remove the option and just move stuff, leave the try: in place and just remove the message from the except: so that we "fail" silently. Make sense?
(In reply to comment #28) > At the time I mentioned flip-flopping, I didn't realize os.renames() would spit > up a traceback if the new location wasn't empty. Seeing that it does, if you > were to do as you describe now, that would solve the interim situation. When we > remove the option and just move stuff, leave the try: in place and just remove > the message from the except: so that we "fail" silently. > > Make sense? Or maybe we can change the message. I don't really like the idea of the user thinking the migration has been done and actually it hasn't. Perhaps the target directory is from a previous migration and everything is ok, but maybe is a fail migration or a very old one. In those cases the config the user will expect and the one he/she gets won't be the same :-/ At least we should notify to the user. don't you think?
(In reply to comment #29) > At least we should notify to the user. don't you think? I think we should notify the user of a successful move, once the move is automatic. Because that answers the question, "where the heck did my $HOME/.orca go?" Since that's been the location for like five years now. But we have -- and will continue to have -- users who run earlier versions of GNOME with Orca from master. We really don't have "beta testers" as much as we have users who sometimes go with the stable version of Orca which came from their distro and sometimes like to give Orca from master a try. If every time such a user, with both a $HOME/.orca and a XDG-DATA-HOME/orca, got an error message as a result of launching master, we'd have unhappy users. Trust me.
Pushed at http://git.gnome.org/browse/orca/commit/?id=759c61df50e61c92c274cf5a9461945bd267d54b and http://git.gnome.org/browse/orca/commit/?id=759c61df50e61c92c274cf5a9461945bd267d54b
(In reply to comment #31) > Pushed at > > http://git.gnome.org/browse/orca/commit/?id=759c61df50e61c92c274cf5a9461945bd267d54b > > and > > http://git.gnome.org/browse/orca/commit/?id=759c61df50e61c92c274cf5a9461945bd267d54b C&P fail! Pushed at http://git.gnome.org/browse/orca/commit/?id=759c61df50e61c92c274cf5a9461945bd267d54b and http://git.gnome.org/browse/orca/commit/?id=49af893c1894821ef0f868aebf75e42c716db8ef can we close this?
(In reply to comment #32) > can we close this? 1. There's still the traceback from comment 25. I think that is part of this bug. 2. There's the removal of the cli option. That can be part of this bug, or it can be addressed in a different bug if you prefer.
Created attachment 166661 [details] [review] Control an exception for avoiding to show a Python's traceback to the user This patch avoid catch the exection when the target directory already exist and show to the user a nicer and useful message. I didn't made the commit because I wanted to know if the message is good enough. If you like the message I will commit it so this bug is almost done :-)
Review of attachment 166661 [details] [review]: > This patch avoid catch the exection when the target directory already exist and > show to the user a nicer and useful message. Way nicer than the one I'd write. :-P > I didn't made the commit because I wanted to know if the message is good > enough. Definitely good enough. If you want perfect: like you try -> like you are trying before to try -> before you try And line length <= 80 > If you like the message I will commit it so this bug is almost done :-) Please do. And since the actual, original bug is fixed with this commit (yay!), I propose we close this bug as fixed and open a new one for the removal of the option.
Changed commited :-) http://git.gnome.org/browse/orca/commit/?id=da4a174b3e8c87357959efefecdb0193e1983425 Thanks for the Emglish tips :-) BTW, the patch I've attached wasn't the good one, I had a newer one with the 80 characters fixed. Anyway, the final patch (the commit) has this fixed as well. Would you close the bug and open the other one? I'm already working on the patch for the new bug. To have it ready for the time we'll need it.
(In reply to comment #36) > Thanks for the Emglish tips :-) Thanks for not asking how my Spanish is coming along. ;-) > Would you close the bug and open the other one? Sure thing. Bug 625422 is opened and assigned to you. > I'm already working on the patch for the new bug. To have it ready for the time > we'll need it. That's awesome. Thank you Juanje!