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 performance, and can slow 
maintenance work while increasing cognitive load for user and developer 
alike.


For that reason, I'd prefer a wiki be in a layout optimized for reading, 
leaving the script editor optimized for writing.


--
 

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

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

that the 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
> . 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 

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

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

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

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