Re: [Notion-general] Handling changes in the default configuration

[Jeff B. <jef...@gm...>]

Hi folks,

Sorry, been meaning to chime in since Arnout sent his initial e-mail.  
Been swamped. Therefore, I'll go ahead and respond to both in one. :)

On Sat, Jul 05, 2014 at 12:07:08AM -0700, Dima Kogan wrote:
>Arnout Engelen <ar...@bz...> writes:
>
>> I think a good out-of-the-box experience (i.e. good default settings)
>> is hugely important. On the other hand, a stable, hassle-free upgrade
>> path for existing users is equally essential.

Agreed on both accounts, though my preference is don't muck with the 
user's custom settings just because we think we know better. It can be 
quite aggravating to have behavior change without a warning. :)

Maybe ship with a conservative set of config files (like we do now) and 
a "new hotness" set, and encourage new users to use the "new hotness"? 

>> Is anyone aware of any applications that solve this tension 
>> gracefully?
>> I.e. by prompting users on upgrade, perhaps telling them what changed and
>> asking them whether they want to accept that change in their configuration?

Unfortunately, this is a lot easier for most programs, as they have a 
very finite "config domain", whereas Notion's config domain is not very 
finite due to fact that options are variables set via Lua scripts. We 
might be able to better automate handling changes to the config domain 
if we used a "config manager" or similar construct. i.e. instead of:
  focuslist_insert_delay = 5
do:
  conf_manager('focuslist_insert_delay', 5)
which would allow us to better track how a user is configuring Notion 
and to notify them of useful changes specific to their use-case. (With 
apologies to Dima's new feature - I have no idea how it works or how to 
configure it. O:-) )

Another option might be to provide the user with a way to dump the Lua 
namespace and compare it against the "new hotness". Not very graceful, 
or user-friendly, though.

>I don't know of any ways to handle this on a distro-independent basis.
>Since each distro handles installation and management of configuration
>files differently, there likely isn't anything that "just works" for
>everybody. This is a bit unsatisfying, but I think each distro
>maintainer has to handle the announcement of potentially-breaking
>changes themselves.
>
>Debian has NEWS.Debian files to do this:
>
> https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-news-debian
>
>We haven't yet released the new Debian packages with the changed
>defaults, but we'll use this when we do.
>
>For from-source installs, we should probably have a very loud
>announcement in the CHANGELOG. We currently do mention the change in
>that file, but it should probably be highlighted.
>
>Anybody got better ideas?

Actually, a simple way we might be able to approximate Debian's NEWS 
files on a distro-independent basis is to maintain a similar file gets 
tucked away somewhere on the system. When Notion starts, it check 
~/.notion to for the file. If it doesn't exist or differs then Notion 
could display the contents of the system-wide one then save a copy in 
~/.notion, similar to what happens with the welcome message for new 
users.

If we gzip or bzip2 the file, it should be pretty small and a binary 
comparison should be pretty quick.  Plus, it wouldn't be dependent on 
version numbers (i.e.  supports installing from git), as long as we were 
diligent about updating it as we hack away at the codebase.

The location of the system-wide file may need to be a compile option to 
allow flexibility distro to distro and source installs. I dunno, just a 
thought.

Oh, and Arnout, I do like the idea of adjusting the default key 
bindings, at least for new users and those wanting to switch. Function 
keys have unfortunately become part of the standard UI lexicon and it 
can be quite confusing to new users when they can't use them without 
additional key strokes. Particularly since one of Notion's selling 
points is "hey, that silly mouse thing is optional!" :)

Regards,
Jeff