I don't really agree. David's wording identifies one situation for this dialog, and not even the primary reason for the lock file in the first place.
Remember that the lock file and this check exist firstly to prevent multiple users from opening the file at one time--and that is still a possibility. Adding to the error message to account for when the software crashes seems like overkill (as does linking to the documentation from a dialog, BTW). The topic is covered both in the wiki and in the Tutorial, and a quick check online or in the documentation should resolve the problem. Expanding messages to cover all eventualities results in messages that are overly complex, overwhelming, and still misunderstood. And for those panicked new users who don't avail themselves of the existing resources, it should be a simple enough proposition to refer them to the same. A quick "Check the tutorial at section 2.5, or the FAQ, and see if that fixes your problem." should suffice. David T. On November 18, 2019, at 2:07 PM, Stan Brown <the_stan_br...@fastmail.fm> wrote: I think David Carlson's suggestion is better than mine. I had hoped to spark a discussion on this point, so I didn't expect my version would be the final one. I'm delighted that it is being looked at, and benefit to users will result. -- Regards, Stan Brown Tompkins County, New York, USA https://BrownMath.com http://OakRoadSystems.com On 2019-11-17 19:24, David Carlson wrote: > A comment about Stan Brown's suggestion. > > I think a better and more accurate wording would be "The data file has > not been cleanly closed since it was last opened. If you are sure that > it was not opened by another user, click 'Open Anyway'. Otherwise click > one of the other options." > > To me the important part is that the data file has not been cleanly > closed, which is the real reason that the lock file exists. There may > be better words to use as long as this idea is incorporated. > > David Carlson > > On Sun, Nov 17, 2019 at 4:35 PM Frank H. Ellenberger > <frank.h.ellenber...@gmail.com <mailto:frank.h.ellenber...@gmail.com>> > wrote: > > Hello Stan et al. > > I like the idea. A short grep delivers 5 occurrences of likewise > texts: 4 at > > https://github.com/Gnucash/gnucash/blob/de09259f13e8e3d7f2e50f97a353bd22eb45a4b6/gnucash/gnome-utils/gnc-file.c#L276 > and one further below: > > https://github.com/Gnucash/gnucash/blob/de09259f13e8e3d7f2e50f97a353bd22eb45a4b6/gnucash/gnome-utils/gnc-file.c#L768 > I am not totally sure if the change can be applied on aloof them. > > BTW. Splitting the first 4 strings like the last would reduce the > burden for our translators. > > Regards > Frank > > Am So., 17. Nov. 2019 um 08:22 Uhr schrieb Stan Brown > <the_stan_br...@fastmail.fm <mailto:the_stan_br...@fastmail.fm>>: > > > > In the two years I've been reading this list, I think the single most > > common question has been about this "could not obtain the lock" > message. > > Seems like someone asks about it at least once a week. > > > > The text "that database may be in use by another user," while > literally > > true, isn't helpful because it points to a less common case and > gives no > > guidance for the more common case. It's like hearing hoofbeats and > > hypothesizing "zebra" instead of "horse". > > > > I suggest that improving the message would be a huge boon to less > > experienced GC users, and very little effort for the developers. > > > > Why not replace the present text > > > > That database may be in use by another user, in which case you > > should not open the database. What would you like to do? > > > > with this: > > > > If your previous session crashed, select Open Anyway. If > this is > > a shared database, wait for other users to finish using it or > > select Open Read-Only. For more information, see (link to sec > > 2.5.3 of Tutorial). > > > > "What would you like to do?" can be omitted, in my opinion. Seeing > > buttons, users will know that they need to pick one. What they > _do_ need > > is text that is relevant to their situation. > > > > (I question the tutorial's advice to delete the lock files manually. > > David Cousens reports: > > > My experience on Linux is that when you select Open > > > Anyway, the previous .LNK and .LCK files will be deleted and new > ones > > > created which should then be deleted when GNucash is closed > properly. > > The same happens for me in Windows. Is there any OS where this > desirable > > behavior doesn't happen? If there is, the tutorial's advice should > > mention those specific systems, or at least it should say that in > > Windows and Linux GC will do this automatically when you reopen a data > > file after the "could not obtain the lock" message.) _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
