Author Topic: SFML 2 for OS X comes true! (Read 95650 times)

Ceylo · « **Reply #120 on:** February 11, 2011, 09:27:31 pm »

And do key events work fine with SFML 1.6 ? Compared to what's being done for SFML 2 ?

Hiura · « **Reply #121 on:** February 14, 2011, 12:47:55 am »

Quote from: "Ceylo"

And do key events work fine with SFML 1.6 ?

Nope, sorry. At least not with my swiss keyboard. I just reinstall 1.6 (not trunk) and can confirm the following :

> keys pressed with shift and without shift don't produce the same event.

> I've 2 unbound keys ¨ and ^ .

> the 'fn' key produce an event but shouldn't.

> Without using shift I've got 7 keys sending event with keycode = 0, and 10 when shift is down.

> Thus I haven't access to all keys of the enum.

Ceylo · « **Reply #122 on:** February 14, 2011, 11:37:35 am »

Quote from: "Hiura"

> keys pressed with shift and without shift don't produce the same event.

Is this really an issue? I mean... for example, I've no Tilde key on the french PC keyboard I'm using right now. To get a tilde I would need to use Alt+é. Thus, is the 'é' key supposed to produce a tilde key event? Or nothing? Is Alt+é supposed to produce a tilde key event? Or nothing?

Quote from: "Hiura"

> the 'fn' key produce an event but shouldn't.

I suppose this could be fixed quite easily.

Quote from: "Hiura"

> Without using shift I've got 7 keys sending event with keycode = 0, and 10 when shift is down.

To me, what's most annoying is getting different results between the key pressed and text entered events. If you were just using -characters and some tricks to get the numpad keys, you could possibly get all of the keys described in the enum. But it would not always match the first character of the concerned key. Would this be acceptable?

Quote from: "Hiura"

> Thus I haven't access to all keys of the enum.

I don't think you could ever have access to all of these, because it really depends on the keyboard layout. This is an issue beyond the scope of the Mac port. I had no answer to this but it should be discussed more deeply with Laurent.

Laurent · « **Reply #123 on:** February 14, 2011, 11:47:43 am »

Quote

Is this really an issue? I mean... for example, I've no Tilde key on the french PC keyboard I'm using right now. To get a tilde I would need to use Alt+é. Thus, is the 'é' key supposed to produce a tilde key event? Or nothing? Is Alt+é supposed to produce a tilde key event? Or nothing?

It is an issue. A key is a key, no matter which modifiers are pressed or not.
If you have no key showing a tilde directly, you should (in a perfect world) never have a KeyPressed event with Code == Tilde. You can only get it with the TextEntered event.
So both 'é' and Alt + 'é' should produce a 'é' KeyPressed event (or '2', like it is currently).

Quote

I don't think you could ever have access to all of these, because it really depends on the keyboard layout. This is an issue beyond the scope of the Mac port. I had no answer to this but it should be discussed more deeply with Laurent.

It is indeed a huge problem, I have to find something to properly handle the differences in keyboard layouts.

Hiura · « **Reply #124 on:** February 14, 2011, 12:55:01 pm »

The link in the task describes layout form windows mostly. On Mac they are a little bit different. I've uploaded here the french, us and swiss layouts. (It's only the small keyboard version because I haven't a keyboard with numeric keypad.)

The current implementation I use is based on the current layout for abc characters and for the other keys on the US layout except '-' (US layout) that is unbound because it might be twice on the keyboard.

I just quickly test SFML2 on my brother computer (also swiss layout but not a Mac keyboard so it's not exactly the same layout as mine – see the task link for visual description) on Ubuntu and encounter the same problem : lot of keys produce event with key code = 0 and shift change the '3' (for example) key into something else.

On a side note, what about adding a System field to sf::Event::KeyEvent ? On OS X it would be very logical to have this. And why not on Unix/Win ?

Laurent · « **Reply #125 on:** February 14, 2011, 01:14:49 pm »

Quote

On a side note, what about adding a System field to sf::Event::KeyEvent ?

And what does it mean?

Hiura · « **Reply #126 on:** February 14, 2011, 01:20:33 pm »

On OS X, instead of using ctrl for shortcut we use cmd so this new field would have the same purpose as Alt, Control and Shift.

Ceylo · « **Reply #127 on:** February 14, 2011, 01:24:20 pm »

Quote from: "Laurent"

It is indeed a huge problem, I have to find something to properly handle the differences in keyboard layouts.

Thus.. is it worth trying to find a solution before getting the right design? To me, efforts should be focused on this issue rather than trying to implement "wonky" solutions.

Laurent · « **Reply #128 on:** February 14, 2011, 01:45:32 pm »

Quote

On OS X, instead of using ctrl for shortcut we use cmd so this new field would have the same purpose as Alt, Control and Shift.

You're right, the System key is a modifier as well.
(sorry it took me a while to figure out what the "System" key was

)

Quote

Thus.. is it worth trying to find a solution before getting the right design? To me, efforts should be focused on this issue rather than trying to implement "wonky" solutions.

You should definitely not spend months on this issue. Don't try to make it better than the Windows and Linux implementations, which use a straight-forward code (they don't try to do anything fancy). But at least, make sure that the behaviour more or less matches these implemetantions.

Hiura · « **Reply #129 on:** February 14, 2011, 02:52:23 pm »

Ok, so everything is fine for me.

Vit · « **Reply #130 on:** February 17, 2011, 06:59:20 pm »

I haven't checked back here for a while (been busy with other things), but SFML 2 on Mac is amazing news

I'll be trying it out in the next few weeks; I hope the problems I had with 1.6 are fixed!

James · « **Reply #131 on:** March 05, 2011, 04:28:37 pm »

G'day, I hope this is the right place to talk about the 2.0 port for mac.

So, the OpenGL tute mentions this: "To use OpenGL, you only have to include Window.hpp : the OpenGL and GLU headers will be automatically included by it."

This isn't the case for mac, since it's not included in the mac specific headers.

(Just wondering why/letting you know. Not a big deal :P)

Laurent · « **Reply #132 on:** March 05, 2011, 04:30:34 pm »

This is the tutorial for SFML 1.6, things have changed a lot in version 2.0

James · « **Reply #133 on:** March 06, 2011, 06:57:19 am »

Aha, I see. I guess I just assumed something like that would stay the same.

Any reason for the change? I'm curious now

Laurent · « **Reply #134 on:** March 06, 2011, 10:04:18 am »

Now OpenGL headers are included in SFML/OpenGL.hpp. This way we still provide a portable way of including GL headers, but the user is no longer forced to have them included by default.