Re: Mobile Device Physical Size

[Richard Gaskin via use-livecode]

Ignore my last post.  Garbage.  I had overlooked a rather obvious fact 
of screen manufacturing: each method will have slight variance in terms 
of absolute PPI, resulting in variance not only in physical pixelDensity 
differences but in how accurately the OS will bother to account for them 
in terms of the approximated logical pixels.


Screens aren't rulers. :)

When you look at devices with sufficiently different screens, you can 
see that common elements like the status bar are slightly different from 
one device to another.  LiveCode objects are no exception.  This can be 
seen with pretty much all software.


Near the beginning of the year when I was fleshing out layout mechanics 
for a couple apps I'm working on, I not only laid my test pool devices 
side by side, but also used a small mm ruler to see how consistently 
they render controls of a known size.


The variance I saw and measured was about the same as what we see here 
between OSes, not small enough to be completely inconsequential but not 
large enough to matter for most things.


As long as we don't try to make rulers on screen for measuring physical 
objects, we can likely account for reasonable object placement, even 
between platforms, well enough.


It would be interesting to learn if Apple devices have 
visible/measurable differences in physical size of software objects 
between screens made using different manufacturing methods.  But it does 
seem to be the case with Android.


--
 Richard Gaskin
 Fourth World Systems

Richard Gaskin had too much coffee when he wrote:
Thanks, Brian.  With your stats we now have our first anomaly, between 
the two platforms:


The iOS math checks out in terms of the reported logical metrics 
matching the physical pixels per the pixel density.


But when we compare the iPhone 5.5" screen with the LG Stylo 5.5" 
screen, LiveCode is telling us that the iPhone screen is both wider and 
taller. Of course given the same diagonal, one screen could be either 
wide or taller than the other, but not both.


This suggests that Apple's APIs and/or LC's handling of the metrics is 
sufficiently different from how it works with Android that we might run 
into cross-platform issues where physical size matters.


I wouldn't try to make a measuring ruler on a phone screen, but more 
practical use-cases might involve layouts that require us to put a lot 
of touchable areas into a small space, so figuring out the smallest 
practical size for a clickable element can be important.  Or even just 
making sure text is of a sufficiently readable size without making it 
larger than needed on the other platform.


If we set things up in a way that works well for Android, it seems we 
risk having things too small on iOS.


Of course both OSes use their own APIs, and neither is required to adopt 
another vendor's method of accounting for things like pixel density.


But it sure would be nice if we had a method as reliable between 
platforms as it seems to otherwise be within each platform.


Maybe simplest if LC's pixel density could take into account the 
difference there apparently is between the two OSes.  That's the sort of 
thing that makes a cross-platform tool valuable, though I recognize 
there may not be as simple as introducing a correction factor for pixel 
density; given the complexity of rendering/Skia, I suspect it's a bit 
more involved than that.


I guess the only solution where physical size of controls between 
platforms may be especially important is for us to just remember that 
regardless of any specific physical pixel density, logical pixels will 
be reported to us as about 20% larger on iOS than on Android, and try to 
aim for somewhere in between.


--
  Richard Gaskin


Brian Milby wrote:

 > iPhone6SPlus: 5.5" 1242x2208 414x736 414x736 3
 >
 > On Sat, Oct 21, 2017 at 3:54 PM, Richard Gaskin via use-livecode
 > wrote:
 >
 >> Yesterday, in reply to Ralph's post I included these notes about mobile
 >> metrics:
 >>
 >> > ...it seems that LC's resolution-independence works very much like
 >> > that of browsers (probably using the same OS APIs under the hood),
 >> > using logical metrics rather than physical.
 >> ...
 >> > I just ran a quick test to see how well that works:
 >> ...
 >> >   Diag  PhysicalWebLiveCode PxDensity
 >> >         -
 >> > LG G Stylo Phone: 5.5"  720x1280  360x592  360x592   2
 >> > Amazon F7 Tablet: 7.0"  600x1024  600x976  600x976   1
 >>
 >> This morning I had some testing to do so I charged a couple older
 >> devices and ran my test on each to get:
 >>
 >>   Samsung S4 Phone: 5.0"  1080x1920  360x640  360x640  3
 >>   Samsung S1 Phone: 4.0"   480x800   320x508* 320x534  1.5



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:

Re: Mobile Device Physical Size

[Richard Gaskin via use-livecode]

Thanks, Brian.  With your stats we now have our first anomaly, between 
the two platforms:


The iOS math checks out in terms of the reported logical metrics 
matching the physical pixels per the pixel density.


