Re: Ken Burns Effects - acceleratedRendering

[Sannyasin Brahmanathaswami via use-livecode]

Monte Goulding wrote:

At some point in the future we may support applying transformations to 
dynamic layerMode objects (changing size and perhaps location) which would mean 
Ken Burn effect would be done by the GPU. I suspect that’s a fair way off and 
would definitely involve some serious Mark time ;-)
  
BR: that answers the question. So I'll need to learn on new language (html5) 
and run it in a browser. :-(
  


___
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: slow slower slowest scroll on Android

[Sphere via use-livecode]

This line: "Guess i did investigate good enough on the ARM versions."
should be: "Guess i did NOT investigate good enough on the ARM 
versions." forgot the NOT


request made: https://quality.livecode.com/show_bug.cgi?id=22118

Sphere via use-livecode schreef op 2019-05-30 19:09:

Thank you Mark , that makes it clear.

Guess i did investigate good enough on the ARM versions.


The arch index is a good idea, somtehing similair is also what i saw
inthe Google explanation on multiple APK's to have a version nr where
the position of the nr identifies what version and for what
architecture it is, like also commonly is used with serial nr's from
tv's for example.

I will create a feature request.

Thanks very much.

Best regards,

Jerry

Mark Waddingham via use-livecode schreef op 2019-05-30 18:09:

On 2019-05-30 19:54, Sphere via use-livecode wrote:

Perhaps for the older ARMv6 devices we may need 5 versions, but like
you said Google play will push the best APK option for the device. 
And

yes every APK needs to have a different/higher Version Code. And keep
in check which Version Code you used for which type of APK.


LiveCode only supports Android 4.x and above, and all devices which 
run
4.x have at the very least an ARMv7 processor - so there isn't any 
need
for a ARMv6 device build anymore (hence why it has been removed in 
9.5).



Is it possible as feature, that there can be a checkbox added, so you
can choose to have separate builds instead of one multiple build when
more then 1 build is chosen?


That would be quite a useful thing to have - perhaps a check-box which
'builds separate APKs' on the standalone settings pane. It could also
do something to derive a new versionCode (they all have to be 
different).

e.g.

APK-versionCode = S/B-specified-versionCode * 10 + arch-index

   arch-index = 0 (ARMv7), 1 (ARM64), 2 (x86), 3 (x86-64)

That would save having to specify (by hand) several different 
versionCodes

for each build.

Could you file an enhancement request for such an option, and we can 
see what

we can do.

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: slow slower slowest scroll on Android

[Sphere via use-livecode]

Thanks,
i will go fiddling around to see if it works and else no glow :)

Regards,
Jerry

Mark Waddingham via use-livecode schreef op 2019-05-30 18:13:

On 2019-05-29 23:10, JJS via use-livecode wrote:

Wow, what a difference does it make.


*Phew*


