Re: Android - Different Builds

2019-06-14 Thread J. Landman Gay via use-livecode
For testing we could just do what we do now, since you can distribute to 
testers privately. I think we'd only need the bundle when submitting to the 
Play Store.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On June 14, 2019 10:01:40 PM Brian Milby via use-livecode 
 wrote:


From reading a little about it, I’m not sure why not.  Everything besides 
the engine/splash stack would go in the common bundle (not the right name) 
and then each engine would have its own slice.  The store would combine the 
two pieces into the apk for delivery.  We would still need to produce the 
apk for testing though (it looks like there is a way to pull an apk out of 
the bundle too).


How to do this is beyond me though

Thanks,
Brian
On Jun 14, 2019, 10:55 PM -0400, J. Landman Gay via use-livecode 
, wrote:

This is good to know. But what I'd really like to see is the app bundle
that the Play Store expects. I wonder if that's possible.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On June 14, 2019 9:24:24 PM Sannyasin Brahmanathaswami via use-livecode
 wrote:

> Got it, it works...
>
> Jerry __ thanks for the chart!
>
> "Boy!" this needs to be documented somewhere...
>
> BR
>
> ?Jerry wrote
> So like this for your sequence if your highest used VC is 15 then:
>
> Build VC
> arm v7a 16 >next time --->20>next time--->24
> arm64 17>next time--->21--->next time--->25
> X86 18--->next time--->22--->next time--->26
> x86-64 19--->next time--->23--->next time--->27
>
>
> and so on, you see the 64 builds need to be higher vc then the 32bits
>
>
> Mark (W) wrote:
>
> > I wonder if the reason this didn't work is because you have the
> > version code
> > for armv7 > that for arm64...
> >
> > I suspect the play store will choose the highest version coded APK
> > that will
> > run on the target device. As ARMv7 APKs will run on devices which can
> > run ARM64,
> > it will choose the ARMv7 in preference (as it is version code 14,
> > which is greater
> > than 7) and thus 'completely shadow' the ARM64 APK.
> >
> > Upshot: probably best to make sure ARM64 APKs have higher version code
> > than
> > ARM7 ones (the same is true of x86-64 and x86 - but in that case
> > you've already
> > got version-code-of(x86-64) > version-code-of(x86) which is why you
> > aren't getting
> > a shadowed error for those)
> >
> > Warmest Regards,
> >
> > Mark.
> >
>
> ___
> 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




___
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





___
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: Android - Different Builds

2019-06-14 Thread Brian Milby via use-livecode
From reading a little about it, I’m not sure why not.  Everything besides the 
engine/splash stack would go in the common bundle (not the right name) and then 
each engine would have its own slice.  The store would combine the two pieces 
into the apk for delivery.  We would still need to produce the apk for testing 
though (it looks like there is a way to pull an apk out of the bundle too).

How to do this is beyond me though

Thanks,
Brian
On Jun 14, 2019, 10:55 PM -0400, J. Landman Gay via use-livecode 
, wrote:
> This is good to know. But what I'd really like to see is the app bundle
> that the Play Store expects. I wonder if that's possible.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On June 14, 2019 9:24:24 PM Sannyasin Brahmanathaswami via use-livecode
>  wrote:
>
> > Got it, it works...
> >
> > Jerry __ thanks for the chart!
> >
> > "Boy!" this needs to be documented somewhere...
> >
> > BR
> >
> > ?Jerry wrote
> > So like this for your sequence if your highest used VC is 15 then:
> >
> > Build VC
> > arm v7a 16 >next time --->20>next time--->24
> > arm64 17>next time--->21--->next time--->25
> > X86 18--->next time--->22--->next time--->26
> > x86-64 19--->next time--->23--->next time--->27
> >
> >
> > and so on, you see the 64 builds need to be higher vc then the 32bits
> >
> >
> > Mark (W) wrote:
> >
> > > I wonder if the reason this didn't work is because you have the
> > > version code
> > > for armv7 > that for arm64...
> > >
> > > I suspect the play store will choose the highest version coded APK
> > > that will
> > > run on the target device. As ARMv7 APKs will run on devices which can
> > > run ARM64,
> > > it will choose the ARMv7 in preference (as it is version code 14,
> > > which is greater
> > > than 7) and thus 'completely shadow' the ARM64 APK.
> > >
> > > Upshot: probably best to make sure ARM64 APKs have higher version code
> > > than
> > > ARM7 ones (the same is true of x86-64 and x86 - but in that case
> > > you've already
> > > got version-code-of(x86-64) > version-code-of(x86) which is why you
> > > aren't getting
> > > a shadowed error for those)
> > >
> > > Warmest Regards,
> > >
> > > Mark.
> > >
> >
> > ___
> > 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
>
>
>
>
> ___
> 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: Android - Different Builds

