Re: Regular crash: Dictionary (API)

[Mark Wieder via use-livecode]

On 6/21/21 12:30 PM, David Bovill via use-livecode wrote:

Anyone point me too an alternative Dictionary  - too many regular crashes using 
the built in one?


TinyDictionary

--
 Mark Wieder
 ahsoftw...@gmail.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: Regular crash: Dictionary (API)

[David Bovill via use-livecode]

Anyone point me too an alternative Dictionary  - too many regular crashes using 
the built in one?

📆    Schedule a call with me
On 11 Jun 2021, 19:46 +0100, David Bovill , wrote:
> For several years I have a regular crash when opening the `Dictionary (API)` 
> - wondering the cause. Everything else works as normal - latest MacOs and 
> Livecode - spinning coloured ball and now dictionary stack displayed  - 
> requires force quit. Doing that now. Third time today.
>
> 📆    Schedule a call with me
___
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

Regular crash: Dictionary (API)

[David Bovill via use-livecode]

For several years I have a regular crash when opening the `Dictionary (API)` - 
wondering the cause. Everything else works as normal - latest MacOs and 
Livecode - spinning coloured ball and now dictionary stack displayed  - 
requires force quit. Doing that now. Third time today.

📆    Schedule a call with me
___
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: Problem with searching dictionary

[Tom Glod via use-livecode]

looks like the search algo is not searching the body of the section just
the title.  Makes sense why, but there ought to be a checkbox somewhere to
enable a deeper search.

try searching for "tiny lc" dictionary somewhere, one one our users here
made an alternative application for the dictionary.

Also there is a version of the lc dictionary that goes with ..a
'documentation' application whose name I cannot remember...

I think I almost helped :D



On Sun, Jul 28, 2019 at 5:05 AM Alex Shaw via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Using LC9.0.4 (but tried other versions) and just tried searching for
> the string "sftp". Nothing comes up.
>
> Yet, if I manually go to a function like "tsNetUploadFile", I can see
> the string "sftp" a few times.
>
> Is there a preference setting I've somehow unset to stop it searching
> deeper or is there a better way to search the dictionary?
>
> regards
> 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
>
___
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

Problem with searching dictionary

[Alex Shaw via use-livecode]

Using LC9.0.4 (but tried other versions) and just tried searching for 
the string "sftp". Nothing comes up.


Yet, if I manually go to a function like "tsNetUploadFile", I can see 
the string "sftp" a few times.


Is there a preference setting I've somehow unset to stop it searching 
deeper or is there a better way to search the dictionary?


regards
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: Dictionary

[Roger Guay via use-livecode]

Ditto on the Dictionary!

Cheers,
Roger

> On May 23, 2019, at 12:26 PM, R.H. via use-livecode 
>  wrote:
> 
> I agree that the dictionary often leaves guess work.
> 
> The biggest problem I have with the dictionary is forgetting the name of a
> function and trying to guess the name. If there were lots of tags to look
> for... but... You must know at least the beginning of a name.
> 
> And how can you even search not knowing what to search for when you only
> know what you want to solve? (Well, search elsewhere...)
> 
> But it would be really very good if editors would put themselves into the
> shoes of newbies assuming no prior knowledge about any of the many
> acronyms, and providing links for further study or simply more explanation
> when a function is not trivial.
> 
> I know, it is hard work. If such task could be structured and we were
> invited as editors to contribute in a more user-friendly way? But too many
> editors may also spoil the soup.
> 
> W3School is s great example of how to combine tutorials with reference
> lists (dictionary).
> 
> The dictionary is a central point of focus for every developer. Probably,
> there is just not enough knowledgable manpower to not just do the absolute
> minimum.
> 
> When Mark is explaining something here, then often I get a picture of what
> is behind the hood. He cannot be, but should be editor-in-chief... )
> ___
> 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: Dictionary

[Sannyasin Brahmanathaswami via use-livecode]

After a year or more getting used to GIT, I am willing help. 

I know somewhere, buried in this list, is a tutorial on helping with the 
dictionary.

Can a lesson be created on the subject? I keep asking a lot of ? and get great 
advice from the list, and save it. I might as well try a few edits to the 
dictionary. 

BR

R.H. wrote:

I know, it is hard work. If such task could be structured and we were
invited as editors to contribute in a more user-friendly way? But too many
editors may also spoil the soup.

___
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

Dictionary

[R.H. via use-livecode]

I agree that the dictionary often leaves guess work.

The biggest problem I have with the dictionary is forgetting the name of a
function and trying to guess the name. If there were lots of tags to look
for... but... You must know at least the beginning of a name.

And how can you even search not knowing what to search for when you only
know what you want to solve? (Well, search elsewhere...)

But it would be really very good if editors would put themselves into the
shoes of newbies assuming no prior knowledge about any of the many
acronyms, and providing links for further study or simply more explanation
when a function is not trivial.

I know, it is hard work. If such task could be structured and we were
invited as editors to contribute in a more user-friendly way? But too many
editors may also spoil the soup.

W3School is s great example of how to combine tutorials with reference
lists (dictionary).

The dictionary is a central point of focus for every developer. Probably,
there is just not enough knowledgable manpower to not just do the absolute
minimum.

When Mark is explaining something here, then often I get a picture of what
is behind the hood. He cannot be, but should be editor-in-chief... )
___
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: Us and them? [was Re: Livecode Dictionary]

[Brian Milby via use-livecode]

If using a binary stack, ScriptTracker makes it easy to edit scripts in an 
external editor.
Levure includes a server process that allows Sublime Text tell LC to reload a 
script only stack when saved from there (I don’t think it depends on the app 
itself being managed with Levure).  I use Atom because it is free and has 
linting support available.

I’d love to build that client-server functionality into Atom, but have not 
looked enough into it.  ScriptTracker works by watching the script export 
directory looking for changes.  When a file is saved, it imports it into the 
stack if the content changed (uses a hash to detect changes).  If I could do 
the client-server thing then it would be much easier to generalize to any open 
stack instead of a single mainstack at a time (I’m thinking mainly of the 
performance impact of watching too many directories for changes at one time).

After this move is behind me I should have more time to code again.

Thanks,
Brian
On Jan 24, 2019, 9:25 PM -0600, Geoff Canyon via use-livecode 
, wrote:
> On Thu, Jan 24, 2019 at 12:36 AM Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > When I forked it I returned to a
> > editor separate from a debugger, each purpose-built for the task they do
> >
>
> YES. If I had a nickel for every time I expand the variable list while in
> the debugger, then shrink back that section while editing a script. If
> there is an easy recipe for automating this, anyone, please share. Or how
> hard is it to set up to edit scripts with an external editor, and maybe
> just debug with the built-in?
> ___
> 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: Us and them? [was Re: Livecode Dictionary]

[Geoff Canyon via use-livecode]

On Thu, Jan 24, 2019 at 12:36 AM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> When I forked it I returned to a
> editor separate from a debugger, each purpose-built for the task they do
>

YES. If I had a nickel for every time I expand the variable list while in
the debugger, then shrink back that section while editing a script. If
there is an easy recipe for automating this, anyone, please share. Or how
hard is it to set up to edit scripts with an external editor, and maybe
just debug with the built-in?
___
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: Us and them? [was Re: Livecode Dictionary]

[Bob Sneidar via use-livecode]

GLX2 was great at one time, but certain features added later, like code saving 
caused problems. I'd like to see GLX2 gone through and made stable again, and 
although Mark Weider has been very diligent to correct any issues that have 
sprung up in the past, no can expect him to continue brooding over it 
indefinitely and getting nothing buy a pat on the back for the effort. 

I wonder if GLX2 is on Github? That would get me into Git for sure. I'd be 
curious if people having issues with the stock SE also have problems with GLX2 
or no. 

Bob S


> On Jan 24, 2019, at 24:36 , Richard Gaskin via use-livecode 
>  wrote:
> 
> So if anyone were relying on me to fix the SE performance issue (and there 
> are many reasons we're all glad no one is relying on me for that), I'd be 
> inclined to write a new one from scratch instead.


___
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: Us and them? [was Re: Livecode Dictionary]

[Curry Kenworthy via use-livecode]

Richard:

> 2. It ain't the field slowing us down.
> As far as I can tell, the LC field object is pretty
> responsive to input.

Agreed, vast majority of SE problems are not field problems. I spend a 
lot of my time in fields and it's pleasant. Responsive in most cases.


> I'm one of the lucky ones, because once I turned off the SE
> features that seemed likely to slow me down, I no longer have a
> slow SE.

I'm in the same boat. I hope most people seriously affected can (like 
us) make the right tweaks for their machines.


> Combining lots of functionality into one window contributes
> to complexity, which often finds expression in performance

Yep, that's my fear. Adding project wiki (or anything else) to the 
already chubby SE is a bit scary for me. I would feel more at ease with 
a separate wiki window in LC that does nothing at all unless opened. I 
do value the debugging and variables inside SE, I want them there, but 
it's getting heavy and that's enough.


Wiki is not essential to the act of script editing, and perhaps not an 
exact match either - after all, a project involves UI too, and data, and 
for some people and projects that might loom larger than the code. A 
UI-centered person might feel that it's in the wrong place and hate 
going into SE to make notes about UI. Although I do understand the 
passion to integrate something cool! Meanwhile dictionary comments could 
just go in the dictionary; potentially a separate and very simple project.


David:

> In terms of GUI - it is possible to have the best of both worlds.
> Integration into the SE, or have the same stack viewed in it's
> own window.

Sounds good! I bet it will be quite impressive. Just try to ensure the 
un-integrated mode is seriously and extremely un-integrated. :)


> so far I've kept my integrations minimal.
> For me the first stage is the content, and collaboration workflow

That will be a neat project to see. Glad you have a vision for it. Great 
things are possible.


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Us and them? [was Re: Livecode Dictionary]

[David Bovill via use-livecode]

Hi Curry - you wrote:

A project wiki would fit in the SE better than it would the Dictionary,
> of course, it would have more features and I could see that being a tab.
> But then again user keyword comments would fit the Dictionary very well,
> they could simply be added there. Having a separate LC window for a
> project wiki is another approach. I would say the tab would be handier
> and more integrated into workflow, but the separate window might be good
> for performance and memory.


In terms of GUI - it is possible to have the best of both worlds.
Integration into the SE, or have the same stack viewed in it's own window.
On a fast machine you might want the full experience with tabs in the SE
-on a slower machine a separate stack showing only text as fast as
possible. You can use front scripts as Richard says, but i preferred to add
behaviours so as to not pollute the environment.

Adding widgets that live replace say the documentation field is also
possible as the SE is destroyed when closed. I've tested all those and they
work well. It would be better to have a standard for that sort of thing -
as otherwise the development can be broken with RunRev updates - so so far
I've kept my integrations minimal.

For me the first stage is the content, and collaboration workflow - if the
basic content of the documentation and the utility of forking / customising
individual pages for a developer is strong - and i'm not the only one that
likes working that way - then creating more advanced SE integrations looks
straight forwards.
___
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: Us and them? [was Re: Livecode Dictionary]

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

> Richard:
>  > Curry Kenworthy wrote:
>  >> What people need most in the Script Editor is to view and edit the
>  >> code itself smoothly, without jitters or delays
>
>  > Not hard to make one.  A frontScript trapping the editScript
>  > message lets you do whatever you want.
>
> It's interesting when we take a comment out of context and spin it in
> another direction by treating it as a different request or problem! :)

Not my intention to take it out of context, but to broaden the context. 
My suggestion of considering a custom SE isn't reductio ad absurdum. 
It's far worse:  I'm actually serious.


Here's where I'm coming from:


Maybe it's just because I was one of the last MC users, but Dr. Raney's 
DIY encouragement never left me: "Let a thousand flowers bloom" he would 
say of anyone with time and interest to fork and replace IDE components.


I kept using the MC IDE about a decade after Revolution first premiered. 
 Eventually I got tired of making my own GUIs for the new engine 
features, so I started using LC IDE - but the script editor was too slow.


So I forked MC's, added line numbers (years before the LC IDE had line 
numbers - we were all such savages back then ), and made it into a 
plugin.  Ken Ray also helped with some of the fork, and we used it for 
another five years or so even after we switched from MC to LC so we 
could use the other tools.


After the big Waddingham SE Overhaul things got a lot better, and the 
balance of features vs performance became more favorable for me, esp. in 
light of the work required to properly maintain a fork. So now I use 
LC's SE.


There's a couple points with this:

1. People can and do make their own script editors.

Why not?  It's text in a field.  If we can't make a good text editor in 
LC why are we even here?  But after delivering a good many custom work 
processors I came to believe -- and still do -- that LC can make an 
excellent text editor.


Basic features aren't hard.  It's modestly rewarding, and you learn a 
lot about making text editors.


What I found, though, was:


2. It ain't the field slowing us down.

As far as I can tell, the LC field object is pretty responsive to input.

And MC is faster than LC.  Given the same engine, the difference is in 
the scripts.


So the good news is that fixing serious slowdowns require the one skill 
everyone on this list has:  LiveCode scripting.


I've spent enough time going through the LC SE code to know that I don't 
enjoy it.  No offense to the team; it just has layers of legacy stuff 
and over time it's accumulated a bit of cruft, made more complex by the 
demands of the audience for new features.  I understand how it got that 
way, and I appreciate it's ambitions.  I just don't enjoy working on it; 
it's a beast.


So if anyone were relying on me to fix the SE performance issue (and 
there are many reasons we're all glad no one is relying on me for that), 
I'd be inclined to write a new one from scratch instead.


It may be possible to design and build something with all the current 
engine strengths and weaknesses in mind that could become more 
satisfying than continually patching a complex legacy stack.


However...

...there's a reason the team patches rather than replaces.  Replacing is 
expensive.  Done well would take tremendous time.  Sure, a field with a 
"Save" button takes only an hour, and a slightly more usable feature set 
takes a day; but a productive set takes weeks; greatness would take months.


And even then, ultimately we may find ourselves left with the question:

Is it possible to deliver the feature set current SE users demand
without adding a performance hit?


I'm one of the lucky ones, because once I turned off the SE features 
that seemed likely to slow me down, I no longer have a slow SE. 
Accordingly, I'm happily making stuff for clients, and am not very 
motivated anymore to work on a script editor.


But if this were bothering me, I'd either dive into the existing SE and 
fix it, or write my own.


Life's too short not to have what we want.



> The wiki sounds like a neat project. Simplicity helps, and whether to
> locate it in the SE is a consideration. Besides performance, another
> issue is that the original proposal here was adding user comments back
> to the Dictionary.

Personally, I prefer dedicated tools.  The MC SE slowed down a lot when 
it was combined with the debugger.  When I forked it I returned to a 
editor separate from a debugger, each purpose-built for the task they do 
(extra bonus points that a sufficiently discrete debugger can also be 
used in a standalone).


Combining lots of functionality into one window contributes to 
complexity, which often finds expression in pe

Re: Us and them? [was Re: Livecode Dictionary]

[Curry Kenworthy via use-livecode]

Richard:

> Curry Kenworthy wrote:
>> What people need most in the Script Editor is to view and edit the
>> code itself smoothly, without jitters or delays

> Not hard to make one.  A frontScript trapping the editScript message
> lets you do whatever you want.

It's interesting when we take a comment out of context and spin it in 
another direction by treating it as a different request or problem! :)


Neither this thread nor my own message was primarily about the SE. 
Feedback (including my own) was requested on a plan for a project wiki 
... located where? Yep, you guessed it - in the LiveCode Script Editor.


My feedback was to keep any addition simple and watch performance, 
because there are some issues and (as you quoted me) the primary feature 
of Script Editor is code editing; that is its priority.


The wiki sounds like a neat project. Simplicity helps, and whether to 
locate it in the SE is a consideration. Besides performance, another 
issue is that the original proposal here was adding user comments back 
to the Dictionary.


A project wiki would fit in the SE better than it would the Dictionary, 
of course, it would have more features and I could see that being a tab. 
But then again user keyword comments would fit the Dictionary very well, 
they could simply be added there. Having a separate LC window for a 
project wiki is another approach. I would say the tab would be handier 
and more integrated into workflow, but the separate window might be good 
for performance and memory.