Turned off the nice border glow around the grid, turned border off and
set it to zero (the latter won't make difference i guess.)


You could experiment by fiddling with the properties of control
"dgBackground" of your
DataGrid group. From memory, I believe that is a graphic, which sits
behind everything
else (within the Datagrid). At the very least, you should be able to
get the border
back, if not the glow (as it would be clipped away by the datagrid's
top-level group).

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: slow slower slowest scroll on Android

[Sphere via use-livecode]

Thank you Mark , that makes it clear.

Guess i did investigate good enough on the ARM versions.


The arch index is a good idea, somtehing similair is also what i saw 
inthe Google explanation on multiple APK's to have a version nr where 
the position of the nr identifies what version and for what architecture 
it is, like also commonly is used with serial nr's from tv's for 
example.


I will create a feature request.

Thanks very much.

Best regards,

Jerry

Mark Waddingham via use-livecode schreef op 2019-05-30 18:09:

On 2019-05-30 19:54, Sphere via use-livecode wrote:

Perhaps for the older ARMv6 devices we may need 5 versions, but like
you said Google play will push the best APK option for the device. And
yes every APK needs to have a different/higher Version Code. And keep
in check which Version Code you used for which type of APK.


LiveCode only supports Android 4.x and above, and all devices which run
4.x have at the very least an ARMv7 processor - so there isn't any need
for a ARMv6 device build anymore (hence why it has been removed in 
9.5).



Is it possible as feature, that there can be a checkbox added, so you
can choose to have separate builds instead of one multiple build when
more then 1 build is chosen?


That would be quite a useful thing to have - perhaps a check-box which
'builds separate APKs' on the standalone settings pane. It could also
do something to derive a new versionCode (they all have to be 
different).

e.g.

APK-versionCode = S/B-specified-versionCode * 10 + arch-index

   arch-index = 0 (ARMv7), 1 (ARM64), 2 (x86), 3 (x86-64)

That would save having to specify (by hand) several different 
versionCodes

for each build.

Could you file an enhancement request for such an option, and we can 
see what

we can do.

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: Setting mobile scroller hScroll fails

[J. Landman Gay via use-livecode]

On 5/29/19 6:22 PM, Monte Goulding via use-livecode wrote:

The max scroll will be the formattedWidth of the group - the width of the group 
unless you have unboundedHScroll true. I_think_  if it’s false then the engine 
will automagically clamp that though.


I tried that but it didn't scroll to the far edge, so I set it back to 
using the formattedwidth of the group as the hscroll.


I'll try to set up a sample stack later and put it in the bug database.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Setting mobile scroller hScroll fails

[J. Landman Gay via use-livecode]

Whenever someone says "math" my eyes kind of glaze over and my brain 
shuts off. I'm using your sample script to resize the group so it 
expands to the screen edges, which works great. I'm not sure how to 
change the scroller so it works with that setup, but I did wonder if 
scrollers were limited to the card size and that might be why it wasn't 
working.


I think I'll write it up as Monte suggested, though I'm not sure whether 
to call it a bug, a feature request, or just impossible.



On 5/29/19 5:29 PM, Brian Milby via use-livecode wrote:

I think it is going to take some math but the scroller should be set for the 
area within the card rect since the areas left/right are not going to be 
responsive to the scroller.

Thanks,
Brian
On May 29, 2019, 2:01 PM -0500, J. Landman Gay via use-livecode 
, wrote:

Thanks Monte, I did over-summarize. I'm not sure why it's going wrong,
but it sounds like it's something I'm doing. I have a standard
"createScroller" handler that I've been using for years, but I've never
had to set the hScroll before. It's always been zero.

In this case, I set the hScroll of the group to the formattedWidth of
the group, which may be wrong. The engine seems to compensate though and
sets the scroll as far as it should go. Then I call "createScroller" and
pass the name of the group. The handler:

command createScroller pName
-- pName = the long ID of a grp
put the rect of control pName into tRect
put the hScrollBar of control pName into tHScroller
put the vScrollBar of control pName into tVScroller
put the hScroll of control pName into tHScroll
put the vScroll of control pName into tVScroll
set the hScrollBar of control pName to false -- remove fld scrollbars
on mobile
set the vScrollBar of control pName to false
mobileControlCreate "scroller", pName
mobileControlSet pName, "rect", tRect
put ("0,0," & (the formattedwidth of control pName) & "," & the
formattedheight of control pName) into tContentRect
mobileControlSet pName, "contentRect", tContentRect
mobileControlSet pName, "hScroll", 0
mobileControlSet pName, "vScroll", 0
mobileControlSet pName, "hIndicator", tHScroller
mobileControlSet pName, "vIndicator", tVScroller
mobileControlSet pName, "hScroll", tHScroll
mobileControlSet pName, "vScroll", tVScroll
mobileControlSet pName, "visible", true
end createScroller

I initialize both the group and the scroller to 0 before doing anything
else, because when I wrote it I couldn't get them to align correctly
otherwise. I should also probably mention that I'm using fullscreenMode
"showAll" and the group is expanded beyond the borders of the card to
fill the screen; i.e., it probably has a negative left margin and a
wider right margin. When the scroller finally does scroll (after
resetting itself) it scrolls too far at the left side by the number of
pixels between the screen left and the card left, and cuts off the same
amount on the right side.

Can you see what I should change?


On 5/28/19 6:33 PM, Monte Goulding via use-livecode wrote:

Hi Jacque

I’m thinking you are over summarising what you are doing here. For example, I 
expect you mean to set the hScroll of the group to the formattedWidth - the 
width of the group. Are you setting the contentRect appropriately before 
setting the hScroll of the scroller?

Cheers

Monte


On 27 May 2019, at 8:03 am, J. Landman Gay via use-livecode 
 wrote:

I want to verify this is a bug and not just me.

I'm creating a mobile scroller over a group. I want the group to initially 
display with its hScroll all the way to the right. I'm doing this:

zoom the group out to fill the screen
create a mobile scroller with the same rect
set the hScroll of the group to its formattedWidth
set the hScroll of the scroller to the scroll of the group

If I insert an answer command to show the scroller's hScroll it reports the 
correct number. But the scroller always acts like its scroll is 0, and it won't 
scroll to the left at all. But scrolling it to the right zaps both it and the 
group to zero and after that it scrolls normally.

I've also tried not setting the group's scroll and just setting the scroller 
alone, thinking it might trigger the scrollerDidScroll handler, but it doesn't.

If I don't set any hScroll at all on either the group or the scroller, all is 
well.

Has anyone else seen this?

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.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




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive 

Re: slow slower slowest scroll on Android

[Mark Waddingham via use-livecode]

On 2019-05-29 23:10, JJS via use-livecode wrote:

Wow, what a difference does it make.


*Phew*


Turned off the nice border glow around the grid, turned border off and
set it to zero (the latter won't make difference i guess.)


You could experiment by fiddling with the properties of control 
"dgBackground" of your
DataGrid group. From memory, I believe that is a graphic, which sits 
behind everything
else (within the Datagrid). At the very least, you should be able to get 
the border
back, if not the glow (as it would be clipped away by the datagrid's 
top-level group).


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

Re: slow slower slowest scroll on Android

[Mark Waddingham via use-livecode]

On 2019-05-30 19:54, Sphere via use-livecode wrote:

Perhaps for the older ARMv6 devices we may need 5 versions, but like
you said Google play will push the best APK option for the device. And
yes every APK needs to have a different/higher Version Code. And keep
in check which Version Code you used for which type of APK.


LiveCode only supports Android 4.x and above, and all devices which run
4.x have at the very least an ARMv7 processor - so there isn't any need
for a ARMv6 device build anymore (hence why it has been removed in 9.5).


Is it possible as feature, that there can be a checkbox added, so you
can choose to have separate builds instead of one multiple build when
more then 1 build is chosen?


That would be quite a useful thing to have - perhaps a check-box which
'builds separate APKs' on the standalone settings pane. It could also
do something to derive a new versionCode (they all have to be 
different).

e.g.

APK-versionCode = S/B-specified-versionCode * 10 + arch-index

   arch-index = 0 (ARMv7), 1 (ARM64), 2 (x86), 3 (x86-64)

That would save having to specify (by hand) several different 
versionCodes

for each build.

Could you file an enhancement request for such an option, and we can see 
what

we can do.

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

Re: slow slower slowest scroll on Android

[Sphere via use-livecode]

Thank you Ralph and Monte,


i've read some things about multiple APK's on Google dev. "Lucky" we 
don't need to use the Google signing, it's optional. We can just use the 
Java keystore.


There is also mentioned what you say Ralph in respect of the different 
cpu and other possible dependencies.


Perhaps for the older ARMv6 devices we may need 5 versions, but like you 
said Google play will push the best APK option for the device. And yes 
every APK needs to have a different/higher Version Code. And keep in 
check which Version Code you used for which type of APK.


Also when Google signing is used there is an option to have dependencies 
build, but probably that is only useful for users of Android Studio.So 
then only the parts being needed are installed, as far as i understood 
it.



Thanks Monte for confirming it, that it will push the build upon the 
target architecture.


Is it possible as feature, that there can be a checkbox added, so you 
can choose to have separate builds instead of one multiple build when 
more then 1 build is chosen?



Indeed that would be a nice addition you proposed.


Regards,

Jerry

Monte Goulding via use-livecode schreef op 2019-05-29 23:27:
On 30 May 2019, at 7:10 am, JJS via use-livecode 
 wrote:


What will it push to the phone if all 4 options are selected? does it 
check what is connected?


Yes the deploy library (Test button) uses an adb command to detect the
target device architecture and just builds that no matter what you
have selected in the standalone settings. This means you can leave
armv7 and arm64 selected for release builds and the Test button will
deploy x86 if you are targeting an x86 emulator.

Note I just created this enhancement request to add the target
architecture in parenthesis after the target name in the menu.
https://quality.livecode.com/show_bug.cgi?id=22114


Cheers

Monte
___
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: FFI & VLC Player

[Tom Glod via use-livecode]

Ok Paul...thank you dooley noted.


On Thu, May 30, 2019 at 11:50 AM Paul Dupuis via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I am current dealing with LiveCode media headaches such as:
>
> 1) Inconsistency with media file formats supported between OSX AVF and
> Microsoft DirectShow
> 2) Very limited set of formats for DirectShow without additional 3rd
> party codec packs installed (we use LAV Filters)
> 3) Inconsistencies with the playRate property between platforms and
> between codecs on Windows.
> 4) Controller bar irregularities in rendering and function
>
> I would really like a solution that just works. To the extent we could,
> Researchware would help with any effort that might lead to a better
> solution for media playback in LiveCode.
>
> For our apps we need the following media properties to work:
> currentTime, startTime, endTime, playSelection, playRate (with playRates
> from -n.n to 0 to +n.n) for both audio and video media.
>
> Paul Dupuis
> Cofounder
> Researchware, Inc.
>
> On 5/30/2019 11:10 AM, Tom Glod via use-livecode wrote:
> > Thanks Roland thats good to know, ... I have tentatively scheduled
> further
> > investigation of this for July.  If I decide to start I might ask the
> > community for help and try for a team effort.  While I look forward to
> > opening up a whole new world of possibilities with FFI, I'm not looking
> > forward to the learning curve...C++ gives me the headaches. :)
> >
> >
> > On Thu, May 30, 2019 at 8:00 AM R.H. via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> >> I would be very happy if VLC could be used in LC and if we had high
> level
> >> access to those functions on ALL platforms. It would be a huge
> >> contribution. I would pay for it.
> >>
> >> Imagine the number of add-ons that could easily be made using LC.
> >>
> >> Roland
> >> ___
> >> 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: Seeking confirmation of a bug...

