search

sharplispers / clx

a fork of crhodes' fork of danb's fork of the CLX library, an X11 client for Common Lisp
Other
114 stars 46 forks source link

Cherry Pick Macro fixes from `randr-improvements` branch #204

Open einsiedlerspiel opened 9 months ago

einsiedlerspiel commented 9 months ago

This PR cherry picks the changes @scymtym's randr-improvements branch makes to clx macros. The original commits are 63ee5bbc59c1ea74ac78e6226f2369ed019e0daa and cf46691.

I'm looking to separate the fixed up randr extension into it's own asdf-system so it can be used with quicklisp versions of clx. This is mostly unproblematic because its changes are mostly in a separate name space already, but it does depend on these fixes to clx's macros. Merging them into master would be helpful.

This would also be a good first step to porting the fixes from that branch to master in a non-breaking manner.

The caveat is that I don't know how this affects other parts of clx and whether the changes were relevant to the down stream breakage the branch caused (#197) , though i don't think it's likely. Maybe @scymtym can help with that.

scymtym commented 9 months ago

I would prefer to finish the changes in their original form instead of in the form of a separate, temporary ASDF system that would provide a similar but slightly different interface compared to the "legacy" interface that would remain in clx proper.

The reason for holding off with the randr-improvements branch was that it could break existing code such as stumpwm. My preferred solution would to be to coordinate with e.g. stumpwm to ensure that they wouldn't mind the interface change.

einsiedlerspiel commented 9 months ago

Yeah having multiple versions of the API around wouldn't be optimal for an eventual consolidation.

I'm not particularly familiar with the StumpWM code base but just did a quick search and it seems they have just like three calls to rr-functions in total. If that's really all it would be fairly trivial to provide them a patch, (that's assuming they don't do anything on their end to fix up buggy return values).

Are there any other big project's you'd want to consider? I don't suspect many projects depend on the randr extension in it's current state. I'm kinda surprised stumpwm uses rr-get-output-info, judging by the commit history they've been using the name value for longer than that has been patched to return legible output.