John: Yes, I'm interested.
My first learning project was to replicate my Windows image viewer/manipulator in Rev. That ended with some finality when it turned out that Rev runs so slowly that it cannot possibly process all of the pixels in a real image in the time a reasonable user would sit still. Sigh.
I'm now working on a special music/video player, again "porting" it from a Windows implementation. It's almost finished (in the sense that all of the features seem to work at least once!), but needs a lot of cosmetic work and then lots of testing. I am displaying guitar tablature in an image along the bottom of the screen. I want the image to "squeeze" into the given box, but NOT be distorted (a fairly obvious need in my opinion). So, I need to write (or steal!) the logic that figures out which dimension needs to be adjusted, and then adjust it, and then use the LockLoc (what a strange and unintuitive name!) to let it expand to fill the properly proportioned image container.
A snippet of code would suffice, although I've written this code enough times that I'm sure I could figure it out again. I am more annoyed that I even have to than anything else.
The Geometry facility is interesting (and novel to me), but I don't know that it will work at all with the kinds of things I want to do. Because I don't want to distort any images, I will end up altering the shape of the Image object each time an image is loaded. Eventually, it will be easy to lose track of the original shape/size of the "container" into which I was trying to stuff the images. There is a concept missing here, I think: we need THREE image sizes (pixel size on disk, size of largest space available on the screen, and actual space used on the screen) rather than the two (first and last, above) that is currently available. I'm spoiled: all of this was available in a single mode property in my previous IDE.
:) Jon John Ridge wrote:
Did you get any response to this query? If so, I've missed it - no surprise, given the volume! I got interested in the issue, and have been playing with the lockLoc property of the image. I do find the language confusing - the "image" is the control within which you display a JPEG (say). When lockLoc is true, the image (the control) stays as is, and the picture is forced to fit within it - which can lead to massive distortion, of course. When lockLoc is false (the default) the picture arrives in its native size - so your image may turn out to be a small window into it. You can grab the image and slide it around under the window. I've also done a ShrinkToFit handler, but I bet there are better ways of doing the job! If you're interested, I can send the stack to the User Space, or somewhere... Regards, John
_______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
