Re: Object Selection Handles

[Bob Sneidar via use-livecode]

The software should allow you to select the handle of the foreground object if 
only one is selected, and if multiple objects are selected, the nearest 
neighbor to your click point. If anchors are so close as to conflict, you 
should be able to zoom in. I think this is a non-issue. 

Bob S


> On Mar 28, 2017, at 08:53 , dunbarx via use-livecode 
>  wrote:
> 
> But having handles fully within their object makes them easy to grab without
> possibly selecting a near neighbor instead. I have this issue all the time,
> aligning and adjusting closely spaced controls. 


___
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: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Bob Sneidar via use-livecode]

What is an LC 475? Do you mean an Apple Performa? 

Bob S


> On Mar 28, 2017, at 10:41 , Richmond Mathewson via use-livecode 
>  wrote:
> 
> LC 475 running system 7.1.


___
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: Blowfish digest , how to create in Livecode

[Bob Sneidar via use-livecode]

NVM I know, it's "put it"

Bob S


> On Mar 28, 2017, at 19:27 , Bob Sneidar  wrote:
> 
> This in message box:
> put "this is a test" into pPayload;encrypt pPayload using "bf" with password 
> "testing" at 128 bit;put pPayload
> produces:
> this is a test
> 
> No Bueno. 
> 
> Bob S
> 
> 
>> On Mar 28, 2017, at 08:21 , Dave Kilroy via use-livecode 
>>  wrote:
>> 
>> encrypt pPayload using "bf" with password tPassword at 128 bit
> 


___
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: Blowfish digest , how to create in Livecode

[Bob Sneidar via use-livecode]

This in message box:
put "this is a test" into pPayload;encrypt pPayload using "bf" with password 
"testing" at 128 bit;put pPayload
produces:
this is a test

No Bueno. 

Bob S


> On Mar 28, 2017, at 08:21 , Dave Kilroy via use-livecode 
>  wrote:
> 
> encrypt pPayload using "bf" with password tPassword at 128 bit


___
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: Line numbers for soft-wrapped styled text?

[hh via use-livecode]

I see, you are optimizing this. Will become perfect.

The current search is part of a script that has to work also for
non-wrapped text (with possibly horizontal scrollbar) and is a first
step for calculating the visible "chars" (incl. whitespace).

In sum: you are right, the search for the lines can/should be
optimised (you already show a way to go).

>From my point of view it has to be a rough estimate only, can be a
full line off, could stop after finding this 'top line' L1, using
then, say, L1-2 to be on the safe side.

*** My approach would then be to start calculating (or collecting, by
using the selectedLoc):
Walk through the string from there, line by line, as one needs the top
of each single 'visible' lines at any rate for the numbers display.
Then compare these found tops with the top and the bottom of the field
and decide when to start and when to stop. *** 

Of course, if one would like to know only the line numbers, then a 
binary search (optimised in your sense) for the bottomLine could/should
also be done.

This is essentially the same problem starting with a downward shifted
text. This again shows immediately that all your considerations are true
and will lead to an improvement.

So this could then use the same algorithm and adaptive guessing, returning
this time L2+2, to be on the safe side.

By the way:
The problem 'space-below' is probably a general problem of the current
text measurement, because for some fonts with extreme metrics ('Zapfino')
or others with wrong/incomplete metrics we have wrong measurement values.
This leads to the bug which I have seen (and seen reported as bug) that
the insertion cursor is up to a full line "off" (in direction top) and of
wrong height.

I'm looking forward to your complete solution. Perhaps one could even try
to draw a ruler with ticks at the exact line borders for styled text.

> Alex T. wrote:
> 

> 1. this uses a linear-interpolation for its initial guess for the 
> topline (i.e. the percentage, set to  vs / formattedheight). This is good.
> But it then uses that same value of percentage for the initial guess of 
> the bottomline - which seems totally wrong. Should it not use a 
> different percentage
> (specifically, the height of the field / (formattedheight - vs) with 
> maybe a minor tweak for margins) for starting on the bottomline calculation?
> 
> 2. After the initial percentage calculation, all the recursive calls 
> just revert to simple binary search (i.e. percentage = 0.5).
> Since the initial one is just an estimate, and can be thrown off by 
> variable line heights, this initial guess could be on the "wrong" side 
> of the actual answer - and hence all the rest of the recursive 
> iterations are done this "slow" way.
> Why not recalculate the percentage for each recursive call ?
> 
> 3. not so much a question as a bit of philosophical question 
>is a line "visible" if it occupies screen real-estate but has no 
> visible pixels on the screen ?
> i.e. the formattedRect has the same problem (if it is a problem) with 
> spacebelow as I mentioned earlier for formattedheight, so if the top 
> line within the visible field consists solely of the spacebelow a line, 
> then that line will not be included in the visibleTextLines().
> 
> Like I said, that's probably a philosophical question - but it does have 
> implications for how one could then set up the lineNumbers field; I 
> think you have to start it on the line before the "topline" form this 
> calculation, and then set the vscroll of the linenumbers field to match 
> the formattedrect of the next line of the original field (because you 
> can't set a negative vscroll value, so this is needed to push the first 
> visible line number downwards).


___
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: Hangs on "Configuring Simulator"

[William Prothero via use-livecode]

Never mind…..
I deleted all versions of Xcode, downloaded 8.2, and it worked.
Whew!
Bill

> On Mar 28, 2017, at 4:44 PM, William Prothero via use-livecode 
>  wrote:
> 
> LC 8.1.3 INDY, XCode 8.2.1, OSX 10.11.6
> 
> My app was running the simulator, then I started messing with new versions of 
> Xcode and the latest dp of v8 in livecode. Now when I test it on iOS, it 
> compiles the app but hangs on “Configuring simulator….”
> 
> I tried deleting the prefs. No joy. At least the rotating busy icon is 
> active, but nothing else happens.
> 
> What might be happening?
> Best,
> Bill
> 
> 
> William A. Prothero
> http://earthlearningsolution.org/
> 
> ___
> 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

Hangs on "Configuring Simulator"

[William Prothero via use-livecode]

LC 8.1.3 INDY, XCode 8.2.1, OSX 10.11.6

My app was running the simulator, then I started messing with new versions of 
Xcode and the latest dp of v8 in livecode. Now when I test it on iOS, it 
compiles the app but hangs on “Configuring simulator….”

I tried deleting the prefs. No joy. At least the rotating busy icon is active, 
but nothing else happens.

What might be happening?
Best,
Bill


William A. Prothero
http://earthlearningsolution.org/

___
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: Line numbers for soft-wrapped styled text?

[Alex Tweedly via use-livecode]

On 28/03/2017 22:11, hh via use-livecode wrote:

Hi Alex,
below you will find a tested binary search for the visible lines which
uses item 4 of the formattedRect for the topLine and item 2 of the
formattedRect for the bottomLine.

That's great - thank you.

However, I do have a couple of questions :

1. this uses a linear-interpolation for its initial guess for the 
topline (i.e. the percentage, set to  vs / formattedheight). This is good.
But it then uses that same value of percentage for the initial guess of 
the bottomline - which seems totally wrong. Should it not use a 
different percentage
(specifically, the height of the field / (formattedheight - vs) with 
maybe a minor tweak for margins) for starting on the bottomline calculation?


2. After the initial percentage calculation, all the recursive calls 
just revert to simple binary search (i.e. percentage = 0.5).
Since the initial one is just an estimate, and can be thrown off by 
variable line heights, this initial guess could be on the "wrong" side 
of the actual answer - and hence all the rest of the recursive 
iterations are done this "slow" way.

Why not recalculate the percentage for each recursive call ?

3. not so much a question as a bit of philosophical question 
  is a line "visible" if it occupies screen real-estate but has no 
visible pixels on the screen ?
i.e. the formattedRect has the same problem (if it is a problem) with 
spacebelow as I mentioned earlier for formattedheight, so if the top 
line within the visible field consists solely of the spacebelow a line, 
then that line will not be included in the visibleTextLines().


