Dropping the SDL2 Frontend

[kleidis]

Issue

Already done on Lime3DS release 2118 https://github.com/Lime3DS/Lime3DS/commit/91294919bbf1a4305578a06492862a94571f27f5, and I assume the other forks soon too, should the SDL2 frontend be removed?

It's not of much use nowadays, and it confuses some Windows users thinking citra.exe is the main GUI executable

[PabloMK7]

This is a HUGE mistake done by Lime3DS developers. The standalone frontend is not useless and some automated setups use it. There are no plans to remove it.

[kleidis]

Can you please give more details

[kleidis]

*As to what it breaks

If it breaks more than expected, then it should definitely be reverted

[BAaaakkka]

why am i included in this email?

On Fri, Sep 13, 2024 at 12:27 PM kleidis @.***> wrote:

*As to what it breaks

If it breaks more than expected, then it should definitely be reverted

— Reply to this email directly, view it on GitHub https://github.com/PabloMK7/citra/issues/256#issuecomment-2349335232, or unsubscribe https://github.com/notifications/unsubscribe-auth/BHOAXPBSK7GQQWHJSPKUMGTZWMG5JAVCNFSM6AAAAABOFTDGX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBZGMZTKMRTGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Lord Farquaad🥸

--

Please consider the environment before printing this email.Remember when writing or responding to email, the Massachusetts Secretary of State has determined that e-mail is a public record. All electronic messages sent from the Northampton Public Schools are archived in conformance with Massachusetts and Federal Public Records law.

[OpenSauce04]

This is a HUGE mistake done by Lime3DS developers. The standalone frontend is not useless and some automated setups use it. There are no plans to remove it.

What specific use cases are there that depend on the SDL frontend?

You can call the Qt executable from the command line to launch games directly, which to my knowledge was the entire purpose of the SDL executable, so I'm out of the loop on how this is useful.

Please inform me if there's anything I hadn't considered so I have the full picture on this.

[rtiangha]

It's useful for scripting, especially for systems that have limited resources or don't have the RAM to run QT (ex. Dedicated applicances). Plus, while the QT version only takes the rom name as an argument, the SDL version takes in all of these:

       -g port, --gdbport port
               Starts the GDB stub on the specified port

       -i, --install FILE
               Installs a specified CIA file

       -m, --multiplayer nick:password@address:port
               Nickname, password, address and port for multiplayer

       -r, --movie-record file
               Record a movie (game inputs) to the given file

       -a, --movie-record-author AUTHOR
               Sets the author of the movie to be recorded

       -p, --movie-play file
               Playback the movie (game inputs) from the given file

       -d, --dump-video file
               Dumps audio and video to the given video file

       -f, --fullscreen
               Start in fullscreen mode

       -h, --help
               Shows syntax help and exits

       -v, --version
               Describes the installed version and exits

That said, not sure how many people still use the cmd version.

[BlurrySquire]

Well we should probably add these arguments to the qt build. Then it will be easier for emulator frontend Devs to use Lime3DS.

[fight-fly]

No...Please don't do this. If you cut it, the project will lose better graphics developers who may participate in the future. Of course, if you think you are the best, you will get the best applause.

[OpenSauce04]

No...Please don't do this. If you cut it, the project will lose better graphics developers who may participate in the future.

Please explain what is actually being lost here. As far as I can tell the only thing which is actually lost here is the aforementioned command line parameters and the ability to display the game without the top menu bar, all of which could easily be integrated with the main executable making the addition of an entire extra program for this purpose entirely unnecessary and messy.

This thread has so much hysteria with no actual explanation of what is wrong. I would like to know so that any issues can be corrected in Lime3DS.

[raphaelthegreat]

Qt is a quite heavy library so by removing the SDL frontend the project would be less portable overall. I recall some initial iOS ports were done with SDL as a base. Having a CLI frontend could also allow for CI testing in the future. While I do agree the code has been left to rot for a while, it should be modernized/refactored, not removed.

[PabloMK7]

It also serves as a simpler example to port the core to other environments without the complexities of QT getting in the way.

[OpenSauce04]

While these are valid points, I personally don't believe that it's worth the overhead of having an entire extra executable.

Functionality such as installing CIAs via the command line etc should still be available regardless of what happens with SDL, and adding that to the Qt executable is something I'll put on the roadmap for then next major Lime3DS update.

Additionally, if you think it's best to keep the SDL frontend around, do you think it would be acceptable if the SDL frontend could be launched via a command line parameter (e.g. --nogui) instead of having a whole other executable dedicated to it? Despite my best efforts to update the executable names to make their purpose as obvious as possible, less technically inclined users still regularly confuse them, and in general it's just not a clean way of handling these things from an end user perspective.

[Wunkolo]

I use the SDL library when developing and debugging and testing graphical features myself for the previously stated reasons. It's also much "lighter" than the Qt frontend and it allowed me to compile a Windows on Arm build before Qt binaries for WoA were available. I strongly think it's worth keeping since it's pretty core to the development loop while the Qt front-end is more user-facing.

[OpenSauce04]

@Wunkolo This isn't something I personally deal with as I find that compilations after an initial full compilation take minimal time even with Qt enabled.

Even so, it would still be possible to seperate the two frontends if deemed necessary with the single executable solution. If the emulator is compiled without Qt, the executable can simply fall back to the SDL frontend when called. If the emulator is not compiled with SDL, the --nogui or equivalent option will simply not be available.

[raphaelthegreat]

@OpenSauce04 If one of the main concerns is user confusion you can always disable building the SDL frontend in release packages with ENABLE_SDL2_FRONTEND

[OpenSauce04]

@OpenSauce04 If one of the main concerns is user confusion you can always disable building the SDL frontend in release packages with ENABLE_SDL2_FRONTEND

While this does address the user confusion issue, I don't believe it's a solution that properly resolves the issue. There are aspects of the SDL executable's functionality which may be useful to end users which would no longer be available if the SDL executable was simply not included with no other changes. This could be remedied by duplicating this other functionality into the Qt executable, but at that point it just seems more appropriate to go for a merger solution like the one I proposed above.

Additionally, I do see how a nogui option would be useful for setups where game launches are automated, for example when games are launched by emulator launchers such as EmuDeck.

If we're properly dealing with this, I want to come up with an elegant solution that we can all agree is appropriate for the emulator, both on the development and end-user side.

Ideally this is a conversation that should have happened before the change was released to Lime3DS, however a lack of active developers who are ready to have these discussions makes it difficult to consider decisions in-depth before anything is merged. I instead opted to simply release the changes as I did and play by ear to see what would be the most appropriate way forward before any major time is put into the issue.

[BlurrySquire]

Even so, it would still be possible to seperate the two frontends if deemed necessary with the single executable solution. If the emulator is compiled without Qt, the executable can simply fall back to the SDL frontend when called. If the emulator is not compiled with SDL, the --nogui or equivalent option will simply not be available.

I feel like this is too complex and we could just add the SDL functionality to the qt build. If you don't want a gui then you have to launch with a specific argument.

[kleidis]

Even so, it would still be possible to seperate the two frontends if deemed necessary with the single executable solution. If the emulator is compiled without Qt, the executable can simply fall back to the SDL frontend when called. If the emulator is not compiled with SDL, the --nogui or equivalent option will simply not be available.

I feel like this is too complex and we could just add the SDL functionality to the qt build. If you don't want a gui then you have to launch with a specific argument.

We would newd to do it properly, no matter the complexity. Since we were the ones to remove it in the first place