VBA-M Forums

Full Version: wxWindows port?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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 Smile
(03-11-2011 02:56 AM)mudlord Wrote: [ -> ]It would be great if you pop by the VBA-M IRC channel. I would love to discuss more on this Smile

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.
(03-13-2011 04:52 PM)bgK Wrote: [ -> ]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.

Is there a build with this floating around? I'd be curious to see the comparison as just now I'm using the standard Windows build. Smile
(03-13-2011 10:23 PM)Hot_Violet Wrote: [ -> ]Is there a build with this floating around? I'd be curious to see the comparison as just now I'm using the standard Windows build. Smile

No, I won't publish that build since it only "works". I don't wan't people to make their minds on a quick and dirty WIP build. Some more configuration / packaging work would be required to have gvbam integrate well with Windows.
imho a wxWidgets interface would be desirable, I've been working on such an interface recently within the past year (not much done though) I'd definitely would be interested in helping with the wxWidgets UI.
Hmm.. email notifications seem to be broken, since I missed most of the replies after my previous rant.

Anyway, I'm sick of working on this thing, so I've gone ahead and posted my code to the tracker. Unfortunately, I posted the final patch (wxWidgets front end, 3302799) as a bug rather than a feature request, but if anyone cares, they can move it around.

As to GTK being portable: I would agree that the SDL front end is portable, but the GTK front end is GTK. It's like saying the Windows GUI is portable because I can link against winelib on MacOSX and Linux. GTK has its own look and feel, and really doesn't work very well under Windows or MacOSX. The GTK front end is also missing quite a few features from the MFC front end.

Look for darktjm-posted bugs (10 total) for the list. Each one has a patch attached. See http://darkalpha.homelinux.org/wxvbam/ for long-winded notes and win32/mac binaries.

In summary: I don't think it was worth the effort, but what's done is done. Now I can go back to playing games and watching TV.

In case it wasn't clear from the above: it works, and it does a lot of stuff the GTK interface can't. It still has a few bugs and missing features, though (see bug 3302799 for my todo list).
I'm impressed by your work. Does it need a specific wxWidgets version (I'm running a very old Linux distro on my laptop)?
There are no known issues with 2.8.4 (May 2007). I did most of my testing with 2.8.12, though. 2.9.1 builds (even without 2.8 compatibility enabled), but has known issues (see the page linked above for the list). There are a few 2.8 widgets (e.g. the pickers) and many minor API changes that make 2.6 support difficult enough that I won't try. It might work with earlier 2.8 releases, though.
The more I play it, the more I patch it.. I have added 5 patches to the main bug (3302799) since my original posting, and one to the ffmpeg bug (3302797). These fix a few bugs and add mouse pointer blanking and ubuntu install support. I think I'll put off any further patching until it gets merged, though, if ever. Unless someone reports a serious bug, that is. I am a little concerned that nobody has tried this on a Mac, but at least it works for me on the only platform I care about.

Also, I've placed Ubuntu 10.04LTS binaries on my site, since that's what was released last time. I also packaged the patches with an ebuild for gentoo users. I have not tested the ubuntu binaries other than "it installs" and "it runs" (and, to test the ffmpeg changes, "it records").
the more I see it the more I get excited, mudlord, nach, or squall get this in asap to svn, we could use more of a universal UI Big Grin
im going to create a seperate branch for Wx i think, until it is really ready for trunk merge
meh, i put (and already updated once) a Pre-Wx branch, and loaded Wx to trunk.

its not ready for MSVC compiling, a bunch of MSVC specifics aren't playing nicely.
Pages: 1 2
Reference URL's