I’m Philip, the maintainer of gnome-inform7, Graham Nelson alerted me to this thread. Sorry I haven’t been too responsive on this issue recently. I’ve had a lot of things going on for the past 6 months which meant I didn’t have much time to spend on Inform.
First of all I’d like to say thanks, these workarounds are much appreciated. I’m making progress on porting Inform7 to non-obsolete versions of the dependencies but it’s a tedious process made more complicated by the fact that I wrote most of the current form of the UI in 2008, and, well, I was 11 years’ worth of experience worse at programming back then. It’s progressing, but slowly.
I can upload these to the website but I’d really appreciate it if you could first share the modifications you made to make it work — ideally as a pull request to my GitHub repository so I can incorporate them in the next version.
I’ve downloaded the .deb and can confirm it works on Linux Mint 19.2 “Tina”, Mate desktop. (i.e. I’ve successfully opened an old project, and changed the settings in the IDE, the first of which the Flatpak version only sort-of managed, and the second it flatly refused to allow.)
I am happy to share the work. The source tree is a bit messy at the moment so I will need to tidy up a little. I am pulling together an Ubuntu 16.04 deb now and will also be attempting Fedora 30/31 rpms.
Here is a short explanation of what was done to get the program up and running:
Packaging Changes: To overcome the webkit-1.0 dependency affecting Fedora 29, I recompiled webkit-1.0 on Fedora 29 and added the specific libraries gnome-inform depended on to the gnome-inform rpm itself. So the rpm is carrying around libwebkitgtk-1.0.so and libjavascriptcoregtk-1.0.so now. To overcome the libgoocanvas dependency affecting Ubuntu 18.04, I migrated libgoocanvas into the source tree and linked statically to libgoocanvas. Essentially the same way chimara was handled in the source tree.
Build File Changes: The bulk of the dependency work around effort affected the top level Configure.ac, gnome-inform7.spec, debian control/rule files, and the Makefile.am in the src directory.
Source Changes: Generally, there are no changes to the base gnome-inform7 6L38 code except for a minor workaround I put in for what appears to be a GTKFileFilter bug (3 lines).
Hi everyone, I have prepared an Ubuntu 16.04 deb package for 64bit systems. It is available at the same link as the original test packages. As before the deb was tested on a fresh install of ubuntu 16.04 64bit, installed via a double click on the package through the software center interface.
Sure, if you’d be willing to show me how to do it. The link you gave, by the way is blocked by Firefox – well not actually blocked, I suppose, but it blanks out the whole page and requires me to click on the “advanced” button and “accept the risk.” Something about not accepting the certificate. When I did proceed, I got a 404.
You might find this thread useful:it’s where I found out about the I7 flatpak.
Hi everyone, I have now completed testing on Fedora 30. The rpm is available at the same link as the original test packages. As before the rpm was tested on a fresh install of fedora 30 64bit, same install approach via software center by double clicking the rpm.
Hi Dizzydonut, i had an old link in my browser for the inform7 mantis tracker. Can you see if this opens up without having to “accept the risk”? http://inform7.com/mantis/my_view_page.php
To get into the specific tracker you have to choose from a list on the top right of the web page.
Hi @interactivefiction – your new link works okay. The issue of not being able to navigate to/open an old project is already there, as no. 0001985, although it didn’t mention specifically that this was a flatpak version. I’ll create an account and log the (Flatpak) preferences problem.
Thanks, @Dizzydonut. Indeed the file browser problem is not specific to the flatpak but I think the preferences problem is.
I think the issue with the bug tracker website is a https vs http link. For now I guess we have to access it insecurely. (Don’t put your credit card number in, I guess.) I noticed that there is a bug in the bug tracker open for fixing the https: http://inform7.com/mantis/view.php?id=2057
Since the confirmation email for the new bug tracker acct didn’t immediately show up in my email account (I did check the spam folder, too) I assume some human has to send it. Is that, in fact, the case?
Hi Dizzydonut, I did a quick test with the mantis tracker and created a new account. The confirmation email appears to be automated to me, it came immediately. One thing I did during registration was to click the “proceed” button that appears below where you input the initial registration information. Maybe that kicked the system to send the response, but I am not sure. This is what the email sender and subject should look like:
Still no activation message. I’ve gone back to the mantis site and gone through the “lost password” process in the hopes it would trigger an activation message, and although the Mantis site does actually say that a message has been sent, nothing is appearing in either my inbox or my trash folder. Now ten minutes and counting. Perhaps the webmail company mail.com is on some sort of blacklist.
Since I’ve had no luck creating my own account on the Mantis bug-tracker, would someone kindly repost this bug report for me?
I’m running Linux Mint 19.2 “Tina”, using the Mate desktop.
The Inform 7 IDE opens as it should and seems to run okay (It does tend to crash when compiling small projects, but I’m used to that.)
However at some point it seems to interfere with the display manager (I think.) What happens is that the taskbar ceases to be displayed, and there’s a gap (showing the desktop background) between the edge of the I7 window and the edge of the screen. The functionality of the taskbar remains: if I click on the area where the Menu button would be, then the Menu appears, and I’m able to select most programs and launch them as usual.
One that doesn’t work as usual is “Quit”. Clicking on the Quit entry usually launches a small central window with the options Log Out, Cancel, Shut Down etc, but this central window doesn’t open, and I have to wait until the auto countdown triggers shutdown.
This sounds like a possible GTK issue or a cumulative memory leak affecting things system wide (perhaps caused by the frequent compilation crashes you mention). I did not get the opportunity to test on Linux Mint only Ubuntu 16.04 / 18.04 and Fedora 29 / 30 using the Xorg display manager. In some testing I did observe that the gnome-inform7 compilation crashes were reduced significantly by launching the application from a commandline window. Is it possible you could try and launch the application (after a fresh reboot of the computer) from the commandline by typing gnome-inform7 at the command line prompt? This should launch the IDE and also leave a commandline window open that you will see various messages appear in. If you see a difference in behavior it would be great to know!
If there is interest I do have an ubuntu 19.10 build working as well as an early test version for Fedora 31; however, I could use some assistance testing them out from the community as there are further new workarounds required for these operating systems. Please let me know if you have any interest to help with testing.
Responding a lot later than I’d intended, sorry! I’ve been opening I7 via a terminal window, and it’s been pretty well behaved overall. There are a lot of warnings when it first opens, mostly saying that various extension files aren’t recognized. When it has crashed, it was always on recompiling, with the following message in the terminal window:
I’ve attached a zip of the full startup, in case any of the warnings are helpful.
The mysterious business of I7 interfering with the taskbar being drawn (and the shutdown window being displayed) continues, but I’ve not been able to see any pattern – except, of course the “when least convenient” pattern common to all bugs!
By the way, I7 is complaining that my extensions folder contains things it shouldn’t, e.g. " Locksmith.h - non-folder found where author folders should be" but since I don’t know where my extensions folder actually is I can’t open it to have a look-see. Where does it install to? I’ve checked /home/ and /usr/ but can’t find it.
I took a look at the crash log and one thing that jumped out immediately to me is the similarity of your issue with:
I was wondering if you could try the preference settings workaround advised in the above thread that claims it is possible to “miraculously” fix them ? For what it is worth, looking at other errors similar to this online I can see that there are others that have seen this behavior with GTK2. I will do some more digging on my side. Hopefully, the workaround in the thread above help on your side!
? For what it is worth, looking at other errors similar to this online I can see that there are others that have seen this behavior with GTK2. I will do some more digging on my side. Hopefully, the workaround in the thread above help on your side!