Make AppleWin multiplatform (port it to SDL2?)

[ao2]

Hi, in #184 I saw @Michaelangel007 mentioning a possible SDL2 port.

Is there an official interest in that?

I am using linapple (http://linapple.sourceforge.net/) on linux which was ported to SDL1.2 from an older version of AppleWin, maybe the two projects can collaborate on this efforts?

Thanks,
Antonio

[Michaelangel007]

Thanks Antonio.

I'm aware of LinApple. I took a look at its source last month. While a lot of AppleWin has been gutted it will still be useful as a template.

Unless I'm mistaken I'm the only "official" interest at the moment. I want to eventually see AppleWin work on OSX and Linux since I have multiple computers with those 3 OSes.

We're currently wrapping up v1.25 but once that is out the door I'll spend some more time working on the SDL branch.

[Michaelangel007]

There is also interest in running a Linux version on the Raspberry Pi.

[timaios]

Hi there,

have you already considered porting to Qt instead of SDL2?
It is also multi-platform (Windows, Linux, OSX) and comes with a powerful IDE (although you can also use it with VisualStudio).
I think it might be easier to port AppleWin to Qt, as it already provides platform-independent ways of displaying dialog windows, buttons, storing and retrieving settings (registry replacement), etc.

I've thought about giving it a try, but it would be kind of a wasted effort if I was the only one interested in such a port...

What do you think?

(btw, Qt applications can also be compiled on the Raspi... 😉 )

Regards,
Tim

[Michaelangel007]

In the past I would of said "I have no interest or desire in Qt." From my game developer experience of shipping multiple console games I would say SDL2 makes more sense since Valve is directly supporting and using it for their games. The other side point is that someone already has ported AppleWin to Linux using SDL so we can refer to that working codebase "in passing." (I do know that they completely ripped out the debugger, but still.)

From my current understanding we have enough work to do just cleaning up the cruft code removing all the "Windows-only-isms" that I don't see how switching to Qt brings anything new to the table except even more work. My perspective could be wrong on that. i.e. This [Qt] is yet-another-API we need to learn, and support. Ugh. All my available time is tied up working on my indie game -- I don't have the motivation or time to learn Qt.

Now, with all that said, you do bring up an interesting point.

The Raspberry Pi would be a nice bonus. (Again someone would need to maintain and support it.)

If we can get a good cross platform UI with minimal work then that is something definitely to consider. The whole UI of AppleWin really needs a lot of TLC and makeover. The problem is that this is a huge investment, has the potential to create tons of (new) bugs, for almost no end-of-the-day benefit to the end user who just wants to fire up the emulator and play his favorite game or software.

The biggest concern of mine is that we need all the spare cycles available already especially with the video rewrite. Adding yet another layer between the App + OS is something I am leery of. The fastest way to convince us that Qt is a good fit would be to see a working OpenGL accelerated Qt demo with a working demo of menus and tooltips. If the code is relatively simple and gives us good runtime performance, my qualms would be address and I would be less hesitant.

Correct me if I'm wrong Tom, but the debugger is the only "core" piece that is changing? The majority of the past releases have been bugfixes, no? If we are at a place were the code is "relatively" stable after the next release, then maybe this question is worth pursuing then.

Weighing the pros and cons of what Qt gives us, and what it takes away, is worth considering -- I feel just not yet.

TL:DR; Probably no, but maybe. :-)

[timaios]

Thanks for your consideration.

I've looked at the code of both AppleWin and LinApple for the last few days and I suspect you're right: it would be a lot of additional work.
As far as I can see, a lot of AppleWin's codebase is not really implemented in an object oriented way, which makes it difficult to be easily ported to Qt.
SDL might indeed be a better candidate, because the way it works (e.g. the event loop) is somewhat "nearer" to the native Windows way...
And if you're planning to invest some work in the UI anyway, I suppose there's not much advantage of implementing it in Qt over doing it with SDL.

The Raspberry Pi would be a nice bonus.

Well, even that's no argument for Qt, because SDL also works perfectly fine on the Raspi. I'm running LinApple on it, without problems.

Anyway, I think that - when the Windows-only-isms have been taken care of - it would be a great thing for AppleWin to go multi-platform. I really love to use it on the Raspi, but LinApple is hopelessly outdated. (I want 80 columns!!! 😉 )

So, again, thanks for your answer! 👍