[GNU/Linux] [Wayland] Building ARES without legacy X11 dependencies

[vanfanel]

Is your feature request related to a problem? Please describe.
I'm trying to build Ares for the first time.
My system uses a lightweight Wayland compositor (labwc) with no X11 dependencies installed or needed: SDL2/3|RetroArch is used for everything having to do with graphics and sound, and all those systems wisely abstract the underlying windowing system.

Now, ARES seems to be different: some of it's components heavily depend on X11 apparently.
I can build the project if I comment out these lines in the main CMakeListst.txt:

add_subdirectory(ruby)
add_subdirectory(hiro)
add_subdirectory(desktop-ui)

I am perfectly OK with command-line driven emulator frontends (in fact, that's what I prefer!), but the results of building ARES with disabled "ruby", "hiro" and "desktop-ui" is a bunch of static libraries and nothing more, apparently.
Trying to install it using "make install" results in just /usr/local/bin/sourcery being installed.

Describe the solution you'd like
I would like to be able to build and run ARES without needing the old X11 libraries and headers to do so, using SDL2/3 (which ARES already does make use of) to abstract the windowing system.

Describe alternatives you've considered
Ehm... I don't know what the situation really is internally in ARES.

Additional context
Well, it doesn't build a runable emulator here, so nothing to show I guess :)

[flagrama]

All I can really do is confirm that currently ares is an X11 application that only runs on Wayland due to using XWayland. I don't think there are currently plans to change it as it works well enough for most people so there isn't a reason to immediately look into it, but if someone wants to work on it they certainly can.

AFAIK you should only need the libraries to compile ares as XWayland should be self-contained and is unlikely to go away even in Wayland-only environments for a long time.

If you were willing to put in the work to do so, I think ruby is probably the most important of the systems you'd need to untie from X11 and then could probably make some sort of SDL3 video/audio/input implementation to integrate with it, and probably just handle the settings.bml file manually in a text editor as a completely bare-bones way of doing this. It probably makes sense to discuss this stuff on the Discord before trying it though since you'll probably get more discussion on development stuff there before implementing something.

I haven't worked with ares too much yet though, so any part of what I've said could just be wrong.

[vanfanel]

Thanks for taking the time to answer, @flagrama
In fact, I have looked at the Ruby component, and it seems to be able to use SDL for everything except video:

ares/ruby/cmake/os-linux.cmake

Lines 58 to 68 in c95ddfe

	option(ARES_ENABLE_SDL "Enable SDL audio and input drivers" ON)
	if(ARES_ENABLE_SDL)
	find_package(SDL)
	endif()
	if(SDL_FOUND)
	target_enable_feature(ruby "SDL input driver" INPUT_SDL)
	target_enable_feature(ruby "SDL audio driver" AUDIO_SDL)
	else()
	target_disable_feature(ruby "SDL audio driver")
	target_disable_feature(ruby "SDL input driver")
	endif()

So near, yet so far! Why some emulators target windowing systems directly, instead of using SDL2/3 to abstract all that OS-specific stuff, is beyond my comprehension.

Adding a new VideoDriver object in the form of ares/ruby/video/sdl.cpp is VERY tempting...
I may give it ago someday: there are other VideoDriver implementation there (glx.cpp, wgl.cpp, etc...) that can be used as templates, and I have done similar things in the past for OpenLara and other engines that were hitting X11 directly.
I may do it some of these days if nobody else does it.

[Screwtapello]

I think ruby is actually the least important part of the codebase to disentangle from X11; there's already a variety of video drivers that might work.

I believe most of the X11 stuff is in hiro - hacks added to support functionality that GTK+2 and Qt4 didn't wrap in a platform-agnostic way. Updating hiro to use GTK+3 or Qt6 without assuming X11 would be a fair amount of work, replacing desktop-UI with brand-new UI that only depends on SDL would be a lot of work.