One Rect For All specificaiton
brahma at hindu.org
Sat Jan 16 13:16:27 EST 2016
I’m about ready to go into the documentation on this, not only for myself, but for our design team and for our illustrators.
I would like to make this collaborative in the sense that we would invite a limited number of contributors to the documentation. It would include some PDF’s templates for media-on-physical media (think water color or acrylic on small art pads) artists.
Pixel definitions for digital artists
and a simple LC stack with big rect on different cards with borders and a floating pallette that would dynamically change the stack size to simulate what happens on different devices, showing live content “safe zone” and the background over flow… etc
So… where do we put all such documentation? Other “open source” software typically maintain a DOKU style Wiki (or MediaWiki) for documentation of this nature. (e.g. Synfig) once a small group refines the documentation then we can release it to a wider group for more additions. Google docs could work and Google Drive, but me-thinks it would be better to somehow keep this in a LiveCode universe..
OR do the whole thing, including notes all in the stack… but then it gets back to:
How does a team collaborate on a stack? (obviously a script only stack can’t work because this is all about the presentation layer)
On January 4, 2016 at 6:55:34 PM, EED-wp Email (prothero at earthednet.org<mailto:prothero at earthednet.org>) wrote:
I wonder if a set of screen templates for a range of ui configurations might not be a product folks would be willing to pay for. It sounds like it might save some folks a lot of time.
> On Jan 4, 2016, at 6:33 PM, Colin Holgate <colinholgate at gmail.com> wrote:
> Don’t know, you should test it. According to the help it returns the screenrect after removing things like the keyboard overlay. But that may still be in virtual pixels, based on the card rect.
>> On Jan 4, 2016, at 8:55 PM, Sannyasin Brahmanathaswami <brahma at hindu.org> wrote:
>> Seems better to let Livecode do the job… which means working in iPad size even though your main target is phones. Odd, but that would work for controls that are meant to stay top and bottom.
>> OTHO I don’t understand how it is that “tricky”… doesn’t the screen rect solve this for any device?
>> on preOpenCard
>> put the effective screenrect into tRect
>> set the bottom of group “tabBar” to item 4 of tRect
>> end preOpenCard
>> On January 4, 2016 at 3:12:46 PM, Colin Holgate (colinholgate at gmail.com<mailto:colinholgate at gmail.com>) wrote:
>> Which you choose is often dependent on whether you have tools that stick to the top and bottom, or the sides. If you do use code to make them snap into place, it can be tricky. You need to find the real width and height of the device itself, divide one into the other, and use that as a multiplier against your card size to know how far from the center the controls should be placed. If you’re only doing current iOS devices you could make assumptions about it being 16:9 or 4:3, but that might not always be the case, and it wouldn’t be correct for most Android devices.
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the Use-livecode