Like I said, that's probably a philosophical question - but it does have 
implications for how one could then set up the lineNumbers field; I 
think you have to start it on the line before the "topline" form this 
calculation, and then set the vscroll of the linenumbers field to match 
the formattedrect of the next line of the original field (because you 
can't set a negative vscroll value, so this is needed to push the first 
visible line number downwards).






TMHO your method is so fast for visible lines of a field on usual
screensizes only that you could do that for each single of these lines.

The spaceBelow issue you describe has probably the (inavoidable) reason
of LC's ignoring a last linedelimiter in nearly all cases.

## The script is part of the result of a thread BerndN and I had once
## in the forum about the visible text of a styled field.
-- Determining the visible text lines of a field (may be styled).
-- pT = the short name of the field
function visibleTextLines pT
   lock screen; lock messages
   put the vscroll of fld pT into vs
   put the scrollbarWidth of fld pT into sw
   put the margins of fld pT into m
   put (m,m,m,m) into m -- now we have always at least 4 items
   -- 5 is the minimum textsize
   put  4 + (item 2 of m) + (the topof fld pT) into t
   put -4 - (item 4 of m) + (the bottom of fld pT) into b
   if the hscrollbar of fld pT then subtract sw from b
   put the num of lines of fld pT into n
   put vs/(the formattedHeight of fld pT) into pct
   put findTopLine(pT,pct,t-5,1,n) into L1
   put findBottomLine(pT,pct,b+5,max(1,L1-1),n) into L2
   return (L1,L2)
end visibleTextLines

-- percentage p% is a percentage of 1, for example p=0.5 (for 50%)

-- p=%, x=bott of fld pT, n1=start, n=max
function findTopLine pT,p,x,n1,n
   put n1+trunc((n-n1)*p) into m
   if item 4 of the formattedRect of line (m+1) of fld pT >= x then
 if item 4 of the formattedRect of line m of fld pT < x then
   return m+1
 else
   if m <= n1 then return n1
   else return findTopLine(pT,0.5,x,n1,m-1)
 end if
   else
 if m>=n then return n
 else return findTopLine(pT,0.5,x,m+1,n)
   end if
end findTopLine

-- p=%, x=bott of fld pT, n1=start, n=max
function findBottomLine pT,p,x,n1,n
   put n1+trunc((n-n1)*p) into m
   if mn then return n
   if item 2 of the formattedRect of line (m+1) of fld pT > x then
 if item 2 of the formattedRect of line m of fld pT <= x then
   return m
 else return findBottomLine(pT,0.5,x,n1,m-1)
   else return findBottomLine(pT,0.5,x,m+1,n)
end findBottomLine

There is a bit of a problem I encountered trying to code this up.

I'm not 100% sure yet if it's a bug, though I think it must be. Comments
anyone ?



Alex T. wrote:
If I set the 'spacebelow' of the last (Nth) line of a field, and get the
formattedheight of the field, that includes the spacebelow value just set.

However, none of
the formattedheight of line N of fld ...
the formattedheight of line 1 to N of fld ...
the formattedheight of line 1 to -1 of fld ...
include it.  The same is true of 'internal' lines - it's not just the
last one in the field - the formattedheight of a chunk doesn't include
any spacebelow set on the last line of the chunk.

