Re: Volunteer github guru for documentation submissions?

[Mark Smith]

J. Landman Gay wrote
> It's a markdown issue I was thinking Mark Smith might want to tackle, 
> since it's part of the community docs we're trying to edit. If he 
> doesn't, then I'll try it.

It's next on my list to look at (I think I've finally got "encrypt" finished
- turned out it needed a lot more
than just an example). If it passes muster this time I will be on to
rawClipboardData (if it still needs work).

I certainly won't be winning any awards for rapidity :)



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-documentation-submissions-tp4703029p4704023.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Volunteer github guru for documentation submissions?

[Mark Smith]

Devin Asay wrote
> Mark, I think you’re right on track with this “fleshed-out” example. In
> the document on Contributing to LiveCode Documentation
> https://github.com/livecode/livecode/blob/community-docs/docs/contributing_to_docs.md;.
> They emphasize Completeness, Correctness, and Instructiveness. There is a
> section in that document on Instructiveness of examples. Your example
> seems to be in line with that. I always find complete, “cookbook”-style
> examples more helpful than examples that merely demonstrate the syntax.

Thanks Devin. I'll submit it and we'll see what the gatekeepers make of it. 

Cheers,

Mark



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-documentation-submissions-tp4703029p4703669.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Volunteer github guru for documentation submissions?

[Mark Smith]

Kay C Lan wrote
>> That would be incorrect. The only time you need to use 
>  (referenceType)>
>  format is if the link is ambiguous. 'sessionSavePath' is
> only a property so it can never be ambiguous so it appears in the
> Description: as 
> 
>  and then in the References: as
> sessionSavePath (property)

Kay,

Thanks for the very close reading of my post. Indeed I caught my own mistake
before I made any further changes and ended up leaving it as it was (which
was accepted). 

Mark



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-documentation-submissions-tp4703029p4703668.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Volunteer github guru for documentation submissions?

[Devin Asay]

> On Apr 17, 2016, at 10:30 AM, Mark Smith  wrote:
> 
> Thanks Jackie, sorry it took so long to get around to this. I have used
> encrypt extensively, but only in a very narrow/limited way. Here is an
> attempt at providing an example. Please, anyone, jump in and let me know if
> you think it can be improved/changed. I've probably strayed from the usual
> narrow format of an example...
> 
> 
> Examples
> 
> encrypt myData using cipher with password myPassword
> 
> the following takes a file from disk, stores it in a variable, encrypts the
> result,
> then writes the file back to disk. 
> 
> put URL ("binfile:" & path2input) into myData
> encrypt myData using "aes-256-cbc" with password 

Re: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Mon, Apr 18, 2016 at 12:21 AM, Mark Smith 
wrote:

> Mark Smith wrote
> >  "
> > 
> >  (property)" is the correct format?
>
> After looking at the documentation guide now I think it should be
> . I'll go make the change...
>
> That would be incorrect. The only time you need to use  format is if the link is ambiguous. 'sessionSavePath' is
only a property so it can never be ambiguous so it appears in the
Description: as  and then in the References: as
sessionSavePath (property)

The only time you need to use the unambiguous link format is if the
referenceName has more than one Type; ie field is an Object, a Keyword and
there is a Glossary entry. Even so, if in the lcdoc you are only referring
to a  as an Object, then there is only one Reference: field (object)
so there is no ambiguity. So in the Description every use of  will
create a link to the field entry in the Dictionary that is only referring
to it as an object.

On the other hand, if in the lcdoc you refer to a field and wish to link to
both the Glossary and to it as an Object, then in References: field
(object), field (glossary) so now in the Description to differentiate which
link you wish to point to you must use  and  in the appropriate locations.

HTH
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Mark Smith]

J. Landman Gay wrote
> Like Devin said, almost everything I look at needs at least a minor 
> tweak. I was just reading the encrypt entry. It's missing examples, but 
> I don't know enough about encryption to add meaningful ones. If you do, 
> that'd be great.

Thanks Jackie, sorry it took so long to get around to this. I have used
encrypt extensively, but only in a very narrow/limited way. Here is an
attempt at providing an example. Please, anyone, jump in and let me know if
you think it can be improved/changed. I've probably strayed from the usual
narrow format of an example...


Examples

encrypt myData using cipher with password myPassword

the following takes a file from disk, stores it in a variable, encrypts the
result,
then writes the file back to disk. 

put URL ("binfile:" & path2input) into myData
encrypt myData using "aes-256-cbc" with password 

Re: Volunteer github guru for documentation submissions?

[Mark Smith]

Mark Smith wrote
>  "
> 
>  (property)" is the correct format? 

After looking at the documentation guide now I think it should be
. I'll go make the change...

Mark



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-documentation-submissions-tp4703029p4703595.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Volunteer github guru for documentation submissions?

[Mark Smith]

Peter TB Brett wrote
> Go to the Dictionary stack, to the Guides tab, and you'll find the 
> documentation format reference in the drop down.

Thanks Peter. I think the drop-down menu might need a scroll option. When I
first looked at it I could not see the Documentation Format Guide (it's near
the bottom of the list) and the list did not scroll. I had to expand the
window in order for it to appear. Minor issue but something to consider.

Cheers,

Mark 



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-documentation-submissions-tp4703029p4703594.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Volunteer github guru for documentation submissions?

[J. Landman Gay]

Oh cool. Perfect. I should have checked there.

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



On April 16, 2016 3:14:02 PM Peter TB Brett  wrote:




On 16/04/2016 19:53, J. Landman Gay wrote:

On 4/16/2016 8:55 AM, Mark Smith wrote:

I changed the reference to
" property" but from your text it looks like maybe
" (property)" is the correct format? Is there somewhere
where these formats are documented?


Yes, this is one of those links I had to track down and still can't
remember where I found it. But I saved the link:



This is one of the links I'd like to see posted prominently somewhere so
we don't have to ask or hunt.


Hi Jacque,

This documentation is actually right in the IDE.

Go to the Dictionary stack, to the Guides tab, and you'll find the
documentation format reference in the drop down.

  Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Peter TB Brett]

On 16/04/2016 19:53, J. Landman Gay wrote:

On 4/16/2016 8:55 AM, Mark Smith wrote:

I changed the reference to
" property" but from your text it looks like maybe
" (property)" is the correct format? Is there somewhere
where these formats are documented?


Yes, this is one of those links I had to track down and still can't
remember where I found it. But I saved the link:



This is one of the links I'd like to see posted prominently somewhere so
we don't have to ask or hunt.


Hi Jacque,

This documentation is actually right in the IDE.

Go to the Dictionary stack, to the Guides tab, and you'll find the 
documentation format reference in the drop down.


 Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/16/2016 8:55 AM, Mark Smith wrote:

I changed the reference to
" property" but from your text it looks like maybe
" (property)" is the correct format? Is there somewhere
where these formats are documented?


Yes, this is one of those links I had to track down and still can't 
remember where I found it. But I saved the link:



This is one of the links I'd like to see posted prominently somewhere so 
we don't have to ask or hunt.


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

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

Re: Volunteer github guru for documentation submissions?

[Mark Smith]

Thanks Ali. I think I am making progress. I changed the reference to
" property" but from your text it looks like maybe
" (property)" is the correct format? Is there somewhere
where these formats are documented? Cheers!!

Mark



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-documentation-submissions-tp4703029p4703573.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Volunteer github guru for documentation submissions?

[Peter TB Brett]

On 15/04/2016 04:14, Kay C Lan wrote:

On Thu, Apr 14, 2016 at 2:12 PM, Monte Goulding  wrote:



why not turn this into a simple plugin to add a button to the dictionary

stack.


Scraping html text, that's super easy for me; creating a plugin - that's
another story. Have generally steered clear of plugins since weening myself
onto LC8. I note that rc1 isn't as stable for me (or others) as dp16 and
elsewhere removing plugins is recommended but that's not a factor in my
case.


Hi Kay,

When you report a bug when using the IDE, we need to determine whether 
it's a bug in the IDE, or a bad interaction between the IDE and a plugin.


In general, if removing the plugin fixes the issue, we'll ask you to go 
and take the problem it up with the plugin's author.


However, we do so in the full expectation that the person who wrote the 
plugin may then turn around and tell us, "No, actually the IDE is broken 
and my plugin has exposed a bug!"


 Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference: https://livecode.com/edinburgh-2016/

___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Richard Gaskin]

Kay C Lan wrote:

> Have generally steered clear of plugins since weening myself onto
> LC8. I note that rc1 isn't as stable for me (or others) as dp16
> and elsewhere removing plugins is recommended but that's not a
> factor in my case.

Plugins are supported in v8.0.  Indeed, they remain the primary means of 
extending the IDE toolset, just as they have for many years.


LC v8.0 should be a superset of capabilities found in earlier versions, 
so anything not working in v8.0 that had worked in earlier versions 
should be reported.


If you encounter an issue with a plugin from a third party, please 
report the issue to the plugin author so it can be addressed before LC 
v8.0 Stable is released.


If you find an issue with a plugin you'd written yourself, please feel 
free to discuss it here so we can find the root cause and fix it.


--
 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: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Thu, Apr 14, 2016 at 2:12 PM, Monte Goulding  wrote:

>
> >why not turn this into a simple plugin to add a button to the dictionary
> stack.
>
> Scraping html text, that's super easy for me; creating a plugin - that's
another story. Have generally steered clear of plugins since weening myself
onto LC8. I note that rc1 isn't as stable for me (or others) as dp16 and
elsewhere removing plugins is recommended but that's not a factor in my
case.
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Ali Lloyd]

Mark - my comment refers to an earlier line in the description section.
Your change to the list of references is correct, but the format of the
reference within the description (I.e. The bit between < and >) is
entryName(optionalType) rather than what it is at the moment, entryName
optionalType

On Thu, 14 Apr 2016 at 21:23, Mark Smith 
wrote:

> Thanks... I will take a look. I am grappling with another problem at the
> moment (and I need to download and install 8 so I can see what all the
> comments are about :)  But Peter had me editing an entry for
> "sessionSavePath (property)" and then Ali said I should change it to
> " property" so it would link properly but all the rest of
> the references are in the former ie. start session (command), delete
> session
> (command), sessionSavePath (property), sessionLifetime (property),
> sessionId
> (property), sessionSavePath property (property) (which I suggested they
> remove as obviously wrong), sessionName (property) etc so now I am totally
> confused (and probably in over my head). I think installing 8 might be the
> first step :)
>
> Cheers
>
>
>
>
> --
> View this message in context:
> http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-documentation-submissions-tp4703029p4703513.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Mark Smith]

Thanks... I will take a look. I am grappling with another problem at the
moment (and I need to download and install 8 so I can see what all the
comments are about :)  But Peter had me editing an entry for
"sessionSavePath (property)" and then Ali said I should change it to
" property" so it would link properly but all the rest of
the references are in the former ie. start session (command), delete session
(command), sessionSavePath (property), sessionLifetime (property), sessionId
(property), sessionSavePath property (property) (which I suggested they
remove as obviously wrong), sessionName (property) etc so now I am totally
confused (and probably in over my head). I think installing 8 might be the
first step :)

Cheers




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-documentation-submissions-tp4703029p4703513.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/13/2016 5:49 PM, Kay C Lan wrote:

Do you have Ali's latest version of the preview.livecode stack? Sorry I
tried to find a link to it but I can only find one to the previous version.


I downloaded the one at the bottom of the blog post only a few days ago 
and it appears to be the newest one. Blog post is here:



The main thing that doesn't work for me is the omission of keywords 
(i.e., "links",) but that's a known limitation.


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

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

Re: Volunteer github guru for documentation submissions?

[Monte Goulding]

> On 14 Apr 2016, at 3:49 PM, Kay C Lan  wrote:
> 
> Don't you hate it when you hit Send and immediately realise there is a
> simpler solution. Don't need to ask for your fork name, I can just use the /
> livecode/livecode/ fork to demonstrate the same thing:
> 
> on mouseUp
>   put the htmltext of widget 1 of stack "revDictionary" into tText
>   filter lines of tText with "* 12px" & quote & ">*"
>   get matchText(tText,".+>(.+?)",tName)
>   replace " " with "-" in tName
>   get matchText(tText,">type )
>   put 
> "https://github.com/livecode/livecode/blob/community-docs/docs/dictionary/ 
> "
> & \
> tType & "/" & tName & ".lcdoc" into tPath
>   launch URL tPath
> end mouseUp

Yep, why not turn this into a simple plugin to add a button to the dictionary 
stack. I’m sure a few people would like to use it.

Cheers

Monte
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Monte Goulding]

> on mouseUp
>   put the htmltext of widget 1 of stack "revDictionary" into tText
>   filter lines of tText with "* 12px" & quote & ">*"
>   get matchText(tText,".+>(.+?)",tName)
>   replace " " with "-" in tName
>   get matchText(tText,">type ,tType)
>   ask "Please enter your GItHub fork name:" with "fork-name" titled "Fork
> Name"
>   put it into tAnswer
>   if (tAnswer = empty) then
>  exit to top
>   end if
>   put "https://github.com/; & tAnswer & \
> "/livecode/blob/community-docs/docs/dictionary/" & \
> tType & "/" & tName & ".lcdoc" into tPath
>   launch URL tPath
> end mouseUp
> 
> 
> If you think figuring out which doc the Dictionary is currently viewing was
> going to be hard, then the future is indeed looking very bright :-)

