Skip to content

refine clipboard API, add API support for multiple clipboard data types#533

Open
ColleagueRiley wants to merge 35 commits into
ColleagueRiley:mainfrom
Hedgehogsoft:main
Open

refine clipboard API, add API support for multiple clipboard data types#533
ColleagueRiley wants to merge 35 commits into
ColleagueRiley:mainfrom
Hedgehogsoft:main

Conversation

@ColleagueRiley
Copy link
Copy Markdown
Owner

@ColleagueRiley ColleagueRiley commented May 19, 2026

No description provided.

@ColleagueRiley ColleagueRiley changed the title refine clipboard API, add API support for multiple clipboard data types (WIP) refine clipboard API, add API support for multiple clipboard data types May 28, 2026
CollinMcKinney
CollinMcKinney previously approved these changes May 29, 2026
Copy link
Copy Markdown

@CollinMcKinney CollinMcKinney left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should should cover any system I know of where a window library makes sense. Critically, it solves the issue with 32/64 bit ints. If there is a missing edge case it should be easy enough to add it in.

@ColleagueRiley
Copy link
Copy Markdown
Owner Author

Thanks, I don't need you to approve my changes

@CollinMcKinney
Copy link
Copy Markdown

CollinMcKinney commented May 29, 2026

Thanks, I don't need you to approve my changes

😂 You're welcome for providing the example "my changes", it's OK don't co-author it. Code thief.

@ColleagueRiley
Copy link
Copy Markdown
Owner Author

@CollinMcKinney As if your idea was so original. These were my changes that I wrote myself based on your suggestion of using limits.h, yes, but a suggestion doesn't give you ownership of my code. I highly doubt you are the one that originated that solution, but maybe you were considering how verbose it is. If you wanted to make a PR for that change, you were/are free to do so, instead you made a PR to fix a few (of the many) C89 incompatibilities.

Your issue has costed me far more wasted time than valuable code because of your unwillingness to have a proper conversation. Maybe other open source communities are willing to put up with this type of behavior, but RGFW is not a typical open source community.

If you want me to do a different fix because you wish to claim ownership over this one, I am more than willing to do that and if you wish to keep up this unproductive behavior, I do not want to see you in this community anymore.

@CollinMcKinney
Copy link
Copy Markdown

You are free to use this fix, I gave you permission to. But when we've been having a conversation for 3 days over this and then you point me to a PR, and I click "approve", there's no reason to be all snarky saying "thanks but I don't need you to approve MY CHANGES" as if you did this with zero input. The only reason I did a review and approved it was because you directed me to the PR in the first place, and I was looking to resolve this as being a nice middle ground. Just saying, a co-authored commit or just dropping my name in the contributors list would've been nice but IDC, you're free to use it regardless. Just don't sit here and be rude/dismissive to me while referring to them as "my changes" when this is clearly not the solution you would've come up with without me wasting my time trying to collaborate.

@ColleagueRiley ColleagueRiley dismissed CollinMcKinney’s stale review May 29, 2026 23:15

literally did not do a review

@ColleagueRiley
Copy link
Copy Markdown
Owner Author

You can interpret my messages however you want, I don't really care. I did not mean anything by "my changes" they are literally my changes I added, even if based on your suggestion. Which I did mention that it was your suggestion in the related issue.

So please feel free stop posting my repository before I block you, I do not want you here. Do not reply to this comment.

@ColleagueRiley
Copy link
Copy Markdown
Owner Author

Though feel free to open an issue if you find any real non-issue issues! :) 👍

@EimaKve
Copy link
Copy Markdown
Collaborator

EimaKve commented May 29, 2026

@CollinMcKinney Unless you have a patent on static assertions somehow, claiming ownership over something as general as “static asserting C int types” is very silly. Also, for someone who doesn’t seem to care about their code being supposedly stolen, it’s weird to demand that @ColleagueRiley should not be rude and not “while referring to them as his changes”. Evidently, you writing this comment out of thin air and your comments suggesting frustration with the collaboration itself contradicts your supposed nonchalant attitude.

@ColleagueRiley
Copy link
Copy Markdown
Owner Author

ColleagueRiley commented May 29, 2026

@EimaKve I don't know if he meant that part. The static assertion part wasn't even from him, I wrote that part 100% from scratch and it was based on stb more than anything. I guess I should give @EimaKve a credit for sending me the stb part and Sean credit for his code even though my version is quite different than how his looks.

His specific contribution comes from the use of checking limits.h to define types, which I doubt he has a patent on. I hope to hear from his lawyers shortly.

@CollinMcKinney
Copy link
Copy Markdown

You can interpret my messages however you want, I don't really care. I did not mean anything by "my changes" they are literally my changes I added, even if based on your suggestion. Which I did mention that it was your suggestion in the related issue.

My apologies if I misinterpreted what you wrote.

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.

3 participants