This makes it near impossible to use a binary search accurately (or
indeed to reliably use "the 

Re: Line numbers for soft-wrapped styled text?

[Alex Tweedly via use-livecode]

Thanks Ralph, but no, that doesn't make any difference.

Usually the "char 1 to -1" addition helps where there is an implied 
trailing delimiter. In this case, the problem occurs even for the 
simplest chunk expression of just a single line (e.g. "line N") where 
the delimiter is never included.


-- Alex.


On 28/03/2017 22:48, Ralph DiMola wrote:

I remember once had a problem like something like this. I solved it by
including char 1 to -1 or was it adding the effective keyword? Don't
remember and I don't have time to try at this moment. If you do this do you
get the expected results?

the formattedheight of char 1 to -1 of line N of fld
or
the effective formattedheight of char 1 to -1 of line N of fld
or
the effective formattedheight of line N of fld

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 Alex Tweedly via use-livecode
Sent: Tuesday, March 28, 2017 4:13 PM
To: use-livecode@lists.runrev.com
Cc: Alex Tweedly
Subject: Re: Line numbers for soft-wrapped styled text?

There is a bit of a problem I encountered trying to code this up.

I'm not 100% sure yet if it's a bug, though I think it must be. Comments
anyone ?


If I set the 'spacebelow' of the last (Nth) line of a field, and get the
formattedheight of the field, that includes the spacebelow value just set.

However, none of

the formattedheight of line N of fld ...

the formattedheight of line 1 to N of fld ...

the formattedheight of line 1 to -1 of fld ...

include it.  The same is true of 'internal' lines - it's not just the
last one in the field - the formattedheight of a chunk doesn't include
any spacebelow set on the last line of the chunk.

This makes it near impossible to use a binary search accurately (or
indeed to reliably use "the formattedheight of chunk xx of fld yy").

So now that I've describe it like that, I'm pretty sure it is a bug 
but comments welcome before I report it.

-- Alex.


On 28/03/2017 05:30, hh via use-livecode wrote:

The solution of Alex T. was the first example I saw of a useful
usage of the styledText array. TMHO this is the way to go for the
future of more and more complicated styled text.

As was said elsewhere, there could be a considerable speed up if
first the visible range of lines, say numbers L1 to L2, is determined.

We had once a thread in the forum about that. The fastest method:

Compare the formattedHeight of line 1 to L of fld T to the vscroll v0
of fld T. Not by walking with L up from one, but by using a binary
search for L1 and then starting from there to find L2 by comparing to
v0+the height of fld T. This needs only a few millisecs even for large
chunks.

Then use Alex's method with the styledText array of these lines. Or,
quick and dirty, save the selectedChunk, select before each line L
in the range L1 to L1 and collect the selectedLocs and then restore
the selectedChunk.

Now draw the line numbers each into an own freshly created field or
use Alex's space below method.

p.s. Hopefully you will share your final code.


___
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: Set Layer bug?

[Mike Bonner via use-livecode]

Confirmed on win10  If you set target to 1, it works.  If you set it to > 1
it seems to always set it to the layer thats highest.  I tested with this
script.

on mouseup
set the layer of the target to 2

repeat with i = 1 to the number of buttons of this card
  set the label of button i to the layer of button i -- So that I can add
any number of buttons
end repeat

end mouseup

On Tue, Mar 28, 2017 at 4:40 PM, Klaus major-k via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi Dan,
>
> > Am 29.03.2017 um 00:28 schrieb Dan Friedman via use-livecode <
> use-livecode@lists.runrev.com>:
> >
> > Is this a bug or am I losing my mind?   Can anyone confirm?
> >
> > Using LC 9.0.0 DP-6, set the layer of any object to anything and it
> always get’s set to the topmost layer.  To repeat, put three buttons on a
> card: “button1”, “button2” and “button3”.  The, put this in the stack
> script:
> >
> > on mouseUp
> >  set the layer of the target to 2
> >  set the label of btn "button1" to the layer of btn "button1"
> >  set the label of btn "button2" to the layer of btn "button2"
> >  set the label of btn "button3" to the layer of btn "button3"
> > end mouseUp
> >
> > You’ll see that any button you click, always get’s set to layer 3, even
> though you’ve set it to 2.
>
> confirmed on macOS 10.12.4 with LC 9 dp6!
> Works fine if you:
> ...
> set the layer of the target to 3
> ...
> or
> ...
> set the layer of the target to 1
> ...
> WTF?
>
> > Thank you!
> > -Dan
>
> Best
>
> Klaus
>
> --
> Klaus Major
> http://www.major-k.de
> kl...@major-k.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

Re: Set Layer bug?

[Richard Gaskin via use-livecode]

Dan Friedman wwrote:

> Is this a bug or am I losing my mind?   Can anyone confirm?
>
> Using LC 9.0.0 DP-6, set the layer of any object to anything and it
> always get’s set to the topmost layer.  To repeat, put three buttons
> on a card: “button1”, “button2” and “button3”.  The, put this in the
> stack script:
>
> on mouseUp
>   set the layer of the target to 2
>   set the label of btn "button1" to the layer of btn "button1"
>   set the label of btn "button2" to the layer of btn "button2"
>   set the label of btn "button3" to the layer of btn "button3"
> end mouseUp
>
> You’ll see that any button you click, always get’s set to layer 3,
> even though you’ve set it to 2.

Confirmed, and differs from the oldest version on my drive, 6.0, where 
the result is what you'd expect.


I'd call it a bug.  Please post the report link so we can follow its 
progress.


Thanks -

--
 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: Xcode version for iOS 10.2.1 and LC 9.0.0 dp6

[William Prothero via use-livecode]

Thanks, Dave. 
Bill

> On Mar 28, 2017, at 3:35 PM, Dave Kilroy via use-livecode 
>  wrote:
> 
> Bill the following is from the Release Notes for LiveCode 8.1.3 (located 
> inside the ‘Guide’ bit of the new dictionary)
> 
> Dave
> 
> 
> iOS
> iOS deployment is possible when running LiveCode IDE on a Mac, and provided 
> Xcode is installed and has been set in LiveCode Preferences (in the Mobile 
> Support pane).
> 
> Currently, the supported versions of Xcode are:
> 
> Xcode 4.6 on MacOS X 10.7
> Xcode 5.1 on MacOS X 10.8
> Xcode 6.2 on MacOS X 10.9
> Xcode 6.2 and 7.2 on Mac OS X 10.10
> Xcode 8.2 on MacOS X 10.11
> Xcode 8.2 on MacOS 10.12
> It is also possible to set other versions of Xcode, to allow testing on a 
> wider range of iOS simulators. For instance, on OS X 10.10 (Yosemite), you 
> can add Xcode 5.1 in the Mobile Support preferences, to let you test your 
> stack on the iOS Simulator 7.1.
> 
> We currently support deployment for the following versions of iOS:
> 
> 6.1 [simulator]
> 7.1 [simulator]
> 8.2 [simulator]
> 9.2
> 10.2
> 
> ___
> 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: Set Layer bug?

[Klaus major-k via use-livecode]

Hi Dan,

> Am 29.03.2017 um 00:28 schrieb Dan Friedman via use-livecode 
> :
> 
> Is this a bug or am I losing my mind?   Can anyone confirm?
> 
> Using LC 9.0.0 DP-6, set the layer of any object to anything and it always 
> get’s set to the topmost layer.  To repeat, put three buttons on a card: 
> “button1”, “button2” and “button3”.  The, put this in the stack script:
> 
> on mouseUp
>  set the layer of the target to 2
>  set the label of btn "button1" to the layer of btn "button1"
>  set the label of btn "button2" to the layer of btn "button2"
>  set the label of btn "button3" to the layer of btn "button3"
> end mouseUp
> 
> You’ll see that any button you click, always get’s set to layer 3, even 
> though you’ve set it to 2.

confirmed on macOS 10.12.4 with LC 9 dp6!
Works fine if you:
...
set the layer of the target to 3
...
or
...
set the layer of the target to 1
...
WTF?

> Thank you!
> -Dan

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.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: Set Layer bug?

[Terry Judd via use-livecode]

Have you tried the relayer command? It has a number of useful options.

Terry...

On 29/03/2017 9:28 am, "use-livecode on behalf of Dan Friedman via 
use-livecode"  wrote:

Is this a bug or am I losing my mind?   Can anyone confirm?

Using LC 9.0.0 DP-6, set the layer of any object to anything and it always 
get’s set to the topmost layer.  To repeat, put three buttons on a card: 
“button1”, “button2” and “button3”.  The, put this in the stack script:

on mouseUp
  set the layer of the target to 2
  set the label of btn "button1" to the layer of btn "button1"
  set the label of btn "button2" to the layer of btn "button2"
  set the label of btn "button3" to the layer of btn "button3"
end mouseUp

You’ll see that any button you click, always get’s set to layer 3, even 
though you’ve set it to 2.

Thank you!
-Dan

___
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: Xcode version for iOS 10.2.1 and LC 9.0.0 dp6

[Dave Kilroy via use-livecode]

Bill the following is from the Release Notes for LiveCode 8.1.3 (located inside 
the ‘Guide’ bit of the new dictionary)

Dave


iOS
iOS deployment is possible when running LiveCode IDE on a Mac, and provided 
Xcode is installed and has been set in LiveCode Preferences (in the Mobile 
Support pane).

Currently, the supported versions of Xcode are:

Xcode 4.6 on MacOS X 10.7
Xcode 5.1 on MacOS X 10.8
Xcode 6.2 on MacOS X 10.9
Xcode 6.2 and 7.2 on Mac OS X 10.10
Xcode 8.2 on MacOS X 10.11
Xcode 8.2 on MacOS 10.12
It is also possible to set other versions of Xcode, to allow testing on a wider 
range of iOS simulators. For instance, on OS X 10.10 (Yosemite), you can add 
Xcode 5.1 in the Mobile Support preferences, to let you test your stack on the 
iOS Simulator 7.1.

We currently support deployment for the following versions of iOS:

6.1 [simulator]
7.1 [simulator]
8.2 [simulator]
9.2
10.2

___
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

Set Layer bug?

[Dan Friedman via use-livecode]

Is this a bug or am I losing my mind?   Can anyone confirm?

Using LC 9.0.0 DP-6, set the layer of any object to anything and it always 
get’s set to the topmost layer.  To repeat, put three buttons on a card: 
“button1”, “button2” and “button3”.  The, put this in the stack script:

on mouseUp
  set the layer of the target to 2
  set the label of btn "button1" to the layer of btn "button1"
  set the label of btn "button2" to the layer of btn "button2"
  set the label of btn "button3" to the layer of btn "button3"
end mouseUp

You’ll see that any button you click, always get’s set to layer 3, even though 
you’ve set it to 2.

Thank you!
-Dan

___
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

Xcode version for iOS 10.2.1 and LC 9.0.0 dp6

[William Prothero via use-livecode]

The list doesn’t specify which XCode version is required for this 
configuration. I’m on Mac OS 10.11.6

Help?
Bill

William A. Prothero
http://earthlearningsolution.org/

___
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: Line numbers for soft-wrapped styled text?

[Ralph DiMola via use-livecode]

I remember once had a problem like something like this. I solved it by
including char 1 to -1 or was it adding the effective keyword? Don't
remember and I don't have time to try at this moment. If you do this do you
get the expected results?

the formattedheight of char 1 to -1 of line N of fld
or
the effective formattedheight of char 1 to -1 of line N of fld
or
the effective formattedheight of line N of fld

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 Alex Tweedly via use-livecode
Sent: Tuesday, March 28, 2017 4:13 PM
To: use-livecode@lists.runrev.com
Cc: Alex Tweedly
Subject: Re: Line numbers for soft-wrapped styled text?

There is a bit of a problem I encountered trying to code this up.

I'm not 100% sure yet if it's a bug, though I think it must be. Comments
anyone ?


If I set the 'spacebelow' of the last (Nth) line of a field, and get the 
formattedheight of the field, that includes the spacebelow value just set.

However, none of

   the formattedheight of line N of fld ...

   the formattedheight of line 1 to N of fld ...

   the formattedheight of line 1 to -1 of fld ...

include it.  The same is true of 'internal' lines - it's not just the 
last one in the field - the formattedheight of a chunk doesn't include 
any spacebelow set on the last line of the chunk.

This makes it near impossible to use a binary search accurately (or 
indeed to reliably use "the formattedheight of chunk xx of fld yy").

So now that I've describe it like that, I'm pretty sure it is a bug  
but comments welcome before I report it.

-- Alex.


On 28/03/2017 05:30, hh via use-livecode wrote:
> The solution of Alex T. was the first example I saw of a useful
> usage of the styledText array. TMHO this is the way to go for the
> future of more and more complicated styled text.
>
> As was said elsewhere, there could be a considerable speed up if
> first the visible range of lines, say numbers L1 to L2, is determined.
>
> We had once a thread in the forum about that. The fastest method:
>
> Compare the formattedHeight of line 1 to L of fld T to the vscroll v0
> of fld T. Not by walking with L up from one, but by using a binary
> search for L1 and then starting from there to find L2 by comparing to
> v0+the height of fld T. This needs only a few millisecs even for large
> chunks.
>
> Then use Alex's method with the styledText array of these lines. Or,
> quick and dirty, save the selectedChunk, select before each line L
> in the range L1 to L1 and collect the selectedLocs and then restore
> the selectedChunk.
>
> Now draw the line numbers each into an own freshly created field or
> use Alex's space below method.
>
> p.s. Hopefully you will share your final code.
>
>
> ___
> 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: Text formatting in LC HTML5 apps?

[Terry Judd via use-livecode]

Well, perhaps not so sure now. I’d like to get different styles within the one 
field (normal and bold) but if I include both normal and bold versions of a 
font in the standalone then the bold one seems to take precedence and all text 
in the app is bold.

Terry...

On 29/03/2017 7:42 am, "use-livecode on behalf of Terry Judd via use-livecode" 
 wrote:

OK, thanks Peter – I’ve got it displaying a different font now. Still 
struggling with styles but I’m sure I’ll get there.

Terry...

On 28/03/2017 11:50 pm, "use-livecode on behalf of Peter TB Brett via 
use-livecode"  wrote:



On 28/03/2017 10:32, Terry Judd via use-livecode wrote:
> Is there any way to display styled text in HTML5 apps? There only
> seems to be one font supported and I can change the colour and size
> but nothing else sticks (LC Community 9.0.0 dp5).

You can add any additional fonts you like by putting them in the 
`/boot/fonts/` directory in the standalone archive.

 Peter


-- 
Dr Peter Brett 
LiveCode Technical Project Manager

lcb-mode for Emacs: https://github.com/peter-b/lcb-mode

___
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: Line numbers for soft-wrapped styled text?

[hh via use-livecode]

Hi Alex,
below you will find a tested binary search for the visible lines which
uses item 4 of the formattedRect for the topLine and item 2 of the
formattedRect for the bottomLine.

TMHO your method is so fast for visible lines of a field on usual
screensizes only that you could do that for each single of these lines.

The spaceBelow issue you describe has probably the (inavoidable) reason
of LC's ignoring a last linedelimiter in nearly all cases.

## The script is part of the result of a thread BerndN and I had once
## in the forum about the visible text of a styled field.
-- Determining the visible text lines of a field (may be styled).
-- pT = the short name of the field
function visibleTextLines pT
  lock screen; lock messages
  put the vscroll of fld pT into vs
  put the scrollbarWidth of fld pT into sw
  put the margins of fld pT into m
  put (m,m,m,m) into m -- now we have always at least 4 items
  -- 5 is the minimum textsize
  put  4 + (item 2 of m) + (the topof fld pT) into t
  put -4 - (item 4 of m) + (the bottom of fld pT) into b
  if the hscrollbar of fld pT then subtract sw from b
  put the num of lines of fld pT into n
  put vs/(the formattedHeight of fld pT) into pct
  put findTopLine(pT,pct,t-5,1,n) into L1
  put findBottomLine(pT,pct,b+5,max(1,L1-1),n) into L2
  return (L1,L2)
end visibleTextLines

-- percentage p% is a percentage of 1, for example p=0.5 (for 50%)

-- p=%, x=bott of fld pT, n1=start, n=max
function findTopLine pT,p,x,n1,n 
  put n1+trunc((n-n1)*p) into m
  if item 4 of the formattedRect of line (m+1) of fld pT >= x then
if item 4 of the formattedRect of line m of fld pT < x then
  return m+1
else
  if m <= n1 then return n1
  else return findTopLine(pT,0.5,x,n1,m-1)
end if
  else
if m>=n then return n
else return findTopLine(pT,0.5,x,m+1,n)
  end if
end findTopLine

-- p=%, x=bott of fld pT, n1=start, n=max
function findBottomLine pT,p,x,n1,n 
  put n1+trunc((n-n1)*p) into m
  if mn then return n
  if item 2 of the formattedRect of line (m+1) of fld pT > x then
if item 2 of the formattedRect of line m of fld pT <= x then
  return m
else return findBottomLine(pT,0.5,x,n1,m-1)
  else return findBottomLine(pT,0.5,x,m+1,n)
end findBottomLine

There is a bit of a problem I encountered trying to code this up.

I'm not 100% sure yet if it's a bug, though I think it must be. Comments 
anyone ?


> Alex T. wrote:
> If I set the 'spacebelow' of the last (Nth) line of a field, and get the 
> formattedheight of the field, that includes the spacebelow value just set.
> 
> However, none of
>the formattedheight of line N of fld ...
>the formattedheight of line 1 to N of fld ...
>the formattedheight of line 1 to -1 of fld ...
> include it.  The same is true of 'internal' lines - it's not just the 
> last one in the field - the formattedheight of a chunk doesn't include 
> any spacebelow set on the last line of the chunk.
> 
> This makes it near impossible to use a binary search accurately (or 
> indeed to reliably use "the formattedheight of chunk xx of fld yy").
> 
> So now that I've describe it like that, I'm pretty sure it is a bug  
> but comments welcome before I report it.
> 
> -- Alex.

___
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: Text formatting in LC HTML5 apps?

[Terry Judd via use-livecode]

OK, thanks Peter – I’ve got it displaying a different font now. Still 
struggling with styles but I’m sure I’ll get there.

Terry...

On 28/03/2017 11:50 pm, "use-livecode on behalf of Peter TB Brett via 
use-livecode"  wrote:



On 28/03/2017 10:32, Terry Judd via use-livecode wrote:
> Is there any way to display styled text in HTML5 apps? There only
> seems to be one font supported and I can change the colour and size
> but nothing else sticks (LC Community 9.0.0 dp5).

You can add any additional fonts you like by putting them in the 
`/boot/fonts/` directory in the standalone archive.

 Peter


-- 
Dr Peter Brett 
LiveCode Technical Project Manager

lcb-mode for Emacs: https://github.com/peter-b/lcb-mode

___
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: Line numbers for soft-wrapped styled text?

[Alex Tweedly via use-livecode]

There is a bit of a problem I encountered trying to code this up.

I'm not 100% sure yet if it's a bug, though I think it must be. Comments 
anyone ?



If I set the 'spacebelow' of the last (Nth) line of a field, and get the 
formattedheight of the field, that includes the spacebelow value just set.


However, none of

  the formattedheight of line N of fld ...

  the formattedheight of line 1 to N of fld ...

  the formattedheight of line 1 to -1 of fld ...

include it.  The same is true of 'internal' lines - it's not just the 
last one in the field - the formattedheight of a chunk doesn't include 
any spacebelow set on the last line of the chunk.


This makes it near impossible to use a binary search accurately (or 
indeed to reliably use "the formattedheight of chunk xx of fld yy").


So now that I've describe it like that, I'm pretty sure it is a bug  
but comments welcome before I report it.


-- Alex.


On 28/03/2017 05:30, hh via use-livecode wrote:

The solution of Alex T. was the first example I saw of a useful
usage of the styledText array. TMHO this is the way to go for the
future of more and more complicated styled text.

As was said elsewhere, there could be a considerable speed up if
first the visible range of lines, say numbers L1 to L2, is determined.

We had once a thread in the forum about that. The fastest method:

Compare the formattedHeight of line 1 to L of fld T to the vscroll v0
of fld T. Not by walking with L up from one, but by using a binary
search for L1 and then starting from there to find L2 by comparing to
v0+the height of fld T. This needs only a few millisecs even for large
chunks.

Then use Alex's method with the styledText array of these lines. Or,
quick and dirty, save the selectedChunk, select before each line L
in the range L1 to L1 and collect the selectedLocs and then restore
the selectedChunk.

Now draw the line numbers each into an own freshly created field or
use Alex's space below method.

p.s. Hopefully you will share your final code.


___
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: Object Selection Handles

[J. Landman Gay via use-livecode]

Just a general agreement here, I also have some issues with the new 
design for selections. The circular handles look strange to me but it's 
an adjustment I can deal with. The dotted outline bothers me more 
because it is harder to see the edges of the object, though I suspect it 
was implemented to match the Project Browser.


The main problem I have with it though is that I can't easily apply and 
observe effects applied to the edges of objects. To see a small shadow, 
for example, I have to de-select the object first. Then if it doesn't 
look right, I have to re-select the object and also re-select both the 
effects pane and the shadow dialog in the inspector, because the 
inspector resets when nothing is selected. That makes adjustments a 
painful process that has to be repeated many times before I get what I'm 
aiming for. That, for me, is the main irritation.


--
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: Object Selection Handles

[Richmond Mathewson via use-livecode]

That's why I do 95% of my graphic design "elsewhere" (Gimp, Inkscape, 
and so on). Doing the "application dance" seems
to take up an awful lot of time, and that along with the eternal 
import-export-import thing can get a wee bit tedious.


