Re: At this point, what's the shortest path to an iOS/Android app?

[J. Landman Gay via use-livecode]

On December 18, 2017 9:32:42 PM Sannyasin Brahmanathaswami via use-livecode 
 wrote:



c) once you accept the above, they you are good to go with

on preopenstack
   wait 200 milliseconds with messages
   set the fullscreenmode of this stack to "showAll"
end preopenstack


Just for the record, I've never needed the wait command. There's something 
about Swami's fairly complex setup that requires it but for a more 
straightforward implementation it doesn't seem necessary.


I do like fullscreenmode though. It really does cut down on development time.

--
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: At this point, what's the shortest path to an iOS/Android app?

[Brian Milby via use-livecode]

The demo stack on the thread I mentioned lets you switch between the
different fullscreen modes to see how it impacts the display. You could add
a background image as suggested to see how that worked too.
On Mon, Dec 18, 2017 at 9:31 PM Sannyasin Brahmanathaswami via use-livecode
 wrote:

> Geoff
>
> IMHO your shortest path will be
>
> a) forget about fully responsive, in terms of trying to emulate  html5 web
> design. IMHO this whole "must be responsive" is a huge sidetrack from
> content development…someone spends days and days and ends up with a few pix
> and a little bit of text and "it's so cool… yeah.. it shrinks and expand so
> beautifully!" but nothing of substance. You will do better focusing on the
> game, content and game play UX instead of wasting time dealing with "on
> resize…"
>
> b) most games we are seeing on mobile are fixed to one orientation. This
> way you can "go crazy" with your design and not worry about "what happens
> if the user turns their phone sideways (or upright)"  .e.g. even apple does
> not respond to orientation change in it settings module. Monument Valley
> (awesomely beautiful) is portrait only… period. other games are landscape
> only. period.
>
> c) once you accept the above, they you are good to go with
>
>
> on preopenstack
>wait 200 milliseconds with messages
>set the fullscreenmode of this stack to "showAll"
> end preopenstack
>
> and your stack *will* be responsive for the screen size, assuming you
>
> a) work in the "safe zone"
> b) are willing to accept some letter boxing.
> c) or just use a large background and then on some screens all your
> significant content will be constrained to the central horizontal safe zone
> (on landscape) or vertical (on portrait)   but still look lovely.
>
> depending on the kinds of controls and overall look you may find one of
> these others works for you
>
> set the fullscreenmode of stack to
> {empty|"exactFit"|"letterbox"|"noBorder"|"noScale"|"showAll"}
>
> Each of these has its own caveats, I'm most familiar with showAll, but I
> think Randy is using exactFit…
> I hope others jump in here to discuss the differences/options..
>
> But the above is, I think the fastest way to get to where you want to be
> without messing with responsive geometry.
>
> Of course I can hear some who will jump in and say  "it's not that hard to
> roll your own." True, but depends on how many hours you want to put in on
> "resize stack" when that same mental re-estate could be going to building
> the game play? If you lock into portrait (or landscape), set a background
> image/grc to 1024 X 1024  and center that… but make your stack  736 X 414
> (or 414 X 736) you and use fullscreenMode ShowAll, you can be deploying
> successfully to pretty much any device in 30 minutes…
>
> in the end there's no way around iterations, test, deploy on device(s) and
> try again.
>
> just two mangos from Hawaii…
>
>
>
>
> On 12/15/17, 11:00 AM, "use-livecode on behalf of Geoff Canyon via
> use-livecode"  use-livecode@lists.runrev.com> wrote:
>
> Is there a ready-made shell that people prefer that I should copy the
> elements of the app into? Or is there a mobile-specific library that I
> should be copying into the app?
>
> What do people prefer to use at this point?
>
> ___
> 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: Versions of LC and Xcode

[Sannyasin Brahmanathaswami via use-livecode]

Hmmm I seem to have gotten myself into the same fix as Ben.

