date:20160302


On 3/2/2016 11:29 PM, Monte Goulding wrote:

>2) we cannot resize the content area for fields of custom props! ouch!

Yes it would seem reasonable to allow us to resize the custom control pane down 
enlarging the value field and put scrollbars on it. Perhaps the option to turn 
on and off wrapping would be helpful too.


Ditto for the content area for fields, which shows only one line. It 
needs to be far taller by default, and resizeable. I think we all edit 
text in there, it's the easiest way to change the content of a locked 
field without tinkering with its other properties. I need to see at 
least a few paragraphs most of the time.


The widths of buttons like those in the graphic effects pane are 
overbearing. They should probably be about half their current width. I 
suspect they were made that wide to accomodate the width of the stack 
header, but they do look sort of clunky. I'm not sure how to solve that, 
but the layout doesn't look right.


The ink effects popdown in the Color pane is also too wide, about three 
times wider than the text it contains, which leaves a large, unused 
empty area above it in the window. Ideally the description of the 
pattern boxes would appear to the right of each box instead of under the 
color description (I know that won't be easy, given the new method for 
building the inspector) but that would fill up some of the empty space.


But even better, I really want the ink popdown to be a list field like 
it was before, which could fit nicely in all that unused space at the 
right of the color/pattern boxes. I think most of us cycle through all 
the ink options looking for the right one, and using arrow keys to 
travel up and down the list is extremely convenient -- one keystroke and 
the target object changes its ink instantly. You can view them all very 
quickly. A popdown button requires you to complete dozens of manual 
selections, and that's not only slow, it's hard on my tendonitis.


--
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: LC8DP15 feedback-IDE Issues

2016-03-02 Thread Erik Beugelaar

I totally agree with the comments from Jacqueline. 

Sent from Matwetwe < http://www.about.me/beugelaar >



On 03:26, Mar 3, 2016, at 03:26, Roland Huettmann  
wrote:
>I really like this comment from Jacqueline.
>
>Who does not eat with the eyes???
>
>An ugly apple is not purchased even if much more tasty.
>
>Roland
>
>
>On Thu, Mar 3, 2016, 01:11 J. Landman Gay 
>wrote:
>
>> On March 2, 2016 4:43:21 PM Richard Gaskin
>
>> wrote:
>> >
>> > Given this, I wonder if it makes more communicative sense to
>consider
>> > moving the basic controls above the Widgets, closer to the
>always-used
>> > Browse and Pointer icons.
>>
>>
>> That was one of the things on my imaginary list. I'd like to see
>widgets at
>> the bottom of the tool palette where they are out of the way, and
>where
>> there is room for expansion as more become available. The primary hit
>> regions will always be the browse and edit tools, and they need to be
>> slightly larger than all the others and at the top where the user's
>eye
>> will focus first.
>>
>> Widgets are also a little too large compared to the other icons, and
>too
>> dark, which makes them visually distracting. They also don't match
>the rest
>> of the interface. Most professional teams create a particular color
>palette
>> early on that will represent their brand and all interface elements
>must
>> adhere to it. Apple uses blue, Google centers around certain
>saturations of
>> primary colors, etc.  LC should choose a color scheme and use it
>throughout
>> to visually integrate all components.
>>
>> I'd avoid greys except as backgrounds. Very dark gray is okay for
>text but
>> not so good for primary icons, it's too overbearing. Very light grey
>is
>> difficult to see, and also implies less importance (temporary text in
>> fields is often light grey, for example, to indicate the text will
>> disappear when the user starts typing.)
>>
>> I do favor functionality over appearance, but the sad fact is that
>new
>> users will base their first impressions of the product on how it
>looks.
>> These are some of the small details that matter for a professional
>> presentation.
>>
>> --
>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>> HyperActive Software   | http://www.hyperactivesw.com
>>
>>
>>
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>___
>use-livecode mailing list
>use-livecode@lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Edinburgh Aug 2-4, 2016


> On 3 Mar 2016, at 4:39 PM, [-hh]  wrote:
> 
> *** And your answer to the proposal of an actual ***
> *** externals-SDK is really the empty set?  :-(  ***

Well I'm not in a position to promise what I will be able to work on just yet 
which is why I didn't comment. When you have a boss you do what he says or you 
don't have a boss for very long ;-)
> 
> But I shouldn't waste the time of a LC dev-team member ...

I'm not working for them just yet (soon) so it's ok to waste my time :-)
___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues


On 3/2/2016 10:27 PM, Sannyasin Brahmanathaswami wrote:

4) no tool tips for the icons at the top. Those who have poor visual
memory (many coders do) will have this subtle "what does the icon do"
reaction. Please add the tool tips.


I need those too. The tooltips are actually there, they just don't 
display. The same omission also happens when pointing to any widget in 
the tool palette.


--
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: Edinburgh Aug 2-4, 2016

2016-03-02 Thread [-hh]

> > Hermann H. wrote
> > I use to look at the top of the current bugs list when I 
> > report one. I have several more to report but stopped for 
> > a while: 
> > The list is simply too long. They will even have problems 
> > to solve the bugs for the current 8.0-dp and to solve the 
> > main problems of LC 6/7 to get (essentially) rid of that 
> > versions. [So any further bug report that goes from LC8 
> > back to LC6 will slow down the 'avantgarde development’.]
> Monte G. wrote.  
> LiveCode is a very large and complex system. Bugs are always
> going to exist in it. The ones that definitely won’t get fixed
> are those that are never reported though! Considering you’ve
> just had one of your bugs fixed (17013) within 6 days of
> reporting (including the weekend) I’m really not sure why you
> are overly concerned about posting bug reports.
> Cheers Monte 

I didn't and I can't complain about resolving bugs reported by
me as they are currently mainly to HTML5.
[And 17013 is one that takes place when going to the limits of
LC 7/8. This wasn't really important. They probably used it to
detect actual memory (leak-)problems.]
But one can see from handling bugs, how much 'nasty' work they
are doing (you will know already now better in detail than I
do) and have on their to-do-list.

It is not important for me to solve some HTML5 problems others
find important. I know HTML5 and can do that "directly" what I
need. It's the fun with LC, to push it in that direction.
It's a good path: For example even leading Mozilla-dev people
(Firefox) already know and acknowledge, that LC is the first
scripting-IDE that compiles (using emscripten for rendering)
directly into HTML5.

*** And your answer to the proposal of an actual ***
*** externals-SDK is really the empty set?  :-(  ***

But I shouldn't waste the time of a LC dev-team member ...

Hermann


___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues


> On 3 Mar 2016, at 3:27 PM, Sannyasin Brahmanathaswami  
> wrote:
> 
> 0) Script editor needs its own top level icon in the Prop inspector! Already 
> requested, but in DP15 it did not happen. If you need space then move the 
> geometry manager icon off to the advanced pull down. Editing scripts comes 
> way ahead of geo manager in dev priority.

What’s wrong with the bug Code button on the toolbar? I would say it could go 
where the prefs cog and just edit the prefs for the inspector in the 
preferences UI, however, I would note that we haven’t had a script button on 
the inspector for some years.
> 
> 1)  the card title of prop inspector goes dim if you click on the stack. The 
> greyscale level is so low i can barely read it.

This is just what happens to palette windows. I’m not sure how you are 
expecting them to fix that.
> 
> 2) we cannot resize the content area for fields of custom props! ouch!

Yes it would seem reasonable to allow us to resize the custom control pane down 
enlarging the value field and put scrollbars on it. Perhaps the option to turn 
on and off wrapping would be helpful too.
> 
> 3) after setting a color in the colors, there is no "Clear" option. you 
> actually have to right click and choose "reset to default"  which is OK I 
> guess once you try that, but newbies will be frustrated

Yes I suspect an inherited checkbox might be good there.
> 
> 4) no tool tips for the icons at the top. Those who have poor visual memory 
> (many coders do) will have this subtle "what does the icon do" reaction. 
> Please add the tool tips.

I agree that would be helpful
> 
> 5) Graphic effects icon doesn't make any sense... looks like another pencil 
> or something. Better to have a small circle with a gradient or something.

I’m not sure about the icon but there’s some other issues here too. The color 
dialog opens behind the gradient dialog. It’s not intuitive that you need to 
choose from the types in order to add a gradient (perhaps a cancel button to 
reset to previous and apply a gradient from the start). Choosing reset to 
default presents the dialog in addition to clearing.
> 
> 6) Entering custom props is messed up (already reported and confirm)…

Yes I reported an issue with the property not being set unless you click around 
and it definitely fails if you add another property in your clicking around.
> 
> 7) Button icons icon doesn't make visual sense... find an icon that looks 
> like an icon.


Works for me actually

___
use-livecode mailing list
use-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: Edinburgh Aug 2-4, 2016

> On 3 Mar 2016, at 3:22 PM, [-hh]  wrote:
> 
> I use to look at the top of the current bugs list when I
> report one. I have several more to report but stopped for
> a while:
> The list is simply too long. They will even have problems
> to solve the bugs for the current 8.0-dp and to solve the
> main problems of LC 6/7 to get (essentially) rid of that
> versions. [So any further bug report that goes from LC8
> back to LC6 will slow down the 'avantgarde development’.]

LiveCode is a very large and complex system. Bugs are always going to exist in 
it. The ones that definitely won’t get fixed are those that are never reported 
though! Considering you’ve just had one of your bugs fixed (17013) within 6 
days of reporting (including the weekend) I’m really not sure why you are 
overly concerned about posting bug reports.

Cheers

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

Re: LC8DP15 feedback-IDE Issues

2016-03-02 Thread Sannyasin Brahmanathaswami

On March 2, 2016 at 4:29:17 PM, J. Landman Gay 
(jac...@hyperactivesw.com) wrote:

> The idea was to be able to select things in the PB that may not be in
> view, even on totally different cards or stacks, and be able to work
> with them without going there. Hilited lines indicate which objects will
> be affected. This could be useful. On the other hand, there is now a
> disconnect between visible selections on a card and objects you can act
> on within the PB.

I'm already fond of this feature. I may have the property inspector open for 
one object but i want to edit the script of a different one. Being able to 
click the other object script lines number without losing the current selected 
object is, IMHO very useful

> Selections also act slightly differently in the Property Inspector. It
> used to be you could shift-click several objects and then double-click
> any one of them to open the multi-object inspector. That doesn't work
> now. Instead you double-click one object on the card to open its
> inspector and then shift-click objects to add more. That causes the
> alignment icon to appear at the top left of the inspector, and the other
> icons will operate on all the selected objects.

Agreed.. this is an issue. I'm always needing to align controls.

  There are multiple issue with the prop inspector.  Not sure how best to 
tackle them.

e.g.

0) Script editor needs its own top level icon in the Prop inspector! Already 
requested, but in DP15 it did not happen. If you need space then move the 
geometry manager icon off to the advanced pull down. Editing scripts comes 
way ahead of geo manager in dev priority.

1)  the card title of prop inspector goes dim if you click on the stack. The 
greyscale level is so low i can barely read it.

2) we cannot resize the content area for fields of custom props! ouch!

3) after setting a color in the colors, there is no "Clear" option. you 
actually have to right click and choose "reset to default"  which is OK I guess 
once you try that, but newbies will be frustrated

4) no tool tips for the icons at the top. Those who have poor visual memory 
(many coders do) will have this subtle "what does the icon do" reaction. Please 
add the tool tips.

5) Graphic effects icon doesn't make any sense... looks like another pencil or 
something. Better to have a small circle with a gradient or something.

6) Entering custom props is messed up (already reported and confirm)...

7) Button icons icon doesn't make visual sense... find an icon that looks like 
an icon.

This is just the beginning. Far, Far from any kind or release candidate IMHO.

