### Atkinson dither algorithm

```Hi All,

I am stuck trying to make this code for Bill Atkinson
dithering algorithm much more faster.
Any ways to speed this code?
Follow the recipe and watch out for lines broken
by mail character length limit.

Recipe:

1) Import an small image (200x200 pixels) and
name it as "Image" (you could import a small
transparent png or a small jpg image)

2) Optionally, create a scrollbar type slider
with a range between 0 and 255.
Set the name of this scrollbar as "ThresholdDither"
and move the slider to 127 or 0 or 255.

3) Paste the following script in a button and
click on it to run this code:

on mouseUp

put the millisecs into startTime
set the cursor to busy

put the imagedata of img "Image" into tVar
-- img "Image" could be a grayscale image
-- where all 3 channels: Red, Green, Blue
-- are identical or a color image where only
-- the red channel is used

delete char 1 of tVar
-- the first char of the imagedata is part
repeat with i = 1 to length(tVar) step 4
put chartonum(char i of tVar) & space after fldhex
end repeat
delete last char of fldhex -- a space
-- fldhex now contains a single channel of the RGB image
-- converted to numbers between 0 and 255

put the number of words of fldhex into lenghtofldhex
put the width of img "Image" into tImageWidth
put the height of img "Image" into tImageHeight

repeat with i = 1 to lenghtofldhex step tImageWidth
-- We need as many words per line, as pixels contains
-- the image width (because each pixel is represented
-- by a word and this word is number between 0 and 255)

put word i to ( i + ((tImageWidth) - 1)) of fldhex & cr after fldhexa2
end repeat

put empty into fldhex
delete last char of fldhexa2
-- deleting the last cr character

put the number of lines of fldhexa2 into sYsize
put the number of words of line 1 of fldhexa2 into sXsize

// get the scrollbar value
-- tThreshold is a value between 0 and 255
if existence(sb the "ThresholdDither") then
put thumbPos of sb the "ThresholdDither" into tThreshold
else
put 127 into tThreshold
end if

repeat with tY = 1 to sYsize
repeat with tX = 1 to sXsize

put tX into tPixelPosition

put word (tPixelPosition) of line tY of fldhexa2 into
tOldPixelValue

if round(tOldPixelValue) <= tThreshold then
put 0 into tNewPixelValue
else
put 255 into tNewPixelValue
end if

put (tOldPixelValue - tNewPixelValue)/8 into tDifusionError

-- Atkinson dither add the diffusion error
-- x o o
--  o o o
-- o

put tNewPixelValue & space after fldhexa3

if tPixelPosition < sXsize then
put tDifusionError + word (tPixelPosition + 1) of line tY of
fldhexa2 into word (tPixelPosition + 1) of line tY of fldhexa2

if tPixelPosition < (sXsize-1) then
put tDifusionError + word (tPixelPosition + 2) of line tY
of fldhexa2 into word (tPixelPosition + 2) of line tY of fldhexa2
end if

end if

if tY < sYsize then

if tPixelPosition > 1 then
put tDifusionError + word (tPixelPosition - 1) of line tY
+ 1 of fldhexa2 into word (tPixelPosition - 1) of line tY + 1 of fldhexa2
end if

put tDifusionError + word (tPixelPosition) of line tY + 1 of
fldhexa2 into word (tPixelPosition) of line tY + 1 of fldhexa2

if tPixelPosition < sXsize then
put tDifusionError + word (tPixelPosition + 1)  of line
tY + 1 of fldhexa2 into word (tPixelPosition + 1) of line tY + 1 of fldhexa2
end if

if tY < (sYsize - 1) then
put tDifusionError + word (tPixelPosition) of line tY + 2
of fldhexa2 into word (tPixelPosition) of line tY + 2 of fldhexa2
end if

end if

end repeat
end repeat

replace "0" with "00" in fldhexa3
replace "255" with "FF" in fldhexa3

repeat with i = 1 to the number of words of fldhexa3
put 00 & word i of fldhexa3 & word i of fldhexa3 & word i of fldhexa3
after tVar2
end repeat
put binaryEncode("H*",tVar2) into tVar3

create img
set the height of it to the height of img "Image"
set the width of it to the width of img "Image"
set the imagedata of it to tVar3

put the millisecs - startTime && "milliseconds to create Atkinson Dither"

end mouseUp

Al
___
use-livecode mailing list
use-livecode@lists.runrev.com
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

```

### Re: Grouping Controls in selectGroupedControls mode

