Adding macOS support

[pgilfernandez]

As previously talked in #70, I'm happy to announce experimental support for macOS.

The work is 95% AI generated with me working as prompter and tester... I've spended lots of hours in these tasks so, apart from the great (?) assistance of AIs it hasn't been trivial and needed lot of human work as macOS is particular in lots of ways.

Anyway, the code could include unnecessary functions and there may be a lot of twists and turns along the way... it works but I'm sure it can be heavily tweaked and improved.

This PR is then the first public try to add macOS support, I hope you like it overall.

If you want to test the build follow this link https://github.com/pgilfernandez/rayforge/releases/tag/1.0.2

The following next "big thing" that should be done is to correctly setup the GitHub workflows or CIs to automate the test and release builds within GitHub... in this regard I need help as the first tests didn't go well and I have the feeling that the IA help is not very accurate here yet...

Cheers

[knipknap]

Wow, awesome job getting to this point!

Now as for integration I am really struggling on how to do this. In its current state the tests do not pass, and I feel it is so large that I have difficulty reviewing it in any safe way, and some parts I do not understand why they would be needed for compatibility.

There are a few places that need work, e.g. the changes in workpiece.py seem like patching over symptoms, and I do not understand the changes in the importers/renderers at all - and those are places that I would consider somewhat fragile so require extra really good understanding before I would touch them.

This part for example:

            # Prefer CairoSVG because bundled libvips may lack SVG support on
            # macOS. Fall back to svgload_buffer if available.

Will break for large raster images due to Cairo's 32k pixel bitmap size limit.
And this part should be responsibility of the task manager:

        if use_thread:
            task = self._task_manager.run_thread_with_proxy(
                make_job_artifact_in_subprocess,
                self._artifact_manager._store,
                job_description_dict=job_desc.__dict__,
                creator_tag="job",
                key=JobKey,
                when_done=when_done_callback,
                when_event=self._on_job_task_event,
                adoption_event=self._adoption_event,
            )
        else:
            task = self._task_manager.run_process(
                make_job_artifact_in_subprocess,
                self._artifact_manager._store,
                job_description_dict=job_desc.__dict__,
                creator_tag="job",
                key=JobKey,
                when_done=when_done_callback,
                when_event=self._on_job_task_event,
                adoption_event=self._adoption_event,
            )

The pipeline should really not have any platform-specific code, as it is already hard to maintain as it is.

Another major issue is that the code essentially reverts large changes that are in main. The PR currently reverts the workpiece element to a state where it uses Ops directly, adding a whopping 700 lines of code that really should not be there.

I have been wrestling trying to come up with a merge strategy. Perhaps one option is to start by some smaller PRs. Some parts that look like obvious "easy to merge" changes:

1. A PR for rayforge/ui_gtk/shared/keyboard.py and adjusting the all code to use it.
2. Second PR that make only the changes on the geo module. I am slightly worried about those, because some of that code is performance sensitive so I definitely want to test those changes in isolation and probably also extend the unit tests accordingly.
3. The GL related changes.
4. Adding the build infrastructure
5. ...

Similarly, app.py is definitely "danger territory". This would ideally have to be changed in a way to not touch existing code paths, because this is extremely finicky to keep working on all platforms and I have really struggled with it in the past.

Now there are a lot of good parts - the build scripts seem well integrated and I like that it auto-generates the icon, too. And just looking at the shear breadth of fixes included I can imagine this took tons of time to figure out. I hope we can get it resolved and merge it in an iterative way.

[pgilfernandez]

Indeed! in the way sometimes I felt like the AI was not fixing but creating a new whole way of doing thing... but as I said y preferred to go ahead and see where I could reach...
Without any doubt, there is work ahead, as I said I expected the code changes weren't going to be so smart and perfect... but it's definitely a start point 😅

Now as for integration I am really struggling on how to do this. In its current state the tests do not pass, and I feel it is so large that I have difficulty reviewing it in any safe way, and some parts I do not understand why they would be needed for compatibility.

There are a few places that need work, e.g. the changes in workpiece.py seem like patching over symptoms, and I do not understand the changes in the importers/renderers at all - and those are places that I would consider somewhat fragile so require extra really good understanding before I would touch them.

...

As it was pretty hard to go ahead and get it all working (packaging, dependencies, macOS special needs...) I would suggest to start "cleaning" it backwards, that is, choose chunks of code that doesn't fit or that you think are not needed, try to in short explain it so that I can feed the prompt and I work on it (with the AI) to make it work at the right way, what do you think?

Now there are a lot of good parts - the build scripts seem well integrated and I like that it auto-generates the icon, too. And just looking at the shear breadth of fixes included I can imagine this took tons of time to figure out. I hope we can get it resolved and merge it in an iterative way.

This is part of the manual work I did, hehehe, but will probably need some work and clean up when we start "fixing things"

Would you mind then doing it this way? you could start with the first thing to be fixed (choose an easy one) and we see if our shared workflow works and we can go deeper. 💪🏻