___
use-livecode mailing list
use-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: Edinburgh Aug 2-4, 2016

2016-03-02 Thread [-hh]

I use to look at the top of the current bugs list when I
report one. I have several more to report but stopped for
a while:
The list is simply too long. They will even have problems
to solve the bugs for the current 8.0-dp and to solve the
main problems of LC 6/7 to get (essentially) rid of that
versions. [So any further bug report that goes from LC8
back to LC6 will slow down the 'avantgarde development'.]

Externals.
I meant this last point with a ";-)". That was a hidden
proposal to you, who is now the new externals specialist
of LC.

People say, the last external-SDK was brilliant while it
was actual (was before I started with LC). I hoped you
would actualize that as long it makes sense to generate
and use externals.

Take a simple example I have read in some posts and what's
also in the 'old' externals-SDK: Imagedata.

It's not the manipulation that's really asked, mainly the
steps for us LC-'dummies', from getting the imagedata of
img 1, deliver it to the external, then say change ARGB
to AGBR, give it back to LC and set the imagedata of img 1.
You could use the old description, the helpers and your
adjusted templates for that.

AND: As soon as this is comparably fast in LC Builder, you
could document the same task, done there? Would be great!

Regards, Hermann

p.s. No misunderstanding here: I appreciate your externals
too, have a license ;-)

> > Hermann H. wrote:
> > What's going on here? 
> > Don't waste valuable time of the dev team. 
> > 
> >  Note  
> > Edinburgh Aug 2-4, 2016. 
> > 21 weeks and 5 days remaining just now. 
> > * 
> > 
> > I'm waiting for 8.0.1. 
> > I see a very long list of not-so-simple bugs. 
> > I'm waiting for an actual guide for externals 
> > (so that we can do by ourselves if nothing 
> > else is upcoming).
> Monte G. wrote:
> Do you want the conference sooner? 21 weeks is a while to 
> wait ;-)
> I have only experienced one LC conference so far and I 
> found it invaluable as a customer. With any luck I might 
> get to experience it from the other side as I expect it 
> will be just as invaluable from that side too. Getting 
> face to face time between engineers and the people they 
> are engineering for is seldom a waste of time. What do you 
> mean by nothing else coming? Have you seen my external 
> templates? https://github.com/montegoulding/livecode-
> external-templates  livecode-external-templates> They are for Xcode only at 
> the moment but the plan is to do Visual C++ and Linuxy 
> type things at some point… Maybe even some starter gyp 
> files if we want to get fancy. Contributions are welcome! 
> While LCB is the future there’s probably going to be a 
> while yet where externals are quicker and easier to 
> deliver features with. Cheers Monte 

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

Re: Edinburgh Aug 2-4, 2016

> On 3 Mar 2016, at 1:38 PM, -hh  wrote:
> 
> What's going on here?
> Don't waste valuable time of the dev team.
> 
>  Note 
> Edinburgh Aug 2-4, 2016.
> 21 weeks and 5 days remaining just now.
> *
> 
> I'm waiting for 8.0.1.
> I see a very long list of not-so-simple bugs.
> I'm waiting for an actual guide for externals
> (so that we can do by ourselves if nothing
> else is upcoming).

Do you want the conference sooner? 21 weeks is a while to wait ;-)

I have only experienced one LC conference so far and I found it invaluable as a 
customer. With any luck I might get to experience it from the other side as I 
expect it will be just as invaluable from that side too. Getting face to face 
time between engineers and the people they are engineering for is seldom a 
waste of time.

What do you mean by nothing else coming?

Have you seen my external templates? 
https://github.com/montegoulding/livecode-external-templates 

They are for Xcode only at the moment but the plan is to do Visual C++ and 
Linuxy type things at some point… Maybe even some starter gyp files if we want 
to get fancy. Contributions are welcome! While LCB is the future there’s 
probably going to be a while yet where externals are quicker and easier to 
deliver features with.

Cheers

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

Edinburgh Aug 2-4, 2016

2016-03-02 Thread -hh

What's going on here?
Don't waste valuable time of the dev team.

 Note 
Edinburgh Aug 2-4, 2016.
21 weeks and 5 days remaining just now.
*

I'm waiting for 8.0.1.
I see a very long list of not-so-simple bugs.
I'm waiting for an actual guide for externals
(so that we can do by ourselves if nothing
else is upcoming).

Hermann
===
Not sent from anybody's iPhone



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Edinburgh-Aug-2-4-2016-tp4701908.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: LC8DP15 feedback-IDE Issues


On 3/2/2016 7:11 PM, Mark Wieder wrote:

On 03/02/2016 04:09 PM, J. Landman Gay wrote:


I do favor functionality over appearance, but the sad fact is that new
users will base their first impressions of the product on how it looks.
These are some of the small details that matter for a professional
presentation.


Coming soon...

http://forums.livecode.com/viewtopic.php?f=9=26133#p135929

Holding off an official release because LC8 is still in flux.



Nice, I'd forgotten about that since I first saw it. The forum topic has 
feedback similar to ours here too.


--
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: LC8DP15 feedback-IDE Issues

2016-03-02 Thread Roland Huettmann

I really like this comment from Jacqueline.

Who does not eat with the eyes???

An ugly apple is not purchased even if much more tasty.

Roland


On Thu, Mar 3, 2016, 01:11 J. Landman Gay  wrote:

> On March 2, 2016 4:43:21 PM Richard Gaskin 
> wrote:
> >
> > Given this, I wonder if it makes more communicative sense to consider
> > moving the basic controls above the Widgets, closer to the always-used
> > Browse and Pointer icons.
>
>
> That was one of the things on my imaginary list. I'd like to see widgets at
> the bottom of the tool palette where they are out of the way, and where
> there is room for expansion as more become available. The primary hit
> regions will always be the browse and edit tools, and they need to be
> slightly larger than all the others and at the top where the user's eye
> will focus first.
>
> Widgets are also a little too large compared to the other icons, and too
> dark, which makes them visually distracting. They also don't match the rest
> of the interface. Most professional teams create a particular color palette
> early on that will represent their brand and all interface elements must
> adhere to it. Apple uses blue, Google centers around certain saturations of
> primary colors, etc.  LC should choose a color scheme and use it throughout
> to visually integrate all components.
>
> I'd avoid greys except as backgrounds. Very dark gray is okay for text but
> not so good for primary icons, it's too overbearing. Very light grey is
> difficult to see, and also implies less importance (temporary text in
> fields is often light grey, for example, to indicate the text will
> disappear when the user starts typing.)
>
> I do favor functionality over appearance, but the sad fact is that new
> users will base their first impressions of the product on how it looks.
> These are some of the small details that matter for a professional
> presentation.
>
> --
> 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: LC8DP15 feedback-IDE Issues


On 03/02/2016 02:08 PM, Peter TB Brett wrote:


Thanks -- that's a much more complete / thorough explanation than I
managed to give.  The Project Browser tries to fit a lot of features
into a small amount of space and I'm not convinced that we've found the
most efficient way to pack them.