```I run for days at a time with selectGroupedControls turned on, setting it
to false is the exception. It's already possible to align or move any
controls together regardless of the groups they are in.

While I rarely use the project browser, it's my understanding that you can
align and manipulate multiple controls even if they are on different cards
or stacks.

On October 6, 2017 2:06:10 PM Sannyasin Brahmanathaswami via use-livecode
wrote:

NOW! I want to be able to select any object at any time, sometime even
object in different groups.. go to align, align left, move over 5 pointes
etc… and typically run with "selectGroupedControls" on… for days at a  stretch.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
```

### Re: [ANN] Release 8.1.7 RC-3

```Mark,

Thank you for the detailed explanation. Overall the current strategy appears
sound. I took a look at Apple's developer info on this topic today and they
state:

"Slicing is the process of creating and delivering variants of the app
bundle for different target devices. A variant contains only the executable
architecture and resources that are needed for the target device. You
continue to develop and upload full versions of your app to iTunes Connect.
The App Store will create and deliver different variants based on the
devices your app supports. Xcode simulates slicing during development so you
can create and test variants locally. Xcode slices your app when you build
and run your app on a device or in Simulator."

I compared the size of my iOS app directly installed onto an iPhone 6S (iOS
11, set to run on iOS 10.3 or later) using Xcode 9.0 - with 64 bit slice
only (8.1.7 RC-2) and with both 64 bit and 32 bit slices (8.1.7 RC-3). The
universal binary on the phone is approximately twice as large as the 64 bit
version. I have not found any way to check app size in the simulator.

Henry

--
Sent from:
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-livecode@lists.runrev.com
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

```

### Re: Grouping Controls in selectGroupedControls mode

```@ Mark As one who is constantly switching from Indesign (editorial work for our
magazine) and Livecode

My testimony is I can't tell you often I "bark" at indesign "why on earth can't
I change the properties of a single object in a group without ungrouping! like
we can do in Livecode!"

So what you describe as "non-standard" I see has a huge plus.

That said, I agree there are frequent times (and lots of wasted time) ensuing
from the "condition" in selectGroupControls where all the objects become
untethered from their group.

If but people work in in different ways, so possibly you will need to use
preferences.

The typical work flow I find, both in Indesign and in Livecode

Phase one: creating the Layout/UI/UX --
# Now we doing a lot of testing creation of groups, adding objects, one is
more focused on the overall layout architecture and structure, if some
objects/controls in a group are not quite right yet, you tend to ignore this
saying to yourself "I will tweak all the eye candy later" and if you scripting
architecture is picking the target higher up the msg path 80% of the objects
may have no script at all. so you are never editing scripts of objects… working
in the card script, the stackscript or a external text only behavior etc.  more
and more I am never touching any script of any object (which still surprises me)

in this environment the model you describe as in Pages has utility. It keeps
us from creating weird issues we face, Where the "sankalpa" - intention is to
be creating objects in a group or add an object to an existing group, there a
too many caveats right now.

I frequently end up with an object that appears outside the intended group. One
has to train oneself to constantly to toggle the selectGroupedControls on and
off, and if you miss it just once, suddenly you have a new object on the card
outside all groups. relayering in deeply nested groups is too  tricky: select,
cut, switch off selectGroupControls edit, edit, now in nested group: paste.

So this behavior would seem useful:

Mark: "Double-clicking on a object within the selected group will select the
object, or the next nested group if the object is within the group."

And Yes this! "  When you create an object it is created in the currently
selected
group of the group which directly contains the selected object.

I like this too…"When a nested object is selected, its immediate owning group
has a
border around it (grey, rather than the blue of the selected border

apps that use the pointer too: which is a valid point.

Yes " So, anyway, perhaps just making the 'Group' operation enabled/disabled
based on selected objects is the most reasonable thing to do now."

--
But not this!

"However, it would be nice to imagine how selectGroupedControls could
actually be eliminated"

Ouch: think carefully before eliminating what is a huge plus/feature for LC
over the "other tools" people are coming from.

Phase 2
OK most of  the UI/UX architecture is locked in, the UX designer's interface
is all laid out. Stack holders reviewed signed off "OK looks good, lets go with
it like this."

NOW! I want to be able to select any object at any time, sometime even object
in different groups.. go to align, align left, move over 5 pointes etc… and
typically run with "selectGroupedControls" on… for days at a  stretch.

And of course sometimes we toggle back and forther between

phase 1 (create UI/UX) and
phase 2 (tweaks objects, work on scripts)

In the course of several sessions in a single day.

Just my two avocados from Kauai

BR

On 10/6/17, 2:36 AM, "use-livecode on behalf of Mark Waddingham via
use-livecode"  wrote:

When you create an object it is created in the currently selected
group of the group which directly contains the selected object.

Of course, the last rule here exposes a distinct difference in the way
things are created in Pages compared to LiveCode - in LiveCode, the
'object tools' allow you to click-drag-create; whereas in Pages it is
click to create at standard size and then edit.

So, anyway, perhaps just making the 'Group' operation enabled/disabled
based on selected objects is the most reasonable thing to do now.

However, it would be nice to imagine how selectGroupedControls could
actually be eliminated - as it (together with 'Edit Group mode') are,
well, just plain odd when viewed from the eyes of someone coming from
other tools which have the concept of object and group.

Warmest Regards,

Mark.

___
use-livecode mailing list
use-livecode@lists.runrev.com
preferences:
```

