New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android port #440

Closed
LaurentGomila opened this Issue Jul 30, 2013 · 17 comments

Comments

@LaurentGomila
Member

LaurentGomila commented Jul 30, 2013

Not integrated to the master repo yet, it is available at https://github.com/Sonkun/esfml/tree/Android

@ghost ghost assigned LaurentGomila Jul 30, 2013

@mjbshaw

This comment has been minimized.

Show comment
Hide comment
@mjbshaw

mjbshaw Jul 30, 2013

Jonathan and I talked a little while back, and once the iOS branch is publicly available (even if it's not done), we can work to make the Android port fit whatever API changes the iOS port will introduce (which would make it much nicer).

mjbshaw commented Jul 30, 2013

Jonathan and I talked a little while back, and once the iOS branch is publicly available (even if it's not done), we can work to make the Android port fit whatever API changes the iOS port will introduce (which would make it much nicer).

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jul 30, 2013

Member

There will be no API change, but yes, both ports must be reviewed so that they are consistent on how they map to the existing API, what features they lack, how they hack the user's main(), etc.

Member

LaurentGomila commented Jul 30, 2013

There will be no API change, but yes, both ports must be reviewed so that they are consistent on how they map to the existing API, what features they lack, how they hack the user's main(), etc.

@mjbshaw

This comment has been minimized.

Show comment
Hide comment
@mjbshaw

mjbshaw Jul 30, 2013

There will be no API change

Not even new additions to the API? I thought there might at least be some new additions.

mjbshaw commented Jul 30, 2013

There will be no API change

Not even new additions to the API? I thought there might at least be some new additions.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jul 30, 2013

Member

Not even new additions to the API? I thought there might at least be some new additions.

Additions will come later. The first step is to have the current SFML API working on mobile platforms.

The only mandatory addition (from my experience on the iOS port so far) is sf::Keyboard::setVirtualKeyboardVisible(bool).

Member

LaurentGomila commented Jul 30, 2013

Not even new additions to the API? I thought there might at least be some new additions.

Additions will come later. The first step is to have the current SFML API working on mobile platforms.

The only mandatory addition (from my experience on the iOS port so far) is sf::Keyboard::setVirtualKeyboardVisible(bool).

@Sonkun

This comment has been minimized.

Show comment
Hide comment
@Sonkun

Sonkun Aug 12, 2013

Member

I mapped it to sf::Window::setVisible() since the window visibility makes no sense on Android.

Member

Sonkun commented Aug 12, 2013

I mapped it to sf::Window::setVisible() since the window visibility makes no sense on Android.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Aug 12, 2013

Member

Hm... sounds like a bad idea. That would pretty much cause odd and unexpected behavior. I'd rather see this in its own method that simply doesn't do anything on other platforms, plus it's not like its introduction would break existing code (which is the important part here).

Member

MarioLiebisch commented Aug 12, 2013

Hm... sounds like a bad idea. That would pretty much cause odd and unexpected behavior. I'd rather see this in its own method that simply doesn't do anything on other platforms, plus it's not like its introduction would break existing code (which is the important part here).

@Sonkun

This comment has been minimized.

Show comment
Hide comment
@Sonkun

Sonkun Aug 12, 2013

Member

Why does that sound like a bad idea ? It reuses the existing API and removes the need to anticipate the future, if we decide now to add sf::Keyboard::setVirtualKeyboardVisible(bool) we should stick with it and avoid to remove it later because it would cause an API break.

Member

Sonkun commented Aug 12, 2013

Why does that sound like a bad idea ? It reuses the existing API and removes the need to anticipate the future, if we decide now to add sf::Keyboard::setVirtualKeyboardVisible(bool) we should stick with it and avoid to remove it later because it would cause an API break.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Aug 12, 2013

Member

sf::Window::setVisible() is supposed to do exactly what it says: toggle visibility for the window. If it isn't supported, it shouldn't do anything (i.e. be a dummy function). But it shouldn't trigger the virtual keyboard, especially considering cross-platform: Imagine a Windows tablet running in Desktop mode. You'll have both: Windows that may become invisible as well as a toggleable virtual keyboard. If you follow your idea you might cause unexpected behavior in such environments.

Member

MarioLiebisch commented Aug 12, 2013

sf::Window::setVisible() is supposed to do exactly what it says: toggle visibility for the window. If it isn't supported, it shouldn't do anything (i.e. be a dummy function). But it shouldn't trigger the virtual keyboard, especially considering cross-platform: Imagine a Windows tablet running in Desktop mode. You'll have both: Windows that may become invisible as well as a toggleable virtual keyboard. If you follow your idea you might cause unexpected behavior in such environments.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Aug 12, 2013

Member

I'm ok to map mobile features to the existing API as long as it's close enough. But Window::setVisible is really too far from what you make it do (showing the virtual keyboard).

However the discussion is still open for how to handle the virtual keyboard the best. The setVirtualKeyboardVisible looks ok to me because it is not limited to mobile platforms ; desktop OSes have a virtual keyboard too, and it could potentially be implemented on Windows/Linux/OS X once it's added.

Member

LaurentGomila commented Aug 12, 2013

I'm ok to map mobile features to the existing API as long as it's close enough. But Window::setVisible is really too far from what you make it do (showing the virtual keyboard).

However the discussion is still open for how to handle the virtual keyboard the best. The setVirtualKeyboardVisible looks ok to me because it is not limited to mobile platforms ; desktop OSes have a virtual keyboard too, and it could potentially be implemented on Windows/Linux/OS X once it's added.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Aug 12, 2013

Member

On a similar note, I really think touch screen events should get their own events group, too (essentially mirror MouseMove but with a tap number or ID). Simple reason for this are once again systems having both: You can connect a computer mouse to your Android device and you'll get a classic mouse cursor that shouldn't trigger touch events while being moved around, but at the same time it should trigger MouseMove events.

Member

MarioLiebisch commented Aug 12, 2013

On a similar note, I really think touch screen events should get their own events group, too (essentially mirror MouseMove but with a tap number or ID). Simple reason for this are once again systems having both: You can connect a computer mouse to your Android device and you'll get a classic mouse cursor that shouldn't trigger touch events while being moved around, but at the same time it should trigger MouseMove events.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Aug 12, 2013

Member

An important point is that people should be able to write a generic application without bothering too much about platform specificities. So the API must not be too specific either.

If I write an app where users must click somewhere, I most likely want to handle a single type of event that will automatically map to mouse on desktop and finger on mobile. Explicitly handling both "touch" and "mouse" events, and making them do the same thing, could be annoying, especially considering that only one will be active on a given platform. Connecting a mouse to a tablet... well, let's consider this a border case :p

And this is just an example. Of course in this case it's not hard to handle two types of events and make them do the same thing, but we should keep this in mind for future features.

Member

LaurentGomila commented Aug 12, 2013

An important point is that people should be able to write a generic application without bothering too much about platform specificities. So the API must not be too specific either.

If I write an app where users must click somewhere, I most likely want to handle a single type of event that will automatically map to mouse on desktop and finger on mobile. Explicitly handling both "touch" and "mouse" events, and making them do the same thing, could be annoying, especially considering that only one will be active on a given platform. Connecting a mouse to a tablet... well, let's consider this a border case :p

And this is just an example. Of course in this case it's not hard to handle two types of events and make them do the same thing, but we should keep this in mind for future features.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Aug 12, 2013

Member

Yeah, I agree, it's border case (for now) and it's always nice being able to just compile and run without having to think about platform specifics. But again I could imagine Desktops running Windows 8 or Android with a multi-touch screen (but okay, you probably wouldn't use mouse and touch at the same time).

This might actually be closer related to how you utilize input/events, as you can't really move the mouse without clicking when you're on touch. Maybe just extend MouseMove and MouseButton to have an index as well (multiple touch events shouldn't map to clicking with multiple buttons; except for single touches).

Member

MarioLiebisch commented Aug 12, 2013

Yeah, I agree, it's border case (for now) and it's always nice being able to just compile and run without having to think about platform specifics. But again I could imagine Desktops running Windows 8 or Android with a multi-touch screen (but okay, you probably wouldn't use mouse and touch at the same time).

This might actually be closer related to how you utilize input/events, as you can't really move the mouse without clicking when you're on touch. Maybe just extend MouseMove and MouseButton to have an index as well (multiple touch events shouldn't map to clicking with multiple buttons; except for single touches).

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Aug 13, 2013

Member

Since multiple mice will have to be supported one day, there will be an index anyway ;)

Member

LaurentGomila commented Aug 13, 2013

Since multiple mice will have to be supported one day, there will be an index anyway ;)

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Aug 13, 2013

Member

Yeah, finally a way to peek under the next card in Solitaire! On a more serious note: I've yet to see any system supporting more than one mouse cursor at a time, but at the same time this does sound reasonable in some way.

Member

MarioLiebisch commented Aug 13, 2013

Yeah, finally a way to peek under the next card in Solitaire! On a more serious note: I've yet to see any system supporting more than one mouse cursor at a time, but at the same time this does sound reasonable in some way.

@emddudley

This comment has been minimized.

Show comment
Hide comment
@emddudley

emddudley Dec 4, 2013

I'm really looking forward to the Android port. Laurent, in the iOS port issue you said the Android port might be merged into the public repository soon. Any news?

emddudley commented Dec 4, 2013

I'm really looking forward to the Android port. Laurent, in the iOS port issue you said the Android port might be merged into the public repository soon. Any news?

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 May 19, 2014

Member

Merged into master.

Member

binary1248 commented May 19, 2014

Merged into master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment