• Screwtape's avatar
    Update to v106r47 release. · 6090c639
    Screwtape authored
    byuu says:
    This is probably the largest code-change diff I've done in years.
    I spent four days working 10-16 hours a day reworking layouts in hiro
    The result is we now have TableLayout, which will allow for better
    horizontal+vertical combined alignment.
    Windows, GTK2, and now GTK3 are fully supported.
    Windows is getting the initial window geometry wrong by a bit.
    GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
    resize signals, and instead keep a list of all hiro windows that are
    allocated, and every time the main loop runs, it will query all of them
    to see if they've been resized. I'm disgusted that I have to do this,
    but after fighting with GTK for years, I'm about sick of it. GTK was
    doing this crazy thing where it would trigger another size-allocate
    inside of a previous size-allocate, and so my layouts would be halfway
    through resizing all the widgets, and then the size-allocate would kick
    off another one. That would end up leaving the rest of the first layout
    loop with bad widget sizes. And if I detected a second re-entry and
    blocked it, then the entire window would end up with the older geometry.
    I started trying to build a message queue system to allow the second
    layout resize to occur after the first one completed, but this was just
    too much madness, so I went with the simpler solution.
    Qt4 has some geometry problems, and doesn't show tab frame layouts
    properly yet.
    Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
    something is seriously wrong there, and it's not hiro's fault. Creating
    a dummy Qt5 application without even using hiro, just int main() {
    TestObject object; } with object performing a dynamic\_cast to a derived
    type segfaults. Memory is getting corrupted where GCC allocates the
    vtables for classes, just by linking in Qt. Could be somehow related to
    the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
    10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
    ability to debug, so this one's going to stay broken.
    The Cocoa port is busted. I'll fix it up to compile again, but that's
    about all I'm going to do.
    Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
    resize windows very quickly now.
    higan crashes when you load a game, so that's not good. bsnes works
    bsnes also has the start of a localization engine now. Still a long way
    to go.
    The makefiles received a rather substantial restructuring. Including the
    ruby and hiro makefiles will add the necessary compilation rules for
    you, which also means that moc will run for the qt4 and qt5 targets, and
    windres will run for the Windows targets.
Last commit
Last update
arm7tdmi Loading commit data...
gsu Loading commit data...
hg51b Loading commit data...
huc6280 Loading commit data...
lr35902 Loading commit data...
m68k Loading commit data...
mos6502 Loading commit data...
spc700 Loading commit data...
upd96050 Loading commit data...
v30mz Loading commit data...
wdc65816 Loading commit data...
z80 Loading commit data...
GNUmakefile Loading commit data...
processor.hpp Loading commit data...