subject:"Re\: Error Messages Are Evil"

Thanks for the responses folks. Keep them coming, and I'll post a summary.

Here's another one of mine:

Names of blendLevel inks: Whaaa? What do those things even mean?

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: IDE oddities (was Re: Error Messages Are Evil)

Try resizing something, or using the alignment tools.

I just ran into this, again, this week, when I was trying to fix a vertical
line.  The line is too short, so I changed the length.  The line
lengthened, UPWARD.  So I then changed the top of the line, thinking that
would help me except the bottom stayed and thus the line was shorter,
again, but I missed that the resize checkbox was unchecked - because, if
you don't have resize checked, then when you change a coordinate of an
object, it just moves the object.

What's even weirder about that is that normally, now, when I create a line,
if I resize it I get the even more bizarre behavior of having the line
lengthen in BOTH directions with the center fixed, which is generally
followed by my shaking my monitor and screaming at it.

Now, go try to use the equalize/align/distribute tools.  Throw three or
four objects on a card and use them.


Is this also where I get to remind everyone about LC's bigotry toward
items?  You know, because ,,a is three items, but a,, and ,a, only
counts as two?


On Thu, May 15, 2014 at 10:42 AM, Devin Asay devin_a...@byu.edu wrote:

 Thanks for the responses folks. Keep them coming, and I'll post a summary.

 Here's another one of mine:

 Names of blendLevel inks: Whaaa? What do those things even mean?

 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: IDE oddities (was Re: Error Messages Are Evil)

And another:
If you have your lappie hooked to two monitors at work, and you use both
monitors, and then you go home, guess what happens to windows, especially
on a Mac, where you are using multiple workspaces?  That's right, the
windows, even the LC development windows, are off-screen somewhere at
3750,150, and your only hope of getting them back is to figure out what the
name of the development window is (say, the message box, or a properties
palette, or maybe the script editor and then going to the message box and
moving it manually.

The good news with most of the things that we complain about is that
because you can modify LC from within LC, you can fix these things
yourself.  The bad news is that when you run into these sorts of things,
there isn't an uproar from the community that puts pressure on Edinburgh to
drop refactoring the engine to fix something.

HOWEVER, I think I'd take it this way, because this way, there is an
economic motive for some author to release a tool that does something
better than LC does, or is ready before LC might make it a priority.  Yes,
it costs money to purchase those tools, but it makes the ecosystem better,
even though the IDE isn't better.


On Thu, May 15, 2014 at 11:16 AM, Mike Kerner mikeker...@roadrunner.comwrote:

 Whoops!  Wait, a second, here's another:
 The locked of the properties palette for each object is separate and
 persistent.  This is really great when you are working with a component or
 object that is installed by another developer, and want to look at two of
 the developer's objects side-by-side and make one like the other, but
 really awful when you don't, because you're stuck with it.  You're not in
 charge of your setup, the component developer is, and if you have to fix
 something in that component, you are in for a lot of extra clicks and
 palette issues.


 On Thu, May 15, 2014 at 11:10 AM, Mike Kerner 
 mikeker...@roadrunner.comwrote:

 Try resizing something, or using the alignment tools.

 I just ran into this, again, this week, when I was trying to fix a
 vertical line.  The line is too short, so I changed the length.  The line
 lengthened, UPWARD.  So I then changed the top of the line, thinking that
 would help me except the bottom stayed and thus the line was shorter,
 again, but I missed that the resize checkbox was unchecked - because, if
 you don't have resize checked, then when you change a coordinate of an
 object, it just moves the object.

 What's even weirder about that is that normally, now, when I create a
 line, if I resize it I get the even more bizarre behavior of having the
 line lengthen in BOTH directions with the center fixed, which is generally
 followed by my shaking my monitor and screaming at it.

 Now, go try to use the equalize/align/distribute tools.  Throw three or
 four objects on a card and use them.


 Is this also where I get to remind everyone about LC's bigotry toward
 items?  You know, because ,,a is three items, but a,, and ,a, only
 counts as two?


 On Thu, May 15, 2014 at 10:42 AM, Devin Asay devin_a...@byu.edu wrote:

 Thanks for the responses folks. Keep them coming, and I'll post a
 summary.

 Here's another one of mine:

 Names of blendLevel inks: Whaaa? What do those things even mean?

 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.




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




-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, This is good.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: IDE oddities (was Re: Error Messages Are Evil)

Whoops!  Wait, a second, here's another:
The locked of the properties palette for each object is separate and
persistent.  This is really great when you are working with a component or
object that is installed by another developer, and want to look at two of
the developer's objects side-by-side and make one like the other, but
really awful when you don't, because you're stuck with it.  You're not in
charge of your setup, the component developer is, and if you have to fix
something in that component, you are in for a lot of extra clicks and
palette issues.


On Thu, May 15, 2014 at 11:10 AM, Mike Kerner mikeker...@roadrunner.comwrote:

 Try resizing something, or using the alignment tools.

 I just ran into this, again, this week, when I was trying to fix a
 vertical line.  The line is too short, so I changed the length.  The line
 lengthened, UPWARD.  So I then changed the top of the line, thinking that
 would help me except the bottom stayed and thus the line was shorter,
 again, but I missed that the resize checkbox was unchecked - because, if
 you don't have resize checked, then when you change a coordinate of an
 object, it just moves the object.

 What's even weirder about that is that normally, now, when I create a
 line, if I resize it I get the even more bizarre behavior of having the
 line lengthen in BOTH directions with the center fixed, which is generally
 followed by my shaking my monitor and screaming at it.

 Now, go try to use the equalize/align/distribute tools.  Throw three or
 four objects on a card and use them.


 Is this also where I get to remind everyone about LC's bigotry toward
 items?  You know, because ,,a is three items, but a,, and ,a, only
 counts as two?


 On Thu, May 15, 2014 at 10:42 AM, Devin Asay devin_a...@byu.edu wrote:

 Thanks for the responses folks. Keep them coming, and I'll post a summary.

 Here's another one of mine:

 Names of blendLevel inks: Whaaa? What do those things even mean?

 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.




-- 
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: IDE oddities (was Re: Error Messages Are Evil)


On May 15, 2014, at 9:12 AM, Richard Gaskin ambassa...@fourthworld.com
 wrote:

 Devin Asay wrote:
 Thanks for the responses folks. Keep them coming, and I'll post a summary.
 
 It may be helpful if you'd post your summary to the IDE Contributors Forum:
 http://forums.runrev.com/viewforum.php?f=67
 
 
 Here's another one of mine:
 
 Names of blendLevel inks: Whaaa? What do those things even mean?
 
 Most of those names come from the bit-wise operations they use, or some 
 similar historic origin.
 
 While it might be nice to try to craft English-like names for them, that's a 
 daunting task - XOR is XOR in every language, and geeky as it is I can't 
 think of any other way to describe it that isn't nearly a sentence long. :)

Yes, I agree that sometimes concepts are too complex to describe in a short, 
neat label. But in the interface, perhaps the menu could show the effect of the 
ink visually, or maybe there could be a help button that would pop up a list 
explaining the inks in simple language.

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: IDE oddities (was Re: Error Messages Are Evil)


Devin Asay wrote:

Thanks for the responses folks. Keep them coming, and I'll post a summary.


It may be helpful if you'd post your summary to the IDE Contributors Forum:
http://forums.runrev.com/viewforum.php?f=67



Here's another one of mine:

Names of blendLevel inks: Whaaa? What do those things even mean?


Most of those names come from the bit-wise operations they use, or some 
similar historic origin.


While it might be nice to try to craft English-like names for them, 
that's a daunting task - XOR is XOR in every language, and geeky as 
it is I can't think of any other way to describe it that isn't nearly a 
sentence long. :)


--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 Follow me on Twitter:  http://twitter.com/FourthWorldSys

___
use-livecode mailing list
use-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: IDE oddities (was Re: Error Messages Are Evil)


On May 15, 2014, at 9:16 AM, Mike Kerner mikeker...@roadrunner.com
 wrote:

 Whoops!  Wait, a second, here's another:
 The locked of the properties palette for each object is separate and
 persistent.  This is really great when you are working with a component or
 object that is installed by another developer, and want to look at two of
 the developer's objects side-by-side and make one like the other, but
 really awful when you don't, because you're stuck with it.  You're not in
 charge of your setup, the component developer is, and if you have to fix
 something in that component, you are in for a lot of extra clicks and
 palette issues.

I'm not sure I'm following you on this one, Mike. Are you talking about the 
lock icon that locks the property palette to the currently selected object? 
What do you mean by persistent? Can't you just click the lock icon to de-link 
it from the object? Or are you referring to another locked property?

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: IDE oddities (was Re: Error Messages Are Evil)

Mike, this is the part that I don't get about open source... yet. I guess we 
don't have the community structures to handle it.

I mean, I've made that (free) plugin to handle this specific problem. lcMover 
moves stacks/windows around, whether they are off-screen or not. I even added 
an option recently to specifically move off-screen stacks back on-screen. (Not 
posted quite yet... on the way.)
Isn't the whole open source idea that I could contribute some code for that to 
the IDE? Preferably without having to write it in C++?

Since GitHub doesn't work for this, will we eventually have designated 
community members to shepherd the integration of code or features like this? 
That is, a community mechanism for addressing IDE oddities?

- Charles

On 15 May 2014, at 10:23 AM, Mike Kerner mikeker...@roadrunner.com wrote:

 And another:
 If you have your lappie hooked to two monitors at work, and you use both
 monitors, and then you go home, guess what happens to windows, especially
 on a Mac, where you are using multiple workspaces?  That's right, the
 windows, even the LC development windows, are off-screen somewhere at
 3750,150, and your only hope of getting them back is to figure out what the
 name of the development window is (say, the message box, or a properties
 palette, or maybe the script editor and then going to the message box and
 moving it manually.
 
 The good news with most of the things that we complain about is that
 because you can modify LC from within LC, you can fix these things
 yourself.  The bad news is that when you run into these sorts of things,
 there isn't an uproar from the community that puts pressure on Edinburgh to
 drop refactoring the engine to fix something.
 
 HOWEVER, I think I'd take it this way, because this way, there is an
 economic motive for some author to release a tool that does something
 better than LC does, or is ready before LC might make it a priority.  Yes,
 it costs money to purchase those tools, but it makes the ecosystem better,
 even though the IDE isn't better.

--
Charles E. Buchwald
CEO/Director General
Museografica Digital
http://digital.museografica.com

LC Developer Tools: http://buchwald.ca/developer-tools/

Email Notice: http://wp.me/P3aT4d-33
___
use-livecode mailing list
use-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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-15 Thread J. Landman Gay

There's a small view of two overlapping images at the bottom of the inspector 
that shows what the ink will do.  

The names of the inks are the same as the ones that Photoshop and many other 
image processing programs use, so that's a tough call.  Specialists might 
complain if they are changed.  

On May 15, 2014 10:24:57 AM CDT, Devin Asay devin_a...@byu.edu wrote:

On May 15, 2014, at 9:12 AM, Richard Gaskin
ambassa...@fourthworld.com
 wrote:

 Devin Asay wrote:
 Thanks for the responses folks. Keep them coming, and I'll post a
summary.
 
 It may be helpful if you'd post your summary to the IDE Contributors
Forum:
 http://forums.runrev.com/viewforum.php?f=67
 
 
 Here's another one of mine:
 
 Names of blendLevel inks: Whaaa? What do those things even mean?
 
 Most of those names come from the bit-wise operations they use, or
some similar historic origin.
 
 While it might be nice to try to craft English-like names for them,
that's a daunting task - XOR is XOR in every language, and geeky as
it is I can't think of any other way to describe it that isn't nearly a
sentence long. :)

Yes, I agree that sometimes concepts are too complex to describe in a
short, neat label. But in the interface, perhaps the menu could show
the effect of the ink visually, or maybe there could be a help button
that would pop up a list explaining the inks in simple language.

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