" Now that I have updated to LC 9.0 DP-10 and LC
8.1.8 stable, nothing can build (except 8.1.6 stable - which unfortunately 
doesn't like the widgets in my stack!)."

I'm on High Sierra 10.13.6, Xcode 9.1 and LC is telling me I don't have the 
required SDK

@Ralph: I should start saving the old XCodes as you describe.

so what now? Can we build for iOS on 9 dp 10 and if so, how?

I’ll go and re-download the previous Xcode 9 from the developer portal… see it 
that helps.

BR

 

 

On 12/6/17, 11:36 AM, "use-livecode on behalf of Ralph DiMola via use-livecode" 
 wrote:

#1 below==>The shared prefs is a problem. I see the same thing. Different 
prefs for each version would solve this. When a new version is started for the 
first time the prefs from the last version in the series(if any) should be 
copied to the new version prefs file. But the rub is... if you change some 
other prefs and go to another version the you lose the change.
#2 below==>True... I always keep the Xcode version to build from in the 
applications folder and name it xcode.app. I put the other versions into 
another folder. When I upgrade Xcode I move the most recent version into my 
"OtherXcodeVersions" folder and rename it with the version number. I then 
download and install the new version into the applications folder. Of course I 
have to go into the LC prefs and fix the Xcode versions. The hardwired path to 
/Applications/Xcode.app should come from the prefs. Radio buttons in the Xcode 
prefs to indicate==> "Build using tools in this version would solve this.
#3 below==> I agree the docs need to be updated matrix whenever a new 
Xcode/Mac/LC version is released. Even if LC does not support a particular 
combination it should be documented.

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 Ben Rubinstein via use-livecode
Sent: Wednesday, December 06, 2017 4:16 PM
To: Use LiveCode
Cc: Ben Rubinstein
Subject: Versions of LC and Xcode

This continues to be a major source of friction.

Once again all my versions of LiveCode seem to have been reset so that they 
can't find a version of Xcode they like. (At any time I am probably switching 
between (or have simultaneously open) four version of LC: LC 6.7.11; the latest 
stable version of 8; the latest 8 RC or sometimes DP; the latest DP of 9. 
Admittedly I'm not building iOS apps from 6.7.11.)

I think that there are two main problems:

1) Because preferences are shared between versions of LiveCode. I believe 
it is the case than when switching between versions of LiveCode, if the mobile 
support preferences are opened in a version of LC which doesn't play nice with 
the selected version of Xcode, that path is deleted; so that next time the 
version of LC which was previously happy is opened, the path to Xcode is gone. 
The behaviour may be a little more subtle than this, but I believe 
something along these lines is correct.

2) Something somewhere along the line of building apps seems to have a 
hardwired path to /Applications/Xcode.app; so that while I may be able to 
maintain a set of different Xcodes in separate folders or separately named, 
LiveCode won't entirely work this way.

So currently I have XCode 8.3.3 as the 'canonical' version, probably 
because I was using LiveCode 9.0 DP-9. Now that I have updated to LC 9.0 DP-10 
and LC
8.1.8 stable, nothing can build (except 8.1.6 stable - which unfortunately 
doesn't like the widgets in my stack!).

3) A third problem: I now want to start using LC 8.1.8, the latest stable 
version; what version of Xcode does it use on Mas OS 10.12? According to 
https://livecode.com/resources/support/ask-a-question/ :

> LiveCode 8.1.8 RC-2 – Xcode 7.2 -Mac OS 10.10 – iOS 9.2 LiveCode 8.1.8 
> RC-2 – Xcode 8.2 -Mac OS 10.11 – iOS 10.2 LiveCode 8.1.8 RC-2 – Xcode 
> 9.1 -Mac OS 10.12.6+ – iOS 11.1
> 
> LiveCode 8.2.0 DP-1 – Xcode 7.2 -Mac OS 10.10 – iOS 9.2 LiveCode 8.2.0 
> DP-1 – Xcode 8.2 -Mac OS 10.11 – iOS 10.2 LiveCode 8.2.0 DP-1 – Xcode 
> 8.3 -Mac OS 10.12 – iOS 10.3


Some things that would make this better:

1) When the mobile support preferences were opened, if there is a path to a 
version of Xcode which this version of LC can't use, it would be better if it 
were displayed - but in grey or red or similar to show it's not usable - rather 
than being deleted, this would be better.

2) Ensure that iOS standalones can be built if there is a path to a valid 
version of Xcode, regardless of that path.

3) Change the list on 

Re: At this point, what's the shortest path to an iOS/Android app?

[Sannyasin Brahmanathaswami via use-livecode]

Geoff

IMHO your shortest path will be

a) forget about fully responsive, in terms of trying to emulate  html5 web 
design. IMHO this whole "must be responsive" is a huge sidetrack from content 
development…someone spends days and days and ends up with a few pix and a 
little bit of text and "it's so cool… yeah.. it shrinks and expand so 
beautifully!" but nothing of substance. You will do better focusing on the 
game, content and game play UX instead of wasting time dealing with "on 
resize…" 

b) most games we are seeing on mobile are fixed to one orientation. This way 
you can "go crazy" with your design and not worry about "what happens if the 
user turns their phone sideways (or upright)"  .e.g. even apple does not 
respond to orientation change in it settings module. Monument Valley (awesomely 
beautiful) is portrait only… period. other games are landscape only. period.

c) once you accept the above, they you are good to go with 