In the core dev team we use the Project Browser a *lot* when working on
the IDE.  But we probably use it in a different way to the way many
people developing apps with the IDE use it.  We need to get more
feedback about what it does well (so we don't mess with those parts) and
clear feedback about specific things it does badly (so we can tweak them).


Well, the PreferencesUI stack has a panel for the Application Browser 
where you can set actions for various object types. But the Project 
Browser doesn't respect these settings. As a start, it might be nice to 
have these carry over so that when a user migrates from the AB to the PB 
and double-clicks a card, for instance, she doesn't have to wonder why 
the property inspector doesn't pop up.


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

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

Re: LC8DP15 feedback-IDE Issues


> On 3 Mar 2016, at 11:55 AM, Mark Wieder  wrote:
> 
> I'm curious, though, about the decision process that moved the cantSelect 
> property up the pantheon of properties out of the Property Inspector and into 
> the Project Browser. Is there something particular about cantSelect that 
> makes it more important than other properties?
> 
> Just curious because there are lots of properties I fiddle with regularly, 
> and I don't think I have ever set the cantSelect on an object.

It was in the application browser so it may be a case of it has always been 
there… that and if you can’t select an object it is just that bit harder to 
present its inspector…

Cheers

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

Re: LC8DP15 feedback-IDE Issues

> On 3 Mar 2016, at 11:09 AM, J. Landman Gay  wrote:
> 
> On March 2, 2016 4:43:21 PM Richard Gaskin  wrote:
>> 
>> Given this, I wonder if it makes more communicative sense to consider
>> moving the basic controls above the Widgets, closer to the always-used
>> Browse and Pointer icons.
> 
> 
> That was one of the things on my imaginary list. I'd like to see widgets at 
> the bottom of the tool palette where they are out of the way, and where there 
> is room for expansion as more become available. The primary hit regions will 
> always be the browse and edit tools, and they need to be slightly larger than 
> all the others and at the top where the user's eye will focus first.

I’m not sure if “out of the way” is exactly the direction the platform is 
heading. Once there are a much larger range of widgets we might not be using 
legacy controls that much any more. At the moment you can choose if you want to 
hide a group. I just hid the paint tools because I can’t remember ever using 
those… It would be nice if we could manage and order (top to bottom) our own 
groups of controls. I think this will be where we need to go when we have the 
“problem" of dealing with too many widgets. That and the ability to nest a set 
of controls into a popup button within another group of controls which was 
suggested earlier. As the LC 8.x series matures I expect these kinds of 
solutions will be a natural progression and likely arrive before or just in 
time for when they are needed.

> I'd avoid greys except as backgrounds. Very dark gray is okay for text but 
> not so good for primary icons, it's too overbearing. Very light grey is 
> difficult to see, and also implies less importance (temporary text in fields 
> is often light grey, for example, to indicate the text will disappear when 
> the user starts typing.)

I’d like to see this and a great many other colors in the UI be user settings 
along with an easy way to share such settings between users.

Cheers

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

Re: LC8DP15 feedback-IDE Issues


On 03/02/2016 04:09 PM, J. Landman Gay wrote:


I do favor functionality over appearance, but the sad fact is that new
users will base their first impressions of the product on how it looks.
These are some of the small details that matter for a professional
presentation.


Coming soon...

http://forums.livecode.com/viewtopic.php?f=9=26133#p135929

Holding off an official release because LC8 is still in flux.

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

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

Re: LC8DP15 feedback-IDE Issues


On 03/02/2016 02:21 PM, panagiotis merakos wrote:

The "mysterious lock icon with a 'Show' tootip" is setting the cantSelect
property of the control. The tooltip should reflect that though, so we have
to update it.


Ah. Thanks.

I'm curious, though, about the decision process that moved the 
cantSelect property up the pantheon of properties out of the Property 
Inspector and into the Project Browser. Is there something particular 
about cantSelect that makes it more important than other properties?


Just curious because there are lots of properties I fiddle with 
regularly, and I don't think I have ever set the cantSelect on an object.


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

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

Re: LC8DP15 feedback-IDE Issues


On March 2, 2016 4:43:21 PM Richard Gaskin  wrote:


Given this, I wonder if it makes more communicative sense to consider
moving the basic controls above the Widgets, closer to the always-used
Browse and Pointer icons.



That was one of the things on my imaginary list. I'd like to see widgets at 
the bottom of the tool palette where they are out of the way, and where 
there is room for expansion as more become available. The primary hit 
regions will always be the browse and edit tools, and they need to be 
slightly larger than all the others and at the top where the user's eye 
will focus first.


Widgets are also a little too large compared to the other icons, and too 
dark, which makes them visually distracting. They also don't match the rest 
of the interface. Most professional teams create a particular color palette 
early on that will represent their brand and all interface elements must 
adhere to it. Apple uses blue, Google centers around certain saturations of 
primary colors, etc.  LC should choose a color scheme and use it throughout 
to visually integrate all components.


I'd avoid greys except as backgrounds. Very dark gray is okay for text but 
not so good for primary icons, it's too overbearing. Very light grey is 
difficult to see, and also implies less importance (temporary text in 
fields is often light grey, for example, to indicate the text will 
disappear when the user starts typing.)


I do favor functionality over appearance, but the sad fact is that new 
users will base their first impressions of the product on how it looks. 
These are some of the small details that matter for a professional 
presentation.


--
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: LC8DP15 feedback-IDE Issues

2016-03-02 Thread Roger Eller

On Wed, Mar 2, 2016 at 5:42 PM, Richard Gaskin 
wrote:

> I haven't used the Tools palette in years, but this conversation prompted
> me to take a gander.
>
> I wonder if having the Widgets above the basic controls is the best place
> for them.
>
>
Tools palette.  Widgets palette.  Separate and simple, with room to grow.

~Roger
___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues

2016-03-02 Thread Peter Haworth

An lcstackbrowser user requested the "single tool with option to set the
style "some time ago and I implemented it.  It takes a lot less screen
space and I think is useful for experienced users but might be a little
daunting for new users.

On Wed, Mar 2, 2016 at 2:56 PM Devin Asay  wrote:

>
> > On Mar 2, 2016, at 3:42 PM, Richard Gaskin 
> wrote:
> >
> > I haven't used the Tools palette in years, but this conversation
> prompted me to take a gander.
> >
> > I wonder if having the Widgets above the basic controls is the best
> place for them.
> >
> > I tend to think of UIs as telling a story, and sometimes that can
> include communicating the importance of things by their placement.
> >
> > Having the Browse and Pointer tools at the top, and giving them the
> largest target area, seem like good choices given their very central role
> throughout development.
> >
> > But I'll spend weeks at a time adding only buttons and fields to cards,
> only occasionally using anything else.
> >
> > The Widgets, while both useful and cool, are less commonly used. Indeed,
> most projects will use most of them once or twice if at all.
> >
> > Given this, I wonder if it makes more communicative sense to consider
> moving the basic controls above the Widgets, closer to the always-used
> Browse and Pointer icons.
> >
> > I might even go so far as to consider moving the graphics above Widgets
> as well, to be consistent in terms of frequency of use, though I recognize
> that the paint tools are perhaps the least commonly used of all, and they
> make sense being grouped near the drawing tools, so perhaps leaving that
> whole set at the bottom is fine, and we could just consider moving the
> basic tools (buttons, fields, and such) above the Widgets.
> >
> > Any opinions on this?
>
> I’m with you on this, Richard. The tools palette is getting very cluttery,
> and could stand a tidying up. For instance, right now there are:
> - 5 button tools
> - 5 field tools
> - 5 menu button tools
> - 4 scrollbar tools
>
> Would it make sense to fold each object class into a single tool with an
> option to set a different style of each object as the default? Sort of how
> Photoshop’s tools palette lets you select the type of marquee tool (or
> shape tool, or magic wand tool, etc. etc.) that is the default.
>
> >
> >
> > PS: What happens when one has 100 Widgets installed?
>
> Right. Now you can choose to hide or show entire sections of the tools
> palette. (Although I had somehow completely missed that option, and only
> noticed it when someone here referred to it.)
>
> I’d like to see an option to display only selected widgets (or other
> tools) on the tools palette.
>
>
> 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: Set the Opacity of a Button Background

2016-03-02 Thread Sannyasin Brahmanathaswami

@ Scott

Thank you.


Actually all these other methods have their use cases. Yes, am familiar with 
using other controls as "buttons" anything with a mouseUp script will do the 
job in 80% of the cases.

BR


On March 1, 2016 at 11:26:57 AM, Scott Rossi 
(sc...@tactilemedia.com) wrote:

Another option similar to Randy's is to create an image tile -- for
example, a 48x48 white PNG that's 50% opaque -- and assign this as the
backPattern of the button. Using this method you can scale the button to
any size and the translucency will fill accordingly. You can also assign
a separate icon if desired.

Unless you REALLY need the properties of a button control, you can also
consider other objects to act as buttons, such as graphics, where you can
employ a translucent gradient fill to the control, or fields, where you
can create the effect of a label that has multiple text styles. There are
several options for create button-style controls.
___
use-livecode mailing list
use-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: Set the Opacity of a Button Background

2016-03-02 Thread Sannyasin Brahmanathaswami

Aloha Paul:

wow... awesome.. you did it! this works perfectly as needed.

So I can just set up a template button and store this and create all new 
buttons according.

Outstanding.. Big Mahalo from Hawaii

BR

On March 1, 2016 at 11:26:57 AM, Scott Rossi 
(sc...@tactilemedia.com) wrote:

By adjusting some colour values and the ink mode I could achieve what I think 
you are looking for, however I may have misunderstood, because I don’t quite 
understand the bit about having 50% opacity of a clear background!

Link to demo stack with my interpretation: 
https://www.dropbox.com/s/xhjqlx0zhdeyq2f/Button%20Demo.livecode?dl=0

HTH

Paul
___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues

I haven't used the Tools palette in years, but this conversation 
prompted me to take a gander.


I wonder if having the Widgets above the basic controls is the best 
place for them.


I tend to think of UIs as telling a story, and sometimes that can 
include communicating the importance of things by their placement.


Having the Browse and Pointer tools at the top, and giving them the 
largest target area, seem like good choices given their very central 
role throughout development.


But I'll spend weeks at a time adding only buttons and fields to cards, 
only occasionally using anything else.


The Widgets, while both useful and cool, are less commonly used. 
Indeed, most projects will use most of them once or twice if at all.


Given this, I wonder if it makes more communicative sense to consider 
moving the basic controls above the Widgets, closer to the always-used 
Browse and Pointer icons.


I might even go so far as to consider moving the graphics above Widgets 
as well, to be consistent in terms of frequency of use, though I 
recognize that the paint tools are perhaps the least commonly used of 
all, and they make sense being grouped near the drawing tools, so 
perhaps leaving that whole set at the bottom is fine, and we could just 
consider moving the basic tools (buttons, fields, and such) above the 
Widgets.


Any opinions on this?


PS: What happens when one has 100 Widgets installed?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: LC8DP15 feedback-IDE Issues

2016-03-02 Thread Terry Judd

On 3/03/2016 9:26 am, "use-livecode on behalf of Roger Eller"
 wrote:

>Tools pallette (not menu).  Yes, the widget icons are gray, but the new
>flat icons across the top (Inspector, Code, Message Box, etc.) are pure
>black.  I would rather see a more consistent appearance for all icons in
>the IDE.

I think you¹re right. I¹m more concerned with how things work than how
they look but there is a bit on inconsistency around the intensity of
black/grey used in icons - and text - across the menubar, tool palette,
stack/card/object inspector and project browser. As far as the latest
incarnation of the project browser goes I quite like it - certainly enough
to not really miss the application browser now it has gone. The selection
indicator (dotted outline) is useful but it doesn¹t immediately update
when you select an object/control by double-clicking an item in the
browser.

Terry...

___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues

2016-03-02 Thread Roger Eller

On Wed, Mar 2, 2016 at 4:57 PM, Peter TB Brett 
wrote:

> On 02/03/2016 21:45, Roger Eller wrote:
>
>>
>> I very much dislike those super dark icons in the new IDE.  Especially
>> when
>> the icons in the Tools menu are a completely different shade of gray.
>> They
>> should be consistent across the IDE.  I also dislike jerks.
>>
>
> Thank you.
>
> Which specific "icons in the Tools menu" are you referring to?  I don't
> seem to have any icons in the "Tools" menu on my system.  Do you mean the
> widget icons in the upper half of the Tools palette, or the miniature
> pictures of controls in the in the lower half of the tools palette, or
> should I be looking somewhere else entirely?
>
> It might be quite straightforward to tweak the colour used to draw the
> widget icons, so it might be a quick fix.
>
> Peter
>
> --
> Dr Peter Brett 
> LiveCode Open Source Team
>

Tools pallette (not menu).  Yes, the widget icons are gray, but the new
flat icons across the top (Inspector, Code, Message Box, etc.) are pure
black.  I would rather see a more consistent appearance for all icons in
the IDE.
___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues

2016-03-02 Thread panagiotis merakos

The "mysterious lock icon with a 'Show' tootip" is setting the cantSelect
property of the control. The tooltip should reflect that though, so we have
to update it.

Panos
--

On Thu, Mar 3, 2016 at 12:08 AM, Peter TB Brett 
wrote:

> On 02/03/2016 16:28, Mark Wieder wrote:
>
>> On 03/01/2016 11:39 PM, Peter TB Brett wrote:
>>
>> You can double click on an item in the Project Browser to select it on
>>> the card.
>>>
>>
>> Empirically...
>> You can double click on an item's icon to do that.
>> Double-clicking on the name allows you to edit the name.
>> Single-clicking a line in the PB has no appreciable effect (other than
>> highlighting the line in the PB).
>>
>> Double-clicking the mysterious lock icon with a "Show" tooltip also
>> seems to select the highlighted object.
>>
>
> Thanks -- that's a much more complete / thorough explanation than I
> managed to give.  The Project Browser tries to fit a lot of features into a
> small amount of space and I'm not convinced that we've found the most
> efficient way to pack them.
>
> In the core dev team we use the Project Browser a *lot* when working on
> the IDE.  But we probably use it in a different way to the way many people
> developing apps with the IDE use it.  We need to get more feedback about
> what it does well (so we don't mess with those parts) and clear feedback
> about specific things it does badly (so we can tweak them).
>
> I'm not entirely sure what the "mysterious lock icon with a 'Show' tootip"
> is for... I haven't used it yet.
>
> Peter
>
> --
> Dr Peter Brett 
> LiveCode Open Source Team
>
> LiveCode 2016 Conference https://livecode.com/edinburgh-2016/
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC8DP15 feedback-IDE Issues


On 02/03/2016 16:28, Mark Wieder wrote:

On 03/01/2016 11:39 PM, Peter TB Brett wrote:


You can double click on an item in the Project Browser to select it on
the card.


Empirically...
You can double click on an item's icon to do that.
Double-clicking on the name allows you to edit the name.
Single-clicking a line in the PB has no appreciable effect (other than
highlighting the line in the PB).

Double-clicking the mysterious lock icon with a "Show" tooltip also
seems to select the highlighted object.


Thanks -- that's a much more complete / thorough explanation than I 
managed to give.  The Project Browser tries to fit a lot of features 
into a small amount of space and I'm not convinced that we've found the 
most efficient way to pack them.


In the core dev team we use the Project Browser a *lot* when working on 
the IDE.  But we probably use it in a different way to the way many 
people developing apps with the IDE use it.  We need to get more 
feedback about what it does well (so we don't mess with those parts) and 
clear feedback about specific things it does badly (so we can tweak them).


I'm not entirely sure what the "mysterious lock icon with a 'Show' 
tootip" is for... I haven't used it yet.


Peter

--
Dr Peter Brett 
LiveCode Open Source Team

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

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

Re: LC8DP15 feedback-IDE Issues


On 02/03/2016 21:45, Roger Eller wrote:


I very much dislike those super dark icons in the new IDE.  Especially when
the icons in the Tools menu are a completely different shade of gray.  They
should be consistent across the IDE.  I also dislike jerks.


Thank you.

Which specific "icons in the Tools menu" are you referring to?  I don't 
seem to have any icons in the "Tools" menu on my system.  Do you mean 
the widget icons in the upper half of the Tools palette, or the 
miniature pictures of controls in the in the lower half of the tools 
palette, or should I be looking somewhere else entirely?


It might be quite straightforward to tweak the colour used to draw the 
widget icons, so it might be a quick fix.


Peter

--
Dr Peter Brett 
LiveCode Open Source Team

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

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

Re: LC8DP15 feedback-IDE Issues

2016-03-02 Thread Roger Eller

On Wed, Mar 2, 2016 at 4:37 PM, Peter TB Brett 
wrote:

> On 02/03/2016 17:23, RM wrote:
>
>> +1
>>
>
> Please don't do this.  If you don't have anything substantive to
> contribute to the conversation, please don't waste the inbox space of
> hundreds of mailing list users.
>
> Peter
>
> --
> Dr Peter Brett 
> LiveCode Open Source Team
>

I very much dislike those super dark icons in the new IDE.  Especially when
the icons in the Tools menu are a completely different shade of gray.  They
should be consistent across the IDE.  I also dislike jerks.

~Roger
___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues


On 02/03/2016 17:23, RM wrote:

+1


Please don't do this.  If you don't have anything substantive to 
contribute to the conversation, please don't waste the inbox space of 
hundreds of mailing list users.


Peter

--
Dr Peter Brett 
LiveCode Open Source Team

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

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

Those Black and White icons in the revMenubar stack in LC 8

Here's my hack to replace them with the previous multicoloured ones, at 
your own

risk:

http://forums.livecode.com/viewtopic.php?f=9=26506=139069#p139069

Love, 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: LC8DP15 feedback-IDE Issues


On 03/02/2016 11:53 AM, J. Landman Gay wrote:


Oh yes, absolutely, and I've found the team to be remarkably responsive.
I was very impressed with Ali, he really listened and was intent on
making the IDE as perfect as possible. I wanted to hug him, I was that
happy.


And not just Ali, the whole team is very responsive. I'll continue to 
carp about things here as necessary, but I'm very impressed with the 
progress this huge project is making.




That said, there are certain established expectations for how computer
interfaces work,


Sometimes it's necessary to break the rules, but otherwise I think the 
Principle of Least Surprise would dictate that we would go with whatever 
the user expects from the OS guidelines.


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

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

Re: LC8DP15 feedback-IDE Issues


On 03/02/2016 12:10 PM, RM wrote:


I am actually quite curious as to why the Livecode team decided to
change the Properties palette so radically.




To be fair about that, the current/previous/whatever property inspector 
leaves a lot to be desired. There's been much complaining over the 
years, and not just by the two of us. But I find the newer PI not so 
much a radical change from the earlier one. I'm not averse to radical 
changes, but it seems like the older PI in a new bottle. And the new 
bottle doesn't seem like a big step forward.


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

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

Re: LC8DP15 feedback-IDE Issues




On 2.03.2016 21:53, J. Landman Gay wrote:

On 3/2/2016 10:04 AM, Mark Waddingham wrote:

Just to clarify my comment, what I was trying to point out (in an
attempt at a humourous way) is that invoking a 'interface designer' does
not magically mean you end up with a user interface which any one person
agrees with, or actually works for all use-cases.


Oh yes, absolutely, and I've found the team to be remarkably 
responsive. I was very impressed with Ali, he really listened and was 
intent on making the IDE as perfect as possible. I wanted to hug him, 
I was that happy.


That said, there are certain established expectations for how computer 
interfaces work, how people read/scan written material, how layouts 
are most easily accessed, and so forth. Every time a tool breaks any 
of those expectations the user will be frustrated or annoyed, even if 
it is just momentary. That's what happened to me when I recently 
started to explore the new IDE.


I have very strong motivations to use LC, it's my whole business. But 
I was frustrated enough that I went back to vs 7 after each attempt 
with 8. I will learn it eventually, and I'm willing to do so, but I 
wonder about the new users we want to court. If they need to read 
documentation (currently lacking) and expend a lot of effort to learn 
how a tool works ("selections aren't as you'd expect, we do it this 
way,") they won't bother. We'll lose them.


I could make a list if that would help. There are too many small 
things to write reports about each one, but I do think that attention 
to these little details would improve the user experience. The team 
may think my criticisms are trivial, but they did cause me trouble. 
And I very much want new users to intuit the IDE immediately and get 
drawn in. Surely making them fight their instincts can't be productive.




I am actually quite curious as to why the Livecode team decided to 
change the Properties palette

so radically.

R.

___
use-livecode mailing list
use-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: Request: Markdown functions

mergMarkdown is my external that does Markdown to HTML. It is fully cross 
platform and MIT licensed. It is based on the sundown library which is also MIT 
licensed. I don’t have anything that can do the reverse sorry…

> On 3 Mar 2016, at 5:27 AM, Richard Gaskin  wrote:
> 
> I need two functions for a community project I'm working on:
> 
> MarkdownToHtmltext -- converts Github Markdown the LC's htmlText
> 
> HtmltextToMarkdown -- converts content and the subset of relevant
>  text styling attributes LC fields offer into
>  Github-flavored Markdown
> 
> These need to be available under either GPL or GPL-compatible license.
> 
> If you have such things please point me to them.
> 
> If not I'll adapt some code I wrote for my WebMerge product and post it on 
> Github under GPLv3.
> 
> -- 
> 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


___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues


On 3/2/2016 10:04 AM, Mark Waddingham wrote:

Just to clarify my comment, what I was trying to point out (in an
attempt at a humourous way) is that invoking a 'interface designer' does
not magically mean you end up with a user interface which any one person
agrees with, or actually works for all use-cases.


Oh yes, absolutely, and I've found the team to be remarkably responsive. 
I was very impressed with Ali, he really listened and was intent on 
making the IDE as perfect as possible. I wanted to hug him, I was that 
happy.


That said, there are certain established expectations for how computer 
interfaces work, how people read/scan written material, how layouts are 
most easily accessed, and so forth. Every time a tool breaks any of 
those expectations the user will be frustrated or annoyed, even if it is 
just momentary. That's what happened to me when I recently started to 
explore the new IDE.


I have very strong motivations to use LC, it's my whole business. But I 
was frustrated enough that I went back to vs 7 after each attempt with 
8. I will learn it eventually, and I'm willing to do so, but I wonder 
about the new users we want to court. If they need to read documentation 
(currently lacking) and expend a lot of effort to learn how a tool works 
("selections aren't as you'd expect, we do it this way,") they won't 
bother. We'll lose them.


I could make a list if that would help. There are too many small things 
to write reports about each one, but I do think that attention to these 
little details would improve the user experience. The team may think my 
criticisms are trivial, but they did cause me trouble. And I very much 
want new users to intuit the IDE immediately and get drawn in. Surely 
making them fight their instincts can't be productive.


--
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: LC8DP15 feedback-IDE Issues




On 2.03.2016 19:13, Mark Wieder wrote:

On 03/02/2016 08:04 AM, Mark Waddingham wrote:


I do think this has been occurring quite healthily recently with regards
LC8 and, indeed, some of the tweaks that have been made to the project
browser (in particular its selection / highlighting logic) have been a
direct result of discussion with individuals who have pointed out
certain flaws and I do hope that will continue.


I'm sure that over time the new paradigms will become ingrained and 
the former muscle memory will fade.


The tiny gray-on-gray icons, though, are another matter. I shudder to 
think of the universe in which someone thought that was a Good Idea. I 
realize that this was no doubt the result of careful A-B testing with 
developer usability focus groups, but nonetheless...


I've been mucking around in the IDE and seem unable to find the icons, 
and assume that, like the new BW menuBar icons they are stored "off 
campus" and referenced:


But I am bu**ered if I can find them.

Richmond.


The eldritch gods are starting to awaken.
Ph'nglui mglw'nafh C'thulhu R'lyeh wgah'nagl fhtagn.




___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues

Mark Wieder wrote:

> The tiny gray-on-gray icons, though, are another matter. I shudder to
> think of the universe in which someone thought that was a Good Idea.

At the top of the window or somewhere else?

At once point I'd submitted a request to use the large icon option for 
the top panel as the default, and that was implemented (thanks, Ali!).

So if you're seeing smaller icons there that's a regression.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web

 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Request: Markdown functions


I need two functions for a community project I'm working on:

MarkdownToHtmltext -- converts Github Markdown the LC's htmlText

HtmltextToMarkdown -- converts content and the subset of relevant
  text styling attributes LC fields offer into
  Github-flavored Markdown

These need to be available under either GPL or GPL-compatible license.

If you have such things please point me to them.

If not I'll adapt some code I wrote for my WebMerge product and post it 
on Github under GPLv3.


--
 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: LC8DP15 feedback-IDE Issues




On 2.03.2016 19:13, Mark Wieder wrote:

On 03/02/2016 08:04 AM, Mark Waddingham wrote:


I do think this has been occurring quite healthily recently with regards
LC8 and, indeed, some of the tweaks that have been made to the project
browser (in particular its selection / highlighting logic) have been a
direct result of discussion with individuals who have pointed out
certain flaws and I do hope that will continue.


I'm sure that over time the new paradigms will become ingrained and 
the former muscle memory will fade.


The tiny gray-on-gray icons, though, are another matter. I shudder to 
think of the universe in which someone thought that was a Good Idea. I 
realize that this was no doubt the result of careful A-B testing with 
developer usability focus groups, but nonetheless...


+1

Richmond



The eldritch gods are starting to awaken.
Ph'nglui mglw'nafh C'thulhu R'lyeh wgah'nagl fhtagn.




___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues


On 03/02/2016 09:09 AM, Tore Nilsen wrote:

Have you tried looking for it in LC 8, which seems to be the version discussed 
in this thread?


Read the previous post.

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

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

Re: LC8DP15 feedback-IDE Issues


On 03/02/2016 09:05 AM, John Dixon wrote:


Anyone in Edinburgh considered asking Scott Rossi how much time he has on his 
hands ? :-)


LOL. +1

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

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

Re: LC8DP15 feedback-IDE Issues


On 03/02/2016 08:04 AM, Mark Waddingham wrote:


I do think this has been occurring quite healthily recently with regards
LC8 and, indeed, some of the tweaks that have been made to the project
browser (in particular its selection / highlighting logic) have been a
direct result of discussion with individuals who have pointed out
certain flaws and I do hope that will continue.


I'm sure that over time the new paradigms will become ingrained and the 
former muscle memory will fade.


The tiny gray-on-gray icons, though, are another matter. I shudder to 
think of the universe in which someone thought that was a Good Idea. I 
realize that this was no doubt the result of careful A-B testing with 
developer usability focus groups, but nonetheless...


The eldritch gods are starting to awaken.
Ph'nglui mglw'nafh C'thulhu R'lyeh wgah'nagl fhtagn.

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

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

Re: LC8DP15 feedback-IDE Issues

2016-03-02 Thread Tore Nilsen

Have you tried looking for it in LC 8, which seems to be the version discussed 
in this thread?

Tore


> 2. mar. 2016 kl. 18.02 skrev Mark Wieder :
> 
> On 03/02/2016 08:23 AM, Peter TB Brett wrote:
>> On 02/03/2016 16:15, Mark Wieder wrote:
>>> On 03/01/2016 11:39 PM, Peter TB Brett wrote:
>>> 
 You can double click on an item in the Project Browser to select it on
 the card.
>>> 
>>> OK - that's getting pinned on the wall as well.
>>> Is this stuff documented somewhere?
>> 
>> See http://quality.livecode.com/show_bug.cgi?id=16609
>> 
>>> The User Guide is missing in action (bug 17054) and the "All User
>>> Guides" menu item just opens the dictionary which, at least on linux, is
>>> somewhat less than actually functional.
>> 
>> It opens the "Guides" tab of the dictionary stack, which on platforms
>> where the browser widget works, displays the user guides (funnily enough).
> 
> OK. Fair enough. So I opened the User Guide for LC 7.1.2, and that brought up 
> the pdf (User Guide 4.5 - Revision 19), which has no mention of the Project 
> Browser.
> 
> In 7.1.2, selecting "All Guides" goes to the LC website, where I can select 
> the "Beginners-Guide" (not sure why the hyphenation), then control-F to 
> search for "Project". There's a single image there, and I assume that this is 
> the same content that would appear if there were an actual User Guide pdf. I 
> do see some explanatory text, but nothing like the discussions here. And I'm 
> still mystified about the lock icon with the tooltip of "Show" and the 
> explanation of "Selectability".
> 
> -- 
> Mark Wieder
> ahsoftw...@gmail.com 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com 
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode 
> 
___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues

2016-03-02 Thread John Dixon


> 
> Indeed - perfection is a journey, not a destination.
> 
> Just to clarify my comment, what I was trying to point out (in an 
> attempt at a humourous way) is that invoking a 'interface designer' does 
> not magically mean you end up with a user interface which any one person 
> agrees with, or actually works for all use-cases. This does not mean to 
> say that having a full time experienced dev-tool oriented UX designer 
> wouldn't help immeasurably with the evolution of LiveCode's interface, 
> but it certainly wouldn't be a magic wand which makes things better 
> overnight.
> 
> My observation over the years that regardless of the UX design 
> experience of the person designing things developing a good UI comes 
> down to dialog between the designer(s) and the user(s); and as with all 
> things it generally comes down to compromise.

Anyone in Edinburgh considered asking Scott Rossi how much time he has on his 
hands ? :-)


  
___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues


On 03/02/2016 08:23 AM, Peter TB Brett wrote:

On 02/03/2016 16:15, Mark Wieder wrote:

On 03/01/2016 11:39 PM, Peter TB Brett wrote:


You can double click on an item in the Project Browser to select it on
the card.


OK - that's getting pinned on the wall as well.
Is this stuff documented somewhere?


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


The User Guide is missing in action (bug 17054) and the "All User
Guides" menu item just opens the dictionary which, at least on linux, is
somewhat less than actually functional.


It opens the "Guides" tab of the dictionary stack, which on platforms
where the browser widget works, displays the user guides (funnily enough).


OK. Fair enough. So I opened the User Guide for LC 7.1.2, and that 
brought up the pdf (User Guide 4.5 - Revision 19), which has no mention 
of the Project Browser.


In 7.1.2, selecting "All Guides" goes to the LC website, where I can 
select the "Beginners-Guide" (not sure why the hyphenation), then 
control-F to search for "Project". There's a single image there, and I 
assume that this is the same content that would appear if there were an 
actual User Guide pdf. I do see some explanatory text, but nothing like 
the discussions here. And I'm still mystified about the lock icon with 
the tooltip of "Show" and the explanation of "Selectability".


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

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

Re: Open source, closed source, and the value of code

2016-03-02 Thread Robert Mann

yap.. in that respect.. with all respect to live code and every team member..
I honestly earnastly was astonished by the virulence of the clause
forbidding any tier to take a community work and turn it into a commercial
application.

I sort of "naively" believed that there was quite a good positive ecosystem
between community hobbyist or a specially updated desktop only hobiist
version because things have become so complex that to fine tune a hobbits
app into an iOS app a guy who already is experienced in bringing an app to
IOs  could well be a very good thing.

But then it's.. none of my business...
I just needed to know where to stand on.



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701870.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: LC8DP15 feedback-IDE Issues


On 2016-03-02 16:44, Richard Gaskin wrote:

Mark Waddingham wrote:


On 2016-03-02 06:46, J. Landman Gay wrote:

I confess my first reaction was that LC needs an interface designer.


Ah - yes - those magical 'interface designers' who you just ask to
give you the perfect UI that *everyone* immediately understands and
knows how to use and works exactly how each individual wants it to
work ;)


There is no best; there is always better.


Indeed - perfection is a journey, not a destination.

Just to clarify my comment, what I was trying to point out (in an 
attempt at a humourous way) is that invoking a 'interface designer' does 
not magically mean you end up with a user interface which any one person 
agrees with, or actually works for all use-cases. This does not mean to 
say that having a full time experienced dev-tool oriented UX designer 
wouldn't help immeasurably with the evolution of LiveCode's interface, 
but it certainly wouldn't be a magic wand which makes things better 
overnight.


My observation over the years that regardless of the UX design 
experience of the person designing things developing a good UI comes 
down to dialog between the designer(s) and the user(s); and as with all 
things it generally comes down to compromise.


I do think this has been occurring quite healthily recently with regards 
LC8 and, indeed, some of the tweaks that have been made to the project 
browser (in particular its selection / highlighting logic) have been a 
direct result of discussion with individuals who have pointed out 
certain flaws and I do hope that will continue.


Warmest Regards,

Mark.

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

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

Re: Open source, closed source, and the value of code

Mark Wieder wrote:

> Yesterday I was handed an nda to sign. There was a clause (yes,
> I actually do read these things) that started "Neither party will
> publicly disclose the existence of this document..." I recoiled,
> this caused a huddle of half a dozen people for several minutes,
> the company lawyer came over and sheepishly crossed out the
> paragraph, and we went on.

Good lawyer.

I know a lot of developers starting out who get timid about asking for 
contract changes. I had the good fortune of cutting my teeth in that 
area under an excellent manager who taught me about doing contract 
review with our clients' corporate counsel with this:

"Their job is to ask for the world.  Your job is to ask for half of it 
back."

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web

 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Summary: Open source, closed source, and the value of code

2016-03-02 Thread Robert Mann

hi, thanks for confirming what I guess is motherships point of view.
That was'n at all crystal clear, but you now made it clear : 
no split license what so ever for live code community.

<< Absolutely every piece of software is derived from a set of files which 
can be considered the 'source code' - whether that be actual 
source-code, artwork, music, prose, or whatever - which is then 
processed using some set of tools to produce something that you can 
actually run and use - this is always 100% crystal clear. >>

It might be a good thing for the community to append your examples of when
to use Community and where to use Closed/commercial with that case with at
least the 2 following cases :

1) I intend to include in a community stack content that is outside of the
GPL scope => please use commercial version
2) i intend to test an app in the community by some distribution to some
public ==> please use commercial version