If all the graphic stuff could be done on-board things would be faster 
and easier.


+1

Richmond.

On 3/28/17 10:43 pm, Sannyasin Brahmanathaswami via use-livecode wrote:

Ditto what Dan, Richard, Craig said

(letting off just a little steam here too)

Ali: "provide examples"

  Adobe illustrator see:

http://wiki.hindu.org/uploads/square-small-selection-handles.jpg

Ali: "justification"

-- I've been ranting for 2 decades about how LC IDE needs to be optimized for 
21st century elegant GUI design.

-- Graphic designers don't switch to console and start typing "set the rect of some object to 
X,X,X,X"   "never gonna happen"

-- Good design is precise design, a miniscule adjustment in the scale of an object, left-edge, can 
make the difference in production values between looking "hokey" vs looking 
"awesome". If you take that ability away from the user, you shoot your product in the 
foot.

-- Please, always optimize the IDE for quality design production values and not necessarily ease of 
use for your kid sister. Yes, your kid sister might find a large handle useful to just drag out an 
object in a use case that is as vague as "I just want it bigger." But that is not how 
"real" design is done. We need quality tools for the whole front end UI builder market… 
and each of us here switches hats (programmer/designer) 20 times a day…

-- point: we don't mind if the selection handles are small, zoom is always an option; if the mouse 
can pick up them up easily in a "nearby" area, that's also OK, but they must be centered 
on the border-edge/corner… because if I'm working to move the edge, scale up-down an object, I will 
make the visual "subconscious" assumption that the center of the handle = the X,Y or X or 
Y position of [whatever]