-- 
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: IDE oddities (was Re: Error Messages Are Evil)


On May 15, 2014, at 9:57 AM, Charles E Buchwald char...@buchwald.ca wrote:

 Mike, this is the part that I don't get about open source... yet. I guess we 
 don't have the community structures to handle it.
 
 I mean, I've made that (free) plugin to handle this specific problem. 
 lcMover moves stacks/windows around, whether they are off-screen or not. I 
 even added an option recently to specifically move off-screen stacks back 
 on-screen. (Not posted quite yet... on the way.)
 Isn't the whole open source idea that I could contribute some code for that 
 to the IDE? Preferably without having to write it in C++?
 
 Since GitHub doesn't work for this, will we eventually have designated 
 community members to shepherd the integration of code or features like this? 
 That is, a community mechanism for addressing IDE oddities?

In light of my effort to compile this list, I'm interested in the answer to 
this question as well. My understanding is that the IDE is not yet part of the 
GitHub… thingy, but will be soon. Richard?

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: IDE oddities (was Re: Error Messages Are Evil)


On May 15, 2014, at 10:00 AM, J. Landman Gay jac...@hyperactivesw.com
 wrote:

 There's a small view of two overlapping images at the bottom of the inspector 
 that shows what the ink will do.  

Well, I'll be d**ned. How many times have I looked at that, and it never 
registered until now. What a funny thing the human brain is. Well maybe just my 
brain.

 The names of the inks are the same as the ones that Photoshop and many other 
 image processing programs use, so that's a tough call.  Specialists might 
 complain if they are changed.  

Right. I don't get then in PS either. :) Maybe this is an area that's just 
gonna require a body to go through a tutorial.


Devin


Devin Asay
Learn to code with LiveCode University
http://university.livecode.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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-15 Thread Richmond


On 15/05/14 17:42, Devin Asay wrote:

Thanks for the responses folks. Keep them coming, and I'll post a summary.

Here's another one of mine:

Names of blendLevel inks: Whaaa? What do those things even mean?


Yes: a set of names that had some sort of connexion with the effects 
produced

would makes things somewhat more intuitive.

Richmond.



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



___
use-livecode mailing list
use-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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-15 Thread Dar Scott

This one might be just me.

It is awkward to move off the keyboard while editing a script to hover over a 
control in the Object Inspector waiting for it to take so I can see the name of 
the property.

On May 15, 2014, at 8:42 AM, Devin Asay devin_a...@byu.edu wrote:

 Thanks for the responses folks. Keep them coming, and I'll post a summary.
 
 Here's another one of mine:
 
 Names of blendLevel inks: Whaaa? What do those things even mean?
 
 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


___
use-livecode mailing list
use-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: IDE oddities (was Re: Error Messages Are Evil)

It's persistent between launches of LC.

The case in question is dealing with the dataGrid, because there are issues
with the DG, which I detailed in a bug report that I filed this week, in
particular related to resizing a header.  Because a DG is an amalgam of
numerous LC objects, issues can quickly become amplified.


On Thu, May 15, 2014 at 11:35 AM, Devin Asay devin_a...@byu.edu wrote:


 On May 15, 2014, at 9:16 AM, Mike Kerner mikeker...@roadrunner.com
  wrote:

  Whoops!  Wait, a second, here's another:
  The locked of the properties palette for each object is separate and
  persistent.  This is really great when you are working with a component
 or
  object that is installed by another developer, and want to look at two of
  the developer's objects side-by-side and make one like the other, but
  really awful when you don't, because you're stuck with it.  You're not in
  charge of your setup, the component developer is, and if you have to fix
  something in that component, you are in for a lot of extra clicks and
  palette issues.

 I'm not sure I'm following you on this one, Mike. Are you talking about
 the lock icon that locks the property palette to the currently selected
 object? What do you mean by persistent? Can't you just click the lock icon
 to de-link it from the object? Or are you referring to another locked
 property?

 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: IDE oddities (was Re: Error Messages Are Evil)

Charles,
I was not aware of your add-on.  Your add-on, like numerous other add-ons,
have not made it to the collective consciousness, yet.  That's exactly why
we're talking about taking the revOnline project broader and trying to get
it organized and improved, so that it becomes a catalog of everything you
might want for LC, all in one place.


On Thu, May 15, 2014 at 11:57 AM, Charles E Buchwald char...@buchwald.cawrote:

 Mike, this is the part that I don't get about open source... yet. I guess
 we don't have the community structures to handle it.

 I mean, I've made that (free) plugin to handle this specific problem.
 lcMover moves stacks/windows around, whether they are off-screen or not.
 I even added an option recently to specifically move off-screen stacks back
 on-screen. (Not posted quite yet... on the way.)
 Isn't the whole open source idea that I could contribute some code for
 that to the IDE? Preferably without having to write it in C++?

 Since GitHub doesn't work for this, will we eventually have designated
 community members to shepherd the integration of code or features like
 this? That is, a community mechanism for addressing IDE oddities?

 - Charles

 On 15 May 2014, at 10:23 AM, Mike Kerner mikeker...@roadrunner.com
 wrote:

  And another:
  If you have your lappie hooked to two monitors at work, and you use both
  monitors, and then you go home, guess what happens to windows, especially
  on a Mac, where you are using multiple workspaces?  That's right, the
  windows, even the LC development windows, are off-screen somewhere at
  3750,150, and your only hope of getting them back is to figure out what
 the
  name of the development window is (say, the message box, or a properties
  palette, or maybe the script editor and then going to the message box
 and
  moving it manually.
 
  The good news with most of the things that we complain about is that
  because you can modify LC from within LC, you can fix these things
  yourself.  The bad news is that when you run into these sorts of things,
  there isn't an uproar from the community that puts pressure on Edinburgh
 to
  drop refactoring the engine to fix something.
 
  HOWEVER, I think I'd take it this way, because this way, there is an
  economic motive for some author to release a tool that does something
  better than LC does, or is ready before LC might make it a priority.
  Yes,
  it costs money to purchase those tools, but it makes the ecosystem
 better,
  even though the IDE isn't better.

 --
 Charles E. Buchwald
 CEO/Director General
 Museografica Digital
 http://digital.museografica.com

 LC Developer Tools: http://buchwald.ca/developer-tools/

 Email Notice: http://wp.me/P3aT4d-33
 ___
 use-livecode mailing list
 use-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: IDE oddities (was Re: Error Messages Are Evil)

Most of the LC-coded portions of LC are not part of GitHub.  This also
includes dataGrids, which have several issues I discovered earlier in the
week.


On Thu, May 15, 2014 at 12:07 PM, Devin Asay devin_a...@byu.edu wrote:


 On May 15, 2014, at 9:57 AM, Charles E Buchwald char...@buchwald.ca
 wrote:

  Mike, this is the part that I don't get about open source... yet. I
 guess we don't have the community structures to handle it.
 
  I mean, I've made that (free) plugin to handle this specific problem.
 lcMover moves stacks/windows around, whether they are off-screen or not.
 I even added an option recently to specifically move off-screen stacks back
 on-screen. (Not posted quite yet... on the way.)
  Isn't the whole open source idea that I could contribute some code for
 that to the IDE? Preferably without having to write it in C++?
 
  Since GitHub doesn't work for this, will we eventually have designated
 community members to shepherd the integration of code or features like
 this? That is, a community mechanism for addressing IDE oddities?

 In light of my effort to compile this list, I'm interested in the answer
 to this question as well. My understanding is that the IDE is not yet part
 of the GitHub… thingy, but will be soon. Richard?

 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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-15 Thread Dar Scott

I’d call this one more than an oddity.  This is a bug.  It goes along with the 
one about how no window can be higher than the icon bar even if it is on a 
display placed high and the bar is not even on that display.  

Dar

On May 15, 2014, at 9:23 AM, Mike Kerner mikeker...@roadrunner.com wrote:

 And another:
 If you have your lappie hooked to two monitors at work, and you use both
 monitors, and then you go home, guess what happens to windows, especially
 on a Mac, where you are using multiple workspaces?  That's right, the
 windows, even the LC development windows, are off-screen somewhere at
 3750,150, and your only hope of getting them back is to figure out what the
 name of the development window is (say, the message box, or a properties
 palette, or maybe the script editor and then going to the message box and
 moving it manually.
 
 The good news with most of the things that we complain about is that
 because you can modify LC from within LC, you can fix these things
 yourself.  The bad news is that when you run into these sorts of things,
 there isn't an uproar from the community that puts pressure on Edinburgh to
 drop refactoring the engine to fix something.
 
 HOWEVER, I think I'd take it this way, because this way, there is an
 economic motive for some author to release a tool that does something
 better than LC does, or is ready before LC might make it a priority.  Yes,
 it costs money to purchase those tools, but it makes the ecosystem better,
 even though the IDE isn't better.
 
 
 On Thu, May 15, 2014 at 11:16 AM, Mike Kerner 
 mikeker...@roadrunner.comwrote:
 
 Whoops!  Wait, a second, here's another:
 The locked of the properties palette for each object is separate and
 persistent.  This is really great when you are working with a component or
 object that is installed by another developer, and want to look at two of
 the developer's objects side-by-side and make one like the other, but
 really awful when you don't, because you're stuck with it.  You're not in
 charge of your setup, the component developer is, and if you have to fix
 something in that component, you are in for a lot of extra clicks and
 palette issues.
 
 
 On Thu, May 15, 2014 at 11:10 AM, Mike Kerner 
 mikeker...@roadrunner.comwrote:
 
 Try resizing something, or using the alignment tools.
 
 I just ran into this, again, this week, when I was trying to fix a
 vertical line.  The line is too short, so I changed the length.  The line
 lengthened, UPWARD.  So I then changed the top of the line, thinking that
 would help me except the bottom stayed and thus the line was shorter,
 again, but I missed that the resize checkbox was unchecked - because, if
 you don't have resize checked, then when you change a coordinate of an
 object, it just moves the object.
 
 What's even weirder about that is that normally, now, when I create a
 line, if I resize it I get the even more bizarre behavior of having the
 line lengthen in BOTH directions with the center fixed, which is generally
 followed by my shaking my monitor and screaming at it.
 
 Now, go try to use the equalize/align/distribute tools.  Throw three or
 four objects on a card and use them.
 
 
 Is this also where I get to remind everyone about LC's bigotry toward
 items?  You know, because ,,a is three items, but a,, and ,a, only
 counts as two?
 
 
 On Thu, May 15, 2014 at 10:42 AM, Devin Asay devin_a...@byu.edu wrote:
 
 Thanks for the responses folks. Keep them coming, and I'll post a
 summary.
 
 Here's another one of mine:
 
 Names of blendLevel inks: Whaaa? What do those things even mean?
 
 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.
 
 
 
 
 --
 On the first day, God created the heavens and the Earth
 On the second day, God created the oceans.
 On the third day, God put the animals on hold for a few hours,
   and did a little diving.
 And God said, This is good.
 
 
 
 
 -- 
 On the first day, God created the heavens and the Earth
 On the second day, God created the oceans.
 On the third day, God put the animals on hold for a few hours,
   and did a little diving.
 And God said, This is good.
 ___
 use-livecode mailing list
 use-livecode@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
 preferences:
 http://lists.runrev.com/mailman/listinfo/use-livecode


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

Re: IDE oddities (was Re: Error Messages Are Evil)

+1


On Thu, May 15, 2014 at 1:59 PM, Dar Scott d...@swcp.com wrote:

 This one might be just me.

 It is awkward to move off the keyboard while editing a script to hover
 over a control in the Object Inspector waiting for it to take so I can see
 the name of the property.

 On May 15, 2014, at 8:42 AM, Devin Asay devin_a...@byu.edu wrote:

  Thanks for the responses folks. Keep them coming, and I'll post a
 summary.
 
  Here's another one of mine:
 
  Names of blendLevel inks: Whaaa? What do those things even mean?
 
  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


 ___
 use-livecode mailing list
 use-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: IDE oddities (was Re: Error Messages Are Evil)

OK, so what do we have to do, as a community of users, to get RevOnline working 
again? This seems like a good way to encourage and coordinate community 
participation. Particularly so because we are talking about LC code, outside of 
the GitHub ecosystem, and outside of the IDE. And because it's been broken, or 
at least hobbled, for quite a while.

How about we take a modest plan to the mothership. Perhaps the mothership could 
appropriately anoint an individual or small team to shepherd a new version of 
RevOnline? Someone to oversee code integration? This could even serve as a 
model for further non-GitHub-based community participation

Richard Gaskin: what's your perspective on this as community liaison?

Other list members: any volunteers?

- Charles

On 15 May 2014, at 1:01 PM, Mike Kerner mikeker...@roadrunner.com wrote:

 Charles,
 I was not aware of your add-on.  Your add-on, like numerous other add-ons,
 have not made it to the collective consciousness, yet.  That's exactly why
 we're talking about taking the revOnline project broader and trying to get
 it organized and improved, so that it becomes a catalog of everything you
 might want for LC, all in one place.
 
 
 On Thu, May 15, 2014 at 11:57 AM, Charles E Buchwald 
 char...@buchwald.cawrote:
 
 Mike, this is the part that I don't get about open source... yet. I guess
 we don't have the community structures to handle it.
 
 I mean, I've made that (free) plugin to handle this specific problem.
 lcMover moves stacks/windows around, whether they are off-screen or not.
 I even added an option recently to specifically move off-screen stacks back
 on-screen. (Not posted quite yet... on the way.)
 Isn't the whole open source idea that I could contribute some code for
 that to the IDE? Preferably without having to write it in C++?
 
 Since GitHub doesn't work for this, will we eventually have designated
 community members to shepherd the integration of code or features like
 this? That is, a community mechanism for addressing IDE oddities?
 
 - Charles

--
Charles E. Buchwald
CEO/Director General
Museografica Digital
http://digital.museografica.com

LC Developer Tools: http://buchwald.ca/developer-tools/

Email Notice: http://wp.me/P3aT4d-33


___
use-livecode mailing list
use-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: IDE oddities (was Re: Error Messages Are Evil)

Look at the [Off] Cool Plugins thread.
-- 
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: IDE oddities (was Re: Error Messages Are Evil)

Richard is heading up this effort.  It is being discussed in another
thread.  Volunteers have been...volunteering.


On Thu, May 15, 2014 at 2:40 PM, Charles E Buchwald char...@buchwald.cawrote:

 OK, so what do we have to do, as a community of users, to get RevOnline
 working again? This seems like a good way to encourage and coordinate
 community participation. Particularly so because we are talking about LC
 code, outside of the GitHub ecosystem, and outside of the IDE. And because
 it's been broken, or at least hobbled, for quite a while.

 How about we take a modest plan to the mothership. Perhaps the mothership
 could appropriately anoint an individual or small team to shepherd a new
 version of RevOnline? Someone to oversee code integration? This could even
 serve as a model for further non-GitHub-based community participation

 Richard Gaskin: what's your perspective on this as community liaison?

 Other list members: any volunteers?

 - Charles

 On 15 May 2014, at 1:01 PM, Mike Kerner mikeker...@roadrunner.com wrote:

  Charles,
  I was not aware of your add-on.  Your add-on, like numerous other
 add-ons,
  have not made it to the collective consciousness, yet.  That's exactly
 why
  we're talking about taking the revOnline project broader and trying to
 get
  it organized and improved, so that it becomes a catalog of everything you
  might want for LC, all in one place.
 
 
  On Thu, May 15, 2014 at 11:57 AM, Charles E Buchwald 
 char...@buchwald.cawrote:
 
  Mike, this is the part that I don't get about open source... yet. I
 guess
  we don't have the community structures to handle it.
 
  I mean, I've made that (free) plugin to handle this specific problem.
  lcMover moves stacks/windows around, whether they are off-screen or
 not.
  I even added an option recently to specifically move off-screen stacks
 back
  on-screen. (Not posted quite yet... on the way.)
  Isn't the whole open source idea that I could contribute some code for
  that to the IDE? Preferably without having to write it in C++?
 
  Since GitHub doesn't work for this, will we eventually have designated
  community members to shepherd the integration of code or features like
  this? That is, a community mechanism for addressing IDE oddities?
 
  - Charles

 --
 Charles E. Buchwald
 CEO/Director General
 Museografica Digital
 http://digital.museografica.com

 LC Developer Tools: http://buchwald.ca/developer-tools/

 Email Notice: http://wp.me/P3aT4d-33


 ___
 use-livecode mailing list
 use-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: IDE oddities (was Re: Error Messages Are Evil)


Charles wrote:
 OK, so what do we have to do, as a community of users, to get
 RevOnline working again?

Fix it.  :)

My Community meeting this morning with Ben focused almost exclusively on 
RevOnline.


It's true that LiveCode is inherently problematic to attempt to 
integrate into tools like GitHub, not merely because it's a binary file 
format and GitHub is designed for plain text, but more because of the 
nature of the workflow in which UI and code are intermingled.  Monte's 
spent considerable time explaining the Why of that, and if needed I 
could try again, but for now the bottom line on GitHub integration is 
that it may require engine enhancements to support, and given current 
priorities not likely to happen for at least a few more months at best.


So in the absence of a GitHub workflow, clearly we need at least some 
alternative to move forward with community contributions on IDE components.


We explored a few options, but one stood out as a *possible* solution 
for modest fixes in the short term.  I'm stressing possible here 
because he needs to review the workflow with the team to make sure it's 
going to work, but here's the outline:



If a member of the community has time and interest to fix a bug in the 
IDE, the revised handler(s) can be added to the bug report, and the 
title of the report prepended with FIX: to flag it for the team as a 
report that also includes the fix.  And of course the post with the 
fixed handler(s) should note the object and line numbers where the 
original handler(s) can be found.


For any issue whose recipe requires more than running a single line of 
code in the Message Box, a unit test stack should be provided 
illustrating the issue so that it can be run before the fix is applied, 
then again after copying-and-pasting the fix to verify that it works.


Well-crafted unit tests may even be included in RunRev's internal 
collection for future regression tests, providing long-term benefit in 
addition to helping to ensure quick action on a bug.



As an example of this workflow in action, we have a simple fix here:
http://quality.runrev.com/show_bug.cgi?id=11493

Since the code change is comprised of adding only five characters to a 
comparison string and can be easily seen in the Message Box, no unit 
test is required for that one.


There may be reasons why they're not able to guarantee super-quick 
responses on reports using this protocol, but even before he runs it by 
the team I see no harm and potentially much good in encouraging 
interested folks to dive into fixing any issues you find particularly 
annoying, and including the fixed code in the report.



True, this protocol can only address issues of limited scope, and at the 
moment is still being reviewed for feasibility.


But the benefit of having fixed code posted to the report is undeniably 
valuable in guiding the team to the solution - all we need now is people 
in a position to supply the fixes.


That last step has been the hardest.

For example, after all the discussion of documentation issues over the 
years, once I got forum permissions to modify things there for community 
initiatives I took the time to set up a new forum section for that:

http://forums.runrev.com/viewforum.php?f=83

Thus far there's been some good ideas discussed, but no one in a 
position to actually act on any of them.


Many of us juggle multiple priorities, much like RunRev themselves, so I 
can understand that it's far easier to imagine fixed code than it is to 
write it. :)