I mentioned the SE relative to its inclusion in the wiki plan, so just 
clarifying (ahem) that SE alternatives aren't directly related to or a 
response to my own quoted comment. Ah, the wonders of context!


Nice thoughts though. Some people like to downplay IDE issues, perhaps 
in order to focus all possible resources on certain engine issues. 
That's fine, as are alternatives, but personally I like to see LC 
looking good out of the box too, so I believe both are important and I 
prefer to use and help improve the official SE. Many things I like about 
the SE. (A good, but different, topic!) Thanks Richard.


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Us and them? [was Re: Livecode Dictionary]

[Bob Sneidar via use-livecode]

+1 for Sublime. I do not code in it much, but there are plugins like for 
comparing two scripts to see differences. If I ever get around to converting my 
main app to Levure, I would probably use it more. 

Bob S


> On Jan 23, 2019, at 10:52 , Trevor DeVore via use-livecode 
>  wrote:
> 
> On Wed, Jan 23, 2019 at 12:39 PM Richard Gaskin via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> 
>> And then there are the countless third-party text editors, some of which
>> have LC-specific add-ons crafted by our community for them, like
>> Trevor's plugin for Atom.  I've been using Atom enough in web
>> development that I'm considering using it with LC.  It's very nice.
>> 
> 
> The Atom plugin was written by somebody else. I think it was Peter Brett. I
> maintain the plugin for Sublime Text.
> 
> -- 
> Trevor DeVore
> CTO - ScreenSteps
> www.screensteps.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: Us and them? [was Re: Livecode Dictionary]

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> On Wed, Jan 23, 2019 at 12:39 PM Richard Gaskin wrote:
>>
>> And then there are the countless third-party text editors, some of
>> which have LC-specific add-ons crafted by our community for them,
>> like Trevor's plugin for Atom.  I've been using Atom enough in web
>> development that I'm considering using it with LC.  It's very nice.
>
> The Atom plugin was written by somebody else. I think it was Peter
> Brett. I maintain the plugin for Sublime Text.

Ah, thanks Trevor.  With Sublime, one more option is available to let LC 
cater to every taste.


--
 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: Us and them? [was Re: Livecode Dictionary]

[Trevor DeVore via use-livecode]

On Wed, Jan 23, 2019 at 12:39 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> And then there are the countless third-party text editors, some of which
> have LC-specific add-ons crafted by our community for them, like
> Trevor's plugin for Atom.  I've been using Atom enough in web
> development that I'm considering using it with LC.  It's very nice.
>

The Atom plugin was written by somebody else. I think it was Peter Brett. I
maintain the plugin for Sublime Text.

-- 
Trevor DeVore
CTO - ScreenSteps
www.screensteps.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: Us and them? [was Re: Livecode Dictionary]

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

> What people need most in the Script Editor is to view and edit the
> code itself smoothly, without jitters or delays

Not hard to make one.  A frontScript trapping the editScript message 
lets you do whatever you want.


You can make a stack with a field and a Save button for the simplest 
form as a starting point.


Or clone MC IDE's SE as a starting point.

I used to maintain my own SE for many years, until the big Waddingham 
overhaul that became the foundation for what we use now.  I'm happy 
enough with the current SE that I stopped work on custom ones, but 
they're not hard to make for basic editing; the tough part is adding 
features without impairing performance, a valuable exercise.


And then there are the countless third-party text editors, some of which 
have LC-specific add-ons crafted by our community for them, like 
Trevor's plugin for Atom.  I've been using Atom enough in web 
development that I'm considering using it with LC.  It's very nice.


And of course LC's SE is fully open.  Anyone can fork it, improve it, 
share it with anyone, and even submit the improvements back to the core 
team for inclusion in the master build.


So many solutions so widely available

--
 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: Us and them? [was Re: Livecode Dictionary]

[Richmond via use-livecode]

Oh, let's get campy.

In a perfect world there should not really be a need for "us" and "them" 
camps with LiveCode,
it should cater to all people along a continuum stretching from "us" to 
"them".


While LiveCode may be tending to introduce more "them" features 
(arguably because all
"us" features are already in place), as long as that does not detract or 
break any of the

"us" features there should be nothing to argue about.

When I teach programming with LiveCode I stick to the "us" features 
because I believe skills
learnt there are more basic and portable to other languages; but I am 
not so narrow minded to see
that many of the "them" features have their place and use in the great 
scheme of things.


This is why my "prayer" is that the good folks at LiveCode central only 
deprecate features

when that is absolutely unavoidable.

Richmond.

On 23.01.19 г. 7:13 ч., Richard Gaskin via use-livecode wrote:

Graham Samuel wrote:

> It’s OK, I think, to provide more facilities for the ‘big picture’
> professionals, such as making it easier to use version control and
> to work in teams, and to have an ever-expanding set of functions
> and even platforms; but it’s not OK if this is at the expense of
> the kind of user who doesn’t want to distort the way LC works,
> for example by deprecating stacks that contain both scripts and
> UI elements...

Stack files have not been in any way deprecated.  Nothing has change 
in that regard.


What has happened is exactly what you describe as ideal above: new 
capabilities have been added that support a much wider range of uses 
for LC, while preserving the methods in place for decades. Definite 
win-win.


I think some of this (a lot of this?) sort of discussion comes down to 
deciding who is "us" and who is "them"?


I used to be squarely in what I presume is the "us" camp, and in many 
ways I still prefer the simplicity of with-the-grain xTalk workflows.


But I also work in other languages on things outside of LC, and the 
tools and habits acquired there are also valuable.


Being able to adapt old habits, and enhance the learning of new ones, 
by mixing the best of what I learn from each has become a rewarding 
adventure.


In fact, I'm no longer sure which camp I'm in, since I'm not fully 
"us" and not full "them", but a mish-mash of both and a lot of moving 
around in between those polarities.


As long as each of us can use the workflows we prefer, does the 
distinction matter?




> A typical casualty of this conflict is the cancelling of the ability
> of these ordinary users to add notes to the dictionary, without
> apparent thought for the negative consequences.

I'm surprised no one in the community has made a LC Plugin that acts 
as a custom GitHub client for LC docs.


That would seem the best of both worlds: a pleasant UI that's as easy 
to use as it is to build, and those who prefer working directly on the 
docs in Markdown can continue to do so.


A custom GitHub client for the main repository solves many problems, 
chiefly (and so far uniquely) the issue of having learning materials 
spread out across an ever-broader range of disparate systems.  All the 
advantages of multiple intput streams, with the advantage of a single 
output stream that we all have installed and available with LC.





___
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: Us and them? [was Re: Livecode Dictionary]

[Richmond via use-livecode]

Well, Curry, at the risk of causing you terminal disappointment, I can 
do nothing but support

your request for the thing to be a simple as possible.

"my budget hardware"

my "budgetist" hard ware is a Pentium 4 I picked up 12 years ago, second 
had, for $12 . . .


It has "2000" written on the back of it!

Oddly enough it runs LC 9.0 under Xubuntu 18.04 without a backward glance.

Richmond.

However, having played around with it when I bought it, 12 years ago, 
with Windows XP,

that was glacially slow back then

On 23.01.19 г. 1:06 ч., Curry Kenworthy via use-livecode wrote:


David:

> I'm working on a solution for this

> collaborative with the minimal possible barrier to entry
> integrated into developer workflow - that means the script editor

> personal project wiki's for the software a developer is working
> on directly from the script editor

> Thoughts? Feedback on this?

As a "KISS man" (bet Richmond will have fun with that!) my only advice 
is: Don't make it one bit more complex than it must be.


Meaning simplicity both for maintenance/quality AND for performance 
speed/memory. The Script Editor is already a bit chubby, huffing and 
puffing on many machines during a modest jog, and the Dictionary is 
waddling around even slower and shakier on my budget hardware than I 
move around myself as a handicap person. :D


What people need most in the Script Editor is to view and edit the 
code itself smoothly, without jitters or delays; the primary function 
of SE. After that, debugging and variables and search are very 
helpful. Something like a project wiki would come below all those in 
priority, and better not slow things down any further. A wiki could 
just as well be external to the SE or to LC - but if it plays nice, 
doesn't use cycles or memory or real estate unless it's turned on, 
sounds cool.


Supporting a list of standards and whizbang features is nice, but user 
comments for keywords are the essence. I would just as soon have user 
comments for the Dictionary kept fairly simple and kept in the 
Dictionary, rather than in the SE. But it sounds like you have a dream 
for this, and I'm glad to see the passion. This will be interesting!


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Us and them? [was Re: Livecode Dictionary]

[David Bovill via use-livecode]

Hi Richard - yes indeed Github and GIST integration is part of the mix. I
have libraries for those and have been publishing directly from Livecode
for a few years now so it works well. My thinking on it is to use Github as
an option for offloading (large) data, and keeping the json as metadata -
light and fast to load.

So at the moment the documentation exports small wiki pages (in json) that
link direclty to Github or GIST repositories. Livecode can then use the
json for fast local / native rendering of text - as Curry Kenworthy
comments. Minimal light weight structured json. The json is basically a
serialised array store and can be converted to markdown of HTML in
Javascript, Livecode or pandoc. So it is easy for a developer to do what
they want with it, and there are libraries to make manipulation easy.

What I'm personally finding useful is the ability to write freely while
coding. I've adopted a process of writing code in which I specify it
first + a little quick software sketch. Having a wiki page for every script
gives me the space to do that - then when you publish you have the
documentation and the code in Github or your own web site. This is a
different architecture from notes + comments - it's a wiki page you can
fork and write on.

On Wed, 23 Jan 2019 at 05:13, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Graham Samuel wrote:
>
>  > It’s OK, I think, to provide more facilities for the ‘big picture’
>  > professionals, such as making it easier to use version control and
>  > to work in teams, and to have an ever-expanding set of functions
>  > and even platforms; but it’s not OK if this is at the expense of
>  > the kind of user who doesn’t want to distort the way LC works,
>  > for example by deprecating stacks that contain both scripts and
>  > UI elements...
>
> Stack files have not been in any way deprecated.  Nothing has change in
> that regard.
>
> What has happened is exactly what you describe as ideal above: new
> capabilities have been added that support a much wider range of uses for
> LC, while preserving the methods in place for decades.  Definite win-win.
>
> I think some of this (a lot of this?) sort of discussion comes down to
> deciding who is "us" and who is "them"?
>
> I used to be squarely in what I presume is the "us" camp, and in many
> ways I still prefer the simplicity of with-the-grain xTalk workflows.
>
> But I also work in other languages on things outside of LC, and the
> tools and habits acquired there are also valuable.
>
> Being able to adapt old habits, and enhance the learning of new ones, by
> mixing the best of what I learn from each has become a rewarding adventure.
>
> In fact, I'm no longer sure which camp I'm in, since I'm not fully "us"
> and not full "them", but a mish-mash of both and a lot of moving around
> in between those polarities.
>
> As long as each of us can use the workflows we prefer, does the
> distinction matter?
>
>
>
>  > A typical casualty of this conflict is the cancelling of the ability
>  > of these ordinary users to add notes to the dictionary, without
>  > apparent thought for the negative consequences.
>
> I'm surprised no one in the community has made a LC Plugin that acts as
> a custom GitHub client for LC docs.
>
> That would seem the best of both worlds: a pleasant UI that's as easy to
> use as it is to build, and those who prefer working directly on the docs
> in Markdown can continue to do so.
>
> A custom GitHub client for the main repository solves many problems,
> chiefly (and so far uniquely) the issue of having learning materials
> spread out across an ever-broader range of disparate systems.  All the
> advantages of multiple intput streams, with the advantage of a single
> output stream that we all have installed and available with LC.
>
> --
>   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: Us and them? [was Re: Livecode Dictionary]

[Brian Milby via use-livecode]

I've posted the Documentation Editor code to GitHub.  I'll try to add some
screen shots eventually.

https://github.com/bwmilby/DocEditorPlus
https://github.com/bwmilby/DocEditorPlus/raw/master/DocEditorPlus.livecode

Script index:
https://github.com/bwmilby/DocEditorPlus/blob/master/DocEditorPlus.md

(field "DocText" of card "DocEditor" is where most of the code from the
LiveCode Doc Helper stack landed).

I last worked on this in December 2017 and have not done extensive testing
on it with the latest LC9 release.  I did verify that it did still parse a
LCDOC file and was able to present it in the system browser on my Mac.  The
intended use is for a forked LiveCode repo which includes the dictionary.
There you can use git to create a branch off of develop-9.0 and update
dictionary entries.  Once the edits are done, commit to your new branch and
then on the GitHub site you can create the PR for inclusion into the
dictionary.  However, there is no requirement to have the full repo on your
system, you can just as easily obtain a single LCDOC file and work with it.

Thanks,
Brian

On Tue, Jan 22, 2019 at 12:07 PM David Bovill via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Thanks Brian - if you have the tie to dig out that stack it would be great.
> I have come across the handlers / libs a few times - but as its not
> documented it takes a while to track down :)
>
> It would be great to figure out how to get proper flow back to the main
> project - so any thoughts on that would be great.
>
> On Tue, 22 Jan 2019 at 17:03, Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > GFM syntax is used, but it does go through additional processing before
> > being turned into what we see in the IDE.  All of that code resides in
> the
> > IDE so it can be leveraged to process the updates.  I actually modified a
> > stack that can allow the editing of a doc and then preview it in a
> > browser.  I’ll need to find where that is posted and link here for
> > reference this evening.
> >
> > For license, I was only referring to the flow back into the main project
> > which has the dual commercial/GPL license.
> >
> > Thanks,
> > Brian
> > On Jan 22, 2019, 10:52 AM -0600, David Bovill via use-livecode <
> > use-livecode@lists.runrev.com>, wrote:
> > > On Tue, 22 Jan 2019 at 14:40, Brian Milby via use-livecode <
> > > use-livecode@lists.runrev.com> wrote:
> > >
> > > >
> > > > That license will not allow inclusion into the LiceCode dictionary as
> > it
> > > > requires any derivative works to carry the same license. For
> > integration
> > > > into the LiveCode project a CLA will need to be signed by each author
> > and
> > > > their contributions also submitted with copyright assigned to the
> > company.
> > > >
> > >
> > > The documentation license is GPLv3 (with a modification for ATL and
> > > OpenSSL). It's not an ideal license for documentation - should probably
> > > changed to make things clearer but "on October 8, 2015, Creative
> Commons
> > > concluded
> > > <
> >
> https://creativecommons.org/share-your-work/licensing-considerations/compatible-licenses/
> > >
> > > that the CC BY-SA <https://en.wikipedia.org/wiki/CC_BY-SA> 4.0 is
> > inbound
> > > compatible with the GPLv3". I also spoke with Kevin from the
> Mothership a
> > > couple of times about this issue, and AFAIK there is not intention to
> > > restrict the use / remix of the documentation in this way - ie using
> with
> > > other so called free culture content such as Wikipedia. Here are a few
> > > links:
> > >
> > > - https://bit.ly/2FQfkvH
> > >
> > > Certainly more complicated is the flow back to the mothership for
> > including
> > > the content in the closed source (commercial) distributions - for that
> > we'd
> > > need the CLA, and some sort of care taken to NOT include Wikipedia
> > content
> > > but only completely rewritten content. I'd certainly like to do that -
> so
> > > getting authors to sign the CLA would be useful to figure out for the
> > > community side of things.
> > >
> > > The dictionary uses markdown as the source format. To be easy to
> > > > integrate, it would be a good idea to use that as the storage/native
> > format
> > > > of contributions.
> > >
> > >
> > > Yes - within the json we store Github flavoured markdown. It seems to
> me
> > > tha

Re: Us and them? [was Re: Livecode Dictionary]

[Richard Gaskin via use-livecode]

Graham Samuel wrote:

> It’s OK, I think, to provide more facilities for the ‘big picture’
> professionals, such as making it easier to use version control and
> to work in teams, and to have an ever-expanding set of functions
> and even platforms; but it’s not OK if this is at the expense of
> the kind of user who doesn’t want to distort the way LC works,
> for example by deprecating stacks that contain both scripts and
> UI elements...

Stack files have not been in any way deprecated.  Nothing has change in 
that regard.


What has happened is exactly what you describe as ideal above: new 
capabilities have been added that support a much wider range of uses for 
LC, while preserving the methods in place for decades.  Definite win-win.


