fix(schemas/yazi.json): set minimum of 3 for offset height#47
fix(schemas/yazi.json): set minimum of 3 for offset height#47
Conversation
|
overriding it worked fine for me when testing i'm against using if you still prefer to not override it i would suggest doing |
Did you test it when using the i16/u16 definitions? In #45 you didn't use u16 at all, I can't get the current state on the main branch to invalidate a value of |
Yeah I'm not too sure what's going on with it, there's some casting of values to u16 and I mean the default value for the offset width is u16 max. cc @sxyazi |
oops i missed that, also now that i look at it i used this is what i would recommend now:
|
|
That's what this is with the exception that 3 and 4 don't have an upper bound. |
|
Yes, it's a bit inconsistent here. I did a blame and found that the initial implementation used a I think at that time I wasn't know that However, I plan to refactor these properties from arrays to dictionaries, for example: - trash_offset = [ 0, 0, 70, 20 ]
+ trash_offset = { x = 0, y = 0, width = 70, height = 20 }to provide better readability, and to support default values so that - trash_offset = { x = 0, y = 0, width = 70, height = 20 }
+ trash_offset = { width = 70, height = 20 }Maybe we could hold off on this until then to avoid rework? WDYT? |
Sure that sounds good! I like the dictionary idea, much better with those benefits you mention and easier for us over here ahah. |

@AminurAlam I think we can't use a reference to a type and override fields like min/max from that type at the same time. I've removed the minimum of 0 on the 3rd item in the offset since that is the default for u16, and then for the fourth item / offset height I switched off using u16 entirely and just manually set the max to the u16 max value. This now appears to properly fail if the height offset is below 3.