Philipp Lohmann - Sun Germany wrote:
First i must apologize for answering so late. For some reason i only got
your original message now, after that CWS is integrated. Sorry.
eric.bachard wrote:
Instead of changing the independent vcl part so it fits the dependent
part you should rather achieve that KEY_MOD2 ist only sent when it
ought to. If this means you need another internal modifier with the
vcl/unx part, fine,
As you probably know, on Mac OS X, we don't use the keyboard as
expected. In our case, we use Apple, key, exactly like CTRL key , but
this is a complete workaround: just a logical "OR" between the two keys.
None is satisfied with current behaviour: use Apple key a different
way as described in Aqua Human Interface Guidelines is a non sense for
Mac users, because the Mac OS X feeling is not respected.
This is something very very important. You can believe me.
If this is important, then please explain what exactly it is the user
expects
and that is currently not working.
1) remap ALT key (very urgent ) : IMHO done in macosxkbd
2) remap Apple key as expected, and respecting Aqua Human Interface
Guidelines : TODO
Waiting a better solution, I decided to
a) use mod5 (this modifier is confirmed without issue)
b) continue to investigate , the time to understand if a complete *Mac
only* solution can be found.
Of course, if modifier 2 is enough, no problem to use it again :-)
but i think it's a really bad idea to put that into the independent
part #ifdef'd with MACOSX.
I just wanted to protect all other OS's arch's from my changes.
Yes there are some instances of #ifdef MACOSX (or UNX for that
matter) already in the independent part, but we should make them
less, not more.
What I perfectly understand.
Besides KEY_MOD5 does not seem to have any use outside of vcl either.
Worse, KEY_MOD5 is only defined in the MACOSX case of keycodes.hxx.
Yes, I did this choice to be sure, it breaks nothing else.
But it does. If it only changed the VCL API, that wouldn't be a problem,
but the numerical KeyCodes go into documents - at least that was the
problem why the original issue 11004 was not integrated. I hope that mba
has a comment on that. By changing the KeyCodes the way you do you break
macros in existing documents on the mac and also by new documents
produced on the mac and read somewhere else.
This is an exported header and should be system neutral like all the
others except sysdata.hxx which is system dependent by definition.
I don't think this patch is a good idea.
If you have any suggestion, please do. In fact, the work is not finished.
If you need a KEY_MOD5 (why by the way MOD5 ? the original patch
contained a new KEY_MOD3 which would be more logical), then the #ifdef
in keycodes.hxx at least will have to vanish. It would not be good to
litter the whole code beyond vcl with them.
Also the matter of document compatibility will have to be addressed;
whether there is such a problem and if yes how to solve it right. I hope
mba or cd has a comment on this.
Hi Eric and Philipp,
Fortunately we store no numerical values for the keyboard configuration
in documents. Instead we use predefined strings which will be mapped to
the correct com.sun.star.awt or VCL key code (e.g. "KEY_A" => keycode
0x0030). Therefore I don't see a problem changing the identifier.
Creating a new identifier can only work for new version. Older version
should ignore these identifier, although I am not completely sure. You
can find the sources for the keyboard shortcuts here:
framework/source/xml/acceleratorconfigurationreader.cxx
framework/source/xml/acceleratorconfigurationwriter.cxx
framework/source/accelerators/keymapping.cxx
Regards,
Carsten
-------
OpenOffice.org Framework Co-Lead
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