It may be that we won't really see serious traction on community 
participation for quite some months yet, until the community grows large 
enough to include a greater number of people in a position to contribute.


We'll see.  But in the meantime the core dev team at RunRev is actively 
exploring many ways to incorporate community contributions for IDE 
components, and if we start seeing fixes submitted to the bug reports 
we'll be able to refine and enhance the workflow to make sure it's 
working well for all of us.


--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.org


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

Re: IDE oddities (was Re: Error Messages Are Evil)

This is similar to a discussion I had earlier this week about fixing the
issues I found in DataGrid.

However, what do we do about OnRev, especially if we are going to work on
it as a group of sorts?


On Thu, May 15, 2014 at 4:29 PM, Richard Gaskin
ambassa...@fourthworld.comwrote:

 Charles wrote:
  OK, so what do we have to do, as a community of users, to get
  RevOnline working again?

 Fix it.  :)

 My Community meeting this morning with Ben focused almost exclusively on
 RevOnline.

 It's true that LiveCode is inherently problematic to attempt to integrate
 into tools like GitHub, not merely because it's a binary file format and
 GitHub is designed for plain text, but more because of the nature of the
 workflow in which UI and code are intermingled.  Monte's spent considerable
 time explaining the Why of that, and if needed I could try again, but for
 now the bottom line on GitHub integration is that it may require engine
 enhancements to support, and given current priorities not likely to happen
 for at least a few more months at best.

 So in the absence of a GitHub workflow, clearly we need at least some
 alternative to move forward with community contributions on IDE components.

 We explored a few options, but one stood out as a *possible* solution for
 modest fixes in the short term.  I'm stressing possible here because he
 needs to review the workflow with the team to make sure it's going to work,
 but here's the outline:


 If a member of the community has time and interest to fix a bug in the
 IDE, the revised handler(s) can be added to the bug report, and the title
 of the report prepended with FIX: to flag it for the team as a report
 that also includes the fix.  And of course the post with the fixed
 handler(s) should note the object and line numbers where the original
 handler(s) can be found.

 For any issue whose recipe requires more than running a single line of
 code in the Message Box, a unit test stack should be provided illustrating
 the issue so that it can be run before the fix is applied, then again after
 copying-and-pasting the fix to verify that it works.

 Well-crafted unit tests may even be included in RunRev's internal
 collection for future regression tests, providing long-term benefit in
 addition to helping to ensure quick action on a bug.


 As an example of this workflow in action, we have a simple fix here:
 http://quality.runrev.com/show_bug.cgi?id=11493

 Since the code change is comprised of adding only five characters to a
 comparison string and can be easily seen in the Message Box, no unit test
 is required for that one.

 There may be reasons why they're not able to guarantee super-quick
 responses on reports using this protocol, but even before he runs it by the
 team I see no harm and potentially much good in encouraging interested
 folks to dive into fixing any issues you find particularly annoying, and
 including the fixed code in the report.


 True, this protocol can only address issues of limited scope, and at the
 moment is still being reviewed for feasibility.

 But the benefit of having fixed code posted to the report is undeniably
 valuable in guiding the team to the solution - all we need now is people in
 a position to supply the fixes.

 That last step has been the hardest.

 For example, after all the discussion of documentation issues over the
 years, once I got forum permissions to modify things there for community
 initiatives I took the time to set up a new forum section for that:
 http://forums.runrev.com/viewforum.php?f=83

 Thus far there's been some good ideas discussed, but no one in a position
 to actually act on any of them.

 Many of us juggle multiple priorities, much like RunRev themselves, so I
 can understand that it's far easier to imagine fixed code than it is to
 write it. :)

 It may be that we won't really see serious traction on community
 participation for quite some months yet, until the community grows large
 enough to include a greater number of people in a position to contribute.

 We'll see.  But in the meantime the core dev team at RunRev is actively
 exploring many ways to incorporate community contributions for IDE
 components, and if we start seeing fixes submitted to the bug reports we'll
 be able to refine and enhance the workflow to make sure it's working well
 for all of us.

 --
  Richard Gaskin
  LiveCode Community Manager
  rich...@livecode.org



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




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

Community Contributions (was IDE oddities (was Re: Error Messages Are Evil))

Mike, I did follow the whole [Off] Cool Plugins thread. I was a bit 
disappointed that it kind of petered out after several people expressed an 
interest in helping. I did propose that the forum for plugins and extensions be 
split in two. My thought being that developing either is very different from 
the other, and that perhaps a forum focusing on LC-code-only plugins would be 
more inviting to newcomers.

I do see that people have been volunteering. I thought if we had a group we 
could designate a code integrator, someone to work on categories, another for 
UI issues, and so on.

