Take into account tags when generating images #1244
Conversation
| } | ||
|
|
||
| public void generateImages(String objectName, String property, String preferredExtension, ImageSpec[] spec) { | ||
| String[] tags = {null, FileReference.TAG_LIGHT, FileReference.TAG_DARK}; |
There was a problem hiding this comment.
This would be fine for now (covers light/dark tags), but if someone used a different tag it wouldn't get processed. I'm wondering if we should be a bit more flexible now. e.g. maybe we still pick up poorly-named files if it doesn't follow the spec, but if someone has logo.green-bg.png we would interpret green-bg as an unknown tag (maybe even unintentional) and process it to logo.green-bg.128x128.png etc.
There was a problem hiding this comment.
If you can come up with a nice way to do this, I'm all for it. As you said I think this is a good start at least.
There was a problem hiding this comment.
Claude came up with something that I think is nice, so I updated the code.
| } | ||
| if (found) { | ||
| list3.add(ref); | ||
| } else { |
There was a problem hiding this comment.
Two concerns here:
- looking at this change it only looks for the correct tag or else untagged images - but if you're looking for
lighttag and the only available image has a taggreen-bgwe would say there's no image. - the spec doesn't help things here, because we don't know whether an untagged image really is any better than another tag. I almost think we should understand tag-opposites here, i.e. if you're looking for
lighttag and there are none we would prioritize anything 'not dark' next, then anything else (which means dark tag...). 😆
The second is probably overkill, but I think we probably shouldn't cause the first. Maybe this means we still prefer untagged over any other tag 🤷🏼♂️ which may not be useful, but at least it wouldn't fail if another tag is found, or we'd fallback to dark if there was no light or untagged image.
There was a problem hiding this comment.
Two concerns here:
- looking at this change it only looks for the correct tag or else untagged images - but if you're looking for
lighttag and the only available image has a taggreen-bgwe would say there's no image.
Does it though? If there are no images without a tag, the list is empty and I don't use it but use the default list, so it would return that one, right?
- the spec doesn't help things here, because we don't know whether an untagged image really is any better than another tag. I almost think we should understand tag-opposites here, i.e. if you're looking for
lighttag and there are none we would prioritize anything 'not dark' next, then anything else (which means dark tag...). 😆
Yeah, the main issue I had is for NWERC I will have logo.svg and logo.dark.svg. No logo.light.svg since DOMjudge doesn't handle tags yet. Currently you will get logo.dark.svg when requesting the light tag if that logo is the first in the list. My change fixes that, but if you have a better way to do it, I'm up for it.
The second is probably overkill, but I think we probably shouldn't cause the first. Maybe this means we still prefer untagged over any other tag 🤷🏼♂️ which may not be useful, but at least it wouldn't fail if another tag is found, or we'd fallback to
darkif there was nolightor untagged image.
deboer-tim
left a comment
There was a problem hiding this comment.
I'm good with the changes in ImagesGenerator. We may still need tweaks, but I agree that's generally a big step in the right direction.
I tested with the ContestObject changes, and I was able to reproduce the problem I expected where if all images are tagged we can fail to pick, or pick the 'opposite' tag over another option.
It's arguable whether this is a 'problem', but if you ask w/o specifying a tag we may also pick the 'dark' or 'light' instead of untagged, depending on what order the file refs are in.
So: feel free to merge just the IG or both, I'll have a PR ready to go that will improve these two issues in getBestFileReference.
Side note: I think the last issue highlights the fact that CDS and CCSs should probably sort file refs to help out 'dumb'/old clients, even if that's not required by spec.
I wonder what exact cases you are hitting, since I thought my code would always return an image if there is at least one. It might indeed be that, if all images are tagged, it will return one with the opposite tag, which might be wrong. But when does it return no image at all?
I'll merge and await your update.
I agree. |
Yeah, you were right: I had misunderstood the fallback and started changing code before I had the issue. The cases you fixed are working and no regression, and I've opened #1246 for some additional refinement and issues I saw. |
This also fixes an issue when requesting an image with tag
x: it could return an image without tagxbut with tagy, even if there is also an image without any tags. Now we first check if we have any images without any tag and return that.