on preopenstack
   wait 200 milliseconds with messages
   set the fullscreenmode of this stack to "showAll"
end preopenstack

and your stack *will* be responsive for the screen size, assuming you 

a) work in the "safe zone" 
b) are willing to accept some letter boxing.
c) or just use a large background and then on some screens all your significant 
content will be constrained to the central horizontal safe zone (on landscape) 
or vertical (on portrait)   but still look lovely.

depending on the kinds of controls and overall look you may find one of these 
others works for you

set the fullscreenmode of stack to 
{empty|"exactFit"|"letterbox"|"noBorder"|"noScale"|"showAll"}

Each of these has its own caveats, I'm most familiar with showAll, but I think 
Randy is using exactFit… 
I hope others jump in here to discuss the differences/options.. 

But the above is, I think the fastest way to get to where you want to be 
without messing with responsive geometry.  

Of course I can hear some who will jump in and say  "it's not that hard to roll 
your own." True, but depends on how many hours you want to put in on "resize 
stack" when that same mental re-estate could be going to building the game 
play? If you lock into portrait (or landscape), set a background image/grc to 
1024 X 1024  and center that… but make your stack  736 X 414  (or 414 X 736) 
you and use fullscreenMode ShowAll, you can be deploying successfully to pretty 
much any device in 30 minutes… 

in the end there's no way around iterations, test, deploy on device(s) and try 
again.

just two mangos from Hawaii…




On 12/15/17, 11:00 AM, "use-livecode on behalf of Geoff Canyon via 
use-livecode"  wrote:

Is there a ready-made shell that people prefer that I should copy the
elements of the app into? Or is there a mobile-specific library that I
should be copying into the app?

What do people prefer to use at this point?

___
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

non-blocking http ... will tsnet end up in community?

[Tom Glod via use-livecode]

Hi Everyone,

I use the Community version for project, and recently I've been working
with the LibURL Library to get some asynchronous server client
communication going ...and if you've ever worked with that .. its clear
there is much room for improvement there.

Though I have no choice what version to use, so I can only wait in
patience, but I think for the long term health of the platform and to give
it the modern robustness it needs, the tsnet library is going to have to
become part of the community version.  Otherwise it will always lag behind
from being able to use modern internet APIs in combination.

Is this something we would have to crowd fund?

Is there anything legally preventing that from happening?

Thanks for any thoughts
___
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: Interprocess Communication (IPC) under OSX

[Richard Gaskin via use-livecode]

Paul Dupuis wrote:

> On 12/18/2017 1:49 PM, Richard Gaskin via use-livecode wrote:
>> Which IPC method are you using?
>>
> Using LiveCode's open process (and related statements) vs open socket
> (IP) or using files.
>
> I have a set of stacks that work perfectly under Windows. The main app
> uses open process to spawn/launch the helper app standalone, which in
> turn listens for messages from the parent. The main app sens a message
> to the helper app, it does its thing and returns information to the
> main app (a series of these exchanges actually takes place) that then
> the main app senss a message for the helper exit. Check are built in
> for error or by checking teh open processes to see if the helper
> crashes or was quit (by a forced quit) and restart the helper is
> needed. As noted it work great.
>
> In principle, the same code should work equally great under OSX, but
> it does not. And yes, if (and when) I have time, i will track down the
> bugs and report them, but at the moment I was hoping for a quick fix
> where someone else already on the list may have identified the OSX
> idiosyncrasies and had sample code that worked around them :-)

If it's a bug in the engine no scripter can help.

But given how much of a Unix like macOS depends on stdin/stdout streams, 
I'd be surprised to see a regression in that engine.


Windows and Unix do handle processes differently under the hood, but if 
LC is doing what it ideally should be doing I agree we shouldn't need 
OS-forked code.


Diagnosing whether this is an engine issue or a platform difference 
would require review of the code for both processes.


--
 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: Interprocess Communication (IPC) under OSX

[Paul Dupuis via use-livecode]

On 12/18/2017 1:49 PM, Richard Gaskin via use-livecode wrote:
> Paul Dupuis wrote:
>
> > I am using IPC vs Sockets...
>
> "IPC" is usually a generic term, encompassing a wide range of
> inter-process communications methods which includes sockets, files,
> shared memory, pipes, and more.
>
> Which IPC method are you using?
>
Using LiveCode's open process (and related statements) vs open socket
(IP) or using files.

I have a set of stacks that work perfectly under Windows. The main app
uses open process to spawn/launch the helper app standalone, which in
turn listens for messages from the parent. The main app sens a message
to the helper app, it does its thing and returns information to the main
app (a series of these exchanges actually takes place) that then the
main app senss a message for the helper exit. Check are built in for
error or by checking teh open processes to see if the helper crashes or
was quit (by a forced quit) and restart the helper is needed. As noted
it work great.