Anything else is just "wrong"

BR

  


On 3/27/17, 10:41 PM, "use-livecode on behalf of Ali Lloyd via use-livecode" 
 wrote:

 Instead of declaring that this is how it should be, it's much better to
 provide examples and justification. I just checked, and every application I
 have on this computer does selection handles with the center of the handle
 on the boundary of the object.

___
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: Object Selection Handles

[Sannyasin Brahmanathaswami via use-livecode]

Ditto what Dan, Richard, Craig said

(letting off just a little steam here too)

Ali: "provide examples" 

 Adobe illustrator see:

http://wiki.hindu.org/uploads/square-small-selection-handles.jpg

Ali: "justification"

-- I've been ranting for 2 decades about how LC IDE needs to be optimized for 
21st century elegant GUI design. 

-- Graphic designers don't switch to console and start typing "set the rect of 
some object to X,X,X,X"   "never gonna happen"

-- Good design is precise design, a miniscule adjustment in the scale of an 
object, left-edge, can make the difference in production values between looking 
"hokey" vs looking "awesome". If you take that ability away from the user, you 
shoot your product in the foot.

-- Please, always optimize the IDE for quality design production values and not 
necessarily ease of use for your kid sister. Yes, your kid sister might find a 
large handle useful to just drag out an object in a use case that is as vague 
as "I just want it bigger." But that is not how "real" design is done. We need 
quality tools for the whole front end UI builder market… and each of us here 
switches hats (programmer/designer) 20 times a day… 

-- point: we don't mind if the selection handles are small, zoom is always an 
option; if the mouse can pick up them up easily in a "nearby" area, that's also 
OK, but they must be centered on the border-edge/corner… because if I'm working 
to move the edge, scale up-down an object, I will make the visual 
"subconscious" assumption that the center of the handle = the X,Y or X or Y 
position of [whatever]

Anything else is just "wrong"  

BR

 

On 3/27/17, 10:41 PM, "use-livecode on behalf of Ali Lloyd via use-livecode" 
 wrote:

Instead of declaring that this is how it should be, it's much better to
provide examples and justification. I just checked, and every application I
have on this computer does selection handles with the center of the handle
on the boundary of the object.

___
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: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Richmond Mathewson via use-livecode]

I came to the Macintosh party late (even if the kilt I wear is always 
Hunting Macintosh, from my Grandfather Richmond McIntosh)

in 1993 with an LC 475 running system 7.1.

Richmond

On 3/28/17 6:05 pm, Dr. Hawkins via use-livecode wrote:

On Tue, Mar 28, 2017 at 2:17 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:


Not necessarily - I believe system 7.5 was pretty advanced when it came to
text and fonts.


Introduced in 7.0.



___
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: Object Selection Handles

[Richard Gaskin via use-livecode]

Ali Lloyd wrote:

> The code hit-detects as if the handles were square, so the
> hit-detection area is actually bigger than it used to be.

And there's the difference between engineering and user experience:

It may be bigger, but if it's visually ambiguous user's won't be able to 
know that.


A rectangle is an unambiguous representation of the hit rect, which may 
be why so many other tools (and even LC for most of its life) uses them.



But there's more:

If we examine the interaction even more closely, there's a related 
issue, perhaps with the hitPoint of the cursor.  I can move the arrow 
pointer inside the visible handle circle, but it doesn't change to the 
direction arrow (nice touch) until I'm within just a pixel or two of the 
centerpoint.


If the hit rect is indeed bigger, it not only feels smaller by virtue of 
being virtualized in non-rendered corners around the circular handle 
shape, but appears to the eye and hand to be visibly smaller when 
attempting to click on the handle, since I now need to get much closer 
to the center than I recall having to do before.


--
 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: Object Selection Handles

[Ali Lloyd via use-livecode]

> So do you see any advantage to having handles outboard?

Yes, it is impossible to resize an object's width or height to zero (or
within (size of handle) of zero) when the handles are inside the object.
Also, you could not previously make a line straight using the selection
handles inside an object, for roughly the same reason.

If you're making precision changes to an object's rect that require seeing
the selection handles within the rect, it seems to me you'd be much better
off adjusting the rect via the message box or using the alignment tools.

On Tue, Mar 28, 2017 at 5:08 PM Ali Lloyd  wrote:

> The code hit-detects as if the handles were square, so the hit-detection
> area is actually bigger than it used to be.
>
>
> On Tue, Mar 28, 2017 at 4:51 PM Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> Ali Lloyd wrote:
>
>  > Instead of declaring that this is how it should be, it's much better
>  > to provide examples and justification. I just checked, and every
>  > application I have on this computer does selection handles with the
>  > center of the handle on the boundary of the object.
>
> Centering the handle on the corrner/edge is how LibreDraw does it too.
>
> I think that makes sense, given that the user will aim for the center of
> the handle, and as such will be aiming for the corner/edge.
>
> As for shape, the justification is is that a solid square is an easier
> target to hit than an anti-aliased circle.
>
> I believe Adobe Illustrator uses circles, but AFAIK only for Bezier
> points.  Object boundary handles there seem to be square, as they are in
> LibreDraw, and historically in apps like Fireworks all the way back to
> NeXTStep Layout and MacDraw.
>
> Apple's Interface Builder uses square handles:
> 
>
> MSDN shows square handles even for Bezier points:
> 
>
> Xamarin also uses square handles:
> <
> https://developer.xamarin.com/guides/ios/user_interface/controls/part_1_-_creating_user_interface_objects/Images/Image8a.png
> >
>
> Qt Creator as well:
> <
> http://doc.crossplatform.ru/qtcreator/en/2.0/images/qtcreator-mobile-project-widgets.png
> >
>
> Even FileMaker Pro:
> <
> https://www.safaribooksonline.com/library/view/filemaker-pro-14/9781491917473/httpatomoreillycomsourceoreillyimages2192071.png.jpg
> >
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Object Selection Handles