2019-06-14 Thread J. Landman Gay via use-livecode
This is good to know. But what I'd really like to see is the app bundle 
that the Play Store expects. I wonder if that's possible.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On June 14, 2019 9:24:24 PM Sannyasin Brahmanathaswami via use-livecode 
 wrote:



Got it, it works...

Jerry __ thanks for the chart!

"Boy!" this needs to be documented somewhere...

BR

?Jerry wrote
So like this for your sequence if your highest used VC is 15 then:

   BuildVC
   arm v7a16 >next time --->20>next time--->24
   arm6417>next time--->21--->next time--->25
   X8618--->next time--->22--->next time--->26
   x86-64  19--->next time--->23--->next time--->27


   and so on, you see the 64 builds need to be higher vc then the 32bits


   Mark (W) wrote:

   > I wonder if the reason this didn't work is because you have the
   > version code
   > for armv7 > that for arm64...
   >
   > I suspect the play store will choose the highest version coded APK
   > that will
   > run on the target device. As ARMv7 APKs will run on devices which can
   > run ARM64,
   > it will choose the ARMv7 in preference (as it is version code 14,
   > which is greater
   > than 7) and thus 'completely shadow' the ARM64 APK.
   >
   > Upshot: probably best to make sure ARM64 APKs have higher version code
   > than
   > ARM7 ones (the same is true of x86-64 and x86 - but in that case
   > you've already
   > got version-code-of(x86-64) > version-code-of(x86) which is why you
   > aren't getting
   > a shadowed error for those)
   >
   > Warmest Regards,
   >
   > Mark.
   >

   ___
   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





___
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: Android - Different Builds

2019-06-14 Thread Sannyasin Brahmanathaswami via use-livecode
Got it, it works...

Jerry __ thanks for the chart!  

"Boy!" this needs to be documented somewhere...

BR

Jerry wrote
So like this for your sequence if your highest used VC is 15 then:

BuildVC
arm v7a16 >next time --->20>next time--->24   
arm6417>next time--->21--->next time--->25 
X8618--->next time--->22--->next time--->26   
x86-64  19--->next time--->23--->next time--->27

   
and so on, you see the 64 builds need to be higher vc then the 32bits


Mark (W) wrote:

> I wonder if the reason this didn't work is because you have the 
> version code
> for armv7 > that for arm64...
>
> I suspect the play store will choose the highest version coded APK 
> that will
> run on the target device. As ARMv7 APKs will run on devices which can 
> run ARM64,
> it will choose the ARMv7 in preference (as it is version code 14, 
> which is greater
> than 7) and thus 'completely shadow' the ARM64 APK.
>
> Upshot: probably best to make sure ARM64 APKs have higher version code 
> than
> ARM7 ones (the same is true of x86-64 and x86 - but in that case 
> you've already
> got version-code-of(x86-64) > version-code-of(x86) which is why you 
> aren't getting
> a shadowed error for those)
>
> Warmest Regards,
>
> Mark.
>

___
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: math on widths doesn't add up

2019-06-14 Thread Ralph DiMola via use-livecode
You don't need sub-pixels per say but you need to know they exist. I found
that out real quick when writing the color gradient math for CGI. If I did
not use center pixel coordinates the gradients were "jaggy" so to speak.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of hh via use-livecode
Sent: Friday, June 14, 2019 7:01 PM
To: use-livecode@lists.runrev.com
Cc: hh
Subject: Re: math on widths doesn't add up

@Dar.
Could we agree that in LC Script we cannot draw subpixels? (I would like
to...)

And yes, you are right with the invariance of width and height. The number
of pixels isn't dependent of how I enumerate them. Sorry.