### Re: Beginners Guide?

```John,

The best place to get the most up-to-date platform support is in the release
notes. Here’s what is in the release notes for 8.1.7RC3:

Windows
LiveCode supports the following versions of Windows:

Windows XP SP2 and above
Windows Server 2003
Windows Vista SP1 and above (both 32-bit and 64-bit) Windows 7 (both 32-bit and
64-bit)
Windows Server 2008
Windows 8.x (Desktop)
Windows 10

Note: On 64-bit Windows installations, LiveCode runs as a 32-bit application
through the WoW layer.

Linux
LiveCode supports the following Linux distributions, on 32-bit or 64-bit
Intel/AMD or compatible processors:

Ubuntu 14.04 and 16.04
Fedora 23 & 24
Debian 7 (Wheezy) and 8 (Jessie) [server] CentOS 7 [server]

LiveCode may also run on Linux installations which meet the following
requirements: Required dependencies for core functionality:

glibc 2.13 or later glib 2.0 or later

Optional requirements for GUI functionality:

GTK/GDK 2.24 or later
Pango with Xft support
esd (optional, needed for audio output)
mplayer (optional, needed for media player functionality) lcms (optional,
required for color profile support in images) gksu (optional, required for
privilege elevation support)

Note: If the optional requirements are not present then LiveCode will still run
but the specified features will be disabled.

Note: The requirements for GUI functionality are also required by Firefox and
Chrome, so if your Linux distribution runs one of those, it will run LiveCode.

Note: It may be possible to compile and run LiveCode Community for Linux on
other architectures but this is not officially supported.

Mac
The Mac engine supports:

10.6.x (Snow Leopard) on Intel
10.7.x (Lion) on Intel
10.8.x (Mountain Lion) on Intel
10.9.x (Mavericks) on Intel
10.10.x (Yosemite) on Intel
10.11.x (El Capitan) on Intel
10.12.x (Sierra) on Intel

This could easily be updated in the Beginners Guide using Git, but it seems
like there ought be an automatic way to update the guide as the release notes
are published.

Devin

On Oct 6, 2017, at 10:37 AM, JOHN PATTEN via use-livecode
> wrote:

Hi All,

I’m going to be doing some short introductions to some of our teachers about
LiveCode. I was reviewing the support resources, specifically the Beginners
Guide. The info seems to need a bit of an update. Is there another link with a
more current Beginners Guide?

i.e..

General
To use LiveCode you will need:

1024×768 or larger monitor
True color display (16-bit or 32-bit depth)
At least 256Mb of memory
At least 150Mb of disk space (is this still accurate?)
Windows
LiveCode supports the following versions of Windows:

Windows 2000 SP4
Windows XP SP2 and above
Windows Server 2003
Windows Vista SP1 and above (both 32-bit and 64-bit)
Windows 7 (both 32-bit and 64-bit)
Windows Server 2008
Windows 8 and 8.1 Desktop
Additionally, QuickTime 7 or later is required for most multimedia features.

Mac OS X
LiveCode supports the following versions of Mac OS X:

10.3.9 (Panther) on PowerPC
10.4.11 (Tiger) on Intel and PowerPC
10.5.8 and later (Leopard) on Intel and PowerPC
10.6.x (Snow Leopard) on Intel
10.7.x (Lion)
10.8.x (Mountain Lion)
10.9.x (Mavericks)
10.10 (Yosemite)
Linux
The minimal requirements for LiveCode to run on Linux are:

32-bit installation, or a 64-bit linux distribution that has a 32-bit
compatibility layer
2.4.x or later kernel
glibc 2.3.2 or later X11R5 capable Xserver running locally on a 24-bit display
compositing window manager (optional – required for alpha-blended window shapes)
gtk/gdk/glib (optional – required for native theme support)
pango/xft (optional – required for pdf printing, anti-aliased text and unicode
font support)
lcms (optional – required for color profile support in JPEGs and PNGs)
gksu (optional – required for elevate process support)
mplayer (optional – required for video playback)
esd (optional – required for audio playback)
Thank  you!

John Patten
SUSD

___
use-livecode mailing list
use-livecode@lists.runrev.com
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Devin Asay
Director
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-livecode@lists.runrev.com
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
```

