Oh yes, definitely. The problem with “use at your own risk” is that it only takes one moment of stupid, of forgetting that I’m not in this nice decent safe space but out in the wilds of the 'net somewhere, and boom! Suddenly I’m Putin’s stalking horse or something. So I’m trying to acquire the habit of regarding appimages with suspicion.
1 Like
Just quickly reporting that the .deb package installs without hitch on x64 Linux Mint 20.1 and the IDE starts and compiles my existing project with no problems. Seems a little snappier than the last version, too.
Two small annoyances I noticed quickly with this version. Both apply to the in-IDE interpreter and are maybe artefacts of using glulxe for that, but neither happened on the previous version I was using.
One is that setting [italic type] seems to also substantially reduce the font size for italic text, which is really noticeable:
My “formatting” setup looks like this:
… and I haven’t intentionally done anything to monkey with themes or font setup or anything like that.
The other annoyance is that glulxe doesn’t always scroll on text output; sometimes it just displays the MORE button at the bottom without scrolling at all, or only scrolls partway. It’s of course always been true that if you dump a whole bunch of text to the screen, it displays the first page and then the MORE prompt, but now it sometimes just displays the MORE prompt without scrolling at all first, meaning I have to hit the space bar to see the text that just got printed to the screen.
1 Like
Thanks for pointing it out, this should be fixed in the most recent build on GitHub.
Yeah, this has been a problem for a long time, I haven’t managed to figure it out yet. I likely wouldn’t hold up releasing a new version on that.
3 Likes
Thanks for all you do!
1 Like
Could I request a small additional change?
The fiction project I contribute to requires a patched version of the 6M62 ni compiler as it’s otherwise too large to compile. By patching the top two bytes of the number at seek position 10481 with bytes 0xFF we get a compiler with limits large enough to work just fine.
Could you consider increasing the static limit on whatever that inbuilt limit might be, to the maximum integer value, so that future releases of the compiler don’t require hacking the binary?
I always ship the app with the officially released compiler binaries, I’m not sure I’d want to be responsible for shipping an unofficially patched version, since I wouldn’t really know what I was doing… This is a good question though and I’ve mentioned it to the rest of the dev team. Hopefully it can be resolved.
This limit is going to be removed in future versions of the compiler, and backported to current versions. I probably will not be able to include the change in this UI refresh that I plan to release shortly, though — I’ll wait for a new build of the compiler.
1 Like
Hi! I’m just starting to dabble in Inform, but I’m a programmer myself and I’d be glad to do what I can to help with testing. I’m excited to see that an update to the GNOME IDE is on the horizon!
I’m currently running Ubuntu 21.10, and will likely upgrade to 22.04 in early May.
I installed the latest build, first via flatpak as I previously had the published flatpak installed. I had a few issues, described below. Then I tried the .deb version, which worked much better, except that while running a story, the right window switched from the story pane to the skein pane every time I pressed enter.
The updated UI looks great, and it seems to play much nicer with Ubuntu’s dark theme than the published version. However, the story pane renders with a dark background, and the dark blue command text is very hard to read against it (the published version has this issue too). I would really love if I could customize the font and/or background colors in the story pane, or at least if the story pane used a light background like the editor pane. At present, I have to switch to a light GTK theme as a workaround.
As for my flatpak issues—I opened a pre-existing project I had been using to run sample code from the Inform manual, and got this message when I clicked run:
Translating the Source - Failed
The application ran your source text through the Inform 7 compiler, as usual, but the compiler unexpectedly failed. This should not happen even if your source text is gibberish, so you may have uncovered a bug in the program.This seems to be an unusual case, because the failure code is not one which has ever been observed in Inform’s testing process, so it is difficult to give advice. Still, further details may be visible on the console output in the Console tab.
The best option now is probably to reword whatever was last changed and to try again. Subsequent attempts will not be affected by the failure of this one, so there is nothing to be gained by restarting the application or the computer. A failed run should never damage the source text, so your work cannot be lost.
If you think it likely that the Inform 7 compiler is at fault, please check that you have the currently distributed build of the system: if you have, please consider taking the time to fill out a bug report at the Inform bug tracker (Bugs | Inform 7). If you think the fault may be due to a problem in an extension you’re using, then please contact the extension’s author directly.
Sorry for the inconvenience.
I’ve occasionally had trouble with fresh installs of other flatpak apps in the past, so I tried rebooting. Then I tried uninstalling and then installing the previous build, with the same result. I uninstalled again and re-installed the latest build using the command-line method (I had double-clicked the flatpak previously). I believe I got the same error again, but I don’t quite remember; in any case, I then tried creating a new project, which compiled successfully. After that, I was able to load and compile my existing test project. However, when I entered my first command in the story pane, the IDE crashed, and this continued to happen upon re-launching the IDE and running the story again.
I don’t know a lot about flatpak, but my guess for the compiler issue is something to do with sandboxing (perhaps the write permission didn’t register properly until I created a new project?). I also may have complicated things by not remembering to uninstall the published flatpak before trying to install the new build. I don’t have any guess about the crash-after-command issue.
I hope this report is helpful. Thanks for all your work on this!
Thanks for the report. I really appreciate the extra eyes as I continue to get closer to publishing this branch.
I’ve fixed this in the latest build.
Sorry about this. A fix probably won’t make it into the update. The theming system in the story pane needs a bit of an overhaul.
I do see this issue with the Flatpak build as well, but just to confirm it’s the same thing: would you mind checking the “Progress” tab in the view that shows the problem report that you see?
I see something like this:
Failed to create folder </run/user/1000/doc/2932dc02/(Your project name here).materials>
Unable to create folders in local file system
If this is what you saw, then it should be fixed in the latest build, but you might have to delete the file ~/.var/app/com.inform7.IDE/data/recently-used.xbel. This will “forget” the recent files that you’ve opened with the sandboxed version.
(skip this paragraph if you don’t care about the technical details) This is indeed a sandboxing issue and is due to the program receiving /run/user/... as the location of your project instead of its real location (in theory, the system should not leak details about your folder hierarchy to an untrusted app.) This doesn’t take into account our use case of needing to create a materials folder alongside the project folder, though. This is a use case that flatpak doesn’t handle well and is tracked here. I thought I had solved this but it turns out I was wrong due to some settings from the pre- and post-update apps conflicting and masking the problem. To fix this I’ll need to have the app request full filesystem access, unfortunately.
Sorry about that. I would eventually like to have a setup where flatpak packages of test builds are installable alongside the stable version, and have a separate icon and are labeled something like “Inform (Test build)”, but I do not have that yet.
2 Likes
Confirmed; installing the .deb from this build, I no longer have this issue.
I figured this would probably take longer. I’d be willing to try to pitch in on this if you’d be interested, though of course I’d also totally get it if having someone else poking around in your codebase would be more trouble than it’s worth.
I can’t seem to reproduce my original compiler issue anymore with the previous flatpak build, even if I have the published flatpak installed at the same time like I did at first. I apologize for not being able to confirm this.
I still had the IDE crash upon entering my first command with the latest flatpak build.
I’m always down for some technical details 
I think flatpak has some kind of support for a beta channel. I’d be willing to do some research here if you’re interested.
Thanks, I did read that in your original post but then I overlooked it when I was trying to figure out if I had addressed everything 
This should be fixed now.
Sure! I’m thinking along the lines of what the messaging app Fractal does, where they have a separate manifest which builds the application with a profile=development configuration, that somehow triggers all this cool stuff like a separate app name and app ID, and a fancy “under construction” design on the app icon and window titlebar. I haven’t looked into it too much yet.
I can give some more details about how I’d tackle the CSS issue but maybe PM me if you’re interested in doing that.
As a heads up, I’ve changed the version numbers of the packages.
If you installed the RPM or DEB package previously, you may need to remove it (with sudo dnf remove inform7-ide, or sudo apt remove inform7-ide) before installing a new build.
For the Flatpak package, it should just be OK, I don’t believe anything special has to be done when installing a new build.
3 Likes
I finally upgraded to the new release candidate, and immediately ran into an issue—the window refuses to be resized to fit on my screen. It seems to have a minimum height that’s a bit taller than my monitor. (I work at 200% zoom, because it’s easier on my eyes.)
Is there an easy way to fix this? It’s annoying not being able to see the status bar at the bottom.
Oh, dang. That may not be easy to fix until I adopt the slightly more vertical-space-saving design that the MacOS app has already introduced.
Can you let me know what the vertical resolution of your screen is, when it’s at 200% zoom? I’ll see what I can do.
The display is 2560×1440, so at 200% I believe it’s effectively 1280×720.
If I have to reduce the zoom to use I7, it’s not the end of the world, but it is a minor annoyance.
Following up on this, since it’s becoming more of an annoyance to switch back and forth, this is how much of the IDE I can see:
This uses the full height of my screen, and I’m missing the Settings tab and the status line at the bottom. More importantly, though, I can’t see the bottom page or so of any section in my source text, because it goes into the part of the window that’s off the bottom of the screen.
Saving space isn’t especially an issue—this is a fine amount of text for me to look at at a time. But it would help a lot if the window would let me resize it to this height.
Hi Daniel,
Sorry I didn’t manage to address this before the 10.1 release. Would you mind opening a bug for this in https://inform7.atlassian.net ? I’d like to keep the known bugs in a format that’s easier for me to handle than forum threads 
Can do! Is that bug tracker also for the IDEs, though? I thought it was just for Inform 7 itself (as in, the compiler and toolchain).
It is. You can specify that the “component” is “IDEs” although I’m pretty sure the maintainers of the bug tracker will eventually route it to the right place even if you don’t…
1 Like