Well I actually just said I wasn’t sure but it appears it isn’t all that 
tricky. I’d possibly like something that might be less inclined to break in 
future releases though.

Actually you don’t need your username here because when editing you want to go 
to the main repo’s community-docs branch rather than yours, edit and github 
will create a branch in your fork for your changes which you then use for the 
PR. An “Edit on GitHub” button on the docs stack would be a nice way to resolve 
my concerns about the branch stuff that appears to be causing headaches there.

Cheers

Monte


___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

Don't you hate it when you hit Send and immediately realise there is a
simpler solution. Don't need to ask for your fork name, I can just use the /
livecode/livecode/ fork to demonstrate the same thing:

on mouseUp
   put the htmltext of widget 1 of stack "revDictionary" into tText
   filter lines of tText with "**"
   get matchText(tText,".+>(.+?)",tName)
   replace " " with "-" in tName
   get matchText(tText,">type

Re: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Thu, Apr 14, 2016 at 11:57 AM, Monte Goulding  wrote:

>
> That sounds complicated.


Getting to Heaven is never going to be easy... especially when it's my LC
Heaven ;-)

>
>  I’m not sure if it is easy to determine which doc is currently being
> viewed in the dictionary.
>

When I visit the LC Community Docs via the Web interface the URL always
start with:

https://github.com/lan-kc/livecode/

where 'lan-kc' is my fork name. If you enter in whatever your fork name is
when you run this script it should display in your browser the lcdoc of
whatever is currently showing in your Dictionary. Obviously this is just a
proof of concept and it wont work for EVERY entry, especially those Entry
names that have special characters - $, #, < etc that need encoding, or any
Glossary entries - but I think you'll agree that those are not
insurmountable.

on mouseUp
   put the htmltext of widget 1 of stack "revDictionary" into tText
   filter lines of tText with "**"
   get matchText(tText,".+>(.+?)",tName)
   replace " " with "-" in tName
   get matchText(tText,">type

Re: Volunteer github guru for documentation submissions?

[Scott Rossi]

I'm a GitHub novice, but I've used this with another client (OS X):
https://desktop.github.com/


Not sure I have it pointed at the right directory,  but I see a bunch of
pull requests from livecodeali and peter-b.

:-)

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 4/13/16, 3:44 PM, "use-livecode on behalf of Alex Tweedly"

wrote:

>Which do you recommend?
>If it's a git gui - any favourite(s) ?



___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Monte Goulding]

> In the LC Dictionary you notice an error
> There is an Edit button to click on
> It retrieves the appropriate lcdoc file from the correct GitHub Branch

So here you could be opening a lcdoc file that is different to the one you 
noticed an error on which could be confusing but probably isn’t a deal breaker.

> It opens in a separate stack - an lcdoc Editor
> It opens in default WYSIWYG mode.

That sounds complicated. Some kind of split screen would be significantly 
simpler to implement and docs contributors really need to understand the lcdoc 
format because if there is an issue with a PR the comments will be against 
lcdoc lines which raises the point that such a system will need to allow you to 
go back and edit your changes further.

> You have a Submit button
> It creates the GitHub PR for you.

So we are missing some steps at the start here where you setup your clone and 
account on GitHub, a local repository is setup pointing to your clone and the 
upstream livecode repo and the GH account and api privileges are setup 
correctly but if that’s all done right then the GitHub API will allow this.

This can all be done as a plugin I think although I’m not sure if it is easy to 
determine which doc is currently being viewed in the dictionary.

Cheers

Monte
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Thu, Apr 14, 2016 at 8:45 AM, Monte Goulding  wrote:

>
> There’s no productivity gains in using a LC docs specific git gui only a
> slightly reduced learning curve.


I my LC Heaven there would be both :-)

In the LC Dictionary you notice an error
There is an Edit button to click on
It retrieves the appropriate lcdoc file from the correct GitHub Branch
It opens in a separate stack - an lcdoc Editor
It opens in default WYSIWYG mode.
You type in your correction/addition.
Because LC knows ALL it's own keywords (commands, objects, etc) it can
automatically reference them
If you type in any ambiguous references it can ask which one you meant (and
markup accordingly)
You change to Check mode - where clicking around will cause the Dictionary
to open at the appropriate Entry
  - if clicking on a recently added word doesn't work or takes you to the
wrong Entry
You have Raw mode - because sometimes WYSIWYG doesn't get it right and you
just have to do the markup yourself.
Back to Check mode to confirm your Raw changes work.
If you type in an Example: - it can be colour coded - so less likely to
make a mistake
In Compile mode you can check that each Example: wont return a error, and
any result is placed in msg
You have a Submit button
It creates the GitHub PR for you.
The lcdoc Editor Stack vanishes and you continue to productively code away.

But I'm sure a reduced learning curve would be paradise for many ;-)
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Monte Goulding]

> On 14 Apr 2016, at 9:53 AM, Kay C Lan  wrote:
> 
> You could say exactly the same thing about LiveCode users. Why hide
> ourselves from C or C++, they exist and 'almost' everyone else is using
> them?

Maybe you could say that but there’s clear productivity gains for using 
LiveCode. There’s no productivity gains in using a LC docs specific git gui 
only a slightly reduced learning curve. But hey if someone wants to do it 
there’s nothing stopping them.

Cheers

Monte
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Thu, Apr 14, 2016 at 6:13 AM, Monte Goulding  wrote:

>
> I’ve thought about this and yes it would be feasible to do however there
> are two things we know exist:
>  - good git gui’s - I like and often use SourceTree which is available for
> Windows and Mac
>  - good text editors - I use Atom these days
> 
> In the end I think our community will benefit from not creating our own
> thing to hide ourselves from using tools that almost everyone else on other
> platforms are using.


You could say exactly the same thing about LiveCode users. Why hide
ourselves from C or C++, they exist and 'almost' everyone else is using
them?

The fact is a git gui is a realisation that a gui is a better way to
interact with git than the command line. Yes some people like the command
line but plenty don't. SourceTree is not the only git gui in town, there
are many many others; if someone one was to make an LC Doc Git Gui, it
would just be another in an ever growing number of attempts to make git
easier.

And as I think you've realised, if we go down the git gui & text editor
path, now you have the trouble of writing Guides to support that. So it's
SourceTree, what about the Linux users, will there be a completely
different set of Guides for them and their gui? What if my preferred tool
is Eclipse which is both a text editor with a Git Gui interface extension?
Which team member is going to support those who choose a different tool set
up?

Now I tend to agree that spending time creating a LC Doc Git Interface may
not be time well spent; so given that many here are Objective-C adverse and
Gitphobic,  we know that the web interface works, and for noobs, means we
are all in the same boat - give or take browser differences - I can see
that it's the time LEAST spent by the Team to tweak the Web Guide and
support Web interaction for Doc ONLY contributions.

I can appreciate, for those who aren't adverse the many flavours of C and
wish to contribute to the Engine, the you'll already have your favourite
text editor and probably should be looking at a good Git Gui.
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Monte Goulding]

> On 14 Apr 2016, at 8:44 AM, Alex Tweedly  wrote:
> 
> 
> 
> On 13/04/2016 22:45, Monte Goulding wrote:
>> GitHub <> git and you are using GitHub which has hacked on a web interface 
>> for working on stuff. I honestly think that if folks spent the same amount 
>> of time working out the web interface as working out how to use git locally 
>> using a good git gui then they would be finding things much simpler. The 
>> main issue is locally you need to actively switch branches so you always 
>> know where you are but on the web it is much easier to jump between branches 
>> and get confused.
> Monte, I'm probably just caffeine-deprived,

You and me both ;-)

> but I have trouble parsing that first sentence.

Sorry, hopefully my comments below will clarify

> I *think* you're recommending using a git gui, and not using the web 
> interface - but it could be just the inverse.

Yes, I think a good git gui would be about the same size learning curve but the 
end result would be a much faster and easier to understand procedure.
> 
> Which do you recommend?
> If it's a git gui - any favourite(s) ?

SourceTree sourcetreeapp.com for Windows and Mac.

> 
> Being old-fashioned, I started with the command-line interface :-) But even 
> then, Ali's document switched into the web interface at a couple of crucial 
> points.

If you are comfortable on the command line I would stay there as there’s stuff 
you can do on the command line that no git-gui will do for you. I tend to jump 
back and forth because I like to use the gui for more of an overview of what’s 
going on in the repo. I’m suggesting this more for folks struggling with the 
web interface. Yes you will need to use GitHubs UI to send a patch for review.
> 
> I do think there are some errors or omissions in the "git gui" section of his 
> document, but I don't know enough to be sure, far less to fix them ….

The biggest issue i see with it is there’s no upstream remote setup which is 
required in order to fetch changes that have been merged into the main repo but 
push changes to your fork. Probably the reason for this is unless the document 
talks specifically about a single git gui (possibly not a bad idea) then the 
process for adding a remote will be different. Alternatively we could just 
steal the command line from the command line section.
> 
> For example
>> 
>> Make sure both the docs change and the bugfix note are ready for commit in 
>> the GUI client.
>> 
>> In the summary and description section,
>> 
>> The title should be along the lines of
>> 
> 
> and later ...
>> 
>> Click commit to
>> 
>> Then click "Submit pull request"
>> 
> 
>> There is a way for others to work on things together and given that’s the 
>> point of git that’s a good thing! The way to do it is to go to your patch-4 
>> branch, edit and then submit a PR to you which you then incorporate and 
>> which would reflect the changes in your PR. In the past I have sent PRs to 
>> branches on other people’s forks on the team and had team members send PRs 
>> to my branches that I have had in review.
>> 
> What's a "patch-4 branch" ?
> I've only got as far as submitting a couple of trivial changes - but I'm 
> pretty sure I didn't have a patch-4 branch ?

OK, sorry for the confusion. This was specifically targeting Mike’s patch to 
the send command docs which on his fork github.com/macmikey/livecode is in a 
branch named patch-4. To do what I was suggesting on a git gui or command line 
you would add his fork as a remote, checkout the patch-4 branch, make a change, 
push to your fork then send a PR to his fork. This isn’t a normal part of the 
contribution process so I wouldn’t worry about it for now I just wanted to 
clarify that yes, people can collaborate outside the normal PR review process 
and their work can be combined into the one PR submitted to the team.


___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Thu, Apr 14, 2016 at 4:30 AM, Devin Asay  wrote:

>
> - A markdown previewer. I know Ali made a stab at this, but I wasn't able
> to get it to work.
>

Do you have Ali's latest version of the preview.livecode stack? Sorry I
tried to find a link to it but I can only find one to the previous version.

You know if you have the latest version if;

1) after clicking the 'Preview' button,
2) after it opens the webpage in your Browser which looks like the
Dictionary,
3) within the 'hits' field at the top there are two entries:
a) the top one 'click me first',and
b) the one below will be the name of the lcdoc you are amending
4) Click on 'Click me first'
5) Then click on the line below which is the name of the lcdoc you are
amending.

If you do not have the 'click me first' line then you have an earlier
version of the preview.livecode stack. Might need to ask Ali to post a link.

If that is still not working for you have you tried another Browser?

Works (with known issues) for me on OS X 10.9.5 with Firefox >= 42.x
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Alex Tweedly]

On 13/04/2016 22:45, Monte Goulding wrote:

GitHub <> git and you are using GitHub which has hacked on a web interface for 
working on stuff. I honestly think that if folks spent the same amount of time 
working out the web interface as working out how to use git locally using a good git 
gui then they would be finding things much simpler. The main issue is locally you 
need to actively switch branches so you always know where you are but on the web it 
is much easier to jump between branches and get confused.
Monte, I'm probably just caffeine-deprived, but I have trouble parsing 
that first sentence.
I *think* you're recommending using a git gui, and not using the web 
interface - but it could be just the inverse.


Which do you recommend?
If it's a git gui - any favourite(s) ?

Being old-fashioned, I started with the command-line interface :-) But 
even then, Ali's document switched into the web interface at a couple of 
crucial points.


I do think there are some errors or omissions in the "git gui" section 
of his document, but I don't know enough to be sure, far less to fix 
them 


For example


Make sure both the docs change and the bugfix note are ready for 
commit in the GUI client.


In the summary and description section,

The title should be along the lines of



and later ...


Click commit to

Then click "Submit pull request"




There is a way for others to work on things together and given that’s the point 
of git that’s a good thing! The way to do it is to go to your patch-4 branch, 
edit and then submit a PR to you which you then incorporate and which would 
reflect the changes in your PR. In the past I have sent PRs to branches on 
other people’s forks on the team and had team members send PRs to my branches 
that I have had in review.


What's a "patch-4 branch" ?
I've only got as far as submitting a couple of trivial changes - but I'm 
pretty sure I didn't have a patch-4 branch ?



