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!
Unfortunately in this version of the IDE, the File Edit View etc. menus don’t open, so I can’t tinker with the styles etc. I do use the text search quite often, because I’ve read the docs so often that I know something can be done, but often only that it’s in the example with the “starry void,” or something. It’ll be annoying if that’s what’s causing the crashes, but hey.
As for the crashes occurring because the code has no errors – that can’t be my problem!
Ok, so none of the normal menu items work. A big hassle. I may try making a Linux Mint build specifically. You are on Linux Mint 19.2 currently? I am curious if, at least, your menus would work correctly if the build was made on the specific OS you are using. I do think the code may have errors; however, gtk2 is an older API so I would expect this type of issue is more likely to get resolved during migration to gtk3 (something I believe ptomato is working on based on a quick glance at the branches in the gnome-inform7 git repo).
Linux Mint 19.2 “Tina” yes. They worked on the previous version though. (6L38) Of course I’d be delighted if you’d consider making such a build, but not if it’s going to be a huge amount of work. Expert volunteer hours are precious.
Very interesting so 6L38 worked before but 6M62 has a problem with the menus. That helps narrow things down quite a bit. Spinning up a VM for Linux Mint is not a big effort nor is making the build itself. That said, the fact that it worked for 6L38 tells me there is a change to the code that introduced this behavior. I may be able to see what that difference is by comparing the code for 6L38 to 6M62. Rather than building a 6M62 specifically for Linux Mint, let me put some effort into seeing what may have changed between the two builds. I will keep you updated!
Personally I have not tested on Debian, only Ubuntu and Fedora. Generally x86_64 versus amd64 are different names for the same thing. So assuming the proper library versions are available on your distro, it should work in theory
Great info! The ni used in the debs is actually a precompiled binary I obtained from the official Inform7 website. It appears it is statically linked agains a different kernel than you are on. Do you have a link to the ni you are using or a deb package that contains it? Also, may I ask a few questions:
Is the user interface for gnome-inform7 opening up for you?
Is the segfault encountered only when you attempt to compile?
yes, only issue is that crashes when I run a glulx build without fully closing the precedent run (I’m not sure to have explained well…)
Next time, I look into the 'terp, eventually changing also that binary.
damn well, YES ! solved putting that 2018 ni binary.
dunno I know now. so many install/disinstall/mucking around, I fear is a sort of mishmash of various flavour of 6M62 (and no, I don’t want to attempt a full cleaning & reinstalling, too many brittle things around, IMVHO.
Now I must get ready for a political meeting (Italian politics… still “keep your dagger ready and watch your six” grade, trust me), so I’ll reply either late in night (CET) or tomorrow.
Nice work! It sounds like you have some improvement on your issue by replacing the ni. If it is possible, can you point me to the location of the ni binary you are using? I would like to download it for myself and when I have time package a gnome-inform7 Debian 10 build using that ni binary. It would be nice if other authors do not have to manually replace the ni in the future.
I suggest navigating in the archives inside with a file & archive manager (I use mc, because, well, for me CLI interface and keyboard is much faster than mouse) and extract that ni from the relevant sub-archive.
HTH and
Best regards from Italy,
dott. Piergiorgio.
Thanks Piergiorgio! I did a quick check and the ni in both debs I posted for Ubuntu 16.04 and 18.04 is quite old. I pulled the tar and compared against the x86_64 ni and found the 2018 version your debug info referenced. It looks like this may be a requirement for Debian 10. Appreciate your help digging into the details. I will attempt to build a new package that includes the updated ni specifically for Debian 10 when I get some free time.