### Beginners Guide?

```Hi All,

I’m going to be doing some short introductions to some of our teachers about
LiveCode. I was reviewing the support resources, specifically the Beginners
Guide. The info seems to need a bit of an update. Is there another link with a
more current Beginners Guide?

i.e..

General
To use LiveCode you will need:

1024×768 or larger monitor
True color display (16-bit or 32-bit depth)
At least 256Mb of memory
At least 150Mb of disk space (is this still accurate?)
Windows
LiveCode supports the following versions of Windows:

Windows 2000 SP4
Windows XP SP2 and above
Windows Server 2003
Windows Vista SP1 and above (both 32-bit and 64-bit)
Windows 7 (both 32-bit and 64-bit)
Windows Server 2008
Windows 8 and 8.1 Desktop
Additionally, QuickTime 7 or later is required for most multimedia features.

Mac OS X
LiveCode supports the following versions of Mac OS X:

10.3.9 (Panther) on PowerPC
10.4.11 (Tiger) on Intel and PowerPC
10.5.8 and later (Leopard) on Intel and PowerPC
10.6.x (Snow Leopard) on Intel
10.7.x (Lion)
10.8.x (Mountain Lion)
10.9.x (Mavericks)
10.10 (Yosemite)
Linux
The minimal requirements for LiveCode to run on Linux are:

32-bit installation, or a 64-bit linux distribution that has a 32-bit
compatibility layer
2.4.x or later kernel
glibc 2.3.2 or later X11R5 capable Xserver running locally on a 24-bit display
compositing window manager (optional – required for alpha-blended window shapes)
gtk/gdk/glib (optional – required for native theme support)
pango/xft (optional – required for pdf printing, anti-aliased text and unicode
font support)
lcms (optional – required for color profile support in JPEGs and PNGs)
gksu (optional – required for elevate process support)
mplayer (optional – required for video playback)
esd (optional – required for audio playback)
Thank  you!

John Patten
SUSD

___
use-livecode mailing list
use-livecode@lists.runrev.com
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
```

### Re: HTTP PUT?

```
On 2017-10-06 15:38, Ben Rubinstein via use-livecode wrote:

We can perform an HTTP GET using "get URL xxx"

We can perform an HTTP POST using "post yy to xxx"

How can we perform an HTTP PUT?

Using 'put':

put zz into url xxx

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
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

```

### HTTP PUT?

```
We can perform an HTTP GET using "get URL xxx"

We can perform an HTTP POST using "post yy to xxx"

How can we perform an HTTP PUT?

TIA,

Ben

___
use-livecode mailing list
use-livecode@lists.runrev.com
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

```

### Grouping Controls in selectGroupedControls mode

```
Hi all,

I just wondered if anyone had any thoughts on this report:

http://quality.livecode.com/show_bug.cgi?id=20511

The summary of the report is that when a 'group' operation fails you
only get a 'beep' and no indication as to why the failure occurred.

Group operations will fail if the owner of all controls being grouped is
not the same - I think this is a reasonable restriction, as otherwise it
would be very easy to break things by accidentally grouping controls you
did not intend. Obviously, the obvious 'fix' is to make it so that the
'Group' operation in the IDE is disabled if the owner-rule is violated.

However, whilst perhaps clearer in the sense you would know ahead of
time whether you can group, it still does not help you work out *why*
you cannot group. One thought I had here was whether a visual indication
of the ownership of selected controls in 'selectGroupedControls' mode
might help - basically perhaps painting a subtle border around the
owning groups of each selected object.

Of course, this might just be highlighting the fact that
'selectGroupedControls' mode in LiveCode is perhaps somewhat
'non-standard'. For example Pages (which just happened to be a
convenient app I have installed which does grouping and such) works
quite differently:

Clicking on a grouped object selects the group.

Double-clicking on a object within the selected group will select the
object, or the next nested group if the object is within the group.

You can only select object / groups together which have the same
owner.

You can select a nested object directly by doing an 'n-click' - where
n is the nesting of the group

When a nested object is selected, its immediate owning group has a
border around it (grey, rather than the blue of the selected border).

When you create an object it is created in the currently selected
group of the group which directly contains the selected object.

Of course, the last rule here exposes a distinct difference in the way
things are created in Pages compared to LiveCode - in LiveCode, the
'object tools' allow you to click-drag-create; whereas in Pages it is
click to create at standard size and then edit.

So, anyway, perhaps just making the 'Group' operation enabled/disabled
based on selected objects is the most reasonable thing to do now.

However, it would be nice to imagine how selectGroupedControls could
actually be eliminated - as it (together with 'Edit Group mode') are,
well, just plain odd when viewed from the eyes of someone coming from
other tools which have the concept of object and group.

Warmest Regards,

Mark.

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

```