I think some of this (a lot of this?) sort of discussion comes down to 
deciding who is "us" and who is "them"?


I used to be squarely in what I presume is the "us" camp, and in many 
ways I still prefer the simplicity of with-the-grain xTalk workflows.


But I also work in other languages on things outside of LC, and the 
tools and habits acquired there are also valuable.


Being able to adapt old habits, and enhance the learning of new ones, by 
mixing the best of what I learn from each has become a rewarding adventure.


In fact, I'm no longer sure which camp I'm in, since I'm not fully "us" 
and not full "them", but a mish-mash of both and a lot of moving around 
in between those polarities.


As long as each of us can use the workflows we prefer, does the 
distinction matter?




> A typical casualty of this conflict is the cancelling of the ability
> of these ordinary users to add notes to the dictionary, without
> apparent thought for the negative consequences.

I'm surprised no one in the community has made a LC Plugin that acts as 
a custom GitHub client for LC docs.


That would seem the best of both worlds: a pleasant UI that's as easy to 
use as it is to build, and those who prefer working directly on the docs 
in Markdown can continue to do so.


A custom GitHub client for the main repository solves many problems, 
chiefly (and so far uniquely) the issue of having learning materials 
spread out across an ever-broader range of disparate systems.  All the 
advantages of multiple intput streams, with the advantage of a single 
output stream that we all have installed and available with LC.


--
 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: Us and them? [was Re: Livecode Dictionary]

[Curry Kenworthy via use-livecode]

David:

> I'm working on a solution for this

> collaborative with the minimal possible barrier to entry
> integrated into developer workflow - that means the script editor

> personal project wiki's for the software a developer is working
> on directly from the script editor

> Thoughts? Feedback on this?

As a "KISS man" (bet Richmond will have fun with that!) my only advice 
is: Don't make it one bit more complex than it must be.


Meaning simplicity both for maintenance/quality AND for performance 
speed/memory. The Script Editor is already a bit chubby, huffing and 
puffing on many machines during a modest jog, and the Dictionary is 
waddling around even slower and shakier on my budget hardware than I 
move around myself as a handicap person. :D


What people need most in the Script Editor is to view and edit the code 
itself smoothly, without jitters or delays; the primary function of SE. 
After that, debugging and variables and search are very helpful. 
Something like a project wiki would come below all those in priority, 
and better not slow things down any further. A wiki could just as well 
be external to the SE or to LC - but if it plays nice, doesn't use 
cycles or memory or real estate unless it's turned on, sounds cool.


Supporting a list of standards and whizbang features is nice, but user 
comments for keywords are the essence. I would just as soon have user 
comments for the Dictionary kept fairly simple and kept in the 
Dictionary, rather than in the SE. But it sounds like you have a dream 
for this, and I'm glad to see the passion. This will be interesting!


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Us and them? [was Re: Livecode Dictionary]

[David Bovill via use-livecode]

Thanks Brian - if you have the tie to dig out that stack it would be great.
I have come across the handlers / libs a few times - but as its not
documented it takes a while to track down :)

It would be great to figure out how to get proper flow back to the main
project - so any thoughts on that would be great.

On Tue, 22 Jan 2019 at 17:03, Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> GFM syntax is used, but it does go through additional processing before
> being turned into what we see in the IDE.  All of that code resides in the
> IDE so it can be leveraged to process the updates.  I actually modified a
> stack that can allow the editing of a doc and then preview it in a
> browser.  I’ll need to find where that is posted and link here for
> reference this evening.
>
> For license, I was only referring to the flow back into the main project
> which has the dual commercial/GPL license.
>
> Thanks,
> Brian
> On Jan 22, 2019, 10:52 AM -0600, David Bovill via use-livecode <
> use-livecode@lists.runrev.com>, wrote:
> > On Tue, 22 Jan 2019 at 14:40, Brian Milby via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > >
> > > That license will not allow inclusion into the LiceCode dictionary as
> it
> > > requires any derivative works to carry the same license. For
> integration
> > > into the LiveCode project a CLA will need to be signed by each author
> and
> > > their contributions also submitted with copyright assigned to the
> company.
> > >
> >
> > The documentation license is GPLv3 (with a modification for ATL and
> > OpenSSL). It's not an ideal license for documentation - should probably
> > changed to make things clearer but "on October 8, 2015, Creative Commons
> > concluded
> > <
> https://creativecommons.org/share-your-work/licensing-considerations/compatible-licenses/
> >
> > that the CC BY-SA <https://en.wikipedia.org/wiki/CC_BY-SA> 4.0 is
> inbound
> > compatible with the GPLv3". I also spoke with Kevin from the Mothership a
> > couple of times about this issue, and AFAIK there is not intention to
> > restrict the use / remix of the documentation in this way - ie using with
> > other so called free culture content such as Wikipedia. Here are a few
> > links:
> >
> > - https://bit.ly/2FQfkvH
> >
> > Certainly more complicated is the flow back to the mothership for
> including
> > the content in the closed source (commercial) distributions - for that
> we'd
> > need the CLA, and some sort of care taken to NOT include Wikipedia
> content
> > but only completely rewritten content. I'd certainly like to do that - so
> > getting authors to sign the CLA would be useful to figure out for the
> > community side of things.
> >
> > The dictionary uses markdown as the source format. To be easy to
> > > integrate, it would be a good idea to use that as the storage/native
> format
> > > of contributions.
> >
> >
> > Yes - within the json we store Github flavoured markdown. It seems to me
> > that the documentation is not in markdown though?
> >
> > -
> >
> https://github.com/livecode/livecode/blob/develop/docs/dictionary/function/URLEncode.lcdoc
> > ___
> > 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: Us and them? [was Re: Livecode Dictionary]

[Brian Milby via use-livecode]

GFM syntax is used, but it does go through additional processing before being 
turned into what we see in the IDE.  All of that code resides in the IDE so it 
can be leveraged to process the updates.  I actually modified a stack that can 
allow the editing of a doc and then preview it in a browser.  I’ll need to find 
where that is posted and link here for reference this evening.

For license, I was only referring to the flow back into the main project which 
has the dual commercial/GPL license.

Thanks,
Brian
On Jan 22, 2019, 10:52 AM -0600, David Bovill via use-livecode 
, wrote:
> On Tue, 22 Jan 2019 at 14:40, Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> >
> > That license will not allow inclusion into the LiceCode dictionary as it
> > requires any derivative works to carry the same license. For integration
> > into the LiveCode project a CLA will need to be signed by each author and
> > their contributions also submitted with copyright assigned to the company.
> >
>
> The documentation license is GPLv3 (with a modification for ATL and
> OpenSSL). It's not an ideal license for documentation - should probably
> changed to make things clearer but "on October 8, 2015, Creative Commons
> concluded
> <https://creativecommons.org/share-your-work/licensing-considerations/compatible-licenses/>
> that the CC BY-SA <https://en.wikipedia.org/wiki/CC_BY-SA> 4.0 is inbound
> compatible with the GPLv3". I also spoke with Kevin from the Mothership a
> couple of times about this issue, and AFAIK there is not intention to
> restrict the use / remix of the documentation in this way - ie using with
> other so called free culture content such as Wikipedia. Here are a few
> links:
>
> - https://bit.ly/2FQfkvH
>
> Certainly more complicated is the flow back to the mothership for including
> the content in the closed source (commercial) distributions - for that we'd
> need the CLA, and some sort of care taken to NOT include Wikipedia content
> but only completely rewritten content. I'd certainly like to do that - so
> getting authors to sign the CLA would be useful to figure out for the
> community side of things.
>
> The dictionary uses markdown as the source format. To be easy to
> > integrate, it would be a good idea to use that as the storage/native format
> > of contributions.
>
>
> Yes - within the json we store Github flavoured markdown. It seems to me
> that the documentation is not in markdown though?
>
> -
> https://github.com/livecode/livecode/blob/develop/docs/dictionary/function/URLEncode.lcdoc
> ___
> 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: Us and them? [was Re: Livecode Dictionary]

[David Bovill via use-livecode]

On Tue, 22 Jan 2019 at 14:40, Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> That license will not allow inclusion into the LiceCode dictionary as it
> requires any derivative works to carry the same license.  For integration
> into the LiveCode project a CLA will need to be signed by each author and
> their contributions also submitted with copyright assigned to the company.
>

The documentation license is GPLv3 (with a modification for  ATL and
OpenSSL). It's not an ideal license for documentation - should probably
changed to make things clearer but "on October 8, 2015, Creative Commons
concluded
<https://creativecommons.org/share-your-work/licensing-considerations/compatible-licenses/>
that the CC BY-SA <https://en.wikipedia.org/wiki/CC_BY-SA> 4.0 is inbound
compatible with the GPLv3". I also spoke with Kevin from the Mothership a
couple of times about this issue, and AFAIK there is not intention to
restrict the use / remix of the documentation in this way - ie using with
other so called free culture content such as Wikipedia. Here are a few
links:

   - https://bit.ly/2FQfkvH

Certainly more complicated is the flow back to the mothership for including
the content in the closed source (commercial) distributions - for that we'd
need the CLA, and some sort of care taken to NOT include Wikipedia content
but only completely rewritten content. I'd certainly like to do that - so
getting authors to sign the CLA would be useful to figure out for the
community side of things.

The dictionary uses markdown as the source format.  To be easy to
> integrate, it would be a good idea to use that as the storage/native format
> of contributions.


Yes - within the json we store Github flavoured markdown. It seems to me
that the documentation is not in markdown though?

   -
   
https://github.com/livecode/livecode/blob/develop/docs/dictionary/function/URLEncode.lcdoc
___
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: Us and them? [was Re: Livecode Dictionary]

[prothero--- via use-livecode]

It sounds very ambitious. My main suggestion was for a shareable user additions 
part of the dictionary that could be incorporated into the main dictionary at 
some later date, if useful. It is so common to see user comments on web 
content, that I don’t see how there could be a problem with licensing. Of 
course, comments would need to be limited to valid users, to avoid spammers. 
There could even be a star rating system to identify particularly useful 
comments.

For this project, I personally would recommend keeping it as simple as possible 
and keeping a wall between the main vetted part of the dictionary and the user 
comments, until a revision, using git, that incorporates the information from 
the user comments is performed.

That said, I really appreciate the thoughtful ideas and help that regularly get 
posted on this list.

Best,
Bill

William Prothero
http://earthlearningsolutions.org

> On Jan 22, 2019, at 7:15 AM, Graham Samuel via use-livecode 
>  wrote:
> 
> Just to clarify, I didn’t really mean to suggest that there was a plan - it’s 
> just that a lot of the creative energy around LC and its development seems to 
> be going away from this as if it were bad, basically because it’s hard to do 
> version control on binary stacks, as far as I can see. I do understand that 
> separating UI elements and code is good practice, but for many types of 
> projects it can be taken too far, I think. I am all for libraries, for 
> example, but I don’t want to strip my stacks right down to a graphical shell. 
> LC and its predecessors aren’t really designed for that - they are 
> essentially systems where interaction with graphic elements via a message 
> path is the key idea, which means that there **must** be some level of 
> scripting at the UI level. To try to suggest that good practice takes that 
> away completely, or as near completely as ingenuity can make it, seems to me 
> a distortion of an really excellent model of interaction - but that’s just my 
> opinion, of course.
> 
> Graham
> 
>>> On 22 Jan 2019, at 01:25, Curry Kenworthy via use-livecode 
>>>  wrote:
>>> 
>>> but it’s not OK if this is at the expense of the kind of user
>>> who doesn’t want to distort the way LC works, for example by
>>> deprecating stacks that contain both scripts and UI elements
>> 
>> I wasn't aware of a plan or push to deprecate those - I don't follow all 
>> threads, but I emphatically hope not; bad idea! I want LC stacks to remain 
>> stacks. Easy to use and learn, self-contained, smart.
> 
> ___
> 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: Us and them? [was Re: Livecode Dictionary]

[Graham Samuel via use-livecode]

Just to clarify, I didn’t really mean to suggest that there was a plan - it’s 
just that a lot of the creative energy around LC and its development seems to 
be going away from this as if it were bad, basically because it’s hard to do 
version control on binary stacks, as far as I can see. I do understand that 
separating UI elements and code is good practice, but for many types of 
projects it can be taken too far, I think. I am all for libraries, for example, 
but I don’t want to strip my stacks right down to a graphical shell. LC and its 
predecessors aren’t really designed for that - they are essentially systems 
where interaction with graphic elements via a message path is the key idea, 
which means that there **must** be some level of scripting at the UI level. To 
try to suggest that good practice takes that away completely, or as near 
completely as ingenuity can make it, seems to me a distortion of an really 
excellent model of interaction - but that’s just my opinion, of course.

Graham

> On 22 Jan 2019, at 01:25, Curry Kenworthy via use-livecode 
>  wrote:
> 
> > but it’s not OK if this is at the expense of the kind of user
> > who doesn’t want to distort the way LC works, for example by
> > deprecating stacks that contain both scripts and UI elements
> 
> I wasn't aware of a plan or push to deprecate those - I don't follow all 
> threads, but I emphatically hope not; bad idea! I want LC stacks to remain 
> stacks. Easy to use and learn, self-contained, smart.

___
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: Us and them? [was Re: Livecode Dictionary]

[Brian Milby via use-livecode]

Two comments initially:

That license will not allow inclusion into the LiceCode dictionary as it 
requires any derivative works to carry the same license.  For integration into 
the LiveCode project a CLA will need to be signed by each author and their 
contributions also submitted with copyright assigned to the company.

The dictionary uses markdown as the source format.  To be easy to integrate, it 
would be a good idea to use that as the storage/native format of contributions.

Sounds much more ambitious than what I was thinking about (trying to figure out 
how to leverage the TinyDictionary notes feature for collaboration).  Looking 
forward to seeing more.

Thanks,
Brian
On Jan 22, 2019, 6:20 AM -0600, David Bovill via use-livecode 
, wrote:
> I'm working on a solution for this - it's kind of ambitious and won't be
> ready to share publicly for about 3 months at a guess - but I'm happy to
> share it with anyone who want to use GitHub and get deep into the issue.
>
> *Quick outline of dictionary strategy*
>
> 1. It should be collaborative with the minimal possible barrier to entry
> (wikipedia style)
> 2. It should be personal - every user is totally free to write and
> over-write their own notes / take on the content. (decentralised version
> control - aka git strategy)
> 3. It should be organised - that is all the version developers use to
> write on, should integrate functionally into the git-workflow editorial
> managed by the mothership.
> 4. It should be useful in your own projects and integrated into
> developer workflow - that means the script editor
>
> The elements come together in an architecture where we create personal
> project wiki's for the software a developer is working on directly from the
> script editor - with wiki pages for projects, stacks, scripts and handlers.
> These project wiki's should be self-contained but link to the general
> Livecode Dictionary. Should you wish to personalise / write more extensive
> notes than available in the "Livecode Dictionary" you can fork teh page to
> create your own personalised version.
>
> *Some basic data structure concepts*
>
> 1. The dictionary content should be directly useable by Livecode and a
> web browser
> 2. The dictionary content should take full advantage of multimedia
> content including audio and video
> 3. The dictionary content should be standards based, work with version
> control, and be capable of things like digital signatures and other metadata
> 4. The dictionary content should be licensed with a Wikipedia compatible
> license so that we can mix in Wikipedia and similar content on software
> development
>
> To that end I've decided to standardise on a JSON format - as both the web
> browser, and Livecode can process it fast. I use a node project for the
> online version, and have a range of tools for publishing directly from the
> script editor, and importing Wikipedia content.
>
> *Collaboration and feedback*
> Would be great to have feedback on this strategy. My guess is it might not
> be clear, and that the only way to effectively communicate it will be a
> short screencast. I hope to add that this week, and maybe make a quick
> video demo. But the main thing to note - is all the code is open source and
> on Github, and the content is all CC-by-SA 4.0
> <https://creativecommons.org/licenses/by-sa/4.0/>. The design is to be able
> to run it locally, and collaborate online - so you can do your own thing.
> Even host a server yourself.
>
> Thoughts? Feedback on this?
>
>
> On Tue, 22 Jan 2019 at 00:26, Curry Kenworthy via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> >
> > Graham:
> >
> > > a conflict between the “everyone can code” philosophy [...]
> > > and the perceived need to be more professional and serious as a
> > > player in the whole software development arena.
> >
> > Well-said!
> >
> > Nor should it be assumed that pros and trend-chasers are always
> > serious/correct and others are not - I've seen some sloppy "pros" and
> > some excellent beginners. People at all levels of software or LC can do
> > a great job. (Or not.)
> >
> > Likewise the trap of assuming that following new trends always brings
> > better results. Imagine a Venn diagram between software innovations,
> > trends, and another important factor such as quality or efficiency.
> > Sometimes or some situations they go together, sometimes not.
> >
> > > but it’s not OK if this is at the expense of the kind of user
> > > who doesn’t want to distort the way LC works, for example by
> > > deprecating stacks that contain both scripts and UI element

