Hi, I think there should be a clear warning about changing the new various prefs - e.g. a user might enable use_safe_file_saving and then run into problems.
I'll try to add a warning label and perhaps put the treeview in an expander, collapsed by default. We want to make it obvious that changing those settings should only be done if you know what you're doing.
I think this change should go through before the string freeze.
Nick
On Wed, 14 Sep 2011 17:47:41 +0100 (BST) Nick Treleaven nick.treleaven@btopenworld.com wrote:
I think there should be a clear warning about changing the new various prefs - e.g. a user might enable use_safe_file_saving and then run into problems.
What are the problems with changing use_safe_file_saving? I don't see how the previous value may affect anything.
Before writing the very first variant of various prefs, I checked all settings for being safe to change, and published the results in the mailing list. There were problems with allow_always_save, and I fixed them with a separate patch.
I'll try to add a warning label and perhaps put the treeview in an expander, collapsed by default. We want to make it obvious that changing those settings should only be done if you know what you're doing.
Or maybe start the page with a warning and an "I'll be careful, I promise?" check button, which shows the list? :)
The dangerous settings are gio_unsafe_save_backup, use_gio_unsafe_file_saving and use_safe_file_saving, and IMHO their names are quite indicative. Everything else is harmless, except for indent_hard_tab_width to some extent. I believe it shoudn't exist in the first place.
Hi,
Le 14/09/2011 20:04, Dimitar Zhekov a écrit :
On Wed, 14 Sep 2011 17:47:41 +0100 (BST) Nick Treleaven nick.treleaven@btopenworld.com wrote:
I think there should be a clear warning about changing the new various prefs - e.g. a user might enable use_safe_file_saving and then run into problems.
What are the problems with changing use_safe_file_saving? I don't see how the previous value may affect anything.
As you say yourself below, it's a "dangerous" setting because it changes the way the file saving works, and actually "breaks" links, permissions, etc. So yes, this one is a sensitive setting.
I'll try to add a warning label and perhaps put the treeview in an expander, collapsed by default. We want to make it obvious that changing those settings should only be done if you know what you're doing.
Or maybe start the page with a warning and an "I'll be careful, I promise?" check button, which shows the list? :)
The dangerous settings are gio_unsafe_save_backup, use_gio_unsafe_file_saving and use_safe_file_saving, and IMHO their names are quite indicative. Everything else is harmless
I'm puzzled between adding "annoyance" to the user and preventing her to touch sensitive settings without a good reason. Actually some "harmless" settings as Dimitar called them may even be of some real interest to some users (the reason why we have that Various tab, heh), like allow_always_save, compiler_tab_autoscroll, etc.
So I agree that we should find a way to tell the user not to change something without having checked the manual (or be prepared no to come cry in our skirts), but I'm not sure we should really make it *hard* to change something like compiler_tab_autoscroll.
So... puzzled :/
except for indent_hard_tab_width to some extent. I believe it shoudn't exist in the first place.
Agreed. Actually it's a vestige from the past, AFAIK just kept for a better compatibility. We even warn on the console/debug window it it isn't set to 8. We might want to remove it at some point, not sure when is the best time.
Regards, Colomban
--- On Wed, 14/9/11, Colomban Wendling lists.ban@herbesfolles.org wrote:
Nick Treleaven nick.treleaven@btopenworld.com
wrote:
I think there should be a clear warning about
changing the new
various prefs - e.g. a user might enable
use_safe_file_saving and
then run into problems.
What are the problems with changing
use_safe_file_saving? I don't see
how the previous value may affect anything.
As you say yourself below, it's a "dangerous" setting because it changes the way the file saving works, and actually "breaks" links, permissions, etc. So yes, this one is a sensitive setting.
Yes, this is what I'm worried about - that people will think 'of course I want safe saving' and check it, then complain to us that geany is broken.
I'll try to add a warning label and perhaps put
the treeview in an
expander, collapsed by default. We want to make it
obvious that
changing those settings should only be done if you
know what you're
doing.
Or maybe start the page with a warning and an "I'll be
careful, I
promise?" check button, which shows the list? :)
Could do. I was thinking an expander is easier to implement ;-) Your idea might be better, like Firefox does.
The dangerous settings are gio_unsafe_save_backup, use_gio_unsafe_file_saving and use_safe_file_saving,
and IMHO their
names are quite indicative. Everything else is
harmless
I'm puzzled between adding "annoyance" to the user and preventing her to touch sensitive settings without a good reason. Actually some "harmless" settings as Dimitar called them may even be of some real interest to some users (the reason why we have that Various tab, heh), like allow_always_save, compiler_tab_autoscroll, etc.
So I agree that we should find a way to tell the user not to change something without having checked the manual (or be prepared no to come cry in our skirts), but I'm not sure we should really make it *hard* to change something like compiler_tab_autoscroll.
I agree, I like Dimitar's feature. I don't want to make it hard to use, just more obvious that the user should be careful.
except for indent_hard_tab_width to some extent. I
believe it
shoudn't exist in the first place.
Agreed. Actually it's a vestige from the past, AFAIK just kept for a better compatibility. We even warn on the console/debug window it it isn't set to 8. We might want to remove it at some point, not sure when is the best time.
Yes, it could probably be removed sometime.
Le 15/09/2011 16:48, Nick Treleaven a écrit :
--- On Wed, 14/9/11, Colomban Wendling lists.ban@herbesfolles.org wrote: [...]
The dangerous settings are gio_unsafe_save_backup, use_gio_unsafe_file_saving and use_safe_file_saving,
and IMHO their
names are quite indicative. Everything else is
harmless
I'm puzzled between adding "annoyance" to the user and preventing her to touch sensitive settings without a good reason. Actually some "harmless" settings as Dimitar called them may even be of some real interest to some users (the reason why we have that Various tab, heh), like allow_always_save, compiler_tab_autoscroll, etc.
So I agree that we should find a way to tell the user not to change something without having checked the manual (or be prepared no to come cry in our skirts), but I'm not sure we should really make it *hard* to change something like compiler_tab_autoscroll.
I agree, I like Dimitar's feature. I don't want to make it hard to use, just more obvious that the user should be careful.
OK, so do as you think it's the best -- unless it makes the thing harder to use for really interested users I'm fine with any type of warning.
Cheers, Colomban
--- On Thu, 15/9/11, Colomban Wendling lists.ban@herbesfolles.org wrote:
The dangerous settings are
gio_unsafe_save_backup,
use_gio_unsafe_file_saving and
use_safe_file_saving,
and IMHO their
names are quite indicative.
...
I agree, I like Dimitar's feature. I don't want to
make it hard to use, just more obvious that the user should be careful.
OK, so do as you think it's the best -- unless it makes the thing harder to use for really interested users I'm fine with any type of warning.
Actually I've changed my mind. First - we've got a string freeze planned for this weekend. Second - the problem seems to me more that use_safe_file_saving is misleadingly named. Even with an opt-in warning, users can still be misled.
The other two 'dangerous' prefs at least have 'unsafe' in the name. An opt-in warning also adds more complexity to Geany.
So I propose we go ahead with the string freeze (assuming there are no other issues) and instead rename use_safe_file_saving to something less misleading. We can provide compatibility with the old name if the new name key doesn't exist.
Nick
On 16 September 2011 20:42, Nick Treleaven nick.treleaven@btopenworld.com wrote:
--- On Thu, 15/9/11, Colomban Wendling lists.ban@herbesfolles.org wrote:
The dangerous settings are
gio_unsafe_save_backup,
use_gio_unsafe_file_saving and
use_safe_file_saving,
and IMHO their
names are quite indicative.
...
I agree, I like Dimitar's feature. I don't want to
make it hard to use, just more obvious that the user should be careful.
OK, so do as you think it's the best -- unless it makes the thing harder to use for really interested users I'm fine with any type of warning.
Actually I've changed my mind. First - we've got a string freeze planned for this weekend. Second - the problem seems to me more that use_safe_file_saving is misleadingly named. Even with an opt-in warning, users can still be misled.
The other two 'dangerous' prefs at least have 'unsafe' in the name. An opt-in warning also adds more complexity to Geany.
So I propose we go ahead with the string freeze (assuming there are no other issues) and instead rename use_safe_file_saving to something less misleading. We can provide compatibility with the old name if the new name key doesn't exist.
Renaming to include unsafe is a good idea, it is some warning on the actual setting, but what exactly?
IIRC the setting actually provides a lower risk of data loss but a higher risk of metadata loss, ie protections/execute etc.
safe_data_unsafe_metadata_save is really silly :)
Cheers Lex
Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
--- On Fri, 16/9/11, Lex Trotman elextr@gmail.com wrote:
Actually I've changed my mind. First - we've got a
string freeze planned for this weekend. Second - the problem seems to me more that use_safe_file_saving is misleadingly named. Even with an opt-in warning, users can still be misled.
The other two 'dangerous' prefs at least have 'unsafe'
in the name. An opt-in warning also adds more complexity to Geany.
So I propose we go ahead with the string freeze
(assuming there are no other issues) and instead rename use_safe_file_saving to something less misleading. We can provide compatibility with the old name if the new name key doesn't exist.
Renaming to include unsafe is a good idea, it is some warning on the actual setting, but what exactly?
Something technical that won't make many users enable it naively.
Something like: use_glib_file_saving use_atomic_file_saving save_clobbers_existing_file
I don't mind any of these, anything but 'safe'.
Nick
[...]
Something technical that won't make many users enable it naively.
Something like: use_glib_file_saving use_atomic_file_saving save_clobbers_existing_file
I don't mind any of these, anything but 'safe'.
What about read_the_flamin_manual_before_you_enable_this_saving :)
Cheers Lex
PS welcome back
On 09/15/2011 07:48 AM, Nick Treleaven wrote:
I agree, I like Dimitar's feature. I don't want to make it hard to use, just more obvious that the user should be careful.
One solution would be to just rename "Various" to "Advanced" which implies that these are not your regular "basic" settings. This along with a little blurb in a label inside the actual tab page should be sufficient IMO.
Either way, I still don't think the wording "Various Preferences" should be used. It's not that it's a big deal or that the wording is incorrect per se, but "Various Preferences" just doesn't sound idiomatic to me (native Canadian/US English speaker).
Lex pointed me to the discussion[1] on the ML related to this, so I made a quick poll[2] with the alternative words mentioned there as well as a few of my own.
[1] http://lists.uvena.de/geany-devel/2010-October/003315.html [2] http://www.doodle.com/dvrvc7cxzcc7vvcv (note the little squiggly collapsed options if you have a small browser window)
P.S. Is there any way to make the "Various" tab in the preferences dialog stick to the bottom position in the notebook so that when tabs are added later, "Various" is still at the end?
Cheers, Matthew Brush
--- On Fri, 16/9/11, Matthew Brush mbrush@codebrainz.ca wrote:
I agree, I like Dimitar's feature. I don't want to
make it hard to use, just more obvious that the user should be careful.
One solution would be to just rename "Various" to "Advanced" which implies that these are not your regular "basic" settings. This along with a little blurb in a label inside the actual tab page should be sufficient IMO.
I think that solution is too subtle - but I posted an alternative, simpler solution just now.
Either way, I still don't think the wording "Various Preferences" should be used. It's not that it's a big deal or that the wording is incorrect per se, but "Various Preferences" just doesn't sound idiomatic to me (native Canadian/US English speaker).
First, we have a string freeze coming up, so it should probably stay as is for now.
Personally I agree that various is not the most precise term, but I think it's good enough and not worth changing. (Various is used throughout the code also).
P.S. Is there any way to make the "Various" tab in the preferences dialog stick to the bottom position in the notebook so that when tabs are added later, "Various" is still at the end?
Probably no enforcible way, but it would be a good convention. It could be appended last when creating the prefs dialog, and with a comment.
Nick
On 09/16/2011 03:51 AM, Nick Treleaven wrote:
--- On Fri, 16/9/11, Matthew Brushmbrush@codebrainz.ca wrote:
Either way, I still don't think the wording "Various Preferences" should be used. It's not that it's a big deal or that the wording is incorrect per se, but "Various Preferences" just doesn't sound idiomatic to me (native Canadian/US English speaker).
First, we have a string freeze coming up, so it should probably stay as is for now.
Personally I agree that various is not the most precise term, but I think it's good enough and not worth changing. (Various is used throughout the code also).
I would've thought it'd be easy to change the two user-facing labels, like 5 minutes easy. Seems to me now would be the ideal time to change those two labels. Or, is it possible to do English translations after the string freeze?
P.S. Is there any way to make the "Various" tab in the preferences dialog stick to the bottom position in the notebook so that when tabs are added later, "Various" is still at the end?
Probably no enforcible way, but it would be a good convention. It could be appended last when creating the prefs dialog, and with a comment.
Isn't the whole dialog created in Glade, except the Terminal tab (for some reason)? I guess it would just take adding the Terminal in the second last position rather than appended on the end if that's the case (plus a comment as you say).
Cheers, Matthew Brush
[...]
I would've thought it'd be easy to change the two user-facing labels, like 5 minutes easy. Seems to me now would be the ideal time to change those two labels. Or, is it possible to do English translations after the string freeze?
The problem is that the decision is needed today (your time, its Saturday for me already :). String freeze means that all English strings in the software are frozen whilst translations are made. This is so that the translations match the originals. So no changes allowed between then and release.
Cheers Lex
On 09/16/2011 07:23 AM, Lex Trotman wrote:
[...]
I would've thought it'd be easy to change the two user-facing labels, like 5 minutes easy. Seems to me now would be the ideal time to change those two labels. Or, is it possible to do English translations after the string freeze?
The problem is that the decision is needed today (your time, its Saturday for me already :). String freeze means that all English strings in the software are frozen whilst translations are made. This is so that the translations match the originals. So no changes allowed between then and release.
Right, so if someone takes 5 minutes to rename Various to <Other Thing> today then it will save it from having to be re-translated later, after the release. It would also be less confusing to the end user to not change the name of this tab/group between this release and the next. If there ever was a time to rename this, now seems ideal. I don't think end users will care so much if Geany's source code says various and the UI says "Advanced" or something, but they will probably notice the labels, especially next release when they're called something else.
But, like I said, it's not a huge deal, just a little bit of polish.
Cheers, Matthew Brush
Le 16/09/2011 16:40, Matthew Brush a écrit :
On 09/16/2011 07:23 AM, Lex Trotman wrote:
[...]
I would've thought it'd be easy to change the two user-facing labels, like 5 minutes easy. Seems to me now would be the ideal time to change those two labels. Or, is it possible to do English translations after the string freeze?
The problem is that the decision is needed today (your time, its Saturday for me already :). String freeze means that all English strings in the software are frozen whilst translations are made. This is so that the translations match the originals. So no changes allowed between then and release.
Right, so if someone takes 5 minutes to rename Various to <Other Thing> today then it will save it from having to be re-translated later, after the release. It would also be less confusing to the end user to not change the name of this tab/group between this release and the next. If there ever was a time to rename this, now seems ideal. I don't think end users will care so much if Geany's source code says various and the UI says "Advanced" or something, but they will probably notice the labels, especially next release when they're called something else.
But, like I said, it's not a huge deal, just a little bit of polish.
Although I also agree it's not necessarily the better term, "Advanced" was rejected in the original discussion, and I doubt something like extra/other/additional warns the user better than "Various".
However, if we find something great before tomorrow morning (2011-09-17 UTC) I think it's fine to change it. We won't change any string if it's not strictly necessary until the release after then.
Cheers, Colomban
On 09/16/2011 08:03 AM, Colomban Wendling wrote:
Le 16/09/2011 16:40, Matthew Brush a écrit :
Right, so if someone takes 5 minutes to rename Various to<Other Thing> today then it will save it from having to be re-translated later, after the release. It would also be less confusing to the end user to not change the name of this tab/group between this release and the next. If there ever was a time to rename this, now seems ideal. I don't think end users will care so much if Geany's source code says various and the UI says "Advanced" or something, but they will probably notice the labels, especially next release when they're called something else.
But, like I said, it's not a huge deal, just a little bit of polish.
Although I also agree it's not necessarily the better term, "Advanced" was rejected in the original discussion, and I doubt something like extra/other/additional warns the user better than "Various".
Even if they don't warn them, at least they don't sound weird.
However, if we find something great before tomorrow morning (2011-09-17 UTC) I think it's fine to change it. We won't change any string if it's not strictly necessary until the release after then.
Considering no one besides myself and Lex bothered to take the 2 second poll I guess no consensus can be reached in time, despite the fact that the general sentiment seems to be that "Various" is not a good choice. But if no one else really cares, I'll just shut up :)
Cheers, Matthew Brush
Le 17/09/2011 02:55, Matthew Brush a écrit :
On 09/16/2011 08:03 AM, Colomban Wendling wrote:
Le 16/09/2011 16:40, Matthew Brush a écrit :
Right, so if someone takes 5 minutes to rename Various to<Other Thing> today then it will save it from having to be re-translated later, after the release. It would also be less confusing to the end user to not change the name of this tab/group between this release and the next. If there ever was a time to rename this, now seems ideal. I don't think end users will care so much if Geany's source code says various and the UI says "Advanced" or something, but they will probably notice the labels, especially next release when they're called something else.
But, like I said, it's not a huge deal, just a little bit of polish.
Although I also agree it's not necessarily the better term, "Advanced" was rejected in the original discussion, and I doubt something like extra/other/additional warns the user better than "Various".
Even if they don't warn them, at least they don't sound weird.
However, if we find something great before tomorrow morning (2011-09-17 UTC) I think it's fine to change it. We won't change any string if it's not strictly necessary until the release after then.
Considering no one besides myself and Lex bothered to take the 2 second poll I guess no consensus can be reached in time, despite the fact that the general sentiment seems to be that "Various" is not a good choice. But if no one else really cares, I'll just shut up :)
The reason I haven't voted is that I don't have any real opinion. I would have voted "advanced" if it wasn't rejected on the original thread; but otherwise I don't have any reason to chose one or another. I'm not a native English speaker as we all know, and I don't even see "Various" as weird, so I can't provide a vote that would mean something.
Actually I think your POV might be interesting since you're a native speaker, but you voted "advanced" and I won't throw away the argumentation Dimitar had against it just for this, it wouldn't be any kind of consensus I think ^^
So I guess yeah, we'll have "various" in 0.21 unless you convince Frank/Nick/Enrico/me/etc. before Frank starts string freeze...
Regards, Colomban
On 09/16/2011 06:10 PM, Colomban Wendling wrote:
Actually I think your POV might be interesting since you're a native speaker, but you voted "advanced" and I won't throw away the argumentation Dimitar had against it just for this, it wouldn't be any kind of consensus I think ^^
I can't recall ever encountering the word "Various" in the context of computers/software. I suppose that's the reason it seems weird.
Cheers, Matthew Brush
On Fri, 16 Sep 2011 19:25:39 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
I can't recall ever encountering the word "Various" in the context of computers/software. I suppose that's the reason it seems weird.
I've seen "Miscellaneous preferences", and prefer not to see it again. :) Good thing that my mailer has a spell checker. How is that pronounced is beyond me.
On 09/17/2011 10:17 AM, Dimitar Zhekov wrote:
On Fri, 16 Sep 2011 19:25:39 -0700 Matthew Brushmbrush@codebrainz.ca wrote:
I can't recall ever encountering the word "Various" in the context of computers/software. I suppose that's the reason it seems weird.
I've seen "Miscellaneous preferences", and prefer not to see it again. :) Good thing that my mailer has a spell checker. How is that pronounced is beyond me.
Much more common, though it's often abbreviated to Misc. Pronounced 'Miss-el-lane-e-us' :)
Cheers, Matthew Brush
Hi, BTW I edited the Various prefs label to be more of a warning than a suggestion (just in time for the string freeze).
--- On Fri, 16/9/11, Matthew Brush mbrush@codebrainz.ca wrote:
P.S. Is there any way to make the "Various" tab in
the
preferences dialog stick to the bottom position in
the
notebook so that when tabs are added later,
"Various" is
still at the end?
Probably no enforcible way, but it would be a good
convention. It could be appended last when creating the prefs dialog, and with a comment.
Having thought more, we could enforce this by setting the Various tab position after other dialog creation is done. That way we can still use Glade and then dynamically change tab position.
Isn't the whole dialog created in Glade, except the Terminal tab (for some reason)? I guess it would just take adding the Terminal in the second last position rather than appended on the end if that's the case (plus a comment as you say).
Nick
On Thu, 15 Sep 2011 00:30:44 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
What are the problems with changing use_safe_file_saving? I don't see how the previous value may affect anything.
As you say yourself below, it's a "dangerous" setting because it changes the way the file saving works, and actually "breaks" links, permissions, etc. So yes, this one is a sensitive setting.
Oh, sorry. At the time of the initial various prefs implementation, there were doubts whether changing any of these settings while Geany is running may break something, so that's the first thing which came to my mind...
On Thu, 15 Sep 2011 00:30:44 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
I'm puzzled between adding "annoyance" to the user and preventing her to touch sensitive settings without a good reason.
On Thu, 15 Sep 2011 09:45:55 +1000 Lex Trotman elextr@gmail.com wrote:
Sadly I think warnings are useless, [...] This is a tool for programmers remember, ie us :-)
On Thu, 15 Sep 2011 15:48:31 +0100 (BST) Nick Treleaven nick.treleaven@btopenworld.com wrote:
I don't want to make it hard to use, just more obvious that the user should be careful.
I don't think these settings will or should be changed often, so making the access to them a bit harder shoudn't matter much. However, once the user promises to be careful or whatever, let's give him/her the full page, without horizontal space wasted by an expander, or vertical by a label, or some other widget.
A two-page scheme will require a bit more work, of course, but I have free time ATM. Nick, if you don't feel like writing it, drop me a note and I'll give it a try.
On 15 September 2011 02:47, Nick Treleaven nick.treleaven@btopenworld.com wrote:
Hi, I think there should be a clear warning about changing the new various prefs - e.g. a user might enable use_safe_file_saving and then run into problems.
I'll try to add a warning label and perhaps put the treeview in an expander, collapsed by default. We want to make it obvious that changing those settings should only be done if you know what you're doing.
Sadly I think warnings are useless, no one reads them, and even if they do they then ignore them :-S This is a tool for programmers remember, ie us :-)
I think this change should go through before the string freeze.
If you can do it in time the expander idea is fine IMHO, just don't expect it to have any effect.
Cheers Lex