Does anyone know all the possible combinations of all screen sizes for
Android? I know there are only 8 iOS screen sizes, but I guess there may
be quite a few variants for Android. More than I suspect would allow for
separate images per layout.
--
Chipp Walters
CEO, Altuit, Inc.
Here is a start for some of the sizes:
http://en.wikipedia.org/wiki/Comparison_of_Android_devices
-- Tom McGrath III
http://lazyriver.on-rev.com
3mcgr...@comcast.net
On Jul 31, 2012, at 3:13 AM, Chipp Walters wrote:
Does anyone know all the possible combinations of all screen sizes for
On 7/31/12 2:13 AM, Chipp Walters wrote:
Does anyone know all the possible combinations of all screen sizes for
Android? I know there are only 8 iOS screen sizes, but I guess there may
be quite a few variants for Android. More than I suspect would allow for
separate images per layout.
I just updated my ResTool plugin. http://buchwald.ca/lc/ResTool.livecode.zip
If you open the reference stack (via the Ref button) and go to card 2, you'll
see a table of many of the most popular Android (and iOS) devices, with
resolution and pixel density... as well as a chart of standard screen
Charles,
I really like that plugin!!! Thanks for it.
Cheers
andre
On Tue, Jul 31, 2012 at 12:41 PM, Charles E Buchwald char...@buchwald.cawrote:
I just updated my ResTool plugin.
http://buchwald.ca/lc/ResTool.livecode.zip
If you open the reference stack (via the Ref button) and go to card
My thoughts as well.
On Tue, Jul 31, 2012 at 10:39 AM, J. Landman Gay
jac...@hyperactivesw.comwrote:
It's unrealistic to design any kind of library that needs to rely on
fixed resolutions or dimensions.
___
use-livecode mailing list
My very first attempt was to include scalable images in my own custom groups
and show the appropriate image on the right devices. But I experienced
sluggishness in going from card to card and rotating interfaces. I did not
delete the unused images once the device was know and that might have
-of-Resolution-Independent-Control-library-for-RevMobile-tp4652555p4653056.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe
In addition to the recent discussion, the hope would be to create a
responsive interface layout: one that adapts to different screen
dimensions/proportions. A good analogy is responsive web design
(http://en.wikipedia.org/wiki/Responsive_design), where the layout changes
based on size thresholds.
Seems like the whole pixel coordinate system achilles heel is showing. Better
would be a percentage system, so that theoretically I can set the topleft of a
control to a percentage of the hv of the card.
This really should be an engine change, but I suppose a library could be
developed for
I have to admit that my brain gets very dizzy when thinking about
resolutions/pixels/etc so please excuse if this question doesn't make sense
I believe we are now looking at resolutions and screen sizes much larger
that has been discussed so far. LG have just come out with 47 and 55
full 1080p
targets:
320x480
480x800
540x960
768x1024
800x1280
1920 x 1080
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Preview-of-Resolution-Independent-Control-library-for-RevMobile-tp4652555p4653102.html
Sent from the Revolution - User mailing list archive at Nabble.com
I've been toying with the concept of loading the mainstack of a stackFile
depending on if it's in the mobile or tablet category. The concept could be
expanded to have as many size ranges and you want. If these ranges were able to
be set by the dev then it would be quite flexible and allow
resolution targets:
320x480
480x800
540x960
768x1024
800x1280
1920 x 1080
--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Preview-of-Resolution-Independent-Control-library-for-RevMobile-tp4652555p4653102.html
Sent from the Revolution - User mailing
Could we be thinking about this the wrong way? Could we have a standalone build
time process that took our stack file and created a ldpi,mdpi,hdpi and xhdpi
version? Then a loader stack that loaded the right one...
--
M E R Goulding
Software development services
Bespoke application
The reason I posted this (most obvious post) was because the LC engine already
knows the difference between a point and a pixel and interprets two physical
pixels as a logical point with this command. It does know how to double the
size of 'everything' all at once. And what we are actually
Thomas McGrath III wrote:
The reason I posted this (most obvious post) was because the LC
engine already knows the difference between a point and a pixel
and interprets two physical pixels as a logical point with this
command. It does know how to double the size of 'everything' all
at once.
On 7/29/12 9:44 AM, Richard Gaskin wrote:
Should we consider adding an imageDirectory property?
Is there some simpler way to swap out the paths to all referenced images
without changing each one individually?
I think it would be pretty straightforward to do that without an engine
change.
I was suggesting something along these lines a couple of days ago but both
Scott and Chipp shot the idea down in preference for proportional scaling of x2
images. I'm not sure how the low end devices will cope with scaling images on
the fly but it would reduce app size. It's worthwhile noting
On 7/29/12 4:37 PM, Monte Goulding wrote:
I was suggesting something along these lines a couple of days ago but
both Scott and Chipp shot the idea down in preference for
proportional scaling of x2 images. I'm not sure how the low end
devices will cope with scaling images on the fly but it would
I haven't said much in this discussion because it's all such a mess I don't
know where to start. But to be honest, I agree that scaling would be better
in general than sets of presized images, since as you say, they'd all need
scaling anyway on some devices.
Good point. I'll try to clarify
I'd like to put in a vote for being able to separate the scaling from the
layout adjustment features. For desktop standalones I'd like to be able to
readjust the stack size without the objects scaling, but still have the general
layout readjust to fit the new window size.
Ultimately I'd like to
I agree and would go as far as saying that these must remain separate
libraries.They should play well together.
-- Tom McGrath III
http://lazyriver.on-rev.com
3mcgr...@comcast.net
On Jul 28, 2012, at 2:44 PM, Charles E Buchwald wrote:
I'd like to put in a vote for being able to separate the
Yes. That was the reason I cose to use the same handler names as Ken's more
robust desktop layout lib.
On Saturday, July 28, 2012, Thomas McGrath III wrote:
I agree and would go as far as saying that these must remain separate
libraries.They should play well together.
-- Tom McGrath III
I wonder how long it will be before we need to deal with this on desktop?
Already a desktop pixel is not a physical pixel with multiple res monitors. But
that's a user choice. If they want to see stuff smaller they choose a higher
res. If our apps wanted to use the retina res then I expect we
For layout to play nicely with scaling it will need to place controls relative
to each other and window boundaries and not include any reference to physical
pixels without multiplying by a scaling factor. So if you want a field to have
3 px padding from the edge of the card you need to use 3 *
I've been looking into an LG 60 TV with Google TV built-in. Apparently
any apps for the Google store will be available to run on the TV. Does
that add another possible resolution/densoty to the pot?
Pete
lcSQL Software http://www.lcsql.com
On Sat, Jul 28, 2012 at 1:41 PM, Monte Goulding
OK, Monte, I get it now. I wasn't thinking that way, but it makes sense. If I
know my desktop application is not on a normal non-Retina display then
scaling = 1.0 (or whatever the equivalent is). On a Retina display it's
something higher/denser, and on Peter's new 60 LG TV maybe it's something
Livecode has included a command for dealing with the pixel and point issue….
The iphoneUseDeviceResolution command specifies whether the full resolution of
high-resolution devices should be used.
By default, iOS handles this by mapping one logical 'point' to two physical
'pixels' with
Monte Goulding wrote:
With all due respect for the ambitious goals here, the further
we look into this the more clear it becomes that scaling must
be handled in the engine if we are to expect reasonable performance:
http://quality.runrev.com/show_bug.cgi?id=6589
Thanks Richard, I've voted
I'm glad that this is staying on list for now as I'm working through trying to
create a scalable app rather than ones with different fixed layouts.
Besides scaling the rect of objects, what other properties will likely need
consideration?
A few that I'm puzzling over at the moment…
textSize
The other thing is any images that are used as icons would need to be found if
they aren't on that stack. Probably in an icon/image library. What do people
think about resizing images as Chipp has done compared to providing 4 sizes. My
thought is that the framework could include a plugin that
My question would be, are 4 separate images for each control necessary?
You're not going to change density in the middle of session, so only one
scaled image for each control is needed at a time. While most of the
controls I've been building are groups of graphics (no images), It seems to me
First off, I would like to say there are a few things which are paramount
for me in any resizer library I would use. Please know these are only my
observations and requirements.
1. Needs to be unlocked and editable my me. If not, then I won't even look
at it. We all know the problems with MobGUI
First off, I would like to say there are a few things which are paramount
for me in any resizer library I would use. Please know these are only my
observations and requirements.
Great. Id like it to meet as many peoples requirements and get as much input as
possible :-)
1. Needs to be
Scott Morrow wrote:
I'm glad that this is staying on list for now as I'm working through trying to
create a scalable app rather than ones with different fixed layouts.
Besides scaling the rect of objects, what other properties will likely need
consideration?
A few that I'm puzzling over at
Why not then on first run, ask the user? At least until there is a
reliable automatic method. A simple Is this a phone or a tablet?. You
can figure the rest from the resolution.
~Roger
On Thursday, July 26, 2012, Chipp Walters wrote:
5. I think I can make a case that it's pretty much
Ok, scaling it is. I was just throwing it out there.
--
M E R Goulding
Software development services
mergExt - There's an external for that!
On 26/07/2012, at 9:40 PM, Scott Rossi sc...@tactilemedia.com wrote:
My question would be, are 4 separate images for each control necessary?
You're
With all due respect for the ambitious goals here, the further we look into
this the more clear it becomes that scaling must be handled in the engine if
we are to expect reasonable performance:
http://quality.runrev.com/show_bug.cgi?id=6589
Thanks Richard, I've voted for that now.
Let's
Is't the working screenrect your best friend at this point ? Works fine against
both iOS and Android.
Le 26 juil. 2012 à 02:59, Mark Wieder a écrit :
Scott-
Wednesday, July 25, 2012, 5:42:57 PM, you wrote:
Looking forward, it seems you're right: being able to lay out a stack at a
On 26/07/2012, at 5:06 PM, Pierre Sahores wrote:
Is't the working screenrect your best friend at this point ? Works fine
against both iOS and Android.
Let's take a button as an example. If I design a button I will design it to be
a usable size on screen. So if the screen density changes I
gave it 5 votes
--
Scott Morrow
On Jul 26, 2012, at 7:25 AM, Richard Gaskin wrote:
Scott Morrow wrote:
I'm glad that this is staying on list for now as I'm working through trying
to create a scalable app rather than ones with different fixed layouts.
Besides scaling the rect of objects,
That is one of the problems with resizing controls based only on the size of
the screen and not on the resolution of the device and not also changing the
placement of controls based on the resolution of the device.
For most apps the size of controls (and text) should remain the same when going
Also, for some layouts when changing Orientation only the widths of controls
may need to change based on the LAYOUT but not the height or text size.
Trying to find one solution for all of these scenarios is not going to happen.
Especially if you are using native controls (real or faked).
--
Thanks Tom,
you are right of course. I watched the tutorial and the resize tool makes it
very tempting to design one app for all devices, but I will be better of with
building an ipad and a iphone app and change the layout upon change in the
orientation.
On Jul 25, 2012, at 3:26 PM, Thomas
That's just crazy talk! I wonder if other mobile dev apps are running into
this?
Bob
On Jul 25, 2012, at 6:11 AM, Thomas McGrath III wrote:
That is one of the problems with resizing controls based only on the size of
the screen and not on the resolution of the device and not also changing
Yeah it is crazy.
I have had to deal with this in every Obj-c xCode app I've built so far. xCode
however has both a system for dealing with @2x size images and with rotating
interfaces - but I still have to have multiple views for both iPhone and iPad.
-- Tom McGrath III
I'm starting to put together a mobile framework to at least handle the
mobile/tablet issue. What it does so far is start using any libraries in a
specified folder and load either a tablet stack or mobile stack depending on if
the max res is = 1024. Until we can work out size I think that's the
Phablets... I like it. :-)
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Don't say that too loudly! Next thing you know Apple will release an iPhab!
On Jul 25, 2012, at 2:05 PM, Roger Eller wrote:
Phablets... I like it. :-)
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe,
Good points.
Years ago I created altLayouLib and have used it for work in multiple OS
environments. With it you could set the controls layout behavior based upon
OS. It read the OS and resized/moved controls based upon MacOS, Win32 or
Other.
As far as responsive design goes, it perhaps this
Helps if I proofread before posting..
-- As far as responsive design goes, perhaps a custom layouts per card
size approach a proper way to go.
-- The square card size should also handle most cases where you want the
width of a control to change but not the height.
On Wed, Jul 25, 2012 at 4:57
Ok, making this up as i go. We might as well design a system from the start
that can handle all 4 android screen densities and used a couple of them as
synonyms for the iOS densities. Even though the android densities are ranges I
think its reasonable to treat them as absolutes as long as your
for now...
On Jul 25, 2012, at 3:14 PM, Monte Goulding wrote:
We might as well design a system from the start that can handle all 4 android
screen densities
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to
How does LC determine density?
On Wednesday, July 25, 2012, Monte Goulding wrote:
Ok, making this up as i go. We might as well design a system from the
start that can handle all 4 android screen densities and used a couple of
them as synonyms for the iOS densities. Even though the android
Yes, any system we design should handle potential future densities however I'm
really not sure if higher densities than retina would be worthwhile. If the
human eye can't detect a difference then why not save the processing power and
$.
--
M E R Goulding
Software development services
mergExt
On 26/07/2012, at 8:40 AM, Chipp Walters wrote:
How does LC determine density?
Good question. If the engine does it then it doesn't provide that info to us.
We know density on iOS so we use that to switch between mdpi and xhdpi.
On android we can only make an educated guess based on this
OK Scott, should we continue on list or move off. It might be good to continue
on list for a while to see who's keen to be involved.
Continuing to think out loud on this. One thing we want to be able to do is
work in whatever density we like and then have everything still scale right. So
what
Looking forward, it seems you're right: being able to lay out a stack at a
specific resolution would be useful long term. I'm not up to speed on
Android, but last I saw, LiveCode wasn't able to detect Android display
density. If that's still the case, it would seem to be a problem since how
Scott-
Wednesday, July 25, 2012, 5:42:57 PM, you wrote:
Looking forward, it seems you're right: being able to lay out a stack at a
specific resolution would be useful long term. I'm not up to speed on
Android, but last I saw, LiveCode wasn't able to detect Android display
density. If
On 26/07/2012, at 10:42 AM, Scott Rossi wrote:
Looking forward, it seems you're right: being able to lay out a stack at a
specific resolution would be useful long term. I'm not up to speed on
Android, but last I saw, LiveCode wasn't able to detect Android display
density. If that's still
On 26/07/2012, at 10:42 AM, Scott Rossi wrote:
Looking forward, it seems you're right: being able to lay out a stack at a
specific resolution would be useful long term. I'm not up to speed on
Android, but last I saw, LiveCode wasn't able to detect Android display
density. If that's still
I still like your new word PHABLET - PHones And Bigger, Let Everybody
Touch! LOL
~Roger
On Wed, Jul 25, 2012 at 8:17 PM, Monte Goulding wrote:
One important thing to consider is inventing a cool non-developer specific
acronym and prefix for this thing ;-) My hope is it can handle more than
Monte, that is very possible what is happening. I will check that out.
-- Tom McGrath III
http://lazyriver.on-rev.com
3mcgr...@comcast.net
On Jul 22, 2012, at 7:51 PM, Monte Goulding wrote:
On 23/07/2012, at 9:29 AM, Thomas McGrath III wrote:
when using Monte's mergMK mapkit which renders
Very nice. Geometry manager the way it ought to work! I think for graphics I
would like to see LC support EPS vector graphics, which would solve the
resizing of graphics problem, but I am not holding my breath.
Bob
On Jul 21, 2012, at 4:03 AM, Chipp Walters wrote:
Hey all,
As you know,
Chipp and Ken,
This is fantastic. Thank you.
Bill Vlahos
_
InfoWallet (http://www.infowallet.com) is about keeping your important life
information with you, accessible, and secure.
lcTaskList: (http://www.infowallet.com/lctasklist/index.htm)
On Jul 21, 2012, at 4:03 AM, Chipp
I tried a simple test, and they don't exactly play well together.
tmControls are grouped objects with their own control scripts, and a nice
gui editor for altering their appearance. If I select each component of
the group separately, I can set their resize attributes with altResizer,
but if I
tmControl already has its own scaling routine. I'll probably have to look
providing a way to disable it if folks want to use Chipp's/Ken's library.
Regards,
Scott Rossi
Creative Director
Tactile Media, UX Design
Original message
Subject: Re: Preview of Resolution Independent
I'm only weighing my options at this point. If somehow Chipp/Ken's library
could be incorporated into tmControl (optionally), once they get it through
beta, it could possibly be the best of both worlds. I've only used
tmControl for a little while, but what do you mean by it already has its
own
probably have to look
providing a way to disable it if folks want to use Chipp's/Ken's library.
Regards,
Scott Rossi
Creative Director
Tactile Media, UX Design
Original message
Subject: Re: Preview of Resolution Independent Control library for RevMobile
From: Roger Eller
FWIW,
If tmControls had a settable altHeight and an altWidth, then they should be
able to work. Or if one could set their height and width from a script, the
resizer library would see them as just another control. Take a peek at the
lib code to see how his is done.
On Sunday, July 22, 2012, Roger
Saturday, July 21, 2012 at 11:45 PM -0700 wrote:
Hi Chipp,
Cool. Way to pre-order ? Will your Interface Designer framework include a way
to apply rules to multiple controls at once ?
Kind regards,
Pierre
How can one get get/purchase Interface Designer. That looks fantastic too.
On 23/07/2012, at 9:29 AM, Thomas McGrath III wrote:
when using Monte's mergMK mapkit which renders so much faster in non-retina
then in retina which then requires me to not use iOS resolution
That's the first I've heard of that. Actually you should be using UIKit points
for all my controls
I've seemed to lost the InterfaceDesigner link after the new overhaul of
our sites. You can PayPal sa...@altuit.com $15 and I'll send it to you.
On Sunday, July 22, 2012, RevList wrote:
Saturday, July 21, 2012 at 11:45 PM -0700 wrote:
Hi Chipp,
Cool. Way to pre-order ? Will your Interface
Hey all,
As you know, Ken and I have been working on some interesting libs for
managing resizing of stacks. I'm particularly focussed on RevMobile and
have created a toolset which allows developers to easily create resolution
independent interfaces-- which smartly resize to take advantage of any
Hey this looks awesome! This would certainly save a lot of time!
On Sat, Jul 21, 2012 at 7:03 AM, Chipp Walters ch...@chipp.com wrote:
Hey all,
As you know, Ken and I have been working on some interesting libs for
managing resizing of stacks. I'm particularly focussed on RevMobile and
Is that Interface Builder a new lib as well or is that available someplace?
SKIP
On Sat, Jul 21, 2012 at 10:14 AM, Magicgate Software - Skip Kimpel
s...@magicgate.com wrote:
Hey this looks awesome! This would certainly save a lot of time!
On Sat, Jul 21, 2012 at 7:03 AM, Chipp Walters
Hi Chipp,
Looks great... can't wait to use it! I have at least 3 projects in the pipeline
for which it will be invaluable.
May I suggest that it could be very nice to have a keyboard shortcut for
refresh position, since it looks like you are clicking that button an awful
lot.
It looks like my
-Independent-Control-library-for-RevMobile-tp4652555p4652578.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
FYI, for those interested...
I don't lock scripts and anyone can use this in their commercial projects
free of charge. IOW, this is a professional library which you can edit and
use however you like (just don't try and sell it please!)
On Sat, Jul 21, 2012 at 7:36 PM, Chipp Walters
Awesome! Will it work with tmControl too?
~Roger
On Jul 21, 2012 8:36 PM, Chipp Walters ch...@chipp.com wrote:
Sorry the double post-- I originally thought the OTHER post was my
originating one.
I've added some auto-install procedures to the plugin and it's now
available for testing at:
I don't know about tmControls. Do they respond to resizeStack and can hoe
set their rect and loc?
On Saturday, July 21, 2012, Roger Eller wrote:
Awesome! Will it work with tmControl too?
--
Chipp Walters
CEO, Altuit, Inc.
___
use-livecode mailing
82 matches
Mail list logo