Re: Us and them? [was Re: Livecode Dictionary]

[David Bovill via use-livecode]

I'm working on a solution for this - it's kind of ambitious and won't be
ready to share publicly for about 3 months at a guess - but I'm happy to
share it with anyone  who want to use GitHub and get deep into the issue.

*Quick outline of dictionary strategy*

   1. It should be collaborative with the minimal possible barrier to entry
   (wikipedia style)
   2. It should be personal - every user is totally free to write and
   over-write their own notes / take on the content. (decentralised version
   control - aka git strategy)
   3. It should be organised - that is all the version developers use to
   write on, should integrate functionally into the git-workflow editorial
   managed by the mothership.
   4. It should be useful in your own projects and integrated into
   developer workflow - that means the script editor

The elements come together in an architecture where we create personal
project wiki's for the software a developer is working on directly from the
script editor - with wiki pages for projects, stacks, scripts and handlers.
These project wiki's should be self-contained but link to the general
Livecode Dictionary. Should you wish to personalise / write more extensive
notes than available in the "Livecode Dictionary" you can fork teh page to
create your own personalised version.

*Some basic data structure concepts*

   1. The dictionary content should be directly useable by Livecode and a
   web browser
   2. The dictionary content should take full advantage of multimedia
   content including audio and video
   3. The dictionary content should be standards based, work with version
   control, and be capable of things like digital signatures and other metadata
   4. The dictionary content should be licensed with a Wikipedia compatible
   license so that we can mix in Wikipedia and similar content on software
   development

To that end I've decided to standardise on a JSON format - as both the web
browser, and Livecode can process it fast. I use a node project for the
online version, and have a range of tools for publishing directly from the
script editor, and importing Wikipedia content.

*Collaboration and feedback*
Would be great to have feedback on this strategy. My guess is it might not
be clear, and that the only way to effectively communicate it will be a
short screencast. I hope to add that this week, and maybe make a quick
video demo. But the main thing to note - is all the code is open source and
on Github, and the content is all CC-by-SA 4.0
<https://creativecommons.org/licenses/by-sa/4.0/>. The design is to be able
to run it locally, and collaborate online - so you can do your own thing.
Even host a server yourself.

Thoughts? Feedback on this?


