Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experimenting with Linux support. #524

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

cfcohen
Copy link

@cfcohen cfcohen commented Mar 25, 2021

Commits related to the Linux Mono port of Trizbort. I'll try to keep the individual commits small so that they'll be easier to review.

cfcohen and others added 10 commits March 24, 2021 21:06
The calls to write Enhanced Metafiles depends on gdi32.dll, which I
expect is not available in the Linux Mono.

This is really a test of whether the conditional Linux runtime
detection is working correctly, and whether my branch is configured
correctly.
This call causes disruptive exceptions when double clicking on a room.
It's not immediately obvious to me what this does.  It appears to be
related to what I would call tooltips, which are not currently being
displayed in Linux when hovering over a room.

Perhaps in the future this should be replaced with something else.
For now my goal is to suppress annoying behavior wher Trizbort prompts
the user to save the file everytime the room dialog is opened.
Presumably because an exception occurred?
These widgets crash the Linux Mono version.  I thought that there
might be a more portable way to handle at least querying the status of
the CapsLock, NumLock, and ScrollLock Keys, but it turns out that the
API just isn't implemented in Mono yet.  See:

https://github.com/mono/mono/blob/main/mcs/class/System.Windows.Forms/System.Windows.Forms/Control.cs#L3487

Fortunately the Trizbort feature isn't terribly important, and the
goal for users on other platforms would be to avoid crashes by
accidentally clicking on the widgets, which is what this commit
accomplishes by removing the widgets from the status bar entirely.
I'm not 100% confident that I really understand the problem here, but
I tracked it back to this call to DrawImage, and the exception seems
to indicate that there was a "busy" problem presumably related to Mono
using System.Drawing to render the Windows forms.

On a whim, I wondered if an XImage would behave differently, and it
did.  No crash, and the icons seem to be drawn correctly.  Perhaps
there's a better fix than this for the issue, but this gets it working
at least.  If someone else can find a better fix or further explain
this one, that feedback would be welcome.
This change should not be committed permanently, because it's actually
much _worse_ on Linux than the code currently on master, but I'm
curious to know if it works in Windows.  It should look very much like
the original behavior and should not require the Windows specific
Wingdings font.
This commit also displays _very_ poorly in Mono on Linux, but I've
included it to ensure that the problem in the previous commit is not
related to the encoding of the source code file.  For me, both commits
produce essentially identical results (correct on console, nothing on
the check boxes inside the application).
This commit is an improvement on Linux if you don't have the Wingdings
font (which is provavly all Linux users by default).  Without the
Wingdings font, you get random characters that don't communicate the
purpose of the checkbox widgets at all.  With this commit, the north,
south, east and west arrows render reasonably and the other five
characters render as "missing character squares" which in my opinion
makes it a little more obvious what was intended.

Unfortunately, despite being only a few characters away from each
other in unicode, on my system the cardinal directions are "normal
width" unicode characters rendered at with a lighter weight, while the
five missing characters are extra wide, and substantially heavier in
their rendering.  So they're definitely not "harmonious".

If it works (and looks good) in Windows, I think this solution should
be considered temporarily since it's an improvement on Linux, and it
might get fixed before the commits #1 or #2, which is what should
really be done long term. If this doesn't look good on Windows, we
should revert to the original source code, and advise non-Windows
users to somehow obtain and install the Wingdings font.
Since this the only solution that actually works completely, and I've
found a copy of Wingdings from a VM, I'm reverting the Linux branch to
this configuration.
This catch clause was why text was mysteriously missing without there
being any errors.  Unfortunately, with it disabled, simply creating a
room causes Trizbort to crash.  Perhaps there's a good reason for this
catch on Windows, but at least for testing Mono on Linux, it should
probably be disabled.  It might also be a good idea to report that
something went wrong in the future, but for now I'd like actual
exceptions if possible.
So this commit shows where the problems revealed by the previous
commit really are.  It's apparently all about graphics.MeasureString
and graphics.DrawString.  There are some other places in the code that
use these same methods, and they probably crash too, but I haven't
attempted to disable them because they don't interfere with adding
rooms or common functionality.

I was surprised to learn that the problem can be triggered by
converting the Font to a XFont.  Perhaps the MeasureString and
DrawString calls would actually work if there was a valid XFont?

This commit makes it clearer to me why PDFSharp is fundamentally part
of the problem, and why a correct Mono port might need to drop support
for PDFSharp entirely.  The traceback generated by the initialXFont
line is mentionded first in 2017, and appears to part of a long
running thread about PDFSharp:

empira/PDFsharp#9 in 2017
empira/PDFsharp#66 in 2018
https://github.com/empira/PDFsharp/issues/136
@cfcohen cfcohen changed the title Disable EMF exports on Linux. Experimenting with Linux support. Mar 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant