Hi Jacque,
Scott made many of the same good points as you did - so I won't
replicate my replies here.
On 06/04/2020 05:20, J. Landman Gay via use-livecode wrote:
On April 5, 2020 8:39:15 PM Alex Tweedly via use-livecode
wrote:
1. xTalk features just don't work, or work totally inadequatel
Bob Sneidar wrote:
> I’m curious though if a library could be created so that a handler for
> a mobile message (let’s say a touch message) could “translate” into a
> desktop message? In this way, the app on the mobile would send a
> mouseUp message to the target.
Why not? Most developers I know
Touch messages already send duplicate mouse messages. In fact, unless you
need two-finger zooming, you don't need touch handlers at all. I only use
standard mouse handlers generally because they wotk on both mobile and desktop.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive So
I think that would kill the Apple Desktop OS.
Bob S
On Apr 6, 2020, at 6:37 AM, Paul Dupuis via use-livecode
mailto:use-livecode@lists.runrev.com>> wrote:
Apple is absolutely working towards iOS and macOS being highly similar.
However, if you're hoping that brings increased simplicity of appl
There’s the rub I think. For RunRev (is the company still called that?) to make
what mobile objects they can universal, and leave the others as is would then
create a situation where developers would have to know what controls were
universal, and which were Mobile/Desktop only. It just adds anot
On 4/5/2020 10:48 PM, JB via use-livecode wrote:
The question is why don’t they make them compatible? Is their some
kind of FCC regulation that prevents Apple from using phone apps on
the desktop? Back in the HyperCard days there was hyperDialer and
I really liked it a lot but I think the compa
On April 5, 2020 8:39:15 PM Alex Tweedly via use-livecode
wrote:
1. xTalk features just don't work, or work totally inadequately (e.g.
scrolling fields).
Somewhat true. LC made a start by adding widgets you can drop onto the
stack to create native mobile buttons and fields, but I'd like to
It seems if Apple made the iOS compatible with the desktop it would
solve a lot of problems.
The question is why don’t they make them compatible? Is their some
kind of FCC regulation that prevents Apple from using phone apps on
the desktop? Back in the HyperCard days there was hyperDialer and
I
As I see it, there are 4 broad areas of problem for LC on mobile OSes.
The first two have been well described earlier in the thread and should
just be fixed.
1. xTalk features just don't work, or work totally inadequately (e.g.
scrolling fields).
2. Failure in cross-platform equivalence.
T
Richard:
> Exactly. Reducing the differences between runtime and development
> is a cornerstone of The xTalk Way.
[...]
> Suffice to say politely and succinctly: a decade later, LC for
> mobile remains half-baked compared to what it could be, compared
> to The xTalk Way that rests at the heart
J. Landman Gay wrote:
> On 4/5/20 1:12 PM, Richard Gaskin via use-livecode wrote:
>
>> Once I saw that the scroller works well on the field content I've
>> been working with, I added a routine to my mobile lib that
>> automatically removes the vScrollbar from any non-editable field
>> that has on
What I wrote here originally:
> I've switched over to trying a group set as a container and setting
> the field itself to scrolling layermode. I haven't tried it yet on
> mobile but we'll see.
is wrong, the field inside the container group uses dynamic layermode. Scrolling layermode
doesn
On 4/5/20 1:12 PM, Richard Gaskin via use-livecode wrote:
Once I saw that the scroller works well on the field content I've been working with, I added a
routine to my mobile lib that automatically removes the vScrollbar from any non-editable field
that has one, and instantiates a matching scrol
J. Landman Gay wrote:
> On April 5, 2020 12:46:19 PM Richard Gaskin wrote:
>
>> I've had such good luck so far with using scrollers directly on
>> fields that it never occurred to me that accelerated rendering
>> would be useful for field objects.
>
> If you're using a vScrollbar then no problem.
On April 5, 2020 12:46:19 PM Richard Gaskin via use-livecode
wrote:
I've had such good luck so far with using scrollers directly on fields
that it never occurred to me that accelerated rendering would be useful
for field objects.
If you're using a vScrollbar then no problem. But for swipe
J. Landman Gay wrote:
> @Richard, when developing for desktop you don't need the enclosing
> group, but on mobile you do because acceleratedRendering only applies
> to groups. Without it you can't achieve smooth scrolling. I wish we
> could just set a field to scrolling layermode, it would sure m
Thanks guys. I did remember there was a limit but for some reason thought
it was only for the width of a line. I've switched over to trying a group
set as a container and setting the field itself to scrolling layermode. I
haven't tried it yet on mobile but we'll see.
@Richard, when developing
J. Landman Gay wrote:
> I have a field that reports a formattedheight of 125396. I want to
> extend it to full height for use inside an enclosing scrolling group.
I see that method used in the Lesson on using a scroller for text as
well, but I've never understood why. What is the advantage of
On 4/5/2020 1:16 AM, J. Landman Gay via use-livecode wrote:
I have a field that reports a formattedheight of 125396. I want to
extend it to full height for use inside an enclosing scrolling group.
But when I try to set the height to the formattedHeight, I get an
error: Value is not a number.
I have a field that reports a formattedheight of 125396. I want to extend it to full height for
use inside an enclosing scrolling group. But when I try to set the height to the
formattedHeight, I get an error: Value is not a number.
If I try to set its height in the property inspector, it rever
20 matches
Mail list logo