Finaly, your precise wording is quite wide, and that raises a question :

 ?? Does that paragraph cited above mean that live code would regard the
strategy of deploying a community "reader app" for a certain type of
separate content not welcomed as being outside the scope of the GPL mantra
as they see it??? Thanks for confirming that.

Robert




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Summary-Open-source-closed-source-and-the-value-of-code-tp4701858p4701867.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: LC8DP15 feedback-IDE Issues


On 03/01/2016 11:39 PM, Peter TB Brett wrote:


You can double click on an item in the Project Browser to select it on
the card.


Empirically...
You can double click on an item's icon to do that.
Double-clicking on the name allows you to edit the name.
Single-clicking a line in the PB has no appreciable effect (other than 
highlighting the line in the PB).


Double-clicking the mysterious lock icon with a "Show" tooltip also 
seems to select the highlighted object.


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

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

Re: LC8DP15 feedback-IDE Issues


On 02/03/2016 16:15, Mark Wieder wrote:

On 03/01/2016 11:39 PM, Peter TB Brett wrote:


You can double click on an item in the Project Browser to select it on
the card.


OK - that's getting pinned on the wall as well.
Is this stuff documented somewhere?


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


The User Guide is missing in action (bug 17054) and the "All User
Guides" menu item just opens the dictionary which, at least on linux, is
somewhat less than actually functional.