On Tue, 22 Jan 2019 at 00:26, Curry Kenworthy via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> Graham:
>
>  > a conflict between the “everyone can code” philosophy [...]
>  > and the perceived need to be more professional and serious as a
>  > player in the whole software development arena.
>
> Well-said!
>
> Nor should it be assumed that pros and trend-chasers are always
> serious/correct and others are not - I've seen some sloppy "pros" and
> some excellent beginners. People at all levels of software or LC can do
> a great job. (Or not.)
>
> Likewise the trap of assuming that following new trends always brings
> better results. Imagine a Venn diagram between software innovations,
> trends, and another important factor such as quality or efficiency.
> Sometimes or some situations they go together, sometimes not.
>
>  > but it’s not OK if this is at the expense of the kind of user
>  > who doesn’t want to distort the way LC works, for example by
>  > deprecating stacks that contain both scripts and UI elements
>
> I wasn't aware of a plan or push to deprecate those - I don't follow all
> threads, but I emphatically hope not; bad idea! I want LC stacks to
> remain stacks. Easy to use and learn, self-contained, smart.
>
> Git is also smart, very useful for many situations, but not superior in
> all situations. There are trade-offs, just as there are with agile dev.
> Savvy people are aware of pros and cons. Trend-chasers: maybe not aware.
> Good to have both options.
>
> (If this is referencing my own remarks about mixing data and UI for
> files saved at compiled runtime, that's a completely different matter.)
>
>  > cancelling of the ability of these ordinary users to add notes
>  > to the dictionary
>
> Yep, it's worthwhile to keep LC 6 handy for those notes! Highly
> valuable. Continuing user comments for LC 9+ would be a smart move.
>
> Richmond:
>
>  > worrying about Microsoft, if one spends too much time on it can
>  > become fairly unhealthy: and what about A

Re: Us and them? [was Re: Livecode Dictionary]

[Curry Kenworthy via use-livecode]

Graham:

> a conflict between the “everyone can code” philosophy [...]
> and the perceived need to be more professional and serious as a
> player in the whole software development arena.

Well-said!

Nor should it be assumed that pros and trend-chasers are always 
serious/correct and others are not - I've seen some sloppy "pros" and 
some excellent beginners. People at all levels of software or LC can do 
a great job. (Or not.)


Likewise the trap of assuming that following new trends always brings 
better results. Imagine a Venn diagram between software innovations, 
trends, and another important factor such as quality or efficiency. 
Sometimes or some situations they go together, sometimes not.


> but it’s not OK if this is at the expense of the kind of user
> who doesn’t want to distort the way LC works, for example by
> deprecating stacks that contain both scripts and UI elements

I wasn't aware of a plan or push to deprecate those - I don't follow all 
threads, but I emphatically hope not; bad idea! I want LC stacks to 
remain stacks. Easy to use and learn, self-contained, smart.


Git is also smart, very useful for many situations, but not superior in 
all situations. There are trade-offs, just as there are with agile dev. 
Savvy people are aware of pros and cons. Trend-chasers: maybe not aware. 
Good to have both options.


(If this is referencing my own remarks about mixing data and UI for 
files saved at compiled runtime, that's a completely different matter.)


> cancelling of the ability of these ordinary users to add notes
> to the dictionary

Yep, it's worthwhile to keep LC 6 handy for those notes! Highly 
valuable. Continuing user comments for LC 9+ would be a smart move.


Richmond:

> worrying about Microsoft, if one spends too much time on it can
> become fairly unhealthy: and what about Apple, Canonical, and
> so on and so forth?

Tribal identity marketing; be careful for people coming after you with 
OS logos and pitchforks, but I totally agree. Tribalism mindset works 
pretty well for group survival, but fails at most other things including 
accurate assessments. Fun social experiment: "MS and Apple are not 
nearly as different as their fans like to think." :D


> the Dictionary inwith LiveCode to regain its previous functionality
> so we can help each other just that wee bit more.

Yep, that would be helpful.

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.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: Us and them? [was Re: Livecode Dictionary]

[prothero--- via use-livecode]

I agree with Richmond. There are many great suggestions for coding tricks, and 
workarounds that occur on this list. That wisdom remains in the archives, but 
is not necessarily obviously accessible to those of us who may be exploring an 
unfamiliar or poorly documented technique. The dictionary is the first place I 
go. Links to comments about use and idiosyncrasies would be very helpful and it 
seems to me a “buyer beware” notice could mitigate and mothership liability. 
Even though the documentation for using git is available, it is still a hurdle 
to overcome and does discourage input from many of us.

Adding a commenting capability seems like an ideal livecode application. The 
dictionary could be still on git with a link or inclusion of text from a 
commenting app with comments linked to the relevant entry. Information in 
comments might occasionally be incorporated into the main dictionary entry, 
then purged as appropriate.

It is also unhelpful the the user guide, accessed in the dictionary window, is 
not searchable.

Best,
Bill

William Prothero
http://es.earthednet.org

> On Jan 21, 2019, at 12:13 PM, Richmond via use-livecode 
>  wrote:
> 
> Oh, fruit-flavoured socks . . .
> 
> If many developers do not trust Microsoft, who can change their term anytime, 
> and
> no one knows what they will do . . .
> 
> One could wonder about the same sort of thing about other software 
> manufacturers;
> even those who keep changing their commercial licensing arrangements in a way 
> that
> sometimes seems haphazard and unpredictable . . .
> 
> Trusting software developers, especially developers on who one's own efforts 
> depend is always
> going to be an "iffy" thing, but so, then, is almost everything in life one 
> has to rely on
> that involves other people; so worrying about Microsoft, if one spends too 
> much time on
> it can become fairly unhealthy: and what about Apple, Canonical, and so on 
> and so forth?
> 
> -
> 
> My objection to bunging user stuff for the LiveCode dictionary on GitHub has 
> nothing to
> do with Microsoft, but has a lot to do with accessibility.
> 
> Way back when with LiveCode 4.5 end-user comments/feedback/hints in the 
> Dictionary
> appeared almost as soon as someone who added them opened LC while they were 
> connected
> to the internet . . .
> 
> I also (possibly incorrectly) had a feeling those comments "came through" 
> unfiltered by the mothership.
> 
> Now I would suppose stuff going to GitHub does not get rolled into the 
> Dictionary until the
> next LC release, and only if the mothership lieutenants approve it.
> 
> Now, if I am messing around "trying to be clever" with LiveCode I generally 
> need and am grateful for
> all the help I can get: and if Fred Flintstone (that well-known LC developer) 
> found something out
> this morning which will serve me well this afternoon I have no great urge to 
> wait 6-8 weeks for
> that to filter through to me.
> 
> So . . . it would be lovely if, unless there are serious objections,
> the Dictionary inwith LiveCode to regain its previous functionality so we can 
> help each other
> just that wee bit more.
> 
> Richmond.
> 
>> On 21.01.19 0:22, Rick Harrison via use-livecode wrote:
>> Many developers do not trust Microsoft, and neither do I.
>> Things may be fine right now, but it is the future that
>> concerns me more.  They can change their terms at
>> anytime, and no one knows what they will do.
>> 
>> Just a word of caution.
>> 
>> Cheers,
>> 
>> Rick
>> 
>> 
>> 
>>> On Jan 20, 2019, at 2:50 PM, Richard Gaskin via use-livecode 
>>>  wrote:
>>> 
>>> Rick Harrison wrote:
>>> 
>>>> I do not believe most of LC’s users are interested in signing up
>>>> for GitHub and having to sign an agreement with new owner Microsoft
>>>> too.
>>> In what way has Girhub's TOS been changed after Microsoft's acquisition 
>>> which would be a concern to LiveCode developers?
>>> 
>>> -- 
>>> 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: Us and them? [was Re: Livecode Dictionary]

[Richmond via use-livecode]

Oh, fruit-flavoured socks . . .

If many developers do not trust Microsoft, who can change their term 
anytime, and

no one knows what they will do . . .

One could wonder about the same sort of thing about other software 
manufacturers;
even those who keep changing their commercial licensing arrangements in 
a way that

sometimes seems haphazard and unpredictable . . .

Trusting software developers, especially developers on who one's own 
efforts depend is always
going to be an "iffy" thing, but so, then, is almost everything in life 
one has to rely on
that involves other people; so worrying about Microsoft, if one spends 
too much time on
it can become fairly unhealthy: and what about Apple, Canonical, and so 
on and so forth?


-

My objection to bunging user stuff for the LiveCode dictionary on GitHub 
has nothing to

do with Microsoft, but has a lot to do with accessibility.

Way back when with LiveCode 4.5 end-user comments/feedback/hints in the 
Dictionary
appeared almost as soon as someone who added them opened LC while they 
were connected

to the internet . . .

I also (possibly incorrectly) had a feeling those comments "came 
through" unfiltered by the mothership.


Now I would suppose stuff going to GitHub does not get rolled into the 
Dictionary until the

next LC release, and only if the mothership lieutenants approve it.

Now, if I am messing around "trying to be clever" with LiveCode I 
generally need and am grateful for
all the help I can get: and if Fred Flintstone (that well-known LC 
developer) found something out
this morning which will serve me well this afternoon I have no great 
urge to wait 6-8 weeks for

that to filter through to me.

So . . . it would be lovely if, unless there are serious objections,
the Dictionary inwith LiveCode to regain its previous functionality so 
we can help each other

just that wee bit more.

Richmond.

On 21.01.19 0:22, Rick Harrison via use-livecode wrote:

Many developers do not trust Microsoft, and neither do I.
Things may be fine right now, but it is the future that
concerns me more.  They can change their terms at
anytime, and no one knows what they will do.

Just a word of caution.

Cheers,

Rick




On Jan 20, 2019, at 2:50 PM, Richard Gaskin via use-livecode 
 wrote:

Rick Harrison wrote:


I do not believe most of LC’s users are interested in signing up
for GitHub and having to sign an agreement with new owner Microsoft
too.

In what way has Girhub's TOS been changed after Microsoft's acquisition which 
would be a concern to LiveCode developers?

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



___
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: Us and them? [was Re: Livecode Dictionary]

[Rick Harrison via use-livecode]

Many developers do not trust Microsoft, and neither do I.
Things may be fine right now, but it is the future that
concerns me more.  They can change their terms at
anytime, and no one knows what they will do.

Just a word of caution.

Cheers,

Rick



> On Jan 20, 2019, at 2:50 PM, Richard Gaskin via use-livecode 
>  wrote:
> 
> Rick Harrison wrote:
> 
> > I do not believe most of LC’s users are interested in signing up
> > for GitHub and having to sign an agreement with new owner Microsoft
> > too.
> 
> In what way has Girhub's TOS been changed after Microsoft's acquisition which 
> would be a concern to LiveCode developers?
> 
> -- 
> 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: Livecode Dictionary

[Geoff Canyon via use-livecode]

On Sun, Jan 20, 2019 at 12:07 PM Tom Glod via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> The permissions are over the top, but not intentional I am sure.
>

Agreed. I'm just waiting to see if:

1. My changes go in with the current state of affairs.
2. Someone from LC re-ups their cert, and hopefully with more reasonable
requirements.
3. Nothing happens.
___
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: Us and them? [was Re: Livecode Dictionary]

[Richard Gaskin via use-livecode]

Rick Harrison wrote:

> I do not believe most of LC’s users are interested in signing up
> for GitHub and having to sign an agreement with new owner Microsoft
> too.

In what way has Girhub's TOS been changed after Microsoft's acquisition 
which would be a concern to LiveCode developers?


--
 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: Livecode Dictionary

[Tom Glod via use-livecode]

I think the LC team set things up so that its convenient for them in their
workflow of growing & maintaining Livecode, ...its not so much our
convenience per se.

I think removing notes from the dictionary is a step backwards.  This one
needs correction.

The permissions are over the top, but not intentional I am sure.



On Sun, Jan 20, 2019 at 2:05 PM Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On Sun, Jan 20, 2019 at 6:47 AM Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > LiveCode can’t use your contribution without the CLA.  Someone from LC
> May
> > need to clarify the details.  Since they release code as GPL and
> > Commercial, we need to assign copyright to them for any changes we make
> and
> > also assert that we are not introducing code where we are not able to
> > assign said copyright.
> >
> > As long as GitHub can’t verify the CLA, I don’t think the PR can move
> > forward.
> >
> > Thanks,
> > Brian
> >
>
> Again, not that I actually ascribe bad motives to the LC crew, but it seems
> excessive to want write access to my profile.
>
> gc
> ___
> 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 Dictionary

[Richard Gaskin via use-livecode]

Rick Harrison wrote:

> Now that Microsoft owns GitHub perhaps LC should consider
> moving everything over to some other entity such as Bitbucket,
> or SourceForge.
>
> What do you think?

Personally, I think if it's good enough for the world's largest software 
project, the open source Linux kernel, it's probably good enough for 
LiveCode.


https://github.com/torvalds/linux/tree/master/kernel

--
 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: Livecode Dictionary

[Geoff Canyon via use-livecode]

On Sun, Jan 20, 2019 at 6:47 AM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> LiveCode can’t use your contribution without the CLA.  Someone from LC May
> need to clarify the details.  Since they release code as GPL and
> Commercial, we need to assign copyright to them for any changes we make and
> also assert that we are not introducing code where we are not able to
> assign said copyright.
>
> As long as GitHub can’t verify the CLA, I don’t think the PR can move
> forward.
>
> Thanks,
> Brian
>

Again, not that I actually ascribe bad motives to the LC crew, but it seems
excessive to want write access to my profile.

gc
___
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 Dictionary

[Geoff Canyon via use-livecode]

On Sun, Jan 20, 2019 at 6:10 AM Trevor DeVore via use-livecode <
use-livecode@lists.runrev.com> wrote:

>
> The newsletter also lists documentation bugs which need fixing. Here is a
> link to the latest edition:
>
>
> https://livecode.github.io/this-week-in-livecode/issue/2019/01/14/this-week-in-livecode-163.html


Nice!
___
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: Us and them? [was Re: Livecode Dictionary]

[Rick Harrison via use-livecode]

I agree that LC should be as simple as possible to use
and to contribute to for most users.  I do not believe most
of LC’s users are interested in signing up for GitHub and
having to sign an agreement with new owner Microsoft too.
User’s want a simple interface that is easy to use.  Scattering
LC resources all over the internet doesn’t fit that model, yet
that seems to be what we are dealing with now.

Just my 2 cents for the day.

Thanks for reading!

Rick

> On Jan 20, 2019, at 8:44 AM, Graham Samuel via use-livecode 
>  wrote:
> 
> Just covering this one point of Geoff’s in the Dictionary discussion. I agree 
> with his comment, and I think it’s symptomatic of a problem with the 
> development of LC in the last few years: there is IMHO a conflict between the 
> “everyone can code” philosophy that LC inherited (and greatly enriched) from 
> Hypercard, and the perceived need to be more professional and serious as a 
> player in the whole software development arena. 
> 
> It’s OK, I think, to provide more facilities for the ‘big picture’ 
> professionals, such as making it easier to use version control and to work in 
> teams, and to have an ever-expanding set of functions and even platforms; but 
> it’s not OK if this is at the expense of the kind of user who doesn’t want to 
> distort the way LC works, for example by deprecating stacks that contain both 
> scripts and UI elements, and who wants to avoid going outside the LC comfort 
> zone as far as is possible, for example to need to use github, or to struggle 
> alone with the elaborate deployment techniques now demanded by the big 
> players in software distribution. This ‘old fashioned’ type of user needs a 
> very clear, understandable environment, and a lot of packaged help with 
> deployment on the various platforms. I am probably hors de combat now, but I 
> would put myself in the second category, despite having a quite technical 
> background in software development.
> 
> A typical casualty of this conflict is the cancelling of the ability of these 
> ordinary users to add notes to the dictionary, without apparent thought for 
> the negative consequences.
> 
> Just my two (tottering) euro-cents.
> 
> Graham
> 
>> On 20 Jan 2019, at 03:59, Geoff Canyon via use-livecode 
>>  wrote:
>> 
>> 1. Not everyone (very few people?) understand how git/GitHub works.
>> 2. Even if you have a reasonable grasp of how to use git it's not obvious
>> how to contribute to the dictionary using git. 
> 
> ___
> 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 Dictionary

[Rick Harrison via use-livecode]

Now that Microsoft owns GitHub perhaps LC should consider
moving everything over to some other entity such as Bitbucket, 
or SourceForge.

What do you think?

Rick




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

[Brian Milby via use-livecode]

LiveCode can’t use your contribution without the CLA.  Someone from LC May need 
to clarify the details.  Since they release code as GPL and Commercial, we need 
to assign copyright to them for any changes we make and also assert that we are 
not introducing code where we are not able to assign said copyright.

As long as GitHub can’t verify the CLA, I don’t think the PR can move forward.

Thanks,
Brian
On Jan 20, 2019, 12:17 AM -0600, Geoff Canyon via use-livecode 
, wrote:
> On Sat, Jan 19, 2019 at 8:22 PM Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > I agree that the dictionary isn’t the easiest to update without a GutHib
> > client, but dictionary updates can be done completely in a browser.
>
>
> Yep, I figured that out after I spent several minutes looking for the
> dictionary data and poking through the dictionary stack. I already cloned
> LiveCode some time ago, and GitHub was smart enough to realize that even
> though my clone is substantially out of date, the merge entry hasn't
> changed. So all i had to do was find it, edit (my copy of) it, save, and
> issue a pull request.
>
> And then notice a few minutes later that LC was asking me to sign the
> waiver and tie my accounts together. I've done everything but that last
> bit, so we'll see what happens.
>
> gc
> ___
> 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 Dictionary

[Trevor DeVore via use-livecode]

On Sat, Jan 19, 2019 at 9:00 PM Geoff Canyon via use-livecode <
use-livecode@lists.runrev.com> wrote:

> 1. Not everyone (very few people?) understand how git/GitHub works.
> 2. Even if you have a reasonable grasp of how to use git it's not obvious
> how to contribute to the dictionary using git.


The “This Week In LiveCode” newsletter contains links to two screencasts I
made that demonstrate how to submit dictionary changes through the GitHub
web interface. There is still the process of setting up an account and
signing the LiveCode agreement. But submitting the actual change through
the browser is pretty easy.

The newsletter also lists documentation bugs which need fixing. Here is a
link to the latest edition:

https://livecode.github.io/this-week-in-livecode/issue/2019/01/14/this-week-in-livecode-163.html

-- 
Trevor DeVore
ScreenSteps

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

Us and them? [was Re: Livecode Dictionary]

[Graham Samuel via use-livecode]

Just covering this one point of Geoff’s in the Dictionary discussion. I agree 
with his comment, and I think it’s symptomatic of a problem with the 
development of LC in the last few years: there is IMHO a conflict between the 
“everyone can code” philosophy that LC inherited (and greatly enriched) from 
Hypercard, and the perceived need to be more professional and serious as a 
player in the whole software development arena. 

It’s OK, I think, to provide more facilities for the ‘big picture’ 
professionals, such as making it easier to use version control and to work in 
teams, and to have an ever-expanding set of functions and even platforms; but 
it’s not OK if this is at the expense of the kind of user who doesn’t want to 
distort the way LC works, for example by deprecating stacks that contain both 
scripts and UI elements, and who wants to avoid going outside the LC comfort 
zone as far as is possible, for example to need to use github, or to struggle 
alone with the elaborate deployment techniques now demanded by the big players 
in software distribution. This ‘old fashioned’ type of user needs a very clear, 
understandable environment, and a lot of packaged help with deployment on the 
various platforms. I am probably hors de combat now, but I would put myself in 
the second category, despite having a quite technical background in software 
development.

A typical casualty of this conflict is the cancelling of the ability of these 
ordinary users to add notes to the dictionary, without apparent thought for the 
negative consequences.

Just my two (tottering) euro-cents.

Graham

> On 20 Jan 2019, at 03:59, Geoff Canyon via use-livecode 
>  wrote:
> 
> 1. Not everyone (very few people?) understand how git/GitHub works.
> 2. Even if you have a reasonable grasp of how to use git it's not obvious
> how to contribute to the dictionary using git. 

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

[Geoff Canyon via use-livecode]

On Sat, Jan 19, 2019 at 8:22 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> I agree that the dictionary isn’t the easiest to update without a GutHib
> client, but dictionary updates can be done completely in a browser.


Yep, I figured that out after I spent several minutes looking for the
dictionary data and poking through the dictionary stack. I already cloned
LiveCode some time ago, and GitHub was smart enough to realize that even
though my clone is substantially out of date, the merge entry hasn't
changed. So all i had to do was find it, edit (my copy of) it, save, and
issue a pull request.

And then notice a few minutes later that LC was asking me to sign the
waiver and tie my accounts together. I've done everything but that last
bit, so we'll see what happens.

gc
___
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 Dictionary

[Geoff Canyon via use-livecode]

On Sat, Jan 19, 2019 at 8:11 PM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Interesting.  I just checked on GitHub and the oauth token for LiveCode
> was recently revoked automatically since it was not used.  It’s been quite
> a while since I did it and I can’t recall about having write access.  There
> are several apps that I still have linked (Hacktoberfest...).
>
> Thanks,
> Brian
>

If the token has been revoked, I wonder if the process would have failed if
I had said yes? Now I'm tempted to say yes just to find out -- I said no
more on principle than on any concern that LC would actually do anything
harmful on my behalf.

gc
___
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 Dictionary

[Brian Milby via use-livecode]

I agree that the dictionary isn’t the easiest to update without a GutHib 
client, but dictionary updates can be done completely in a browser.  The use of 
the browser widget for the display of the dictionary data is quite independent 
from the data itself.  Maybe the community could put a complete replacement 
together for LC 10.  TinyDictionary would make a good start.  Would want to 
leverage how the Script Editor manages access to dictionary data to reduce 
memory usage (currently I’m guessing a good bit is in memory for the SE and the 
dictionary loads it all again from the JS version).

I’d also volunteer to submit PRs for updates if provided the necessary 
information.  I’ve done quite a few.  If there is a bug report, I would need 
the number as well to add the correct note.

Thanks,
Brian
On Jan 19, 2019, 9:00 PM -0600, Geoff Canyon via use-livecode 
, wrote:
> 1. Not everyone (very few people?) understand how git/GitHub works.
> 2. Even if you have a reasonable grasp of how to use git it's not obvious
> how to contribute to the dictionary using git. I've maintained Navigator in
> git/GitHub for about a year, and I'm sure I don't know the detailed steps
> -- just the general sense of "clone the repository, make changes to the
> dictionary, do a pull request." I just gave this a shot (pull request
> <https://github.com/livecode/livecode/pull/6856>) for the thinly-documented
> merge function. We'll see if I did it right.
>
> As an aside, I just checked, and the dictionary is now just two widgets? It
> seems counterproductive and unnecessary to convert the dictionary to
> widgets. There's no special functionality needed(?). And the dictionary
> functionality is now expressly beyond the ability of a large portion of the
> community to contribute to.
>
> gc
>
> On Sat, Jan 19, 2019 at 8:55 AM Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
> > We have an even better option now. Contributions to the actual dictionary
> > can be submitted via GitHub.
> >
> > Thanks,
> > Brian
> > On Jan 19, 2019, 9:48 AM -0600, Richmond via use-livecode <
> > use-livecode@lists.runrev.com>, wrote:
> > > Some of those user entries were extremely useful.
> > >
> > > It would be good if user entries could be restored to the dictionary
> > > once again.
> > >
> > > Richmond.
> > >
> > > On 19.01.19 9:49, Simon Knight via use-livecode wrote:
> > > > Hi all,
> > > >
> > > > I have just read about two “issues” and both would be resolved or at
> > least helped with a more detailed dictionary entry. Now in the dim distant
> > past the RunRev dictionary use to allow humble users to add comments and
> > examples which I for one found useful. Does anyone know why this useful
> > feature was removed? Security ?
> > > >
> > > >
> > > >
> > > > Simon Knight
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ___
> > > > use-livecode mailing list
> > > > use-livecode@lists.runrev.com
> > > > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> > >
> > > ___
> > > use-livecode mailing list
> > > use-livecode@lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
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 Dictionary

[Brian Milby via use-livecode]

Interesting.  I just checked on GitHub and the oauth token for LiveCode was 
recently revoked automatically since it was not used.  It’s been quite a while 
since I did it and I can’t recall about having write access.  There are several 
apps that I still have linked (Hacktoberfest...).

Thanks,
Brian
On Jan 19, 2019, 9:04 PM -0600, Geoff Canyon via use-livecode 
, wrote:
> So I have to sign an agreement -- I thought I had, but I have now.
>
> And I have to link my LiveCode account and my GitHub account, meaning LC
> can read and write all user data, including private email addresses,
> private profile information, and followers. Is that really necessary?
>
> gc
>
>
> On Sat, Jan 19, 2019 at 6:59 PM Geoff Canyon  wrote:
>
> > 1. Not everyone (very few people?) understand how git/GitHub works.
> > 2. Even if you have a reasonable grasp of how to use git it's not obvious
> > how to contribute to the dictionary using git. I've maintained Navigator in
> > git/GitHub for about a year, and I'm sure I don't know the detailed steps
> > -- just the general sense of "clone the repository, make changes to the
> > dictionary, do a pull request." I just gave this a shot (pull request
> > <https://github.com/livecode/livecode/pull/6856>) for the
> > thinly-documented merge function. We'll see if I did it right.
> >
> > As an aside, I just checked, and the dictionary is now just two widgets?
> > It seems counterproductive and unnecessary to convert the dictionary to
> > widgets. There's no special functionality needed(?). And the dictionary
> > functionality is now expressly beyond the ability of a large portion of the
> > community to contribute to.
> >
> > gc
> >
> > On Sat, Jan 19, 2019 at 8:55 AM Brian Milby via use-livecode <
> > use-livecode@lists.runrev.com> wrote:
> >
> > > We have an even better option now. Contributions to the actual
> > > dictionary can be submitted via GitHub.
> > >
> > > Thanks,
> > > Brian
> > > On Jan 19, 2019, 9:48 AM -0600, Richmond via use-livecode <
> > > use-livecode@lists.runrev.com>, wrote:
> > > > Some of those user entries were extremely useful.
> > > >
> > > > It would be good if user entries could be restored to the dictionary
> > > > once again.
> > > >
> > > > Richmond.
> > > >
> > > > On 19.01.19 9:49, Simon Knight via use-livecode wrote:
> > > > > Hi all,
> > > > >
> > > > > I have just read about two “issues” and both would be resolved or at
> > > least helped with a more detailed dictionary entry. Now in the dim distant
> > > past the RunRev dictionary use to allow humble users to add comments and
> > > examples which I for one found useful. Does anyone know why this useful
> > > feature was removed? Security ?
> > > > >
> > > > >
> > > > >
> > > > > Simon Knight
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ___
> > > > > use-livecode mailing list
> > > > > use-livecode@lists.runrev.com
> > > > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > > >
> > > >
> > > > ___
> > > > use-livecode mailing list
> > > > use-livecode@lists.runrev.com
> > > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > > ___
> > > use-livecode mailing list
> > > use-livecode@lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> >
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
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 Dictionary

[Geoff Canyon via use-livecode]

So I have to sign an agreement -- I thought I had, but I have now.

And I have to link my LiveCode account and my GitHub account, meaning LC
can read and write all user data, including private email addresses,
private profile information, and followers. Is that really necessary?

gc


On Sat, Jan 19, 2019 at 6:59 PM Geoff Canyon  wrote:

> 1. Not everyone (very few people?) understand how git/GitHub works.
> 2. Even if you have a reasonable grasp of how to use git it's not obvious
> how to contribute to the dictionary using git. I've maintained Navigator in
> git/GitHub for about a year, and I'm sure I don't know the detailed steps
> -- just the general sense of "clone the repository, make changes to the
> dictionary, do a pull request." I just gave this a shot (pull request
> <https://github.com/livecode/livecode/pull/6856>) for the
> thinly-documented merge function. We'll see if I did it right.
>
> As an aside, I just checked, and the dictionary is now just two widgets?
> It seems counterproductive and unnecessary to convert the dictionary to
> widgets. There's no special functionality needed(?). And the dictionary
> functionality is now expressly beyond the ability of a large portion of the
> community to contribute to.
>
> gc
>
> On Sat, Jan 19, 2019 at 8:55 AM Brian Milby via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> We have an even better option now.  Contributions to the actual
>> dictionary can be submitted via GitHub.
>>
>> Thanks,
>> Brian
>> On Jan 19, 2019, 9:48 AM -0600, Richmond via use-livecode <
>> use-livecode@lists.runrev.com>, wrote:
>> > Some of those user entries were extremely useful.
>> >
>> > It would be good if user entries could be restored to the dictionary
>> > once again.
>> >
>> > Richmond.
>> >
>> > On 19.01.19 9:49, Simon Knight via use-livecode wrote:
>> > > Hi all,
>> > >
>> > > I have just read about two “issues” and both would be resolved or at
>> least helped with a more detailed dictionary entry. Now in the dim distant
>> past the RunRev dictionary use to allow humble users to add comments and
>> examples which I for one found useful. Does anyone know why this useful
>> feature was removed? Security ?
>> > >
>> > >
>> > >
>> > > Simon Knight
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > ___
>> > > use-livecode mailing list
>> > > use-livecode@lists.runrev.com
>> > > Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> > > http://lists.runrev.com/mailman/listinfo/use-livecode
>> >
>> >
>> > ___
>> > use-livecode mailing list
>> > use-livecode@lists.runrev.com
>> > Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> > http://lists.runrev.com/mailman/listinfo/use-livecode
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Livecode Dictionary

[Geoff Canyon via use-livecode]

1. Not everyone (very few people?) understand how git/GitHub works.
2. Even if you have a reasonable grasp of how to use git it's not obvious
how to contribute to the dictionary using git. I've maintained Navigator in
git/GitHub for about a year, and I'm sure I don't know the detailed steps
-- just the general sense of "clone the repository, make changes to the
dictionary, do a pull request." I just gave this a shot (pull request
<https://github.com/livecode/livecode/pull/6856>) for the thinly-documented
merge function. We'll see if I did it right.

As an aside, I just checked, and the dictionary is now just two widgets? It
seems counterproductive and unnecessary to convert the dictionary to
widgets. There's no special functionality needed(?). And the dictionary
functionality is now expressly beyond the ability of a large portion of the
community to contribute to.

gc

On Sat, Jan 19, 2019 at 8:55 AM Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:

> We have an even better option now.  Contributions to the actual dictionary
> can be submitted via GitHub.
>
> Thanks,
> Brian
> On Jan 19, 2019, 9:48 AM -0600, Richmond via use-livecode <
> use-livecode@lists.runrev.com>, wrote:
> > Some of those user entries were extremely useful.
> >
> > It would be good if user entries could be restored to the dictionary
> > once again.
> >
> > Richmond.
> >
> > On 19.01.19 9:49, Simon Knight via use-livecode wrote:
> > > Hi all,
> > >
> > > I have just read about two “issues” and both would be resolved or at
> least helped with a more detailed dictionary entry. Now in the dim distant
> past the RunRev dictionary use to allow humble users to add comments and
> examples which I for one found useful. Does anyone know why this useful
> feature was removed? Security ?
> > >
> > >
> > >
> > > Simon Knight
> > >
> > >
> > >
> > >
> > >
> > > ___
> > > use-livecode mailing list
> > > use-livecode@lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Livecode Dictionary

[hh via use-livecode]

Use Bernd's TinyDictionary.
There everybody can add his own (private) notes.

Download from "Sample Stacks" or
http://livecodeshare.runrev.com/stack/825/TinyDictionary

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

[kee nethery via use-livecode]

> On Jan 19, 2019, at 8:54 AM, Brian Milby via use-livecode 
>  wrote:
> 
> We have an even better option now.  Contributions to the actual dictionary 
> can be submitted via GitHub.

If you have to post this here, it means it needs to be more obvious in the 
Dictionary wrapper that we all use.

Please put links into the Dictionary.

Thanks,
Kee
___
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 Dictionary

[Brian Milby via use-livecode]

We have an even better option now.  Contributions to the actual dictionary can 
be submitted via GitHub.

Thanks,
Brian
On Jan 19, 2019, 9:48 AM -0600, Richmond via use-livecode 
, wrote:
> Some of those user entries were extremely useful.
>
> It would be good if user entries could be restored to the dictionary
> once again.
>
> Richmond.
>
> On 19.01.19 9:49, Simon Knight via use-livecode wrote:
> > Hi all,
> >
> > I have just read about two “issues” and both would be resolved or at least 
> > helped with a more detailed dictionary entry. Now in the dim distant past 
> > the RunRev dictionary use to allow humble users to add comments and 
> > examples which I for one found useful. Does anyone know why this useful 
> > feature was removed? Security ?
> >
> >
> >
> > Simon Knight
> >
> >
> >
> >
> >
> > ___
> > 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: Livecode Dictionary

[Richmond via use-livecode]

Some of those user entries were extremely useful.

It would be good if user entries could be restored to the dictionary 
once again.


Richmond.

On 19.01.19 9:49, Simon Knight via use-livecode wrote:

Hi all,

I have just read about two “issues” and both would be resolved or at least 
helped with a more detailed dictionary entry.  Now in the dim distant past the 
RunRev dictionary use to allow humble users to add comments and examples which 
I for one found useful.  Does anyone know why this useful feature was removed?  
Security ?



Simon Knight





___
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

Livecode Dictionary

[Simon Knight via use-livecode]

Hi all,

I have just read about two “issues” and both would be resolved or at least 
helped with a more detailed dictionary entry.  Now in the dim distant past the 
RunRev dictionary use to allow humble users to add comments and examples which 
I for one found useful.  Does anyone know why this useful feature was removed?  
Security ?



Simon Knight





___
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: how to refresh LC IDE dictionary after i changed a api.lcdoc file?

[panagiotis merakos via use-livecode]

Hi Matthias,

Not sure if this will work, but try deleting the Documentation Cache folder
of the LC version you modified:

/Users//Library/Application Support/RunRev/Documentation Cache/ ..

Best,
Panos
--

On Wed, Jul 18, 2018 at 10:51 AM, Matthias Rebbe via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Hi,
>
> i changed some information in an api.lcdoc file of an extension. In my
> case i added some additional examples. Each new example with a leading
> “Example:” tag.
> How do i get that new information displayed in the dictionary. Even after
> a restart of LC i just see the old information, but not the updated one.
> Do i have to refresh the dictionary cache or what ever in some way?
>
> Regards,
>
> Matthias
>
>
> ___
> 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

how to refresh LC IDE dictionary after i changed a api.lcdoc file?

[Matthias Rebbe via use-livecode]

Hi,

i changed some information in an api.lcdoc file of an extension. In my case i 
added some additional examples. Each new example with a leading  “Example:” 
tag.  
How do i get that new information displayed in the dictionary. Even after a 
restart of LC i just see the old information, but not the updated one.
Do i have to refresh the dictionary cache or what ever in some way?

Regards,

Matthias


___
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: WebDocMaker / Online Dictionary

[Brian Milby via use-livecode]

No difference in the content. I made it mainly so I could have the dictionary 
available on my iPad in a searchable format. There is now an app available and 
Dash which provides the same type of thing.

Thanks,
Brian
On Jul 4, 2018, 8:41 PM -0400, Michel F. Lukawecki via use-livecode 
, wrote:
> Hi all.
>
> Being a newbie, I’m easily confused.
>
> Brian, is there a difference between your “online version of the dictionary 
> to the LC 9.0 release” and what I find at Livecode 
> Community/Contents/Tools/Documentation/pdf/LiveCode User Guide (9.0.0)?
>
> Thanks!
> 
> Michel F. Lukawecki
> Longueuil, Canada
>
> > On 2018-Jul-4, at 19:00, Brian Milby via use-livecode 
> >  wrote:
> >
> > I've finally updated my online version of the dictionary to the LC 9.0
> > release. In the process, I've posted the stack to my GitHub repo.
> >
> > https://github.com/bwmilby/lc-misc/tree/master/WebDocMaker
> >
> > The dictionary is available at:
> > https://milby.us/lc/docs/api.html
> >
> > The guides are available at:
> > https://milby.us/lc/docs/guide.html
> >
> > The files are probably much more appropriate to be self-hosted on a local
> > network though.
> >
> > I have not tried to make it work better on small/mobile screens yet. I did
> > put the code in that allows it work on iOS to at least select dictionary
> > entries.
> >
> > For those of us in the USA, Happy 4th of July!
> >
> > Brian
> > ___
> > 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: WebDocMaker / Online Dictionary

[Michel F. Lukawecki via use-livecode]

Hi all.

Being a newbie, I’m easily confused.

Brian, is there a difference between your “online version of the dictionary to 
the LC 9.0 release” and what I find at Livecode 
Community/Contents/Tools/Documentation/pdf/LiveCode User Guide (9.0.0)?

Thanks!

Michel F. Lukawecki
Longueuil, Canada

> On 2018-Jul-4, at 19:00, Brian Milby via use-livecode 
>  wrote:
> 
> I've finally updated my online version of the dictionary to the LC 9.0
> release.  In the process, I've posted the stack to my GitHub repo.
> 
> https://github.com/bwmilby/lc-misc/tree/master/WebDocMaker
> 
> The dictionary is available at:
> https://milby.us/lc/docs/api.html
> 
> The guides are available at:
> https://milby.us/lc/docs/guide.html
> 
> The files are probably much more appropriate to be self-hosted on a local
> network though.
> 
> I have not tried to make it work better on small/mobile screens yet.  I did
> put the code in that allows it work on iOS to at least select dictionary
> entries.
> 
> For those of us in the USA, Happy 4th of July!
> 
> Brian
> ___
> 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

WebDocMaker / Online Dictionary

[Brian Milby via use-livecode]

I've finally updated my online version of the dictionary to the LC 9.0
release.  In the process, I've posted the stack to my GitHub repo.

https://github.com/bwmilby/lc-misc/tree/master/WebDocMaker

The dictionary is available at:
https://milby.us/lc/docs/api.html

The guides are available at:
https://milby.us/lc/docs/guide.html

The files are probably much more appropriate to be self-hosted on a local
network though.

I have not tried to make it work better on small/mobile screens yet.  I did
put the code in that allows it work on iOS to at least select dictionary
entries.

For those of us in the USA, Happy 4th of July!

Brian
___
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: LC 9 Dictionary, Linux

[panagiotis merakos via use-livecode]

Hi Warren,

If you quit LC, this setting is lost next time you open LC. You could
probably tweak the script that checks the value of this setting. It should
be in the script of stack revIdeLibrary, around line 4583:

*function* revIDEBrowserWidgetUnavailable

*   return* (the platform is "Linux") and ($LIVECODE_USE_CEF is 0)

*end* revIDEBrowserWidgetUnavailable

probably the easiest way to force the Dictionary opening in a stack is to
change this handler to return false:

*function* revIDEBrowserWidgetUnavailable

*   return* false

*end* revIDEBrowserWidgetUnavailable


Hope this helps.

Best,

Panos

--

On Wed, Jun 27, 2018 at 7:15 PM, Warren Samples via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 06/27/2018 12:17 PM, Warren Samples via use-livecode wrote:
>
>> On 06/27/2018 03:45 AM, panagiotis merakos wrote:
>>  > If your Linux machine is not affected by this issue, then you can do
>> the following to open the Dictionary in a LC stack (as it used to be):
>>  >
>>  > 1. in the msg box type "put 1 into $LIVECODE_USE_CEF"
>>  > 2. open the dictionary, it should now open in a stack
>>  >
>>  > Best,
>>  > Panos
>>
>
> Panos,
>
> It works but it's not persistent. What is the best way to make this
> "stick"?
>
>
>
>
> Warren
>
> ___
> 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: LC 9 Dictionary, Linux

[Warren Samples via use-livecode]

On 06/27/2018 12:17 PM, Warren Samples via use-livecode wrote:

On 06/27/2018 03:45 AM, panagiotis merakos wrote:
 > If your Linux machine is not affected by this issue, then you can do 
the following to open the Dictionary in a LC stack (as it used to be):

 >
 > 1. in the msg box type "put 1 into $LIVECODE_USE_CEF"
 > 2. open the dictionary, it should now open in a stack
 >
 > Best,
 > Panos


Panos,

It works but it's not persistent. What is the best way to make this "stick"?



Warren

___
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: LC 9 Dictionary, Linux

[Warren Samples via use-livecode]

On 06/27/2018 03:45 AM, panagiotis merakos wrote:
> If your Linux machine is not affected by this issue, then you can do 
the following to open the Dictionary in a LC stack (as it used to be):

>
> 1. in the msg box type "put 1 into $LIVECODE_USE_CEF"
> 2. open the dictionary, it should now open in a stack
>
> Best,
> Panos


Thank you! It works perfectly here. The distro is Antergos (Arch) with 
KDE Plasma5, in case you're keeping a list.


Warren

___
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: LC 9 Dictionary, Linux

[panagiotis merakos via use-livecode]

Hi Warren,

We made this "hack" to open the Dictionary in a browser as a workaround to
the problem where some Linux distros could not display the browser widget.
If your Linux machine is not affected by this issue, then you can do the
following to open the Dictionary in a LC stack (as it used to be):

1. in the msg box type "put 1 into $LIVECODE_USE_CEF"
2. open the dictionary, it should now open in a stack

Best,
Panos
--

On Wed, Jun 27, 2018 at 8:42 AM, Warren Samples via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 06/23/2018 07:05 PM, Warren Samples via use-livecode wrote:
>
>> Hello,
>>
>> I don't recall off the top of my head what the current remaining issue is
>> with the dictionary under Linux. I know there have been a couple or three
>> that have been reported by different people on different distros. The
>> workaround to open the dictionary in a browser is working pretty well, but
>> could use at least one enhancement if it can be managed. Currently if I
>> have my default browser open on some desktop other than the one LiveCode is
>> on, the dictionary opens in a new tab on the other desktop. Could the
>> command used be finessed to force it to open a new window? This 'should'
>> open naturally on the current desktop. Another possible solution would be a
>> preference option to set a browser for the dictionary. That would allow one
>> to use a browser other than the default browser and avoid this (minor)
>> inconvenience.
>>
>> Warren
>>
>>
>
> I found a solution. I post it here in case another Linux user would be
> interested in this.
>
> It requires some very minor editing of the file:
>
> 'revidelibrary.8.livecodescript'
>
> which is in the 
> '../runrev/components//Toolset/libraries/'
> directory.
>
> I commented out two lines and added for each of them a corresponding line
> which launches the browser using shell(). This is what it looks like (email
> formatting may insert linebreaks):
>
> revIDEGenerateDictionaryHTML tWhich
> -- launch url ("file:" & revIDEGetDictionaryUrl(tWhich)) #original
> code
>   get shell("falkon" && revIDEGetDictionaryUrl(tWhich) && " &>/dev/null &") -- my shell call, all one line
>
> and
>
> revIDEGenerateDictionaryHTML "api", pLibrary, pTag, pType
> -- launch url ("file:" & revIDEGetDictionaryUrl("api"))  #original code
>   get shell("falkon" && revIDEGetDictionaryUrl("api") && " &>/dev/null &") -- my shell call, all one line
>
> The first instance is at line 4639 and the second at line @ 4920.
>
> I ultimately chose a dedicated browser, Falkon, for a few reasons. Opening
> my default browser with a command line switch which forces a new window
> works, and does what I had hoped, but using a dedicated browser and letting
> it open tabs once it's open has some significant advantages. The
> redirection at the end of the command detaches the running process from the
> shell, making shell() non-blocking.
>
>
> Warren
>
>
>
> ___
> 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: LC 9 Dictionary, Linux

[Warren Samples via use-livecode]

On 06/23/2018 07:05 PM, Warren Samples via use-livecode wrote:

Hello,

I don't recall off the top of my head what the current remaining issue 
is with the dictionary under Linux. I know there have been a couple or 
three that have been reported by different people on different distros. 
The workaround to open the dictionary in a browser is working pretty 
well, but could use at least one enhancement if it can be managed. 
Currently if I have my default browser open on some desktop other than 
the one LiveCode is on, the dictionary opens in a new tab on the other 
desktop. Could the command used be finessed to force it to open a new 
window? This 'should' open naturally on the current desktop. Another 
possible solution would be a preference option to set a browser for the 
dictionary. That would allow one to use a browser other than the default 
browser and avoid this (minor) inconvenience.


Warren




I found a solution. I post it here in case another Linux user would be 
interested in this.


It requires some very minor editing of the file:

'revidelibrary.8.livecodescript'

which is in the 
'../runrev/components//Toolset/libraries/' 
directory.


I commented out two lines and added for each of them a corresponding 
line which launches the browser using shell(). This is what it looks 
like (email formatting may insert linebreaks):


revIDEGenerateDictionaryHTML tWhich
-- launch url ("file:" & revIDEGetDictionaryUrl(tWhich)) #original code
  get shell("falkon" && revIDEGetDictionaryUrl(tWhich) && 
"/dev/null &") -- my shell call, all one line


and

revIDEGenerateDictionaryHTML "api", pLibrary, pTag, pType
-- launch url ("file:" & revIDEGetDictionaryUrl("api"))  #original code
  get shell("falkon" && revIDEGetDictionaryUrl("api") && 
"/dev/null &") -- my shell call, all one line


The first instance is at line 4639 and the second at line @ 4920.

I ultimately chose a dedicated browser, Falkon, for a few reasons. 
Opening my default browser with a command line switch which forces a new 
window works, and does what I had hoped, but using a dedicated browser 
and letting it open tabs once it's open has some significant advantages. 
The redirection at the end of the command detaches the running process 
from the shell, making shell() non-blocking.


Warren



___
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

LC 9 Dictionary, Linux

[Warren Samples via use-livecode]

Hello,

I don't recall off the top of my head what the current remaining issue 
is with the dictionary under Linux. I know there have been a couple or 
three that have been reported by different people on different distros. 
The workaround to open the dictionary in a browser is working pretty 
well, but could use at least one enhancement if it can be managed. 
Currently if I have my default browser open on some desktop other than 
the one LiveCode is on, the dictionary opens in a new tab on the other 
desktop. Could the command used be finessed to force it to open a new 
window? This 'should' open naturally on the current desktop. Another 
possible solution would be a preference option to set a browser for the 
dictionary. That would allow one to use a browser other than the default 
browser and avoid this (minor) inconvenience.


Warren

___
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: Dictionary Entry For TouchMove

[Brian Milby via use-livecode]

PR submitted to clarify the touchMove dictionary entry:
https://github.com/livecode/livecode/pull/6413

On Mon, Mar 12, 2018 at 5:24 PM, Brian Milby  wrote:

> Short answer, you need to track the location of each touch yourself and do
> the math.
>
> Check out this piece of code:
> https://raw.githubusercontent.com/bwmilby/lc-misc/master/
> PinchZoom/pinchzoom.livecodescript
>
> That is a piece of code that I translated into LCS that deals with
> tracking two touch points to zoom an object.  Depending on what you want to
> accomplish, you won't need anything that complicated.
>
> Looking at the Netflix app, you can either go vertical or horizontal.
> First movement direction locks it until all touches are released.  So you
> would need to capture the touchStart to get the ID and then 2 touchMove
> messages to establish direction (I didn't try using mouseloc to get the
> touchStart location).  You may want to pair the direction detection with a
> minimum to ensure you capture the correct direction.
>
> Hope this helps,
> Brian
>
> On Mon, Mar 12, 2018 at 4:39 PM, Sannyasin Brahmanathaswami via
> use-livecode  wrote:
>
>> I have a group control (made up smaller groups) they I want users to
>> scroll vertically. And the sub-groups, which want the user to scroller
>> horizontally. My current thinking is to turn off scrollers until we get
>> swipe direction, and turn them on, "mid-swipe"
>>
>> simply: how do you know if touchMove is a horizontal or vertical swipe?
>>
>> in the dictionary, it says (another cryptic entry!)
>>
>> touchMove pTouchID, pTouchX, pTouchY
>>
>> Summary
>>
>> Sent when the point at which the user is touching the screen changes.
>> Example
>>
>> on touchMove pTouchID, pX, pY
>>  if pX > lastX then
>>  -- user has moved to the right
>>  end if
>> end touchMove
>>
>> where does "lastX"  come from? It is not localized as a variable.
>>
>> Other touch handlers do not record the X,Y coords of touchRelease.
>>
>> should we
>>
>> local sLastMouseUp
>>
>> end touchRelease
>>   put the mouseloc to sLastMouseUp
>> end touchRelease
>>
>> on touchMove pTouchID, pX, pY
>>  if pX > (item 1 of sLastMouseUp) then
>>  -- user has moved to the right
>>  end if
>> end touchMove
>>
>> But this relative to the last swipe -  this is not "runtime" as the
>> dictionary says:
>>
>> "Handle the touchMove message if you want to perform some action when
>> the user changes the touch position without ending the touch or if you
>> want to keep continuous track of the touch position."
>>
>> BR
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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: Dictionary Entry For TouchMove

[Brian Milby via use-livecode]

Short answer, you need to track the location of each touch yourself and do
the math.

Check out this piece of code:
https://raw.githubusercontent.com/bwmilby/lc-misc/master/PinchZoom/pinchzoom.livecodescript

That is a piece of code that I translated into LCS that deals with tracking
two touch points to zoom an object.  Depending on what you want to
accomplish, you won't need anything that complicated.

Looking at the Netflix app, you can either go vertical or horizontal.
First movement direction locks it until all touches are released.  So you
would need to capture the touchStart to get the ID and then 2 touchMove
messages to establish direction (I didn't try using mouseloc to get the
touchStart location).  You may want to pair the direction detection with a
minimum to ensure you capture the correct direction.

Hope this helps,
Brian

On Mon, Mar 12, 2018 at 4:39 PM, Sannyasin Brahmanathaswami via
use-livecode  wrote:

> I have a group control (made up smaller groups) they I want users to
> scroll vertically. And the sub-groups, which want the user to scroller
> horizontally. My current thinking is to turn off scrollers until we get
> swipe direction, and turn them on, "mid-swipe"
>
> simply: how do you know if touchMove is a horizontal or vertical swipe?
>
> in the dictionary, it says (another cryptic entry!)
>
> touchMove pTouchID, pTouchX, pTouchY
>
> Summary
>
> Sent when the point at which the user is touching the screen changes.
> Example
>
> on touchMove pTouchID, pX, pY
>  if pX > lastX then
>  -- user has moved to the right
>  end if
> end touchMove
>
> where does "lastX"  come from? It is not localized as a variable.
>
> Other touch handlers do not record the X,Y coords of touchRelease.
>
> should we
>
> local sLastMouseUp
>
> end touchRelease
>   put the mouseloc to sLastMouseUp
> end touchRelease
>
> on touchMove pTouchID, pX, pY
>  if pX > (item 1 of sLastMouseUp) then
>  -- user has moved to the right
>  end if
> end touchMove
>
> But this relative to the last swipe -  this is not "runtime" as the
> dictionary says:
>
> "Handle the touchMove message if you want to perform some action when
> the user changes the touch position without ending the touch or if you
> want to keep continuous track of the touch position."
>
> BR
>
>
>
>
>
>
>
>
> ___
> 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

Dictionary Entry For TouchMove

[Sannyasin Brahmanathaswami via use-livecode]

I have a group control (made up smaller groups) they I want users to scroll 
vertically. And the sub-groups, which want the user to scroller horizontally. 
My current thinking is to turn off scrollers until we get swipe direction, and 
turn them on, "mid-swipe"

simply: how do you know if touchMove is a horizontal or vertical swipe?

in the dictionary, it says (another cryptic entry!) 

touchMove pTouchID, pTouchX, pTouchY

Summary

Sent when the point at which the user is touching the screen changes.
Example

on touchMove pTouchID, pX, pY
 if pX > lastX then
 -- user has moved to the right
 end if
end touchMove

where does "lastX"  come from? It is not localized as a variable.

Other touch handlers do not record the X,Y coords of touchRelease. 

should we 

local sLastMouseUp

end touchRelease 
  put the mouseloc to sLastMouseUp
end touchRelease

on touchMove pTouchID, pX, pY
 if pX > (item 1 of sLastMouseUp) then
 -- user has moved to the right
 end if
end touchMove

But this relative to the last swipe -  this is not "runtime" as the dictionary 
says:

"Handle the touchMove message if you want to perform some action when
the user changes the touch position without ending the touch or if you
want to keep continuous track of the touch position."

BR








___
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: New Books/Dictionary

[Mike Kerner via use-livecode]

This sounds like a good LCG multi-part project - building a mobile app
version of the dictionary that you can mark up similar to the way you can
mark up pdf's and images.  Maybe you have a paint/draw layer that overlays
the dictionary for notes, illustrations, etc.

On Mon, Nov 27, 2017 at 1:25 PM, Alejandro Tejada via use-livecode <
use-livecode@lists.runrev.com> wrote:

> James Hale wrote:
> > For those wanting to read the docs in an i-device
> > Dash for iOS is FREE.
> > I have posted some screenshots on the forum
> > if you want to see how the docs look.
>
> > http://forums.livecode.com/viewtopic.php?f=16&t=29745&p=160713#p160712
>
> Really nice! Thanks a lot for posting these images, James.  8)
> I noticed that docsets use a few mySQLite databases and a folder
> with images and thousands html formatted webpages.
>
> I tried (and failed) to use this docset in Android, using the App
> named "Lovely Docs" but this unsupported app does not recognize
> the folder as a docset.
>
> Then, I simply copied the folder for single webpage browsing
> using HTML viewer in Android.
>
> Does exists a script that create a single index webpage
> (html with links) from all 3,492 webpages?
>
> Thanks in advance!
>
> Al
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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

New Books/Dictionary

[Alejandro Tejada via use-livecode]

James Hale wrote:
> For those wanting to read the docs in an i-device
> Dash for iOS is FREE.
> I have posted some screenshots on the forum
> if you want to see how the docs look.

> http://forums.livecode.com/viewtopic.php?f=16&t=29745&p=160713#p160712

Really nice! Thanks a lot for posting these images, James.  8)
I noticed that docsets use a few mySQLite databases and a folder
with images and thousands html formatted webpages.