Richard, I'm glad there is talk about mechanisms for contributing fixes. I will 
look at a couple of my pet IDE Oddities with that in mind and try submitting 
a FIX. Perhaps I can even dig into the RevOnline stack and suggest a FIX or two.

I did participate in the Documentation Brainstorming forum, but I haven't seen 
much discussion there.

The message I'm getting overall, is that it's too early for anything but simple 
FIX contributions. I'll try to be patient for the coming ideas and solutions 
for making contributions. (Isn't that, as much as anything, a topic for 
community discussion?)

In the mean time, I'm going to continue making plugins. I'll add explicit open 
source licenses to at least some of them. Perhaps some of the ideas and code 
can be folded in to community efforts later.

Maybe I can even find another list member or two who would be interested in 
collaborating on a plugin

Cheers,
- Charles

P.S. I haven't posted any of my plugins on RevOnline, because it crashes LC 
each time I attempt a login or search.


On 15 May 2014, at 2:23 PM, Mike Kerner mikeker...@roadrunner.com wrote:

 Look at the [Off] Cool Plugins thread.

--
Charles E. Buchwald
CEO/Director General
Museografica Digital
http://digital.museografica.com

LC Developer Tools: http://buchwald.ca/developer-tools/

Email Notice: http://wp.me/P3aT4d-33


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

Community Contributions (was IDE oddities (was Re: Error Messages Are Evil))

Mike, I did follow the whole [Off] Cool Plugins thread. I was a bit 
disappointed that it kind of petered out after several people expressed an 
interest in helping. I did propose that the forum for plugins and extensions be 
split in two. My thought being that developing either is very different from 
the other, and that perhaps a forum focusing on LC-code-only plugins would be 
more inviting to newcomers.

I do see that people have been volunteering. I thought if we had a group we 
could designate a code integrator, someone to work on categories, another for 
UI issues, and so on.

Richard, I'm glad there is talk about mechanisms for contributing fixes. I will 
look at a couple of my pet IDE Oddities with that in mind and try submitting 
a FIX. Perhaps I can even dig into the RevOnline stack and suggest a FIX or two.

I did participate in the Documentation Brainstorming forum, but I haven't seen 
much discussion there.

The message I'm getting overall, is that it's too early for anything but simple 
FIX contributions. I'll try to be patient for the coming ideas and solutions 
for making contributions. (Isn't that, as much as anything, a topic for 
community discussion?)

In the mean time, I'm going to continue making plugins. I'll add explicit open 
source licenses to at least some of them. Perhaps some of the ideas and code 
can be folded in to community efforts later.

Maybe I can even find another list member or two who would be interested in 
collaborating on a plugin

Cheers,
- Charles

P.S. I haven't posted any of my plugins on RevOnline, because it crashes LC 
each time I attempt a login or search.


On 15 May 2014, at 2:23 PM, Mike Kerner mikeker...@roadrunner.com wrote:

 Look at the [Off] Cool Plugins thread.

--
Charles E. Buchwald
CEO/Director General
Museografica Digital
http://digital.museografica.com

LC Developer Tools: http://buchwald.ca/developer-tools/

Email Notice: http://wp.me/P3aT4d-33


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

[TIC: Tongue in Cheek] Re: IDE oddities (was Re: Error Messages Are Evil)

2014-05-15 Thread Alex Tweedly


On 15/05/2014 21:29, Richard Gaskin wrote:


As an example of this workflow in action, we have a simple fix here:
http://quality.runrev.com/show_bug.cgi?id=11493

Since the code change is comprised of adding only five characters to a 
comparison string and can be easily seen in the Message Box, no unit 
test is required for that one.


I confess I have not read the guidelines on making code contributions, 
so I don't know which step includes code review by general onlookers - 
so here's a quick code review of this change.


The proposed change is summarized as:

Currently:
if the platform is MacOS then

Should be:
if the platform is in MacOSLinux then

I'd regard that change as unsafe for the following reason.

Currently Apple have reached version 10 (i.e. X) of MacOS, and version 
7 of IOS. I suspect these may merge in the future, and be named either 
simply OS or something like that. Now, given enough years, the version 
number will reach 50, i.e. in Roman numerals, L - and so be called 
OSL. This could result in a false positive in the above test, since 
OSL is a substring spread across what are really two distinct parts of 
MacOSLinux.


I'd therefore propose that this test should be something more like
   if the platform is among the items of MacOS,Linux then

However - I've not actually tested that, nor checked whether the itemDel 
can be safely assumed at that point in the script - so you should 
probably ignore this suggestion :-)


-- Alex.

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

Re: IDE oddities (was Re: Error Messages Are Evil)


Mike Kerner wrote:


This is similar to a discussion I had earlier this week about fixing the
issues I found in DataGrid.


I think I missed something.  Did you submit fixes with those?  If you 
did, please add a FIX: prefix to the report titled so they can be flagged.



However, what do we do about OnRev, especially if we are going to work on
it as a group of sorts?


On-Rev the hosting service, or RevOnline the stack sharing tool?

If the former, the LiveCode Server engine is already open source in 
GitHub, and the real-time debugger is being reviewed for possible open 
source as I noted in the post you replied to.


In that post I also outlined some specific next steps for RevOnline, but 
one of the problems with writing long posts is details get lost. ;)


I'll cover that some more in my reply to Charles shortly, but in brief 
let's start with the things we know we want to do:


The biggest complaint with RevOnline right now is that some folks report 
it doesn't work for them.  Let's fix that.


In the course of addressing the these immediate short-term goals, we'll 
discover what works and doesn't work with the process and refine it as 
we go.


--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.org

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

Re: [TIC: Tongue in Cheek] Re: IDE oddities (was Re: Error Messages Are Evil)


Well, always good to anticipate future-proofing. :)

On another note, as I promised you last week I did ask Ben if RunRev 
planned on open-sourcing the On-Rev real-time debugger.  He's not sure 
and will check with Kevin, but he did confirm my hunch that it requires 
specific sockets open on the server so it won't be useful for anyone on 
a shared host, only a dedicated server where they can run custom 
daemons.  I'll let you know when I hear back from him on that.


Also, he let me know that the developer working on it reports that he's 
about a week or two away from completion.  Nothing set in stone, of 
course, because it's a busy place there with team members wearing 
multiple hats, but at the moment things look promising for a rollout of 
the new On-Rev debugger reasonably soon.


--
 Richard Gaskin
 LiveCode Community Manager
 rich...@livecode.org


Alex Tweedly wrote:


On 15/05/2014 21:29, Richard Gaskin wrote:


As an example of this workflow in action, we have a simple fix here:
http://quality.runrev.com/show_bug.cgi?id=11493

Since the code change is comprised of adding only five characters to a
comparison string and can be easily seen in the Message Box, no unit
test is required for that one.


I confess I have not read the guidelines on making code contributions,
so I don't know which step includes code review by general onlookers -
so here's a quick code review of this change.

The proposed change is summarized as:

Currently:
if the platform is MacOS then

Should be:
if the platform is in MacOSLinux then

I'd regard that change as unsafe for the following reason.

Currently Apple have reached version 10 (i.e. X) of MacOS, and version
7 of IOS. I suspect these may merge in the future, and be named either
simply OS or something like that. Now, given enough years, the version
number will reach 50, i.e. in Roman numerals, L - and so be called
OSL. This could result in a false positive in the above test, since
OSL is a substring spread across what are really two distinct parts of
MacOSLinux.

I'd therefore propose that this test should be something more like
if the platform is among the items of MacOS,Linux then

However - I've not actually tested that, nor checked whether the itemDel
can be safely assumed at that point in the script - so you should
probably ignore this suggestion :-)


___
use-livecode mailing list
use-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: [TIC: Tongue in Cheek] IDE oddities (was Re: Error Messages Are Evil)

2014-05-15 Thread Igor de Oliveira Couto

On 16 May 2014, at 8:34 am, Richard Gaskin ambassa...@fourthworld.com wrote:

 On another note, as I promised you last week I did ask Ben if RunRev planned 
 on open-sourcing the On-Rev real-time debugger.  He's not sure and will check 
 with Kevin, but he did confirm my hunch that it requires specific sockets 
 open on the server so it won't be useful for anyone on a shared host, only a 
 dedicated server where they can run custom daemons.  I'll let you know when I 
 hear back from him on that.

I suspect that this would be suitable for many small businesses that have 
virtual, co-located or in-house servers. I, for one, would be VERY interested 
in that: I have a business that sets up turn-key server solutions for small 
enterprise, and being able to remote-debug LiveCode scripts would mean I'd be 
more inclined to use LiveCode-based solutions for my clients.

 Also, he let me know that the developer working on it reports that he's about 
 a week or two away from completion.  Nothing set in stone, of course, because 
 it's a busy place there with team members wearing multiple hats, but at the 
 moment things look promising for a rollout of the new On-Rev debugger 
 reasonably soon.

Oooh, wonderful!!! :-)

--
Igor Couto
Sydney, Australia

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

Re: Community Contributions (was IDE oddities (was Re: Error Messages Are Evil))


Charles E Buchwald wrote:

 Mike, I did follow the whole [Off] Cool Plugins thread. I was a
 bit disappointed that it kind of petered out after several people
 expressed an interest in helping.

I wouldn't be too disappointed.  Things ebb and flow; we all have many 
things to do.  But two very good things have come out of that already: 
several members of the community have stepped forward offering to help, 
and that prompted me to make RevOnline the core focus of my meeting with 
Ben today.


As the old saying goes, A journey of a thousand miles begins with one 
step.  We'll get where we want to go, one steady step at a time.


This stack open source stuff is new for all of us.  There's nothing like 
LiveCode in the open source world, so we're breaking new ground, 
discovering new workflow models.  This requires as much innovation as it 
is important.  It may seem slow, but all big things do in the beginning.



 I did propose that the forum for plugins and extensions be split in
 two. My thought being that developing either is very different from
 the other, and that perhaps a forum focusing on LC-code-only plugins
 would be more inviting to newcomers.

I saw that and I agree.  I just haven't gotten to it yet, between client 
work and the upcoming LiveCode Global Jam next weekend (more on that 
tomorrow).



 I do see that people have been volunteering. I thought if we had a
 group we could designate a code integrator, someone to work on
 categories, another for UI issues, and so on.

 Richard, I'm glad there is talk about mechanisms for contributing
 fixes. I will look at a couple of my pet IDE Oddities with that in
 mind and try submitting a FIX. Perhaps I can even dig into the
 RevOnline stack and suggest a FIX or two.

That would be very cool - thanks.

Also, to keep that earlier conversation rolling, I've started a new 
thread in the IDE Contributors forum around one of the themes that 
emerged, RevOnline curation:

http://forums.runrev.com/viewtopic.php?f=67t=20417

By flagging the topic as a Brainstorm I'm hoping to encourage broad, 
perhaps adventurous thinking.  All input is welcome.  RevOnline is, 
after all, a community resource, so it should reflect our values and 
desires.




 I did participate in the Documentation Brainstorming forum, but I
 haven't seen much discussion there.

It'll happen.  At least we have a place for it, and a process outlined 
there to move initiatives from brainstorming to actual work projects.



 The message I'm getting overall, is that it's too early for anything
 but simple FIX contributions. I'll try to be patient for the coming
 ideas and solutions for making contributions. (Isn't that, as much as
 anything, a topic for community discussion?)

Indeed it is.  Maybe my earlier post wasn't clear or simply too long, 
but my intention wasn't to limit the conversation to bug fixes, but 
simply to triage activities in a way that recognizes that bugs 
preventing RevOnline from being used at all are immediate concerns, and 
fortunately items we can take action on without guidance from the core 
dev team.


In parallel with that, Ben and Mark Waddingham will be discussing other 
aspects of RevOnline from their end, and collectively the experiment 
with the FIX: protocol will help inform directions for all of us to 
establish workflows for more ambitious tasks ahead.



 In the mean time, I'm going to continue making plugins. I'll add
 explicit open source licenses to at least some of them. Perhaps some
 of the ideas and code can be folded in to community efforts later.

