How unified should desktop & mobile SFML be?

[Ceylo]

(probably to be moved in SFML development section)

Hello,
As far as SFML iOS and Android support is concerned, I wonder what is the wanted direction in terms of differences on a few aspects:
- API
- examples

Currently it looks like there is zero difference on API side (the same API is visible on all platforms), although some APIs like TouchEvents and Sensors most likely only have a meaning on mobile platforms. And these APIs are implemented as empty stubs on desktop platforms from what I see.

Do we want the exact same API to be visible from both mobile and desktop? Or trigger a compilation error if a mobile API is used on desktop and vice versa? Or maybe we don't care yet because for now it's still rather obvious which APIs make sense in which context?


About examples, at the moment the Android example is totally disconnected from CMake stuff and is distinct from current GUI-based examples (opengl, pong, shader and window examples — although shader example is another story by itself ).

For iOS there is also a distinct example which currently doesn't make use of any mobile specific API except a Touch event.

Regarding examples I would expect the following:
- current GUI-based examples (opengl, pong, and window) are adapted to work on mobile too, but share their code with desktop version
- examples that are here to showcase mobile APIs are kept distinct from desktop examples

This would most likely mean current iOS example would be merged or removed. As for the Android example, its main interest looks to be to showcase JNI usage (which then should not be optional in a #if defined(USE_JNI)), but I guess current GUI-based examples could also work for Android with small changes.

What are your thoughts?

[Laurent]

some APIs like TouchEvents and Sensors most likely only have a meaning on mobile platforms.

I don't think so. The difference between "mobile" and "desktop" tends to disappear, both on hardware side (laptops which are tablets + keyboards) and on OS side (almost all OS try to unify their mobile and desktop version).

I think a Windows version of the Touch API is pending in PRs, and we could as well make a Linux version of it.

Do we want the exact same API to be visible from both mobile and desktop?

It's hard to say, I guess we should invest some time to list the APIs which belong to only one of these two worlds, in order to get the full picture and then make a decision.

- current GUI-based examples (opengl, pong, and window) are adapted to work on mobile too, but share their code with desktop version

I know nothing about Android stuff, but what's preventing these examples from working on iOS directly? As far as I remember:
- several years ago when I started to port SFML on iOS, I managed to make some examples work
- there's now a clean CMake toolchain for iOS

Listing the problems (either blocking or not) to compile iOS (and Android?) examples with the same setup as on desktop OSes, would be a good starting point I think.

- examples that are here to showcase mobile APIs are kept distinct from desktop examples

Definitely.

[Ceylo]

I don't think so. The difference between "mobile" and "desktop" tends to disappear, both on hardware side (laptops which are tablets + keyboards) and on OS side (almost all OS try to unify their mobile and desktop version).

I think a Windows version of the Touch API is pending in PRs, and we could as well make a Linux version of it.

Ok we'll see how it goes on. Even if both tend to be closer, most of the time in desktop PC you have much fewer sensors. But I guess there is no actual limitation so it's not worth forbidding its use on desktop.

Another example I can think of is the sf::Window size. Fix me if I'm wrong but to me it doesn't make sense to use anything else that the full screen size on mobile, or at least the size that the OS tells you you can use. In that sense, sf::Window constructor should probably have no size param at all when compiling for mobile.

Do we want the exact same API to be visible from both mobile and desktop?

It's hard to say, I guess we should invest some time to list the APIs which belong to only one of these two worlds, in order to get the full picture and then make a decision.

Ok, we'll see over time, unless someone has a clear vision already. On my side I still need to get familiar again with the whole Window module.

I know nothing about Android stuff, but what's preventing these examples from working on iOS directly? As far as I remember:
- several years ago when I started to port SFML on iOS, I managed to make some examples work
- there's now a clean CMake toolchain for iOS

Listing the problems (either blocking or not) to compile iOS (and Android?) examples with the same setup as on desktop OSes, would be a good starting point I think.

I know nothing about Android too (maybe Mario can help?)
As for iOS :
- the CMake MACOSX_BUNDLE property must be set on target
- the CMake MACOSX_BUNDLE_GUI_IDENTIFIER property must be set on target (otherwise launching in simulator makes Xcode crash :-° )
- need to include <SFML/Main.hpp>
- need a few tweaks related to OpenGL ES (glClearDepth -> glClearDepthf and glFrustum -> glFrustumf)
- need to embed their media resources

So nothing big. Which I guess means we don't need to have mobile-only version of current GUI-based examples.

[Jonny]

In terms of the API, I'd like to be able to write the same SFML code for all platforms, with platform specific parts of the API providing

isAvailable()

functions so the user can handle it appropriately (a la sf::Sensor and sf::Shader)

For the examples, I would also like to see them as unified as possible across all platforms, something like this:

• cocoa (macOS only)
• ftp (CLI only)
• island
• joystick (I suppose this would be desktop only, but perhaps replace with an "input" example which demonstrates input on all platforms?)
• mobile (demonstrate mobile specific features, unified android/ios example)
• opengl
• pong
• shader (desktop only I suppose, until shaders are supported on mobile)
• sockets (CLI only)
• sound (CLI only)
• sound_capture (CLI only)
• voip (CLI Only)
• win32 (Windows only)
• window
• X11 (Linux only)

Obviously the platform specific examples would remain that way, and then I'd say we try and demonstrate the CLI example features in the unified mobile example, to cover all functionality?