VisualBoyAdvance-M

Currently, the Windows front end has a number of features not present on the other front ends. My wish is to see any non-Windows-specific features on the other platforms, as well. To that end, there should be at least a platform-independent GUI front end. It seems that a Qt version was worked on a few years ago, and then abandoned. I instead propose a wxWidgets (+other) version. For my own amusement, I have already started implementing some of this. My plan is to just copy the gtk and windows GUIs and all three front ends' features as much as possible, without implementing any new features.

 

On the other hand, even if I get something working, will this just be a one man operation? I mean, is there even any desire on the part of currently active developers to switch to something completely different, and end development on the other three front ends (or maybe just the gtk and win32 ones, since the SDL front end is presumably already cross-platform, and may be more desirable than wxwidgets due to smaller size)? I have no intention of forking/maintaining this in the long term.

 

I am open to suggestions on what libraries to use. I chose wxWidgets for several reasons, which I am happy to list if alternatives are proposed. Qt in particular is something I don't care for due to the weird licensing and other issues. That doesn't mean I won't use it if that's what the primary vba-m developers think I should use, though.

 

Here's a current list of features I would like to see cross-platform, in order of importance:

• link

• A/V recording

• minor changes in state save/restore

• aspect ratio

• debugging tools

 

Some of this may require major effort and/or other library dependencies. For example, link would need to use SFML, most likely, and A/V recording some other method (ffmpeg exec was suggested, although I would prefer using libavcodec if possible to avoid platform-specific piping issues).

Although I wouldn't mind a proper cross platform GUI frontend it does feel like you are duplicating work. What are the weird licensing issues with Qt? Extending the Qt GUI until it reaches feature parity with the Windows version seems like a better idea to me.

The licensing probably doesn't matter. I was under the impression that there are still some embedded uses that required commercial licenses, but then again, supporting PDAs is probably not a high priority, and I'm probably wrong. Really the main gripe I have with qt has always been that I don't care for the idea of a c++ preprocessor. It's a personal preference that's easily overcome.

 

If the Qt route is preferred, I'll abandon my wxWindows work in progress and go with it, regardless of my opinions on the toolkit itself. However, if the concern is merely that I am putting more effort into it than necessary, then I'd prefer to continue with wxWindows.

 

That brings me to another issue with the Qt front end: where is it? It's not in SVN, at least that I can find. Not finding it is part of the reason I believe it's been permanently abandoned. The other reason is that the sticky thread on this forum has no new posts for years.

It would be great if you pop by the VBA-M IRC channel. I would love to discuss more on this [img]<fileStore.core_Emoticons>/emoticons/smile.png[/img]/emoticons/smile@2x.png 2x" width="20" height="20" />

It would be great if you pop by the VBA-M IRC channel. I would love to discuss more on this [img]<fileStore.core_Emoticons>/emoticons/smile.png[/img]/emoticons/smile@2x.png 2x" width="20" height="20" />

 

I could, I suppose. I have somehow managed to avoid IRC since its inception (chaotic communication bothers me for some reason, and I'm not much of a talker, anyway), but I think I have pidgin correctly logged into #vba-m at irc.freenode.net. I would use the "chat" link in the form and main page, but it's broken for me (java security exception). As with any real-time communication, we would now need to agree on a time. I'll just remain logged in for now.

GTK is or should be on parity with windows now... and well.. osx..... lol.... who cares.

What do you mean by "now"? The latest SVN (1010) looks pretty much the same as the last time I looked. Has someone implemented the missing features I listed above in an alternate branch, maybe? Or not checked it in yet? Or am I looking at the wrong SVN?

 

Regardless, I will press on, even if it's just for my own amusement. Having multiple front ends to maintain will lead to feature disparity again.

why are you posting your wishes here and not on the project tracker?

Maybe because I wanted to discuss things first? To see how others felt about it? Maybe because I thought this forum is supposed to be about GUI wishes? Maybe because I tend not to open issues unless I have a patch to go with it? Any of these reasons good enough for you?

 

Or were you suggesting that I file a bug report against the GTK GUI about feature disparity? I don't think that fixing the GTK front end is the correct solution. GTK is only marginally cross-platform, so I doubt people will be satisfied with dropping win32 in favor of gtk. This means that feature disparity will always be an issue.

 

By the way, thanks for responding to my question about the GTK port. I can't believe that you think the Windows front end and GTK front end have feature parity. The SDL and GTK front ends don't have feature parity either, by the way. I suggest you look at the actual features provided once to see what I mean. Just scroll through the menus/command-line/config-file options; it doesn't take a lot of time. If you're stuck in Linux, like me, you can use Wine to evaluate the Windows front end. And no, I will not open a bug report for that. If you care enough to fix it, then you care enough to report it (and, as far as I'm concerned, vice-versa).

 

It seems to me like you don't want me to continue what I'm doing. If so, that's fine. I'll just crawl back into my lair and do it for myself. It's not like I'm asking for anything in return, anyway, except perhaps future consideration for Linux users.

The GTK port is cross platform. The current version can be built for Windows with a few minor changes (I did it something like a month ago). Building it for MacOS X should be easy too.