But when we compare the iPhone 5.5" screen with the LG Stylo 5.5" 
screen, LiveCode is telling us that the iPhone screen is both wider and 
taller. Of course given the same diagonal, one screen could be either 
wide or taller than the other, but not both.


This suggests that Apple's APIs and/or LC's handling of the metrics is 
sufficiently different from how it works with Android that we might run 
into cross-platform issues where physical size matters.


I wouldn't try to make a measuring ruler on a phone screen, but more 
practical use-cases might involve layouts that require us to put a lot 
of touchable areas into a small space, so figuring out the smallest 
practical size for a clickable element can be important.  Or even just 
making sure text is of a sufficiently readable size without making it 
larger than needed on the other platform.


If we set things up in a way that works well for Android, it seems we 
risk having things too small on iOS.


Of course both OSes use their own APIs, and neither is required to adopt 
another vendor's method of accounting for things like pixel density.


But it sure would be nice if we had a method as reliable between 
platforms as it seems to otherwise be within each platform.


Maybe simplest if LC's pixel density could take into account the 
difference there apparently is between the two OSes.  That's the sort of 
thing that makes a cross-platform tool valuable, though I recognize 
there may not be as simple as introducing a correction factor for pixel 
density; given the complexity of rendering/Skia, I suspect it's a bit 
more involved than that.


I guess the only solution where physical size of controls between 
platforms may be especially important is for us to just remember that 
regardless of any specific physical pixel density, logical pixels will 
be reported to us as about 20% larger on iOS than on Android, and try to 
aim for somewhere in between.


--
 Richard Gaskin


Brian Milby wrote:

> iPhone6SPlus: 5.5" 1242x2208 414x736 414x736 3
>
> On Sat, Oct 21, 2017 at 3:54 PM, Richard Gaskin via use-livecode
> wrote:
>
>> Yesterday, in reply to Ralph's post I included these notes about mobile
>> metrics:
>>
>> > ...it seems that LC's resolution-independence works very much like
>> > that of browsers (probably using the same OS APIs under the hood),
>> > using logical metrics rather than physical.
>> ...
>> > I just ran a quick test to see how well that works:
>> ...
>> >   Diag  PhysicalWebLiveCode PxDensity
>> >         -
>> > LG G Stylo Phone: 5.5"  720x1280  360x592  360x592   2
>> > Amazon F7 Tablet: 7.0"  600x1024  600x976  600x976   1
>>
>> This morning I had some testing to do so I charged a couple older
>> devices and ran my test on each to get:
>>
>>   Samsung S4 Phone: 5.0"  1080x1920  360x640  360x640  3
>>   Samsung S1 Phone: 4.0"   480x800   320x508* 320x534  1.5



___
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

Re: Mobile Device Physical Size

[Brian Milby via use-livecode]

iPhone6SPlus: 5.5" 1242x2208 414x736 414x736 3

On Sat, Oct 21, 2017 at 3:54 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Yesterday, in reply to Ralph's post I included these notes about mobile
> metrics:
>
> > ...it seems that LC's resolution-independence works very much like
> > that of browsers (probably using the same OS APIs under the hood),
> > using logical metrics rather than physical.
> ...
> > I just ran a quick test to see how well that works:
> ...
> >   Diag  PhysicalWebLiveCode PxDensity
> >         -
> > LG G Stylo Phone: 5.5"  720x1280  360x592  360x592   2
> > Amazon F7 Tablet: 7.0"  600x1024  600x976  600x976   1
>
> This morning I had some testing to do so I charged a couple older devices
> and ran my test on each to get:
>
>   Samsung S4 Phone: 5.0"  1080x1920  360x640  360x640  3
>   Samsung S1 Phone: 4.0"   480x800   320x508* 320x534  1.5
>
> So now we have data from four devices with very different specs:
> - four different resolutions
> - four different physical sizes
> - four different pixel densities
> - four different Android versions
> - three different vendors
>
> ...and in each case the screen metrics as understood by web browsers match
> those LiveCode gives us (with the one minor exception in the oldest phone,
> noted in the footnote below).
>
> It would be good to know if any of you testing with iOS devices get
> results that don't like up as well as these.
>
> But from what I've seen so far, on Android (and in my limited testing on
> iOS devices a few months ago) it looks like LC's resolution independence is
> very reliable for object placement across devices with very different
> display characteristics.
>
>
> * I don't believe there's a version of FireFox available now for a phone
> that old (I keep it in its original state with an older Android version for
> testing), so the web test used the browser Samsung included on those
> models.  The difference of 26p is likely a bug (maybe counting the status
> bar height twice?), one I've not seen in newer browsers.
>
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> 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
>
___
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