In principle, the same code should work equally great under OSX, but it
does not. And yes, if (and when) I have time, i will track down the bugs
and report them, but at the moment I was hoping for a quick fix where
someone else already on the list may have identified the OSX
idiosyncrasies and had sample code that worked around them :-)




___
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: Interprocess Communication (IPC) under OSX

[Richard Gaskin via use-livecode]

Paul Dupuis wrote:

> I am using IPC vs Sockets...

"IPC" is usually a generic term, encompassing a wide range of 
inter-process communications methods which includes sockets, files, 
shared memory, pipes, and more.


Which IPC method are you using?

--
 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: Screen Resolution for Desktop Apps

[Charles Szasz via use-livecode]

Jacqueline,

Thanks for your comments!  I really would like to know if others have use the 
Hi-DPI scaling setting and how it worked for them. 

Sent from my iPad
___
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: Screen Resolution for Desktop Apps

[J. Landman Gay via use-livecode]

I haven't used Hi-DPI scaling but it sounds like the right thing. I guess 
you'll just have to try it and see how it goes.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On December 18, 2017 8:53:27 AM Charles Szasz via use-livecode 
 wrote:



Jacqueline

I am referring to the Hi-DPI scaling that was introduced in LC 6.5 that 
allows stacks to be automatically scaled to match the system display 
setting.  I am not using 6.5 but using 6.7.11 instead.  I am assuming that 
this works with the user's setting when they use your app.


I set most of my desktop apps to a minimum of a 1280x768 screen resolution 
in order to launch and run my apps. I had some Windows 10 users complained 
of not being able to run my apps although their screen resolution is higher 
than the required 1280x768.  In the past I had recommended that they adjust 
their ClearType font setting to resolve this problem.


I think that the Hi-DPI scaling is responsible for this problem. This is 
why I thought THAT using LC 6.9.11 the Hi-DPI scaling might resolve this 
problem.  What do you think is the best way to resolve this problem?


Sent from my iPad
___
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

Interprocess Communication (IPC) under OSX

[Paul Dupuis via use-livecode]

I have a situation where an LC standalone (built on recent LC releases)
need to communicate with a "helper app" standalone, built under LC4.6.4.
The why is not really import, but it is to migrate some data that is
highly dependent on how 464 handles text field character positions to
versions of LiveCode that are above LC5.5.x where the position ranges
change due to changes (bug fixes and improvements) to the field object.

I am using IPC vs Sockets because under both Windows and OSX (the target
platforms) if the user has their firewall security set high enough,
using sockets causes a dialog to appear requiring the user to allow the
connection.

IPC under Windows (7 through 10) works great. Reliable and consistent.

However, I am having problems with the same code under OSX. Has anyone
worked out using Interprocess communication reliably between two
LiveCode stacks/standalones under OSX that they would share or license
for small money? Rather than pick apart our Windows code for what has to
be different for OSX, I'd rather just jump to something that works under
OSX if such code exists.



___
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

[ANN] This Week in LiveCode 111

[panagiotis merakos via use-livecode]

Hi all,

Read about new developments in LiveCode open source and the open source
community in today's edition of the "This Week in LiveCode" newsletter!

Read issue #111 here: https://goo.gl/Rm6U3z

This is a weekly newsletter about LiveCode, focussing on what's been
going on in and around the open source project. New issues will be
released weekly on Mondays. We have a dedicated mailing list that will
deliver each issue directly to you e-mail, so you don't miss any!

If you have anything you'd like mentioned (a project, a discussion
somewhere, an upcoming event) then please get in touch.


-- 
Panagiotis Merakos 
LiveCode Software Developer

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: Screen Resolution for Desktop Apps

[Charles Szasz via use-livecode]

Jacqueline 

I am referring to the Hi-DPI scaling that was introduced in LC 6.5 that allows 
stacks to be automatically scaled to match the system display setting.  I am 
not using 6.5 but using 6.7.11 instead.  I am assuming that this works with the 
user's setting when they use your app. 

I set most of my desktop apps to a minimum of a 1280x768 screen resolution in 
order to launch and run my apps. I had some Windows 10 users complained of not 
being able to run my apps although their screen resolution is higher than the 
required 1280x768.  In the past I had recommended that they adjust their 
ClearType font setting to resolve this problem.

I think that the Hi-DPI scaling is responsible for this problem. This is why I 
thought THAT using LC 6.9.11 the Hi-DPI scaling might resolve this problem.  
What do you think is the best way to resolve this problem?  

Sent from my iPad
___
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