2008/4/22, Douglas S. Blank <dblank@...>:
> > Doug,
> >> As suggested, I've made an "invalid-date-format"
> >> config key in trunk 10618 so
> >> that you can make invalid dates appear however you
> >> wish. The default is
> >> bold.
> > Sometimes I feel we are a bit too cavalier with the
> > configuration options. In my experience, I have often
> > found that when I am tempted to add a configuration
> > option, what I am really doing is avoiding the work of
> > figuring out the best implementation.
> Hmmm... this sounds familiar. This discussion did not go well before...
> Think of the config setting as a global variable that happens to be in a
> single place with all of the other globals. The idea of a global is a
> programming paradigm that has its place. Having all error colors in a
> single place is good thing, I think.
> > While configuration options seem like an inexpensive
> > flexible solution, they often turn out to be a source
> > of unnecessary complexity.
> import Config
> var = Config.get(Config.VAR)
> That's most of the complexity.
> > Additionally, if you don't expose this configuration
> > option in the user interface, approximately 0.1% of
> > users will ever use it.
> Currently, that is true. 0.1 may not sound like a lot, but when the
> developer is that person, it gives a certain motivation to scratch that
> itch :)
> > In my experience, configuration options should be used
> > to change the behavior of an application, not its
> > appearance (I know we already have some options that
> > violate this).
> I think that there are some appearance items that are borderline behavior.
> Error display is, I think, important enough to warrant this.
> > What do others think? Is this feature best served with
> > a hidden configuration option? Is there a method that
> > could be *almost* universally accepted that would not
> > require a configuration option?
> Perhaps this new default (bold) will be fine for all. But then it doesn't
> matter if it is a Config or a const: the code will be pretty much
> Also, I am hoping that we will someday have a nice GUI to change all
> config settings. So then none will be hidden, and we won't have to make
> any distinctions between ones in the GUI vs. hidden ones.
> One last point: creating a config setting usually causes a refactoring
> around the new point of abstraction, which is a good thing. For example,
> there is currently a string "Gramps_3.0_Wiki_Manual" that is used in 26
> files. What happens when that becomes 3.1? Is that more of a problem than
> having a config option?
When I added that, it was unclear to me how it should be used in different
places, now I know, and indeed that string can move to the const module, and
obtaining the string in the GrampsDisplay help routine, not to config
I guess at the time 3.2 will be made, I or somebody else will do that.
Should I add the manual links, I would have changed it already, but Erik
(thanks!) is doing most of this work and doesn't mind about it. Anyway, this
is not related to the config question.
About the config option for dates, I am of the thinking of Brian, that it
would be best to have one interface for all, so find one good
implementation, instead of a config option nobody changes.
Now that the date is bold, we will obtain the question: 'Why do I see a bold
date', although opening an editor and seeing it turn red, should explain it,
so it is somewhat self explanatory, which is good.
I agree also the bold is better than the color to indicate this in view of
themes/color blind. I would hence do away with the config option (however
nice the freedom), and let it be bold for everybody. The reasons:
1/config option is not visible
2/difficult config option, people need to know gtk markup, this is not how
it could be presented in a option screen. I suppose it can even crash
3/if you as a developer have an itch, you can put the setting of markup in a
utility function reused in all places (if you did not implement it already
like that), and change the setting there once for yourself. It is python, no
need to recompile.
4/if people complain about the bold, we can add a config option then,
combined with the reusable function from 3/ this is easy, and implement a
correct way of setting this value, which would not be to let users enter a
string containing %s.
To end, this function is reusable for other data, and is not limited to
invalid date, eg, one can indicate invalid latitude/longitude in the same
manner, I would even ask you to implement that. It would hence be a function
to indicate invalid data in a treeview, whereas the editor use the markup
data entry to show this.