-- Alex.
P.S. I'm really struggling to avoid being a grumpy old man and saying 
"it's all been downhill since we switched from SCCS to RCS" :-)


___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Monte Goulding]

> On 14 Apr 2016, at 12:42 AM, Richard Gaskin  
> wrote:
> 
> I wonder if the power and flexibility of LiveCode could be applied to making 
> a front-end for working with LiveCode documentation.
> 
> It would of course be ideal if the core dev team had time for that, but 
> looking at the queue of things I'd like them to do and things others want 
> them to do I can't say I'd want that to be a priority for them.

I’ve thought about this and yes it would be feasible to do however there are 
two things we know exist:
 - good git gui’s - I like and often use SourceTree which is available for 
Windows and Mac
 - good text editors - I use Atom these days

There really isn’t anything else we need other than some reasonable 
instructions on using said git gui and text editor. I really think that people 
would find using a local git gui and text editor much easier than the GitHub 
web interface.

In the end I think our community will benefit from not creating our own thing 
to hide ourselves from using tools that almost everyone else on other platforms 
are using. We can’t expect people to take a step in our direction if we aren’t 
prepared to take a step in theirs first. From a user centric perspective if I 
am going to learn to use something in order to do something for someone else 
I’d much rather the thing I’m learning be useful in other contexts I can apply 
it to. Neither the web interface nor some custom LC docs git gui will pass that 
test. Indeed a LC docs git gui is worse on that front.

Cheers

Monte
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Monte Goulding]

> On 14 Apr 2016, at 1:07 AM, Mike Kerner  wrote:
> 
> The process for modifying code and the process for modifying documentation
> should be different.  Git, maybe intentionally, makes it difficult for
> people to work together on documents.  One of the things that Ali and I ran
> into is that he cannot easily make changes to my changes because that's not
> the way git is designed.  So, if I have something I screwed up (like some
> of the tags), his only option is to write a missive about it.  A few
> hundred words later, and he has spend a lot of time writing, but I don't
> understand so a few hundred words more, and I think I understand what he is
> saying, so I make a change but something else is messed up and so we go
> back and forth and all we have manged to do is write a lot of words but not
> fix anything.
> 
> And I'm in the wrong branch.  I won't be the only person to do that,
> either.
> 
> If git is going to be the tool, then there needs to be a pre-tool.  If that
> pre-tool is a mailing list, then so be it.  I'll send my last version of
> send, and y'all can have at it, if you choose.

GitHub <> git and you are using GitHub which has hacked on a web interface for 
working on stuff. I honestly think that if folks spent the same amount of time 
working out the web interface as working out how to use git locally using a 
good git gui then they would be finding things much simpler. The main issue is 
locally you need to actively switch branches so you always know where you are 
but on the web it is much easier to jump between branches and get confused.

There is a way for others to work on things together and given that’s the point 
of git that’s a good thing! The way to do it is to go to your patch-4 branch, 
edit and then submit a PR to you which you then incorporate and which would 
reflect the changes in your PR. In the past I have sent PRs to branches on 
other people’s forks on the team and had team members send PRs to my branches 
that I have had in review.

Cheers

Monte



___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Ralph DiMola]

You are correct. It made a difference in v6 at one point. I will try to nail
down when it changed.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay
Sent: Monday, April 11, 2016 7:48 PM
To: How to use LiveCode
Subject: RE: Volunteer github guru for documentation submissions?

I tested this in LC 8 and wasn't getting any difference when adding
"effective" so maybe it's been changed. I'm editing the two formatted
properties right now and wasn't sure I should add the effective distinction.
Do you get a difference in 8?

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



On April 11, 2016 5:25:53 PM "Ralph DiMola" <rdim...@evergreeninfo.net>
wrote:

> The "Effective" modifier for "formattedheight". This modifier will
calculate
> the text height in a field allowing for maximum acenders and decenders in
> the field's current text. Without the "Effective" modifier the height is
> calculated for the maximum acenders and decenders in the entire font set.
>
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
>
>
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
Behalf
> Of Mark Smith
> Sent: Monday, April 11, 2016 3:53 PM
> To: use-revolut...@lists.runrev.com
> Subject: Re: Volunteer github guru for documentation submissions?
>
> Does anyone have a documentation bug they would like to see fixed? I'd
like
> to give Ali's guide a try but don't have any documentation bugs top of
mind.
>
> Mark
>
>
>
> --
> View this message in context:
>
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-doc
> umentation-submissions-tp4703029p4703298.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> ___
> use-livecode mailing list
> use-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: Volunteer github guru for documentation submissions?

[Devin Asay]

> On Apr 13, 2016, at 11:52 AM, J. Landman Gay  wrote:
> 
> On April 13, 2016 7:58:21 AM Mike Kerner  wrote:
> 
>> I'm done.  I have better things to do than fight through trying to help
>> everybody by making the docs better.
> 
> I can so sympathize, but at least I don't feel so stupid now. I am going to 
> keep plugging away at it, doing only the most minimal changes until I know 
> what I'm doing. I plan to do only one or two a day to keep down the 
> frustration. Last night I forgot to add labels to my descriptive summaries 
> and when I tried to go back to do that I could find no way to edit them. 
> Peter put them in for me so there must be a way but it sure isn't obvious.

I sympathize, too, but after a few days of intensively trying to figure this 
out (and probably causing Ali and Peter some head-shaking), it’s starting to 
make sense. When I start into editing a dictionary entry now this is my process:

1 - Find the entry I want to work on by identifying errors or omissions in the 
LC Dictionary.

2 - Make extra, extra sure I go in at 
https://github.com/livecode/livecode/tree/community-docs/docs/dictionary. I 
really fouled this up my first couple of pull requests.

3 - Navigate to the category the dictionary entry belongs in; e.g. keyword, 
property, command, etc. and open the specific document.

4 - Once the doc is open hit the Edit button.

Once we’re at this point, I think a couple of tools could really make things 
easier:

- A style guide. When do you use block quoting? How thorough should we be at 
linking terms within the document and adding entries to the References: 
section? When to use a list? How and when do you create tables anyway?

- A markdown validator. Even though markdown is way simpler than something like 
html, it’s easy to miss things. (@peter-b, can something like this be done in 
Atom?)

- A markdown previewer. I know Ali made a stab at this, but I wasn't able to 
get it to work.

5 - I’ve found that once I get to this point, it’s straightforward to submit 
the pull request. Well, except that you have to Click about three times on 
different buttons before it’s really, really submitted. 

Finally, I think this effort could benefit by having a “traffic cop” who 
monitors documentation problems and invites people to fix them. No, I don’t 
want to be that guy. :)

These are mainly just musings on this process after a few days of deep diving 
into it. Fiddly but doable.

Devin



Devin Asay
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Ali Lloyd]

That's correct, clipboardData, rawClipboardData and fullClipboardData are
all global properties, whereas clipboard is a function that returns the
type of data on the clipboard.

Now that I read it again though, those instances of  in the
summaries of all the clipboard entries should be links to the clipboard
glossary entry, not the clipboard function. So the following things should
probably happen:
- clipboard (property) should be removed from the references of
fullClipboardData and rawClipboardData
- clipboard (glossary) should be add to the references of
clipboardData, fullClipboardData and rawClipboardData
- The references to  in all of those entries should be audited
so that they link to  when the entry is talking about
the clipboard function, and  when, as in the
summaries, they are referring to the general concept of a clipboard.

On Wed, Apr 13, 2016 at 6:54 PM J. Landman Gay 
wrote:

> All the clipboard entries are listed in the Properties category on github
> also. Made me scratch my head.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
>
>
> On April 13, 2016 2:18:20 AM Ali Lloyd  wrote:
>
> > I think the problem with  in those two entries is that
> clipboard
> > (property) is in the references, but it there is no clipboard property,
> > only a clipboard function. So removing that from the references should
> fix
> > it.
> >
> > On Wed, Apr 13, 2016 at 6:57 AM J. Landman Gay  >
> > wrote:
> >
> >> On 4/13/2016 12:51 AM, Monte Goulding wrote:
> >> >
> >> >> On 13 Apr 2016, at 3:47 PM, J. Landman Gay
> >> >>  wrote:
> >> >>
> >> >>> That must be a bug with the dictionary as  is
> >> >>> rendering fine on the clipboardData. Can you report that?
> >> >>
> >> >> It's a markdown issue I was thinking Mark Smith might want to
> >> >> tackle, since it's part of the community docs we're trying to edit.
> >> >> If he doesn't, then I'll try it.
> >> >
> >> > I can’t see anything different between the use in the summary of
> >> >  in the clipboardData and the fullClipboadData so I don’t
> >> > think it is markdown related but I could be wrong.
> >>
> >> Yeah, I was just looking at it again and I think you're right. I'll
> >> report it.
> >>
> >> --
> >> Jacqueline Landman Gay | jac...@hyperactivesw.com
> >> HyperActive Software   | http://www.hyperactivesw.com
> >>
> >>
> >> ___
> >> use-livecode mailing list
> >> use-livecode@lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>
> ___
> use-livecode mailing list
> use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

All the clipboard entries are listed in the Properties category on github 
also. Made me scratch my head.


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



On April 13, 2016 2:18:20 AM Ali Lloyd  wrote:


I think the problem with  in those two entries is that clipboard
(property) is in the references, but it there is no clipboard property,
only a clipboard function. So removing that from the references should fix
it.

On Wed, Apr 13, 2016 at 6:57 AM J. Landman Gay 
wrote:


On 4/13/2016 12:51 AM, Monte Goulding wrote:
>
>> On 13 Apr 2016, at 3:47 PM, J. Landman Gay
>>  wrote:
>>
>>> That must be a bug with the dictionary as  is
>>> rendering fine on the clipboardData. Can you report that?
>>
>> It's a markdown issue I was thinking Mark Smith might want to
>> tackle, since it's part of the community docs we're trying to edit.
>> If he doesn't, then I'll try it.
>
> I can’t see anything different between the use in the summary of
>  in the clipboardData and the fullClipboadData so I don’t
> think it is markdown related but I could be wrong.

Yeah, I was just looking at it again and I think you're right. I'll
report it.

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


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

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

http://lists.runrev.com/mailman/listinfo/use-livecode




___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On April 13, 2016 7:58:21 AM Mike Kerner  wrote:


I'm done.  I have better things to do than fight through trying to help
everybody by making the docs better.


I can so sympathize, but at least I don't feel so stupid now. I am going to 
keep plugging away at it, doing only the most minimal changes until I know 
what I'm doing. I plan to do only one or two a day to keep down the 
frustration. Last night I forgot to add labels to my descriptive summaries 
and when I tried to go back to do that I could find no way to edit them. 
Peter put them in for me so there must be a way but it sure isn't obvious.


Stuff like that makes you crazy.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



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

Re: Volunteer github guru for documentation submissions?

[Richard Gaskin]

Mike Kerner wrote:


The process for modifying code and the process for modifying documentation
should be different.


I agree that's it's very valuable to continually strive for ever-better 
workflow methods.


The challenge here is: what exactly does a better solution look like?

Even if we decide we don't want to use Git for part of the product, the 
rest of the product is maintained in Git so we'd then have the 
additional task of creating some means of integrating the new system to 
allow tracking and building within Git.


This is not impossible.  But it is also not trivial.  That much is known.

What's unknown is whether that additional work is more or less work than 
working within Git.


Anyone who came come up with a solution that answers that question 
favorably in terms of cost-effectiveness will be a hero.




Git, maybe intentionally, makes it difficult for people to work together
on documents.  One of the things that Ali and I ran into is that he
cannot easily make changes to my changes because that's not the way
git is designed.


I'd need to learn more about the specifics of that particular moment 
before I'd feel comfortable charactering Git as not being designed for 
collaborative workflows.  Indeed, Git's support for collaboration is the 
main reason people deal with its funkiness in other respects. :)




And I'm in the wrong branch.  I won't be the only person to do that,
either.


Yep, I've done that.  Happens, in any system that supports branching. 
Such an error is similar to the fact that many thousands of people will 
have automobile accidents today.  No one wants an automobile accident, 
but it's easy for humans to make mistakes.  We all have a lot going on.


Documenting how branching works can help, but then admittedly it adds to 
the knowledge one needs to acquire in order to help.


Perhaps this may reduce some of the overhead with contributing:



If git is going to be the tool, then there needs to be a pre-tool.

...

On Wed, Apr 13, 2016 at 10:42 AM, Richard Gaskin wrote:

...

Maybe this is an opportunity to raise the bar, for both Git and LiveCode,
to serve our own needs while showing the world how awesome LiveCode is:


Many years ago Ken Ray made a marvelous stack called Revzilla, a LiveCode
plugin that served as a front-end to Bugzilla.  At the time many found
Bugzilla's cumbersome UI off-putting, and Revzilla provided a way to submit
and review bug requests that was much simpler and more convenient.

(I don't think it's been maintained through the last two rounds of LC's
Bugzilla overhaul, but FWIW Revzilla can be downloaded here:
 )

I wonder if the power and flexibility of LiveCode could be applied to
making a front-end for working with LiveCode documentation.

