On 2013-11-06 12:47 PM, intrigeri wrote:
>> Whenever a configuration option is changed in the prefs dialog, the
>> entire file is re-written. #LazyProgramming
>
>> Should I do something different there?
>
> I suggest loading the config file when the prefs dialog is open.
> Monitoring changes of the config file seems overkill, but at least not
> destroying manual config seems useful. Anyway, that's certainly not
> high priority :)
It's not monitoring the config at all. When an option in the prefs
dialog is changed/toggled the file is overwritten with the current
configuration state.
The only time the file is actually read is... oh look at that... every
*tick*, shoot. That's not how I intended it. Darn it.
File will be read at startup and when the prefs dialog is opened. All
changes will continue to happen immediately and get written immediately.
>>> * When the locale doesn't support AM/PM, why not simply hide the
>>> config option in the prefs dialog, instead of locking it?
>>> That may be only me, but I generally feel weird when I'm shown some
>>> piece of UI that I can't interact with.
>
>> I'm not a fan of hidden options just because my locale doesn't support
>> the feature.
>
> OK, then let me rephrase: what's the use or advantage of showing me an
> "option" that I can't change?
I don't know that there is an advantage. In any case, the option will be
hidden instead of deactivated as you've suggested... which I'm totally
fine with :)
>> For some unknown reason, printing to stderr did not show up for me in
>> ~/.xsession-errors.
>
>> As for why debug is on by default, right now I'd like to ensure that
>> when someone tests and has a bug with the formatting or whatnot, they've
>> got something they can add to the bug report.
>
>> 0.5 will be a bugfix build without debugging and if that's all good then
>> we'll finalize and jump to a 1.0 actual release.
>
> Makes sense.
Groovy, cheers!
--
Kevin C. Krinke <kevin@???>
GnuPG - 851662D2 - 0x18C67F61851662D2
http://kevin.c.krinke.ca/851662D2.asc