keyboard handling change

[Lubomir I. Ivanov]

On 1 January 2013 20:38, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> This has been a pet peeve of Linus and mine since we switched to the
> current screen layout with the three areas for divelist, profile and the
> information notebook - if gtk's focus switched to one of the other two
> areas of the window, cursor up/down would no longer switch to the
> previous or next dive.
>
> I just commited some code that grabs a few keys away from gtk whenever
> the main window has the focus. It uses Cursor up/down to switch dives
> and right/left to switch between divecomputers (if you have multiple
> computers for a dive... has anyone besides Linus and me ever tried that?
> The existing key binding of Ctrl-C was just retarded...).
>
> In the current UI design where all editing happens in separate windows
> this works as expected, as we only grab the keys for the main window. If
> we manage to re-enable in-place editing then we need to make sure that
> this doesn't cause problems (as gtk uses up/down for the ability to
> change drop down selections in combo boxes or values in spin buttons and
> of course you need left/right to edit test). So we must make sure that
> we stop stealing these keys once we start editing something (in which
> case simply switching to the next/prev dive wouldn't be a good thing,
> anyway).
>

just sent a patch that tries to fix some small issues with the KB up/down code:
[PATCH] Improvements to select_prev_dive() and select_next_dive()

i was able to produce when importing all test dives with auto-group.
it shouldn't be limited to them only, though.

lubomir
--