> I don't understand why you say "pixel 1".

OK. I should say pixel 1 (one-based counting).
Zero-based counting certainly has also some advantages.


___
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: math on widths doesn't add up

2019-06-14 Thread Dar Scott Consulting via use-livecode
Sure, I'll agree (SVG notwithstanding).

> On Jun 14, 2019, at 5:01 PM, hh via use-livecode 
>  wrote:
> 
> @Dar.
> Could we agree that in LC Script we cannot draw subpixels? (I would like 
> to...)
> 
> And yes, you are right with the invariance of width and height. The number of 
> pixels
> isn't dependent of how I enumerate them. Sorry.
> 
>> I don't understand why you say "pixel 1".
> 
> OK. I should say pixel 1 (one-based counting).
> Zero-based counting certainly has also some advantages.
> 
> 
> ___
> 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: math on widths doesn't add up

2019-06-14 Thread hh via use-livecode
@Dar.
Could we agree that in LC Script we cannot draw subpixels? (I would like to...)

And yes, you are right with the invariance of width and height. The number of 
pixels
isn't dependent of how I enumerate them. Sorry.

> I don't understand why you say "pixel 1".

OK. I should say pixel 1 (one-based counting).
Zero-based counting certainly has also some advantages.


___
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: math on widths doesn't add up

2019-06-14 Thread dsc--- via use-livecode
For some reason the message below was delayed a while and thus is out of order.

Looking back, I see hh has been mentioning things like first pixel and counting 
pixels. This might be where there is confusion. I was referring to pixels by 
the LiveCode reference. 

> On Jun 14, 2019, at 4:13 PM, Dar Scott Consulting via use-livecode 
>  wrote:
> 
> When we apply math, we must map what we see to our mathematical models.  What 
> we see is LiveCode.  The application of math is thus an interpretation. (The 
> interpretation of calendar year or how-old-are-you might not apply.)
> 
> I do agree with you, except for the part that one has to redefine width and 
> height. A delta does not depend on the offset.
> 
> If I create a line from 0,0 to 100,0; I get a line visible on the card, not a 
> line just off the card. The LiveCode line is between the coordinates we are 
> talking about, that is, a half pixel moved in from those, creating pixel 
> coordinates off from what we are saying.
> 
> I can get the same thing with a rectangle of rect 0, 0, 101, 1. Well, if the 
> border width is zero and the fill color is set.  This uses the coordinates we 
> are talking about. The rectangle is filled.  
> 
> The one-pixel width of the line causes it to fill that space. If there is a 
> 1-pixel square as a brush and it went from 0.5 to 100.5, it would sweep out 
> the same space as the rectangle
> 
> However, others might have a view, an interpretation, that also works. 
> 
> 
> 
>> On Jun 14, 2019, at 3:04 PM, hh via use-livecode 
>>  wrote:
>> 
>> This is interestingly the same problem that made a lot of people believe
>> two thousand years were full at the end of 1999/ beginning of 2000.
>> Two thousand years were full at the END of 2000/ beginning of 2001:
>> 
>> Full year 1 has the left 0, the right 1 and the width = right-left = 1 year, 
>> ...,
>> full years 1 to 2000 have the left 0, the right 2000 and the width = 
>> right-left = 2000 years.
>> 
>>> Dar S. wrote:
>>> I like this interpretation. I don't think it is a popular view, but it 
>>> makes sense to me.
>>> I would change the range wording, though, to something like this:
>>> Pixel 0 ranges from 0 to 1.
>>> For example, the rect of a card has zeros.
>>> Maybe it depends on whether one wants to draw pixels on the intersections 
>>> of the lines
>>> on the graph paper, or in between.
>> 
>> No, this is math, not an interpretation. If you agree that counting pixels 
>> is one-based
>> then there is no pixel 0.
>> 
>> Rect (0,0,0,0) has left 0, right 0, top 0, bottom 0, width 0 and height 0, 
>> contains 0 pixels.
>> In fact it is degenerated to the point (0,0).
>> 
>> Rect (0,0,1,1) is one pixel, the first pixel on your coordinate system.
>> It has left 0, right 1, top 0, bottom 1 and width 1, height 1.
>> 
>> The width of a rect is the number of its pixel columns,
>> the height of a rect is the number of its pixel rows,
>> width*height of a rect is the number of its enclosed pixels.
>> 
>> If you wisth to count zero-based the you have to redefine width and height.
>> ___
>> 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


