optimo
commented
2 weeks ago I don't believe that's right. I have been able to place Images and have them resize generally speaking - depending on their parent container size and layout rules which might be limiting you in your experience.
ImageButton, by default, has it's image's Scaling set to Scaling.Fit. just above lines 116 of Image.cs you can see the the scaling is applied on every layout; you may have been changing the size values, but there in Apply it would follow the rules for Fit where scale is calculated and new sizes returned. Whether that's exactly the hurdle you're up against, it's likely that or related to that.
for a general Image element, the scaling policy and size of the element would determine how large the image would get drawn (if it's parent table/group allows).
So what's a fix? well you could take the code from ImageButton class and make your own, or try subclassing it. but in doing that your own way you can decide another Scaling policy or do the math however you like. Maybe you set it to Scaling.Stretch (this is a default value for the enum, so you could also just not set scaling at all), and see if resizing the button also resizes the child image element. Subclassing or building your own elements for your UI needs is totally not weird, so consider it normal. Everyone's UI needs differ.
Much of the Nezui kit does not easily yield resizing drawables as they are used in a lot of places. But the Image element class does calculate the drawable size using some hard math, and its draw routine uses that to achieve some sort of scaling according to a chosen policy (or freestyle if you like). sometimes when dev says "this drawable wont scale in my element" its because the element class they are using just can't do it.
The final thing you mention about drawables in the constructor: seems like a typo resulting possibly from copy/past from another drawable and overlooked. (and could be fixed) It really should offer you the third argument with name reflecting that it's supposed to specify the ImageChecked drawable, and it does look that way as you saw following the constructors. There is some value in having a checked version of the image I suppose, and you could see it with SetChecked. But since you're more interested in the over/hover thing, you could use your custom class and instantiate the ImageButtonStyle with all the drawable elements you want or dont want, including the ImageOver drawable.
Not sure if this is a bug or not, but I was unable to scale/resize the Image of ImageButtons through any method on the Table, Row, Cell, the ImageButton or even the Image itself. I ended up changing the Layout() method of Image from
imageWidth = size.X;imageHeight = size.Y;toimageWidth = size.X * scaleX;imageHeight = size.Y * scaleY;(Line 116 & 117) and then it worked as expected. Is there another way I missed or should this be made into a pull request?Also the overloaded constructor for ImageButtons taking three IDrawables suggests that the third IDrawable is to be displayed when the mouse hovers over it (ImageOver). But instead it gets set to the ImageChecked property, which I honestly don't know when it would be displayed, but it's certainly not what I expect or need.