Oh, sweet. Thanks so much for all your help; I’m looking forward to having some fun with this.
(Edit) Wait, that very much didn’t work; it looked like it did, but the folder doesn’t show up in my filesystem and I can’t re-open the test project I saved in another folder. Only having one sandboxed folder I can use is very annoying, but not a dealbreaker, so I’ll just live with it.
I think it really is Flatpak sandboxing in this case, not just the former file-browsing problem.
Darn.
So, here’s a weird problem that might be because of Flatpak sandboxing, but I don’t know for sure. I can’t change any of the Formatting preferences. I can’t select a different theme, and if I open the Font dialogue and select something different, it doesn’t take.
I was sure I had managed to get the Flatpak running properly, with access to the file system, and now I found out how I did it before:
flatpak override <package_name_here> --filesystem=<path_here>
I got the answer from this thread here:
Another tip there was a program called flatseal that manages permissions for flatpaks.
Hi,
I have made a fix that will hopefully fix both of these errors (the file system access, and changing the preferences) here: Permissions by ptomato · Pull Request #5 · flathub/com.inform7.IDE · GitHub
These issues were both due to Flatpak sandboxing.
Once the test build finishes, I’ll merge it right away. After that happens, if you update with flatpak update or your software center then it should work properly.
I hate to keep asking for everyone’s patience, but I’m still working off and on at porting the IDE to use more modern versions of the dependencies so that we don’t have to use such an old version of the Flatpak runtime.
(And if there’s anyone who’s comfortable compiling the program from source — it’d be great to have some people trying it out)
In case were still wondering this, it didn’t run because it’s IDE, not KDE 
Personally as the author of an app, I prefer it this way — over the years I’ve had basically no chance to distribute Inform widely unless I built packages for every architecture and every Linux system myself, or relied on others to do it. And even then you just have to trust me, or the other packagers, that I didn’t hide malware in there… There would have been no way that the big Linux distributions would have picked up and maintained Inform as a trusted package, since it’s such a niche application. Flatpak (well, assuming I get the sandbox permissions right) allows me to distribute packages without much hassle, that at least you can be reasonably sure will not be able to wreak havoc on your computer. So I do plan to lean more heavily on Flatpak for distributing Inform in the future.
That is great, thank you!
Sorry, I was unclear. I didn’t mean to talk smack about the devs using Flatpak to distribute software, which is a totally reasonable response to the dumpster fire that Linux app packaging unquestionably is. Anyone packaging apps for distribution on Linux is an underpraised essential worker.
I was talking about some of the implications built into the Flatpak system itself, and how I wish those devs had made different structural decisions. (Needing flatpak run [identifier] instead of being able to just type the name of an executable in $PATH being one, but only one, of those issues.)
Thank you for maintaining the Linux port.
For what it’s worth, I believe this has been sort-of fixed: with newer Flatpak versions you can type com.inform7.IDE to run the app, without flatpak run. (IIUC they still won’t allow the executable name because they don’t want some random app to be able to include an executable named sudo and steal your admin password)
So, gnome-inform7 is dead on modern Debian computers again. I don’t know GTK, but I’d say it needs a rewrite with a modern version.
I tried the build at interactivefiction/gnome-inform7-builds; I dug out an obsolete copy of libpng12-0; but it’s dying because it wants libwebkitgtk-1.0-0, which has a mess of dependencies and which I can’t install without breaking more modern programs. I can’t get interactivefiction/gtk3-alldeps-inform7 to configure because it’s looking for too many obsolete libraries.
After the experience with ni needing recompilation for several years for a simple gettimeofday call, which killed my experimentation with Inform 7 for years, this isn’t very encouraging. The bit-rot problem is getting bad.
I tried setting up the command-line interface, which almost worked, but I can’t figure out how to get “ni” to find my extensions directory, since the command-line interface to ni is undocumented. I am so disgusted with Graham Nelson right now.
I disagree with the last line, because of the tone; I don’t hide that here and there in my WIPs I have placed some jab on him; but I substantially agree, but you should consider his limits.
AFAIK, he was, and still is, a mathematician @ oxford (UK), so coding isn’t his first activity, but an important support to his first activity (I understand this, because, being a Naval historian, often I need quick’n’dirty navigation, ballistics, &c. programs, and trust me, no one want to see the resulting code…)
and, from his known environment, I can even picture the classical oxonian stereotype: tweed, tea and phlegm. And is the latter perhaps is the real issue here.
I can speak only about me: I guess, or hope, that no one is disgusted about me (perhaps aside politics ?) because I can afford the luxury of NOT talking about my WIPs, save their existence, but for Graham, this isn’t an option. and he understand that has limits in coding prowess (reading his posts in the r.a.i.f archives during the Inform 5/6 era, mid-90s, era is very instructive on the persona and his handling of development, and if you look at inform 5 & 6’s source (both compiler and library) archive you surely get why he want to release a readable and polished opensource for ni.
Best regards from Italy,
dott. Piergiorgio.
Oh, I understand his motivation. But… for the last five years, he’s done an incredible disservice to everyone who’s tried to use Inform 7, especially but not only on Linux, by letting it bitrot and making it extraordinarily difficult for anyone else to maintain it. I just resorted to a hex editor just to figure out how to get the command line version of ni to load extensions in Linux. (The correct, undocumented argument is ’ --external “$HOME/Inform” ', with extensions in $HOME/Inform/Extensions . ). The last time I was trying to work with Inform in 2017, the gettimeofday bug bit me, and woe to anyone working on Linux who doesn’t have the specially-recompiled version of ni which was finally extracted from Graham Nelson that year.
It does not seem too much to ask for some basic documentation of what he has already released – such as documenting the --external and --internal command line options to ni. A 20-minutes-of-work maintenance release every couple of years to keep up with modern OSes would have worked wonders, too.
I’d say this is a problem with proprietary software in general. Graham is aware of the issues and therefore working on a complete rewrite which will be released under a free license.
In the meantime, the flatpak version from ptomato should work fine on Debian.
You can be but it doesn’t change the situation.
Would it help if I pointed out that Graham doesn’t do the Linux builds, e.g., to address the gettimeofday thing? You could be mad at Philip Chimento instead.
I may be mistaken but I don’t believe any of the major players in IF are compensated in any way, particularly the development system coders. Some authors may be able to sell their work but I doubt they make much compared to using their talents in a more commercial way.
Chris has a (personal) Patreon to support his Twine development work.
Fair enough. I find it hard to be mad at Philip Chimento, since he’s in the unenviable position of being one of very few people Graham Nelson deigns to share enough source code with to compile.
I finally got the command-line version of i7 (by Adam Thornton) working. I’m OK with that; I don’t need an IDE and am quite comfortable with command-line workflow.
Though I can’t figure out why it’s trashing my git directory records every time it runs, necessitating some extra copying back and forth between a repo directory and a working directory…
…wait, I solved it. Bug in the perl script, which was being too clever for its own good. Do you know where I should send amendments to the command-line perl script? Should I still email Adam Thornton, I wonder?
My greatest frustration was simply the lack of documentation of the command-line invocation of ni; a remarkably large obstacle when trying to debug the invocation. If only that had been in some documentation somewhere. Thank you, zarf, for putting the full invocation up.
It actually looks like the commandline Linux tarball on inform7.com has been stealth-updated a few times without version numbering changes or datestamp updates (but updating ni and inform6), which is simply confusing (I didn’t think to redownload at first since it looked like I had the most recent copy). I suppose I should have been keeping track of checksums to spot updates, but really, keeping a dev environment going shouldn’t be like computer archaeology.
Hunh. Yeah, 6M62 was originally December 2015 but the timestamps on the binaries in the gnome package are January 2016 and in the current CLI package they’re May 2018 and the ni and inform6 sizes are different.