Plugins and libraries are really great contributions for the community, 
for several reasons:


1. They have immediate value.

2. They're often borne of scratching an itch, so they get done.

3. Because they can be written by a solo dev or small team, they're 
unemcumbered by integration issues with the IDE workflow.


4. They help build a future in which newcomers can know that they don't 
have to reinvent every wheel.


CPAN (the Comprehensive Perl Archive Network) is a great example of the 
power of community.  Anyone considering Perl can see the size of that 
collection and feel confident they can do anything.


As our community resource pool grows we'll have that as well, and as we 
fix the issues currently preventing some folks from using RevOnline 
we'll have something better than CPAN because we can run and install 
them from one tool right in the IDE.


In fact, we already have some great stuff in our community.  We just 
need to address the immediate issue of making RevOnline run reliably for 
folks so everyone can be using it.


And kudos for the explicit licensing.  As more newcomers join, and many 
of those being large orgs, having licensing made clear is really helpful.



 Maybe I can even find another list member or two who would be
 interested in collaborating on a plugin
...
 P.S. I haven't posted any of my plugins on RevOnline, because it
 crashes LC each time I attempt a login or

Re: IDE oddities (was Re: Error Messages Are Evil)

2014-05-15 Thread J. Landman Gay


On 5/15/14, 12:59 PM, Dar Scott wrote:

It is awkward to move off the keyboard while editing a script to
hover over a control in the Object Inspector waiting for it to take
so I can see the name of the property.


You can select go the the General pane in preferences, look for 
Property labels are: at the top, and select Name of LiveCode 
property. Then you won't have to wait for a tool tip.


Personally I think the native property names should be shown by default. 
New users will learn scripting much faster if the real names are always 
displayed, and if they wonder what a property does, the tooltip hover 
will display the plain English description as a cue.


Basically, whichever option is selected in prefs, the tooltip shows the 
other one.


--
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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-15 Thread J. Landman Gay


On 5/15/14, 10:35 AM, Devin Asay wrote:

The locked of the properties palette for each object is separate and
persistent.


From what I can see, cards and stacks selected from the app browser 
will open a locked inspector (anything in the left-hand pane.) Objects 
on a card (anything in the right-hand pane) will open an unlocked inspector.


Anything selected from within the stack itself (by clicking or using the 
contextual menu) opens an unlocked inspector.


The behavior might be different in the new project browser. I'm not 
using it much because it's too slow and unwieldy for the large stacks in 
my current job.


--
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: Community Contributions (was IDE oddities (was Re: Error Messages Are Evil))

Thanks for your considered and thorough answer, Richard.

As a footnote, I posted another little plugin I made. I've been working with 
HTML a lot, and the itch I've been scratching with it is having to switch 
between HTMLtext and styledText, and sometimes look up LC-legal HTML entities.

The lcHTML plugin is here: http://buchwald.ca/developer-tools/
(Towards the bottom of the page)

It's not very robust, so if anyone happened to have any suggestions or 
contributions, that would be very cool.

I'll post it on RevOnline as soon as I get that working...  :-)

Cheers,
- Charles

On 15 May 2014, at 6:05 PM, Richard Gaskin ambassa...@fourthworld.com wrote:

 Charles E Buchwald wrote:
 
  Mike, I did follow the whole [Off] Cool Plugins thread. I was a
  bit disappointed that it kind of petered out after several people
  expressed an interest in helping.
 
 I wouldn't be too disappointed.  Things ebb and flow; we all have many things 
 to do.  But two very good things have come out of that already: several 
 members of the community have stepped forward offering to help, and that 
 prompted me to make RevOnline the core focus of my meeting with Ben today.
 
 As the old saying goes, A journey of a thousand miles begins with one step. 
  We'll get where we want to go, one steady step at a time.
 
 This stack open source stuff is new for all of us.  There's nothing like 
 LiveCode in the open source world, so we're breaking new ground, discovering 
 new workflow models.  This requires as much innovation as it is important.  
 It may seem slow, but all big things do in the beginning.
 
 
  I did propose that the forum for plugins and extensions be split in
  two. My thought being that developing either is very different from
  the other, and that perhaps a forum focusing on LC-code-only plugins
  would be more inviting to newcomers.
 
 I saw that and I agree.  I just haven't gotten to it yet, between client work 
 and the upcoming LiveCode Global Jam next weekend (more on that tomorrow).
 
 
  I do see that people have been volunteering. I thought if we had a
  group we could designate a code integrator, someone to work on
  categories, another for UI issues, and so on.
 
  Richard, I'm glad there is talk about mechanisms for contributing
  fixes. I will look at a couple of my pet IDE Oddities with that in
  mind and try submitting a FIX. Perhaps I can even dig into the
  RevOnline stack and suggest a FIX or two.
 
 That would be very cool - thanks.
 
 Also, to keep that earlier conversation rolling, I've started a new thread in 
 the IDE Contributors forum around one of the themes that emerged, RevOnline 
 curation:
 http://forums.runrev.com/viewtopic.php?f=67t=20417
 
 By flagging the topic as a Brainstorm I'm hoping to encourage broad, 
 perhaps adventurous thinking.  All input is welcome.  RevOnline is, after 
 all, a community resource, so it should reflect our values and desires.
 
 
 
  I did participate in the Documentation Brainstorming forum, but I
  haven't seen much discussion there.
 
 It'll happen.  At least we have a place for it, and a process outlined there 
 to move initiatives from brainstorming to actual work projects.
 
 
  The message I'm getting overall, is that it's too early for anything
  but simple FIX contributions. I'll try to be patient for the coming
  ideas and solutions for making contributions. (Isn't that, as much as
  anything, a topic for community discussion?)
 
 Indeed it is.  Maybe my earlier post wasn't clear or simply too long, but my 
 intention wasn't to limit the conversation to bug fixes, but simply to triage 
 activities in a way that recognizes that bugs preventing RevOnline from being 
 used at all are immediate concerns, and fortunately items we can take action 
 on without guidance from the core dev team.
 
 In parallel with that, Ben and Mark Waddingham will be discussing other 
 aspects of RevOnline from their end, and collectively the experiment with the 
 FIX: protocol will help inform directions for all of us to establish 
 workflows for more ambitious tasks ahead.
 
 
  In the mean time, I'm going to continue making plugins. I'll add
  explicit open source licenses to at least some of them. Perhaps some
  of the ideas and code can be folded in to community efforts later.
 
 Plugins and libraries are really great contributions for the community, for 
 several reasons:
 
 1. They have immediate value.
 
 2. They're often borne of scratching an itch, so they get done.
 
 3. Because they can be written by a solo dev or small team, they're 
 unemcumbered by integration issues with the IDE workflow.
 
 4. They help build a future in which newcomers can know that they don't have 
 to reinvent every wheel.
 
 CPAN (the Comprehensive Perl Archive Network) is a great example of the power 
 of community.  Anyone considering Perl can see the size of that collection 
 and feel confident they can do anything.
 
 As our community resource pool grows we'll have that as

Re: IDE oddities (was Re: Error Messages Are Evil)

2014-05-15 Thread Dar Scott

Yeah, I was aware of that, but never tried it.  I’m afraid I’d get very 
confused.  I should be brave.

Also, I’m greedy and want both.  I’ll try what you suggest and see if that is 
too greedy.

Dar
Dar Scott Consulting
d...@swcp.com
Helping LiveCode programers with Externals and Libraries


On May 15, 2014, at 5:23 PM, J. Landman Gay jac...@hyperactivesw.com wrote:

 On 5/15/14, 12:59 PM, Dar Scott wrote:
 It is awkward to move off the keyboard while editing a script to
 hover over a control in the Object Inspector waiting for it to take
 so I can see the name of the property.
 
 You can select go the the General pane in preferences, look for Property 
 labels are: at the top, and select Name of LiveCode property. Then you 
 won't have to wait for a tool tip.
 
 Personally I think the native property names should be shown by default. New 
 users will learn scripting much faster if the real names are always 
 displayed, and if they wonder what a property does, the tooltip hover will 
 display the plain English description as a cue.
 
 Basically, whichever option is selected in prefs, the tooltip shows the other 
 one.
 
 -- 
 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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-15 Thread Alejandro Tejada

Devin Asay wrote
 [snip]
 Yes, I agree that sometimes concepts are too complex to describe in a
 short, neat label. But in the interface, perhaps the menu could show the
 effect of the ink visually, or maybe there could be a help button that
 would pop up a list explaining the inks in simple language.

This page explains the math of ink effects:
http://ssp.impulsetrain.com/porterduff.html

But the best way to understand ink effects is

1- creating a stack

2- import as control a transparent PNG image like:
http://pngimg.com/upload/orange_PNG811.png

3- import as control a second transparent PNG image like:
http://upload.wikimedia.org/wikipedia/commons/thumb/2/22/Earth_Western_Hemisphere_transparent_background.png/240px-Earth_Western_Hemisphere_transparent_background.png

4- Place the earth image over the orange. All orange leafs should be still
visible

5- select both images and group them...
The stack contains a group of two png images with transparency

6- Now... change ink effects on every element:
a) The Group
b) image Earth
c) image Orange

Results are difficult to predict, at least for me... :o





--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Error-Messages-Are-Evil-tp4679382p4679568.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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-15 Thread Scott Rossi

You're right, the results aren't predictable, as you've seen, since
object-level effects are modified when compounded by an effect applied to
a containing group.  Color sometimes plays factor too.

But realistically, there aren't that many results that are useful.
Generally, I've found the structural blends are most useful for masking
objects and groups, while the imaging blends are more for color/visual
effects, like the standard Photoshop blend modes.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 5/15/14 7:42 PM, Alejandro Tejada capellan2...@gmail.com wrote:

Devin Asay wrote
 [snip]
 Yes, I agree that sometimes concepts are too complex to describe in a
 short, neat label. But in the interface, perhaps the menu could show the
 effect of the ink visually, or maybe there could be a help button that
 would pop up a list explaining the inks in simple language.

This page explains the math of ink effects:
http://ssp.impulsetrain.com/porterduff.html

But the best way to understand ink effects is

1- creating a stack

2- import as control a transparent PNG image like:
http://pngimg.com/upload/orange_PNG811.png

3- import as control a second transparent PNG image like:
http://upload.wikimedia.org/wikipedia/commons/thumb/2/22/Earth_Western_Hem
isphere_transparent_background.png/240px-Earth_Western_Hemisphere_transpar
ent_background.png

4- Place the earth image over the orange. All orange leafs should be still
visible

5- select both images and group them...
The stack contains a group of two png images with transparency

6- Now... change ink effects on every element:
a) The Group
b) image Earth
c) image Orange

Results are difficult to predict, at least for me... :o





--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Error-Messages-Are-Evil-tp4
679382p4679568.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

IDE oddities (was Re: Error Messages Are Evil)


On May 13, 2014, at 9:57 PM, Alejandro Tejada capellan2...@gmail.com wrote:

 Richard Gaskin wrote
 [snip]
 These are basic tasks we should expect to be done efficiently and 
 without error.  They require no celebration.  Don't even mention them 
 unless something goes wrong.  Otherwise, as long as the computer is 
 doing what we expect it to do, please just shut up and let me focus on 
 my work.
 
 Thanks for letting me rant
 
 You are not alone in this! :D
 https://www.youtube.com/watch?v=xYiiD-p2q80

Thanks for the link, Alejandro. This is a great overview of usability 
principles, even for those of us who do not use Blender. Well worth a watch for 
anyone who designs software.

Now here's a good exercise for us LiveCode users--can we identify a similar 
list of oddities in the LiveCode IDE interface that might tend to turn off new 
users and send them elsewhere? The imminent prospect of an open-sourced IDE 
makes this an ideal time to start identifying these problems so that we can 
make the environment as inviting as possible for new users.

