Support Windows (and OS X)

[shervinemami]

I tried porting BeamGrid to Windows, with a few minor changes I was able to render the grids on Windows but found a fundamental problem: "fixed-width fonts" don't render all symbols with equal width! They only render the more common symbols with a fixed width but then they use other widths for some of the more uncommon symbols, including many of the symbols that BeamGrid uses! I spent 2 hours trying to find symbols that will render with the same width in Windows, but couldn't find enough symbols. I also tried it with a number of different TTF font files that support both Linux and Windows but couldn't find anything decent.

In other words, BeamGrid on Linux splits the screen up into roughly 100 different cells because it can render that many different fixed width symbols, but on Windows I only found about half of that number of fixed width symbols.

So to port BeamGrid to Windows (and I assume Mac is similar), there are 2 options:

• Easy Option: Simply stick with the limited number of symbols that are working well on both Linux & Windows. I've already put comments in the symbolmap.py file in BeamGrid to show which ones should be disabled in Windows. This would mean BeamGrid could be ported to Windows and Caster and Mac with minimal effort, but Windows won't be able to split the screen into as many cells as Linux can. I haven't tested on Mac, or different versions of Windows and Linux, so maybe with more rigorous testing we'd find even more symbols that don't render the same on all machines, meaning that we slowly reduce the number of cells that BeamGrid can show.
• Medium option: Add some ugly hacks to BeamGrid so that for symbols that render to non-uniform widths in different OSes, we manually adjust where we render the symbol. I did a quick try of this and it should be fine, it just slows down rendering slightly in some cases because it must render each symbol separately instead of as a group.
• Hard option: instead of asking TK to render our text, we render text manually. ie: we save bitmaps of every symbol at every font size we want to support, and then we paste the bitmap of each symbol at the location we want. This actually allows much more symbols in the future, because we wouldn't be tied to existing Unicode font symbols anymore, we can draw any symbols we want! So we could have 200 symbols instead of roughly 100, allowing an even finer control of the mouse. It would also be fully identical view on all OSes and versions, since we wouldn't be dependent on how the OS renders rare Unicode symbols.

[LexiconCode]

I am curious to know what makes the third option difficult? I suppose that's the time involved creating the bitmaps of every symbol at every font size we want to support?

The third option is attractive for a number of reasons.

• Transitioning to a different framework from TK we won't have new bugs related to rendering text.
• Uniformity across all platforms
• Flexibility for Fine-grained mouse control

[shervinemami]

Yeah I agree, the 3rd option is the most appealing, especially long-term. The only difficulty is the software development, and maybe it's not too hard.
The speed issue I mentioned is also not a huge problem, because I designed BeamGrid to only render the grids on rare occasions (application startup and each time it changes modes), and by keeping the window hidden in the background except when suddenly needed, it doesn't need to render the text before displaying it each time the user says "beam", it only needs to make the window visible and in the foreground. That's why it has reasonable latency even though it's written in Python.
So yeah, I think the 3rd option is the best path for it to be used on Windows & Mac.

[shervinemami]

Adding link "https://eli.thegreenplace.net/2012/01/30/the-bytesstr-dichotomy-in-python-3" for when this feature does get implemented using Python 3