Custom Query (1067 matches)


Show under each result:

Results (16 - 18 of 1067)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ticket Resolution Summary Owner Reporter
#1341 fixed Remove autotools support KaZeR kazer
Description We switched to CMake a while ago, and only some specific ports seems to require autotools now.

We should remove autotools support in a branch to ensure that it does not break something else, and merge in trunk once confirmed.

See also #1144
#1340 fixed Ensure that the CSV plugin does not throw useless errors KaZeR kazer
Description We've got report of erroneous errors thrown by the csv plugin

{{{error: navit: attr_data_size: size for item_type unknown}}}

Full discussion here :

We should write some tests for the CI workflow, and ensure that we don't throw useless errors.
#1339 fixed Town search: Hide OSD keyboard keys instead of highlighting sleske sleske
Description In the address search dialog of the internal GUI, the OSD keyboard
currently (tries to) provide hints by highlighting "possible" keys
(keys that will provide results if pressed next).

Unfortunately, this feature does not work well when the OSD keyboard is
operated using cursor keys or a rotary encoder (implemented recently):
The hint highlighting and the keyboard focus highlighting collide, and
since un-highlighted keys remain accessible, navigating the keyboard
requires many keypresses.

To improve this, greg42 provided a patch to completely hide (and
disable) not possible keys, instead of highlighting possible keys.
The patch was originally part of [ pull request #5] on GitHub; it is now
available in branch pr-5-hide-keys.


One problem remains to be solved before merging this patch:

The search is case-insensitive and accepts unaccented for accented
letters (i.e. it finds results with é for input e, or with ü for input u
[but not vice versa]).
The possible keys highlighting does not follow this behaviour. For
example, in the town search in Germany, the input "Mul" or "mül" will
find "Mülheim", but the "h" key will not be highlighted.
Similarly, if the next possible key is an accented letter, the
corresponding un-accented key is not highlighted. Example: Search input
"Schl" will find "Schlüterstraße", but "u" will not be highlighted (this
bug occurs less often, because often there will be another result with
the un-accented letter - "u" in this case - so highlighting still

Currently, this only means that key highlighting is incomplete. However,
with the patch applied these keys will be hidden instead, even though
they would produce a result - which in turn can mean that some results
cannot be obtained via the OSD keyboard, forcing the user to go through
the list.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note: See TracQuery for help on using queries.