A reasonable consideration. Keep in mind, there have been only 2 inquiries about this column before now, back in 2009. (on IRC)
It seems the discoverability by accident, even with people trying to resize the balance column (and expanding the rate column instead) is very low. And since this is “use at your own risk” free software, the devs are exempt from blame anyway. Perhaps there can be something on the wiki as a reference should someone go searching for it specifically, but not made prominent so as not to encourage fiddling. Regards, Adrien > On Aug 20, 2018, at 1:49 PM, GT-I9070 H <[email protected]> wrote: > > Em seg, 20 de ago de 2018 às 14:01, Derek Atkins <[email protected]> escreveu: > >> IMHO, the column does not need to be documented becuase it is a >> non-servicible part. It exists the way it does because that was the >> easiest way to get the register to store the meta-information about a >> rate. It exists as a 1-pixel column because that's the narrowest you can >> make it. There's no way to hide it absolutely completely, and duplicating >> the functionality in a different way didn't make sense when this way was >> available. >> >> I see no reason to document it, because it should not be editable by a >> user. >> I see no reason to document it, because in 99.9% of use cases, a user will >> not even be aware that it's there. >> I see no reason to document it, becuase if someone DOES see it in the >> documentation and does try to look for it and does find it and does try to >> meddle with it, they can do some pretty strange damage to their data. >> >> Anyways, that's my $0.02. >> >> Don't bother to even mention it; it's not worth your time to document >> something that users wont (and shouldn't) see or touch. >> >> -derek >> > > Here are my $0.0001, > > I use this rate column for a long time and I particularly find it very > useful to be able to see it to know quickly if it are filled correctly. > > If the column is there and can be displayed and it has already been > discovered, it poses a risk to the uninformed user. > > Perhaps the information should be documented with Derek's important and > critical observations. That would be better than a misinformation accident. > Myself even took the risk of damaging my data, and I just learned that now. > > The information exempts the devs from blame. > > > Regards > GTI > _______________________________________________ > gnucash-user mailing list > [email protected] > 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 [email protected] 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.
