-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename group attribute for non GLenum parameters not corresponding to any enum group #534
Rename group attribute for non GLenum parameters not corresponding to any enum group #534
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs to be added to registry.rnc. Otherwise looks good.
The changes are definitely better than keeping it as is. (no more) Long term (probably other PR's)
Completed
Non-kind_attribute changes(this is all good, noting here just to keep track) |
Also needs to be added to xml/readme.tex, the schema description document. |
It appears this isn't ready yet for approval. Let me know if you think otherwise. |
I've fixed the The functions all take special values such as buffer addresses or bindless texture handles. |
Co-authored-by: Sun Serega <[email protected]>
Is there anything more to do or should I make this ready for review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think it's ready.
@Perksey would you like to give this another review? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty happy with these changes, I think the final form of these attributes makes sense given these are meant to be a "hint" and not gospel for what a parameter value represents - it's a good balance.
There are a few things worth double checking (and they may already have been discussed, so apologies if so!) but these needn't block merging, I'm happy with this is as is.
@@ -9072,29 +9110,29 @@ typedef unsigned int GLhandleARB; | |||
<proto>void <name>glColorTableParameterfv</name></proto> | |||
<param group="ColorTableTarget"><ptype>GLenum</ptype> <name>target</name></param> | |||
<param group="ColorTableParameterPName"><ptype>GLenum</ptype> <name>pname</name></param> | |||
<param group="CheckedFloat32" len="COMPSIZE(pname)">const <ptype>GLfloat</ptype> *<name>params</name></param> | |||
<param kind="CheckedFloat32" len="COMPSIZE(pname)">const <ptype>GLfloat</ptype> *<name>params</name></param> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kind hasn't been declared at this top of the file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of CheckedFloat32
and CheckedInt32
kinds will need to be turned into Clamped[*]
, some may be more complex.
I proposed to leave them undocumented to say they are unsupported, while not deleting existing info from XML.
Similar in the case of Path
and FenceNV
kinds - but they need to turn into their respective class
attribute.
Look at the "Long term (probably other PR's)" section of my first review.
@@ -9072,29 +9110,29 @@ typedef unsigned int GLhandleARB; | |||
<proto>void <name>glColorTableParameterfv</name></proto> | |||
<param group="ColorTableTarget"><ptype>GLenum</ptype> <name>target</name></param> | |||
<param group="ColorTableParameterPName"><ptype>GLenum</ptype> <name>pname</name></param> | |||
<param group="CheckedFloat32" len="COMPSIZE(pname)">const <ptype>GLfloat</ptype> *<name>params</name></param> | |||
<param kind="CheckedFloat32" len="COMPSIZE(pname)">const <ptype>GLfloat</ptype> *<name>params</name></param> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine either way, but wanted to point it out anyway: it seems the precedent set elsewhere in your changes remove type information from the kind names (e.g. Coord
instead of CoordF
) which makes sense given you can get this from the ptype
. Is there any reason why this isn't done with this kind? (i.e. should this just be Checked
?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CheckedFloat32
is a name that comes from the old groups and I've probably not looked at what kind this particular parameter should have.
I can do a pass over them to see if any of them are easily changed or removed, but otherwise I think we can fix them in future PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a working branch where I have already done the changes to remove all of the CheckedInt32
and CheckedFloat32
kinds, and removed them or replaced them with the appropriate replacement.
https://github.com/NogginBops/OpenGL-Registry/tree/more-kind-changes
I just realized I need to remove the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from the note on restricting kind annotations to not contain the ',' separator, I'll need to run this through the schema validator and ensure the generated headers aren't affected before merging, but it seems fine.
Should the |
I think it's fine as is, as to me it reads as "the parameter is of a kind that is a color and is clamped to a specific range" i.e. they're describing the properties of the kind, they are not kinds themselves. |
@NogginBops could you resolve the merge conflicts? I assume otherwise this is ready to go in? Thanks. |
@oddhack did you get a chance to run this through the schema validator? |
@oddhack, this is approved to merge as soon as the merge conflicts are resolved and you're happy with it. |
…ename-groups-that-are-not-enums
Fixed merge conflicts. |
Fixes #517
I've used the word
kind
here to indicate that the label indicates the kind if value the parameter is (egClampedFloat32
orCoordF
).I was thinking about other words to use such as "attrib", "category", "variety", "set" or "label", but personally it seemed like "kind" was the best, most descriptive name.
@Perksey @SunSerega comments?