It opens the "Guides" tab of the dictionary stack, which on platforms 
where the browser widget works, displays the user guides (funnily enough).


   Peter

--
Dr Peter Brett 
LiveCode Open Source Team

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

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

Re: Open source, closed source, and the value of code


On 03/01/2016 09:35 PM, J. Landman Gay wrote:


I have been trying to follow this thread, not always successfully, but
common sense tells me:


Heh.
Common sense in a discussion of legal things.

Yesterday I was handed an nda to sign. There was a clause (yes, I 
actually do read these things) that started "Neither party will publicly 
disclose the existence of this document..." I recoiled, this caused a 
huddle of half a dozen people for several minutes, the company lawyer 
came over and sheepishly crossed out the paragraph, and we went on.


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

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

Re: LC8DP15 feedback-IDE Issues


On 03/01/2016 11:39 PM, Peter TB Brett wrote:


You can double click on an item in the Project Browser to select it on
the card.


OK - that's getting pinned on the wall as well.
Is this stuff documented somewhere?

The User Guide is missing in action (bug 17054) and the "All User 
Guides" menu item just opens the dictionary which, at least on linux, is 
somewhat less than actually functional.


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

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

Re: OS X - how to write to a file associated as a Unix executable

2016-03-02 Thread Glen Bojsza

Thanks Mark

That did it ... both methods of filetype allowed me to correctly get the
chmod results I was looking for.



On Tue, Mar 1, 2016 at 2:54 AM, Mark Waddingham  wrote:

> On 2016-03-01 02:06, Glen Bojsza wrote:
>
>> What I am trying to do is within a LC application
>>
>> 1. put field "mytest" into URL "binfile:~/race"
>>
>> This creates a file called race in the ~/ directory.
>>
>> The problem is that when you do a chmod +rw race the file is still
>> recognized as textedit file and NOT a UNIX executable.
>>
>> When you look at a file created with LC and chmod  verses a file created
>> with textmate and chmod you can see the differences in the finder or get
>> info on both files and see the difference.
>>
>
> Try doing:
>
> set the fileType to ""
>
> or
>
> set the fileType to empty
>
> Before saving the file from LC.
>
> The default setting is "ttxtTEXT". I believe, these days, that Mac first
> looks at the file extension and then falls back to the filetype. As the
> engine is explicitly setting the fileType of saved files (by default) to
> text, the OS will pick up any files without extensions as text files.
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> 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: LC8DP15 feedback-IDE Issues

Mark Waddingham wrote:

> On 2016-03-02 06:46, J. Landman Gay wrote:
>> I confess my first reaction was that LC needs an interface designer.
>
> Ah - yes - those magical 'interface designers' who you just ask to
> give you the perfect UI that *everyone* immediately understands and
> knows how to use and works exactly how each individual wants it to
> work ;)

There is no best; there is always better.

We could use reductio ad absurdum to trivialize any profession.  Where's 
the magical software engineer who can deliver perfect bug-free code on 
schedule every time? ;) I've never heard of such a thing; ours is an 
imperfect world defined by constraints.

UX professionals are moving fast up the org charts at some of the most 
profitable companies in the world because their work contributes to 
directly measurable sales growth.  In some companies UX is a strategic 
C-suite position.

Of course it's not possible to produce a single UI that will satisfy all 
possible use cases.

But I do hope we all keep an open mind and actively listen to 
suggestions from users.  Not all of them will be actionable, and some of 
them might not be all that useful, but many of them can lead to insights 
into ways to improve the LiveCode experience, and that benefits us all.

Hopefully one day LiveCode Ltd. will grow large enough to be able to 
hire a UX strategist, who could contribute to refining the UI as well as 
onboarding materials, marketing assets, and more, reducing ever further 
the distance between "What is this?" and "Yes I want this!"

The company is chock full of uncommonly smart people, but not everyone 
is a specialist in everything.  Let's leave the door open the continual 
improvement in design.

I know firsthand the team has been very receptive to good ideas well 
presented in enhancement requests.  So all I'm saying here is let's keep 
our ears and minds open as we continue our journey forward.

Corning Gorilla Glass was an interesting technology sitting on the shelf 
in their labs until a crazy UX strategist called them up and suggested 
it might be useful on a phone.  We just never know where the next useful 
idea might come from.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web

 ambassa...@fourthworld.comhttp://www.FourthWorld.com

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