___
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: math on widths doesn't add up

2019-06-14 Thread Dar Scott Consulting via use-livecode
When we apply math, we must map what we see to our mathematical models.  What 
we see is LiveCode.  The application of math is thus an interpretation. (The 
interpretation of calendar year or how-old-are-you might not apply.)

I do agree with you, except for the part that one has to redefine width and 
height. A delta does not depend on the offset.

If I create a line from 0,0 to 100,0; I get a line visible on the card, not a 
line just off the card. The LiveCode line is between the coordinates we are 
talking about, that is, a half pixel moved in from those, creating pixel 
coordinates off from what we are saying.

I can get the same thing with a rectangle of rect 0, 0, 101, 1. Well, if the 
border width is zero and the fill color is set.  This uses the coordinates we 
are talking about. The rectangle is filled.  

The one-pixel width of the line causes it to fill that space. If there is a 
1-pixel square as a brush and it went from 0.5 to 100.5, it would sweep out the 
same space as the rectangle

However, others might have a view, an interpretation, that also works. 



> On Jun 14, 2019, at 3:04 PM, hh via use-livecode 
>  wrote:
> 
> This is interestingly the same problem that made a lot of people believe
> two thousand years were full at the end of 1999/ beginning of 2000.
> Two thousand years were full at the END of 2000/ beginning of 2001:
> 
> Full year 1 has the left 0, the right 1 and the width = right-left = 1 year, 
> ...,
> full years 1 to 2000 have the left 0, the right 2000 and the width = 
> right-left = 2000 years.
> 
>> Dar S. wrote:
>> I like this interpretation. I don't think it is a popular view, but it makes 
>> sense to me.
>> I would change the range wording, though, to something like this:
>> Pixel 0 ranges from 0 to 1.
>> For example, the rect of a card has zeros.
>> Maybe it depends on whether one wants to draw pixels on the intersections of 
>> the lines
>> on the graph paper, or in between.
> 
> No, this is math, not an interpretation. If you agree that counting pixels is 
> one-based
> then there is no pixel 0.
> 
> Rect (0,0,0,0) has left 0, right 0, top 0, bottom 0, width 0 and height 0, 
> contains 0 pixels.
> In fact it is degenerated to the point (0,0).
> 
> Rect (0,0,1,1) is one pixel, the first pixel on your coordinate system.
> It has left 0, right 1, top 0, bottom 1 and width 1, height 1.
> 
> The width of a rect is the number of its pixel columns,
> the height of a rect is the number of its pixel rows,
> width*height of a rect is the number of its enclosed pixels.
> 
> If you wisth to count zero-based the you have to redefine width and height.
> ___
> 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: math on widths doesn't add up

2019-06-14 Thread Dar Scott Consulting via use-livecode
I tried to avoid the confusion by using the word pixel. I goofed somewhere.

I don't understand why you say "pixel 1". Other that that, I think we are 
saying the same thing.


> On Jun 14, 2019, at 3:54 PM, hh via use-livecode 
>  wrote:
> 
> @Dar.
> 
> Probably you wish with your post avoid the confusion between
> 
> = a math-point (x,y) which has no dimension, so cannot be drawn and
> 
> = a LC-point (x,y) which is (with a linewidth of 1) in fact a
> shorthand for the rect (x,y,x+1,y+1)= 1 pixel, which can be drawn.
> 
> So the LC-point (x,y) is (with a linewidth of 1) the pixel in column x+1
> and row y+1 of your screen/ coordinate system which has the rect 
> (x,y,x+1,y+1).
> 
> Rows and Columns count here one-based, so for example (with a linewidth of 1)
> LC-Point (0,0) = rect (0,0,1,1) = pixel 1 of your coordinate system.
> ___
> 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: math on widths doesn't add up

2019-06-14 Thread Dar Scott Consulting via use-livecode
When we apply math, we must map what we see to our mathematical models.  What 
we see is LiveCode.  The application of math is thus an interpretation. (The 
interpretation of calendar year or how-old-are-you might not apply.)

