Request: Linux Support

[dstelzer]

I used to rely on Trizbort extensively, but after switching to Linux I haven't been able to use it any more (because it crashes in WINE). A Mono version would be much appreciated.

[JasonLautzenheiser]

I know...I think I know why it's crashing in WINE from previous conversations, but it would force me to unwire some stuff that I'm not looking forward to unwiring and finding a suitable replacement for.

But I really need to buckle down and look deeper into it. I know you're not the only one that would benefit from this.

[ghost]

Would it be possible to get a mono-compatible version? I can live without PDF, command-line and other 3rd-party DLLs, at least basic functionality (as now it crash in mono when try to get properties of an object).

[JasonLautzenheiser]

@adlogic That may be a possibility, trying to do a slimmed down version. I'll try to find time to take a look a closer look at that (unless anyone else wants to take a stab at it)

[ghost]

Linux users still have interest in slimmed down version.

[Screwtapello]

I've been playing with Trizbort 1.7.2 on Debian Testing recently, and with Wine 4.0 and Wine-Mono 4.5, it seems to work pretty well. I haven't tried exporting, or automapping, but for the basic task of creating rooms, linking them together, and scrolling around the map it works fine.

Two odd things I've noticed:

• When I select a bunch of rooms and then choose "Change Region" from the Rooms menu (or press Shift+F2) nothing happens. Bulk-region-changing from the context menu works fine, though.
• Whenever I save, Trizbort immediately says "Some other application has modified the map, do you want to reload?" If I say "no", nothing happens, if I say "yes" it zooms out to fit the entire map, but otherwise seems unchanged.

[ghost]

@Screwtapello in native mono it crashes for me when I try to edit a room and it does not show proper data (all the squares are blank instead of having text).

If run under wine - all the buttons are inverted (mouse wheel, cursor keys - you press right and it does scroll left, you scroll inside - and it zooms out).

So again I vote for slimmed down version which could be run natively under linux mono (not under wine, which is not a native app, but full scale windows interpreter).

[github-actions[bot]]

Stale issue message

[spamegg1]

@adlogic I have exactly the same experience on Ubuntu with Mono. Haven't tried Wine.

It's that time of the year: Interactive Fiction Competition and right now I'm relying on IFMapper and it's working fine. The installation was a bit of a pain, but it has basic functionality and automapping also works. (The window looks weird but it's not emulated, it's a Ruby gem so it has old Windows style GUI)

I would love to work on a Linux version of Trizbort but I've never coded in C# before. It would take a long time and require a ton of hand holding.

[cfcohen]

So I recently built Trizbort with the Linux Mono under Ubuntu 20.10, using the Ubuntu 20.04 version of Mono from here. This version of Mono provided a more current version (2.12) of nuget, which was required to install the required packages. Since the procedure was not immediately obvious to me, and I couldn't find any Linux centric instructions here's what I did:

$ git clone https://github.com/JasonLautzenheiser/trizbort Trizbort
$ cd Trizbort
$ mkdir packages
$ cd packages
$ nuget install CommandLineParser -Version 2.6.0
$ nuget install Newtonsoft.Json -Version 12.0.2
$ nuget install PDFsharp-gdi -Version 1.50.5147
$ nuget install NUnit -Version 3.12
$ nuget install NUnit3TestAdapter -Version 3.17.0
$ cd ..
$ msbuild
$ cp obj/x86/Debug/Trizbort.exe bin/Debug/Trizbort.exe
$ chmod 755 ./bin/Debug/Trizbort.exe
$ ./bin/Debug/Trizbort.exe

This procedure produced only one error for me:

error MSB3030: Could not copy the file "obj/x86/Debug/Trizbort.exe.manifest" because it was not found.

Which I presume is why I had to copy around the Trizbort.exe and change the permissions. The executable is fairly functional but has some definite problems. For example, double-clicking on a room produced the following traceback:

System.EntryPointNotFoundException: SendMessage assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) Trizbort.UI.Controls.TrizbortTextBox.SendMessage(intptr,int,intptr,string)
  at Trizbort.UI.Controls.TrizbortTextBox.updateCue () [0x0002b] in <dd1e80e13d5641739252688faded2c42>:0
  ...

Which appears to be related to using USER32.DLL to "SendMessage(this, EM_SETCUEBANNER, 1, 1)". Commenting out that line (since I don't have user32.dll) seems to have prevented the traceback from occurring. As with the Wine version, the most significant problem is that all text is missing in the main map window, which is a pretty serious problem. I suspect that perhaps I'm lacking the Arial font, although I wouldn't have expected an exception to have been thrown. I've also crashed Trizbort several times, whereas it's much more reliable under Windows.

The point of my posting a message to this issue is to raise the question... If it's this close to working, are you willing to help with some of the fixes if I do the testing and identify the bits that are still causing the problems? I hope so because I hate running a Windows VM just to get Trizbort. :-)

[cfcohen]

Following up on my previous comment, Trizbort appears to rely on gdi32.dll:CopyEnhMetaFile(), gdi32.dll:DeleteEnhMetaFile() in UI/Mainform.cs. This is probably a case where Windows Enhanced MetaFile (EMF) support should be conditionally disabled when building on Linux.

Additionally Util/KeyboardHelper.cs, relies on user32.dll:keybd_event(), and user32.dll:GetKeyState(). It looks like this link might provide an alternative to the keybd_event() and GetKeyState() code, since it seems to mostly be related to detecting CapsLock, NumLock, and ScrollLock.

Those appear to be the only DllImports, so I think that would mark the end of that class of Linux porting problem.

Having little experience with Windows programming makes me very reluctant to even try changing the keyboard stuff for fear that I would break the primary platform, but if you could confirm that the new Control.IsKeyLocked() method worked for you, I bet it would on Linux as well, and I could test it. I can try conditionally disabling EMF support on my end and perhaps submit a pull request.

[JasonLautzenheiser]

Thanks for all the work you've put into this I'd be willing to help where I can with this as I'd love to see a linux version out there. My time to work on this is a bit limited this time of year, but I can help where I can.

Thanks

[cfcohen]

Great. I'll start fixing what I can and submit some pull requests for your consideration. You'll probably need to review them carefully since I'm not really that familiar with C# and Trizbort internals, but I'm confident we'll figure it out. I've started a fork here for anyone interested in following the progress, testing, commenting, etc.

[cfcohen]

So this has been pretty frustrating. I had originally expected a lot of failures kind of like the "no Wingdings font problem". In other words, the software was originally written with only Windows in mind, and someone needed to conduct a careful review of all of the places that used Windows-only features and decide what the right cross-platform thing to do was. A few of the early bugs supported that view (e.g. disabling EMF image exports conditionally under Linux).

Instead, it's turned into a giant learning exercise for me in discovering that many things that purportedly work in Mono just don't, and that apparently practically all software in C# has roughly the same level of cross-platform support as Trizbort does. Aka it kind-of works sometimes. :-( It seems that Unicode support is still seriously borked in Mono in general, that PDFsharp still calls Windows API in some places despite there being a Nuget package that will fetch and install it under Linux, and even Windows.Forms in Mono has non-trivial features that are just not implemented. I can't background Mono tasks in general under Linux, my entire desktop periodically hangs when running Mono applications, there are occasionally seriously wrong widget layout problems in the dialog boxes, and I sometimes have window redraw problems in my window manager.

I guess I was just naive about the state of cross-platform development in C#. This is more or less my first experience with C# and Mono, and it's turned into something that I no longer feel productive doing. Perhaps I'll return to this after I've had some time to calm down. In the meantime, I'm hopeful that my fork and the list of issues found in the port will allow the next person willing to undertake this task to start from a position of better clarity than I did.

Jason, if you want to close the pull request, that's fine although there was some progress on some minor issues. I might also be encouraged to try again, if any of my work has given you clarity about what the real problem is, or if you could suggest how PDFSharp could be removed more easily than I can currently envision.