[chirp_devel] [PATCH] [RFC] Natively support null-terminated strings in Browser

[Dan Smith]

> # HG changeset patch
> # User Tom Hayward <tom at tomh.us>
> # Date 1490595310 25200
> #      Sun Mar 26 23:15:10 2017 -0700
> # Node ID 50462c735ef1eee2d3bb2bb2c4d0f49fa0a4f2ef
> # Parent  c558e223d37835907823f1804ade6a8bcf0b4594
> [RFC] Natively support null-terminated strings in Browser.
> 
> When a bitwise char array that contains a null character is requsted in the
> Browser, there is an error:
> 
> Traceback (most recent call last):
>   File "/home/tom/src/chirp.hg/chirp/ui/radiobrowser.py", line 313, in _tree_click
>     e = CharArrayEditor(item)
>   File "/home/tom/src/chirp.hg/chirp/ui/radiobrowser.py", line 123, in __init__
>     self._build_ui()
>   File "/home/tom/src/chirp.hg/chirp/ui/radiobrowser.py", line 206, in _build_ui
>     ent.set_text(str(self._element))
> TypeError: Gtk.Entry.set_text() argument 1 must be string without null bytes, not str
> 
> This errors results in the char array contents not being displayed at all. All
> we get is the attribute name.
> 
> Radios commonly store strings shorter than the maximum length with null
> characters filling the remaining space. This is so common that I think the
> browser should be able to display it.
> 
> This patch strips the null characters off the char array so that Gtk doesn't
> freak out. This results in the string being displayed correctly.
> 
> The side effect is that the null characters are discarded on change. If the
> field is edited in the browser, Chirp fills the empty chars with spaces, not
> null characters like were there originally. Visually there is no difference,
> but the stored data are different.
> 
> I don't think this will break anything. Can anyone think of a reason this would
> be a problem?
> 
> Is this complete? Should \xFF be stripped as well? They're visually unpleasing,
> but don't break Gtk like \x00 does.

Seems okay to me. And yeah, if we're displaying as a string we should
probably either filter out the obvious ones (0x00 and 0xFF) or maybe
just filter for printable ascii.

--Dan