I do agree with you, except for the part that one has to redefine width and 
height. A delta does not depend on the offset.

If I create a line from 0,0 to 100,0; I get a line visible on the card, not a 
line just off the card. The LiveCode line is between the coordinates we are 
talking about, that is, a half pixel moved in from those, creating pixel 
coordinates off from what we are saying.

I can get the same thing with a rectangle of rect 0, 0, 101, 1. Well, if the 
border width is zero and the fill color is set.  This uses the coordinates we 
are talking about. The rectangle is filled.  

The one-pixel width of the line causes it to fill that space. If there is a 
1-pixel square as a brush and it went from 0.5 to 100.5, it would sweep out the 
same space as the rectangle

However, others might have a view, an interpretation, that also works. 



> On Jun 14, 2019, at 3:04 PM, hh via use-livecode 
>  wrote:
> 
> This is interestingly the same problem that made a lot of people believe
> two thousand years were full at the end of 1999/ beginning of 2000.
> Two thousand years were full at the END of 2000/ beginning of 2001:
> 
> Full year 1 has the left 0, the right 1 and the width = right-left = 1 year, 
> ...,
> full years 1 to 2000 have the left 0, the right 2000 and the width = 
> right-left = 2000 years.
> 
>> Dar S. wrote:
>> I like this interpretation. I don't think it is a popular view, but it makes 
>> sense to me.
>> I would change the range wording, though, to something like this:
>> Pixel 0 ranges from 0 to 1.
>> For example, the rect of a card has zeros.
>> Maybe it depends on whether one wants to draw pixels on the intersections of 
>> the lines
>> on the graph paper, or in between.
> 
> No, this is math, not an interpretation. If you agree that counting pixels is 
> one-based
> then there is no pixel 0.
> 
> Rect (0,0,0,0) has left 0, right 0, top 0, bottom 0, width 0 and height 0, 
> contains 0 pixels.
> In fact it is degenerated to the point (0,0).
> 
> Rect (0,0,1,1) is one pixel, the first pixel on your coordinate system.
> It has left 0, right 1, top 0, bottom 1 and width 1, height 1.
> 
> The width of a rect is the number of its pixel columns,
> the height of a rect is the number of its pixel rows,
> width*height of a rect is the number of its enclosed pixels.
> 
> If you wisth to count zero-based the you have to redefine width and height.
> ___
> 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: math on widths doesn't add up

2019-06-14 Thread hh via use-livecode
@Dar.

Probably you wish with your post avoid the confusion between

= a math-point (x,y) which has no dimension, so cannot be drawn and

= a LC-point (x,y) which is (with a linewidth of 1) in fact a
shorthand for the rect (x,y,x+1,y+1)= 1 pixel, which can be drawn.

So the LC-point (x,y) is (with a linewidth of 1) the pixel in column x+1
and row y+1 of your screen/ coordinate system which has the rect (x,y,x+1,y+1).

Rows and Columns count here one-based, so for example (with a linewidth of 1)
LC-Point (0,0) = rect (0,0,1,1) = pixel 1 of your coordinate system.
___
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: math on widths doesn't add up

2019-06-14 Thread hh via use-livecode
This is interestingly the same problem that made a lot of people believe
two thousand years were full at the end of 1999/ beginning of 2000.
Two thousand years were full at the END of 2000/ beginning of 2001:

Full year 1 has the left 0, the right 1 and the width = right-left = 1 year, 
...,
full years 1 to 2000 have the left 0, the right 2000 and the width = right-left 
= 2000 years.

> Dar S. wrote:
> I like this interpretation. I don't think it is a popular view, but it makes 
> sense to me.
> I would change the range wording, though, to something like this:
> Pixel 0 ranges from 0 to 1.
> For example, the rect of a card has zeros.
> Maybe it depends on whether one wants to draw pixels on the intersections of 
> the lines
> on the graph paper, or in between.

No, this is math, not an interpretation. If you agree that counting pixels is 
one-based
then there is no pixel 0.

Rect (0,0,0,0) has left 0, right 0, top 0, bottom 0, width 0 and height 0, 
contains 0 pixels.
In fact it is degenerated to the point (0,0).

