Comment 1 Andre Klapper 2008-12-05 14:41:09 UTC

http://maemo.org/maemo_release_documentation/maemo4.1.x/Maemo_Diablo_Reference_Manual_for_maemo_4.1.pdf
, Section 6.6.3 Hardware Keys


That's not a bug, but a design decision. Feel free to provide an example which
external keyboard keys should be used instead for the N8x0 hardware keys if you
are not content with the current collection.

In GNOME, Open Menu is F10 and Full screen view is F11.

(In reply to comment #1)
> That's not a bug, but a design decision. Feel free to provide an example which
> external keyboard keys should be used instead for the N8x0 hardware keys if you
> are not content with the current collection.

Gnumeric Example:
F3 - Open
F5 - Goto Cell (Can't use in Maemo)
F6 - Search&Replace (Can't use in Maemo)
F7 - Search (Can't use in Maemo)
F9 - Recalculate

> In GNOME, Open Menu is F10 and Full screen view is F11.
Similarly in Windows. Yet, F1-F9 are normally left to the applications. Making
them perform special functions makes it more difficult to port and use Gnome
applications, such as Gnumeric, etc.

Comment 3 Andre Klapper 2008-12-09 16:03:33 UTC

Hmm, I asked for a proposal that I haven't seen yet here...

Please confirm that this is the *full* list of keys you complain about:
    Open menu                         F4 GDK_F4
    Full screen                       F6 GDK_F6
    Increase / Zoom in / Volume up    F7 GDK_F7
    Decrease / Zoom out / Volume down F8 GDK_F8

> F5 - Goto Cell (Can't use in Maemo)
Any idea why this does not work? What happens in Maemo? Just "nothing"?

Even if we move F4 to F10 and F6 to F11, we still only have F12 left.
I wonder whether to map F7 to Control+plus and F8 to Control+minus.

(In reply to comment #3)
> Hmm, I asked for a proposal that I haven't seen yet here...
I am proposing to create new definitions for hardware keys that do not
intersect with any existing GDK_* definitions in GTK. Something like:

GDK_MAEMO_MENU
GDK_MAEMO_HOME
GDK_MAEMO_FULLSCREEN
GDK_MAEMO_INCREASE
GDK_MAEMO_DECREASE
GDK_MAEMO_SELECT

> Please confirm that this is the *full* list of keys you complain about:
>     Open menu                         F4 GDK_F4
>     Full screen                       F6 GDK_F6
>     Increase / Zoom in / Volume up    F7 GDK_F7
>     Decrease / Zoom out / Volume down F8 GDK_F8
Also:

Show Home F5     GDK_F5
Confirm   RETURN GDK_RETURN

The GDK_RETURN binding becomes problematic because some BT keyboards (like
Apple BT keyboard) generate GDK_RETURN when the ENTER key is pressed.

> > F5 - Goto Cell (Can't use in Maemo)
> Any idea why this does not work? What happens in Maemo? Just "nothing"?
In Maemo, GDK_F5 is the HOME hardware key.

> Even if we move F4 to F10 and F6 to F11, we still only have F12 left.
> I wonder whether to map F7 to Control+plus and F8 to Control+minus.
As mentioned above, I suggest to create a whole new set of numeric key codes
that do not intersect with existing GDK_* key codes. These hardware keys are
new keys, not the same as ones found in normal keyboards, so it makes no sense
to map them to normal keyboard key codes.

Comment 5 Andre Klapper 2008-12-10 17:12:15 UTC

But F5 normally works for you? I'm a bit surprised because of bug 2182.

(In reply to comment #5)
> But F5 normally works for you? I'm a bit surprised because of bug 2182.
I have no idea. Bug 2182 is reported for the Scratchbox Hildon environment, not
for the real device. I have not used SB1 for months and do not even have it
installed.

The idea of this bug (3913) is that F-keys perform application-dependent
functions in non-Maemo GTK-based software and thus should not be mixed with
Maemo hardware keys.

(In reply to comment #6)
> The idea of this bug (3913) is that F-keys perform application-dependent
> functions in non-Maemo GTK-based software and thus should not be mixed with
> Maemo hardware keys. 

I'd support treating the tablet keys similar to special function keys in
multimedia-keyboards (Full Screen, Zoom in and Zoom out and Power are not
uncommon there) without overlapping with the generic function keys.

I know there is useable support for this kind of keys in KDE and assume there
should also for Gnome/GTK. One resulting question is how to simulate them in
scratchbox then!

Comment 8 Quim Gil 2008-12-18 13:36:40 UTC

This request is now listed at
http://wiki.maemo.org/Mainstream_Linux_Alignment#freedesktop.org_level

Is there any related freedesktop.org reference followed by GNOME/KDE? That
would help.

Comment 9 Mohammad Anwari 2008-12-18 16:11:22 UTC

Moved to core. This is not input method area.

Comment 10 Quim Gil 2008-12-18 16:36:05 UTC

Eero, any comments?

Comment 11 Eero Tamminen 2008-12-18 17:39:57 UTC

(In reply to comment #10)
> Eero, any comments?

The proposal of not using generic F-keys is fine and I think we should do this
at some point (it has been discussed earlier internally).

It will require:
- changing the HW key mappings in kernel (and/or in X?)
- changing the corresponding defines in the Hildon header
- re-compiling all applications (also 3rd party ones) which use this header
- fixing the code in applications which don't use this header
  (I don't think e.g. any of the 3rd party SDL games to use Hildon header
files)

It would be nice to have this in Fremantle, but somebody needs to specifically
drive it internally as this is an API break, not just a bug.

Comment 12 Quim Gil 2008-12-18 18:42:00 UTC

Mmm... considering how busy are already the teams working on Kernel, Xorg and
Hildon I prefer not to raise this (unplanned) flag right now for Fremantle.

However, we have time to do the right thing for Harmattan. Assigning t me while
I find the right godfather.

Comment 13 Quim Gil 2008-12-30 11:46:27 UTC

This is not Busybox. Moving to Kernel since this is the first component where
the work needs to be done.

Additional clarification about the RETURN key:

Current version of Maemo binds GDK_Return to the DPad center button, while
binding GDK_KP_Enter to the real RETURN key. This is wrong, as it interferes
with external keyboards which report their RETURN keys as GDK_Return.
Specifically, the following two scenarios occur:

1. If a developer processes GDK_Return and GDK_KP_Enter equally, the users will
accidentally press DPad center button while navigating (it is easy to press
accidentally) and mess things up.

2. If a developer explicitely disables GDK_Return processing in his
application, the DPad navigation becomes safe, but the RETURN keys on external
keyboards no longer work.

Proposed solution is to create a new binding for the DPad center button and
assign GDK_Return to the proper RETURN key on the keyboard. GDK_KP_Enter should
only be used for extra keypad keys.

Additional clarification about the RETURN key:

Current version of Maemo binds GDK_Return to the DPad center button, while
binding GDK_KP_Enter to the real RETURN key. This is wrong, as it interferes
with external keyboards which report their RETURN keys as GDK_Return.
Specifically, the following two scenarios occur:

1. If a developer processes GDK_Return and GDK_KP_Enter equally, the users will
accidentally press DPad center button while navigating (it is easy to press
accidentally) and mess things up.

2. If a developer explicitely disables GDK_Return processing in his
application, the DPad navigation becomes safe, but the RETURN keys on external
keyboards no longer work.

Proposed solution is to create a new binding for the DPad center button and
assign GDK_Return to the proper RETURN key on the keyboard. GDK_KP_Enter should
only be used for extra keypad keys.

Comment 16 Frantisek Dufka 2009-02-10 15:42:27 UTC

Just to confirm that this is indeed not solved in Fremantle. Kernel for RX-51
has hardcoded mappings for F6, F7 (real buttons) and F8,F9,F10 (reserved but no
row/column mapping = virtual keys, F9 and F10 are generated in camera button
driver, not found F8 anywhere).

So it looks like F4,F5 are gone but we may have clash with F9/F10 now :-)

Personally this bothers me too while running midnight commander in osso-xterm -
you press F7/F8 on bluetooth/usb keyboard to mkdir/delete and it will change
terminal font size instead :-) Similar for other keys (F4 pops osso-xterm menu,
F5 does nothing at all, F6 toggles full screen).

Comment 17 Andre Klapper 2012-03-24 11:37:53 UTC

The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia and it seems that there are no
plans for official updates currently, hence nobody plans to work on this
enhancement/wishlist request. 
(And in case you feel like discussing this situation: Nokia Customer Care or
http://talk.maemo.org would be the place to do so as you will not reach Nokia
officials in this community bugtracker - though all of this is really no news.)

Reflecting this status by setting RESOLVED WONTFIX for this
enhancement/wishlist request (see
https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations).

There is a small chance for issues in those Maemo components that are open
source: Contributed patches could be included and made available in the Maemo 5
Community CSSU updates. 
The Maemo CSSU project is run by a small team of volunteers; see
http://wiki.maemo.org/CSSU for more information.
So in case that you can provide a patch that fixes the reported problem, please
feel encouraged to file a request under
https://bugs.maemo.org/enter_bug.cgi?product=Maemo%205%20Community%20SSU .
Please note: The Maemo CSSU project is not related in any way to Nokia.


( Tag for mass-deleting bugmail: [cleanup20120324] )