It would of course be ideal if the core dev team had time for that, but
looking at the queue of things I'd like them to do and things others want
them to do I can't say I'd want that to be a priority for them.

And ideally it needn't be.  After all, the one thing we know about the
LiveCode community is that everyone in it knows how to program in LiveCode.

I could contribute to such a project, but I have to be realistic about
time commitments and admit that I can't take a lead role on that.

But just maybe someone here has the intersection of time, skills, and
interest to consider it.

If so, I'd be happy to help where I can.


--
 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: Volunteer github guru for documentation submissions?

[Mike Kerner]

Name: send

Type: command

Syntax: send  [ to  [in  [seconds | ticks
| milliseconds]] ]

Summary: Sends  to  immediately, or adds
 to the  queue.

Introduced: 1.0

OS: mac,windows,linux,ios,android

Platforms: desktop,server,web,mobile

Example:
send "mouseDown" to button "next"

Example:
send "mouseDown" to button "text" of stack "project2"

Example:
# A simple timer using send example

local sTime
on mouseUp
   put 0 into sTime
   send "timerIncrement" to me in 1 seconds
end mouseUp

on timerIncrement
   add 1 to sTime
   put sTime
   send "timerIncrement" to me in 1 seconds
end timerIncrement

Parameters:
message: An expression that evaluates to a message name, possibly including
parameters.
object: Any object reference. If you don't specify an object, the message
is set to the object whose  contains the send command. If you
specify a time, you must also specify an object.
time (integer): If you don't specify a unit of time, the default of ticks
is used.

The result: If you specify a ,  is the ID of the
 in the   queue.

Description:
Use the   to override the normal , or to delay
a  until after a specified time.

The  can be either the name of a  or a 
. If the  is a  containing more
than one  (for example, if it includes , or if
it is a multi-word command), it must be enclosed in .

Any parameters are evaluated before they are passed to the 
. For example, the following statement sends the 
 with 2 as the first parameter:

  send "mouseUp 1+1" to button "Example"

>*Important:* When the send command is used, the stack containing the
target  temporarily becomes the defaultStack. All object
references in the  are  in the current
context i. e. the defaultStack. Therefore references within the message
that refer to "this card" or "this stack" will be referring to the card or
stack where the target  is located.

>*Important:*  If you don't specify a , the  is sent
immediately, and any  it  is completed before
the rest of the current  is .  However, if you
specify a , even one of 0, the current  finishes
 before the  is sent.

>*Note:*  Using the   is slower than directly
 the  using the normal .
For best efficiency, use the   only when you want to delay
the  or when the  you want to execute is not in the
.

References: callbacks (property), backgroundBehavior (property), function
(control_st), mouseUp (message), word (keyword), object (object), literal
string (glossary), return (glossary), evaluate (glossary), execute
(glossary), command (glossary), LiveCode (glossary), double quote
(glossary), trigger (glossary), message path (glossary), message
(glossary), parameter (glossary), statement (glossary), 
(glossary), debugDo (command), dispatch (command), call (command), cancel
(command), result (function), pendingMessages (function)
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Mike Kerner]

The process for modifying code and the process for modifying documentation
should be different.  Git, maybe intentionally, makes it difficult for
people to work together on documents.  One of the things that Ali and I ran
into is that he cannot easily make changes to my changes because that's not
the way git is designed.  So, if I have something I screwed up (like some
of the tags), his only option is to write a missive about it.  A few
hundred words later, and he has spend a lot of time writing, but I don't
understand so a few hundred words more, and I think I understand what he is
saying, so I make a change but something else is messed up and so we go
back and forth and all we have manged to do is write a lot of words but not
fix anything.

And I'm in the wrong branch.  I won't be the only person to do that,
either.

If git is going to be the tool, then there needs to be a pre-tool.  If that
pre-tool is a mailing list, then so be it.  I'll send my last version of
send, and y'all can have at it, if you choose.

On Wed, Apr 13, 2016 at 10:42 AM, Richard Gaskin  wrote:

> Mike Kerner wrote:
>
> I'm done.  I have better things to do than fight through trying to
>> help everybody by making the docs better.  Have a look at send and
>> the attempts to clarify what it does and how it works, and if
>> afterward you want a go at it, go for it.  What looks at first glance
>> like a tweak turns out to be a hornet's nest that still isn't done.
>>
>
> Writing good docs is hard work.  We used to see a lot of "If they just..."
> comments here about the docs, but the more we participate the more we can
> appreciate firsthand that writing good documentation is no more trivial a
> task than writing good code.
>
> I appreciate your effort in giving it a go, and there's no blame in taking
> a break from it, even if the break becomes a permanent one.
>
> Contributions from the community are very valuable, but not an
> obligation.  The most important task any of us can do is to make great
> software with LiveCode and let others know how LiveCode helped you do it.
> Anything beyond that is appreciated, but not required.
>
>
>  If I have realized anything in the last 24 hours it's a) Github is
>> completely the wrong tool to use for documentation.  We should be
>> using a wiki or something similar.  The complexity that git adds does
>> not make this better.  If the goal was to open the documentation so
>> that the team can spend less time working on it, and so the folks who
>> use the tool all the time can improve it, then making updating the
>> docs this difficult is not going to do that.  b) Trying to keep all
>> the branches straight, and the complexity this adds is only going
>> to make it more difficult, still.
>>
>
> In some ways Github is like what Winston Churchill said about democracy:
>
>  Indeed it has been said that democracy is the worst
>  form of government except for all those other forms
>  that have been tried from time to time.
>
> As I used to write here on this list, software development happened before
> Github, and it will continue to happen after Github.  Its UI/UX is
> horrifyingly opaque, designed in a fit of Dunning-Kruger Effect by people
> with IQs north of 180 who are apparently impatient with anyone working in a
> more normal range.
>
> But over time I've come to recognize that it's the world's leading choice
> for collaborative software development.
>
> It's no magic pony, but then again magic ponies don't exist.
>
> We might even say it's a mess, but millions of project managers have found
> it less messy than the alternatives.
>
> Wikis definitely simplify input, but are far less flexible with output.
> If you're producing a web site they're often an excellent choice, but LC
> docs need to be exportable for local install, something the malleability of
> Markdown offers in spades but can be very difficult to do with a tool
> dependent on LAMP.  And wikis don't handle code at all, while Git provides
> a single set of tools for everything that comprises LiveCode.
>
> One of the strengths of Git is also one of the sources of frustration
> here:  support for multiple branches.  Warts and all, Git is recognized by
> even people who dislike it as excelling at that aspect of collaborative
> workflows more than any other tool.
>
> Branching and many other useful features of Git do indeed add complexity.
> But projects requiring branching are complex in themselves, and it allows
> that complexity to be isolated.
>
> For relatively trivial projects branching may not unimportant, perhaps
> even distracting.  But today's LiveCode code base, needing to isolate the
> broad scope of changes in v6 and v7 on the way to v8, would not likely have
> been possible without it.
>
>
> Maybe this is an opportunity to raise the bar, for both Git and LiveCode,
> to serve our own needs while showing the world how awesome LiveCode is:
>
>
> Many years ago Ken Ray made a marvelous 

Re: Volunteer github guru for documentation submissions?

[Richard Gaskin]

Mike Kerner wrote:


I'm done.  I have better things to do than fight through trying to
help everybody by making the docs better.  Have a look at send and
the attempts to clarify what it does and how it works, and if
afterward you want a go at it, go for it.  What looks at first glance
like a tweak turns out to be a hornet's nest that still isn't done.


Writing good docs is hard work.  We used to see a lot of "If they 
just..." comments here about the docs, but the more we participate the 
more we can appreciate firsthand that writing good documentation is no 
more trivial a task than writing good code.


I appreciate your effort in giving it a go, and there's no blame in 
taking a break from it, even if the break becomes a permanent one.


Contributions from the community are very valuable, but not an 
obligation.  The most important task any of us can do is to make great 
software with LiveCode and let others know how LiveCode helped you do 
it.  Anything beyond that is appreciated, but not required.




 If I have realized anything in the last 24 hours it's a) Github is
completely the wrong tool to use for documentation.  We should be
using a wiki or something similar.  The complexity that git adds does
not make this better.  If the goal was to open the documentation so
that the team can spend less time working on it, and so the folks who
use the tool all the time can improve it, then making updating the
docs this difficult is not going to do that.  b) Trying to keep all
the branches straight, and the complexity this adds is only going
to make it more difficult, still.


In some ways Github is like what Winston Churchill said about democracy:

 Indeed it has been said that democracy is the worst
 form of government except for all those other forms
 that have been tried from time to time.

As I used to write here on this list, software development happened 
before Github, and it will continue to happen after Github.  Its UI/UX 
is horrifyingly opaque, designed in a fit of Dunning-Kruger Effect by 
people with IQs north of 180 who are apparently impatient with anyone 
working in a more normal range.


But over time I've come to recognize that it's the world's leading 
choice for collaborative software development.


It's no magic pony, but then again magic ponies don't exist.

We might even say it's a mess, but millions of project managers have 
found it less messy than the alternatives.


Wikis definitely simplify input, but are far less flexible with output. 
 If you're producing a web site they're often an excellent choice, but 
LC docs need to be exportable for local install, something the 
malleability of Markdown offers in spades but can be very difficult to 
do with a tool dependent on LAMP.  And wikis don't handle code at all, 
while Git provides a single set of tools for everything that comprises 
LiveCode.


One of the strengths of Git is also one of the sources of frustration 
here:  support for multiple branches.  Warts and all, Git is recognized 
by even people who dislike it as excelling at that aspect of 
collaborative workflows more than any other tool.


Branching and many other useful features of Git do indeed add 
complexity. But projects requiring branching are complex in themselves, 
and it allows that complexity to be isolated.


For relatively trivial projects branching may not unimportant, perhaps 
even distracting.  But today's LiveCode code base, needing to isolate 
the broad scope of changes in v6 and v7 on the way to v8, would not 
likely have been possible without it.



Maybe this is an opportunity to raise the bar, for both Git and 
LiveCode, to serve our own needs while showing the world how awesome 
LiveCode is:



Many years ago Ken Ray made a marvelous stack called Revzilla, a 
LiveCode plugin that served as a front-end to Bugzilla.  At the time 
many found Bugzilla's cumbersome UI off-putting, and Revzilla provided a 
way to submit and review bug requests that was much simpler and more 
convenient.


(I don't think it's been maintained through the last two rounds of LC's 
Bugzilla overhaul, but FWIW Revzilla can be downloaded here:

 )

I wonder if the power and flexibility of LiveCode could be applied to 
making a front-end for working with LiveCode documentation.


It would of course be ideal if the core dev team had time for that, but 
looking at the queue of things I'd like them to do and things others 
want them to do I can't say I'd want that to be a priority for them.


And ideally it needn't be.  After all, the one thing we know about the 
LiveCode community is that everyone in it knows how to program in LiveCode.


I could contribute to such a project, but I have to be realistic about 
time commitments and admit that I can't take a lead role on that.


But just maybe someone here has the intersection of time, skills, and 
interest to consider it.


If so, I'd be happy to help 

Re: Volunteer github guru for documentation submissions?

[Ali Lloyd]

Mike,
I'm sorry it ended up being a very tricky document to change - I think we
jointly suffered a sort of scope creep because that doc doesn't properly
distinguish between the notion of a message and the messageName parameter.

While it's true that what you were originally suggesting was a tweak, you
di say yourself in this comment
https://github.com/livecode/livecode/pull/3861#issuecomment-206918583 that
you wanted to make a more radical change. Such things are bound to take
more time and involve more discussion. Perhaps if you could articulate what
difficulties you are having with conducting that discussion on the pull
request itself, we can find a way to overcome it.


On Wed, Apr 13, 2016 at 1:55 PM Mike Kerner 
wrote:

> I'm done.  I have better things to do than fight through trying to help
> everybody by making the docs better.  Have a look at send and the attempts
> to clarify what it does and how it works, and if afterward you want a go at
> it, go for it.  What looks at first glance like a tweak turns out to be a
> hornet's nest that still isn't done.  If I have realized anything in the
> last 24 hours it's a) Github is completely the wrong tool to use for
> documentation.  We should be using a wiki or something similar.  The
> complexity that git adds does not make this better.  If the goal was to
> open the documentation so that the team can spend less time working on it,
> and so the folks who use the tool all the time can improve it, then making
> updating the docs this difficult is not going to do that.  b) Trying to
> keep all the branches straight, and the complexity this adds is only going
> to make it more difficult, still.
>
> On Wed, Apr 13, 2016 at 3:16 AM, Ali Lloyd  wrote:
>
> > I think the problem with  in those two entries is that
> clipboard
> > (property) is in the references, but it there is no clipboard property,
> > only a clipboard function. So removing that from the references should
> fix
> > it.
> >
> > On Wed, Apr 13, 2016 at 6:57 AM J. Landman Gay  >
> > wrote:
> >
> > > On 4/13/2016 12:51 AM, Monte Goulding wrote:
> > > >
> > > >> On 13 Apr 2016, at 3:47 PM, J. Landman Gay
> > > >>  wrote:
> > > >>
> > > >>> That must be a bug with the dictionary as  is
> > > >>> rendering fine on the clipboardData. Can you report that?
> > > >>
> > > >> It's a markdown issue I was thinking Mark Smith might want to
> > > >> tackle, since it's part of the community docs we're trying to edit.
> > > >> If he doesn't, then I'll try it.
> > > >
> > > > I can’t see anything different between the use in the summary of
> > > >  in the clipboardData and the fullClipboadData so I don’t
> > > > think it is markdown related but I could be wrong.
> > >
> > > Yeah, I was just looking at it again and I think you're right. I'll
> > > report it.
> > >
> > > --
> > > Jacqueline Landman Gay | jac...@hyperactivesw.com
> > > HyperActive Software   | http://www.hyperactivesw.com
> > >
> > >
> > > ___
> > > use-livecode mailing list
> > > use-livecode@lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
>
> --
> 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
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Mike Kerner]