Rect (0,0,1,1) is one pixel, the first pixel on your coordinate system.
It has left 0, right 1, top 0, bottom 1 and width 1, height 1.

The width of a rect is the number of its pixel columns,
the height of a rect is the number of its pixel rows,
width*height of a rect is the number of its enclosed pixels.

If you wisth to count zero-based the you have to redefine width and height.
___
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: math on widths doesn't add up

2019-06-14 Thread Dar Scott Consulting via use-livecode
I like this interpretation. I don't think it is a popular view, but it makes 
sense to me.

I would change the range wording, though, to something like this:
Pixel 0 ranges from 0 to 1.

For example, the rect of a card has zeros.

Maybe it depends on whether one wants to draw pixels on the intersections of 
the lines on the graph paper, or in between.


> On Jun 14, 2019, at 1:55 PM, hh via use-livecode 
>  wrote:
> 
> Nothing is wrong:
> If you have a row then left is the integer left of first pixel
> and right is the integer right of last pixel.
> 
> So left and right are the integers that limit the object, NOT pixel numbers.
> 
> As to your example:
> pixel 1 ranges from 0 to 1, ... pixel 12 ranges from 11 to 12.
> The left is 0, the right is 12, the width is 12=right-left.
> 
>> Richard H. wrote:
>> Playing around with a couple of things needing alignment, I’ve noticed that 
>> the math on widths and edges isn’t quite right.
>> For example, I have a boundary rect of width 12, with a left of 0 and a 
>> right of 12.
>> One of these is wrong . . . a width of 12 would go from 0 to 11; 0 to 12 is 
>> 13 pixels wide . . .
>> It seems that “right” actually means, “the pixel to the right of” . . .
> 
> 
> ___
> 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: math on widths doesn't add up

2019-06-14 Thread hh via use-livecode
Nothing is wrong:
If you have a row then left is the integer left of first pixel
and right is the integer right of last pixel.

So left and right are the integers that limit the object, NOT pixel numbers.

As to your example:
pixel 1 ranges from 0 to 1, ... pixel 12 ranges from 11 to 12.
The left is 0, the right is 12, the width is 12=right-left.

> Richard H. wrote:
> Playing around with a couple of things needing alignment, I’ve noticed that 
> the math on widths and edges isn’t quite right.
> For example, I have a boundary rect of width 12, with a left of 0 and a right 
> of 12.
> One of these is wrong . . . a width of 12 would go from 0 to 11; 0 to 12 is 
> 13 pixels wide . . .
> It seems that “right” actually means, “the pixel to the right of” . . .


___
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

math on widths doesn't add up

2019-06-14 Thread Dr. Hawkins via use-livecode

Playing around with a couple of things needing alignment, I’ve noticed that the 
math on widths and edges isn’t quite right.

For example, I have a boundary rect of width 12, with a left of 0 and a right 
of 12.

One of these is wrong . . . a width of 12 would go from 0 to 11; 0 to 12 is 13 
pixels wide . . .

It seems that “right” actually means, “the pixel to the right of” . . .
— 
Richard E. Hawkins, Esq.
The Hawkins Law Firm
3430 E. Flamingo Rd.
Suite 232
Las Vegas, NV  89121
(702) 508-8462

___
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: one computer, but not other, cannot use breakpoints of any type under 9.5.0_dp1

2019-06-14 Thread doc hawk via use-livecode
On Tue, Jun 11, 2019 at 1:13 PM JJS via use-livecode <
use-livecode@lists.runrev.com> wrote:

> try delete your preferences file and restart LC.
>
>
Thanks.

I ultimately did this this morning, but it always seems to take weeks to
get things back like aI had them

I tried copying the file from the other computer, but it ignored it . . .

-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: PlayStore and Tablets

2019-06-14 Thread Ralph DiMola via use-livecode
J,

Thanks. I'm going to start digging on this... My Customer can't have this.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay via use-livecode
Sent: Friday, June 14, 2019 1:09 PM
To: How to use LiveCode
Cc: J. Landman Gay
Subject: Re: PlayStore and Tablets

I see that on almost every app I download on my tablet. It started right
around the time Google started requiring the target version to be 26 so I
assumed it had to do with that.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software |
http://www.hyperactivesw.com On June 14, 2019 11:30:06 AM Ralph DiMola via
use-livecode  wrote:

> When I access the page of my app in Google Play using a tablet I get 
> the following message: "This app may not be optimized for your device" in
red.
> My app resizes to use all of a tablet's real-estate. I uploaded tablet 
> screenshots and use an icon of "xxxhdpi" size.
>
> Does anyone know how to solve this?
> Thanks!
>
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
>
>
>
> ___
> 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


___
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: Android - Different Builds

2019-06-14 Thread JJS via use-livecode

Yes i believe it works so too as Mark says.


@BR make sure that for your next release, that when now your highest 
versioncode is 15 for x86-64


the armv7a starts with 16

that's why i showed you the sequence as example.

you need to increase the versioncodes but with the lowest versioncode 
for the lowest architecture, i did it too and had no problem


so like this for your sequence if your highest used VC is 15 then:

Build                    VC

arm v7a                16 >next time --->20>next time--->24

arm64                    17>next time--->21--->next time--->25

X86                        18--->next time--->22--->next time--->26

x86-64                  19--->next time--->23--->next time--->27


and so on, you see the 64 builds need to be higher vc then the 32bits


Op 14-6-2019 om 10:33 schreef Mark Waddingham via use-livecode:

On 2019-06-14 00:41, Sannyasin Brahmanathaswami via use-livecode wrote:

Aloha Jerry, I think I have done it correctly

1)
I have the four builds in one release
2)
Native platforms --  armeabi-v7a - version code 14
Native platforms -- x86_64 - version code 9
Native platforms --  x86   - version code 8
Native platforms -- arm64-v8a - version code 7

I still get ERROR
=
1 message for APK 7
Fully shadowed APK

Problem:
This APK will not be served to any users because it is completely


I wonder if the reason this didn't work is because you have the 
version code

for armv7 > that for arm64...

I suspect the play store will choose the highest version coded APK 
that will
run on the target device. As ARMv7 APKs will run on devices which can 
run ARM64,
it will choose the ARMv7 in preference (as it is version code 14, 
which is greater

than 7) and thus 'completely shadow' the ARM64 APK.

Upshot: probably best to make sure ARM64 APKs have higher version code 
than
ARM7 ones (the same is true of x86-64 and x86 - but in that case 
you've already
got version-code-of(x86-64) > version-code-of(x86) which is why you 
aren't getting

a shadowed error for those)

Warmest Regards,

Mark.



___
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: PlayStore and Tablets

2019-06-14 Thread J. Landman Gay via use-livecode
I see that on almost every app I download on my tablet. It started right 
around the time Google started requiring the target version to be 26 so I 
assumed it had to do with that.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On June 14, 2019 11:30:06 AM Ralph DiMola via use-livecode 
 wrote:


When I access the page of my app in Google Play using a tablet I get the 
following message: "This app may not be optimized for your device" in red. 
My app resizes to use all of a tablet's real-estate. I uploaded tablet 
screenshots and use an icon of "xxxhdpi" size.


Does anyone know how to solve this?
Thanks!

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net



___
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


PlayStore and Tablets

2019-06-14 Thread Ralph DiMola via use-livecode
When I access the page of my app in Google Play using a tablet I get the 
following message: "This app may not be optimized for your device" in red. My 
app resizes to use all of a tablet's real-estate. I uploaded tablet screenshots 
and use an icon of "xxxhdpi" size.

Does anyone know how to solve this?
Thanks!

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net



___
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: OT - Could someone with an Android phone do me a favour and test my website?

2019-06-14 Thread Matthias Rebbe via use-livecode
Thanks to all for their reports.

So it seems my website is okay and the problem is on the customer´s side.

Regards,

Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de 
https://winsignhelper.dermattes.de 