[Bob Sneidar via use-livecode]

:-)

> On May 29, 2019, at 08:46 , J. Landman Gay via use-livecode 
>  wrote:
> 
> Read the release notes. You'll get a much better view of the number of bug 
> fixes in each version. The last one had 2 pages of fixes.
> 
> The team can both walk and chew gum, they're talented that way.
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.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: FFI & VLC Player

[Paul Dupuis via use-livecode]

I am current dealing with LiveCode media headaches such as:

1) Inconsistency with media file formats supported between OSX AVF and 
Microsoft DirectShow
2) Very limited set of formats for DirectShow without additional 3rd 
party codec packs installed (we use LAV Filters)
3) Inconsistencies with the playRate property between platforms and 
between codecs on Windows.

4) Controller bar irregularities in rendering and function

I would really like a solution that just works. To the extent we could, 
Researchware would help with any effort that might lead to a better 
solution for media playback in LiveCode.


For our apps we need the following media properties to work: 
currentTime, startTime, endTime, playSelection, playRate (with playRates 
from -n.n to 0 to +n.n) for both audio and video media.


Paul Dupuis
Cofounder
Researchware, Inc.

On 5/30/2019 11:10 AM, Tom Glod via use-livecode wrote:

Thanks Roland thats good to know, ... I have tentatively scheduled further
investigation of this for July.  If I decide to start I might ask the
community for help and try for a team effort.  While I look forward to
opening up a whole new world of possibilities with FFI, I'm not looking
forward to the learning curve...C++ gives me the headaches. :)


On Thu, May 30, 2019 at 8:00 AM R.H. via use-livecode <
use-livecode@lists.runrev.com> wrote:


I would be very happy if VLC could be used in LC and if we had high level
access to those functions on ALL platforms. It would be a huge
contribution. I would pay for it.

Imagine the number of add-ons that could easily be made using LC.

Roland
___
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: FFI & VLC Player

[Tom Glod via use-livecode]

Thanks Roland thats good to know, ... I have tentatively scheduled further
investigation of this for July.  If I decide to start I might ask the
community for help and try for a team effort.  While I look forward to
opening up a whole new world of possibilities with FFI, I'm not looking
forward to the learning curve...C++ gives me the headaches. :)


On Thu, May 30, 2019 at 8:00 AM R.H. via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I would be very happy if VLC could be used in LC and if we had high level
> access to those functions on ALL platforms. It would be a huge
> contribution. I would pay for it.
>
> Imagine the number of add-ons that could easily be made using LC.
>
> Roland
> ___
> 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

FFI & VLC Player

[R.H. via use-livecode]

I would be very happy if VLC could be used in LC and if we had high level
access to those functions on ALL platforms. It would be a huge
contribution. I would pay for it.

Imagine the number of add-ons that could easily be made using LC.

Roland
___
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