I'm done.  I have better things to do than fight through trying to help
everybody by making the docs better.  Have a look at send and the attempts
to clarify what it does and how it works, and if afterward you want a go at
it, go for it.  What looks at first glance like a tweak turns out to be a
hornet's nest that still isn't done.  If I have realized anything in the
last 24 hours it's a) Github is completely the wrong tool to use for
documentation.  We should be using a wiki or something similar.  The
complexity that git adds does not make this better.  If the goal was to
open the documentation so that the team can spend less time working on it,
and so the folks who use the tool all the time can improve it, then making
updating the docs this difficult is not going to do that.  b) Trying to
keep all the branches straight, and the complexity this adds is only going
to make it more difficult, still.

On Wed, Apr 13, 2016 at 3:16 AM, Ali Lloyd  wrote:

> I think the problem with  in those two entries is that clipboard
> (property) is in the references, but it there is no clipboard property,
> only a clipboard function. So removing that from the references should fix
> it.
>
> On Wed, Apr 13, 2016 at 6:57 AM J. Landman Gay 
> wrote:
>
> > On 4/13/2016 12:51 AM, Monte Goulding wrote:
> > >
> > >> On 13 Apr 2016, at 3:47 PM, J. Landman Gay
> > >>  wrote:
> > >>
> > >>> That must be a bug with the dictionary as  is
> > >>> rendering fine on the clipboardData. Can you report that?
> > >>
> > >> It's a markdown issue I was thinking Mark Smith might want to
> > >> tackle, since it's part of the community docs we're trying to edit.
> > >> If he doesn't, then I'll try it.
> > >
> > > I can’t see anything different between the use in the summary of
> > >  in the clipboardData and the fullClipboadData so I don’t
> > > think it is markdown related but I could be wrong.
> >
> > Yeah, I was just looking at it again and I think you're right. I'll
> > report it.
> >
> > --
> > Jacqueline Landman Gay | jac...@hyperactivesw.com
> > HyperActive Software   | http://www.hyperactivesw.com
> >
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
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: Volunteer github guru for documentation submissions?

[Ali Lloyd]

I think the problem with  in those two entries is that clipboard
(property) is in the references, but it there is no clipboard property,
only a clipboard function. So removing that from the references should fix
it.

On Wed, Apr 13, 2016 at 6:57 AM J. Landman Gay 
wrote:

> On 4/13/2016 12:51 AM, Monte Goulding wrote:
> >
> >> On 13 Apr 2016, at 3:47 PM, J. Landman Gay
> >>  wrote:
> >>
> >>> That must be a bug with the dictionary as  is
> >>> rendering fine on the clipboardData. Can you report that?
> >>
> >> It's a markdown issue I was thinking Mark Smith might want to
> >> tackle, since it's part of the community docs we're trying to edit.
> >> If he doesn't, then I'll try it.
> >
> > I can’t see anything different between the use in the summary of
> >  in the clipboardData and the fullClipboadData so I don’t
> > think it is markdown related but I could be wrong.
>
> Yeah, I was just looking at it again and I think you're right. I'll
> report it.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/13/2016 12:51 AM, Monte Goulding wrote:



On 13 Apr 2016, at 3:47 PM, J. Landman Gay
 wrote:


That must be a bug with the dictionary as  is
rendering fine on the clipboardData. Can you report that?


It's a markdown issue I was thinking Mark Smith might want to
tackle, since it's part of the community docs we're trying to edit.
If he doesn't, then I'll try it.


I can’t see anything different between the use in the summary of
 in the clipboardData and the fullClipboadData so I don’t
think it is markdown related but I could be wrong.


Yeah, I was just looking at it again and I think you're right. I'll 
report it.


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


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

Re: Volunteer github guru for documentation submissions?

[Monte Goulding]

> On 13 Apr 2016, at 3:47 PM, J. Landman Gay  wrote:
> 
>> That must be a bug with the dictionary as  is rendering
>> fine on the clipboardData. Can you report that?
> 
> It's a markdown issue I was thinking Mark Smith might want to tackle, since 
> it's part of the community docs we're trying to edit. If he doesn't, then 
> I'll try it.

I can’t see anything different between the use in the summary of  in 
the clipboardData and the fullClipboadData so I don’t think it is markdown 
related but I could be wrong.

Cheers

Monte
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/13/2016 12:06 AM, Monte Goulding wrote:



On 13 Apr 2016, at 2:43 PM, J. Landman Gay
 wrote:

BTW, I've found omitted words in the rawClipboardData summary if
you want to tackle that one. The summary reads

provides low-level access to the contents of the .


That must be a bug with the dictionary as  is rendering
fine on the clipboardData. Can you report that?


It's a markdown issue I was thinking Mark Smith might want to tackle, 
since it's part of the community docs we're trying to edit. If he 
doesn't, then I'll try it.


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

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

Re: Volunteer github guru for documentation submissions?

[Monte Goulding]

> On 13 Apr 2016, at 2:43 PM, J. Landman Gay  wrote:
> 
> BTW, I've found omitted words in the rawClipboardData summary if you want to 
> tackle that one. The summary reads
> 
>  provides low-level access to the contents of the .

That must be a bug with the dictionary as  is rendering fine on the 
clipboardData. Can you report that?

Cheers

Monte 
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/12/2016 6:55 PM, Mark Smith wrote:

J. Landman Gay wrote

>textShift is not tagged as "text processing"

BTW, are tags something new in the LC 8 dictionary? I can't see any in the
LC 7 version (or don't know how to make them appear).


Yes. It's the pseudo-word-cloud at the left of the window. If you click 
on a tag, search results are filtered by that tag. You can filter by 
type or OS too.


BTW, I've found omitted words in the rawClipboardData summary if you 
want to tackle that one. The summary reads


  provides low-level access to the contents of the .

If you look at the github doc, the rest of the sentence is there but it 
isn't displaying. I'm not familiar enough yet with the markdown to know 
how to fix it.


The same error occurs in fullClipboardData.

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

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

Re: Volunteer github guru for documentation submissions?

[Mark Smith]

J. Landman Gay wrote
>textShift is not tagged as "text processing"

BTW, are tags something new in the LC 8 dictionary? I can't see any in the
LC 7 version (or don't know how to make them appear).

Mark



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-documentation-submissions-tp4703029p4703397.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Volunteer github guru for documentation submissions?

[Mark Smith]

J. Landman Gay wrote
> Like Devin said, almost everything I look at needs at least a minor 
> tweak. I was just reading the encrypt entry. It's missing examples, but 
> I don't know enough about encryption to add meaningful ones. If you do, 
> that'd be great.
> 
> Another thing to do would be to go through a pre-8 dictionary and look 
> at entries with user notes. Those aren't included in the LC 8 dictionary 
> and if you see some that are useful, add them to the main description.

Great suggestions, thanks. (You and Devin have knowledge of LC I don't, so I
think your strategies probably would not bear much fruit in my case). Still
happy to submit pull requests for anyone who can't be bothered. I do learn
something indirectly in the process, so there is some advantage. 

I'll go take a look at encrypt.

Mark



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-documentation-submissions-tp4703029p4703396.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/12/2016 5:19 AM, Ali Lloyd wrote:

The viewer stack was something I quickly knocked up so that there was
*some*  way of viewing the document in context - the links indeed don't work
as it doesn't rebuild the whole dictionary. I'm sorry about that- I can
probably make it work properly at some point.


I wouldn't make it a priority, the problem for me wasn't with the viewer 
itself. I only needed to know whether I should ignore the terms that 
didn't display. Your blog mentioned that links don't work, but I hadn't 
yet seen the markdown document so I didn't know what you meant by 
"link." I thought you meant URLs.



The line
*Navigate to the file you want to modify in the dictionary folder of the
community-docs branch
.*

with a link to the correct branch/folder was there before, but I've
submitted a PR to reinforce the fact that the community-docs branch should
be the base branch to modify the file:


Thanks. I know you want the best for us, and you're responsiveness is 
terrific. I may not be typical because my eyesight is poor and I don't 
always notice things. If I need to read through a lot of text to find 
links, I'll miss some. A straightforward list would have helped a lot:


Contribution overview: 
Joining github: 
The documentation files: 
Using the web interface: contributing_to_docs.md#using-the-github-web-interface>

Using Git GUI software: 
Using the command line: 
Linking to your LC account: 
Signing the CLA: 
Documentation Format Reference: 
-- etc

For me, this thread would have been a whole lot shorter if that had been 
available on github, or at least a link to it.


Thanks again for your dedication Ali.

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

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

Re: Volunteer github guru for documentation submissions?

[Ali Lloyd]

 On Mon, Apr 11, 2016 at 9:55 PM J. Landman Gay 
wrote:

> BTW, I downloaded the elusive viewer stack but it's leaving out most of
>
the keywords when it opens the text in a browser. I can't tell if it's a
>
bug in the text itself or in the viewer. Anyone know?
>
I've updated a couple of text files but haven't submitted yet because of
>
the disconnect in the viewer.
>

The viewer stack was something I quickly knocked up so that there was
*some* way of viewing the document in context - the links indeed don't work
as it doesn't rebuild the whole dictionary. I'm sorry about that- I can
probably make it work properly at some point.

The line
*Navigate to the file you want to modify in the dictionary folder of the
community-docs branch
.*

with a link to the correct branch/folder was there before, but I've
submitted a PR to reinforce the fact that the community-docs branch should
be the base branch to modify the file:
https://github.com/livecodeali/livecode/blob/docs-base_branch/docs/contributing_to_docs.md#making-your-dictionary-change
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Tue, Apr 12, 2016 at 2:00 PM, J. Landman Gay 
wrote:

>
> Don't worry about being rude, you weren't really.


Well inconsiderate and lacked empathy. Everyone reads things differently
and their eyes catch something else on a web page. As Monte said, it's
great that this is gathering a bit of momentum, but if you had difficulty
then others surely will. So rather than telling you to see how I see, the
Guide really does need to be fine tuned so that no matter how any one reads
it, or what they focus on on the various web pages, they will be gently
herded in the correct direction, avoid tripping down holes of confusion,
and get to feel the same sense of accomplishment.
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Monte Goulding]

> On 12 Apr 2016, at 4:40 PM, J. Landman Gay  wrote:
> 
> I gotta say though, I had no idea you guys were spying on me through the air 
> vents.

If you watch the repo you get emails about everything.

It really is great things are starting to move on the contribution front. The 
more people that get involved the better.

Cheers

Monte
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/12/2016 12:38 AM, Mark Wieder wrote:

On 04/11/2016 09:32 PM, J. Landman Gay wrote:


*I'm* toasted. I worked it out by making a new name.


...and I see you managed to get past vulcan's Contributor's Agreement
hurdle as well.



I feel so...accomplished. Which is better than feeling stupid, which I 
did. Finding Vulcan's links weren't as hard though, there was only one 
per page and it kind of leads you by the nose.


I gotta say though, I had no idea you guys were spying on me through the 
air vents.


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

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

Re: Volunteer github guru for documentation submissions?

[J. Landman Gay]

Kay C Lan wrote:

The very first screenshot within the Using the
GitHub Web Interface guide shows: Branch: comm I think you can guess
it's the community branch. The Link given just above it to try as an
example is:

https://github.com/livecode/livecode/blob/community-docs/docs/dictionary/command/accept.lcdoc


I ended up with eight document tabs in my browser and a second window 
open for cross reference. I didn't notice the link you mention or the 
relevant part of the screenshot; at that point I didn't know what was 
important. There was too much to read. I do know what would have made it 
easier for me though and I'll write it up.


Don't worry about being rude, you weren't really.

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

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

Re: Volunteer github guru for documentation submissions?

[Kay C Lan]

Great!
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/11/2016 10:53 PM, Monte Goulding wrote:

>You appear to have worked it out and are now cooking with gas so I’ll have my 
sandwich tasted please ;-)

Aha… I meant toasted but you can taste it if you want ;-P


*I'm* toasted. I worked it out by making a new name.

I edited two entries and was pleased to see your comment there. Thanks 
for that, I'm sure I look like a dunce to the in-group. If I knew how to 
reply I would, but I think I've learned enough for today. I have also 
developed a healthy sympathy for the new people who come to the LC 
forums and don't know which end is up or where to start.


