Images of Imagebuttons not scaling

[pitaxed]

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;
to
imageWidth = 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.

[optimo]

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.

[davepruitt]

I am experiencing this same exact issue. My UI is fairly simple. The tree looks like this:

UICanvas is the top level node
UICanvas has a child that is a Table
Table has a child that is an ImageButton
The ImageButton is set to be top-right

This is the image I am using for the image button. It is 256x256:

No matter what I do, that image button will not resize. I have tried calling SetScale, SetSize, SetWidth, and SetHeight on the ImageButton object. None of them have any effect.

[davepruitt]

I have found the bug in your code. So, the ImageButton class has a private Image member called image. This member image is set to an IDrawable for the various states - button-up, button-down, etc. etc. etc. This image member is then "added" as a child of the the ImageButton (which inherits from Table so it can have child elements).

When setting the scale of the ImageButton, this scale factor is never passed down to the image member, so it literally never even knows that it should be scaled. My temporary fix is to simply make image a public member and manually set the scale on it rather than setting the scale on the ImageButton object.

So, in my temporary fix, my ImageButton class now begins like this:

	public class ImageButton : Button
	{
		public Image image;

And now when I set the scale in my code it looks like this:

var close_button = new ImageButton(close_button_up_sprite, close_button_down_sprite);
close_button.image.SetScale(0.25f);

This is a bit hackish so I think a better solution needs to be implemented, but that is what got it working for me.

[optimo]

for future reference - I was about to make the PR to fix this but then I found this tidbit:

// IDrawable has .MinWidth and .MinHeight
var close_button_up_sprite = new SpriteDrawable(...sprite);
close_button_up_sprite.MinWidth = sprite.SourceRect.Width * desired_scale;
close_button_up_sprite.MinHeight = sprite.SourceRect.Height * desired_scale;

this would scale the image and works as expected without changing any code or subclasses. and this works well for me because I have hard pixel values in mind and don't have to do the scale math like I show above, rather I just set it to twice the size of the sprite dimensions. (I know they are 32x32, for example)

food for thought. the commenters' ideas above about how scale should work ideally are not wrong, but I'm not sure thats how the original libgdx did it either so there may be a philosophical difference (the ui system has handful of such (in)consistencies.)
The advice is the same as ever with this ui system, when in doubt: subclass or rewrite the parts that dont behave intuitively for you. as far as I can tell these behaviors are copied right from the source libgdx stuff.

PS: to clarify for my earlier reply last year: I was using ImageTextButton which is similar but slightly different to ImageButton, they are not actually siblings surprisingly.