Supporting SFML 3 Development

[ChrisThrasher]

Hi, Elias! I've been working on SFML 3 for the past few months and recently started a new project that is using SFML 3 with ImGui-SFML. So far it's been working just fine with SFML 3 but a recent SFML PR finally broke compatibility with ImGui-SFML.

What is propose is that ImGui-SFML adopt SFML's branching strategy. This means that the master branch is where most development effort is focused and this is kept in sync with SFML 3's master branch. A 2.6.x branch is made which contains ongoing 2.6.x work and will remain compatible for those who still want to use SFML 2.

I already have one fix planned for SFML 3 compatibility pending feedback on how you may want to approach this versioning problem. Thanks!

[Bambo-Borris]

I'm also testing a lot of SFML3 stuff and often the test projects I do will use this repository so for me and others testing it would be a really welcome addition to have a new SFML3 compatible branch for this.

[danieljpetersen]

You have more clarity into future sfml developments than I do but from what I gather it may be possible to retain compatibility with both 2 and 3 on the master branch.

I assume the breaking change you are referring to is the removal of arguments (int x, int y) in favor of sf::vector2's? If so then fixing shouldn't break compatibility with 2

Not sure if there are any other planned changes which could break things.

[ChrisThrasher]

I assume the breaking change you are referring to is the removal of arguments (int x, int y) in favor of sf::vector2's?

Yes, it's one of many API changes already merged into SFML 3. In this case the problem is sf::Texture::create which in SFML 2 has one overload of bool create(unsigned int width, unsigned int height); which changed to [[nodiscard]] bool create(const Vector2u& size); in SFML 3. There is no common subset of APIs between the two versions we can use. Even if there was a common API to use for now, it's only a matter of time before more API breaks get merged in further increasing the need for ImGui-SFML to maintain two branches that target either major version.

[oprypin]

(Note that I am not an owner of this project, just been lurking for quite a while.)

I would strongly suggest to avoid branches. I just don't see the advantage. Why should every improvement to imgui-sfml need to be ported to another branch?
One can just add compile-time conditionals and be done. For example:

diff --git a/imgui-SFML.cpp b/imgui-SFML.cpp
index bbea0eff4..9238d4920 100644
--- a/imgui-SFML.cpp
+++ b/imgui-SFML.cpp
@@ -784,9 +784,15 @@ bool UpdateFontTexture() {
     io.Fonts->GetTexDataAsRGBA32(&pixels, &width, &height);
 
     sf::Texture& texture = s_currWindowCtx->fontTexture;
+#if SFML_VERSION_MAJOR >= 3
+    if (!texture.create({width, height})) {
+        return false;
+    }
+#else
     if (!texture.create(width, height)) {
         return false;
     }
+#endif
 
     texture.update(pixels);
 

means that the master branch is where most development effort is focused and this is kept in sync with SFML 3's master branch

There is very little developer time available for imgui-sfml as is, why should effort be focused on supporting something unstable?
I'd suggest to keep SFML 3 support best-effort: fixes are welcome as long as they don't touch SFML 2 support.

[ChrisThrasher]

Oh yeah I forgot we can use the preprocessor. That's definitely the easier solution and will get us pretty far. We can reevaluate if maintaining the preprocessor code gets too cumbersome in the future. So far it's not a problem but one other thing to keep in mind is how ImGui-SFML links to sfml-graphics but the SFML 3 target names are styled as SFML::Graphics so we might later need to modify the build to use the new target name when SFML 3 is detected.

There is very little developer time available for imgui-sfml as is

For what it's worth I'm volunteering to do the labor myself to support my use case. I won't require anyone else to make these changes.

[eliasdaler]

I definitely agree that using #ifdefs is a right way to do it.

As for the CMake stuff - I feel like adding IMGUI_SFML_USE_SFML3 would be a great start (and then putting everything specific to SFML 3 in if/else branches to make everything explicit about SFML 2 and SFML 3 differences)