I owe you a sandwich.

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


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

Re: Volunteer github guru for documentation submissions?

[Monte Goulding]

> On 12 Apr 2016, at 1:12 PM, J. Landman Gay  wrote:
> 
> So how do I get my user name back?

You appear to have worked it out and are now cooking with gas so I’ll have my 
sandwich tasted please ;-)

Cheers

Monte
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

>
> On Apr 11, 2016, at 8:31 PM, J. Landman Gay 
> wrote:
> >
> > I think it says "object" should only be used for glossary entries:
>
> On Tue, Apr 12, 2016 at 11:01 AM, Devin Asay  wrote:
>
> Well, okay, but this confuses me.
>
> Devin
>
> In LC8 dp16 Dictionary, type in 'do state' and click on the 'do statement'
entry. Scroll down and have a look at 'Related:' the various Linked entries
- keyword; command: function: glossary:

Note that it just happens that none of the Glossary entries have anything
to do with objects.

Then in the Description section, if you pass you mouse along the first line
of the 2nd paragraph you'll note that the words 'command', 'executing',
'commands' turn into links.

Hopefully that better explains what I tried to type in my previous post.
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

Maybe someone knows how to fix this. I tried to join github and open an 
account. I typed "jacque" into the user name field. Github told me I 
needed to have cookies turned on, so I did that. Then I tried to fill 
out the rest of the fields and it said my user name was already taken. I 
started over in a different browser but my user name was still taken.


So how do I get my user name back?

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

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

Re: Volunteer github guru for documentation submissions?

[Devin Asay]

> On Apr 11, 2016, at 8:31 PM, J. Landman Gay  wrote:
> 
> On 4/11/2016 6:58 PM, Devin Asay wrote:
>> in the HTMLText document there were cross references to field (keyword) that 
>> really should have been field (object).
> 
> Just found this document:
> 
> 
> I think it says "object" should only be used for glossary entries:
> 
> ***
> Type (required)
> 
> The type of this API entry. One of the following: (API-level) * command * 
> function * property * message * constant * keyword * control structure * 
> operator * statement * expression
> 
> (Glossary-level) * library * widget * glossary * object
> ***
> 
> I think of fields as objects, but maybe something else is going on.

Well, okay, but this confuses me.

Devin



Devin Asay
Learn to code with LiveCode University
https://livecode.com/store/education/


___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Tue, Apr 12, 2016 at 10:31 AM, J. Landman Gay 
wrote:

>
> I think it says "object" should only be used for glossary entries:
>
> No that is not what it's saying. You will find that there are 3 separate
lcdocs relating to fields: keyword, object and glossary - you can tell from
the URL without clicking on them.

https://github.com/lan-kc/livecode/blob/develop/docs/glossary/f/field.lcdoc

https://github.com/lan-kc/livecode/blob/develop/docs/dictionary/keyword/field.lcdoc

https://github.com/lan-kc/livecode/blob/develop/docs/dictionary/object/field.lcdoc

Where this becomes important is that within the 'body' of the text if you
use the word 'field' and you are going to link it to another lcdoc you need
to know what context it is in so that in the Reference section of the lcdoc
you have the correct link: field (glossary). More importantly, if in the
'body' you refer to a field generically, so - field (glossary) and then as
an object, so field (object) link, and then again you refer to creating a
field, and therefore the use of field as a keyword, then you also need a
field (keyword) link. BUT THESE THREE need to be made unambiguous with the
way you <> the links in the 'body' so that each link will point to the
correct lcdoc

This entry is with the LiveCode Documentation Format Reference refers:

If the target name is shared by two references, then the link should be
> disambiguated by including the type in brackets:
> We might want to link to the  function and the
>  command in the same entry, if the references contain
> "other (function)" and "other (command)".


AND THEN MUST in the reference section have:

References: field (glossary), field (keyword), field (object) ... etc to
other links

HTH
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Ralph DiMola]

I will try it in 8 tomorrow. If I recall correctly it was different only if
you did "the effective formattedheight OF CHAR 1 TO -1 of field MyField"

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of J. Landman Gay
Sent: Monday, April 11, 2016 7:48 PM
To: How to use LiveCode
Subject: RE: Volunteer github guru for documentation submissions?

I tested this in LC 8 and wasn't getting any difference when adding
"effective" so maybe it's been changed. I'm editing the two formatted
properties right now and wasn't sure I should add the effective distinction.
Do you get a difference in 8?

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



On April 11, 2016 5:25:53 PM "Ralph DiMola" <rdim...@evergreeninfo.net>
wrote:

> The "Effective" modifier for "formattedheight". This modifier will
calculate
> the text height in a field allowing for maximum acenders and decenders in
> the field's current text. Without the "Effective" modifier the height is
> calculated for the maximum acenders and decenders in the entire font set.
>
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdim...@evergreeninfo.net
>
>
> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
Behalf
> Of Mark Smith
> Sent: Monday, April 11, 2016 3:53 PM
> To: use-revolut...@lists.runrev.com
> Subject: Re: Volunteer github guru for documentation submissions?
>
> Does anyone have a documentation bug they would like to see fixed? I'd
like
> to give Ali's guide a try but don't have any documentation bugs top of
mind.
>
> Mark
>
>
>
> --
> View this message in context:
>
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-doc
> umentation-submissions-tp4703029p4703298.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> ___
> use-livecode mailing list
> use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/11/2016 6:58 PM, Devin Asay wrote:

in the HTMLText document there were cross references to field (keyword) that 
really should have been field (object).


Just found this document:


I think it says "object" should only be used for glossary entries:

***
Type (required)

The type of this API entry. One of the following: (API-level) * command 
* function * property * message * constant * keyword * control structure 
* operator * statement * expression


(Glossary-level) * library * widget * glossary * object
***

I think of fields as objects, but maybe something else is going on.

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

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

Re: Volunteer github guru for documentation submissions?

[Kay C Lan]

Actually, that last post of mine was very rude. Sorry. Let me start again.

If there is anything within the Contributing to LiveCode Documentation at:

https://github.com/livecode/livecode/blob/community-docs/docs/contributing_to_docs.md

that can be improved, i.e. links to Branches that aren't obvious, or
hilighting [highlighting] of URLs that need to be check so you know you are
in the right place, or could be bookmarked so you can quickly return to the
right place. Please drop Ali a line, with screenshots if you can, and he
will incorporate those improvements.

Again, sorry for my earlier post.

On Tue, Apr 12, 2016 at 10:15 AM, Kay C Lan 
wrote:

> On Tue, Apr 12, 2016 at 10:08 AM, J. Landman Gay  > wrote:
>
>>
>>> If there's a community branch, it's another secret link.
>>>
>>
>> Found it, it's buried under all the bug fixes. Basically you have to know
>> it exists and type it into the combo box field to get there.
>>
>> After the very first visit, knowing I'd be back I simply bookmarked:
>
> https://github.com/livecode/livecode/tree/community-docs/docs
>
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Tue, Apr 12, 2016 at 10:08 AM, J. Landman Gay 
wrote:

>
>> If there's a community branch, it's another secret link.
>>
>
> Found it, it's buried under all the bug fixes. Basically you have to know
> it exists and type it into the combo box field to get there.
>
> After the very first visit, knowing I'd be back I simply bookmarked:

https://github.com/livecode/livecode/tree/community-docs/docs
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Tue, Apr 12, 2016 at 9:54 AM, J. Landman Gay 
wrote:

> On 4/11/2016 6:58 PM, Devin Asay wrote:
>
>>  instead use the community-docs
>> branch athttps://github.com/livecode/livecode/tree/community-docs
>> and make edits there. Maybe that is obvious to others; it wasn’t to
>> me.
>>
>
> There's no path to that in the web interface. The only one I see is
> docs/dictionary/ which takes you directly to /develop. (And if I was
> looking for "/tree/" it isn't there either.)
>
> If there's a community branch, it's another secret link.


I don't understand this. The very first screenshot within the Using the
GitHub Web Interface guide shows: Branch: comm I think you can guess
it's the community branch. The Link given just above it to try as an
example is:

https://github.com/livecode/livecode/blob/community-docs/docs/dictionary/command/accept.lcdoc

now I don't know the ins and outs, but when I click on that it takes me to
Branch: community and although it starts out as
'livecode/blob/community-docs/' as soon as I go to any individual document
it automatically changes to 'livecode/tree/community-docs/'
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Tue, Apr 12, 2016 at 9:43 AM, J. Landman Gay 
wrote:

>
> Another thing to do would be to go through a pre-8 dictionary and look at
> entries with user notes. Those aren't included in the LC 8 dictionary and
> if you see some that are useful, add them to the main description.
>
> Monte, are you going to comment on this? By the way I still haven't heard
back form my 'unsigned' contributor.
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/11/2016 8:54 PM, J. Landman Gay wrote:


If there's a community branch, it's another secret link.


Found it, it's buried under all the bug fixes. Basically you have to 
know it exists and type it into the combo box field to get there.


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

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

Re: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/11/2016 6:58 PM, Devin Asay wrote:

Don’t start in the main develop branch (livecode/livecode/develop)
when making documentation fixes; instead use the community-docs
branch athttps://github.com/livecode/livecode/tree/community-docs
and make edits there. Maybe that is obvious to others; it wasn’t to
me.


There's no path to that in the web interface. The only one I see is 
docs/dictionary/ which takes you directly to /develop. (And if I was 
looking for "/tree/" it isn't there either.)


If there's a community branch, it's another secret link.

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


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

Re: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/11/2016 5:14 PM, Mark Smith wrote:

Thanks Jackie. That one is now submitted. Have any others (send me your list
if you'd like)? Once I've done this a few times I'd like to abbreviate the
instructions (but I need to understand the process a bit better).


Like Devin said, almost everything I look at needs at least a minor 
tweak. I was just reading the encrypt entry. It's missing examples, but 
I don't know enough about encryption to add meaningful ones. If you do, 
that'd be great.


Another thing to do would be to go through a pre-8 dictionary and look 
at entries with user notes. Those aren't included in the LC 8 dictionary 
and if you see some that are useful, add them to the main description.


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

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

Re: Volunteer github guru for documentation submissions?

[Mike Kerner]

The good news is that if you make an edit after a pull request, at least if
you're using github desktop, you don't have to re-submit the pull request,
as long as no action has taken place on the original one.  I found that out
when I was working on send and pendingMessages.  I also made the mistake of
being in the wrong branch (I think the branch issue is going to be a
constant problem).

On Mon, Apr 11, 2016 at 7:58 PM, Devin Asay  wrote:

> On Apr 11, 2016, at 4:14 PM, Mark Smith 
> wrote:
> >
> > Thanks Jackie. That one is now submitted. Have any others (send me your
> list
> > if you'd like)? Once I've done this a few times I'd like to abbreviate
> the
> > instructions (but I need to understand the process a bit better).
>
> Mark,
>
> I’m on the same learning curve as you right now. I’m having no problem
> finding little problems to fix—I just browse through dictionary entries for
> terms I’m pretty familiar with and do a close reading of the whole
> thing—syntax, examples, description, the works. I almost always find some
> little thing that needs fixing, like misspellings, missing examples and
> inaccuracies/omissions in the description. One common problem is missing or
> inappropriate entries in the “Related” category. For example, in one
> document I found that there were cross references to “keyword” where it
> really should have been “object” or “glossary". E.g. in the HTMLText
> document there were cross references to field (keyword) that really should
> have been field (object).
>
> Here are a couple of github lessons learned so far:
>
> Don’t start in the main develop branch (livecode/livecode/develop) when
> making documentation fixes; instead use the community-docs branch at
> https://github.com/livecode/livecode/tree/community-docs and make edits
> there. Maybe that is obvious to others; it wasn’t to me.
>
> As long as you’re editing a document, do the close reading I talked about
> and make all of the changes at once. A couple of times I’ve found something
> I missed and had to go back and re-edit then re-submit the pull request.
>
> It’s been a learning curve, but the good news is my head doesn’t hurt
> quite as much as it did last week. :)
>
> Devin
>
>
> Devin Asay
> Office of Digital Humanities
> Brigham Young University
>
> ___
> use-livecode mailing list
> use-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: Volunteer github guru for documentation submissions?

[Devin Asay]

On Apr 11, 2016, at 4:14 PM, Mark Smith  wrote:
> 
> Thanks Jackie. That one is now submitted. Have any others (send me your list
> if you'd like)? Once I've done this a few times I'd like to abbreviate the
> instructions (but I need to understand the process a bit better).

Mark,

I’m on the same learning curve as you right now. I’m having no problem finding 
little problems to fix—I just browse through dictionary entries for terms I’m 
pretty familiar with and do a close reading of the whole thing—syntax, 
examples, description, the works. I almost always find some little thing that 
needs fixing, like misspellings, missing examples and inaccuracies/omissions in 
the description. One common problem is missing or inappropriate entries in the 
“Related” category. For example, in one document I found that there were cross 
references to “keyword” where it really should have been “object” or 
“glossary". E.g. in the HTMLText document there were cross references to field 
(keyword) that really should have been field (object). 

Here are a couple of github lessons learned so far:

Don’t start in the main develop branch (livecode/livecode/develop) when making 
documentation fixes; instead use the community-docs branch at 
https://github.com/livecode/livecode/tree/community-docs and make edits there. 
Maybe that is obvious to others; it wasn’t to me.

As long as you’re editing a document, do the close reading I talked about and 
make all of the changes at once. A couple of times I’ve found something I 
missed and had to go back and re-edit then re-submit the pull request.

It’s been a learning curve, but the good news is my head doesn’t hurt quite as 
much as it did last week. :)

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University

___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

I tested this in LC 8 and wasn't getting any difference when adding 
"effective" so maybe it's been changed. I'm editing the two formatted 
properties right now and wasn't sure I should add the effective 
distinction. Do you get a difference in 8?


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



On April 11, 2016 5:25:53 PM "Ralph DiMola" <rdim...@evergreeninfo.net> wrote:


The "Effective" modifier for "formattedheight". This modifier will calculate
the text height in a field allowing for maximum acenders and decenders in
the field's current text. Without the "Effective" modifier the height is
calculated for the maximum acenders and decenders in the entire font set.

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Mark Smith
Sent: Monday, April 11, 2016 3:53 PM
To: use-revolut...@lists.runrev.com
Subject: Re: Volunteer github guru for documentation submissions?

Does anyone have a documentation bug they would like to see fixed? I'd like
to give Ali's guide a try but don't have any documentation bugs top of mind.

Mark



--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-doc
umentation-submissions-tp4703029p4703298.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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


___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Mark Smith]

Thanks Jackie. That one is now submitted. Have any others (send me your list
if you'd like)? Once I've done this a few times I'd like to abbreviate the
instructions (but I need to understand the process a bit better).




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-documentation-submissions-tp4703029p4703303.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

RE: Volunteer github guru for documentation submissions?

[Ralph DiMola]

The "Effective" modifier for "formattedheight". This modifier will calculate
the text height in a field allowing for maximum acenders and decenders in
the field's current text. Without the "Effective" modifier the height is
calculated for the maximum acenders and decenders in the entire font set. 

Ralph DiMola
IT Director
Evergreen Information Services
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf
Of Mark Smith
Sent: Monday, April 11, 2016 3:53 PM
To: use-revolut...@lists.runrev.com
Subject: Re: Volunteer github guru for documentation submissions?

Does anyone have a documentation bug they would like to see fixed? I'd like
to give Ali's guide a try but don't have any documentation bugs top of mind.

Mark



--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-doc
umentation-submissions-tp4703029p4703298.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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


___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/11/2016 2:52 PM, Mark Smith wrote:

Does anyone have a documentation bug they would like to see fixed? I'd like
to give Ali's guide a try but don't have any documentation bugs top of mind.


I have a short list. Here's a small one:

  textShift is not tagged as "text processing"

BTW, I downloaded the elusive viewer stack but it's leaving out most of 
the keywords when it opens the text in a browser. I can't tell if it's a 
bug in the text itself or in the viewer. Anyone know?


I've updated a couple of text files but haven't submitted yet because of 
the disconnect in the viewer.


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

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

Re: Volunteer github guru for documentation submissions?

[Mark Smith]

Does anyone have a documentation bug they would like to see fixed? I'd like
to give Ali's guide a try but don't have any documentation bugs top of mind.

Mark



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Volunteer-github-guru-for-documentation-submissions-tp4703029p4703298.html
Sent from the Revolution - User mailing list archive at Nabble.com.

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

Re: Volunteer github guru for documentation submissions?

[Mark Wieder]

On 04/06/2016 01:44 PM, J. Landman Gay wrote:


You know, even just linking to the blog post from github would have done
the trick. We just need some kind of discoverable pathway over there.



Nice idea. Seconded.

--
 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: Volunteer github guru for documentation submissions?

[Peter TB Brett]

On 06/04/2016 21:41, J. Landman Gay wrote:

On 4/6/2016 3:17 PM, Ali Lloyd wrote:

Jacque, you may want to read this blog post
https://livecode.com/putting-the-you-in-documentation/


I did, back when you posted it, and that's what made me decide I should
pitch in. But I no longer had the reference handy.


What happens when you type "how do I contribute to LiveCode 
documentation" into Google?


   Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Peter TB Brett]

On 06/04/2016 21:44, J. Landman Gay wrote:

On 4/6/2016 3:17 PM, Ali Lloyd wrote:

Jacque, you may want to read this blog post
https://livecode.com/putting-the-you-in-documentation/


You know, even just linking to the blog post from github would have done
the trick. We just need some kind of discoverable pathway over there.


I'm not sure we can do better than having a top-level file called 
"CONTRIBUTING" and a file called "docs/contributing_to_docs".  I mean, 
that's the recommended, standard way to document how to contribute used 
across the majority of modern open source software.


I'll look into moving the "Contributing to LiveCode" section towards the 
top of the README file.


Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/6/2016 3:17 PM, Ali Lloyd wrote:

Jacque, you may want to read this blog post
https://livecode.com/putting-the-you-in-documentation/


You know, even just linking to the blog post from github would have done 
the trick. We just need some kind of discoverable pathway over there.


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

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

Re: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/6/2016 3:17 PM, Ali Lloyd wrote:

Jacque, you may want to read this blog post
https://livecode.com/putting-the-you-in-documentation/


I did, back when you posted it, and that's what made me decide I should 
pitch in. But I no longer had the reference handy. I'd like to see an 
easy way to get to the guide(s) without needing to find (or even know 
about) URLs that were posted somewhere in the past. If you could add a 
Contributor Info directory at the top level of the main livecode 
directory, it would help new people orient themselves easily.


If it's too hard to find the info, people will give up.

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

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

Re: Volunteer github guru for documentation submissions?

[Ali Lloyd]

Jacque, you may want to read this blog post
https://livecode.com/putting-the-you-in-documentation/

On Wed, Apr 6, 2016 at 7:25 PM J. Landman Gay 
wrote:

> On 4/6/2016 1:45 AM, Monte Goulding wrote:
> > I hadn’t seen the contributing to the docs guide so even though I
> > know my way around GitHub it was fresh eyes on finding the docs.
> > Here’s what I did: - openhttps://github.com/livecode/livecode/
>
> That was my first hurdle. You already knew to go to the
> livecode/livecode directory, which is clearly marked as an engine
> folder. That's not intuitive, one would expect the dictionary to be in
> the IDE directory. I know it's in the engine folder because reasons, but
> only because I wrote here and you told me. I spent an inordinate amount
> of time looking through all the others first.
>
> > - see
> > the “Contributing to LiveCode” section links to the CONTRIBUTING
> > filehttps://github.com/livecode/livecode/blob/develop/CONTRIBUTING.md
>
> Second hurdle. After finally venturing into the livecode/livecode
> directory I was met with a wall of activity. I scrolled, scrolled,
> scrolled, and decided there was nothing I could use so backed out again.
>
> So I went back to the URL that Mark linked to, remembering I'd seen some
> breadcrumbs in one of the screenshots (someone without that link would
> have quit by now.) Some images were too small to read clearly so I spent
> another ten minutes clicking each one to view it larger. I finally found
> the one with breadcrumbs and headed back to the livecode/livecode
> directory. I scrolled all the way past the wall of activity looking for
> something familiar. I didn't see anything but I found the text
> instructions way at the bottom.
>
> It discussed repositories and compiling and target platforms. I didn't
> click the Contributing link because it seemed to apply to engine
> contributions; that was the directory I was in, and that's what the text
> discussed.
>
> I had to write to the list just to find out how to find out stuff.
>
> The uninitiated need a clear path to information. The top level entry
> page should have its own directory labelled "Contributor Guides". In
> that directory should be a link to information regarding engine
> contributions, and a second link to the documentation guide. I would
> have found it immediately.
>
> I still don't know what this elusive "viewer" is, but I'm not going to
> bother with it.
>
> --
> >
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/6/2016 1:45 AM, Monte Goulding wrote:

I hadn’t seen the contributing to the docs guide so even though I
know my way around GitHub it was fresh eyes on finding the docs.
Here’s what I did: - openhttps://github.com/livecode/livecode/


That was my first hurdle. You already knew to go to the 
livecode/livecode directory, which is clearly marked as an engine 
folder. That's not intuitive, one would expect the dictionary to be in 
the IDE directory. I know it's in the engine folder because reasons, but 
only because I wrote here and you told me. I spent an inordinate amount 
of time looking through all the others first.



- see
the “Contributing to LiveCode” section links to the CONTRIBUTING
filehttps://github.com/livecode/livecode/blob/develop/CONTRIBUTING.md


Second hurdle. After finally venturing into the livecode/livecode 
directory I was met with a wall of activity. I scrolled, scrolled, 
scrolled, and decided there was nothing I could use so backed out again.


So I went back to the URL that Mark linked to, remembering I'd seen some 
breadcrumbs in one of the screenshots (someone without that link would 
have quit by now.) Some images were too small to read clearly so I spent 
another ten minutes clicking each one to view it larger. I finally found 
the one with breadcrumbs and headed back to the livecode/livecode 
directory. I scrolled all the way past the wall of activity looking for 
something familiar. I didn't see anything but I found the text 
instructions way at the bottom.


It discussed repositories and compiling and target platforms. I didn't 
click the Contributing link because it seemed to apply to engine 
contributions; that was the directory I was in, and that's what the text 
discussed.


I had to write to the list just to find out how to find out stuff.

The uninitiated need a clear path to information. The top level entry 
page should have its own directory labelled "Contributor Guides". In 
that directory should be a link to information regarding engine 
contributions, and a second link to the documentation guide. I would 
have found it immediately.


I still don't know what this elusive "viewer" is, but I'm not going to 
bother with it.


--



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


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

Re: Volunteer github guru for documentation submissions?

[Mike Kerner]

The guides are a long read.  If I get up the motivation, I'm going to at
least try to work on them so it doesn't feel so much like work.

On Wed, Apr 6, 2016 at 11:10 AM, Devin Asay  wrote:

>
> > On Apr 6, 2016, at 12:38 AM, J. Landman Gay 
> wrote:
> >
> > On 4/5/2016 10:26 AM, Mark Wieder wrote:
> >> But I do want to say that there's fascinating reading in
> >> https://github.com/livecode/livecode/pull/3518#issuecomment-205199749
> >
> > It's only fascinating if you understand all the jargon. I read it and
> came away with nothing but frustration. I have only the vaguest idea what
> half those terms mean and the screen shots are confusing.
> >
> > Where's this "guide" they talk about? And there's some kind of viewer?
> Where? Where are Ali's instructions for using the web interface? It took me
> forever just to find where the actual documentation files live. (Why are
> the doc files in the *engine* category? Wouldn't one logically look in the
> IDE category?)
> >
> > Pointers to instructions should be located prominently somewhere,
> ideally on the entry page. Github is a maze at best, novices shouldn't have
> to hunt for elusive instructions. I'm pretty sure someone here will give me
> a link, but that isn't going to help the next person.
>
> Ditto. Github for Dummies workshop at the LiveCode Dev Conference, anyone?
>
> Devin
>
>
> Devin Asay
> Office of Digital Humanities
> Brigham Young University
>
>
> ___
> use-livecode mailing list
> use-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: Volunteer github guru for documentation submissions?

[Devin Asay]

> On Apr 6, 2016, at 12:38 AM, J. Landman Gay  wrote:
> 
> On 4/5/2016 10:26 AM, Mark Wieder wrote:
>> But I do want to say that there's fascinating reading in
>> https://github.com/livecode/livecode/pull/3518#issuecomment-205199749
> 
> It's only fascinating if you understand all the jargon. I read it and came 
> away with nothing but frustration. I have only the vaguest idea what half 
> those terms mean and the screen shots are confusing.
> 
> Where's this "guide" they talk about? And there's some kind of viewer? Where? 
> Where are Ali's instructions for using the web interface? It took me forever 
> just to find where the actual documentation files live. (Why are the doc 
> files in the *engine* category? Wouldn't one logically look in the IDE 
> category?)
> 
> Pointers to instructions should be located prominently somewhere, ideally on 
> the entry page. Github is a maze at best, novices shouldn't have to hunt for 
> elusive instructions. I'm pretty sure someone here will give me a link, but 
> that isn't going to help the next person.

Ditto. Github for Dummies workshop at the LiveCode Dev Conference, anyone?

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University


___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Wed, Apr 6, 2016 at 2:38 PM, J. Landman Gay 
wrote:

Monte's already pointed you to Ali's Web Interface Instructions.


> Why are the doc files in the *engine* category? Wouldn't one logically
> look in the IDE category?


When you use the Web Interface the docs are logically located in the
community-docs/docs/dictionary folder:

https://github.com/livecode/livecode/tree/community-docs/docs/dictionary

Here the logic continues with Commands in the commands folder, Constants in
the constants folder etc etc.

The only bit that might confuse is the Glossary entries aren't here.
Towards the top of the Web interface there is a breadcrumb path to your
current location, it will be something like livecode / docs / dictionary /
function / exists.lcdoc

If you want to do a Glossary entry simply click on 'docs', it will take you
back to the docs folder where you'll note not just the dictionary folder
but also the glossary folder and other goodies. If the glossary not being
in the dictionary folder is of concern I'm sure if you suggest to Ali a
symlink he'd be right onto it.
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Monte Goulding]

> On 6 Apr 2016, at 4:45 PM, Monte Goulding  wrote:
> 
>> Why are the doc files in the *engine* category? Wouldn't one logically look 
>> in the IDE category?

I didn’t answer this bit. For the most part the documentation is not 
documenting the IDE so it makes more sense for it to be in the engine 
repository. If someone changes or adds a command then it makes sense that they 
can change or add documentation for it into the one repository.

Cheers

Monte
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Monte Goulding]

