This adds support for extension projects, which the last OSX build introduced. Extension projects allow extensions and their associated examples to be developed and tested with rather more support than previously.
There aren’t any really exciting new changes in this build, just some incremental improvements that will hopefully make a few things better:
The skein tab now has some of the improvements from the OSX version: the appearance of knots and the layout of the context menu has been updated, layout algorithm is less wasteful of space, and there is an optional help page shown below.
The compiler is now built with a much more recent version of GCC (5.4, which is the latest MinGW-w64 version included with Cygwin). This seems to make it slightly faster, but reports from the field are welcome.
If the compiler hits an internal error (that is, stops with error code 10 or 11) then a proper stack back-trace is written to the console (on the Report tab). If you’re entering a bug at inform7.com/mantis for such a problem, adding the stack back-trace will help diagnose the problem a lot.
The indexes used to search documentation are now generated when the front-end starts, rather than when the documentation is first searched, making the first search faster.
The Glulx story interpreters now support version 0.7.5 of the Glk specification.
The story interpreters now handle PNG images with a gamma chunk (this is Mantis bug 1957).
Thanks for this! I really appreciate all the work you’ve put into the Windows build over the years.
That being said, the new skein strikes me as kind of a mixed bag.
I like the way the context menu for knots works. It’s much smoother than right-clicking, especially when you’re using a finicky touchpad to do your clicking.
I like the way clicking on a knot highlights the whole thread all the way back to the start.
Being able to specify whether to insert a knot above or below the selected knot is handy. I always guessed wrong with the previous skein.
“Split thread” is handy.
Personal preference, but I strongly dislike the color scheme. The green and gold jewels of the previous version were much, much nicer than this flat gray. It might not be so bad, except…
…eliminating all the white space does not make the skein any easier to read. Between the gray and the dense layout, the skein feels overcrowded and oppressive.
There is no longer any way to jump to a specific label, which pretty much defeats the purpose of having labels at all! They are also difficult to see with the new color scheme/layout.
There seems to be no way to lock threads, which means if I want to keep one or two important threads but clean up the rest, I have to do so carefully & manually instead of just locking the ones I want to keep and clicking “clear all”.
You can bless a command or a thread, but there is no visual feedback, and no way to tell which threads are blessed and which aren’t.
On balance, there are a few nice features, but a big step backwards in look and functionality. I hope some of these problems are improved or fixed soon.
How close are the Windows and Mac skein UIs at this point? I know the Mac skein UI came in for some criticism in 6M62 (can’t find refs at the moment). Some of the above may be relevant to both platforms.
Another missing feature: you used to be able to double-click a knot as a shortcut for “play to here”. Not such a big deal, since you can also just open up the context menu and select that option, but… it’s yet another example of a convenience that’s now gone, and it’s not clear why it had to go or what we’re meant to gain in its place.
Probably not, no … The search could really do with a full overhaul with a better UI to closer match the Mac implementation. That is on the list of things to do. I am unconvinced that adding a dependency on Lucene will add much, but as ever, the best argument would be a patch to implement it …
Just a heads up, this post is the only reason I knew to download a new build as the download page on Inform7.com still lists the release date of 2015-12-24. You probably should have a new release number as well.
It’s usually just Visual Studio 2012. It does have to be the full edition with the MFC libraries installed. For building the final release I use an older version: Visual Studio 2002, as that produces executables that work on older versions of Windows.
The only dependencies are some third-party C libraries: hunspell, jpeglib 6b, libmodplug, libogg, libpng, libvorbis and zlib. I would be very reluctant to add any framework dependencies like .NET or Java.
Working within the framework of general C++ and keeping it backwards compatible with older windows is a fair expectation. I’m not interested in changing your work environment. I just want to look at forking the code as-is and adding something seamlessly to the user interface to see if it’s a viable alternative to existing functionality.
It would also be helpful to have detailed build and installer creation instructions in a readme.md file on the GitHub repository.