I got tired of having no working GUI for VBA-M on Linux, so I ported the old GTK GUI to the new code base. It required only a few changes to compile. The new HQ4x scalers are missing, and there are propably a lot of other bugs. It's also not very fast right now, but it's enough for me. It should be buildable on Windows and MacOS without too much changes.
I added a CMake project that can compile the SDL and the GTK port. CMake is a very powerful (unlike qmake) and easy to use (unlike the autotools) build system that generates native project files (makefiles for linux, VC projects for Windows, and XCode projects for MacOS)
Holy crap! Brilliant work!
Thanks
I'm willing to improve this GUI to make it more comfortable to use. Do you want me to integrate it with VBA-M ?
Sure!
However, we like GUI files of course, to be in their seperate directories, so they don't interfere with each other. Like how the Qt4 GUI and current SDL port is now, as well as the current MFC Windows GUI.
Great !
Of course, the GUIs should be in different folders. I made the required changes to remove the share directory of the previous version of the patch. However, I'm afraid the CMake files can't be moved. Anyway they're used by both the SDL and the GTK backends. New patch attached.
I wrote a PortAudio sound driver to make the GTK build compile without the SDL library. You'll be able to reuse it for the QT port if you want.
Is it possible to have a SVN access so that I can commit my work ?
Great work!
I hope the VBA-M devs are not giving up on the Qt GUI now though?? O.O
Quote:Is it possible to have a SVN access so that I can commit my work ?
Yes, however you need a SourceForge account before I can give you SVN commit access.
I think it's great that the developers are willing to support multiple toolkits (just like the developers of other emulators like Mupen64Plus).
mudlord Wrote:Quote:Is it possible to have a SVN access so that I can commit my work ?
Yes, however you need a SourceForge account before I can give you SVN commit access.
Thanks. My SF.net account is bgk.
deniseweird> No, the GTK GUI won't affect the QT GUI at all. I don't plan to make the GTK GUI a fully featured one. I want it to be simple to configure and to use.
Thanks. It works fine. I just commited the GTK GUI.
To build it, you need cmake and the development files of glibmm, gtkmm, glademm, and portaudio.
Then you have to generate the makefile using "cmake ." and build the binaries with "make".
Hi all!
I have been watching the progress of VBA-M and just wanted to say well done, and keep up the good work!
I tried to compile the fresh GTK GUI vba-m and I'm having some trouble.
I'm using ArchLinux.
Here's the output of make:
Quote:In file included from /home/george/LimeWire/vbam/src/gtk/window.h:36,
from /home/george/LimeWire/vbam/src/gtk/main.cpp:30:
/home/george/LimeWire/vbam/src/gtk/screenarea.h:65: error: ‘SigC’ has not been declared
/home/george/LimeWire/vbam/src/gtk/screenarea.h:65: error: ISO C++ forbids declaration of ‘Connection’ with no type
/home/george/LimeWire/vbam/src/gtk/screenarea.h:65: error: expected ‘;’ before ‘m_oCursorSig’
In file included from /home/george/LimeWire/vbam/src/gtk/main.cpp:30:
/home/george/LimeWire/vbam/src/gtk/window.h:259: error: ‘SigC’ has not been declared
/home/george/LimeWire/vbam/src/gtk/window.h:259: error: ISO C++ forbids declaration of ‘Connection’ with no type
/home/george/LimeWire/vbam/src/gtk/window.h:259: error: expected ‘;’ before ‘m_oEmuSig’
make[2]: *** [CMakeFiles/gvbam.dir/src/gtk/main.o] Error 1
make[1]: *** [CMakeFiles/gvbam.dir/all] Error 2
make: *** [all] Error 2
My guess is that GCC ver. 4.3.0 is the one responsible for this.
I'm also planning to create a PKGBUILD (kind of a package, more or less) for arch, and I can't wait for the Qt gui. Keep up the good work!
Fixed. I don't even know why it worked on my system. Thanks for the bug report.
It's great to have packagers for Linux distros. Arch is really a nice distro, with a great community. The AUR system is just brilliant.
Quote:I'm also planning to create a PKGBUILD (kind of a package, more or less) for arch
Thanks a lot! I really appreciate it ^_^.
Honestly, this is why I like Linux: the whole package idea. I just wish MS thought of something like this for Windows. That way, there is no dependancy issues, and everything is a cinch.
But that topic is getting OT...
OT: Microsoft got the MSI (Microsoft Installer), which has a sh*tload of features no individual can ever use
bgK, thank you for your work.
Separation of sound system allowed me to reuse most of the code from src/win32/OpenAL.cpp (I already had OpenAL and libao, didn't wanted Portaudio without a very good reason).
It seems to work fine (I'm using openal-soft-1.3.253).
But my hate for cmake still grows. And on a related note, you should note somewhere that cmake 2.4.8 is required, with 2.4.6 it fails.
I added soundShutdown() to Window destructor, cause OpenAL was bitching about it.
BTW, it was not that obvious that calls to alGetError are invalid, if current context == NULL.
Sorry for the late response but NG-Emu and these forums seem to be down most of the time that I am online.
No prob about the bug reports. If I find something I' ll be more than happy to report it.
Well, thanks for the fixes, vba-m now compiles succesfully with the gtk GUI.
However, I cannot start gvbam. Here's the error
Quote:$ gvbam
terminate called after throwing an instance of 'Glib::FileError'
Aborted
I'm using the following switch of cmake to compile : -DCMAKE_INSTALL_PREFIX=/usr
(Otherwise the files end up in /usr/local. I will test asap if the cmake . alone works correct)
Also two files (vba.glade and gbadvance.svg) end up in src/gtk, which is not very appropriate for these files I believe. Maybe /usr/share/vbam/gtk and /usr/share/icons would be more compatible with packaging standards of most distros?
Well, if you read CMakeLists.txt (doing that is just oh-so-obvious) you would learn that you need to define DATA_INSTALL_DIR for cmake, too.
It's done this way, so there's a way for gvbam to work while still in the source tree.
It's not a nice way, cause you need to rerun cmake when you actually want to install (please correct me if I'm wrong), but otherwise you'd have to install to check if it's working.
It should probably be defined to share/vbam (or share/gvbam)