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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitted by:  julian <julian_>
Submitted on:  Sat 05 Nov 2011 10:29:07 PM UTC  
 
Category: Base/FoundationSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: None
Open/Closed: Closed

(Jump to the original submission 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>
Project 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>
Project 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>
Project 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>
Project 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_>

 

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
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by FredKiefer (Posted a comment)
  • -unavailable- added by julian_ (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 07 Nov 2011 09:33:03 AM UTCFredKieferCategoryGui/AppKit=>Base/Foundation
      StatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Mon 07 Nov 2011 09:29:46 AM UTCCaSCategoryBase/Foundation=>Gui/AppKit
    Mon 07 Nov 2011 09:12:56 AM UTCCaSAssigned toCaS=>None
    Sun 06 Nov 2011 09:48:09 PM UTCFredKieferCategoryNone=>Base/Foundation
      Item GroupNone=>Bug
      Assigned toNone=>CaS
    Sat 05 Nov 2011 10:29:07 PM UTCjulian_Attached File-=>Added gnustepbug-keyequiv.zip, #24308

    Back to the top


    Powered by Savane 3.1-cleanup1