[Ali Lloyd via use-livecode]

The code hit-detects as if the handles were square, so the hit-detection
area is actually bigger than it used to be.

On Tue, Mar 28, 2017 at 4:51 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Ali Lloyd wrote:
>
>  > Instead of declaring that this is how it should be, it's much better
>  > to provide examples and justification. I just checked, and every
>  > application I have on this computer does selection handles with the
>  > center of the handle on the boundary of the object.
>
> Centering the handle on the corrner/edge is how LibreDraw does it too.
>
> I think that makes sense, given that the user will aim for the center of
> the handle, and as such will be aiming for the corner/edge.
>
> As for shape, the justification is is that a solid square is an easier
> target to hit than an anti-aliased circle.
>
> I believe Adobe Illustrator uses circles, but AFAIK only for Bezier
> points.  Object boundary handles there seem to be square, as they are in
> LibreDraw, and historically in apps like Fireworks all the way back to
> NeXTStep Layout and MacDraw.
>
> Apple's Interface Builder uses square handles:
> 
>
> MSDN shows square handles even for Bezier points:
> 
>
> Xamarin also uses square handles:
> <
> https://developer.xamarin.com/guides/ios/user_interface/controls/part_1_-_creating_user_interface_objects/Images/Image8a.png
> >
>
> Qt Creator as well:
> <
> http://doc.crossplatform.ru/qtcreator/en/2.0/images/qtcreator-mobile-project-widgets.png
> >
>
> Even FileMaker Pro:
> <
> https://www.safaribooksonline.com/library/view/filemaker-pro-14/9781491917473/httpatomoreillycomsourceoreillyimages2192071.png.jpg
> >
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Object Selection Handles

[dunbarx via use-livecode]

Ali.

I was presumptuous.

But having handles fully within their object makes them easy to grab without
possibly selecting a near neighbor instead. I have this issue all the time,
aligning and adjusting closely spaced controls. I often just select a
control, nudge it a few times with an arrowKey to clear the handle of
interest, and only then grab. This is a pain.

So do you see any advantage to having handles outboard?

And rectangular handles are at least conforming with the typical shape and
extent of a control's rect; a round peg does not fit in that hole, and
somewhat misleads as to the precise visual boundary of that rect.

Anyway, if my vote counts at all, rectangular handles inBoard, a la v.6.

Craig Newman



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Object-Selection-Handles-tp4713410p4713445.html
Sent from the Revolution - User mailing list archive at Nabble.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: Object Selection Handles

[Richard Gaskin via use-livecode]

Ali Lloyd wrote:

> Instead of declaring that this is how it should be, it's much better
> to provide examples and justification. I just checked, and every
> application I have on this computer does selection handles with the
> center of the handle on the boundary of the object.

Centering the handle on the corrner/edge is how LibreDraw does it too.

I think that makes sense, given that the user will aim for the center of 
the handle, and as such will be aiming for the corner/edge.


As for shape, the justification is is that a solid square is an easier 
target to hit than an anti-aliased circle.


I believe Adobe Illustrator uses circles, but AFAIK only for Bezier 
points.  Object boundary handles there seem to be square, as they are in 
LibreDraw, and historically in apps like Fireworks all the way back to 
NeXTStep Layout and MacDraw.


Apple's Interface Builder uses square handles:


MSDN shows square handles even for Bezier points:


Xamarin also uses square handles:


Qt Creator as well:


Even FileMaker Pro:


--
 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: Blowfish digest , how to create in Livecode

[Dave Kilroy via use-livecode]

Mathias I use blowfish from within LiveCode … but no blowfishdigest that I know 
of:


encrypt pPayload using "bf" with password tPassword at 128 bit

put it into tPayload




Dave
___
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: Blowfish digest , how to create in Livecode

[J. Landman Gay via use-livecode]

I thought the encrypt /decrypt commands supported blowfish. (Not at my Mac 
to check.)


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



On March 28, 2017 9:33:31 AM Matthias Rebbe via use-livecode 
 wrote:



Hi Peter,


Am 28.03.2017 um 14:58 schrieb Peter TB Brett via use-livecode 
>:




Hi Matthias,

Quick note that you may be affected by this PHP security vulnerability:

http://www.php.net/security/crypt_blowfish.php 





thanks for letting me know, but we running PHP 5.6x on our server. So we 
are not affected by this.





I'm not sure about Blowfish-based `crypt()` with LiveCode, I'm afraid.

I have sent a support request to Runrev 1 or 2 hours ago, so i´ll have to 
wait to see what your colleagues are thinking about it.


Regards,
Matthias




Matthias Rebbe
Bramkampsieke 13
32312 Lübbecke
Tel +49 5741 31
+49 160 5504462
Fax: +49 5741 310002
eMail: matth...@m-r-d.de 

BR5 Konverter - BR5 -> MP3 
___
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: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Dr. Hawkins via use-livecode]

On Tue, Mar 28, 2017 at 2:17 AM, Mark Waddingham via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Not necessarily - I believe system 7.5 was pretty advanced when it came to
> text and fonts.


Introduced in 7.0.

-- 
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: where does the standalonebuilder saves the substacks in an Mac OS App?

[Bob Sneidar via use-livecode]

Is it a library that will not be edited programmatically at runtime? If not, 
then that is the place it belongs. 

Bob S


> On Mar 28, 2017, at 06:07 , Tiemo Hollmann TB via use-livecode 
>  wrote:
> 
> Creating a standalone on MacOS 10.12 with LC 8.1.3, LiveCode puts the file
> "revsecurity.dylib" into "my.app/Contents/MacOS/"
> As you say, this would be against the rules of Apple. Is this a bug? Or is
> it still arbitrary, where to put your files?
> Tiemo


___
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: Blowfish digest , how to create in Livecode

[Matthias Rebbe via use-livecode]

Hi Peter,


> Am 28.03.2017 um 14:58 schrieb Peter TB Brett via use-livecode 
> >:
> 
> 
> 
> Hi Matthias,
> 
> Quick note that you may be affected by this PHP security vulnerability:
> 
> http://www.php.net/security/crypt_blowfish.php 
> 
> 

thanks for letting me know, but we running PHP 5.6x on our server. So we are 
not affected by this.



> I'm not sure about Blowfish-based `crypt()` with LiveCode, I'm afraid.
> 
I have sent a support request to Runrev 1 or 2 hours ago, so i´ll have to wait 
to see what your colleagues are thinking about it.

Regards,
Matthias




Matthias Rebbe
Bramkampsieke 13
32312 Lübbecke
Tel +49 5741 31
+49 160 5504462
Fax: +49 5741 310002
eMail: matth...@m-r-d.de 

BR5 Konverter - BR5 -> MP3 
___
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

AW: where does the standalonebuilder saves the substacks in an Mac OS App?

[Tiemo Hollmann TB via use-livecode]

Creating a standalone on MacOS 10.12 with LC 8.1.3, LiveCode puts the file
"revsecurity.dylib" into "my.app/Contents/MacOS/"
As you say, this would be against the rules of Apple. Is this a bug? Or is
it still arbitrary, where to put your files?
Tiemo


-Ursprüngliche Nachricht-
Von: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] Im Auftrag
von J. Landman Gay via use-livecode
Gesendet: Montag, 27. März 2017 20:31
An: How to use LiveCode 
Cc: J. Landman Gay 
Betreff: Re: where does the standalonebuilder saves the substacks in an Mac
OS App?

I think that's right, Apple enforces this rule.

The standalone builder will move files to a Resources folder when it builds
the app. For backward compatibility, scripts that reference the engine
folder are redirected to the Resources folder automatically.