I'm not proposing we discuss every one of these issues in detail; some of them 
we've already beaten to death on this list. :) But we ought to create a list 
that those who work on the new IDE interface can consider.

I'll start...

One of the most confusing things to new users is the requirement to lock size 
and location of images after you have resized them. If you don't they revert to 
their original size when you leave the card and return. Why not make this 
settable with a property?

Closely related: Why are lock size and lock location controlled by a single 
property?

Anyone else?

Regards,

Devin

Devin Asay
Learn to code with LiveCode University
http://university.livecode.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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-14 Thread Dar Scott


On May 14, 2014, at 10:00 AM, Devin Asay devin_a...@byu.edu wrote:
 Closely related: Why are lock size and lock location controlled by a single 
 property?

Good question.  The good news is that it is now possible to group a single 
object.  

Dar Scott
Libraries and Externals
d...@swcp.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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-14 Thread Richmond


On 14/05/14 19:26, Dar Scott wrote:

On May 14, 2014, at 10:00 AM, Devin Asay devin_a...@byu.edu wrote:

Closely related: Why are lock size and lock location controlled by a single 
property?

Good question.  The good news is that it is now possible to group a single 
object.


What?

I grouped a single object with version 2.2.1: an image that was bigger 
than my stack, so I could

constrain it with scrollbars.

Richmond.



Dar Scott
Libraries and Externals
d...@swcp.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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-14 Thread Dar Scott

Yeah, I goofed.  

No sleep.  I was getting confused with grouping a group.  It can be done, but I 
don’t know how with the IDE.

Dar

On May 14, 2014, at 11:35 AM, Richmond richmondmathew...@gmail.com wrote:

 On 14/05/14 19:26, Dar Scott wrote:
 On May 14, 2014, at 10:00 AM, Devin Asay devin_a...@byu.edu wrote:
 Closely related: Why are lock size and lock location controlled by a single 
 property?
 Good question.  The good news is that it is now possible to group a single 
 object.
 
 What?
 
 I grouped a single object with version 2.2.1: an image that was bigger than 
 my stack, so I could
 constrain it with scrollbars.
 
 Richmond.
 
 
 Dar Scott
 Libraries and Externals
 d...@swcp.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: IDE oddities (was Re: Error Messages Are Evil)


On May 14, 2014, at 10:26 AM, Dar Scott d...@swcp.com wrote:

 
 On May 14, 2014, at 10:00 AM, Devin Asay devin_a...@byu.edu wrote:
 Closely related: Why are lock size and lock location controlled by a single 
 property?
 
 Good question.  The good news is that it is now possible to group a single 
 object.  

Thanks for your reply, Dar. I'd like to keep the focus of this thread on things 
in the LiveCode IDE that are odd, inconsistent, or confusing to the new user. 
Later I'll make a compilation and share it with the list. As a reminder, I got 
to thinking about this topic after watching an excellent 2-part video on user 
interface design principles at https://www.youtube.com/watch?v=xYiiD-p2q80. 
This series was focused on Blender, an open source 3D rendering package, but 
you could substitute LiveCode for Blender in the narrative and have a useful 
think about how LC's interface comes across to newbies.

In that spirit, here's another one:

- Lack of reliable Undo functionality outside of the script editor. This is a 
major source of frustration to new users (and old, but we've learned to work 
around it.)

(If you'd like to discuss the Undo issue, please start a new thread, so I can 
keep this one on topic.) :)

Thanks,

Devin



Devin Asay
Learn to code with LiveCode University
http://university.livecode.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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-14 Thread Peter Haworth

One thing that confused the heck out of me at the start is how the menu bar
changes depending on whether a stack or the script editor is in front (this
is on OSX).

When in the script editor, the menu bar shows File, Edit, Debug, Handler,
Window, Help and the File menu has no entries to open a stack, etc.  When
on a stack, it shows File, Edit, Tools, Object Text, Development, View,
Window, Help.

So if I'm in the script editor and close all the open stacks, there is no
way to open another stack without opening either the application browser or
the Tools palette (and maybe other IDE stacks), neither of which I use.

I'm sure this is a result of Apple's HIG but I have to say things work much
better in this regard on Windows, where the script editor related menus are
in the script editor itself.

Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html


On Wed, May 14, 2014 at 11:04 AM, Devin Asay devin_a...@byu.edu wrote:


 On May 14, 2014, at 10:26 AM, Dar Scott d...@swcp.com wrote:

 
  On May 14, 2014, at 10:00 AM, Devin Asay devin_a...@byu.edu wrote:
  Closely related: Why are lock size and lock location controlled by a
 single property?
 
  Good question.  The good news is that it is now possible to group a
 single object.

 Thanks for your reply, Dar. I'd like to keep the focus of this thread on
 things in the LiveCode IDE that are odd, inconsistent, or confusing to the
 new user. Later I'll make a compilation and share it with the list. As a
 reminder, I got to thinking about this topic after watching an excellent
 2-part video on user interface design principles at
 https://www.youtube.com/watch?v=xYiiD-p2q80. This series was focused on
 Blender, an open source 3D rendering package, but you could substitute
 LiveCode for Blender in the narrative and have a useful think about how
 LC's interface comes across to newbies.

 In that spirit, here's another one:

 - Lack of reliable Undo functionality outside of the script editor. This
 is a major source of frustration to new users (and old, but we've learned
 to work around it.)

 (If you'd like to discuss the Undo issue, please start a new thread, so I
 can keep this one on topic.) :)

 Thanks,

 Devin



 Devin Asay
 Learn to code with LiveCode University
 http://university.livecode.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: IDE oddities (was Re: Error Messages Are Evil)


On May 14, 2014, at 12:41 PM, Peter Haworth p...@lcsql.com
 wrote:

 One thing that confused the heck out of me at the start is how the menu bar
 changes depending on whether a stack or the script editor is in front (this
 is on OSX).
 
 When in the script editor, the menu bar shows File, Edit, Debug, Handler,
 Window, Help and the File menu has no entries to open a stack, etc.  When
 on a stack, it shows File, Edit, Tools, Object Text, Development, View,
 Window, Help.
 
 So if I'm in the script editor and close all the open stacks, there is no
 way to open another stack without opening either the application browser or
 the Tools palette (and maybe other IDE stacks), neither of which I use.
 
 I'm sure this is a result of Apple's HIG but I have to say things work much
 better in this regard on Windows, where the script editor related menus are
 in the script editor itself.

Good one, Pete. I trip over that all the time. Keep 'em coming, folks.

Here's another one of mine:

By default closing a stack window keeps the file open in memory. This is one of 
the biggest sources of confusion and frustration for new users. It is too easy 
to save and close a stack window, then inadvertantly open an older version of a 
stack and then make the wrong choice on the confusing Save-Purge-Cancel dialog. 
Often the new user is convinced that all of their recent work has simply 
vanished, when in reality they just opened the wrong version of the stack. The 
default behavior should be that when a stack window is closed it is also 
removed from memory. I realize there are good and valid reasons for the current 
behavior, but it is confusing and offputting for new users. Experienced users 
can easily change the behavior.

Devin

Devin Asay
Learn to code with LiveCode University
http://university.livecode.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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-14 Thread Alejandro Tejada

Actually, new users wants that LiveCode IDE
looks and behave as their own favorite
software...

So a Graphic Designer wants that Livecode looks
and behave like Photoshop, Ilustrator, Flash, etc.

A MS Office needs that LiveCode adopt all the
conventions of these products...

The 3D artist wants...
The Musician wants...
The Database Manager wants...
The Linux user wants...
The Mac User wants...
The Windows user wants

http://www.youtube.com/watch?v=BNsrK6P9QvI

Al



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Error-Messages-Are-Evil-tp4679382p4679496.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: IDE oddities (was Re: Error Messages Are Evil)


On May 14, 2014, at 3:31 PM, Alejandro Tejada capellan2...@gmail.com
 wrote:

 Actually, new users wants that LiveCode IDE
 looks and behave as their own favorite
 software...
 
 So a Graphic Designer wants that Livecode looks
 and behave like Photoshop, Ilustrator, Flash, etc.
 
 A MS Office needs that LiveCode adopt all the
 conventions of these products...
 
 The 3D artist wants...
 The Musician wants...
 The Database Manager wants...
 The Linux user wants...
 The Mac User wants...
 The Windows user wants
 
 http://www.youtube.com/watch?v=BNsrK6P9QvI
 
 Al

True, maybe, but surely there are interface problems that can be improved by 
applying common-sense design principles. The video you linked to before was 
arguing for the opposite of what special interest groups want. He was, in fact, 
arguing against his own special interest group (blender developers) in favor of 
making the user interface more accessible to new users.

I think we could do the same for the LiveCode interface.

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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-14 Thread J. Landman Gay


On 5/14/14, 1:04 PM, Devin Asay wrote:

I'd like to keep the focus of this thread on things in the LiveCode
IDE that are odd, inconsistent, or confusing to the new user.


I know there are a hundred things like that. Problem is, I'm so used to 
working around them that I can't think of what they are any more.


--
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: IDE oddities (was Re: Error Messages Are Evil)

2014-05-14 Thread Dr. Hawkins

On Wed, May 14, 2014 at 10:47 AM, Dar Scott d...@swcp.com wrote:

 No sleep.  I was getting confused with grouping a group.  It can be done,
 but I don’t know how with the IDE.


Group two things, and delete one.

I've stumbled across *empty* groups hanging around in my stacks . . .


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Error Messages Are Evil

2014-05-13 Thread Dave Kilroy

Thanks for this Dar - I like it very much :)

Dar Scott wrote
 Sure.  Here is a belabored example of my style of tenacious I/O.





-
Some are born coders, some achieve coding, and some have coding thrust upon 
them. - William Shakespeare  Hugh Senior

--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Error-Messages-Are-Evil-tp4679382p4679438.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: Error Messages Are Evil

2014-05-13 Thread Richard Gaskin


Peter M. Brigham wrote:
 Someone on this list (Richard Gaskin?) once observed that the
 difference between a tool and a product is that a tool only has
 to be able to be used properly, whereas a product has to be unable
 to be used improperly.

I wish I could take credit for that, but that slice of insight comes 
from Steven McConnell, from either Code Complete or Rapid Development.


...
 Windows has always done a lousy job with consistency...

One thing Windows is consistent about is telling us obvious things that 
don't need special notice, like letting me know there are icons on my 
desktop or that I've inserted a CD.


Of course I've inserted a CD - I know that because I just did it.  In 
fact, I can't think of any other way to insert a CD than by human 
intervention, so what new information did they designers of the OS 
imagine they were imparting?


It's the opposite of a confidence-builder when the designers of an OS 
are so overjoyed at the prospect of a computer simply doing what you 
asked it to do that it must be celebrated with an announcement.


Ubuntu had a similar annoyance for many years (thankfully fixes in 
recent versions):  when connecting to wifi, it would present a 
notification box letting me know, as though the wifi icon wasn't 
notification enough.


These are basic tasks we should expect to be done efficiently and 
without error.  They require no celebration.  Don't even mention them 
unless something goes wrong.  Otherwise, as long as the computer is 
doing what we expect it to do, please just shut up and let me focus on 
my work.



Thanks for letting me rant

--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 Follow me on Twitter:  http://twitter.com/FourthWorldSys


___
use-livecode mailing list
use-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: Error Messages Are Evil

2014-05-13 Thread Alejandro Tejada

Richard Gaskin wrote
 [snip]
 These are basic tasks we should expect to be done efficiently and 
 without error.  They require no celebration.  Don't even mention them 
 unless something goes wrong.  Otherwise, as long as the computer is 
 doing what we expect it to do, please just shut up and let me focus on 
 my work.
 
 Thanks for letting me rant

You are not alone in this! :D
https://www.youtube.com/watch?v=xYiiD-p2q80



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Error-Messages-Are-Evil-tp4679382p4679456.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: Error Messages Are Evil

