FYI I'd be willing to workshop this into a mergable form, just want to avoid doing a bunch of work in the wrong direction.

I think the build changes should mostly be no-brainers. But the GTK changes require more work. I do think it's important to get rid of GTK since it's a huge dependency that is very hard to bundle in a lot of systems, and scopehal doesn't really need it for much.

• Removing color was easy, but a bit more work is needed to turn the color strings back into colors at the other end. Pretty mechanical change.
• Graph.cpp is a bit more tricky, and would have to be refactored to live somewhere else, which I'd need your input on.
• Changing the includes has unexpected knock-on effects on scopeprotocols because it includes scopehal.h and then expects GTK to exist, another tedious but mechanical change.

Support for 32-bit systems is not currently on my radar, because my typical use cases for glscopeclient and libscopehal involve large amounts of data (several GB) and pretty much all platforms with enough compute power to do a reasonable amount of waveform analysis are 64-bit.

My target platforms for the near term are x86-64 Linux/Windows and ARM64 Linux, with BSD and OSX as wishlist items but I'm not willing to spend significant effort on supporting them.

The graph widget is actually a separate repo already (https://github.com/azonenberg/graphwidget) so perhaps would make sense to pull in under glscopeclient rather than scopehal. I don't think anything currently located in scopehal depends on it.

I do agree that this is an important change to make in the long term, because any kind of headless instrumentation application - or integration into vendor scope software - will not be using the GTK UI or OpenGL UI. Being able to use scopehal and scopeprotocols for both offline analysis applications and headless data streaming for ATE are very much on my wishlist; glscopeclient is simply the flagship application for the libraries.

Well the good news is with my changes, it does build on BSD and OSX, as well as 32bit systems, and using older versions of gcc/glibc.

Scopeprotocols will be A LOT harder to make GTK-free because it takes a drawing context in pretty much every function. This PR only deals with scopehal itself.

Yea nothing broke after removing graphwidget. Moving that to glscopeclient seems like a good idea. For me, the problem is not so much doing it, but figuring out how to submit the pull requests in the right order to fix the git submodules. So if you have time to do the submodule shuffling that would be great.

If the other points look good to you, once the graphwidget is taken care of I can start work on making glscopeclient and scopeprotocols work with this PR and properly implement the aligned_alloc mess. (can we use C++17 std::aligned_alloc?)

@pepijndevos Any update on that PR ? (it seems abandoned/unfinished since more than 1 year now ?)

Yeah it's basically unfinished. I was trying to build scopehal as a standalone library, which seems to be discouraged until the API is stable. @azonenberg seemed not very interested in supporting more platforms, and I simply did not complete the gtk decoupling on the glscopeclient side.

So I think this PR as well as the other was basically parked until scopehal API's stabilize.

Closing this because so many things have changed since then. The long term plan is and continues to be a full decoupling of GTK from scopehal as we move towards ngscopeclient becoming the primary UI, but it will likely be slow and piecewise.