Hi,
Now that I'm working on the specifics of the stack file format, I thought
it would be the right time to ask how we should modify the way things like
the card and background pictures are handled.
Remember:
- HyperCard has no vector graphics objects yet
- Every card and background has one bitmapped image that can be modified
using the paint tools and that can contain black, white and transparent
pixels
Now, this is all nice and useful, but when we introduce vector graphics,
all of this might look a little makeshift, because
Then You Would Have:
- Vector drawing objects (including ovals, pixel image objects, lines etc.)
- At the bottom level below all vector graphics every card and background has
a bitmapped image ...
But why? If you want a bitmap image you can simply create a pixel image
object and make it bottom-most, right? But a disadvantage of this approach
would be that pixel images on top of a background button might not promote
the click to the button they cover, we'd need a special provision to allow
this. Also, if you want only vector graphics, why carry around a pixel
object for every card? (OK, image compression would probably make this a
non-issue). The trouble I see when doing it differently is we have to
explain to people: Beside the graphics objects, there is a painting area at
the bottom.
How SuperCard solves this:
- Vector drawing objects
- Card/bg pictures get converted to pixel image objects without a script,
which signals to SuperCard that clicks are to pass through.
But this would mean people would find inconsistent behaviour, because
buttons without a script swallow clicks while graphics don't, and the part
count inside stacks would suddenly be off by one.
Now, I have one half-baked solution on which I need your thoughts:
Remember that resources like ICONs are a Mac-only affair. I.e. we will need
to find a cross-platform way to store small images in the stack that have
ID numbers and can be used as icons. Also, people have been clamoring for
icons bigger than 32x32 pixels.
Note that there are some similarities between icons and the card picture
the way we're planning to do this:
1) arbitrary sizes
2) part of the stack
3) transparency
So, what I thought of is: Why don't we modify the concept of the card
picture? All card pictures are converted to icons and kept in the stack in
a separate list (as "data fork resources", if you wish). Every card has a
backdrop image property (not unlike the background of a web page) for which
any icon can be used. This backdrop doesn't swallow clicks.
However, this would again mean that there are two places where people have
to look for graphics (vector objects and icons). But anyway, it might be
better than three (vector objects, icons, cd/bg picture). But what isn't
yet solved is the problem of the paint tools: How do we explain that
clicking outside any pixel image objects will draw in the background image,
probably changing other cards that share this icon?
Another thought I am having is just leaving the card and background
picture in there as legacy and giving cards a "paint canvas" property to
turn this on or off. Converted HC stacks would automatically have this
property set and thus work just like before, however new stacks would
mainly work just by using vector graphics. Why I don't want to have a card
picture you can always draw in is because an unsuspecting click outside the
pixel image object you're currently drawing in might otherwise spoil your
backdrop.
Help! Does anyone have a good idea?
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
The future of programming: http://freecard.sourceforge.net
_______________________________________________
Freecard-general mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/freecard-general