Re: Hey-Ho and Off We Go with HTML5

2016-03-02 Thread Matt Maier

You could try out the free tier of services like http://www.formmail.com/
or HTTP://www.SE dgrid.com
On Mar 2, 2016 00:30, "RM"  wrote:

>
>
> On 2.03.2016 10:18, Mark Waddingham wrote:
>
>> On 2016-03-02 09:01, RM wrote:
>>
>>> Preferably this would be WITHOUT the message having to go via the
>>> client's e-mail system as:
>>>
>>> 1.  The message should be anonymous.
>>>
>>> 2.  The end-user may have no e-mail client configured.
>>>
>>
>> Okay so there in terms of what you will be able to do in this regard with
>> the HTML5 engine there are two feasible options as far as I can see:
>>
>> 1) "launch url" with a 'mailto:' URL. This would invoke the locally
>> configured email client (and is what revMail does). This won't (I believe)
>> work in the HTML5 engine yet because we haven't hooked it up (to my
>> knowledge at least). I *think* this would be possible - Peter could perhaps
>> comment. (It would ask the hosting web-browser to launch the url).
>>
>> 2) Put a web-service on a server and get that to send the email. This
>> requires no client-side email configuration but does require configuring a
>> web-service to do it. Indeed, there might be third party services out there
>> which could be used. Again, Peter would have to comment on the feasibility
>> of whether this would work in the HTML5 engine at the moment since I cannot
>> recall off the top of my head which (if any) URL primitives we have yet
>> implemented.
>>
>> Warmest Regards,
>>
>> Mark.
>>
>>
> Thank you very much for a reply that is a statement of the /status quo/ as
> regards e-mailing from Livecode at the moment. This is extremely helpful as
> it gives me an idea of what I /can/ and /cannot/
> do at the moment in this regard.
>
> What I would like to do, ideally, is set up a chart of some sort with text
> entry fields for students to fill in
> online, then click a 'submit' button that will send the field entries as a
> list to an e-mail address.
>
> As the current revMail capabilities are not /currently/ implemented in the
> HTML5 engine that will have
> to wait.
>
> Am I right in understanding that, theoretically a least, the goal is to
> implement all the capabilities
> of Livecode into the HTML5 engine?
>
> 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
>
___
use-livecode mailing list
use-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: Export & LC8 & Browser widget

2016-03-02 Thread Trevor DeVore

On Wed, Mar 2, 2016 at 9:11 AM, Mark Waddingham  wrote:

> Take a look at the "do in widget" command in the dictionary.


This just made my day. Here I was thinking there was no two-way
communication.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.com-www.clarify-it.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: Licensing questions again (was: Glen Bojsza "LC 8 hard question...")

2016-03-02 Thread Heather Laine

Dear Wilhelm,

I have explained to you what you actually have and why. These are the facts, it 
is unfortunate that you do not agree with them but they remain the facts. 

This is not a topic for this list. If you continue to post about your personal 
license issues here I will have no choice but to moderate those posts.

Regards,

Heather


Heather Laine
Customer Services Manager
LiveCode Ltd
www.livecode.com



> On 2 Mar 2016, at 14:24, sa...@hrz.uni-kassel.de wrote:
> 
> While answering Matthias Rebbe Kevin Miller wrote on Tue, 01 Mar 2016 
> 17:34:48:
> 
> 
>> (snip)
>>> I?ve reviewed the thread between Heather and Wilhelm and I can see that no
>>> such withdrawal of rights after the fact has taken place. Wilhelm simply
>>> does not yet appear to fully understand the extensive explanation that
>>> Heather supplied. Perhaps we can improve the way we communicate these
>>> complexities in the future.
>>> 
>>> This list is definitely not the place to discuss this. I?m sure Heather
>>> and Wilhelm will reach a point of understanding through normal channels.
> 
> 
> It is a rather simplistic and convenient way to assume that I "simply do not 
> yet appear to fully understand" - and I think this needs to be commented 
> here.
> 
> Given the present state of the discussion, in which Support simply refuses to 
> drop some untenable and unsustainable arguments, I still have the impression 
> that indeed a "withdrawal of rights after the fact has taken place", like I 
> have described it in my post.
> 
> I could quote a number of statements here that definitely leave no room for 
> any misunderstandings.
> 
> I may take your "chiming in" as a positive note and an encouragement to try 
> to "reach a point of understanding" and I hope you will second such attempts 
> that could be beneficial for both sides. And we should have improved our ways 
> to communicate already in the past. To that effect I had proposed to apply 
> the principle of "intellectual honesty" in our discussions, which is a 
> standard usually employed in academic or scientific discourses, but useful 
> everywhere.
> 
> 
> Kind regards,
> 
> Wilhelm Sanke
> 
> 
> ---
> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
> https://www.avast.com/antivirus
> 
> 
> ___
> use-livecode mailing list
> use-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

Summary: Open source, closed source, and the value of code


Hi all,

There has been a long thread discussing a number of different aspects 
relating to licensing and pricing. Thank you all for your input! In the 
interests of clarity, here is a summary of our position on the matters 
discussed.


PRICING
~~~

We are raising our prices - yes. We are not doing it suddenly, we have 
been and are doing it over a period of time. The reason we have staged 
price increases has been precisely because we know we have a great many 
long standing users who have supported us over the years and we wanted 
to insulate them from increases as a 'thank you' for that long support. 
We even recently ran an offer which allowed you to lock in the price of 
$299/year, and I’m pleased to see that many of you did so.


I'm minded of the following wee anecdote:

A fellow was stuck on his rooftop in a flood. He was praying to God 
for help.


Soon a man in a rowboat came by and the fellow shouted to the man on 
the roof, "Jump in, I can save you."


The stranded fellow shouted back, "No, it's OK, I'm praying to God 
and he is going to save me."


So the rowboat went on.

Then a motorboat came by. "The fellow in the motorboat shouted, 
"Jump in, I can save you."


To this the stranded man said, "No thanks, I'm praying to God and he 
is going to save me. I have faith."


So the motorboat went on.

Then a helicopter came by and the pilot shouted down, "Grab this 
rope and I will lift you to safety."


To this the stranded man again replied, "No thanks, I'm praying to 
God and he is going to save me. I have faith."


So the helicopter reluctantly flew away.

Soon the water rose above the rooftop and the man drowned. He went 
to Heaven. He finally got his chance to discuss this whole situation 
with God, at which point he exclaimed, "I had faith in you but you 
didn't save me, you let me drown. I don't understand why!"


To this God replied, "I sent you a rowboat and a motorboat and a 
helicopter, what more did you expect?"


Of course we wouldn't have even considered raising prices if we didn't 
believe it was warranted. We have made huge investments in the LiveCode 
product over the last few years and continue to do so. The quality of 
every release is the best it has ever been, thanks in part to the 
construction of an automated build and test system, but also because of 
the new talent we have been able to employ, who have brought their own 
years of expertise to our engineering process. The timeliness with which 
we are able to address bugs has increased substantially, and we are 
close to releasing LiveCode 8 which we hope will be as transformative 
for the LiveCode ecosystem as the explosion in VBX/OCX controls were to 
the Visual Basic world.


At the end of the day, LiveCode is important to a lot of people - 
whether they be users, company employees, shareholders or investors. 
LiveCode is also hugely expensive to develop and maintain and it is not 
going to get any cheaper to do so. There are simply an order of 
magnitude more things to consider when writing software at the level 
LiveCode has to be written at today compared to 10 years ago, and people 
expect software (particularly development tools) to do an order of 
magnitude more (which is entirely fair enough - but the more something 
does, the more it costs to produce and maintain). Please note, this is 
not a complaint on my part - part of the reason I do what I do and enjoy 
doing it is that I like the challenge of battling with large complex 
systems, and trying to simplify them (at least from the point of view 
from an outside observer/user).


Pricing is never an easy area and is always a balancing act. We do not 
take such decisions lightly. This is the path for LiveCode and its 
ecosystem as a whole, and unfortunately it is simply never possible to 
please everyone.


If you do have specific questions about pricing or related matters 
(particularly pertaining to your own situations) then please do remember 
that supp...@livecode.com is always there, and is generally the best 
place to have such discussions. Heather and Neil are always happy to 
receive your emails :)



LICENSING
~

There is a very simple rule to apply to work out whether you need a 
commercial license or not. If you need to ask 'do I need a commercial 
license' then you probably do. In particular, if you are asking that 
question to try to avoid paying for a commercial license then you almost 
certainly do.


The fact of the matter is that it comes down to one of the following:

1) If you are happy to buy into the ideal of the GPL and abide by 
its terms then use the community edition.


2) If not, buy a commercial edition.

The most critical thing to remember is that it is the *intent* of the 
GPL that actually matters and not the current text of any particular 
version. The simple reason for that is if the GPL is ever tested in 
court and the outcome is not favourable or contradicts

Summary: Open source, closed source, and the value of code


Hi all,

There has been a long thread discussing a number of different aspects 
relating to licensing and pricing. Thank you all for your input! In the 
interests of clarity, here is a summary of our position on the matters 
discussed.


PRICING
~~~

We are raising our prices - yes. We are not doing it suddenly, we have 
been and are doing it over a period of time. The reason we have staged 
price increases has been precisely because we know we have a great many 
long standing users who have supported us over the years and we wanted 
to insulate them from increases as a 'thank you' for that long support. 
We even recently ran an offer which allowed you to lock in the price of 
$299/year, and I’m pleased to see that many of you did so.


I'm minded of the following wee anecdote:

A fellow was stuck on his rooftop in a flood. He was praying to God 
for help.


Soon a man in a rowboat came by and the fellow shouted to the man on 
the roof, "Jump in, I can save you."


The stranded fellow shouted back, "No, it's OK, I'm praying to God 
and he is going to save me."


So the rowboat went on.

Then a motorboat came by. "The fellow in the motorboat shouted, 
"Jump in, I can save you."


To this the stranded man said, "No thanks, I'm praying to God and he 
is going to save me. I have faith."


So the motorboat went on.

Then a helicopter came by and the pilot shouted down, "Grab this 
rope and I will lift you to safety."


To this the stranded man again replied, "No thanks, I'm praying to 
God and he is going to save me. I have faith."


So the helicopter reluctantly flew away.

Soon the water rose above the rooftop and the man drowned. He went 
to Heaven. He finally got his chance to discuss this whole situation 
with God, at which point he exclaimed, "I had faith in you but you 
didn't save me, you let me drown. I don't understand why!"


To this God replied, "I sent you a rowboat and a motorboat and a 
helicopter, what more did you expect?"


Of course we wouldn't have even considered raising prices if we didn't 
believe it was warranted. We have made huge investments in the LiveCode 
product over the last few years and continue to do so. The quality of 
every release is the best it has ever been, thanks in part to the 
construction of an automated build and test system, but also because of 
the new talent we have been able to employ, who have brought their own 
years of expertise to our engineering process. The timeliness with which 
we are able to address bugs has increased substantially, and we are 
close to releasing LiveCode 8 which we hope will be as transformative 
for the LiveCode ecosystem as the explosion in VBX/OCX controls were to 
the Visual Basic world.


At the end of the day, LiveCode is important to a lot of people - 
whether they be users, company employees, shareholders or investors. 
LiveCode is also hugely expensive to develop and maintain and it is not 
going to get any cheaper to do so. There are simply an order of 
magnitude more things to consider when writing software at the level 
LiveCode has to be written at today compared to 10 years ago, and people 
expect software (particularly development tools) to do an order of 
magnitude more (which is entirely fair enough - but the more something 
does, the more it costs to produce and maintain). Please note, this is 
not a complaint on my part - part of the reason I do what I do and enjoy 
doing it is that I like the challenge of battling with large complex 
systems, and trying to simplify them (at least from the point of view 
from an outside observer/user).