I tried (and failed) to use this docset in Android, using the App
named "Lovely Docs" but this unsupported app does not recognize
the folder as a docset.

Then, I simply copied the folder for single webpage browsing
using HTML viewer in Android.

Does exists a script that create a single index webpage
(html with links) from all 3,492 webpages?

Thanks in advance!

Al
___
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: New Books/Dictionary

[Sean Cole (Pi) via use-livecode]

Amazing, Thanks James

Sean Cole
*Pi Digital Productions Ltd*
www.pidigital.co.uk
+44(1634)402193
+44(7702)116447
'Don't try to think outside the box. Just remember the truth: There is no
box!'
'For then you realise it is not the box you are trying to look outside of,
but it is yourself!'

eMail Ts & Cs    Pi Digital
Productions Ltd is a UK registered limited company, no. 5255609

On 27 November 2017 at 13:15, James Hale via use-livecode <
use-livecode@lists.runrev.com> wrote:

> For those wanting to read the docs in an i-device Dash for iOS is FREE.
>
> I have posted some screenshots on the forum if you want to see how the
> docs look.
>
> http://forums.livecode.com/viewtopic.php?f=16&t=29745&p=160713#p160712 <
> http://forums.livecode.com/viewtopic.php?f=16&t=29745&p=160713#p160712>
>
>
> James
>
>
>
> ___
> 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: New Books/Dictionary

