Darn.
1 Like
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.
2 Likes
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.
3 Likes
(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.
4 Likes
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.
5 Likes
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)
2 Likes
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.
1 Like
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.
If youāre going to be mad at anyone then you really should make more of an effort to be mad at me, though ā Iām the one who has been slow porting the GUI to more modern libraries, something which Graham Nelson is not guilty of impeding in any way, and in fact has had no involvement with whatsoever. What can I say, Iām working on it.
If anyone is comfortable compiling things themselves, Iād appreciate some testing of my code on this āgtk3ā branch; if I can be somewhat confident that itās not worse than the current version that you can get from Flathub, Iāll release this one there instead.
Interesting, I donāt think I knew this either, other than that Adam had updated it to fix the gettimeofday call. In any case there may be another update at some point since Adam and I had talked about compiling a binary for ARM64 processors.
5 Likes
For those interested in trying it, it might be easier to build than you expect (all depending, of course, on where your expectations areā¦)
On Debian Buster (probably extremely close on recent Ubuntus but exact package names may vary and will definitely vary on distros that arenāt Debian derivatives):
$ sudo apt-get install git build-essential pkg-config libncurses-dev \
itstool uuid-dev libgoocanvas-2.0-dev libxml2-dev libgtkspell3-3-dev \
libgtksourceview-3.0-dev libwebkit2gtk-4.0-dev libglib2.0-bin \
libgstreamer1.0-dev gstreamer1.0-tools libgstreamer-plugins-base1.0-dev \
gstreamer1.0-plugins-bad gstreamer1.0-plugins-good uuid virtualenv \
libgspell-1-dev libplist-dev texinfo desktop-file-utils libcanberra-gtk3-module \
dbus-x11
$ virtualenv --python=python3 meson
$ source meson/bin/activate
$ pip install meson==0.55.0 ninja
$ git clone -b gtk3 https://github.com/ptomato/gnome-inform7.git
At this point you have to manually copy the appropriate ni binary for your architecture to gnome-inform7/src/ni/ni ā if you already have Inform 7 installed, you already have a copy, probably in /usr/local/libexec/ni , otherwise find it in http://inform7.com/apps/6M62/I7_6M62_Linux_all.tar.gz . Once thatās doneā¦
$ cd gnome-inform7
$ meson setup build
$ cd gnome-inform7/build
$ meson compile
$ sudo meson install # WARNING! will overwrite any existing gnome-inform7 under /usr/local
# now you can run it with
$ LD_LIBRARY_PATH=/usr/local/lib/x86_64-linux-gnu gnome-inform7
# or if you don't do meson install, run with:
LD_LIBRARY_PATH=gnome-inform7/build/subprojects/ratify:gnome-inform7/build/subprojects/chimara gnome-inform7/build/src/gnome-inform7
Iāve ripped this from a Docker image Iāve been working on that does some other things, too. Odds are good you donāt really need pkg-config, libncurses-dev, automake and other packages included above, but Iām not going to re-test paring it down right this minute. [Edited to adjust package list, adding dbus-x11 and libcanberra-gtk3-module and removing cmake, bison, automake.]
2 Likes