On 3/27/17 1:22 PM, Bob Sneidar via use-livecode wrote:
> To my understanding, it's a requirement in accordance with Apple's 
> sandboxing policies, if you want an executable to be able to make 
> changes to files inside the executable bundle. The way it's supposed 
> to work, no application is allowed to write or modify anything in the 
> old location where the actual application binary resides, but in the 
> new location they can.
>
> As an administrative user I am able to copy files to both locations, 
> but sandboxing is not about folder permissions. It's about executable 
> permissions and it's baked into the OS so no one can (ostensibly) 
> change it.
>
> That is my understanding at least. I've not dug in enough to know for 
> certain.
>
> Bob S
>
>
>> On Mar 27, 2017, at 09:45 , Tiemo Hollmann TB via use-livecode 
>>  wrote:
>>
>> Hello, "Apple requires" - Is this only a "best practise" guideline or 
>> what will happen if you don't care? I have an old application just 
>> migrated to LC 8, where I am running an independent stack file in 
>> that old dir("Contents/MacOS"), and it is running fine on MacOS
>> 10.12.3 Is there any Apple link about that or are there any 
>> informations, into which issue you can run, if you put files into the 
>> old dir? If you integrate Valentina, they also keep one file in that 
>> directory. Thanks for any info Tiemo
>
>
> ___ 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 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

Re: Blowfish digest , how to create in Livecode

[Peter TB Brett via use-livecode]

On 28/03/2017 00:29, Matthias Rebbe via use-livecode wrote:

Hi,

i have a MySQL DB which uses passwords  created with php crypt
function using blowfish

the php code looks like this for example

$salt='$2a$08$NWy7XidPPL2XEsouCG3dy’;
$digest= crypt(‘myPassword01’,$salt);

how can i do this in Livecode server? I find SHA1digest and MD5digest
functions in the dictionary, but no blowfishDigest function.


Hi Matthias,

Quick note that you may be affected by this PHP security vulnerability:

http://www.php.net/security/crypt_blowfish.php

I'm not sure about Blowfish-based `crypt()` with LiveCode, I'm afraid.

Peter


--
Dr Peter Brett 
LiveCode Technical Project Manager

lcb-mode for Emacs: https://github.com/peter-b/lcb-mode

___
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: Text formatting in LC HTML5 apps?

[Peter TB Brett via use-livecode]

On 28/03/2017 10:32, Terry Judd via use-livecode wrote:

Is there any way to display styled text in HTML5 apps? There only
seems to be one font supported and I can change the colour and size
but nothing else sticks (LC Community 9.0.0 dp5).


You can add any additional fonts you like by putting them in the 
`/boot/fonts/` directory in the standalone archive.


Peter


--
Dr Peter Brett 
LiveCode Technical Project Manager

lcb-mode for Emacs: https://github.com/peter-b/lcb-mode

___
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: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Richmond via use-livecode]

On 28/03/17 12:17, Mark Waddingham via use-livecode wrote:

On 2017-03-28 10:30, Richmond via use-livecode wrote:

In 1996 I bought a copy of Fontographer, having previously developed
several bitmap fonts
for Macintosh with Fontastic (for Anglo-Saxon and Old Slavic). At that
time (1996) it was possible
to use Fontographer to make fonts with about 4000 characters which one
could access through Mac Keyboard layouts. As far as I know, although
Unicode development started in 1986, there was
no question of Unicode compatibility (and I had not heard of Unicode).

Presumably (?) ALL that Macintosh system 7.5 was doing when it
displayed characters outwith the ASCII set was what I need now?


Not necessarily - I believe system 7.5 was pretty advanced when it 
came to text and fonts. In particular, I'm sure it had an 
implementation of TrueType at least. The only difference then was that 
a font might have multiple CMAP tables for different text encodings as 
the Unicode encoding was still in its infancy. Even bitmap fonts 
(which might not necessarily have been TrueType) would have to declare 
what encoding it assumed was being used so that things could be mapped 
appropriately.


In actual fact, fonts don't really care about encoding exactly - they 
provide tables which map indexes in an encoding to the glyphs to 
represent them. Everything inside the font runs on glyph indexes and 
not codepoints in any encoding. Indeed (as I mentioned in another 
email) you can use the PUA area for your font as a direct 
codepoint->glyph map.



I'm glad you find it unusable: I have a G5 iMac (connects to the
Internet using TenFourFox) running
dual-boot 10.4 and 10.5 that is stuffed with lots of PPC software that
I bought when I had more money for that sort of thing than I have now:
I would be lost without the availability of Appleworks and
Bryce.


I'd point out that TenFourFox is a fork of FireFox and is not a 
Mozilla project.


Is that a point that anyone who is prepared to go on running a PPC Mac 
should

be worried about?

The same goes for Classilla on my OS 9 G3 iMac :)

My original point was that I feel the word "unusable" is a way too 
strong way of saying "not

up-to-date in the least".

I'm NOT going to make Amazon purchases with my Debit card on my G3 iMac!

I have a friend who drives a 1980 Lada: it's great because as its 
incredibly "primitive" not having
any on board computers anything that goes wrong can generally be sorted 
out with a spanner,

a soldering iron and a few vulgar words.



i.e. A third-party has taken the responsibility for maintaining a fork 
of an open-source project to ensure there is a variant of FireFox 
which runs on older systems...


I set up a Macintosh 5400 running system 9 and a series of standalones 
hived off LC/RR 2
derived from my EFL stacks for a chap in a village near here to help the 
kids at a Syrian
refugee camp: certainly a bit ancient, but not unusable. The kids are 
smiling, and learning
basic English vocabulary so they can work out how to become illegal 
migrants into Britain and

vote for Theresa May . . . or something.

Found a donor who is shipping us 12 more PPC all-in-ones running system 
9 . . . . cool; whatever works.




Warmest Regards,

Mark.



Best, Richmond.

___
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

Text formatting in LC HTML5 apps?

[Terry Judd via use-livecode]

Is there any way to display styled text in HTML5 apps? There only seems to be 
one font supported and I can change the colour and size but nothing else sticks 
(LC Community 9.0.0 dp5).

Terry...
___
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: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Mark Waddingham via use-livecode]

On 2017-03-28 10:30, Richmond via use-livecode wrote:

In 1996 I bought a copy of Fontographer, having previously developed
several bitmap fonts
for Macintosh with Fontastic (for Anglo-Saxon and Old Slavic). At that
time (1996) it was possible
to use Fontographer to make fonts with about 4000 characters which one
could access through Mac Keyboard layouts. As far as I know, although
Unicode development started in 1986, there was
no question of Unicode compatibility (and I had not heard of Unicode).

Presumably (?) ALL that Macintosh system 7.5 was doing when it
displayed characters outwith the ASCII set was what I need now?


Not necessarily - I believe system 7.5 was pretty advanced when it came 
to text and fonts. In particular, I'm sure it had an implementation of 
TrueType at least. The only difference then was that a font might have 
multiple CMAP tables for different text encodings as the Unicode 
encoding was still in its infancy. Even bitmap fonts (which might not 
necessarily have been TrueType) would have to declare what encoding it 
assumed was being used so that things could be mapped appropriately.


In actual fact, fonts don't really care about encoding exactly - they 
provide tables which map indexes in an encoding to the glyphs to 
represent them. Everything inside the font runs on glyph indexes and not 
codepoints in any encoding. Indeed (as I mentioned in another email) you 
can use the PUA area for your font as a direct codepoint->glyph map.



I'm glad you find it unusable: I have a G5 iMac (connects to the
Internet using TenFourFox) running
dual-boot 10.4 and 10.5 that is stuffed with lots of PPC software that
I bought when I had more money for that sort of thing than I have now:
I would be lost without the availability of Appleworks and
Bryce.


I'd point out that TenFourFox is a fork of FireFox and is not a Mozilla 
project.


i.e. A third-party has taken the responsibility for maintaining a fork 
of an open-source project to ensure there is a variant of FireFox which 
runs on older systems...


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: Object Selection Handles

[Ali Lloyd via use-livecode]

Instead of declaring that this is how it should be, it's much better to
provide examples and justification. I just checked, and every application I
have on this computer does selection handles with the center of the handle
on the boundary of the object.

