XRoar 1.4 released

[sixxie]

It does work well on all my programs and I have also a high dpi display

Could just be that as example code it doesn't do all the things you're supposed to do to make sure it's right

I compiled the "cube" example just to make sure the opengl stuff was working.

[sixxie]

And indeed, for reasons I can't explain, a simple FLTK framework for XRoar and the menubar font seems normal to me.

What I am finding weird is having to specify dimensions, eg the height of the menubar - wasn't this originally a forms library? Shouldn't it be doing that for me? Maybe as I read more...

Edit: looks like more complex resizing behaviour has been described for FLTK 1.4... so might be worth scrapping this and starting again with that. Sad, as it's not packaged up for even Debian testing, seemingly.

Also the way you create menus seems to not be very dynamic - like I'd have to recreate the whole menubar to update the Machines submenu, etc. Again, we'll see.

[sixxie]

FWIW I've made a 'fltk' branch public with what little I've done so far.

It works under Linux, and it seemed to work on Mac OS X too. While I did manage to build a Windows version, all I got under Wine was a non-updating black blob where the OpenGL was supposed to be.

Now, I haven't actually done any dialog boxes yet, it's really the bare minimum to show things working, but it's getting there Even if the result only ever ends up used for Linux and Mac OS X+ that could still be a win.

FLTK itself has some niggles. The obvious big one being it's C++ Also the codebase for it is quite crufty, because it's evolved over a very long time: even for C++, it's difficult to trace what's subclassing what etc.

FLTK 1.4's approach to high-DPI is to treat all coordinates as though they were for a 96DPI display and then scale everything. That probably works quite well for most things, but I want control of how many pixels there are, dammit! Also when it does the same thing to user-specified geometries, I think that's actually incorrect. Thankfully, you can override such scaling anyway, while still making use of what it thought it should be if you like, so there should be no problem there.

Also, FLTK is getting active development. I actually submitted a patch (just a personal irritation regarding how toolkits interact with window managers under X11), and someone was on it almost straight away - while committing new stuff themself. That's cool. Obviously GTK will also be getting such attention, but it's the big dog so you'd expect that. And anyway GTK seem to be sriving to make their stuff ever worse

[robcfg]

I use CMake for generating the build files, and on Windows it creates a nice Visual Studio solution that so far, hasn't failed me.

So, I think it's perfectly possible to get all three systems working with the same toolkit, which will then take a lot of maintenance away

[sixxie]

I use CMake for generating the build files, and on Windows it creates a nice Visual Studio solution that so far, hasn't failed me.

So, I think it's perfectly possible to get all three systems working with the same toolkit, which will then take a lot of maintenance away

I have a grudge against cmake: I've seen it lock up trying to build itself on Solaris and then lots later Mac OS X homebrew. A build system that gets confused trying to build itself seemed... problematic. Also the end user has to have it installed to do anything with a cmakefied project, which makes me turn my nose up.

But that's fine, FLTK comes with a configure script too. I was able to get it cross-built for Windows. Today I'll try the result on a real Windows box: it's possible something about Wine didn't like it using OpenGL? Though come to think of it, isn't OpenGL on Windows generally unreliable? This might not be a great direction for the Windows build anyway...

[sixxie]

Hey what do you know - it works on a real Windows box: http://www.6809.org.uk/tmp/xroar/xroar-fltk.exe

[robcfg]

I tried it with Wine on my Mac and it seems to work fine!