2014-05-12 Thread Peter Bogdanoff

I've been having a horrible experience with the United States Internal Revenue 
Service website--trying just to set up an account in order to download a pdf of 
a previous year's return.

Every attempt (at least 6) over two days ended somewhere along the process with:
A technical problem has occurred. Please try your request again later.
followed by the options Close your browser and a button Continue ().

The time I actually did get to the part where I was able to set a user name and 
password, there was no explanation what was an acceptable user name or password 
until I had entered one in. I pushed on through this and the security questions 
and answers until the final Create account where I got again the A technical 
problem has occurred. Please try your request again later.

(I was trying to avoid the 2 hour wait time on the phone and the 60 mile drive 
to the nearest IRS office.)

Idiot programmers. Maybe the same ones who did the Obamacare website. Grr.

Peter Bogdanoff
UCLA



On May 11, 2014, at 10:19 PM, Bob Sneidar bobsnei...@iotecdigital.com wrote:

 I also meant to say that to imagine one could predict every kind of erroneous 
 user input or machine fault and program around it is easy, but it’s just our 
 imagination. In reality, it is a great deal more difficult to do. I remember 
 articles written when Hypercard was rolled out, about how much work it took 
 in a commercial product to program around the possible user input errors. 
 Some were saying that a full 2/3 to 3/4 of code in a commercial product was 
 dedicated to error detection. My own experience bears this out. How often do 
 we encounter a dialog that reports an “unknown error”?
 
 Perhaps I should revise my estimate of this article, referring to it as 
 “tripe”. Perhaps that was too harsh. It’s probably just a product of the 
 author’s imagination. How nice it would be if we could write software that 
 never generated an error dialog? And have bacon that cooks itself, and dishes 
 that never got dirty, and clothes that put themselves on our bodies when we 
 called for them? Well, that WOULD be nice indeed!
 
 Bob S
 
 
 On May 11, 2014, at 10:48 , Bob Sneidar 
 bobsnei...@iotecdigital.commailto:bobsnei...@iotecdigital.com wrote:
 
 Call me a naysayer, but I think the premise is nonsense.
 
 ___
 use-livecode mailing list
 use-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: Error Messages Are Evil

2014-05-12 Thread Richmond


snip


Idiot programmers. Maybe the same ones who did the Obamacare website. Grr.

Peter Bogdanoff
UCLA


Yes; a program is only so good as its programmers have made it; so Donald 
Norman's anthropomorphic heresy
piling all the blame on some machine is ridiculous.

Nowadays we don't have bad computers; we only have bad programmers.

And, to be honest the bad programmers are not the ones we have to be worried 
about, as bad programs
can normally be seen a mile off and avoided.

What we have to be worried about MOST are the programmers, who might as such be 
very good programmers, who
don't have a clue how end-users might respond to their program's interface.

Richmond.


snip

___
use-livecode mailing list
use-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: Error Messages Are Evil

2014-05-12 Thread J. Landman Gay


On 5/11/14, 7:49 PM, Dar Scott wrote:

Sure.  Here is a belabored example of my style of tenacious I/O.


Good stuff, thanks for writing that up. I need to pay more attention to 
this kind of thing. It's way too easy to pop up a dialog and tell the 
user they're wrong, and that's not a great approach no matter how kindly 
you phrase the prompt.


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

Someone on this list (Richard Gaskin?) once observed that the difference
between a tool and a product is that a tool only has to be able to be used
properly, whereas a product has to be unable to be used improperly. A
well-designed application should anticipate as much as possible users' likely
confusion and prevent users from doing things by mistake. Error messages are
part of this process -- but they should be more in the form of in order to do
x I must know y and z, please clarify… or did you mean a or b? or I'm
sorry, you can't do x in this context, do you want me to…. Even better, the
interface should be designed so that even these messages are encountered rarely
-- consistency is a crucial part of this. The earlier Apple OSes used to do a
good job on this, mostly. Later versions not so much. Windows has always done a
lousy job with consistency -- I don't know how many times I've found that I
can't paste into a Windows system window.

Sorry, you got me started….

-- Peter

Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig

On May 11, 2014, at 5:24 PM, Alejandro Tejada wrote:

Probably, the point of Mr. Donald Norman is:

Reduce as much as possible the chance of
human error... (Richmond wrote about this
key concept in a previous message: affordance)
http://www.jnd.org/dn.mss/affordances_and.html

A truly collaborative system would tell me the requirements
before I did the work. If there are special ways you want
stuff entered, tell me before I enter it, not afterwards.

How many times must we endure the indignity of typing in
a long strong only to be told afterwards that it doesn't fit
the machine's whims (more accurately, doesn't fit the
whims of the programmer)?

Yes, that is the point: The program should guide the users
and collaborate with them... effectively stopping them
of making ineffective or potentially dangerous actions
and guiding users in a smart way.

This sounds really difficult to do. It's very difficult to stop
users from doing what they want, but not impossible.

It's possible, but... it's wise?

and that is another difficult question
to answer...

--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Error-Messages-Are-Evil-tp4679382p4679389.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: Error Messages Are Evil

2014-05-11 Thread Richmond


On 11/05/14 21:48, Alejandro Tejada wrote:

Recent article published by Don Norman.
http://www.jnd.org/dn.mss/error_messages_are_e.html

Error messages punish people for not behaving like machines.
It is time we let people behave like people. When a problem
arises, we should call it machine error, not human error:

the machine was designed wrong, demanding that we conform
to its peculiar requirements. It is time to design and build
machines that conform to our requirements.


Indeed: but how?

Mind you, if Donald Norman (who has been banging on about Usability 
theory and 'affordance'
for years) wants to write about machine errors, he should at least 
correct his human error and

get his English grammar sorted out:

the machine was designed wrong

is a simple grammatical error any person who wants to be taken 
seriously, and has any academic

pretensions, should not make.

the machine was designed wrongly

Obviously Donald Norman doesn't know that verbs are modified by adverbs, 
not adjectives:

that is HUMAN ERROR.

-

It is time to design and build machines that conform to our requirements

Well, oddly enough, all machines that I know of are designed by humans, 
and are very rarely,
if ever, designed to annoy the people who use them, but in conformance 
to their requirements.




Donald Norman started his career years ago by making some blindingly 
obvious remarks about
door handles being put on the wrong way round, or on the wrong sides of 
door . . . and he did
have a point; now he, as a one trick pony has extended that into areas 
which do not connect

with door handles.

---

What Norman might have done is criticise GUI, and in very many cases the 
criticism would be valid.


What Norman conveniently overlooks is that millions of people use 
computers with
badly designed interfaces, badly designed keyboards (he had a right 
royal rant about the QWERTY
keyboard) and don't seem to feel an urge to get up from their collective 
bottom and radically

redesign everything.

The same could be said for the efforts of the late Jeff Raskin.



Error messages are a necessity, not because computer systems are 
designed badly, but because
humans and computers are completely different things that work in 
completely different ways.


If babies had error messages parenting would be 1000 times easier.

All an error message is is a computer's way of telling us it doesn't 
understand; because a computer
is, frankly, a very stupid mathematical calculator, and we humans are 
not. If a computer did not
throw up error messages we would never know when we were failing to get 
a machine to do what we wanted it to do: that would make life far more 
difficult than any error message.


Stop confronting us: Collaborate with us.




Computers never confront us; they are not capable of that. All a 
computer does is tell you it does

not understand what you have told it to do.

Accusing a computer of confronting us is a socking great 
anthropomorphism which only serves to show that Norman has very little 
understanding of what a computer is and what it can do.


The fact is that a computer can ONLY do what we tell it to; and it ONLY 
understands a load of electronic pulses. Clever people have made our 
lives easier by designing graphical representations
of what goes on inside a computer and nicer ways of getting a computer 
to do what you want it
to. Some people are not quite as clever as other people, and they have 
designed less effective

ways of getting a computer to do something.

--

Error messages punish people

punish ; utter rubbish.

Error messages are more important than Norman realises.

Before he makes any further pronouncements of this sort Donald Norman 
needs to do the

following to things:

1. Go on holiday to a country where he doesn't speak the language and 
nobody there speaks his.


2. Get time allotted to himself on a VAX machine (if there are any left) 
and learn a spot of
Assembler language, and then try and type an e-mail message to his best 
friend using only

Assembler language on the VAX.

-

It's amazing how purified I feel after a rant of that sort.

But, having had to read about 3 of Norman's book and attend interminable 
lectures on
Usability theory at the University of Abertay I feel very strongly 
indeed about what he says, and

have given it some considerable thought.

Richmond.

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

Re: Error Messages Are Evil

2014-05-11 Thread Bob Sneidar

Call me a naysayer, but I think the premise is nonsense. Only a perfect machine 
could conform to those standards, and there is no perfect machine. All will 
have or develop problems, and to not inform the user when that happens is 
irresponsible at best, and disastrous at worse. And it doesn’t help to exclude 
error banners (like some red text in a web page) as being error dialogs. The 
issue is confrontation, and an error banner is every bit a confrontation 
towards the user that a mistake has been made. 

Here is a common scenario: I need the user to enter his full address in order 
to ship the product to him. The end user neglects to enter his street address, 
or perhaps enters the wrong credit card number, and clicks submit. God forbid I 
should punish the poor end user for (dare I say it) making a mistake! Better 
that I just allow the order to go through, and perhaps pick an address in the 
concentric center of what information I have, or just ship the product anyway, 
even though no actual payment has been made, but by all means I MUST NOT 
present the end user with a judgmental ERROR DIALOG, or offend against his 
frail ego by alerting him to any oversight he may have inadvertently made! If 
the machine cannot discern the missing information, then it cannot be human 
error. It MUST be the machine! 

Pure tripe. 

Bob S


On May 11, 2014, at 08:48 , Alejandro Tejada capellan2...@gmail.com wrote:

 Recent article published by Don Norman.
 http://www.jnd.org/dn.mss/error_messages_are_e.html
 
 Error messages punish people for not behaving like machines. 
 It is time we let people behave like people. When a problem 
 arises, we should call it machine error, not human error:
 
 the machine was designed wrong, demanding that we conform 
 to its peculiar requirements. It is time to design and build 
 machines that conform to our requirements. 
 
 Stop confronting us: Collaborate with us.
 
 
 
 --
 View this message in context: 
 http://runtime-revolution.278305.n4.nabble.com/Error-Messages-Are-Evil-tp4679382.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: Error Messages Are Evil

2014-05-11 Thread Alejandro Tejada

Probably, the point of Mr. Donald Norman is:

Reduce as much as possible the chance of 
human error... (Richmond wrote about this
key concept in a previous message: affordance)
http://www.jnd.org/dn.mss/affordances_and.html

A truly collaborative system would tell me the requirements
before I did the work. If there are special ways you want 
stuff entered, tell me before I enter it, not afterwards. 

How many times must we endure the indignity of typing in 
a long strong only to be told afterwards that it doesn't fit 
the machine's whims (more accurately, doesn't fit the 
whims of the programmer)?

Yes, that is the point: The program should guide the users
and collaborate with them... effectively stopping them
of making ineffective or potentially dangerous actions
and guiding users in a smart way.

This sounds really difficult to do. It's very difficult to stop
users from doing what they want, but not impossible.

It's possible, but... it's wise? 

and that is another difficult question
to answer...

Al




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Error-Messages-Are-Evil-tp4679382p4679389.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: Error Messages Are Evil

Ah, I have much to learn.

I said, “The house was painted red.”  

I should have said, “The house was painted redly.”  

Dar