### Re: [ANN] Release 8.1.7 RC-3

```
On 2017-10-06 06:57, hlowe via use-livecode wrote:
As Apple no longer supports running 32 bit apps under iOS 11, would it
be

possible to make including a 32 bit slice optional, as defaulting to
universal binaries almost doubles the size of the app bundle (my app
went
from 18 MB when built with LC 8.1.7 RC-2 to 31 MB when built with LC
8.1.7
RC-3. Ideally in iOS Application Settings one could choice from : (1)
Build

universal binary; (2) Build 64 bit binary only; (3) Build 32 bit binary
only.

I believe the iTunes store automatically removes unnecessary slices from
apps *before* they get downloaded onto a user's phone (and I wouldn't be
surprised if this also happens when transferring the app locally through
Xcode / iTunes - although this is somewhat difficult to check without a
rooted iOS device!).

The current situation from the S/B's point of view is this:

1) If the min iOS version in the S/B is set to iOS 11, then only a
64-bit slice will be included and it will only work on devices which
have iOS 11

2) If the '32-bit only' checkbox is set, then the S/B will only
include a 32-bit slice - this is to support iPad 1 (it was added to
support a few customers who were having to support iPad 1's in their
apps after Apple added the 64-bit option - we're not sure if anyone is
still using it which is why it is still there).

3) Otherwise the S/B will include a 32-bit and 64-bit slice. This
means that the app can run on devices older than the iPhone 5s (which
was the first to run in 64-bit mode).

The reason the 32-bit slice is still needed is that the (32-bit only)
iPhone 5 and iPhone 5C can run up to iOS 10 - so *not* including it
would exclude those devices from being able to use your app.

To rephrase (for clarity) - the slices required in an iOS app are
determined by the min iOS version you have set in the S/B with the remit
of supporting as many devices as possible.

So the question is whether we actually need an explicit toggle - or
whether it is better for the S/B to just do the right thing (as it does
at the moment) based on iOS target version...

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
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

```

### Re: Expanded dictionary in LC 9

```
On 2017-10-06 09:41, James At The Hale via use-livecode wrote:

I knew there was work behind the scenes with the documentation but not
to this extent.

While reinstating some formatting on the make docset stack I
discovered than under LC 8.2 and below an enquiry to the dictionary
yields 3940 entries

In LC 9 dp9 the same enquiry yields 5646.

A quick look reveals that one aspect of this expansion is the
inclusion of synonyms.
The glossary appears to be greatly expanded too.

Brian Milby (thanks Brian!) has been working on the docs in this regard
- things will change again in dp-10. He found a better way to handle
synonyms and such, which doesn't require duplicating entries:

https://github.com/livecode/livecode-ide/pull/1765

The initial version (in dp-9 or dp-8) handled synonyms by making
duplicate doc entries; in dp-10 it has been changed so that searches and
such use the synonym info without duplicating them.

Warmest Regards,

Mark.

P.S. Also thanks to all of you who have been helping improve the
dictionary with the tweaks and changes which have been continually
submitted to it - the content and formatting of them is getting better
all the time!

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

___
use-livecode mailing list
use-livecode@lists.runrev.com
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

```

### Expanded dictionary in LC 9

```I knew there was work behind the scenes with the documentation but not to this
extent.

While reinstating some formatting on the make docset stack I discovered than
under LC 8.2 and below an enquiry to the dictionary yields 3940 entries

In LC 9 dp9 the same enquiry yields 5646.

A quick look reveals that one aspect of this expansion is the inclusion of
synonyms.
The glossary appears to be greatly expanded too.

James

___
use-livecode mailing list
use-livecode@lists.runrev.com