@wpI think there is no way to distinguish a single image from mulitple images now because the ImageList now accepts any size (the old one insisted on the Width and Height properties). And the many buttons: Well, you'll get used to it...
a button "Add sliced" could be welcomed.
(although there already are a bunch of buttons there...
could it not be detected at file opening as before?)
If opened in Lazarus 2,
the old TImageList will show the file adequately sliced
but it won't be possible to reload the original image file in a new TImageList
Although some kind of regression I'd prefer to keep this modification in trunk and avoid backporting to fixes because the release of the new version is so close. Martin, do you agree?I had a quick look, all code is in new methods (except 2 unused vars), not called by existing code. So it can't cause regressions to existing code. Therefore it should be fine.
Is it normal that the imagelist clears when a new value for Width or Height is set in the property editor? To reproduce:yes. An image list is not a list of bitmaps it is a a huge bitmap with size of image height x image width * number of images in the list. By changing the the size the image list does not know how to handle the existing images ee center them in the new size? resize them? some other way? so it simple clears its results and forces you to reload the images so you can decide how to be handle on per image bases.
Every LCL control that supports ImageList has now a new [Images]Width property to decide what custom width at 96 PPI (100% scale) is to be used. Example: TToolBar.Images/ImageWidth, TListView.LargeImages/LargeImagesWidth.
Set the Scaled property to True and the image list will automatically pick up the scaled image in your High-DPI aware LCL application.