On May 11, 2014, at 1:43 PM, Richmond richmondmathew...@gmail.com wrote:

 On 11/05/14 21:48, Alejandro Tejada wrote:
 Recent article published by Don Norman.
 http://www.jnd.org/dn.mss/error_messages_are_e.html
 
 Error messages punish people for not behaving like machines.
 It is time we let people behave like people. When a problem
 arises, we should call it machine error, not human error:
 
 the machine was designed wrong, demanding that we conform
 to its peculiar requirements. It is time to design and build
 machines that conform to our requirements.
 
 Indeed: but how?
 
 Mind you, if Donald Norman (who has been banging on about Usability theory 
 and 'affordance'
 for years) wants to write about machine errors, he should at least correct 
 his human error and
 get his English grammar sorted out:
 
 the machine was designed wrong
 
 is a simple grammatical error any person who wants to be taken seriously, and 
 has any academic
 pretensions, should not make.
 
 the machine was designed wrongly
 
 Obviously Donald Norman doesn't know that verbs are modified by adverbs, not 
 adjectives:
 that is HUMAN ERROR.
 
 -
 
 It is time to design and build machines that conform to our requirements
 
 Well, oddly enough, all machines that I know of are designed by humans, and 
 are very rarely,
 if ever, designed to annoy the people who use them, but in conformance to 
 their requirements.
 
 
 
 Donald Norman started his career years ago by making some blindingly obvious 
 remarks about
 door handles being put on the wrong way round, or on the wrong sides of door 
 . . . and he did
 have a point; now he, as a one trick pony has extended that into areas 
 which do not connect
 with door handles.
 
 ---
 
 What Norman might have done is criticise GUI, and in very many cases the 
 criticism would be valid.
 
 What Norman conveniently overlooks is that millions of people use computers 
 with
 badly designed interfaces, badly designed keyboards (he had a right royal 
 rant about the QWERTY
 keyboard) and don't seem to feel an urge to get up from their collective 
 bottom and radically
 redesign everything.
 
 The same could be said for the efforts of the late Jeff Raskin.
 
 
 
 Error messages are a necessity, not because computer systems are designed 
 badly, but because
 humans and computers are completely different things that work in completely 
 different ways.
 
 If babies had error messages parenting would be 1000 times easier.
 
 All an error message is is a computer's way of telling us it doesn't 
 understand; because a computer
 is, frankly, a very stupid mathematical calculator, and we humans are not. If 
 a computer did not
 throw up error messages we would never know when we were failing to get a 
 machine to do what we wanted it to do: that would make life far more 
 difficult than any error message.
 
 Stop confronting us: Collaborate with us.
 
 
 
 Computers never confront us; they are not capable of that. All a computer 
 does is tell you it does
 not understand what you have told it to do.
 
 Accusing a computer of confronting us is a socking great anthropomorphism 
 which only serves to show that Norman has very little understanding of what a 
 computer is and what it can do.
 
 The fact is that a computer can ONLY do what we tell it to; and it ONLY 
 understands a load of electronic pulses. Clever people have made our lives 
 easier by designing graphical representations
 of what goes on inside a computer and nicer ways of getting a computer to do 
 what you want it
 to. Some people are not quite as clever as other people, and they have 
 designed less effective
 ways of getting a computer to do something.
 
 --
 
 Error messages punish people
 
 punish ; utter rubbish.
 
 Error messages are more important than Norman realises.
 
 Before he makes any further pronouncements of this sort Donald Norman needs 
 to do the
 following to things:
 
 1. Go on holiday to a country where he doesn't speak the language and nobody 
 there speaks his.
 
 2. Get time allotted to himself on a VAX machine (if there are any left) and 
 learn a spot of
 Assembler language, and then try and type an e-mail message to his best 
 friend using only
 Assembler language on the VAX.
 
 -
 
 It's amazing how purified I feel after a rant of that sort.
 
 But, having had to read about 3 of Norman's book and attend interminable 
 lectures on
 Usability theory at the University of Abertay I feel very strongly indeed 
 about what he says, and
 have given it some considerable thought.
 
 Richmond.
 
 ___
 use-livecode mailing list

Re: Error Messages Are Evil

Often I design communications without error responses to commands.  Instead 
there is state information while the underlying system is working doggedly to 
make what you wanted work.  

On May 11, 2014, at 12:48 PM, Alejandro Tejada capellan2...@gmail.com wrote:

 Recent article published by Don Norman.
 http://www.jnd.org/dn.mss/error_messages_are_e.html
 
 Error messages punish people for not behaving like machines. 
 It is time we let people behave like people. When a problem 
 arises, we should call it machine error, not human error:
 
 the machine was designed wrong, demanding that we conform 
 to its peculiar requirements. It is time to design and build 
 machines that conform to our requirements. 
 
 Stop confronting us: Collaborate with us.
 
 
 
 --
 View this message in context: 
 http://runtime-revolution.278305.n4.nabble.com/Error-Messages-Are-Evil-tp4679382.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: Error Messages Are Evil

2014-05-11 Thread dunbarx

I am a person, and I behave like a person. That means that 99% of all mistakes, 
errors and harebrained methods are proudly mine.


The machine is not perfect; LC has its peccadillos. But I would never have the 
temerity to accuse the machine being the source of my woes.


Craig Newman



-Original Message-
From: Bob Sneidar bobsnei...@iotecdigital.com
To: How to use LiveCode use-livecode@lists.runrev.com
Sent: Sun, May 11, 2014 4:49 pm
Subject: Re: Error Messages Are Evil


Call me a naysayer, but I think the premise is nonsense. Only a perfect machine 
could conform to those standards, and there is no perfect machine. All will 
have 
or develop problems, and to not inform the user when that happens is 
irresponsible at best, and disastrous at worse. And it doesn’t help to exclude 
error banners (like some red text in a web page) as being error dialogs. The 
issue is confrontation, and an error banner is every bit a confrontation 
towards 
the user that a mistake has been made. 

Here is a common scenario: I need the user to enter his full address in order 
to 
ship the product to him. The end user neglects to enter his street address, or 
perhaps enters the wrong credit card number, and clicks submit. God forbid I 
should punish the poor end user for (dare I say it) making a mistake! Better 
that I just allow the order to go through, and perhaps pick an address in the 
concentric center of what information I have, or just ship the product anyway, 
even though no actual payment has been made, but by all means I MUST NOT 
present 
the end user with a judgmental ERROR DIALOG, or offend against his frail ego by 
alerting him to any oversight he may have inadvertently made! If the machine 
cannot discern the missing information, then it cannot be human error. It MUST 
be the machine! 

Pure tripe. 

Bob S


On May 11, 2014, at 08:48 , Alejandro Tejada capellan2...@gmail.com wrote:

 Recent article published by Don Norman.
 http://www.jnd.org/dn.mss/error_messages_are_e.html
 
 Error messages punish people for not behaving like machines. 
 It is time we let people behave like people. When a problem 
 arises, we should call it machine error, not human error:
 
 the machine was designed wrong, demanding that we conform 
 to its peculiar requirements. It is time to design and build 
 machines that conform to our requirements. 
 
 Stop confronting us: Collaborate with us.
 
 
 
 --
 View this message in context: 
 http://runtime-revolution.278305.n4.nabble.com/Error-Messages-Are-Evil-tp4679382.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: Error Messages Are Evil

2014-05-11 Thread J. Landman Gay

I'm interested.  Can I get an example? I know Apple discourages error dialogs 
now.  

On May 11, 2014 5:44:47 PM CDT, Dar Scott d...@swcp.com wrote:
Often I design communications without error responses to commands. 
Instead there is state information while the underlying system is
working doggedly to make what you wanted work.  

-- 
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: Error Messages Are Evil

2014-05-11 Thread Peter Haworth

Perfect example - signing up for an account online and getting an error
because your password didn't meet the site 's rules which they didn't
reveal to start with. That's evil!

Pete
lcSQL Software
On May 11, 2014 2:24 PM, Alejandro Tejada capellan2...@gmail.com wrote:

Probably, the point of Mr. Donald Norman is:

Reduce as much as possible the chance of
human error... (Richmond wrote about this
key concept in a previous message: affordance)
http://www.jnd.org/dn.mss/affordances_and.html

A truly collaborative system would tell me the requirements
before I did the work. If there are special ways you want
stuff entered, tell me before I enter it, not afterwards.

How many times must we endure the indignity of typing in
a long strong only to be told afterwards that it doesn't fit
the machine's whims (more accurately, doesn't fit the
whims of the programmer)?

This sounds really difficult to do. It's very difficult to stop
users from doing what they want, but not impossible.

It's possible, but... it's wise?

and that is another difficult question
to answer...

--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Error-Messages-Are-Evil-tp4679382p4679389.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: Error Messages Are Evil

Sure.  Here is a belabored example of my style of tenacious I/O.

I typically start one each of a communications “machine with prefixStart 
command and stop it with prefixStop.  The status is available though a status 
function and notification of the status change by a callback.  

A very simple example is a TCP service.  

Almost always present is the part of the status that says the machine is on or 
off.  That is, the start handler has been called.

A fundamental part of the status for such a service is whether a listening port 
is set up correctly.  That part of the status might have values “listening” or 
“can’t listen (latest reason)”.  The callback allows this to be displayed as 
a green light or a red light, or it might never get to the user.  

If the machine gets an error on accept (usually because you left a test 
standalone running or forgot to shut down some OS service) that status will 
remain “can’t listen”.  The machine keeps trying every half second or so, 
depending on the need.  It doesn’t block in the start.  I use 'send … in … 
seconds’.

Quit that offending application and this one has a green light indicator 
immediately.

This same thing applies to a gadget that looks like a serial adaptor.  “Oh.  
It’s not plugged in.”  Plug it in and everything starts working.  Want to move 
it to the front?  Unplug it, the light goes red, plug it back in and the light 
turns green.  All is working.  

Now, think of something more complicated, such a machine that allows you to 
pass an array from one app to the other.  In that case write errors might mean 
trying again, even trying to take things down and building them again.  The 
machine keeps trying everything, kicking and biting, to do what you want.  
Heartbeat messages back and forth let your code and perhaps the user know what 
the current state of affairs is:  communicating. 

You can see the current state in the status.  

So, a status for array sender might be “on, receiver open, sender open, 
receiving, sending, high error rates”.  

So, in my communications modules, I say, “Don’t tell me you can’t, just let me 
know how well you are doing.  Just keep at it.  Wen’t down a bunny trail?  Then 
backtrack or start over if you have to.”  

This is also important when there are lots of components to a complex system 
and I expect the system to work no matter the order the components got started 
or got past hurdles.

If you have an application blocking a network port you wanted to use, you want 
to shut it down and everything start working.  You don’t want to say, “OK, I 
think I found the problem, everybody shut your systems down and then bring them 
come up when I say.  We should be able to grab an early breakfast within the 
hour or so.”  

The important goal is if everything is in the right state and in the right 
environment, it works.  It doesn’t matter how it got there.  

I call this tenacious I/O.  Some have called it Dar’s badger programming.  

This does not apply to isolated request-response situations, such as making a 
REST query with LiveCode URL.  But it might apply to a simple REST server.  It 
might apply to some higher level function that needs to work doggedly at 
getting something done that includes making REST queries.   

Most of what I do with this is for control, but it also applies to physical 
security and distributed systems.

I also design protocols are are highly resistant to errors.  

Dar


On May 11, 2014, at 5:21 PM, J. Landman Gay jac...@hyperactivesw.com wrote:

 I'm interested.  Can I get an example? I know Apple discourages error dialogs 
 now.  
 
 On May 11, 2014 5:44:47 PM CDT, Dar Scott d...@swcp.com wrote:
 Often I design communications without error responses to commands. 
 Instead there is state information while the underlying system is
 working doggedly to make what you wanted work.  
 
 -- 
 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: Error Messages Are Evil

2014-05-11 Thread Mark Wieder

Dar-

Do not go gently into that good night.

-- 
-Mark Wieder
 ahsoftw...@gmail.com

This communication may be unlawfully collected and stored by the National 
Security Agency (NSA) in secret. The parties to this email do not 
consent to the retrieving or storing of this communication and any 
related metadata, as well as printing, copying, re-transmitting, 
disseminating, or otherwise using it. If you believe you have received 
this communication in error, please delete it immediately.


___
use-livecode mailing list
use-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: Error Messages Are Evil