Pricing is never an easy area and is always a balancing act. We do not 
take such decisions lightly. This is the path for LiveCode and its 
ecosystem as a whole, and unfortunately it is simply never possible to 
please everyone.


If you do have specific questions about pricing or related matters 
(particularly pertaining to your own situations) then please do remember 
that supp...@livecode.com is always there, and is generally the best 
place to have such discussions. Heather and Neil are always happy to 
receive your emails :)



LICENSING
~

There is a very simple rule to apply to work out whether you need a 
commercial license or not. If you need to ask 'do I need a commercial 
license' then you probably do. In particular, if you are asking that 
question to try to avoid paying for a commercial license then you almost 
certainly do.


The fact of the matter is that it comes down to one of the following:

1) If you are happy to buy into the ideal of the GPL and abide by 
its terms then use the community edition.


2) If not, buy a commercial edition.

The most critical thing to remember is that it is the *intent* of the 
GPL that actually matters and not the current text of any particular 
version. The simple reason for that is if the GPL is ever tested in 
court and the outcome is not favourable or contradicts

Re: Export & LC8 & Browser widget


On 2016-03-02 15:18, Terence Heaford wrote:

Thanks, for some reason I thought it would be in the widget docs.


Indeed that would be a logical place for it to be - the reason it isn't 
is because the browser widget syntax (such as 'do ...') is currently 
hard-coded in the engine's parser rather than defined by the widget (the 
latter will come when we've finished Open Language) and so the 
dictionary doesn't actually know that there is specific syntax for the 
browser widget.


I've raised Bug 17053 about that 
(http://quality.livecode.com/show_bug.cgi?id=17053).


Warmest Regards,

Mark.

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

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

Re: Licensing questions again (was: Glen Bojsza "LC 8 hard question...")

2016-03-02 Thread sanke

While answering Matthias Rebbe Kevin Miller wrote on Tue, 01 Mar 2016 17:34:48:

(snip)

I?ve reviewed the thread between Heather and Wilhelm and I can see that no
such withdrawal of rights after the fact has taken place. Wilhelm simply
does not yet appear to fully understand the extensive explanation that
Heather supplied. Perhaps we can improve the way we communicate these
complexities in the future.

This list is definitely not the place to discuss this. I?m sure Heather
and Wilhelm will reach a point of understanding through normal channels.

It is a rather simplistic and convenient way to assume that I "simply do not yet
appear to fully understand" - and I think this needs to be commented here.

Given the present state of the discussion, in which Support simply refuses to drop some
untenable and unsustainable arguments, I still have the impression that indeed a
"withdrawal of rights after the fact has taken place", like I have described it
in my post.

I could quote a number of statements here that definitely leave no room for any
misunderstandings.

I may take your "chiming in" as a positive note and an encouragement to try to "reach a point
of understanding" and I hope you will second such attempts that could be beneficial for both sides. And
we should have improved our ways to communicate already in the past. To that effect I had proposed to apply
the principle of "intellectual honesty" in our discussions, which is a standard usually employed in
academic or scientific discourses, but useful everywhere.

Kind regards,

Wilhelm Sanke

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

___
use-livecode mailing list
use-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: Export & LC8 & Browser widget

2016-03-02 Thread Terence Heaford

Thanks, for some reason I thought it would be in the widget docs.


All the best

Terry


> On 2 Mar 2016, at 14:11, Mark Waddingham  wrote:
> 
> Take a look at the "do in widget" command in the dictionary.
> 
> Warmest Regards,
> 
> Mark.


___
use-livecode mailing list
use-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: Export & LC8 & Browser widget


On 2016-03-02 15:09, Terence Heaford wrote:

This seems to be the best way by calling from LiveCode into the
Javascript of the Browser.

I have found this which seems to allow for calling LiveCode from
Javascript but not anything going in the other direction?

--
Name: javascriptHandlers
Type: property
Syntax: set the javascriptHandlers of  to 
get the javascriptHandlers of 
Summary: A list of LiveCode handlers that are made available to
JavaScript calls within the browser.
———


Take a look at the "do in widget" command in the dictionary.

Warmest Regards,

Mark.

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

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

Re: Export & LC8 & Browser widget

2016-03-02 Thread Terence Heaford


> On 2 Mar 2016, at 13:53, Mark Waddingham  wrote:
> 
> If you are printing the browser content on its own, then you could try using 
> JavaScript - something along the lines of 'window.print()'. However, I'm not 
> sure how controllable that is - perhaps someone with more intimate knowledge 
> of doing such things in JavaScript in browsers could chime in and comment :)


This seems to be the best way by calling from LiveCode into the Javascript of 
the Browser.

I have found this which seems to allow for calling LiveCode from Javascript but 
not anything going in the other direction?

--
Name: javascriptHandlers
Type: property
Syntax: set the javascriptHandlers of  to 
get the javascriptHandlers of 
Summary: A list of LiveCode handlers that are made available to JavaScript 
calls within the browser.
———


All the best

Terry
___
use-livecode mailing list
use-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: Export & LC8 & Browser widget


On 2016-03-02 14:26, Terence Heaford wrote:

Thanks for the comments.

As I am using a Browser to display amCharts it would be good to be
able to print the contents of the Browser.

This workaround of snapshot gives a poor printout when it is copied to
an image for printing.

Would there be a better way to achieve this?

I understand the need to create widgets to showcase what can be
achieved with LC8 but I am thinking it is counter productive
to include widgets that are not completed, particularly when LC8 is 
released.


The Browser is a good example in that without printing functionality,
it’s not useless but is severely limited.


For a use-case which requires printing the browser contents then yes, 
that is a limitation. However, it would be a huge stretch to assert that 
'all uses of a browser require printing functionality' because they 
don't, quite frankly. So, 'severely limited' - no; not ideal for your 
use-case - yes.


To be fair, if you are trying to print the current image in the browser 
window as part of a larger document rather than just the browser window 
contents itself then I'm not sure that is actually going to be generally 
possible. I *think* it can be done on Mac (as the WebView component has 
the standard Cocoa-based printing ability at first sight at least), 
however I'm not so sure on the other platforms - particularly mobile. (I 
just had a quick look into CEF and the options there do appear to be 
very very limited as well).


If you are printing the browser content on its own, then you could try 
using JavaScript - something along the lines of 'window.print()'. 
However, I'm not sure how controllable that is - perhaps someone with 
more intimate knowledge of doing such things in JavaScript in browsers 
could chime in and comment :)


Looking into amCharts there does seem to be a way to 'export' a chart as 
an image using JS - either as images or SVG. You could export as a PNG / 
JPG at 2-4x the size in pixels and then print that using LiveCode - that 
would give a better fidelity result. Once we have SVG support integrated 
(which won't happen for LC8 unfortunately, but should shortly 
afterwards), then that would be another approach which will give much 
better fidelity.


Alternatively, you could consider generating a PDF from JavaScript 
(there's a tutorial of that on the amCharts site), or building a web 
page with all that you wish to print and using the 'window.print()' 
method - taking LiveCode out of the equation entirely.


Warmest Regards,

Mark.

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

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

Re: Export & LC8 & Browser widget

2016-03-02 Thread Terence Heaford

Thanks for the comments.

As I am using a Browser to display amCharts it would be good to be able to 
print the contents of the Browser.

This workaround of snapshot gives a poor printout when it is copied to an image 
for printing.

Would there be a better way to achieve this?

I understand the need to create widgets to showcase what can be achieved with 
LC8 but I am thinking it is counter productive
to include widgets that are not completed, particularly when LC8 is released.

The Browser is a good example in that without printing functionality, it’s not 
useless but is severely limited.


All the best

Terry

> On 2 Mar 2016, at 08:34, Mark Waddingham  wrote:
> 
> On 2016-03-02 08:36, Terence Heaford wrote:
>> This suggestion doesn’t work because the widget is a Browser widget
>> and I believe the browser is not a true object
>> but a window overlay.
> 
> Not exactly - the browser widget is a true engine object, but it uses a 
> 'native' layer to display itself. At present native layers do stack above the 
> card layer (which also renders into a native layer, just with drawing code 
> the engine has complete control over) but we would like to make them 
> interleave as you would generally expect at some point (there's just a fair 
> bit of engineering to do to get that to work!). (Note that there is a well 
> defined ordering for layers used by native layer using objects - the layering 
> follows the same layering as the objects on the card, its just that all 
> non-native objects will stack first, then all native objects).
> 
> Whether or not you can actually get the pixels directly out of a native layer 
> depends entirely on what 'kind' the native layer is and whether the platform 
> lets you do that kind of thing.
> 
> See my other post for more details.
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> 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: Open source, closed source, and the value of code

2016-03-02 Thread Robert Mann

Spot on! Thanks Jacqueline, That is exactly the choice I have :

1. make a viewer of a special kind of media aggregate with the community
version under GPL
& deliver these media aggregate in a separate file under whatever license.
(plus i'll document that format so that others can produce such content)

--> I can crunch in a specialized in house editor
--> content will be more "industrialized" not as rich visually,
just like an app instead of the original hypercard spirit mix of app + book.
--> not ok for iOs distribution

2. create fully contained mixed apps+content in the spirit oh hypercard, non
GPL, with livecode commercial edition.
--> ok for iOs distribution

to which I add :

3. have a tier party do the viewer ready for iOs and let me concentrate on
the in house editor.
--> ok for iOs distibution

4. switch to web service for distribution which is something I do "master"
thanks to revIgniter bootcamp and some in house development i've done in
that view.
--> ok for wider usage/distribution
--> if third parties/individuals wish to produce content, I can either open
source the in house editor or sell it with a commercial version.

5. see in the future if live code HTML5 can help produce better quality
content for the web, that would match the quality of interaction we once
upon a time had with hypercard stacks!

And the winner is : number 4 (the web app path) considering that for kids,
having to install one more app on a phone is to my point of view not ideal.
Also dealing with separate content is subject of problems on my android
phone.

So as conclusion, the "evolution" from the hypercard time is internet, web
pages, web apps.
bye bye stacks.

So that is it for the issue number 3 for me // many thanks all and I hope it
can help others have a clearer view of the impact of licensings schemes in
their plans.
RObert

--
View this message in context:
http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701848.html
Sent from the Revolution - User mailing list archive at Nabble.com.

Re: Apple Automator

2016-03-02 Thread Kay C Lan

On Tue, Mar 1, 2016 at 2:24 AM, Glen Bojsza  wrote:
> Is it possible to launch Apple Automator shell scripts from LC app?

If by shell script you mean Workflow, then the answer is yes.

Try this:

Open up Automator, create a new workflow, go to the iTunes actions and
drag 'Start iTunes Playing' into the right side. Save this to your
Documents folder as 'test.workflow'

Quit Automator.

Start AppleScript Editor, click on the record button, then double
click on your test.workflow so that Automator starts up. Go back to
the AppleScript Editor and click stop. In the workspace their should
be something like this:

tell application "Finder"
activate
open document file "test.workflow" of folder "Documents" of folder
"yourname" of folder "Users" of startup disk
end tell


To that add the following 4 lines:

delay 2
tell application "Automator"
execute workflow "test.workflow"
end tell

So the whole lot in AppleScript should look like this:

tell application "Finder"
activate
open document file "test.workflow" of folder "Documents" of folder
"yourname" of folder "Users" of startup disk
end tell
delay 2
tell application "Automator"
execute workflow "test.workflow"
end tell

Quit Automator.

Click on the Run button in AppleScript Editor. Automator should start
up with your test.workflow and it should start iTunes playing. If not
there might be an error about 'Can't get workflow "test.workflow" If
so you need to try a bigger delay.

Once you've got that working, Quit iTunes and Automator.

You now go to LiveCode, New Stack, drag a button onto it.

The next part is the hard part. You have to take that entire script
above and put it into a variable, in this case I've called it tScript.
You have to be careful because every " (quote) used in the script
above MUST appear as the word 'quote' in the variable tScript. You
have to also add all the carriage returns - cr

So basically: tell application "Finder"
becomes: "tell application " & quote & "Finder" & quote

The final script for your button should look like this:

on mouseUp
put "tell application " & quote & "Finder" & quote & cr & \
"activate" & cr & \
"open document file " & quote & "test.workflow" & quote & " of folder
" & quote & "Documents" & quote & " of folder " & quote & "yourname" &
quote & " of folder " & quote & "Users" & quote & " of startup disk" &
cr & \
"end tell" & cr & \
"delay 2" & cr & \
"tell application " & quote & "Automator" & quote & cr & \
"execute workflow " & quote & "test.workflow" & quote & cr & \
"end tell" into tScript

do tScript as "AppleScript"

end mouseUp

If it doesn't work, add a breakpoint and stop at the:

put "...." into tScript

 line and double check what is in tScript looks exactly the same -
same number of lines, same quotes, as it appears in the AppleScript
Editor. Once you have it perfect then:

do tScript as "AppleScript"

will cause AppleScript to launch, which will then launch your workflow.

Practically, if you create the workflow as described, and give it the
name 'test.workflow'. You should be able to just copy and past the
LiveCode script here into your button, change 'yourname' to whatever
your computer account name is and it should work. The only gotcha is
you have to careful of linebreaks as email clients have a tendency to
add hard line wraps where there is a soft line wrap: - the 4th line is
very long

1st line: on mouseUp
7 lines which all end in: cr & \
9th line:  "end tell" into tScript
blank line
do tScript as "AppleScript"
blank line
last line: end mouseUp

13 lines total

___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues

2016-03-02 Thread Tore Nilsen

> 2. mar. 2016 kl. 09.39 skrev Mark Waddingham :
> 
> On 2016-03-02 06:46, J. Landman Gay wrote:
>> I confess my first reaction was that LC needs an interface designer.
> 
> Ah - yes - those magical 'interface designers' who you just ask to give you 
> the perfect UI that *everyone* immediately understands and knows how to use 
> and works exactly how each individual wants it to work ;)
> 
> Warmest Regards,
> 
> Mark.
> 

Yes, we would prefer those magical interface designers whenever they are 
available. If not, we will accept the interface designers who are able to speak 
the lingo of grumpy software engineers, and who can facilitate fruitful 
discussions that may lead to an optimal amalgamation of UI/UE and awesome code. 
But magical would be better off course. ;)