On Tue, Mar 28, 2017 at 3:04 AM Craig Newman via use-livecode <
use-livecode@lists.runrev.com> wrote:

> A lesson should be taken from any CAD program worth its salt.
>
>
> Handles are ALWAYS rectangles for objects, and always within the bounds of
> the object in question.
>
>
> That said, a group might be an exception, since handles would overlie the
> controls at the extreme corners of a group, and that looks and feels wrong.
>
>
> Craig Newman
>
>
>
> -Original Message-
> From: Richard Gaskin via use-livecode 
> To: use-livecode 
> Cc: Richard Gaskin 
> Sent: Mon, Mar 27, 2017 3:39 pm
> Subject: Re: Object Selection Handles
>
> Dan Friedman wrote: > Is there a property to change the shape of the
> selection handles when > using the selection tool?  In LC 9 (and 8), they
> are round circles > that protrude outside the edge of the control.  In
> previous versions, > they were squares that remained within the rect of the
> control. > These large “dots” make it hard to do fine alignment of
> controls. > > I know there is a selectionHandleColor property, but is there
> > anything like a selectionHandleShape property?I too find the selection
> handles harder to work with.  I submitted a request for an adjustable size;
> I don't mind if you add a note there asking for shape as well (the older
> rectangles would be preferable to me as well, much less ambiguous than any
> anti-aliased curve shape):
> http://quality.livecode.com/show_bug.cgi?id=16375 > Also, the border of
> the selected control is dashed when selected. > Can that be removed as
> well?The new selection borders drive me crazy - I can't see the edges
> clearly when resizing, and can't see them at all when applying border
> treatments - request to make that option here:
> http://quality.livecode.com/show_bug.cgi?id=17057--   Richard Gaskin
> Fourth World Systems  Software Design and Development for the Desktop,
> Mobile, and the Web
> 
> ambassa...@fourthworld.com
> http://www.FourthWorld.com___use-livecode
> mailing listuse-livecode@lists.runrev.comPlease 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: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Richmond via use-livecode]

In 1996 I bought a copy of Fontographer, having previously developed 
several bitmap fonts
for Macintosh with Fontastic (for Anglo-Saxon and Old Slavic). At that 
time (1996) it was possible
to use Fontographer to make fonts with about 4000 characters which one 
could access through Mac Keyboard layouts. As far as I know, although 
Unicode development started in 1986, there was

no question of Unicode compatibility (and I had not heard of Unicode).

Presumably (?) ALL that Macintosh system 7.5 was doing when it displayed 
characters outwith the ASCII set was what I need now?


I intend this weekend to start up my dedicated Mac OS 9 G3 iMac 
(previously running 10.4 but
now DELIBERATELY downgraded) and LC/RR 2.1 to play around with 
Fontographer 'Classic' and so on.


On 27/03/17 15:39, Mark Waddingham via use-livecode wrote:

On 2017-03-27 13:56, Richmond via use-livecode wrote:

"UnicodeChecker is being developed using the Objective-C programming
language with the standard macOS developer tools, i.e. Xcode and the
Cocoa frameworks. The display of Unicode characters uses the default
system facilities of macOS. So there is no special handling of newer
Unicode characters: While Mac OS X 10.7.5 does not support the latest
Unicode versions when it comes to the character properties (such as
„General Category“, „Combining Class“, etc.) it will happily just
display any character that is present in a font, even if the character
was not actually defined in the very specific version of Unicode that
this version of Mac OS X supports."


Well, yes - it is just displaying the glyph completely out of context.


Now what is interesting is that LC 8.1.3 on Mac OS 10.7.5 will NOT
display characters simply as
characters, but tries to be too clever for its own good.


No - it is not being too clever. It is doing precisely what it should 
for the purposes of laying out text (and indeed what the CoreText 
engine on MacOS does - as that is what the engine uses). Pretty much 
everyone writing apps does not want to care about the (very complex) 
details of turning text into positioned glyphs, they just want a text 
string to be rendered how 'you would' expect, with regard to the 
codified rules which have been developed over a large number of years 
for typesetting language into a printed representation. Moreover, 
generally people want that done in a way which is 100% consistent with 
all other apps on the same OS (which is why using system services for 
such things is so important - Windows, for example, has a lot of 
behaviors built-in for dealing with CJK fonts which date back 1-2 
decades, if an app doesn't support those then it won't operate in the 
same fashion).



As I am the developer of a program that does "all the knitting"
internally all I really would like is exactly
what this chap describes above. The fact that LiveCode seems to be
doing some of "the knitting" off
its own bat and/or leveraging OS "knitting" is what is causing me 
problems.


Quite - you have a special-case - you don't want to layout text, you 
(probably) just want to render glyphs which you specify.



I have already run the latest builds of my Devawriter on Mac OS 10.12
and Ubuntu 16.04
without these problems.  However I have several clients who run their
Macs on Mac OS 10.6.


Well, it is unlikely that anything will change with regards 10.6 with 
regards LiveCode. 8.1.x will be the last branch which will support 
anything less than 10.9.


To be fair, 10.6 is pretty much now a completely dead operating system 
for anything other than offline use.


Possibly in the commercial world; but not for private individuals who do 
not have the money to

buy a new Mac laptop every 3-4 years.

Currently MacBook Air laptops are running at 1200 Euros, and 
contemporary iMacs at 2300 Euros

here in Bulgaria.

One of the things I love about Linux is that, for instance, I can run 
the "latest and greatest" on

my dual core DELL OPTIPLEX 2006 with absolutely not problems at all.

Admittedly, I am planning a "dirty weekend" to try the interesting 
procedure I have been studying on and off for the last month to upgrade 
a reserve polycarbonate iMac (5 in the cupboard) from 10.7.5 to
10.11; but whether that will actually come off is quite another 
question. How long one can

"cheat on the cheese" is an interesting question.

Critically, it does not and will never support some new SSL related 
transport modes, nor does it get Certificate Store updates. Basically, 
as time goes by the number of things a 10.6 machine will happily 
connect to *safely and securely* 'over the internet' will diminish to 
probably zero. (I know this from experience - my laptop is still on 
10.6 for various reasons and is just about unusable now as it can't be 
used to connect a variety of online services anymore - updating it to 
10.11 or 10.12 is on my todo list).


I'm glad you find it unusable: I have a G5 iMac (connects to the 
Internet using TenFourFox) running
dual-boot 10.4 and 10.5 

Re: LiveCode's handling of Unicode glyphs being dependent on the underlying OS

[Mark Waddingham via use-livecode]

On 2017-03-27 14:39, Mark Waddingham via use-livecode wrote:

In regards to your specific requirements, I had a thought on that last
night. I think essentially what you want is a way to treat a sequence
of codepoints in a field as a sequence of glyph indicies into the
current font. So rather than treating the 0x1CF7 codepoint as a
character, it would just be treated as a number to index into the
glyph table of the (inherited) font set on its style. This could be
done as a textStyle, although that would give you no control over
positioning, the only thing it could do there is use the advance width
/ baseline in the glyph to position it sequentially.


I realized that you don't actually need this at all - the PUA can be 
used to do precisely this.


As I'm sure you realize, a font has a 'cmap' table which maps codepoints 
to glyphs and this is can be a many->one mapping - i.e. you can have 
more than one codepoint mapping to the same glyph. So what you could do 
is:


  1) Map all the unicode defined codepoints to their appropriate glyphs 
(noting that use of these codepoints will cause the standard rules to be 
applied when typesetting strings).


  2) Map all the glyphs you want access to a block in the PUA (noting 
that these codepoints will have no extra processing)


You can then use PUA codepoints to get 'just the glyphs', or the normal 
codepoints if you want the standard behavior.


In the future you could look into adding OpenType tables (GPOS, GDEF and 
GSUB in particular) to your font - these allow the font to define things 
like complex kerning, ligatures (where two characters combine into one 
glyph), accents (where single character is composed of a base glyph and 
an accent attached to it) and all kinds of other things without the 
software using it having to know anything about the gory details.


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