[Linux] GUI discussion
[Linux] GUI discussion
Hi again.
I am interested in building a new GUI for linux (I prefer one GTK based but I am open to suggestions).
Would you be interested in integrating this into mainline? Or maybe would it be better to create my own fork?
Is anyone already working on something like this?
I am interested in building a new GUI for linux (I prefer one GTK based but I am open to suggestions).
Would you be interested in integrating this into mainline? Or maybe would it be better to create my own fork?
Is anyone already working on something like this?
Re: [Linux] GUI discussion
I have a soft spot for FLTK only because (on Windows) it doesn't need a hundred of prerequisite dlls installed, doesn't bloat up the binary hugely when statically compiled and it can resemble pretty close to native Windows gui. On the development and linux side i'm not so sure nor am i sure of its application in use of real-time emulation
A good example of fltk in use is Oblige
A good example of fltk in use is Oblige
- SarahWalker
- Site Admin
- Posts: 2054
- Joined: Thu 24 Apr, 2014 4:18 pm
Re: [Linux] GUI discussion
Tuxality was looking at implementing a GTK+ GUI - viewtopic.php?f=2&t=573#p3941. Might be worth syncing up with him?
I'd certainly be interested in including a proper Linux GUI in mainline.
I'd certainly be interested in including a proper Linux GUI in mainline.
Re: [Linux] GUI discussion
FLTK is nice and would be a good candidate if we wanted a cross-platform GUI.leilei wrote:I have a soft spot for FLTK only because (on Windows) it doesn't need a hundred of prerequisite dlls installed, doesn't bloat up the binary hugely when statically compiled and it can resemble pretty close to native Windows gui. On the development and linux side i'm not so sure nor am i sure of its application in use of real-time emulation
But if it is just for Linux I believe that GTK is better because:
- On Linux shared libraries are the standard. On most Linux systems GTK is already installed. However, FLTK would create a new dependency because it is rarely used.
- GTK is C and it will integrate better with PCem. FLTK is C++ (although it is certainly possible to use it).
- Visually FLTK is a bit ugly (IMHO) or at least it does not look native on Linux.
Re: [Linux] GUI discussion
Ok, I will send a PM to him.SarahWalker wrote:Tuxality was looking at implementing a GTK+ GUI - viewtopic.php?f=2&t=573#p3941. Might be worth syncing up with him?
Great!SarahWalker wrote:I'd certainly be interested in including a proper Linux GUI in mainline.
Re: [Linux] GUI discussion
Thank you for PM. My vote goes for GTK, it will be close to PCem's vibe. If you want we can do this together.AmatCoder wrote: Ok, I will send a PM to him.
I can start working on this from April I believe as I have quite a lot things to do in real life and I promised on other forum that I'll release some stuff, I don't want to make another delays.
If I remember correctly, I should have some preliminary stub, but I don't know if anything has changed in newer version of PCem. It would be better to start this from scratch in my opinion, it will be easier to plan, maintain code and also splitting task would be better.
Re: [Linux] GUI discussion
Alright, there is no rush, we can wait until April.
When the moment comes, let me know if you need help with this project.
Thanks and regards.
When the moment comes, let me know if you need help with this project.
Thanks and regards.
Re: [Linux] GUI discussion
Well, I have exchanged some PM's with Tuxality and we have decided that I should start this project (Tuxality will join when he find some free time).
But there are some technical decisions/options that need to be discussed and it is better to do it here.
So I'll write here some guidelines I would like to follow for discussion (or rejection ):
PD.- Some patches are needed to fixing some issues related to linux port. I will open a new thread for these.
But there are some technical decisions/options that need to be discussed and it is better to do it here.
So I'll write here some guidelines I would like to follow for discussion (or rejection ):
- I'll clone Pcem code to a public github repository to work on this. Patches will be attached in this thread (in hg diff format).
- GTK+ is the chosen toolkit. It will be compatible with versions 2 and 3.
- It must be enabled at compile time (i.e. ./configure --enable-gui=gtk2). If not enabled, Allegro gui can still be used.
- I would like to use a glade file for the interface and link it into the executable with GResource (so PCem will remains as relocatable application).
PD.- Some patches are needed to fixing some issues related to linux port. I will open a new thread for these.
Re: [Linux] GUI discussion
I PMed AmatCoder about wanting to help out with the new Linux GUI and to ask if there's anything that can be used from my own GUI-project that I’ve been working on which is based on wxWidgets and SDL2. He said that it might and that I should post it here so everyone can join in on the discussion.
Here is a screenshot of what the GUI looks like:
As can be seen in the screenshot there are two windows, one is the machine and the other is the display. By default the machine-window is smaller, with only the first three lines and the drive-status icons visible. The graph at the bottom shows a short history of the the emulation speed.
When starting the emulator it is in an “powered off” state, so only the machine-window is visible. Using the toolbar the emulation can be started, paused or stopped (similar to what was mentioned in the config revamp-thread). Starting the emulation pops up the display-window and while it is running the machine-window can be hidden through the menu or Ctrl+Alt+PageUp. Fullscreen is toggled through the menu or with Ctrl+Alt+PageDown.
The main advantage of having the display as a separate window is that while using the emulator it will be through pure SDL2 which has very good support for input-devices.
Most of my focus has been on SDL2 (which can be configured with several options) and the features that can be seen in the machine-window. The majority of the menu and dialogs are ported straight from the Windows-source so it looks and behaves pretty much the same.
Is this something that could be of any use?
The code is available here:
https://github.com/mborjesson/PCem-wx-SDL2
It depends on wxgtk3, sdl2 and openal and to build it use Makefile.linuxXX-wx-sdl2.
To install dependencies on Ubuntu: sudo apt install libwxgtk3.0-dev libsdl2-dev libopenal-dev
To compile it with MinGW on Windows 32-bit download wxMSW-3.1.0_gccXXXTDM_Dev.7z and wxWidgets-3.1.0-headers.7z from https://github.com/wxWidgets/wxWidgets/ ... tag/v3.1.0, SDL2-devel-2.0.5-mingw.tar.gz from http://libsdl.org/download-2.0.php and OpenAL.
Use Makefile.mingw-wx-sdl2 to build it.
Here is a screenshot of what the GUI looks like:
As can be seen in the screenshot there are two windows, one is the machine and the other is the display. By default the machine-window is smaller, with only the first three lines and the drive-status icons visible. The graph at the bottom shows a short history of the the emulation speed.
When starting the emulator it is in an “powered off” state, so only the machine-window is visible. Using the toolbar the emulation can be started, paused or stopped (similar to what was mentioned in the config revamp-thread). Starting the emulation pops up the display-window and while it is running the machine-window can be hidden through the menu or Ctrl+Alt+PageUp. Fullscreen is toggled through the menu or with Ctrl+Alt+PageDown.
The main advantage of having the display as a separate window is that while using the emulator it will be through pure SDL2 which has very good support for input-devices.
Most of my focus has been on SDL2 (which can be configured with several options) and the features that can be seen in the machine-window. The majority of the menu and dialogs are ported straight from the Windows-source so it looks and behaves pretty much the same.
Is this something that could be of any use?
The code is available here:
https://github.com/mborjesson/PCem-wx-SDL2
It depends on wxgtk3, sdl2 and openal and to build it use Makefile.linuxXX-wx-sdl2.
To install dependencies on Ubuntu: sudo apt install libwxgtk3.0-dev libsdl2-dev libopenal-dev
To compile it with MinGW on Windows 32-bit download wxMSW-3.1.0_gccXXXTDM_Dev.7z and wxWidgets-3.1.0-headers.7z from https://github.com/wxWidgets/wxWidgets/ ... tag/v3.1.0, SDL2-devel-2.0.5-mingw.tar.gz from http://libsdl.org/download-2.0.php and OpenAL.
Use Makefile.mingw-wx-sdl2 to build it.
Re: [Linux] GUI discussion
I tested this and my thoughts are:
I take my hat off to you, bit.
- Impressive work! This is more than I had in mind...Aside from some minor issues the job is done!
- SDL2 is really great. Now we can resize/fullscreen on Linux...And I believe that now it is faster than Windows port (most probably thanks to OpenGL renderer).
- It comes with some improvements requested on forum.
- It can be compiled and used on Windows too (even it could on Mac OS X if someone is brave enough... )
I take my hat off to you, bit.
Re: [Linux] GUI discussion
I'm not interested in the Linux version, but impressive job from watching the screen! Congrats bit!
Re: [Linux] GUI discussion
I assume a newer GCC than 4.7.2 is required? Wxwidgets takes a while to build and then fails memory allocation at linking, and the headers for mingw expect wx/setup.h which isn't there at allbit wrote:Use Makefile.mingw-wx-sdl2 to build it.
Not a bad idea for a window though, could stylize it after a baby-AT tower with the relevant lights, drive bays and buttons in the right places (and pop open the status window by clicking on the led indicator area)....
- SarahWalker
- Site Admin
- Posts: 2054
- Joined: Thu 24 Apr, 2014 4:18 pm
Re: [Linux] GUI discussion
Certainly looks very good! I'm away this weekend, but when I'm back I'll give this a try.
Re: [Linux] GUI discussion
Thanks everyone! I'm happy to hear that you like it! :)
And I agree with SDL2, it's awesome!
I also attempted to build wxWidgets from source and I agree that it wasn't a fun experience.
Cool idea to skin the machine window like small tower! :)
If it's alright with you I can provide a compiled Windows-version so it will be easier to test.
I think the most major features that I haven't ported is joystick- and real CD-ROM-support, but it shouldn't be too much work to add it.AmatCoder wrote:Aside from some minor issues the job is done!
And I agree with SDL2, it's awesome!
Thanks! If you'd like to try it you can build it for Windows :)omarsis81 wrote:I'm not interested in the Linux version, but impressive job from watching the screen!
You could try to build with wxWidgets 3.0.2, there are pre-built binaries for GCC 4.7.1 and 4.8.1 available at https://github.com/wxWidgets/wxWidgets/ ... tag/v3.0.2 (wxMSW-3.0.2_gccXXXTDM_Dev.7z). The pre-built binaries have the wx/setup.h-file placed in lib/mswu.leilei wrote:I assume a newer GCC than 4.7.2 is required?
I also attempted to build wxWidgets from source and I agree that it wasn't a fun experience.
Cool idea to skin the machine window like small tower! :)
Thanks! I hope you'll like it!SarahWalker wrote:Certainly looks very good! I'm away this weekend, but when I'm back I'll give this a try.
If it's alright with you I can provide a compiled Windows-version so it will be easier to test.
- TheMechanist
- Posts: 71
- Joined: Mon 03 Apr, 2017 6:59 pm
- Contact:
Re: [Linux] GUI discussion
For me GUI development, and above all cross platform, was always a torture, so thanks to all, that accept that challenge ..
.. if I may, I'd recommend a very underrated cross platform gui toolkit ..
Supports Win32 native, Linux with GTK2/3 & Motif, and is pure C and very straight forward, with little dependencies and overhead and of course opensource & MIT licensed .. a long development history and still active
IUP
http://webserver2.tecgraf.puc-rio.br/iup/
.. if I may, I'd recommend a very underrated cross platform gui toolkit ..
Supports Win32 native, Linux with GTK2/3 & Motif, and is pure C and very straight forward, with little dependencies and overhead and of course opensource & MIT licensed .. a long development history and still active
IUP
http://webserver2.tecgraf.puc-rio.br/iup/
Re: [Linux] GUI discussion
Tried thatbit wrote:You could try to build with wxWidgets 3.0.2, there are pre-built binaries for GCC 4.7.1 and 4.8.1 available at https://github.com/wxWidgets/wxWidgets/ ... tag/v3.0.2 (wxMSW-3.0.2_gccXXXTDM_Dev.7z). The pre-built binaries have the wx/setup.h-file placed in lib/mswu.
Code: Select all
$ make -f Makefile.mingw-wx-sdl2 g++ -DRELEASE_BUILD -O3 -march=i686 -fomit-frame-pointer -msse2 -mstackrealign -c wx-main.cc
In file included from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/wx/defs.h:27:0,
from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/wx/wxprec.h:12,
from wx-app.h:4,
from wx-main.cc:1:
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/wx/platform.h:183:22:fatal error: wx/setup.h: No such file or directory
compilation terminated.
make: *** [wx-main.o] Error 1
Probably wants me to build it :/
Re: [Linux] GUI discussion
Hey all,
Just reporting in that bit's SDL2 version of PCem builds and runs under OS X with minimal hassle, which is lightyears ahead of the Allegro version where you had to force it to compile in 32-bit using an 8-year old SDK because Allegro 4 depended on ancient deprecated frameworks on OS X. All that was required was
along with maybe openal-soft (I already had it installed, so unsure if it's required). After that, 'make -f Makefile.osx64-wx-sdl2' resulted in a working binary in the 'src' directory, which started up fine once it was moved to the same directory as the 'roms' folder. I tested out Need For Speed II SE in Windows 95 with Voodoo 2 emulation, which ran somewhat choppily but playably:
I also managed to get NeXTSTEP 3.3 for Intel up and running with full 32-bit colour using the Diamond Stealth 3D 2000 card:
The only major bug I've found is that enabling dynarec on either the Voodoo 2 or the CPU causes an instant crash, meaning that speeds are somewhat slow and that none of the Pentium CPUs are useable. Does this happen on Linux as well or is it just a Mac thing?
Just reporting in that bit's SDL2 version of PCem builds and runs under OS X with minimal hassle, which is lightyears ahead of the Allegro version where you had to force it to compile in 32-bit using an 8-year old SDK because Allegro 4 depended on ancient deprecated frameworks on OS X. All that was required was
Code: Select all
brew install wxmac sdl2
I also managed to get NeXTSTEP 3.3 for Intel up and running with full 32-bit colour using the Diamond Stealth 3D 2000 card:
The only major bug I've found is that enabling dynarec on either the Voodoo 2 or the CPU causes an instant crash, meaning that speeds are somewhat slow and that none of the Pentium CPUs are useable. Does this happen on Linux as well or is it just a Mac thing?
Re: [Linux] GUI discussion
Did you copy the contents from /lib/gcc471TDM_dll/mswu/ to your include folder? setup.h can be found there.leilei wrote:Probably wants me to build it :/
Nice to see it working! I don't own a Mac so I borrowed a Mac Mini just to get it working. I noticed the same issue with dynarec too but since I didn't have much time available with the Mac i couldn't investigate it. It doesn't happen on Linux though so I guess there's something in the recompiler code.ahurst wrote:Just reporting in that bit's SDL2 version of PCem builds and runs under OS X with minimal hassle
EDIT: CPU dynarec that is. The Voodoo recompiler works on Linux 32-bit but crashes on 64-bit.
Re: [Linux] GUI discussion
I just got it working in Windows
I had to modify the makefile.mingw-wx-sdl2 file to change the wx libs to -lwxbase30ud -lwxmsw30ud_core -lwxmsw30ud_xrc and add -std=gnu99 to the cflags however, as it had this to complain about:
I must mention the resulting binary is huge (10mb) and the dlls it depends on are also huge, but that's probably to expected of the typical huge 'nix UI toolkits
So far of what i've tried, what I really hate is Ctrl-End not working half of the time and it's not giving an exception to Alt-F4 (which shouldn't close PCem when the mouse is locked in). Personally i've always had bad luck with SDL2 and input on Windows so I'm not surprised at all by this.
Still not a bad proof of concept though. Voodoo2 dynarec+Pentium dynarec works fine for me BTW
I had to modify the makefile.mingw-wx-sdl2 file to change the wx libs to -lwxbase30ud -lwxmsw30ud_core -lwxmsw30ud_xrc and add -std=gnu99 to the cflags however, as it had this to complain about:
Code: Select all
wx-sdl2-video.c:311:9: error: 'for' loop initial declarations are only allowed in C99 mode
wx-sdl2-video.c:311:9: note: use option -std=c99 or -std=gnu99 to compile your code
So far of what i've tried, what I really hate is Ctrl-End not working half of the time and it's not giving an exception to Alt-F4 (which shouldn't close PCem when the mouse is locked in). Personally i've always had bad luck with SDL2 and input on Windows so I'm not surprised at all by this.
Still not a bad proof of concept though. Voodoo2 dynarec+Pentium dynarec works fine for me BTW
Re: [Linux] GUI discussion
Nice! Thanks for testing! :)leilei wrote:I just got it working in Windows :)
I had to modify the makefile.mingw-wx-sdl2 file to change the wx libs to -lwxbase30ud -lwxmsw30ud_core -lwxmsw30ud_xrc and add -std=gnu99 to the cflags however, as it had this to complain about:I must mention the resulting binary is huge (10mb) and the dlls it depends on are also huge, but that's probably to expected of the typical huge 'nix UI toolkitsCode: Select all
wx-sdl2-video.c:311:9: error: 'for' loop initial declarations are only allowed in C99 mode wx-sdl2-video.c:311:9: note: use option -std=c99 or -std=gnu99 to compile your code
So far of what i've tried, what I really hate is Ctrl-End not working half of the time and it's not giving an exception to Alt-F4 (which shouldn't close PCem when the mouse is locked in). Personally i've always had bad luck with SDL2 and input on Windows so I'm not surprised at all by this.
Still not a bad proof of concept though. Voodoo2 dynarec+Pentium dynarec works fine for me BTW
Yeah wxWidgets is a pretty big library.
Regarding your issues with Ctrl-End and Alt-F4 I've been working on a fix for these which seems to work like it should but is untested. Since you can now run it on Windows I decided to commit these changes so if you like I'd be happy if you could test them out :)
Re: [Linux] GUI discussion
When I cross-compiled this for Windows I was able to build an static executable (without dependencies) of only 3.3mb (UPX'ed, of course ).leilei wrote: [...]I must mention the resulting binary is huge (10mb) and the dlls it depends on are also huge, but that's probably to expected of the typical huge 'nix UI toolkits[...]
Re: [Linux] GUI discussion
My main problem with using this GUI on Windows would be fact it uses SDL for input which on Windows refers back to DirectInput from what I know, which according to Microsoft themselves should not be used for keyboard because it breaks when the host OS is set to a keyboard layout that is not English (US).
Re: [Linux] GUI discussion
I just build a 64-bit PCem-wx-SDL2 https://github.com/mborjesson/PCem-wx-SDL2
It seems impossible that a SDL display window and control window can be merged into one window.
It seems impossible that a SDL display window and control window can be merged into one window.
- Attachments
-
- screen2.png (227.68 KiB) Viewed 28321 times
Last edited by startmenu on Mon 01 May, 2017 2:49 pm, edited 1 time in total.
Re: [Linux] GUI discussion
Gonna explain this. The tl;dr is that theoretically, there's nothing stopping you; it just doesn't work that well, is platform specific, and doesn't integrate with your game engine very well.startmenu wrote:I just build a 64-bit PCem-wx-SDL2 https://github.com/mborjesson/PCem-wx-SDL2
It seems impossible that a SDL display window and control window cannot be merged into one window.
Theoretically, you *can display Win32 controls on top of a DirectX window.
Practically, though, it's too much trouble to bother. Especially when you go full-screen. Win32 doesn't integrate with DirectX unless you write the integration code yourself...In which case, it's not really integration; more like gluing two different things together and hoping nothing breaks.
Using your game engine to display a GUI, OTOH, integrates with everything else in your game, and works on all the same platforms as your game engine, not just Windows.
* At least you could in the DX9 era, which is the last time I checked.
Edit: Since you probably have seen games where the DX window is inside a Win32 setup, I should probably explain that one.
DX (not sure if all versions, or only past some version) can display in a Win32 panel (and presumably, a Win16 panel, although I don't actually know) just fine. You just give it full control of that panel, and off you go. In this case, Win32/16 effectively never directly interact; commands get passed from the Win32/16 controls to your game engine, which then translates them and tells the graphics engine what to display. This is effectively the same thing as giving DX full control of a Win32/16 window, except scaled down to a panel.
Re: [Linux] GUI discussion
This GUI uses SDL2 version and, as far as I know, DirectInput for keyboard input was dropped from SDL1.x to SDL2.Battler wrote:My main problem with using this GUI on Windows would be fact it uses SDL for input which on Windows refers back to DirectInput from what I know, which according to Microsoft themselves should not be used for keyboard because it breaks when the host OS is set to a keyboard layout that is not English (US).
Re: [Linux] GUI discussion
With SDL2 and wxwidgets is not so difficult.A. Naim wrote: Gonna explain this. The tl;dr is that theoretically, there's nothing stopping you; it just doesn't work that well, is platform specific, and doesn't integrate with your game engine very well.
Theoretically, you *can display Win32 controls on top of a DirectX window.
Practically, though, it's too much trouble to bother. Especially when you go full-screen. Win32 doesn't integrate with DirectX unless you write the integration code yourself...In which case, it's not really integration; more like gluing two different things together and hoping nothing breaks.
Using your game engine to display a GUI, OTOH, integrates with everything else in your game, and works on all the same platforms as your game engine, not just Windows.
* At least you could in the DX9 era, which is the last time I checked.
We could use SDL_GetWindowWMInfo to get native handle (HWND on Windows) from SDL window and wxNativeWindow to embed it in the wxwidgets application.
Re: [Linux] GUI discussion
We with international keyboards were used to automatically think of a US layout in games in the 90's and early 2000's, no big deal. But for something like PCem it would be bad.AmatCoder wrote:This GUI uses SDL2 version and, as far as I know, DirectInput for keyboard input was dropped from SDL1.x to SDL2.Battler wrote:My main problem with using this GUI on Windows would be fact it uses SDL for input which on Windows refers back to DirectInput from what I know, which according to Microsoft themselves should not be used for keyboard because it breaks when the host OS is set to a keyboard layout that is not English (US).
I can confirm that SDL2 has proper support for international layouts from my experience writing games.
Re: [Linux] GUI discussion
My reading of their post was that they wanted it the other way around. And please quote my entire post.AmatCoder wrote: With SDL2 and wxwidgets is not so difficult.
We could use SDL_GetWindowWMInfo to get native handle (HWND on Windows) from SDL window and wxNativeWindow to embed it in the wxwidgets application.
I do not want to have to start posting multiple posts for the next three minutes as I finish fixing up my posts.
Re: [Linux] GUI discussion
- EluanCM: But does SDL2 pass the raw scan codes through its API? Because if it doesn't, it's pretty much useless as you have to retranslate whatever SDL2 now uses for key codes back to raw scan codes, and if the SDL2 key codes are not directly 1:1 mapped to scan codes, you will never get the accurate sequence back. And do special keys (such as the Japanese JIS layout keys (kana, half/full, etc.)) get passed? And are the Windows Registry scan code remappings respected?
Re: [Linux] GUI discussion
I just wanted to say THANK YOU SO MUCH. @bit I'm finally able to get rid of DOSBox for good. This port is almost perfect, work beautifully under Arch Linux