> Am 14.06.2019 um 10:54 schrieb Richmond Mathewson via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> Looks fine on ASUS.
> 
> Richmond.
> 
> 
> On Fri, Jun 14, 2019, 5:14 AM J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com > wrote:
> 
>> All is fine on both my Pixel and Huawei MediaPad m5.
>> 
>> --
>> Jacqueline Landman Gay | jac...@hyperactivesw.com 
>> 
>> HyperActive Software | http://www.hyperactivesw.com 
>> 
>> On June 13, 2019 3:23:31 PM Matthias Rebbe via use-livecode
>> mailto:use-livecode@lists.runrev.com>> wrote:
>> 
>>> Hi,
>>> 
>>> yesterday i´ve received an email from a user who informed me that my
>>> website was not completely visible on his Samsung S7 Edge phone.
>>> Better said, some text at the bottom of some pages (e.g. pages
>> impressum,
>>> disclaimer)  was not visible.
>>> I could replicate this even on my iPhone and modified my website. After
>>> this modification i am able to see all text on all pages with an iPhone
>> and
>>> a Samsung S9.
>>> 
>>> Unfortunately my customer still experience the problem.
>>> 
>>> I would be very grateful if someone with an Android phone could test my
>>> site at https://instamaker.dermattes.de  <
>> https://instamaker.dermattes.de/ >
>>> and would tell me, if all text was displayed or not.
>>> 
>>> The last words of page impressum should be '32312 Lübbecke' and the last
>>> words of page disclaimer should be 'means of spam mail'.
>>> 
>>> Regards
>>> 
>>> Matthias
>>> 
>>> .
>>> 
>>> 
>>> Matthias Rebbe
>>> 
>>> free tools for Livecoders:
>>> https://instamaker.dermattes.de  
>>> >
>>> https://winsignhelper.dermattes.de  
>>> >
>>> ___
>>> 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 
>> 
> ___
> 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 
> 


Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de 
https://winsignhelper.dermattes.de 
___
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: OT - Could someone with an Android phone do me a favour and test my website?

2019-06-14 Thread Richmond Mathewson via use-livecode
Looks fine on ASUS.

Richmond.


On Fri, Jun 14, 2019, 5:14 AM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> All is fine on both my Pixel and Huawei MediaPad m5.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On June 13, 2019 3:23:31 PM Matthias Rebbe via use-livecode
>  wrote:
>
> > Hi,
> >
> > yesterday i´ve received an email from a user who informed me that my
> > website was not completely visible on his Samsung S7 Edge phone.
> > Better said, some text at the bottom of some pages (e.g. pages
> impressum,
> > disclaimer)  was not visible.
> > I could replicate this even on my iPhone and modified my website. After
> > this modification i am able to see all text on all pages with an iPhone
> and
> > a Samsung S9.
> >
> > Unfortunately my customer still experience the problem.
> >
> > I would be very grateful if someone with an Android phone could test my
> > site at https://instamaker.dermattes.de <
> https://instamaker.dermattes.de/>
> > and would tell me, if all text was displayed or not.
> >
> > The last words of page impressum should be '32312 Lübbecke' and the last
> > words of page disclaimer should be 'means of spam mail'.
> >
> > Regards
> >
> > Matthias
> >
> > .
> >
> >
> > Matthias Rebbe
> >
> > free tools for Livecoders:
> > https://instamaker.dermattes.de 
> > https://winsignhelper.dermattes.de 
> > ___
> > 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
___
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: Android - Different Builds

2019-06-14 Thread Mark Waddingham via use-livecode

On 2019-06-14 00:41, Sannyasin Brahmanathaswami via use-livecode wrote:

Aloha Jerry, I think I have done it correctly

1)
I have the four builds in one release
2)
Native platforms --  armeabi-v7a- version code 14
Native platforms -- x86_64   - version code 9
Native platforms --  x86- version code 8
Native platforms -- arm64-v8a   - version code 7

I still get ERROR
=
1 message for APK 7
Fully shadowed APK

Problem:
This APK will not be served to any users because it is completely


I wonder if the reason this didn't work is because you have the version 
code

for armv7 > that for arm64...

I suspect the play store will choose the highest version coded APK that 
will
run on the target device. As ARMv7 APKs will run on devices which can 
run ARM64,
it will choose the ARMv7 in preference (as it is version code 14, which 
is greater

than 7) and thus 'completely shadow' the ARM64 APK.

Upshot: probably best to make sure ARM64 APKs have higher version code 
than
ARM7 ones (the same is true of x86-64 and x86 - but in that case you've 
already
got version-code-of(x86-64) > version-code-of(x86) which is why you 
aren't getting

a shadowed error for those)

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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