Re: Mobile Device Physical Size

[Richard Gaskin via use-livecode]

Yesterday, in reply to Ralph's post I included these notes about mobile 
metrics:


> ...it seems that LC's resolution-independence works very much like
> that of browsers (probably using the same OS APIs under the hood),
> using logical metrics rather than physical.
...
> I just ran a quick test to see how well that works:
...
>   Diag  PhysicalWebLiveCode PxDensity
>         -
> LG G Stylo Phone: 5.5"  720x1280  360x592  360x592   2
> Amazon F7 Tablet: 7.0"  600x1024  600x976  600x976   1

This morning I had some testing to do so I charged a couple older 
devices and ran my test on each to get:


  Samsung S4 Phone: 5.0"  1080x1920  360x640  360x640  3
  Samsung S1 Phone: 4.0"   480x800   320x508* 320x534  1.5

So now we have data from four devices with very different specs:
- four different resolutions
- four different physical sizes
- four different pixel densities
- four different Android versions
- three different vendors

...and in each case the screen metrics as understood by web browsers 
match those LiveCode gives us (with the one minor exception in the 
oldest phone, noted in the footnote below).


It would be good to know if any of you testing with iOS devices get 
results that don't like up as well as these.


But from what I've seen so far, on Android (and in my limited testing on 
iOS devices a few months ago) it looks like LC's resolution independence 
is very reliable for object placement across devices with very different 
display characteristics.



* I don't believe there's a version of FireFox available now for a phone 
that old (I keep it in its original state with an older Android version 
for testing), so the web test used the browser Samsung included on those 
models.  The difference of 26p is likely a bug (maybe counting the 
status bar height twice?), one I've not seen in newer browsers.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: Resizing stack window by scaling

[Richard Gaskin via use-livecode]

Hello Peter -

Scaling is tempting, but problematic.

Automating that with the stack's scaleFactor would be quick, but will 
scale everything, even controls the user needs to interact with. If the 
default size is good will they be usable at a smaller size? will text be 
readable?


Hand-coding a more refined scaling can be done, but it's a bit of work. 
It's been a while since I've seen your app, but from from what I recall 
of your app's UI it should be possible to craft a scaling routine for 
it, but it would not be trivial.  Many decisions would have to be made 
about minimum size for both readability and interaction.


Your item #2 noted 12" screens are just a bit small.  That's actually 
not a bad problem to have, because it's very close to the most popular 
size, 11.6", which is also the smallest practical size most apps will 
need to deal with (more on that below).


Moreover, most 12" screens sold in the last half-decade or so have the 
same resolution as 11.6" screens, 1366x768, with just slightly larger 
pixels.  So for the purposes of UI layout, they're effectively the same.


1366x768 is so common that it may be both less work and more rewarding 
in terms of market share to consider a refinement of your app's design 
to make that resolution optimal first, and consider dynamic scaling or 
other options later on.


If this impacts a lot of your content, you may consider looking at ways 
to automate that once you've identified the common patterns needed to 
accommodate the change.


A world of students using Macbook Airs and the most popular Windows 
laptops will welcome your app optimized for 1366x768.


The exercise may also provide a good opportunity to consider options for 
making good use of larger monitors without scaling both X and Y axes, or 
scale each to optimize different content opportunities.  For example, 
with a timeline a longer X axis will let you see more time, while a 
taller Y axis can offer more details about what's happening in a given 
moment.  Both can be useful, but neither is true "scaling" per se.


Many possibilities, but until the app has 1366x768 as its optimal size 
it may be more difficult to decide best approaches for using the space 
available on the fewer machines with larger screens.




Notes on minimal size for desktop layouts:

One of the risks of being a developer is that we often have better gear 
than our users.  Spending all day with our machines we may have more RAM 
than they do on average, or faster CPUs, and often larger monitors.  Now 
and then this may tempt us to design for our own system, but it's 
helpful to keep user specs in mind and design for those first.


If you haven't yet don't fret; at least you're in good company.  I've 
met some very well-placed UI designers who overlook the market stats on 
monitor sizes.  Indeed it was my own mistake in this area years ago that 
has me checking resolution trends at least annually now.


With monitors, 1366x768 screens are by far the most common, the second 
leading size only a bit more than half as popular, and it's a long tail 
of single-digit market share from there:


1366x768:  29.87%
1920x1080: 16.69%
1440x900:   6.86%
1600x900:   5.81%
1280x800:   5.14%
1024x768:   4.74%