[James Hale via use-livecode]

For those wanting to read the docs in an i-device Dash for iOS is FREE.

I have posted some screenshots on the forum if you want to see how the docs 
look.

http://forums.livecode.com/viewtopic.php?f=16&t=29745&p=160713#p160712 



James



___
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: New Books/Dictionary

[pink via use-livecode]

While I use the internal dictionary (via TinyDict) for quick lookups, there
is something nice about having a separate browsable copy on my iPad. 

Why would I like an electronic version?

1. I can easily make notes, bookmarks and highlights for future reference.
2. I can browse through it on a whim to learn random facts and explore other
topics. (I'm a computer geek... this is fun for me)
3. I tend to do most of my programming on my MacBook Air which does not have
a lot of real estate, so having one less window open helps. 
4. I can just read and learn more about the language apart from the IDE, and
in or at places I may not want to bring my laptop. 

There's more, but I think that covers most of it



-
---
Greg (pink) Miller
mad, pink and dangerous to code
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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: New Books/Dictionary

[James At The Hale via use-livecode]

For those wanting an electronic version of the dictionary download Dash (for 
Mac) or one of its widows or android equivalents and the Dash docset version of 
the docs.
They are at lc9dp10 version and will be updated to dp11 soon after it is 
released.
Searching is very fast, even with the guides.

James

___
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

New Books/Dictionary

[Alejandro Tejada via use-livecode]

Greg Miller wrote:
> Will it be possible to buy electronic versions of
> the new dictionary and lessons book?

Ideally, in a near future, lessons and dictionary would be available as
interactive stacks or downloadable apps. Until then, here is a LiveCode 4.6
PDF dictionary, uploaded by et_phone_home:

http://www.mediafire.com/file/eteillibdzzcbxc/Livecode++Dictionnaire.pdf

I found this pdf dictionary in a forum thread:
http://forums.livecode.com/viewtopic.php?t=8430

and Ken Ray's 2.1.2 online Rev documentation for Rev 2.1.2 in PDF, RTF and
TXT format:

http://www.sonsothunder.com/devres/livecode/downloads.htm

By the way, RunRev 2.8.1 dictionary, printed in color coded paper, still
have a place in my work desk, along Dan Shafer's first RunRev book.

Al
___
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: New Books/Dictionary

[Richmond Mathewson via use-livecode]

Dunno about that: I use the LiveCode dictionary that I got through the 
Android store for nix

on my cheap-N-nasty Android tablet :)

Richmond.

On 25/11/17 7:34 pm, Pi Digital via use-livecode wrote:

Coz it sucks at searching for one thing! For another, it’s nice to have it on a 
device to the side of you rather than swapping on the pc desktop.

Greg, I’m making a little app for it that will be made freely available as soon 
as possible. If it works really well I’m going to make it a stack for inclusion 
with LC as the current one is tiresome.
#therehastobeabetterway

Sean Cole
Pi Digital


On 25 Nov 2017, at 16:19, Richmond Mathewson via use-livecode 
 wrote:

Why would anyone want to buy an electronic version of the new dictionary
when it comes rolled into every version of Livecode?

Richmond.


On 25/11/17 5:24 pm, pink via use-livecode wrote:
Will it be possible to buy electronic versions of the new dictionary and
lessons book?



-
---
Greg (pink) Miller
mad, pink and dangerous to code
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: New Books/Dictionary

[Brian Milby via use-livecode]

Are you just talking about the lack of full text search?

The dictionary seems to work ok on my iPad (served from my server).  CSS
and HTML need more tweaks to work well on a phone sized device.

On Sat, Nov 25, 2017 at 11:34 AM Pi Digital via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Coz it sucks at searching for one thing! For another, it’s nice to have it
> on a device to the side of you rather than swapping on the pc desktop.
>
> Greg, I’m making a little app for it that will be made freely available as
> soon as possible. If it works really well I’m going to make it a stack for
> inclusion with LC as the current one is tiresome.
> #therehastobeabetterway
>
> Sean Cole
> Pi Digital
>
> > On 25 Nov 2017, at 16:19, Richmond Mathewson via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Why would anyone want to buy an electronic version of the new dictionary
> > when it comes rolled into every version of Livecode?
> >
> > Richmond.
> >
> >> On 25/11/17 5:24 pm, pink via use-livecode wrote:
> >> Will it be possible to buy electronic versions of the new dictionary and
> >> lessons book?
> >>
> >>
> >>
> >> -
> >> ---
> >> Greg (pink) Miller
> >> mad, pink and dangerous to code
> >> --
> >> Sent from:
> http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
> >>
> >> ___
> >> use-livecode mailing list
> >> use-livecode@lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: New Books/Dictionary

[Mike Kerner via use-livecode]

have you tried tinydict?

On Sat, Nov 25, 2017 at 12:34 PM, Pi Digital via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Coz it sucks at searching for one thing! For another, it’s nice to have it
> on a device to the side of you rather than swapping on the pc desktop.
>
> Greg, I’m making a little app for it that will be made freely available as
> soon as possible. If it works really well I’m going to make it a stack for
> inclusion with LC as the current one is tiresome.
> #therehastobeabetterway
>
> Sean Cole
> Pi Digital
>
> > On 25 Nov 2017, at 16:19, Richmond Mathewson via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > Why would anyone want to buy an electronic version of the new dictionary
> > when it comes rolled into every version of Livecode?
> >
> > Richmond.
> >
> >> On 25/11/17 5:24 pm, pink via use-livecode wrote:
> >> Will it be possible to buy electronic versions of the new dictionary and
> >> lessons book?
> >>
> >>
> >>
> >> -
> >> ---
> >> Greg (pink) Miller
> >> mad, pink and dangerous to code
> >> --
> >> Sent from: http://runtime-revolution.278305.n4.nabble.com/
> Revolution-User-f278306.html
> >>
> >> ___
> >> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: New Books/Dictionary

[Pi Digital via use-livecode]

Coz it sucks at searching for one thing! For another, it’s nice to have it on a 
device to the side of you rather than swapping on the pc desktop. 