Regards
Tore

___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues

I designed an interface for my Devawriter Pro [ go and have a look at 
it: http://andregarzia.on-rev.com/richmond/dwriterpro.html ].


Frankly I am well aware it is horrible because it is cluttered to blazes 
with all sorts of fancy features

I built into the thing along the way.

It is meant to be the "B-and-end-all" of Devanagari text entry: were I 
to dumb the thing down it

would be . . . well . . . DUMB.

So here's Richmond's "9 shilling note" on interface design:

1. You'll never keep everybody happy.

2. You'll always have a fight between what to include and what to exclude.

3. Which is more important? Functionality or Appearance?

4. Every single thing that has ever been invented involves a learning 
curve; be it a frying pan

or Livecode.

5.  People who expect to open a box and get something that "just works" 
are naive in their

expectations and should not be pandered to.

6. Certainly in my experience with Primary school children they lose 
interest very quickly indeed in

a program that is moronic and does not involve some cognitive effort.

---

Livecode's interface as of version 7 is significantly easier to use than 
Runtime Revolution 1.1.1,
and Livecode 8's interface will take a bit of getting used to 
(especially the new properties palette),
but is NOT insurmountable, and is NOT daft, and after a wee while is 
perfectly usable.


Anyone who feels "lumpy" about Livecode's interface should take a look 
at Hypercard's, Metacard's and RunRev 1. AND that list doesn't even 
mention Visual Basic . . . or, for that matter, all those programming 
languages one writes in a text editor with NO interface whatsoever.


--

My first reaction when I saw Livecode/RunRev 1.1 was a long sigh of 
relief after having wrestled with
Toolbook and Director. Any rude noises I have made about the interface 
subsequently are minor by comparison; and, as I have demonstrated time 
and time again, mucking around with the Livecode interface to get 
something more to one's taste is really comparatively easy.


Richmond.

On 2.03.2016 10:39, Mark Waddingham wrote:

On 2016-03-02 06:46, J. Landman Gay wrote:

I confess my first reaction was that LC needs an interface designer.


Ah - yes - those magical 'interface designers' who you just ask to 
give you the perfect UI that *everyone* immediately understands and 
knows how to use and works exactly how each individual wants it to 
work ;)


Warmest Regards,

Mark.




___
use-livecode mailing list
use-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: LC8DP15 feedback-IDE Issues


On 2016-03-02 06:46, J. Landman Gay wrote:

I confess my first reaction was that LC needs an interface designer.


Ah - yes - those magical 'interface designers' who you just ask to give 
you the perfect UI that *everyone* immediately understands and knows how 
to use and works exactly how each individual wants it to work ;)


Warmest Regards,

Mark.

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

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

Re: Hey-Ho and Off We Go with HTML5


On 2016-03-02 09:30, RM wrote:

Am I right in understanding that, theoretically a least, the goal is
to implement all the capabilities
of Livecode into the HTML5 engine?


The goal is to implement (over time) as many LiveCode capabilities which 
are possible to implement in HTML5 it definitely won't be all because 
that simply isn't possible.


Warmest Regards,

Mark.

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

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

Re: Export & LC8 & Browser widget


On 2016-03-02 08:36, Terence Heaford wrote:

This suggestion doesn’t work because the widget is a Browser widget
and I believe the browser is not a true object
but a window overlay.


Not exactly - the browser widget is a true engine object, but it uses a 
'native' layer to display itself. At present native layers do stack 
above the card layer (which also renders into a native layer, just with 
drawing code the engine has complete control over) but we would like to 
make them interleave as you would generally expect at some point 
(there's just a fair bit of engineering to do to get that to work!). 
(Note that there is a well defined ordering for layers used by native 
layer using objects - the layering follows the same layering as the 
objects on the card, its just that all non-native objects will stack 
first, then all native objects).


Whether or not you can actually get the pixels directly out of a native 
layer depends entirely on what 'kind' the native layer is and whether 
the platform lets you do that kind of thing.


See my other post for more details.

Warmest Regards,

Mark.

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

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

Re: Export & LC8 & Browser widget


On 2016-03-01 22:57, Terence Heaford wrote:
On 1 Mar 2016, at 21:32, J. Landman Gay  
wrote:


"To export a snapshot for a portion of a stack you use the form:
export snapshot from rect[angle] of window windowID to ...
Where windowId is the windowId property of the required stack."


This does not work correctly on a Mac for the reason given previously.

The top and bottom of the image exported has shifted down by the depth
of the menubar.
put the rect widget "Chart" into tRect

export snapshot from rectangle tRect of window (the windowId of window
"Test") to tVar as PNG


The corrected version would be:

put the rect widget "Chart" into tRect

subtract 22 from item 2 of tRect

subtract 22 from item 4 of tRect

export snapshot from rectangle tRect of window (the windowId of window
 “Test") to tVar as PNG


There are three types of export/import snapshot.

The first uses the screen buffer - the co-ordinates have to be in screen 
co-ordinate space:


  export snapshot from rectangle tRect

The second uses the window buffer (if the OS has such things, otherwise 
it is equivalent to using the screen buffer after a translation of 
co-ordinates) - the co-ordinates have to be in window co-ordinate space 
(NOT card co-ordinate space):


  export snapshot from rectangle tRect of window tWindowId

The third uses no buffer at all, it asks the target object (and 
children) to render the specified rect of itself into an offscreen 
buffer (the same mechanism which the engine uses to update a window when 
the OS requests it, or a portion gets changed) - the co-ordinates have 
to be in card co-ordinate space:


  export snapshot from rectangle tRect of 

Now, the final form here will work for any object which is drawn by the 
LiveCode engine - it will not necessarily work for objects which use 
'native' layers to display things (such as the browser). Whether or not 
one can get a native layer to render itself entirely depends on the 
native layer. For example, we've not had any success at all in 
persuading the CEF browser to give us a snapshot as it uses various 
'native' things which do not want to give up their backing store of 
pixels.


Therefore, if you want to take a snapshot of a stack containing native 
layers your best bet to make this work generally is to use the screen or 
window form. When you do this you do have to take into account the fact 
that cards might have a vertical scroll due to menus (that mysterious 22 
px) - you can get the current scroll amount by using 'the vscroll of 
stack ...'.


Warmest Regards,

Mark.

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

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

Re: Hey-Ho and Off We Go with HTML5




On 2.03.2016 10:18, Mark Waddingham wrote:

On 2016-03-02 09:01, RM wrote:

Preferably this would be WITHOUT the message having to go via the
client's e-mail system as:

1.  The message should be anonymous.

2.  The end-user may have no e-mail client configured.


Okay so there in terms of what you will be able to do in this regard 
with the HTML5 engine there are two feasible options as far as I can see:


1) "launch url" with a 'mailto:' URL. This would invoke the locally 
configured email client (and is what revMail does). This won't (I 
believe) work in the HTML5 engine yet because we haven't hooked it up 
(to my knowledge at least). I *think* this would be possible - Peter 
could perhaps comment. (It would ask the hosting web-browser to launch 
the url).


2) Put a web-service on a server and get that to send the email. This 
requires no client-side email configuration but does require 
configuring a web-service to do it. Indeed, there might be third party 
services out there which could be used. Again, Peter would have to 
comment on the feasibility of whether this would work in the HTML5 
engine at the moment since I cannot recall off the top of my head 
which (if any) URL primitives we have yet implemented.


Warmest Regards,

Mark.



Thank you very much for a reply that is a statement of the /status quo/ 
as regards e-mailing from Livecode at the moment. This is extremely 
helpful as it gives me an idea of what I /can/ and /cannot/

do at the moment in this regard.

What I would like to do, ideally, is set up a chart of some sort with 
text entry fields for students to fill in
online, then click a 'submit' button that will send the field entries as 
a list to an e-mail address.


As the current revMail capabilities are not /currently/ implemented in 
the HTML5 engine that will have

to wait.

Am I right in understanding that, theoretically a least, the goal is to 
implement all the capabilities

of Livecode into the HTML5 engine?

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: Hey-Ho and Off We Go with HTML5


On 2016-03-02 09:01, RM wrote:

Preferably this would be WITHOUT the message having to go via the
client's e-mail system as:

1.  The message should be anonymous.

2.  The end-user may have no e-mail client configured.


Okay so there in terms of what you will be able to do in this regard 
with the HTML5 engine there are two feasible options as far as I can 
see:


1) "launch url" with a 'mailto:' URL. This would invoke the locally 
configured email client (and is what revMail does). This won't (I 
believe) work in the HTML5 engine yet because we haven't hooked it up 
(to my knowledge at least). I *think* this would be possible - Peter 
could perhaps comment. (It would ask the hosting web-browser to launch 
the url).


2) Put a web-service on a server and get that to send the email. This 
requires no client-side email configuration but does require configuring 
a web-service to do it. Indeed, there might be third party services out 
there which could be used. Again, Peter would have to comment on the 
feasibility of whether this would work in the HTML5 engine at the moment 
since I cannot recall off the top of my head which (if any) URL 
primitives we have yet implemented.


Warmest Regards,

Mark.

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

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

Re: Hey-Ho and Off We Go with HTML5