> On 6 Apr 2016, at 4:38 PM, J. Landman Gay  wrote:
> 
> On 4/5/2016 10:26 AM, Mark Wieder wrote:
>> But I do want to say that there's fascinating reading in
>> https://github.com/livecode/livecode/pull/3518#issuecomment-205199749
> 
> It's only fascinating if you understand all the jargon. I read it and came 
> away with nothing but frustration. I have only the vaguest idea what half 
> those terms mean and the screen shots are confusing.
> 
> Where's this "guide" they talk about? And there's some kind of viewer? Where? 
> Where are Ali's instructions for using the web interface? It took me forever 
> just to find where the actual documentation files live. (Why are the doc 
> files in the *engine* category? Wouldn't one logically look in the IDE 
> category?)
> 
> Pointers to instructions should be located prominently somewhere, ideally on 
> the entry page. Github is a maze at best, novices shouldn't have to hunt for 
> elusive instructions. I'm pretty sure someone here will give me a link, but 
> that isn't going to help the next person.

Hi Jacque

I hadn’t seen the contributing to the docs guide so even though I know my way 
around GitHub it was fresh eyes on finding the docs. Here’s what I did:
 - open https://github.com/livecode/livecode/
 - see the “Contributing to LiveCode” section links to the CONTRIBUTING file 
https://github.com/livecode/livecode/blob/develop/CONTRIBUTING.md
 - Right at the top there is "See also the documentation contributions guide.” 
linked to 
https://github.com/livecode/livecode/blob/develop/docs/contributing_to_docs.md
 - Scroll down to find the “Using the GitHub Web Interface” section

Cheers

Monte
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[J. Landman Gay]

On 4/5/2016 10:26 AM, Mark Wieder wrote:

But I do want to say that there's fascinating reading in
https://github.com/livecode/livecode/pull/3518#issuecomment-205199749


It's only fascinating if you understand all the jargon. I read it and 
came away with nothing but frustration. I have only the vaguest idea 
what half those terms mean and the screen shots are confusing.


Where's this "guide" they talk about? And there's some kind of viewer? 
Where? Where are Ali's instructions for using the web interface? It took 
me forever just to find where the actual documentation files live. (Why 
are the doc files in the *engine* category? Wouldn't one logically look 
in the IDE category?)


Pointers to instructions should be located prominently somewhere, 
ideally on the entry page. Github is a maze at best, novices shouldn't 
have to hunt for elusive instructions. I'm pretty sure someone here will 
give me a link, but that isn't going to help the next person.


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

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

Re: Volunteer github guru for documentation submissions?

[Mark Wieder]

On 04/05/2016 06:41 PM, Kay C Lan wrote:

Mark Wieder wrote:

But I do want to say that there's fascinating reading in
https://github.com/livecode/livecode/pull/3518#issuecomment-205199749


If you've had a look at that thread you'll see some of it is related to the
Instructions for using the Web Interface to access the Docs on Github. As
you'll note Ali is EXTREMELY receptive to any comments on improving them to
make it easier for the Gitphobic to successful get on and do simple
amendments


Yes, exactly my point. The interplay between you and Ali in coming 
together to make the process work better is great!


--
 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: Volunteer github guru for documentation submissions?

[Monte Goulding]

> On 6 Apr 2016, at 12:25 PM, Mike Kerner  wrote:
> 
> Just to be clear, you don't need to use gitHub, etc. to work on any of the
> files.  The web interface is easy enough to use.  You just have to get to
> the file you want to edit, Hit the edit button, make your changes, explain
> them, and you're done.  It really is very simple without having to fork,
> etc. to get there.

Not to be pedantic but the web interface *is* GitHub. GitHub is a web interface 
for remote git repositories. There are a number of such interfaces (BitBucket, 
GitLab, GitWeb etc). So to clarify: using GitHub you can avoid having to use 
git locally. You are actually still using git though remotely and via a web 
interface. Git really is a helpful thing in your toolbox and I encourage 
everyone to spend a little bit of time learning it regardless of whether you 
would like to contribute to LiveCode or not. One thing I use it for is web 
deployment. I can make a change locally, commit and push to the server and that 
will trigger a shell script to run on the server (called a post-update hook) 
which deploys my web app.

Cheers

Monte

___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Charles Warwick]

On 6/04/2016 4:36 am, J. Landman Gay wrote:

On 4/5/2016 2:26 AM, Kay C Lan wrote:

That's why I suggested prefixing the subject with [DOC] so as people
can quickly filter out subjects they are not interested in. Thank you
those who use [ANN] [BUG] and [OT] - very helpful. I also envisaged
(maybe wrongly) that you wouldn't be posting the entire document, just
the portion/line/paragraph of relevance


I was on a different track, planning to grab the latest file, edit it, 
and send it back to github via our Good Deed Doer, that is, Charles.


It would be the same process as anyone else uses who knows github, 
only using a proxy person.


My offer was based on exactly that, getting a complete file sent through 
so that I could just copy into my livecode repo and submit it.


As others have already said, once you have created a github account, 
signed the contributors agreement and (if you are not using the web 
interface)
established your local/github livecode repository, the ongoing process 
of submitting contributions is not difficult.


I recommend that anyone who wants to contribute to LiveCode should at 
least give it a go, following the instructions that have been provided 
by Ali

and others.

However, for those that are struggling with that process, my offer 
stands so that their contributions can still be included.


Cheers,

Charles

___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

On Wed, Apr 6, 2016 at 10:25 AM, Mike Kerner 
wrote:

> Just to be clear, you don't need to use gitHub, etc. to work on any of the
> files.  The web interface is easy enough to use.  You just have to get to
> the file you want to edit, Hit the edit button, make your changes, explain
> them, and you're done.  It really is very simple without having to fork,
> etc. to get there.
>
> You still need to Sign the Contributor's License Agreement (CLA) and sign
up to Github account, but yes, all the instructions mentioned above relate
to using the Git Web Interface which is the easiest of all.
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Mike Kerner]

Just to be clear, you don't need to use gitHub, etc. to work on any of the
files.  The web interface is easy enough to use.  You just have to get to
the file you want to edit, Hit the edit button, make your changes, explain
them, and you're done.  It really is very simple without having to fork,
etc. to get there.

Tonight, for instance, just to prove to myself that the web interface was
easy (instead of using github and Atom), I modified the docs for send and
pendingMessages.  I probalby spent less than ten minutes, total.  The
desktop tools are nice for editing offline and having your own copy of the
various files, and having the prettyprinting/formatting, but it is not
necessary.

On Tue, Apr 5, 2016 at 9:41 PM, Kay C Lan  wrote:

> Mark Wieder wrote:
> >But I do want to say that there's fascinating reading in
> >https://github.com/livecode/livecode/pull/3518#issuecomment-205199749
>
> If you've had a look at that thread you'll see some of it is related to the
> Instructions for using the Web Interface to access the Docs on Github. As
> you'll note Ali is EXTREMELY receptive to any comments on improving them to
> make it easier for the Gitphobic to successful get on and do simple
> amendments
>
> On Wed, Apr 6, 2016 at 7:22 AM, Alex Tweedly  wrote:
> > I followed Ali's
> > instructions cautiously and slowly, hit [two minor bumps]
> >
> > I even took the opportunity to practice with a real example - and fixed
> the
> > minor issues with the instructions, so anyone else following them now
> should
> > have an even smoother experience.
> >
> Thank you!
>
> But for those who are Gitphobic I can also assure you that if you mention
> any issues you have following the instructions to Ali, with clear
> instruction on how to improve the guide to remove any ambiguity or head
> scratching, he'll implement them immediately.
>
> > So if you haven't done it yet - give it a go. Fill in the Contributors'
> > Agreement, find some minor issue in the docs to improve, set aside 20-30
> > minutes and go for it!
>
> And that should be just the first time. From then on any further amendments
> should go much much quicker.
> >
> > If anything does go wrong, either the experts on the use-list or the
> helpful
> > guys at Livecode will help you through :-)
> >
> Also, stating the obvious, you CAN'T break anything. If you think you've
> completely botched something and completely messed up a document, because
> it's Git all the previous versions are safely stored so you (or the team)
> can easily restore the last usable version.
>
> With trepidation I will also mention that the above thread also talks a lot
> about the many anomalies (errors) with the documents; it's grown to a
> daunting list. What I want to say is that this should NOT put anyone off
> contributing. The way I see it there are two ways to contribute: 10 people
> can each contribute 10% of a documents corrections - each one focusing on
> whatever their pet peeve is. OR, you can attempt to cover 100% of errors.
> Because of my work/internet/spare time situation, I want to attempt to
> correct as many issues in one pass of a document as possible - but I can't
> spell, I don't do Windows or Linux, so I know I can't achieve 100%. But in
> the end it doesn't matter if all you do is just spelling errors, or just
> Linux examples, or you attempt to correct Parameters AND References AND
> Associations AND Tags; the result is the same - every little bit means the
> documents are better.
> ___
> use-livecode mailing list
> use-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: Volunteer github guru for documentation submissions?

[Kay C Lan]

Mark Wieder wrote:
>But I do want to say that there's fascinating reading in
>https://github.com/livecode/livecode/pull/3518#issuecomment-205199749

If you've had a look at that thread you'll see some of it is related to the
Instructions for using the Web Interface to access the Docs on Github. As
you'll note Ali is EXTREMELY receptive to any comments on improving them to
make it easier for the Gitphobic to successful get on and do simple
amendments

On Wed, Apr 6, 2016 at 7:22 AM, Alex Tweedly  wrote:
> I followed Ali's
> instructions cautiously and slowly, hit [two minor bumps]
>
> I even took the opportunity to practice with a real example - and fixed
the
> minor issues with the instructions, so anyone else following them now
should
> have an even smoother experience.
>
Thank you!

But for those who are Gitphobic I can also assure you that if you mention
any issues you have following the instructions to Ali, with clear
instruction on how to improve the guide to remove any ambiguity or head
scratching, he'll implement them immediately.

> So if you haven't done it yet - give it a go. Fill in the Contributors'
> Agreement, find some minor issue in the docs to improve, set aside 20-30
> minutes and go for it!

And that should be just the first time. From then on any further amendments
should go much much quicker.
>
> If anything does go wrong, either the experts on the use-list or the
helpful
> guys at Livecode will help you through :-)
>
Also, stating the obvious, you CAN'T break anything. If you think you've
completely botched something and completely messed up a document, because
it's Git all the previous versions are safely stored so you (or the team)
can easily restore the last usable version.

With trepidation I will also mention that the above thread also talks a lot
about the many anomalies (errors) with the documents; it's grown to a
daunting list. What I want to say is that this should NOT put anyone off
contributing. The way I see it there are two ways to contribute: 10 people
can each contribute 10% of a documents corrections - each one focusing on
whatever their pet peeve is. OR, you can attempt to cover 100% of errors.
Because of my work/internet/spare time situation, I want to attempt to
correct as many issues in one pass of a document as possible - but I can't
spell, I don't do Windows or Linux, so I know I can't achieve 100%. But in
the end it doesn't matter if all you do is just spelling errors, or just
Linux examples, or you attempt to correct Parameters AND References AND
Associations AND Tags; the result is the same - every little bit means the
documents are better.
___
use-livecode mailing list
use-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: Volunteer github guru for documentation submissions?

[Alex Tweedly]

I fully agree - it ain't that hard, even I could do it.

This is the first time I've used git, or Github, etc.  I followed Ali's 
instructions cautiously and slowly, hit one minor bump-in-the-road 
(which Mark solved for me within minutes courtesy of the use-list), one 
more minor issue which was obvious enough to guess my way round it - and 
I got through it all OK.


I even took the opportunity to practice with a real example - and fixed 
the minor issues with the instructions, so anyone else following them 
now should have an even smoother experience.


So if you haven't done it yet - give it a go. Fill in the Contributors' 
Agreement, find some minor issue in the docs to improve, set aside 20-30 
minutes and go for it!


If anything does go wrong, either the experts on the use-list or the 
helpful guys at Livecode will help you through :-)


-- Alex.

On 05/04/2016 18:31, Mark Wieder wrote:

On 04/05/2016 09:35 AM, J. Landman Gay wrote:


As our glorious ex-leader used to say,,  I misremembered.


Well, since that lets me off the hook, let me say now that really, it 
ain't that hard to do. There's a bit of setup involved, but after that 
you're home free.





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