Greg, I’m making a little app for it that will be made freely available as soon 
as possible. If it works really well I’m going to make it a stack for inclusion 
with LC as the current one is tiresome. 
#therehastobeabetterway

Sean Cole
Pi Digital

> On 25 Nov 2017, at 16:19, Richmond Mathewson via use-livecode 
>  wrote:
> 
> Why would anyone want to buy an electronic version of the new dictionary
> when it comes rolled into every version of Livecode?
> 
> Richmond.
> 
>> On 25/11/17 5:24 pm, pink via use-livecode wrote:
>> Will it be possible to buy electronic versions of the new dictionary and
>> lessons book?
>> 
>> 
>> 
>> -
>> ---
>> Greg (pink) Miller
>> mad, pink and dangerous to code
>> --
>> Sent from: 
>> http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html
>> 
>> ___
>> 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: New Books/Dictionary

[Richmond Mathewson via use-livecode]

Why would anyone want to buy an electronic version of the new dictionary
when it comes rolled into every version of Livecode?

Richmond.

On 25/11/17 5:24 pm, pink via use-livecode wrote:

Will it be possible to buy electronic versions of the new dictionary and
lessons book?



-
---
Greg (pink) Miller
mad, pink and dangerous to code
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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

New Books/Dictionary

[pink via use-livecode]

Will it be possible to buy electronic versions of the new dictionary and
lessons book?



-
---
Greg (pink) Miller
mad, pink and dangerous to code
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
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: Expanded dictionary in LC 9

[Mark Waddingham via use-livecode]

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
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Expanded dictionary in LC 9

[James At The Hale via use-livecode]

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
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Printed dictionary (was Re: send mouseup to control)

[Mark Wieder via use-livecode]

On 05/25/2017 07:47 AM, Richard Gaskin via use-livecode wrote:

James Hale wrote:

 > In following them discussion on execution contexts Richard wrote:
 >> The executionContexts is documented, though in all fairness that
 >> Dict entry includes a note about not relying on the format of its
 >> contents.
 >
 > ...this morning the printed dictionary arrived! 🎉
 >
 > So I looked up executionContexts
 >
 > Where I read...
 > '' A common use of the executionContexts is to obtain the name of the
 > object and handler that called the current handler, this information
 > is available as line -2 of the executionContexts."
 >
 > BTW there was no mention of any caveats in using this property.

In v6.7 and later (possibly earlier too; I didn't check any version 
prior to v6.7), the Dictionary entry for the executionContexts includes 
this note:


 Important: The value of the executionContexts may be
 changed in future versions of LiveCode, it is not
 recommended to write code that depends on its contents.

The web version of the Dictionary, though reportedly a few versions 
behind more recent versions (to the confusion of a few forum readers), 
also includes that note:

https://livecode.com/resources/api/#livecode_script/executioncontexts


Interesting. I stand corrected - the executionContexts is documented 
after all. It *is* a bit out of date, though, as it doesn't reflect the 
additional parameter(s) for behavior objects. The additional parameter 
was added in a way that cleverly maintains backward compatibility, 
although if you need to trace your way through behaviors you need to 
take it into account.


--
 Mark Wieder
 ahsoftw...@gmail.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: Printed dictionary (was Re: send mouseup to control)

[Richard Gaskin via use-livecode]

James Hale wrote:

> In following them discussion on execution contexts Richard wrote:
>> The executionContexts is documented, though in all fairness that
>> Dict entry includes a note about not relying on the format of its
>> contents.
>
> ...this morning the printed dictionary arrived! 🎉
>
> So I looked up executionContexts
>
> Where I read...
> '' A common use of the executionContexts is to obtain the name of the
> object and handler that called the current handler, this information
> is available as line -2 of the executionContexts."
>
> BTW there was no mention of any caveats in using this property.

In v6.7 and later (possibly earlier too; I didn't check any version 
prior to v6.7), the Dictionary entry for the executionContexts includes 
this note:


Important: The value of the executionContexts may be
changed in future versions of LiveCode, it is not
recommended to write code that depends on its contents.

The web version of the Dictionary, though reportedly a few versions 
behind more recent versions (to the confusion of a few forum readers), 
also includes that note:

https://livecode.com/resources/api/#livecode_script/executioncontexts

What version was used for the printed Dictionary?


All that said, I still feel comfortable using the executionContexts, 
though sparingly and usually with an easily-searchable flag comment* in 
case I need to update it later.


After all, consider the fate of every Cocoa API call, or what happened 
to Python users moving from v2 to v3, or so many other things in the 
programming world.  Stuff changes.  If this changes too it won't be all 
that different from anything else we need to contend with. :)


LiveCode has a far-better-than-average record for maintaining backward 
compatibility, and for responsibly managing change.  In the rare case 
when a token is deprecated or its behavior is changed, it's usually 
called out in bold read type in the Release Notes.  So if that ever 
happens, I'll know about it early on during the DP builds, and can find 
the few places I use executionContexts easily enough.


Where factoring into separate handlers is the best fit for the problem, 
it's the best fit for the problem; a different solution like 
executionContexts wouldn't be the best choice in such cases anyway.


But if I avoid a working solution solely out of fear of possible future 
change in an API, in a world where the only constant is change I'd never 
write any code. :)




* FWIW I often flag code with three tags for easy searching, using a 
pattern Ken Ray and I call "Hmmm, Bang! What?":


"Hmmm":
--# Something worth drawing attention to for future versions,
perhaps for later optimization, or just an unusual construct
possibly worth reconsidering down the road.

"Bang!":
--! Something that MUST be addressed before release! Used for
very unusual blocks that should be reviewed for
revision before shipping.  In the heat of the moment we
may need to patch something together in one place in order
to finish work in another part of the system; this flag
allows finding those so we don't ship with those in place.

"What?":
--? Something that should be addressed as soon as time or
opportunity permits, but not show-stoppers (which would
use "--!" as above).  Sometimes this may be a workaround
for a bug in the engine, and if so I'll usually include
the bug number so I can refer to it later.  Or it may be
a kludgey solution that works well enough for now but
may be brittle or have potentially complicating implications
elsewhere down the road.

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

Printed dictionary (was Re: send mouseup to control)

[James Hale via use-livecode]

In following them discussion on execution contexts Richard wrote:
> The executionContexts is documented, though in all fairness that Dict 
> entry includes a note about not relying on the format of its contents. 


Normally I would moan to myself about how I would like to look that up but as I 
am reading this email (and nearly all others) on my iPad I cannot use the 
online dictionary as it can't handle a touch interface (the mothership is aware 
that they do have a non mobile friendly resource for a mobile capable product).

But this morning the printed dictionary arrived! 🎉

So I looked up executionContexts

Where I read...
'' A common use of the executionContexts is to obtain the name of the object 
and handler that called the current handler, this information is available as 
line -2 of the executionContexts."

BTW there was no mention of any caveats in using this property.

James

___
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: Dictionary entry for 'answer' - something missing?

[Graham Samuel via use-livecode]

Thanks Panos - on the Mac, it is not immediately obvious that the panel showing 
the different types of ‘answer’ is a scrolling list! My error, but I am 
probably not the only one likely to make it!

Cheers

Graham

> On 12 May 2017, at 14:42, panagiotis merakos via use-livecode 
>  wrote:
> 
> Hi Graham,
> 
> If you search for "answer", the 9th result in the list is what you are
> looking for:
> 
> answer [iconType] prompt [with button1 [or buttons]] [titled windowTitle] [
> as sheet]
> 
> Tested in 8.1.4 RC1 Indy.
> 
> Best,
> Panos
> --
> 
> On Fri, May 12, 2017 at 1:31 PM, Graham Samuel via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Maybe I don’t understand how to access the LC Dictionary in 8.1.4 rc 1,
>> but when I look up ‘answer’ I miss the plain vanilla version, as in
>> 
>>  answer question “Do you agree?” with “Yes” or “No” titled “Make a
>> Decision!”
>> 
>> This does work from the message box.
>> 
>> Can anyone find this definition? If not, it’s a bug, I think.
>> 
>> TIA
>> 
>> Graham
>> ___
>> 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: Dictionary entry for 'answer' - something missing?

[panagiotis merakos via use-livecode]

Hi Graham,

If you search for "answer", the 9th result in the list is what you are
looking for:

answer [iconType] prompt [with button1 [or buttons]] [titled windowTitle] [
as sheet]

Tested in 8.1.4 RC1 Indy.

Best,
Panos
--

On Fri, May 12, 2017 at 1:31 PM, Graham Samuel via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Maybe I don’t understand how to access the LC Dictionary in 8.1.4 rc 1,
> but when I look up ‘answer’ I miss the plain vanilla version, as in
>
>   answer question “Do you agree?” with “Yes” or “No” titled “Make a
> Decision!”
>
> This does work from the message box.
>
> Can anyone find this definition? If not, it’s a bug, I think.
>
> TIA
>
> Graham
> ___
> 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

Dictionary entry for 'answer' - something missing?

[Graham Samuel via use-livecode]

Maybe I don’t understand how to access the LC Dictionary in 8.1.4 rc 1, but 
when I look up ‘answer’ I miss the plain vanilla version, as in 

  answer question “Do you agree?” with “Yes” or “No” titled “Make a Decision!”

This does work from the message box.

Can anyone find this definition? If not, it’s a bug, I think.

TIA

Graham
___
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: Community Dictionary (was Re: Delete element from array)

[Phil Davis via use-livecode]

Very nice! I think I'll start using it as my primary docs UI and see if 
there's anything I wish it had in addition. I love the simplicity of it.


Phil Davis


On 2/22/17 6:14 PM, Mike Kerner via use-livecode wrote:

Everyone,
Have a look at what Bernd has done.  Again, the thread is
http://forums.livecode.com/viewtopic.php?f=67&t=28731&p=151678#p151678


On Mon, Jan 30, 2017 at 9:10 PM, Mike Kerner 
wrote:


Also, over there, I have included a list of bug reports that I found that
seem to be relevant.  If you have submitted a bug report for *the way the
dictionary works*  (not for an entry being incorrect or requiring
modification, because that is a separate, but eventually related project),
please weigh in so we can add it to the list.

On Mon, Jan 30, 2017 at 12:00 PM, Mike Kerner 
wrote:


Do me a favor, please, and post to the thread I already started on the
forum.
http://forums.livecode.com/viewtopic.php?f=67&t=28731

I also have a bug report that I started on this, that I suppose you could
contribute to, but I would think that first the forum would be the place to
go, until we have some firm things, so The Team doesn't have even more
stuff to read when they should be writing.

On Sat, Jan 28, 2017 at 12:03 AM, Sannyasin Brahmanathaswami via
use-livecode  wrote:


Richard Gaskin wrote:

 /Documentation/resources/data/api/api.sqlite

Oh boy, gonna have fun with that!

BR

___
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




--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
and did a little diving.
And God said, "This is good."




--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
and did a little diving.
And God said, "This is good."






--
Phil Davis


___
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: Community Dictionary (was Re: Delete element from array)

[Mike Kerner via use-livecode]

Everyone,
Have a look at what Bernd has done.  Again, the thread is
http://forums.livecode.com/viewtopic.php?f=67&t=28731&p=151678#p151678


On Mon, Jan 30, 2017 at 9:10 PM, Mike Kerner 
wrote:

> Also, over there, I have included a list of bug reports that I found that
> seem to be relevant.  If you have submitted a bug report for *the way the
> dictionary works*  (not for an entry being incorrect or requiring
> modification, because that is a separate, but eventually related project),
> please weigh in so we can add it to the list.
>
> On Mon, Jan 30, 2017 at 12:00 PM, Mike Kerner 
> wrote:
>
>> Do me a favor, please, and post to the thread I already started on the
>> forum.
>> http://forums.livecode.com/viewtopic.php?f=67&t=28731
>>
>> I also have a bug report that I started on this, that I suppose you could
>> contribute to, but I would think that first the forum would be the place to
>> go, until we have some firm things, so The Team doesn't have even more
>> stuff to read when they should be writing.
>>
>> On Sat, Jan 28, 2017 at 12:03 AM, Sannyasin Brahmanathaswami via
>> use-livecode  wrote:
>>
>>> Richard Gaskin wrote:
>>>
>>> /Documentation/resources/data/api/api.sqlite
>>>
>>> Oh boy, gonna have fun with that!
>>>
>>> BR
>>>
>>> ___
>>> 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
>>>
>>
>>
>>
>> --
>> On the first day, God created the heavens and the Earth
>> On the second day, God created the oceans.
>> On the third day, God put the animals on hold for a few hours,
>>and did a little diving.
>> And God said, "This is good."
>>
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>and did a little diving.
> And God said, "This is good."
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Community Dictionary (was Re: Delete element from array)

[Mike Kerner via use-livecode]

Also, over there, I have included a list of bug reports that I found that
seem to be relevant.  If you have submitted a bug report for *the way the
dictionary works*  (not for an entry being incorrect or requiring
modification, because that is a separate, but eventually related project),
please weigh in so we can add it to the list.

On Mon, Jan 30, 2017 at 12:00 PM, Mike Kerner 
wrote:

> Do me a favor, please, and post to the thread I already started on the
> forum.
> http://forums.livecode.com/viewtopic.php?f=67&t=28731
>
> I also have a bug report that I started on this, that I suppose you could
> contribute to, but I would think that first the forum would be the place to
> go, until we have some firm things, so The Team doesn't have even more
> stuff to read when they should be writing.
>
> On Sat, Jan 28, 2017 at 12:03 AM, Sannyasin Brahmanathaswami via
> use-livecode  wrote:
>
>> Richard Gaskin wrote:
>>
>> /Documentation/resources/data/api/api.sqlite
>>
>> Oh boy, gonna have fun with that!
>>
>> BR
>>
>> ___
>> 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
>>
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>and did a little diving.
> And God said, "This is good."
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Community Dictionary (was Re: Delete element from array)

[Mike Kerner via use-livecode]

Do me a favor, please, and post to the thread I already started on the
forum.
http://forums.livecode.com/viewtopic.php?f=67&t=28731

I also have a bug report that I started on this, that I suppose you could
contribute to, but I would think that first the forum would be the place to
go, until we have some firm things, so The Team doesn't have even more
stuff to read when they should be writing.

On Sat, Jan 28, 2017 at 12:03 AM, Sannyasin Brahmanathaswami via
use-livecode  wrote:

> Richard Gaskin wrote:
>
> /Documentation/resources/data/api/api.sqlite
>
> Oh boy, gonna have fun with that!
>
> BR
>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Dictionary rewrite - thoughts, please

[Mike Kerner via use-livecode]

Definitely, but for those that don't subscribe to the forums, either email
me at one of my addresses or put something here.
Link: http://forums.livecode.com/viewtopic.php?f=67&t=28731

On Sun, Jan 29, 2017 at 9:05 AM, Richmond Mathewson via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Would it be possible to move this dicussion over to the forums so we can
> illustrate
> some of our likes and dislikes with screenshots, mockups and so forth?
>
> Richmond.
>
> On 1/29/17 4:01 pm, Mike Kerner via use-livecode wrote:
>
>> I'm finally starting to take a look at redoing, or perhaps undoing the
>> dictionary in 8.  So what do we like in the old, what do we hate in the
>> old, what do we like in the new, what do we hate in the new, and what
>> sorts
>> of wishlist things do we have?
>>
>>
> ___
> 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
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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: Dictionary rewrite - thoughts, please

[Richmond Mathewson via use-livecode]

Would it be possible to move this dicussion over to the forums so we can 
illustrate

some of our likes and dislikes with screenshots, mockups and so forth?

Richmond.

On 1/29/17 4:01 pm, Mike Kerner via use-livecode wrote:

I'm finally starting to take a look at redoing, or perhaps undoing the
dictionary in 8.  So what do we like in the old, what do we hate in the
old, what do we like in the new, what do we hate in the new, and what sorts
of wishlist things do we have?



___
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

Dictionary rewrite - thoughts, please

[Mike Kerner via use-livecode]

I'm finally starting to take a look at redoing, or perhaps undoing the
dictionary in 8.  So what do we like in the old, what do we hate in the
old, what do we like in the new, what do we hate in the new, and what sorts
of wishlist things do we have?

-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
___
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