On 14 July 2011 03:23, Greg Brown <gk_br...@verizon.net> wrote: >> The same syntax could also be used to support a clip area on an >> Image/Picture. >> Instead of the iconBounds data being passed on to an ImageView, it >> would instead be passed on the Image/Picture that ButtonData uses >> internally. > > True, but that's kind of sketchy. It would actually be modifying the button's > data, which renderers aren't really supposed to do. The renderer "owns" the > image view, so it is OK to modify that.
No, not modifying it, just specifying the bounds within the larger image that should be exposed as a smaller image. Much the same as a Panorama showing an image doesn't modify the larger image, but just exposes part of it. I was thinking of a lightweight ClippedImage for want of a better name, that would just wrap/decorate another Image. // Load an image resource Image sourceImage = Image.load(...); // Create a new image that shares another Image's data // At this point it would just be a duplicate of the source image, but sharing its BufferedImage or whatever is used internally. ClippedImage image = new ClippedImage(sourceImage); // Now would its size would be determined by the supplied bounds, and it would only show the appropriate section of the source image (not actually create a copy of the source and clip it) image.setClipBounds(bounds); // Or even simply this .... Image sourceImage = Image.load(...); // Returns a new Image sharing the actual data of sourceImage image = sourceImage.getImage(bounds); Something just doesn't sit right with me about passing data to ImageView, and then telling it to only show part of it. Perhaps if it there were frequent context switches, such as when creating an animation from parts of an image (think animated GIF). It just seems cleaner to prepare the data first, and then let ImageView simply show whatever it has been given. Much the same as when populating a ListView, TableView or TreeView for example. You figure out what you want it to display and then provide it to the Component. You can't directly tell a ListView to only show the widgets with a sale price of > $10. You do that by manipulating the list that ListView uses. Are there other Components that are managed differently to ListView, TableView & TreeView? Containers do to a certain extent, but that is part of their purpose. I suppose it could be argued that the ImageView is just 'rendering' its data in a different way, but then why not introduce an ImageViewRenderer interface? (Not that I think this is necessary or desirable) One other thing popped into my head, but probably doesn't need any special consideration. What if a ListItem (or similar source of content) should be displayed with different icons depending on whether or not it was selected or disabled? The current solution would probably involve a custom renderer which knows about the multiple icons (or how to read them from a ListItem that supports multiple icons) and places them into the renderer's ImageView accordingly. I suppose the same would be true with this proposal, only that the ImageView would have its clip bounds adjusted - either instead of, or possibly even in addition to changing the source image. Chris
