Re: RFS: keynav (updated package)

[Wen-Yen Chuang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/05/10 04:28, Daniel Kahn Gillmor wrote:
> The one thing stopping me from uploading now is that the new package
> seems to introduce a system-wide config file, /etc/keynavrc.

The file was introduced by upstream last winter.
If the file is absent, a newly installed keynav will fail to work.
(because no global and local config files).

Older versions of keynav used a default setting when no config file was
found.
I think the better way is:
1. find local config file
2. find global config file if no local one found
3. a fallback default when no config files was found

> So i just want to make sure you're confident that /etc/keynavrc is the
> right filename to use here. For example, if you can imagine a
> system-wide config directory in the future, you might prefer to start
> off with /etc/keynav/keynavrc to avoid cluttering up /etc with more
> files in the future.

"keynavrc" is not a very generic name, so I am ok with /etc/keynavrc.
"/etc/keynav/keynavrc" is good. But I think it should be changed by
upstream so every distributions use the same path.

> * have you offered your keynav.1 manpage upstream?

I have mailed keynav.1 to upsteam on year 2007 (version 20071031 I
think).
I updated the manpage for 20080614.01 to close Debian bug #487023,
but I forgot that if I mailed the newer one to upstream. [1]

> * debian/copyright looks machine-readable. That's great! but it
> doesn't seem to have a Format-Specification: line to indicate what
> version of the machine-readable format you're using.

"debian/copyright" for keynav was written before the DEP [2] starts.
Its specification was a snapshotted proposal on debian wiki, which
gradually become the DEP-5.
Some people complained that the proposal on wiki became too complicated
(in some time-span), so I did not update the format-specification.

I can update it to latest DEP-5 if you prefer it.

> * you're cleaning up a spurious a.out file that the build process
> generates. it looks to me like that file is the result of the ld test.
> you could probably fix that test to avoid creating the a.out in the
> first place, and offer it back upstream for cleanliness.

I have no plan to do it recently. :-P
I will CCed this mail to keynav-users list.

> * keynav.1 doesn't mention the system-wide config file location or
> indicate whether the user's config file overrides the system-wide one.
> it's looks pretty easy to tell from the code, or by experimenting, but
> users shouldn't have to read the code or experiment to figure that out.

The current manpage has this:

CONFIGURATION
You can configure your own key setting. There is an
example in /usr/share/doc/keynav/keynavrc. Copy it to
$HOME/.keynavrc and edit it as you like.

Kind regards
Wen-Yen Chuang

[1] http://www.calno.com/moto/gcin/keynav.1
[2] http://dep.debian.net

- --
My GPG key is signed by Debian Developer Masayuki Hatta.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuQV9cACgkQdEpXpumNYVnzQwCeKSvqBitRnsiXGTdFIM50wfT/
zS0An0VDi4Tb5qm3hqGw89lgDEtJ9Dqr
=Ipea
-----END PGP SIGNATURE-----

[Jordan Sissel]

On Thu, Mar 4, 2010 at 5:01 PM, Wen-Yen Chuang <ca...@calno.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/05/10 04:28, Daniel Kahn Gillmor wrote:
> The one thing stopping me from uploading now is that the new package
> seems to introduce a system-wide config file, /etc/keynavrc.

The file was introduced by upstream last winter.
If the file is absent, a newly installed keynav will fail to work.
(because no global and local config files).

Older versions of keynav used a default setting when no config file was
found.
I think the better way is:
1. find local config file
2. find global config file if no local one found
3. a fallback default when no config files was found

The current behavior is:

- apply global config if it exists.

- apply ~/.keynavrc if it exists.

Currently, if you don't want the global config, your ~/.keynavrc should use 'clear' to wipe all the existing bindings. If you want this behavior to continue, let me know. I think it should go this way: defaults + global + local, that way any step (globla, local) can clear the previous step's bindings.

 

Looks like we don't apply any defaults anymore. I think this is a bug. I'll fix that.

Of course, we could do this instead:

if (local keynavrc) { apply it }

else if (global keynavrc ) { apply it }

else { use defaults }

Let me know what you think would be best.

 

> So i just want to make sure you're confident that /etc/keynavrc is the
> right filename to use here.  For example, if you can imagine a
> system-wide config directory in the future, you might prefer to start
> off with /etc/keynav/keynavrc to avoid cluttering up /etc with more
> files in the future.

The global config file defaults to /etc/keynavrc.

It's set as a macro GLOBAL_CONFIG_FILE that you can redefine at compile time:

CFLAGS='-DGLOBAL_CONFIG_FILE="\"/etc/keynav/keynavrc\""' make 

"keynavrc" is not a very generic name, so I am ok with /etc/keynavrc.
"/etc/keynav/keynavrc" is good. But I think it should be changed by
upstream so every distributions use the same path.

Platforms like FreeBSD are going to want the global config in /usr/local/etc (not /etc), so wherever your distro wants the file is where it should go. See above for targeting keynav at a specific file for the global path.

If you'd like something else tweakable at compile-time, do let me know :)

 

>  * have you offered your keynav.1 manpage upstream?

I have mailed keynav.1 to upsteam on year 2007 (version 20071031 I
think).
I updated the manpage for 20080614.01 to close Debian bug #487023,
but I forgot that if I mailed the newer one to upstream. [1]

If you mailed it to me, I don't think I have it. So, apologies for losing it!

If you've got a manpage, I'd love to put it in the releases if that's where you want it. Feel free to send it to me again.

>  * you're cleaning up a spurious a.out file that the build process
> generates.  it looks to me like that file is the result of the ld test.
>  you could probably fix that test to avoid creating the a.out in the
> first place, and offer it back upstream for cleanliness.

I have no plan to do it recently. :-P
I will CCed this mail to keynav-users list.

Good catch. I hadn't noticed the a.out being produced by the libxdo ld test. I'll fix that in the makefile.

[Wen-Yen Chuang]

Jordan Sissel wrote:
> Looks like we don't apply any defaults anymore. I think this is a
> bug. I'll fix that.
> Of course, we could do this instead:
> if (local keynavrc) { apply it }
> else if (global keynavrc ) { apply it }
> else { use defaults }
> Let me know what you think would be best.

I am ok with either case.

I attached the manpage currently included in Debian package.
It is not updated since 2008, though.

Kind regards
Wen-Yen Chuang

[Jordan Sissel]

Thanks! I'll update it with the latest changes and put it in the next release.

-Jordan

Kind regards
 Wen-Yen Chuang

--
You received this message because you are subscribed to the Google Groups "keynav-users" group.
To post to this group, send email to keynav...@googlegroups.com.
To unsubscribe from this group, send email to keynav-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/keynav-users?hl=en.

[Daniel Kahn Gillmor]

On 03/04/2010 11:03 PM, Wen-Yen Chuang wrote:
> Jordan Sissel wrote:
>> Looks like we don't apply any defaults anymore. I think this is a
>> bug. I'll fix that.
>> Of course, we could do this instead:
>> if (local keynavrc) { apply it }
>> else if (global keynavrc ) { apply it }
>> else { use defaults }
>> Let me know what you think would be best.
>
> I am ok with either case.

Personally, I like the idea of:

* a built-in set of defaults, which can be piecewise overridden by:

* a system-wide config, which can in turn be piecewise overridden by:

* a per-user config

Particularly if each config is capable of explicitly "clear"ing all
previous configurations, or unbinding particularly undesirable default
configs.

I like this because:

* distributors don't need to provide the system-wide config file at all
(maintaining shipped, admin-editable configs which change across
upgrades is a hassle)

* users without configs will see reasonably consistent behavior across
systems.

* system administrators *can* provide nuanced system-specific tweaks if
they feel the built-in defaults are suboptimal for their system, without
requiring every user to make a change, and

* users are ultimately in control of their own tools.

so the only question i suppose i have is: "what does piecewise mean?"

For example, if the default is to bind key X to action foo, and key Y to
action bar, and one of my overriding configs says "bind X to bar", does
that wipe out both default configs? or just the first? I'd prefer the
former semantics, alongside a "clear all" and an "unbind key Y" (or
their equivalents).

To be clear: i'm stating my gut preferences here, but would be happy
with any reasonable (and reasonably documented) implementation.

Regards,

--dkg

[Jordan Sissel]

On Thu, Mar 4, 2010 at 9:05 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:

On 03/04/2010 11:03 PM, Wen-Yen Chuang wrote:
> Jordan Sissel wrote:
>> Looks like we don't apply any defaults anymore. I think this is a
>> bug. I'll fix that.
>> Of course, we could do this instead:
>> if (local keynavrc) { apply it }
>> else if (global keynavrc ) { apply it }
>> else { use defaults }
>> Let me know what you think would be best.
>
> I am ok with either case.

Personally, I like the idea of:

 * a built-in set of defaults, which can be piecewise overridden by:

 * a system-wide config, which can in turn be piecewise overridden by:

 * a per-user config

Particularly if each config is capable of explicitly "clear"ing all
previous configurations, or unbinding particularly undesirable default
configs.

 

<snip>

 

so the only question i suppose i have is: "what does piecewise mean?"

For example, if the default is to bind key X to action foo, and key Y to
action bar, and one of my overriding configs says "bind X to bar", does
that wipe out both default configs?  or just the first?  I'd prefer the
former semantics, alongside a "clear all" and an "unbind key Y" (or
their equivalents).

I like this approach, so I should clarify the existing behaviors.

First, 'clear' will wipe any prior bindings. So a ~/.keynavrc with 'clear' at the top will erase all the defaults and global configs. Likewise, a 'clear' in the global config will wipe the default bindings.

Second, the last binding seen for a given key stroke will win. So if the order of loading is defaults, global, local, you could define key 'j' in all three places, but the local config's bindings will win, replacing the binding with whatever was in the local config.

Lastly, I'm happy to implement an 'unbind <key>' option.

-Jordan