bugGNUstep - Bugs: bug #34754, gnustep only supports some...

Group
 
 

bug #34754: gnustep only supports some "key equivalents (shortcuts)"

Submitter:  julian <julian_>
Submitted:  Sat 05 Nov 2011 10:29:07 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 07 Nov 2011 12:01:35 PM UTC, comment #7: 

i've sent a bugreport to apple about the XIB format not being documented:

http://openradar.appspot.com/radar?id=1428402

julian <julian_>
Mon 07 Nov 2011 11:43:41 AM UTC, comment #6: 

thanks i can confirm the "enter" shortcut works in my app now.

julian <julian_>
Mon 07 Nov 2011 09:33:03 AM UTC, comment #5: 

Thank you, this change fixed the problem for me. I will close the bug report and later add the default into back to support the AltGr key directly.

As far as I know there is no specification for the XIB file format. All I know about it I learned by inspecting existent XIB files. The format seems to changed for each version of XCode.

Fred Kiefer <FredKiefer>
Group Member
Mon 07 Nov 2011 09:12:56 AM UTC, comment #4: 

Is there any specification for the XIB format?

I ask because 'DQ' does not conform to the standards for base64 encoding as a base64 encoded string is supposed to be a multiple of four bytes.

I've modified GSMime to tolerate short strings (by simply acting as if the missing bytes had been the normal '=' padding characters), since our general principle is to be tolerant of errors in input rather than strictly enforcing standards.

This will probably get things working, but I don't know that it's the correct thing to do here.  Maybe the gui code ought to add any necessary '=' padding before decoding, to make the string legal base64 encoded data.  On the other hand ... whats the point of doing that if I've made the decoding work 'correctly' when given bad data?

Richard Frith-Macdonald <CaS>
Group Member
Mon 07 Nov 2011 09:12:41 AM UTC, comment #3: 

I wrote a short test on Cocoa and this rules out the possibility to remove the trailing zeros in NSString. When creating an NSString from an NSData all trailing zeros are preserved.

We need to remove them either in the Mime conversion or in the XIB loading code.

Fred Kiefer <FredKiefer>
Group Member
Sun 06 Nov 2011 11:38:18 PM UTC, comment #2: 


>The simplest thing to do is to set the default for GSSecondAlternateKey to ISO_Level3_Shift and that button will just work.


interesting! yes i am using a german keyboard so thats probably the bug here.
i actually don't use alt-anything as shortcut, i was just experimenting a bit for sake of the bugreport and noticed this didn't work either.
+1 for sane defaults which actually work ;-)

>The second problem is a bit harder to resolve.


interesting as well, thanks for the explanation. sounds like an easy fix ;-)

julian <julian_>
Sun 06 Nov 2011 09:48:09 PM UTC, comment #1: 

There are two different issues here.

For the button where you use Alt-s as the key shortcut the most likely problem is that you have a different key assigned to Alt than you expect. The Alt key gets defined with the default values  GSFirstAlternateKey and GSSecondAlternateKey, with XK_Alt_R getting used as the default. (See the documentation of back for details on this) The reason why we use XK_Alt_R but not XK_Alt_L is that we use the later for the even more important command key, which has no proper equivalent on a PC keyboard. Now if you like me are using a german keyboard there wont be any XK_Alt_R key on it. The right Alt key is AltGr and this gets mapped to XK_ISO_Level3_Shift. The simplest thing to do is to set the default for GSSecondAlternateKey to ISO_Level3_Shift and that button will just work. We could think about having this setting as a default in GNUstep, it would make live easier, at least for me.

The second problem is a bit harder to resolve. The 'return' key equivalent setting is stored in the XIB file as:
<string type="base64-UTF8" key="NSKeyEquivalent">DQ</string>

That is an NSData object with the value <4451>, as this is UTF8 base64 encoded, we need to convert it into something usable. This code tries to do this conversion:
if ([type isEqualToString: @"base64-UTF8"])
        {
          NSData *d = [new dataUsingEncoding: NSASCIIStringEncoding];
          d = [GSMimeDocument decodeBase64: d];
          new = AUTORELEASE([[NSString alloc] initWithData: d
                                                  encoding: NSUTF8StringEncoding]);
        }

The intermediate result is an NSData containing <0d0000>. This is almost the 13 we expect for 'return' but followed by to zero bytes. Later one when we compare the characters from the key event with this string the test fails as they have a different length. This of course is bad and should not happen. We should always end up with a minimal string, that is training zeros should get cut off. I have assigned this bug report to Richard so he gets aware of this problem. I think he is the best person to suggest a solution as we could either cut of the zeros in the local XIB code, do it in the Mime conversion code or in NSString.



Fred Kiefer <FredKiefer>
Group Member
Sat 05 Nov 2011 10:29:07 PM UTC, original submission:  

attached is a small sample application with a window with three buttons.

those buttons have their "key equivalents" (shortcuts) set in interface builder to be able to trigger the keys from the keyboard.

triggering the button with the shortcut key "s" works fine under gnustep, so the feature and decoding it from XIBs seems to work in principle.


triggering the button with the shortcut key combination "alt-s" doesn't work.


triggering the button with the shortcut key "return" doesn't work either.

there is another bug visible here too. giving an button the key equivalent "return" automatically makes the button the "default" button, which is drawn "boldly", however this doesn't seem to work under gnustep.

here is a screenshot that gives you an idea of the visual difference normal and default button:

http://devfiles.myopera.com/articles/901/mac_install_customise.png

julian <julian_>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #24308:  gnustepbug-keyequiv.zip added by julian_ (108KiB - application/zip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by julian_ (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-11-07 FredKiefer CategoryGui/AppKit Base/Foundation
        StatusNone Fixed
        Open/ClosedOpen Closed
    2011-11-07 CaS CategoryBase/Foundation Gui/AppKit
    2011-11-07 CaS Assigned toCaS None
    2011-11-06 FredKiefer CategoryNone Base/Foundation
        Item GroupNone Bug
        Assigned toNone CaS
    2011-11-05 julian_ Attached File- Added gnustepbug-keyequiv.zip, #24308

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code