Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - deadc0der

Pages: [1]
1
Window / Bug: Window menu doesn't work on OSX
« on: May 19, 2016, 07:55:53 pm »
Hi, I think I found a bug in the OSX version of SFML.

The "Window" menu in the menu bar normally contains the options "Minimize", "Zoom" and "Enter Full Screen", as well as a list of windows. In an SFML program, though these menu items exist, they are greyed out, which also has the unfortunate side-effect that the familiar keyboard shortcuts for these actions don't work either.

I was able to reproduce the problem on a simple program that only creates a window and runs an event loop, and even on all of the examples (except, of course, the command-line ones), which leads me to believe the problem was effectively in SFML.

So, does the problem always happen or is it just on my machine?

EDIT: I tried to associate the "Minimize" menu item with the selector miniaturize: instead of performMiniaturize:. That didn't change anything.

EDIT 2: I was able to get "Minimize" and "Zoom" to work (the items are enabled, and perform the requested function) by associating these menu items with the following custom selectors:
- (void) doMiniaturize: (id) sender {
        [[self keyWindow] performMiniaturize: sender];
}

- (void) doZoom: (id) sender {
        [[self keyWindow] performZoom: sender];
}
 

However, this can't be applied to "Enter Full Screen" and the window list, since these are added by the system (presumably during the call to [NSApp setWindowsMenu]).

I believe the problem is that the menu items target the SFApplication instance, when they should target the current key window (NSWindow does have performMiniaturize and performZoom). However, I don't know how to make the binding such that the target changes when a different window becomes key (apart from overriding the delegate to find out when a different window becomes key, but that seems particularly clumsy).

2
System / Re: Minor bug: U+FFFF not encoded properly in UTF-16
« on: October 29, 2015, 02:29:49 pm »
Should we create a PR for this '=' to add? ;D

That's probably overkill, a single commit push would do :)

3
System / Minor bug: U+FFFF not encoded properly in UTF-16
« on: October 29, 2015, 12:17:57 am »
Hi, I think I found a minor bug. When using sf::Utf16 t encode the Unicode character U+FFFF, it is incorrectly encoded as a surrogate pair, while it should be encoded as a single code unit. For confirmation, RFC 2781, which specifies the UTF-16 encoding, specifies in section 2.1:

Quote
If U < 0x10000, encode U as a 16-bit unsigned integer and terminate.

U+FFFF (0xFFFF) fulfills this requirement, so it should be encoded as a single code unit. However, include/SFML/System/Utf.inl at line 325 encodes a code point into a single code unit only if it is strictly inferior to 0xFFFF, whereas it should be inferior or equal in order to account for the edge-case that is U+FFFF.

Now, since U+FFFF is barely ever used by applications, this is not going to end the world, but I thought it might be good to report it nonetheless.

NOTE: This is my first post on this forum, so I apologize if this is not the right place to post this.

Pages: [1]