1366x768 is most prevalent among small-and-light form factors, but can 
be found in larger laptops in the 12" and 13" ranges, and once in a 
while with older, bulkier 15" laptops.


Given the market share of 1366x768, desktop software should ideally have 
their layouts optimized for that first, allowing resizing where 
appropriate for other sizes.


Fortunately, the need to support anything smaller is so rare you may not 
need to bother unless you're in a specialized niche where a specific 
small screen size is uncommonly popular.  The 4% using 1024x768 are 
probably machines too old to be in your target market; the other 96% 
will welcome your time spent on more relevant considerations.


So in practical terms, 1366x768 is not only the primary target for 
today's layouts, but also the smallest you're likely to need to support. 
 That's helpful, as it's usually less of a problem to have more space 
available than it is to have too little.


When designing for any size, keep in mind that in Mac most users will 
have the Dock at the bottom of the screen, and most Windows users will 
have their Task Bar there.  Additionally, the menu bar will need to be 
taken into account when designing for the actual content area of your 
window.


So while 768 is a good vertical minimum to target, between the Dock/Task 
Bar, menus, and drag bar, actual usable size will be much smaller.


The Dock is the largest element, 64p by default in El Capitan. With a 
menu bar height of 22p, and another 22p for the drag bar, the content 
region of the window is normally only about 660p.  Design your content 
for that and you're golden.


--
 Richard Gaskin
 Fourth World Systems
 

Re: Resizing stack window by scaling

[Pyyhtiä Christer via use-livecode]

The following is only one opinion of many possible.

First, you should consider automatic scaling only with a very restricted amount 
of cases.  These are for example sort of games, where the "playing field" is 
the better the larger it is, and the icons / images and their relative 
positions or moves act well.

Second, if you want to make a balanced user interface, you might use the full 
size of a phablet, but with larger tablets or laptops, you might choose the 
window to be smaller, and the width and height to be in relation to a phone / 
phablet form.  You maintain your smart phone at a distance of 30+ cm (1 ft), 
and a laptop or tablet twice the distance.  This gives you a guidance for 
required sizing of the display of your app on a smartphone / phablet / tablet & 
laptop.

The result is that you want to do the scaling retaining the relative positions 
of objects in all device implementations. I even think that you should drop the 
option for rotating the display along the device position changes portrait / 
landscape - unless it is a part of the features and functions of your app.

Further the result is that you need to maintain a log of your objects and the 
possible inheritance of sub-objects (icon -> button; text content -> text field 
etc.), and do scaling for each object & level based on the screen size & 
resolution.

Yes it hurts initially, but it allows scaling to any device seamlessly.  In the 
case of laptops you just need to define the max window size you want to use (vs 
the # of available pixels you need), and do some desk simulation what it means 
on different sizes of tablets.  A too big difference from a smart phone screen 
to a tablet may mean that you need to be able to dig out either from the device 
by your app coding (where LiveCode is very efficient), or just make 
assumptions, and have separate versions in distribution.

In addition a good tool is to make a test you can send to any user, mailing 
(with the permission of the user) you all the device characteristics, allowing 
you to embed yet another exception into your scaling code.  Yes, it hurts, but 
becomes easier every time you must take action.


Christer Pyyhtiä
chris...@mindcrea.com


___
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

SOLVED Re: HELP - Script debugger out of sync

[James Hale via use-livecode]

After i sent my post I wondered if perhaps there were unseen gremlins in the 
script.

I copied it out and pasted into BBEDIT and  "Zap(ped) gremlins" (one of my 
favourite BBEDT commands).

Pasted the zapped script back into LC and everything was back in sync.

How I ended up with some unseen characters in the script I do not know but they 
are gone now and all is well.

Sorry for the disturbance.


James





___
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

HELP - Script debugger out of sync

[James Hale via use-livecode]

I have been modifying one of my utility apps and have hit a strange glitch.

While trying to debug the script I find the visual feedback of where I am in 
the script to be out of sync by, it appears, 4 lines.

For those interested in how this looks I have uploaded a video of same.

http://www.thehales.id.au/samples/lag%20debug.mkv 


For those not wanting to watch the symptoms are...

1. enter the debug mode of the script editor.
2. step into the handler
3. actually shown at the end of the handler (or more correctly 4 lines in)
4. stepping through script into other handlers I remain 4 lines out of sync 
with what is actually displayed.

I have now tried this in LC versions 8.16, 8.17, 8.20, 9dp9

All do the same thing.

I have deleted the preference files

They still do the same thing.

AURGH!!!

what is going on?

James




___
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