image sizing (was "dump newbie image questiosn"(
Jon
jbondy at sover.net
Mon Jun 6 07:33:58 EDT 2005
Nick, Jaque:
Here's a specific example.
I'm writing a music player. The top 300 pixels of the window/stack (no
matter how the user resizes the stack) is reserved for some fixed
buttons and tables. The remaining height, for the full width of the
stack, is reserved for display of guitar tablature. If the user wants
to see more/better tablature, the user makes the stack taller.
In Delphi and windows, I specify an Image object/component that lives
below the fixed objects, and automatically expands to fill all available
space below the fixed objects. In Windows this is called Client
Alignment. When I put an image (data) into that Image (object), because
of properties I set at design time, the image automatically becomes as
large as possible, but without distorting, within the original bounds of
the Image. If there needs to be white space to the right or below the
image, but within the Image, it is all done for me.
In Rev, I'm not sure how to get the Image to live below the fixed
objects. I guess I make a huge super-group out of all of that stuff,
and then have the Image float below the group using Geometry. I then
have to inspect the incoming image and change the size of the Image to
avoid the distortion. Having every programmer intervene in this way is
more complex and more prone to error. And what I'm trying to do is such
an obviously desirable behavior: that's why I'm frustrated. I expect to
roll my own in special circumstances, but the whole point of Rev is that
it is powerful, right? Not in this situation. And not when it comes to
Tables. Or processing image pixels. Very primitive and slow.
In fact, my player is more complex than described above. There are
quite a few "panels" of objects that must move around depending on a
variety of things (like "are we playing audio or video", because in the
latter case, I have to provide screen real estate for the image; and
"are the tablature files present", because I then have to provide space
for those images). I'm about to start struggling with how to do this in
Rev. The Geometry paradigm is very different than the Align paradigm on
Windows/Delphi. Not worse or better, that I can see, but different.
And having had the IDE crash when I combined Geometry with On ReSize,
I'm gun-shy.
I've read about how people use multiple cards stacked behind each other,
with each card having virtually identical content. I suppose I could
try to design two or three fixed format cards and stack them, but I'm
not familiar with the tradeoffs. In Delphi I would NEVER duplicate
objects, for fear that they would not synchronize with each other
without my manual intervention. How do I put a Table on three cards and
have it appear the same on all cards (content if not size and position)?
For example, I gather that the Tab object does not work at ALL like in
Windows, where each tab has different content. I gather the Tab in Rev
just gives the user a signal that a different card is desired, and
provides the tab visual. It is up to the user to put the varying
content on every card (along with a series of redundant Tabs) and switch
between cards manually (again, something that is not required in
Delphi/Windows). Many of you keep saying how easy Rev is to use, how
powerful, how productive. There are many counter examples, and Tabs
seem to be one.
:)
Jon
Nicolas Cueto wrote:
>Hello.
>
>Sorry to barge in what seems like a private conversation
>between Jon and Jacqueline about lockLoc and image
>resizing but it's reminding me of a similar "problem" I had
>with one of my image-based stacks a long time back.
>
>Once upon a time, while my young EFL learners and I were
>happily studying the English names of shapes using a
>concentration game stack, I was very surprised to hear
>the word "rectangle" emitting from the PC speakers when
>the image on-screen was very much a "square".
>
>Looking for the source of this mistake later on, I discovered
>that the culprit was the lockLoc setting of each image object,
>Though the original image had indeed been a "rectangle",
>the lockLoc of the image object forced the "rectangle" to fill
>in the entire image object -- or, as Jon wrote, it scaled in both
>directions.
>
>My solution then was to create a new rectangle image
>file, with lots of white space at the top and bottom of
>the rectangle.
>
>But something Jacqueline wrote to Jon is making
>me think that maybe there's another (easier!) way,
>i.e.:
>
>
>
>>Well, generally we calculate the dimensions before we set the image
>>size. ;) Then it works okay.
>>
>>
>
>"Calculate the dimensions"? Can someone explain how to do this
>with RunRev? (Or is Jacqueline just joking? ;) )
>
>Cause I have to agree with Jon that, at least sometimes,
>the image object's lockLoc property does cause an ugly
>distortion of an original image file's size.
>
>So, if there's a way around this "ugliness" ...
>
>Thanks.
>
>Cheers,
>Nicolas Cueto
>niconiko language school
>(J)
>
>_______________________________________________
>use-revolution mailing list
>use-revolution at lists.runrev.com
>http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
>
>
More information about the use-livecode
mailing list