Re: LC 8 Property Inspector

[Richmond]

More:

http://forums.livecode.com/viewtopic.php?f=6=25526=133078#p133078

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: LC 8 Property Inspector

[Bob Sneidar]

You and I are apparently in the minority on that point these days. In fact, we 
may be the only two people left! ;-)

Bob S


On Oct 14, 2015, at 01:14 , Mark Waddingham 
> wrote:

Unfortunately, I don't have much confidence in chaos producing anything in any 
particularly useful timeframe (the mathematician in me screams that the numbers 
just don't add up in that regard).

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

Re: LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-14 15:59, Geoff Canyon wrote:
I've never found this to be the case. I have never had someone report a 
bug

to me because some other tool interfered with Navigator, or because
Navigator tripped up someone else's tool.


I wasn't saying Navigator ever caused a problem, I was more talking 
about how to construct an environment which minimises the chance of such 
a negative interaction *and* ensures the toolmakers don't have to do 
more work than necessary to actually write their tool.


I think Navigator is useful. I've used it in place of everything except 
the

script editor and the dictionary for over ten years.


Indeed - it is a nice compact tool - I've played with it over the years 
(at least the version which is currently in plugins) particularly when 
checking that we haven't broken anything in the engine :)


Again, unless I'm misunderstanding you, this isn't accurate -- 
Navigator

happily co-exists with every tool I know.


As I said above, I wasn't talking about specific tools, nor any specific 
problems at the moment.


I just want to make sure we make tool writing as easy and painless as 
possible - my thoughts on doing this are that we build a well 
maintained, well documented and simple API which all tools sit on. Any 
'hairy details' can sit below the API (just as the engine hides many 
hairy details of cross-platform development from script), and anything 
sitting on top the API can be assured of the environment which it runs 
in.


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: LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-14 16:29, Geoff Canyon wrote:
I wasn't defending Navigator specifically, just pointing out that, in 
my
experience, the current framework allows for reasonably clean 
development

of tools.


But there *is* a framework :)

We've learnt a lot from trying to write new components in the existing 
IDE and it has not been easy in many cases - hence the determination we 
have of trying to drag the current IDE through into the modern era by 
re-underpinning it.


Through doing so, we'll hopefully get to a state that all components in 
the IDE are essentially optional and replaceable, and will all run on a 
common foundation (which would sit just above the IDE engine).


If you needed a sha1Digest function you'd probably not go off and write 
your own in LiveCode Script (unless it was something you were *really* 
interested in doing), you'd use the engine one.


I'd like a similar thing to be true at the IDE level. Ideally, there'd 
be a good set of IDE APIs which you'd be able to use when you need to do 
a certain thing in a tool - rather than having to go off and write your 
own (unless that is your specific interest of course!).


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: LC 8 Property Inspector

[Peter Haworth]

New version of lcStackBrowser coming out this week with Widget support.
Not super difficult but did involve some searching around to figure out how
to get the properties of a widget.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Wed, Oct 14, 2015 at 8:28 AM, Mark Wieder  wrote:

> On 10/14/2015 07:28 AM, Geoff Canyon wrote:
>
> Yay, then hopefully I won't have to update Navigator much/at all.
>>
>
> You shouldn't have much trouble with it. Aside from spotty documentation,
> I added Extension/Widget support to PowerTools fairly easily.
>
>
> --
>  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: LC 8 Property Inspector

[Mark Wieder]

On 10/14/2015 07:28 AM, Geoff Canyon wrote:


Yay, then hopefully I won't have to update Navigator much/at all.


You shouldn't have much trouble with it. Aside from spotty 
documentation, I added Extension/Widget support to PowerTools fairly easily.


--
 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: LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-14 17:23, Mark Wieder wrote:

Exactly. And that's, for the most part, how PowerTools works as well.
The hard part of tool coexistence is when you have to cooperate with
frontscript handlers that may or may not do the right thing before you
have a chance to handle messages. Duelling frontscripts gets ugly.


Sounds like a good reason to have a well-written (and well documented 
*cough*) IDE API that allows you to subscribe for the critical 
notifications your tool needs to function correctly to me ;)


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: LC 8 Property Inspector

[Mark Wieder]

On 10/14/2015 07:40 AM, Mark Waddingham wrote:


If you needed a sha1Digest function you'd probably not go off and write
your own in LiveCode Script (unless it was something you were *really*
interested in doing), you'd use the engine one.


Given the recent demonstration of a poc sha1 collision, I'd like a 
sha2Digest function, but again, I'd use the functionality from the 
openssl library rather than foolishly crating my own.


--
 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: LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-14 17:19, Mark Wieder wrote:

Given the recent demonstration of a poc sha1 collision, I'd like a
sha2Digest function, but again, I'd use the functionality from the
openssl library rather than foolishly crating my own.


Slightly Off-Topic... But...

I wrote up a spec a while ago about digest functions in LC. There's a PR 
for the spec here:


https://github.com/livecode/livecode/pull/1897

Please feel free to read and add any comments on the syntax etc. and 
reasonings that are there.


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: LC 8 Property Inspector

[Mark Wieder]

On 10/14/2015 06:49 AM, Geoff Canyon wrote:


No. The IDE already provides messages that things have changed, and all
Navigator has to do is get its name on the list of message receivers. After
that Navigator just responds to the update requests it receives. It doesn't
have its own code for monitoring changes, and it is self-contained as
Richard says.


Exactly. And that's, for the most part, how PowerTools works as well.
The hard part of tool coexistence is when you have to cooperate with 
frontscript handlers that may or may not do the right thing before you 
have a chance to handle messages. Duelling frontscripts gets ugly.


--
 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: LC 8 Property Inspector

[Geoff Canyon]

On Wed, Oct 14, 2015 at 10:13 AM, Mark Waddingham  wrote:

> [Widgets] aren't groups of underlying objects - they are black-boxes like
> the engine controls. Indeed, they are a mechanism for (essentially) writing
> engine controls incredibly easily and accessibly (relative to doing so in
> C++, at least) and they plug into LiveCode Script just like all the
> existing ones.


Yay, then hopefully I won't have to update Navigator much/at all.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Geoff Canyon]

On Wed, Oct 14, 2015 at 10:21 AM, Mark Waddingham  wrote:

>
> Again, unless I'm misunderstanding you, this isn't accurate -- Navigator
>> happily co-exists with every tool I know.
>>
>
> As I said above, I wasn't talking about specific tools, nor any specific
> problems at the moment.


I wasn't defending Navigator specifically, just pointing out that, in my
experience, the current framework allows for reasonably clean development
of tools.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Peter Haworth]

Hi Mark,
I found revIDEExtensionProperties and used it.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Wed, Oct 14, 2015 at 10:45 AM, Mark Waddingham  wrote:

> For what you are doing, I suspect it is the underlying details about what
> the properties are and their 'meta' attributes which are really needed.
>
> There are functions in the LC8 IDE for getting thins information for all
> controls - using the metadata file which accompanies any widget - however,
> we really need to document them :)
>
> What approach did you take in the end?
>
> Mark.
>
> Sent from my iPhone
>
> > On 14 Oct 2015, at 18:33, Peter Haworth  wrote:
> >
> > Would be great if that were the case and maybe it will be eventually but
> > when I tried "get the keys of widget 1 of this card", I got an empty
> array.
> >
> > Widgets have their own set of properties which are defined as part of the
> > process of creating them. You get and set them as any other property but
> > lcStackbrowser needs to discover their names. They're somewhat akin to
> > custom properties in my mind but they don't show up as such in the IDE.
> >
> > Pete
> > lcSQL Software 
> > Home of lcStackBrowser  and
> > SQLiteAdmin 
> >
> > On Wed, Oct 14, 2015 at 10:07 AM, Richard Gaskin <
> ambassa...@fourthworld.com
> >> wrote:
> >
> >> Peter Haworth wrote:
> >>
> >>> New version of lcStackBrowser coming out this week with Widget support.
> >>> Not super difficult but did involve some searching around to figure out
> >>> how
> >>> to get the properties of a widget.
> >>
> >> If Widgets are a means of adding new objects to LC Script to compliment
> >> the existing ones, wouldn't "the properties" work as it always has?
> >>
> >> --
> >> Richard Gaskin
> >> Fourth World Systems
> >> Software Design and Development for the Desktop, Mobile, and the Web
> >> 
> >> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> >>
> >>
> >> ___
> >> use-livecode mailing list
> >> use-livecode@lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> >> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Richard Gaskin]

Mark Wieder wrote:

The hard part of tool coexistence is when you have to cooperate with
frontscript handlers that may or may not do the right thing before you
have a chance to handle messages. Duelling frontscripts gets ugly.


A few years ago I proposed to my congressman that he introduce a bill 
mandating jail time for any LiveCode scripter who writes dev tools with 
frontScripts that don't pass system messages.


Oddly, the proposal was not taken seriously.

So it's up to us to enforce this voluntarily.

Thankfully it's just a single line of code, so we rarely see felony 
offenders.


--
 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: LC 8 Property Inspector

[Richard Gaskin]

Peter Haworth wrote:

Typo - s/b get the properties of widget 1 of this card.

Believe me Richard, it doesn't work, as per Mark W's response.


I have no reason to doubt you. I was just hoping I'd missed some cool 
trick with the language.


I'm sure as LCB evolves it'll continue to do an ever better job of 
allowing Widgets to compliment and ultimately replace the objects we're 
used to working with in the ways we work with them.


--
 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: LC 8 Property Inspector

[Peter Haworth]

Would be great if that were the case and maybe it will be eventually but
when I tried "get the keys of widget 1 of this card", I got an empty array.

Widgets have their own set of properties which are defined as part of the
process of creating them. You get and set them as any other property but
lcStackbrowser needs to discover their names. They're somewhat akin to
custom properties in my mind but they don't show up as such in the IDE.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Wed, Oct 14, 2015 at 10:07 AM, Richard Gaskin  wrote:

> Peter Haworth wrote:
>
>> New version of lcStackBrowser coming out this week with Widget support.
>> Not super difficult but did involve some searching around to figure out
>> how
>> to get the properties of a widget.
>>
>
> If Widgets are a means of adding new objects to LC Script to compliment
> the existing ones, wouldn't "the properties" work as it always has?
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Richard Gaskin]

Peter Haworth wrote:

Would be great if that were the case and maybe it will be eventually but
when I tried "get the keys of widget 1 of this card", I got an empty array.


I'm unable to do that here even with built-in objects in v7.1:

  get the keys of this stack -- throws error

  put the properties of this stack into tA; get the keys of tA -- works

Are you able to get "the keys" of built-in objects?

--
 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: LC 8 Property Inspector

[Richard Gaskin]

Geoff Canyon wrote:
> I wasn't defending Navigator specifically, just pointing out that,
> in my experience, the current framework allows for reasonably clean
> development of tools.

In the case of RevNavigator even more so: your tool politely checks for 
the existence of revMenubar when it inits, and if it doesn't find one it 
inserts a slender frontScript to provide the handful of handlers it 
relies on.  This allows it to be enjoyed in the MetaCard IDE or even 
OpenCard along with the LiveCode IDE and conceivably any other, all 
fully self-contained, nimble, and (at least in my experience having used 
it in two different IDEs) error-free.


--
 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: LC 8 Property Inspector

[Peter Haworth]

Typo - s/b get the properties of widget 1 of this card.

Believe me Richard, it doesn't work, as per Mark W's response.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Wed, Oct 14, 2015 at 10:58 AM, Richard Gaskin  wrote:

> Peter Haworth wrote:
>
>> Would be great if that were the case and maybe it will be eventually but
>> when I tried "get the keys of widget 1 of this card", I got an empty
>> array.
>>
>
> I'm unable to do that here even with built-in objects in v7.1:
>
>   get the keys of this stack -- throws error
>
>   put the properties of this stack into tA; get the keys of tA -- works
>
> Are you able to get "the keys" of built-in objects?
>
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Richard Gaskin]

Peter Haworth wrote:

New version of lcStackBrowser coming out this week with Widget support.
Not super difficult but did involve some searching around to figure out how
to get the properties of a widget.


If Widgets are a means of adding new objects to LC Script to compliment 
the existing ones, wouldn't "the properties" work as it always has?


--
 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: LC 8 Property Inspector

[J. Landman Gay]

It's likely you've never had interference issues with Navigator because users 
wouldn't be using more than one property inspector simultaneously. But my 
Zygodact system did interfere with the GLX framework and I had to rewrite it to 
accommodate GLX. It wasn't how I wanted things to work, but enough people were 
using GLX at the time that it was necessary. Fixing the problem required 
communication between me and the author. 

The conflict occurred because of different approaches when handling preferences 
files. Standardization would have avoided the issue. 

On October 14, 2015 8:59:51 AM CDT, Geoff Canyon  wrote:
>On Wed, Oct 14, 2015 at 4:14 AM, Mark Waddingham 
>wrote:
>> Great - how do you ensure that Mark's tools don't interfere with
>Geoff's
>> so users can use them side-by-side?
>>
>> If every toolmaker has to take into account every other toolmaker's
>'way
>> of doing things' you end up with a situation where one individual who
>wants
>> to write a tool needs to learn about everybody else's if they want to
>> distribute it for the benefit of all.
>
>
>I've never found this to be the case. I have never had someone report a
>bug
>to me because some other tool interfered with Navigator, or because
>Navigator tripped up someone else's tool.
>
-- 
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: LC 8 Property Inspector

[Mark Waddingham]

Well, as has been the subject of other threads on here and the forums, 'the 
properties' whilst well meaning has never been particularly well defined.

Monte did significant work on it a couple of years ago to make it work for 
lcVCS but that meant putting in specific code for the engine controls to ensure 
overlapping properties didn't affect the end result.

However, how to do that generally for widgets is not yet clear.

Mark.

Sent from my iPhone

> On 14 Oct 2015, at 18:07, Richard Gaskin  wrote:
> 
> Peter Haworth wrote:
>> New version of lcStackBrowser coming out this week with Widget support.
>> Not super difficult but did involve some searching around to figure out how
>> to get the properties of a widget.
> 
> If Widgets are a means of adding new objects to LC Script to compliment the 
> existing ones, wouldn't "the properties" work as it always has?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

Re: LC 8 Property Inspector

[Geoff Canyon]

On Wed, Oct 14, 2015 at 12:13 PM, Peter Haworth  wrote:

> New version of lcStackBrowser coming out this week with Widget support.
> Not super difficult but did involve some searching around to figure out how
> to get the properties of a widget.
>

Great, then my biggest problem is that I have two versions at present: one
that is function, but which has the spaghetti code from hell in it, and the
updated version, which is vastly cleaned up, but significantly buggy at
present. Picking up twelve-year-old code sucks.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Mark Waddingham]

For what you are doing, I suspect it is the underlying details about what the 
properties are and their 'meta' attributes which are really needed.

There are functions in the LC8 IDE for getting thins information for all 
controls - using the metadata file which accompanies any widget - however, we 
really need to document them :)

What approach did you take in the end?

Mark.

Sent from my iPhone

> On 14 Oct 2015, at 18:33, Peter Haworth  wrote:
> 
> Would be great if that were the case and maybe it will be eventually but
> when I tried "get the keys of widget 1 of this card", I got an empty array.
> 
> Widgets have their own set of properties which are defined as part of the
> process of creating them. You get and set them as any other property but
> lcStackbrowser needs to discover their names. They're somewhat akin to
> custom properties in my mind but they don't show up as such in the IDE.
> 
> Pete
> lcSQL Software 
> Home of lcStackBrowser  and
> SQLiteAdmin 
> 
> On Wed, Oct 14, 2015 at 10:07 AM, Richard Gaskin > wrote:
> 
>> Peter Haworth wrote:
>> 
>>> New version of lcStackBrowser coming out this week with Widget support.
>>> Not super difficult but did involve some searching around to figure out
>>> how
>>> to get the properties of a widget.
>> 
>> If Widgets are a means of adding new objects to LC Script to compliment
>> the existing ones, wouldn't "the properties" work as it always has?
>> 
>> --
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
>> 
>> ambassa...@fourthworld.comhttp://www.FourthWorld.com
>> 
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

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

Re: LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-13 17:35, Richard Gaskin wrote:

It's possible to invest our time enumerating reasons why people
shouldn't enjoy crafting tools in LiveCode, but to what end?

Any IDE (or IDE "tool" or "framework" or any other subset) is just a
collections of stacks. The one thing we know about LiveCode
programmers is that they know how to program in LiveCode.  Many of
them are quite good at it.


This is where I have to disagree - an 'IDE' is *not* 'just' a collection 
of stacks. Those stacks have to work together in a consistent way, agree 
on certain conventions, protocols and 'how things should generally fit 
together'. It is a 'framework' which does this (even if it is one which 
contains no code, and just a long list of 'do's' and 'don't's).



I see no harm in encouraging people to just continue doing what
they've been enjoying for decades:  making tools to help their work
and sharing them with others.


Indeed - there is no harm at all - it is actually quite important. I 
wasn't implying that it shouldn't be encouraged...



All of the tools I've referred to - Mark Weider's, Bjornke's, Geoff's,
Peter's, and others' - exist.  Why not have more?  Why not have a
convenient launcher for them?


Great - how do you ensure that Mark's tools don't interfere with Geoff's 
so users can use them side-by-side?


If every toolmaker has to take into account every other toolmaker's 'way 
of doing things' you end up with a situation where one individual who 
wants to write a tool needs to learn about everybody else's if they want 
to distribute it for the benefit of all.



Why not have an IDE for pro devs, another for kids, and other for
educators, and others for just about anything people might want to do?


Again, let us not confuse 'IDE' with 'IDE Framework'.


It's possible to imagine a perfect circle, but in the natural world
none exists.  All systems are imperfect, influenced by subtle but
pervasive forces that ultimately alter them from their ideal form.
Anything that seems otherwise lives in the space between design specs
and shipping. :)  Even the OSes we love are riddled with kludgey
workarounds - not that we should pursue kludges, but it's no more
useful to postpone everything until a perfect system exists.


Things are never perfect, it is true - but most people's daily lives are 
governed by rules, regulations and policies to ensure that everyone can 
co-exist (reasonably?) 'happily'. (Or at least function without huge 
amount of friction at every interaction).


My main assertion here is that I don't think 'the engine' in its current 
form provides a sufficiently strict set of such things for the purposes 
of interchangeable IDE Tool writing so there needs to be a concerted 
effort to build something on top of it which is.



Ultimately you and I are describing the same goal, a modular and
lightweight IDE system in which tools are plentiful and
interchangeable, something Ken Ray and others have been advocating
since the engine acquisition in 2003.


Indeed - advocacy and implementation are two entirely separate things 
though - which is perhaps why no such widespread 'lightweight IDE 
system' has appeared (to my knowledge at least).



And there is one salient aspect: neither of us is describing an IDE
that exists today.


I cannot agree there. You may be describing an IDE which does not exist 
today - some sort of mystical entity which will just appear naturally 
out of a lot of people playing around in a sandpit. Unfortunately, I 
don't have much confidence in chaos producing anything in any 
particularly useful timeframe (the mathematician in me screams that the 
numbers just don't add up in that regard).


On the other hand, I am describing an IDE (Framework) which is currently 
in the process of being built - we are working quite hard to try and 
separate out what tools in a LiveCode IDE need to function from what is 
specific to the tools themselves. As I've already said, we are trying to 
build APIs upon which any tool written by anyone could sit and still 
work together with any other tool written on the same APIs.



All I'm offering here is encouragement for the things that led to this
thread, an acknowledgement that some folks like the App Browser and
others like the Project Browser and still others like Geoff Canyon's
Navigator and others like their own.  And the same goes for object
creation tools, and inspectors, and the rest.


What I'm offering here is more than encouragement - which means I hope 
that things might actually change :)


There are a number of people who are interested in creating IDE Tools - 
it is clear - indeed, many such tools already exist.


My offer to those who are interested in this are of things is simply 
this:


Take a look at what we are trying to do with the LC8+ IDE, dig around in 
the libraries we are creating. Play with moving your tools to those APIs 
which are gradually being chiselled out of the monolithic system which 
was there before, talk to us and 

Re: LC 8 Property Inspector

[Geoff Canyon]

Interesting -- does/did GLX remove the update messages the IDE sends? Other
than that, I don't think there's anything Navigator needs/does that could
cause a problem, but of course I'm not really thinking about it thoroughly.
If someone complained I might, but Navigator has been mostly unsupported
for some time now.

On Wed, Oct 14, 2015 at 1:13 PM, J. Landman Gay 
wrote:

> It's likely you've never had interference issues with Navigator because
> users wouldn't be using more than one property inspector simultaneously.
> But my Zygodact system did interfere with the GLX framework and I had to
> rewrite it to accommodate GLX. It wasn't how I wanted things to work, but
> enough people were using GLX at the time that it was necessary. Fixing the
> problem required communication between me and the author.
>
> The conflict occurred because of different approaches when handling
> preferences files. Standardization would have avoided the issue.
>
> On October 14, 2015 8:59:51 AM CDT, Geoff Canyon 
> wrote:
> >On Wed, Oct 14, 2015 at 4:14 AM, Mark Waddingham 
> >wrote:
> >> Great - how do you ensure that Mark's tools don't interfere with
> >Geoff's
> >> so users can use them side-by-side?
> >>
> >> If every toolmaker has to take into account every other toolmaker's
> >'way
> >> of doing things' you end up with a situation where one individual who
> >wants
> >> to write a tool needs to learn about everybody else's if they want to
> >> distribute it for the benefit of all.
> >
> >
> >I've never found this to be the case. I have never had someone report a
> >bug
> >to me because some other tool interfered with Navigator, or because
> >Navigator tripped up someone else's tool.
> >
> --
> 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: LC 8 Property Inspector

[Geoff Canyon]

On Wed, Oct 14, 2015 at 2:05 PM, Richard Gaskin 
wrote:

> Geoff Canyon wrote:
> > I wasn't defending Navigator specifically, just pointing out that,
> > in my experience, the current framework allows for reasonably clean
> > development of tools.
>
> In the case of RevNavigator even more so: your tool politely checks for
> the existence of revMenubar when it inits, and if it doesn't find one it
> inserts a slender frontScript to provide the handful of handlers it relies
> on.  This allows it to be enjoyed in the MetaCard IDE or even OpenCard
> along with the LiveCode IDE and conceivably any other, all fully
> self-contained, nimble, and (at least in my experience having used it in
> two different IDEs) error-free.


Wow, check me out. I hope I haven't broken that behavior with my recent
round of updates. I'll check.

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

Re: LC 8 Property Inspector

[J. Landman Gay]

On 10/14/2015 1:54 PM, Geoff Canyon wrote:

Interesting -- does/did GLX remove the update messages the IDE sends?


I don't know but I doubt it. The problem in my case was that Zygodact's 
Registration dialog needs to store info in a prefs stack, and is 
intended to be opened before the mainstack is displayed. My method was 
to open the prefs stack, store the info, and remove it on the assumption 
that Zygodact should not interfere with the developer's instructions 
about whether the prefs should be in RAM or not. If their script opens a 
prefs file later, no problem. If not, prefs won't hang around.


GLX has startup handlers that also work with prefs, and GLX leaves the 
stack open. When Zygodact closed it soon afterward, GLX errored.


There were two ways to solve it. GLX could have checked the openstacks 
and reopened it if necessary, or Zygodact could have just left the file 
open. It was easier for me to leave it open, which hasn't seemed to 
interfere really with anything else the developer did with it except 
that there's a possibly unwanted stack in RAM.


But the point is, there was interference that required me to know what 
another tool (or framework in this case) was doing.


--
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: LC 8 Property Inspector

[Geoff Canyon]

Ah, okay, I do none of that.

gc

On Wed, Oct 14, 2015 at 4:42 PM, J. Landman Gay 
wrote:

> On 10/14/2015 1:54 PM, Geoff Canyon wrote:
>
>> Interesting -- does/did GLX remove the update messages the IDE sends?
>>
>
> I don't know but I doubt it. The problem in my case was that Zygodact's
> Registration dialog needs to store info in a prefs stack, and is intended
> to be opened before the mainstack is displayed. My method was to open the
> prefs stack, store the info, and remove it on the assumption that Zygodact
> should not interfere with the developer's instructions about whether the
> prefs should be in RAM or not. If their script opens a prefs file later, no
> problem. If not, prefs won't hang around.
>
> GLX has startup handlers that also work with prefs, and GLX leaves the
> stack open. When Zygodact closed it soon afterward, GLX errored.
>
> There were two ways to solve it. GLX could have checked the openstacks and
> reopened it if necessary, or Zygodact could have just left the file open.
> It was easier for me to leave it open, which hasn't seemed to interfere
> really with anything else the developer did with it except that there's a
> possibly unwanted stack in RAM.
>
> But the point is, there was interference that required me to know what
> another tool (or framework in this case) was doing.
>
>
> --
> 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: LC 8 Property Inspector

[Geoff Canyon]

On Thu, Oct 8, 2015 at 5:20 PM, Richard Gaskin 
wrote:

> Ken Ray and I discussed having one of the theoretical collapsible headers
> being Favorites, so anyone who finds themselves using a certain subset of
> props frequently can include them there while still keeping the logical
> groupings it would ship with by default.


I hadn't been paying attention to this thread, but then Mark and Richard
mentioned me, so here I am.

My latest update to Navigator (which I haven't officially updated for some
time) does two things:

1. It collects recently-accessed properties at the top of the list.
2. It lets the developer specify a list of properties to always show at the
top of the list.

Both of the above are determined individually by object type. That said,
Navigator doesn't support custom interfaces for any property types other
than booleans, which you can click to set/unset, and 2- and 4-item lists,
which it allows you to just type in and hit return to set.

Further, I haven't even begun to look at widgets, but if they're
implemented as a group of underlying objects, then Navigator doesn't (yet)
handle that intelligently at all.

*That* said, the above frequently-used-properties item took a couple hours
to implement and wasn't difficult.

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

Re: LC 8 Property Inspector

[Geoff Canyon]

On Thu, Oct 8, 2015 at 9:07 PM, Peter Haworth  wrote:

> The properties array of an object does not include properties which can be
> derived from other properties.  That change was made a few releases back
> and no method of invoking the prior behavior (perhaps "the effective
> properties") was provided.
>
> Also, the propertynames list is missing some entries and includes some
> entries that seem more like keywords than properties, e.g. "abbrev".
>

This is why I implemented a preference for properties-to-add-to-the-list in
Navigator. That way it doesn't matter if the propertynames doesn't include
the blork property -- I can add it to the list before releasing a new
version of Navigator, or if I miss something, a developer can add it
themselves.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Geoff Canyon]

On Tue, Oct 13, 2015 at 3:16 AM, Mark Waddingham  wrote:

>
> Tools can be entirely self-contained and fully interchangeable, even
>> open at the same time, using nothing more than what the engine has
>> provided for years.
>>
>
> Really? Are you sure that is true?
>
> So you would have every 'application browser' type tool implement its own
> code for monitoring for changes in the user stacks, and for collecting all
> the data about the objects in user stacks?
>
> You would have every 'tools palette' type tool implement its own code to
> go digging around on disk for all extensions, listing, enumerating and
> providing an ability to create them?
>

No. The IDE already provides messages that things have changed, and all
Navigator has to do is get its name on the list of message receivers. After
that Navigator just responds to the update requests it receives. It doesn't
have its own code for monitoring changes, and it is self-contained as
Richard says.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Richard Gaskin]

J. Landman Gay wrote:
> It's likely you've never had interference issues with Navigator
> because users wouldn't be using more than one property inspector
> simultaneously. But my Zygodact system did interfere with the GLX
> framework and I had to rewrite it to accommodate GLX. It wasn't how
> I wanted things to work, but enough people were using GLX at the
> time that it was necessary. Fixing the problem required communication
> between me and the author.
>
> The conflict occurred because of different approaches when handling
> preferences files. Standardization would have avoided the issue.

It would be interesting to learn more about the details of that 
conflict, informative for both the IDE team and skunkworks projects alike.


It may be a question of scope, since as you noted that GLX isn't a 
discrete tool but a framework.  Ideally even frameworks should coexist, 
at least when of different types, since things like GLX are for apps and 
an IDE's being for the tools run alongside the app during development.


This is one reason why, although I'm aware of the difference between a 
plugin and a framework (I've been making both for decades), I don't 
often distinguish them in discussions of the opportunities and 
challenges of either:  the underlying issues with regard to components 
playing nice together are similar, varying mostly in scope but not so 
much in their nature.


Indeed. the more I think about your specific circumstance the more I 
realize that what you're describing reinforces my point that dependence 
on presumptions of a single monolithic framework can sometimes introduce 
as many issues as they seek to address:


Even if there were one single modular framework for IDE tools, what 
occurred in your circumstance is quite different, a conflict between 
*application* frameworks which each assume themselves to be the only 
such thing in play.


We hope that the LC world would have many app frameworks over time, just 
as one expects to find for any popular language like JavaScript or Python.


And like frameworks in other languages, they're not always mix-and-match.

Standardizing some core elements like prefs handling may be useful for 
all app framework developers to discuss and explore solutions for (Andre 
once proposed a stdLib for LiveCode for exactly that reason), but 
anything app frameworks do would be independent of any IDE frameworks 
used alongside them.


There are many ways to resolve such conflicts, one of them being lengthy 
discussions of all possible circumstances and an expensive effort to 
craft a single one-size-fits-all solution to accommodate every app 
developer's need.


But I find I learn a lot just watching how things organically evolve, as 
they did here:  a conflict was discovered, a script change affordably 
implemented, and both toolkits now live happily together with minimal 
effort.


--
 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: LC 8 Property Inspector

[Richmond]

On 14/10/15 11:14, Mark Waddingham wrote:




However, LC8 will be better than LC7, and subsequent LC versions will 
be better still. The more people who get involved to help us reach the 
goal of a lightweight IDE Framework, the more quickly it will happen 
and the better it will be.





That sounds a bit dogmatic.

I can imagine some people not being entirely convinced about certain 
aspects of LiveCode 8: for instance, they might

feel that things have suddenly become rather unnecessarily over-complicated.

-

I don't really understand all that stuff about IDEs and frameworks but I 
do understand why birds have wings and people don't:


Genetically there is not that much different between birds and people; 
what there is in common is what we might choose
to call (at the risk of offending all sorts of people) "God's Universal 
LEGO kit", or the Basic DNA set.


If one were clever enough one could have women giving birth to babies 
with wings by making sure that while those babies
were developing in the womb the switches for wings were turned on, and 
the switches for arms and fingers were turned off.


The fact that I have red hair and white skin, and that my best friend 
has black hair and dark brown skin is a simple illustration

of this principle.

NOW:  I can imagine a stack that resides in the plug-ins folder of a 
LiveCode installation [lets' call it stack "X"]
that, when the end-user starts up LiveCode sets all sorts of "switches" 
to suppress parts of RunRev's IDE and

activate equivalent-but-different parts developed by someone else.

In fact I made a very crude stack that bungs a button on the revMenuBar 
stack and turns both the revMenuBar and the revTools
stacks black about a week ago: this could be regarded as an indication 
of the direction in which IDE hacks should be moving:
AND, before you rush to thank me, don't, as that was not my clever idea 
- I just implemented somebody else's clever idea.


I did understand that bit about different parts of the IDE chatting to 
each other, and any set of switches
would have to take that into account. A baby with wings but no sternum 
to anchor them to would die as

soon as it tried to stretch its wings.

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: LC 8 Property Inspector

[Geoff Canyon]

On Wed, Oct 14, 2015 at 4:14 AM, Mark Waddingham  wrote:

> On 2015-10-13 17:35, Richard Gaskin wrote:
>
>>



> I see no harm in encouraging people to just continue doing what
>> they've been enjoying for decades:  making tools to help their work
>> and sharing them with others.
>>
>
> Indeed - there is no harm at all - it is actually quite important. I
> wasn't implying that it shouldn't be encouraged...
>
> All of the tools I've referred to - Mark Weider's, Bjornke's, Geoff's,
>> Peter's, and others' - exist.  Why not have more?  Why not have a
>> convenient launcher for them?
>>
>
> Great - how do you ensure that Mark's tools don't interfere with Geoff's
> so users can use them side-by-side?
>
> If every toolmaker has to take into account every other toolmaker's 'way
> of doing things' you end up with a situation where one individual who wants
> to write a tool needs to learn about everybody else's if they want to
> distribute it for the benefit of all.


I've never found this to be the case. I have never had someone report a bug
to me because some other tool interfered with Navigator, or because
Navigator tripped up someone else's tool.


> Indeed - advocacy and implementation are two entirely separate things
> though - which is perhaps why no such widespread 'lightweight IDE system'
> has appeared (to my knowledge at least).
>
> And there is one salient aspect: neither of us is describing an IDE
>> that exists today.
>>
>
> I cannot agree there. You may be describing an IDE which does not exist
> today - some sort of mystical entity which will just appear naturally out
> of a lot of people playing around in a sandpit. Unfortunately, I don't have
> much confidence in chaos producing anything in any particularly useful
> timeframe (the mathematician in me screams that the numbers just don't add
> up in that regard).
>

I think Navigator is useful. I've used it in place of everything except the
script editor and the dictionary for over ten years.

Let a thousand flowers bloom.
>>
>
> Indeed - a thousand flowers blooming can be a truly breathtaking sight.
>
> However, it is much less amazing if those thousand flowers are dotted
> around the world individually, not being able to be brought together
> because they cannot co-exist within the same climate, or in the same soil.


Again, unless I'm misunderstanding you, this isn't accurate -- Navigator
happily co-exists with every tool I know.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-14 15:37, Geoff Canyon wrote:

Further, I haven't even begun to look at widgets, but if they're
implemented as a group of underlying objects, then Navigator doesn't 
(yet)

handle that intelligently at all.


They aren't groups of underlying objects - they are black-boxes like the 
engine controls. Indeed, they are a mechanism for (essentially) writing 
engine controls incredibly easily and accessibly (relative to doing so 
in C++, at least) and they plug into LiveCode Script just like all the 
existing ones.


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: LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-13 06:08, Peter Haworth wrote:
The publish/subscribe stuff sounds great, especially since I just found 
no
newxxx messages are sent when creating a control from the tools 
palette.


I did notice your bug report on that - however Ali is away for a few 
days at the moment so I haven't been able to check with him about this.


The problem with the 'tools hooking into the message path' approach is 
that you end up interfering with the operation of user stacks unless you 
are very careful. You kinda end up with the abstract picture of each 
tool wrapping the preceding tool with the application somewhere at the 
bottom surrounded by a wash of code each potentially doing its own 
thing.


The publish/subscribe mechanism, along with the other APIs emerging in 
the LC8 IDE tries to change this by providing a 'model' tools can hook 
into to mutate the user stacks being edited. This means that the tools 
themselves can be insulated from the user stacks, and the user stacks 
can be insulated from the tools - hopefully ensuring a much more easy 
co-existence than sometimes occur in the current (pre-LC8) IDE.


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: LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-12 22:31, Richard Gaskin wrote:

That's an obvious option if we assume there must be only one IDE.  And
from the company's perspective that's a useful assumption, at least in
as much as they need to provide at a solid basic toolkit to accompany
the engine.


Well, the engine is pretty useless in isolation without tools to be able 
to build apps with it (unless of course you are happy with restricting 
yourself to script libraries and using a text editor - which whilst 
appropriate for some endeavours, for most purposes it would be extremely 
tedious).



I've been using my own tools within every xTalk IDE I've used, and as
long as frontScripts work and we pass messages as good citizens do,
there's an opportunity to have LESS dependence on a large IDE
framework rather than more.  Or if we were to be thorough, a fairly
slender one.


I think you might be confusing 'IDE' with 'IDE Framework' here - they 
are two quite distinct things.



Tools can be entirely self-contained and fully interchangeable, even
open at the same time, using nothing more than what the engine has
provided for years.


Really? Are you sure that is true?

So you would have every 'application browser' type tool implement its 
own code for monitoring for changes in the user stacks, and for 
collecting all the data about the objects in user stacks?


You would have every 'tools palette' type tool implement its own code to 
go digging around on disk for all extensions, listing, enumerating and 
providing an ability to create them?


You would have every 'documentation palette' type tool implements its 
own code to go digging around on disk for the content it needs to 
display, and then its own code for processing that content into the form 
it wishes to display?


You would have every 'standalone builder palette' type tool implement 
its own code for building standalones?


You would have every palette which wants a button on some sort of 
'launcher stack' have to understand how every 'independent' launcher 
stack needs to be told to add its button?


And assuming you would have that, how do you ensure that all these 
components which can be used in a 'fully interchangeable' and in an 
entirely 'self-contained' fashion don't actually interfere with each 
other to the detriment of the user stacks they are acting upon?


In order for any system to work where you can plug-and-play components 
from different sources you need to have a common basis of communication 
which provides the basic services all the components need to ensure that 
they can be used together in the same environment without conflict. 
Also, you need to ensure that said set of basic services is rich enough 
that those that wish to write such components don't spend most of their 
time re-inventing the wheel and can focus entirely on the purpose of 
their component.


Now, I see that you appear to regard the 'engine' with some sort of 
magical prowess. Indeed, it does provide a 'standard' interface to a 
common set of functionality that is exposed through its object model and 
syntax; however, I'd assert that the engine's interface is not at a 
high-enough level right now to give you what is needed for what you 
dream of in terms of the 'bit that binds all these decentralised built 
components together'. Thus any solution which provides the above 
'nirvana' in terms of interchangeable tools will end up relying on a 
collection of script libraries which everyone's tools rely on and use to 
ensure they can all co-exist together - i.e. you end up with precisely 
the IDE Framework that I've been talking about.


It is important to remember that 'framework' means precisely that - it 
is scaffolding, policy, and ancillary services. A 'framework' is just 
there to ensure that everything works together for its particular end 
purpose - and good ones interfere as little as possible with the actual 
action of the components which sit within them.


Ideally, of course, the 'engine' would provide such an appropriate 
high-level interface - a strong API - for tools written by disparate 
parties acting together in a single environment to give users complete 
choice in their toolkit for creating LiveCode applications...


... Sounds like a good way to approach that (given how much faster it is 
to write LiveCode Script than C++) would be to provide the engine with a 
standard set of script libraries which present a suitable high-level 
interface for building IDE Tools to ensure tool writers (including 
ourselves) can easily build tools...


... Which is rather like what we've been working on in the LC8 IDE ;)

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: LC 8 Property Inspector

[Richard Gaskin]

Peter Haworth wrote:
> The publish/subscribe stuff sounds great, especially since I just
> found no newxxx messages are sent when creating a control from the
> tools palette.

I just ran a test:

1. Create a new stack

2. In the card script, add this:

on newButton
  put the params && the millisecs
end newButton

3. Drag a button from the LC IDE Tools palette onto the card

Here the Message Box appears with "newbutton  1444741892267"

What do you see?

--
 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: LC 8 Property Inspector

[Peter Haworth]

I see nothing. My bug report has been confirmed so not sure why you see a
message. Were you using lc8 dp7?

On Tue, Oct 13, 2015, 6:12 AM Richard Gaskin 
wrote:

> Peter Haworth wrote:
>  > The publish/subscribe stuff sounds great, especially since I just
>  > found no newxxx messages are sent when creating a control from the
>  > tools palette.
>
> I just ran a test:
>
> 1. Create a new stack
>
> 2. In the card script, add this:
>
> on newButton
>put the params && the millisecs
> end newButton
>
> 3. Drag a button from the LC IDE Tools palette onto the card
>
> Here the Message Box appears with "newbutton  1444741892267"
>
> What do you see?
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Richard Gaskin]

Mark Waddingham wrote:

On 2015-10-12 22:31, Richard Gaskin wrote:

That's an obvious option if we assume there must be only one IDE.  And
from the company's perspective that's a useful assumption, at least in
as much as they need to provide at a solid basic toolkit to accompany
the engine.


Well, the engine is pretty useless in isolation without tools to be able
to build apps with it (unless of course you are happy with restricting
yourself to script libraries and using a text editor - which whilst
appropriate for some endeavours, for most purposes it would be extremely
tedious).


Of course, which is why I wrote "they need to provide at a solid basic 
toolkit to accompany the engine".


Thumbs up on the team's continued IDE efforts.

Noting I've written is an "or". merely a "yes, and"



I've been using my own tools within every xTalk IDE I've used, and as
long as frontScripts work and we pass messages as good citizens do,
there's an opportunity to have LESS dependence on a large IDE
framework rather than more.  Or if we were to be thorough, a fairly
slender one.


I think you might be confusing 'IDE' with 'IDE Framework' here - they
are two quite distinct things.


Tools can be entirely self-contained and fully interchangeable, even
open at the same time, using nothing more than what the engine has
provided for years.


Really? Are you sure that is true?

So you would have every 'application browser' type tool implement its
own code for monitoring for changes in the user stacks, and for
collecting all the data about the objects in user stacks?

You would have every 'tools palette' type tool implement its own code to
go digging around on disk for all extensions, listing, enumerating and
providing an ability to create them?

You would have every 'documentation palette' type tool implements its
own code to go digging around on disk for the content it needs to
display, and then its own code for processing that content into the form
it wishes to display?

You would have every 'standalone builder palette' type tool implement
its own code for building standalones?

You would have every palette which wants a button on some sort of
'launcher stack' have to understand how every 'independent' launcher
stack needs to be told to add its button?

And assuming you would have that, how do you ensure that all these
components which can be used in a 'fully interchangeable' and in an
entirely 'self-contained' fashion don't actually interfere with each
other to the detriment of the user stacks they are acting upon?

In order for any system to work where you can plug-and-play components
from different sources you need to have a common basis of communication
which provides the basic services all the components need to ensure that
they can be used together in the same environment without conflict.
Also, you need to ensure that said set of basic services is rich enough
that those that wish to write such components don't spend most of their
time re-inventing the wheel and can focus entirely on the purpose of
their component.

Now, I see that you appear to regard the 'engine' with some sort of
magical prowess. Indeed, it does provide a 'standard' interface to a
common set of functionality that is exposed through its object model and
syntax; however, I'd assert that the engine's interface is not at a
high-enough level right now to give you what is needed for what you
dream of in terms of the 'bit that binds all these decentralised built
components together'. Thus any solution which provides the above
'nirvana' in terms of interchangeable tools will end up relying on a
collection of script libraries which everyone's tools rely on and use to
ensure they can all co-exist together - i.e. you end up with precisely
the IDE Framework that I've been talking about.

It is important to remember that 'framework' means precisely that - it
is scaffolding, policy, and ancillary services. A 'framework' is just
there to ensure that everything works together for its particular end
purpose - and good ones interfere as little as possible with the actual
action of the components which sit within them.

Ideally, of course, the 'engine' would provide such an appropriate
high-level interface - a strong API - for tools written by disparate
parties acting together in a single environment to give users complete
choice in their toolkit for creating LiveCode applications...

... Sounds like a good way to approach that (given how much faster it is
to write LiveCode Script than C++) would be to provide the engine with a
standard set of script libraries which present a suitable high-level
interface for building IDE Tools to ensure tool writers (including
ourselves) can easily build tools...

... Which is rather like what we've been working on in the LC8 IDE ;)

Warmest Regards,

Mark.


I refer to the engine with admiration only because we all understand 
that it's what runs all scripts, including those in an IDE.  I rather 
like LiveCode Script, and 

Re: LC 8 Property Inspector

[Richard Gaskin]

Peter Haworth wrote:
> I see nothing. My bug report has been confirmed so not sure why you
> see a message. Were you using lc8 dp7?

Ah, thanks - that's it.  I'm using the current shipping product, v7.1.

--
 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: LC 8 Property Inspector

[Richard Gaskin]

Peter TB Brett wrote:

> Hi Richard,
>
> Just because LiveCode 8 hasn't got all its eventual features yet
> doesn't mean it can't, or indeed shouldn't, be used for creating and
> shipping production apps. Many people are doing so quite successfully.
>
> "Developer Preview" is actually a misleading term for describing
> LiveCode 8's current state.  We both sell and provide full support
> for LiveCode 8, and in that respect it's certainly a "shipping
> product".

Yes, good point.  I understand this audience is quite diverse and folks 
use a lot of different versions.  A lot of folks I know still use v6.x, 
and I have one friend who continued to ship with v5.5.4.


I didn't mean to imply that v8 wasn't supported, merely that it does 
seem to have a lot of regressions (understandable at this stage), so it 
seems helpful to manage expectations while those are being sorted out.



> However, we reserve the option to change its behaviour. With LiveCode
> 7, which is "stable", we don't have that luxury.

True, but most of my friends and clients have tons of good work they can 
do in v7 as its Dictionary defines it right now.  We just need to make 
sure it does what the Dictionary says it does, so it's reassuring to see 
that the v7 engine being the foundation for v8 is paying off nicely for 
both versions.


--
 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: LC 8 Property Inspector

[Richard Gaskin]

Mark Wieder wrote:

On 10/12/2015 01:31 PM, Richard Gaskin wrote:


1. How do we open them?  Currently third-party tools are relegated to
the Plugins submenu, but crafting a launcher tool rack is simple
stuff, and equally simple to just hide the current IDE's toolbar
(which I've been doing for years - I go weeks at a time without ever
seeing it).


Check out some things in the revIDELibrary. For instance, the
revIDEPaletteToStackName() and revIDEAvailablePalettes() functions.
They're hard-coded for now, but the plan is to open them up when the
references in the IDE stacks are refactored. And look at the publish
and subscribe functions as well, which will allow IDE component
replacements to register interest in certain IDE messages and respond
to them.



A while back I was reading about Linux' ibus and got inspired to start 
playing around with an experimental library for a similar system in 
LiveCode, a sort of "message bus" where one could define messages as 
hierarchical paths and assign listeners to them at any point in the path.


For example, imagine a set of message buses defined as:

   /ide/tools/init
   /ide/tools/update
   /app/data/recordChanged
   /app/data/tableChanged
   /ahsoftware/glx/scriptChanged

With those, any IDE tool palette could subscribe to the first two buses, 
your app's data views could subscribe to that third and fourth buses, 
anything that needs to know when a script has changed in your editor 
could subscribe to that last bus.


But with these "message buses" expressed as hierarchies, anything that 
needs notification of any GLX messages could just subscribe to 
"/ahsoftware/glx" without having to bind to every message individually, 
and receive all messages sent to that path or anything below it.


Similarly, IDE tools could subscribe to /ide/tools to get all 
tool-related message, and an app's data views might subscribe to 
/app/data to get all of those notifications.


Generic bus monitoring tools could be made by binding to "/".

When a subscribed object receives the dispatched message, the message 
itself is just the last element in the path (e.g., "scriptChanged").  In 
cases where an object may need to distinguish between messages which may 
have the same name but coming from different parts of the bus hierarchy 
a function is provided to obtain the full path of the dispatched message.


My current implementation only handles messages and managing 
subscriptions to them, but it wouldn't be hard to borrow other ideas 
from ibus to include data at those paths as well, or even metadata which 
might contain the long ID of the sender and a timestamp of when that 
data changed.


It would seem a lot of things might become much simpler with 
hierarchical binding.


If this seems useful to anyone I'll see if I can get some time to put 
together a demo stack more usable than my thrown-together unlabeled 
buttons and post it somewhere.


--
 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: LC 8 Property Inspector

[Peter TB Brett]

Hi Richard,

Just because LiveCode 8 hasn't got all its eventual features yet doesn't mean 
it can't, or indeed shouldn't, be used for creating and shipping production 
apps. Many people are doing so quite successfully.

"Developer Preview" is actually a misleading term for describing LiveCode 8's 
current state.  We both sell and provide full support for LiveCode 8, and in 
that respect it's certainly a "shipping product".

However, we reserve the option to change its behaviour. With LiveCode 7, which 
is "stable", we don't have that luxury.

Peter

On 13 October 2015 16:37:12 BST, Richard Gaskin  
wrote:
>Peter Haworth wrote:
> > I see nothing. My bug report has been confirmed so not sure why you
> > see a message. Were you using lc8 dp7?
>
>Ah, thanks - that's it.  I'm using the current shipping product, v7.1.
>
>-- 
>  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

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

Re: LC 8 Property Inspector

[Richard Gaskin]

Correction - I had written:

  A lot of folks I know still use v6.x, and I have one friend
  who continued to ship with v5.5.4.

That sentence makes more sense when I type the "s" I'd intended rather 
than a "d":


  A lot of folks I know still use v6.x, and I have one friend
  who continues to ship with v5.5.4.


One of the things I like about the forums is that I can safely write 
posts there before coffee, knowing I can clean up my typos later. :)


--
 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: LC 8 Property Inspector

[Richard Gaskin]

Mark Waddingham wrote:

On 2015-10-10 22:12, Richard Gaskin wrote:

Weirdest: Replace the IDE with the best of community components
---
Like the "Weirder" option above, this would be independent of the
product build, but would open the door for anyone to do whatever they
want.  Bjornke's BVGDocu could replace the Dictionary, Peter's
lcStackBrowser could replace the App and Proj browsers, your GLX2
editor could replace the Script Editor, etc.

...

It's like the thing I like most about Linux:  although people in the
Linux world enjoy arguing about darn near everything, the fact is
there's actually little to argue about since the system is so flexible
and has so many components available there's no reason why everyone
can't have exactly what they most desire.


The obvious option (which is the one we have been working towards in the
LC8 IDE) is that the IDE becomes a 'framework'. It provides well defined
extension points, well defined APIs for building IDE components, and a
well defined mechanism to ensure that changes flow properly so all
components are kept synchronized.

The IDE framework has to be the arbiter which ensures that two distinct
IDE components (which could be written and maintained by people who
never speak to each other) can happily co-exist with each other in an
end-user's install.


That's an obvious option if we assume there must be only one IDE.  And 
from the company's perspective that's a useful assumption, at least in 
as much as they need to provide at a solid basic toolkit to accompany 
the engine.


The community, however, has more flexibility.

There used to be three IDEs for this engine, and Python, Ruby, and 
others have far more.


I've been using my own tools within every xTalk IDE I've used, and as 
long as frontScripts work and we pass messages as good citizens do, 
there's an opportunity to have LESS dependence on a large IDE framework 
rather than more.  Or if we were to be thorough, a fairly slender one.


Tools can be entirely self-contained and fully interchangeable, even 
open at the same time, using nothing more than what the engine has 
provided for years.


The only questions here are:

1. How do we open them?  Currently third-party tools are relegated to 
the Plugins submenu, but crafting a launcher tool rack is simple stuff, 
and equally simple to just hide the current IDE's toolbar (which I've 
been doing for years - I go weeks at a time without ever seeing it).


2. Make sure the current IDE stays out of the way. This is the harder 
part, but not insurmountable, and since the goal of this "Weirdest" 
option is to encourage a new community-based exploratory playground of 
an IDE, ultimately the monolithic product version would be replaced over 
time within this one anyway, at least among the weirdos who like such 
things.  And given the number of good tools in the community right now, 
it seems there are more than a few weirdos among us. :)


This "Weirdest" option isn't for everyone, and that's very much the 
idea, that IDEs are simple enough in a language as flexible as LiveCode 
that we can several for every taste.


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

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

Re: LC 8 Property Inspector

[Mark Wieder]

On 10/12/2015 01:31 PM, Richard Gaskin wrote:


1. How do we open them?  Currently third-party tools are relegated to
the Plugins submenu, but crafting a launcher tool rack is simple stuff,
and equally simple to just hide the current IDE's toolbar (which I've
been doing for years - I go weeks at a time without ever seeing it).


Check out some things in the revIDELibrary. For instance, the 
revIDEPaletteToStackName() and revIDEAvailablePalettes() functions. 
They're hard-coded for now, but the plan is to open them up when the 
references in the IDE stacks are refactored. And look at the publish and 
subscribe functions as well, which will allow IDE component replacements 
to register interest in certain IDE messages and respond to them.


--
 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: LC 8 Property Inspector

[Peter Haworth]

The publish/subscribe stuff sounds great, especially since I just found no
newxxx messages are sent when creating a control from the tools palette.

On Mon, Oct 12, 2015, 7:11 PM Mark Wieder  wrote:

> On 10/12/2015 01:31 PM, Richard Gaskin wrote:
>
> > 1. How do we open them?  Currently third-party tools are relegated to
> > the Plugins submenu, but crafting a launcher tool rack is simple stuff,
> > and equally simple to just hide the current IDE's toolbar (which I've
> > been doing for years - I go weeks at a time without ever seeing it).
>
> Check out some things in the revIDELibrary. For instance, the
> revIDEPaletteToStackName() and revIDEAvailablePalettes() functions.
> They're hard-coded for now, but the plan is to open them up when the
> references in the IDE stacks are refactored. And look at the publish and
> subscribe functions as well, which will allow IDE component replacements
> to register interest in certain IDE messages and respond to them.
>
> --
>   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: LC 8 Property Inspector

[Mark Waddingham]

On 2015-10-10 22:12, Richard Gaskin wrote:

Weirdest: Replace the IDE with the best of community components
---
Like the "Weirder" option above, this would be independent of the
product build, but would open the door for anyone to do whatever they
want.  Bjornke's BVGDocu could replace the Dictionary, Peter's
lcStackBrowser could replace the App and Proj browsers, your GLX2
editor could replace the Script Editor, etc.

...

It's like the thing I like most about Linux:  although people in the
Linux world enjoy arguing about darn near everything, the fact is
there's actually little to argue about since the system is so flexible
and has so many components available there's no reason why everyone
can't have exactly what they most desire.


The obvious option (which is the one we have been working towards in the 
LC8 IDE) is that the IDE becomes a 'framework'. It provides well defined 
extension points, well defined APIs for building IDE components, and a 
well defined mechanism to ensure that changes flow properly so all 
components are kept synchronized.


The IDE framework has to be the arbiter which ensures that two distinct 
IDE components (which could be written and maintained by people who 
never speak to each other) can happily co-exist with each other in an 
end-user's install.


In particular, this means that IDE components *cannot* patch random 
parts of the IDE (as they might conflict), and any points within the IDE 
which might be usefully customized (e.g. adding extra buttons to 
revMenubar) need to be explicitly exposed in a well-defined way.


Now a lot of work has been done towards this, but at the moment if you 
want to play with it you have to do a bit of digging around in the 
libraries which are emerging (revidelibrary, revideextensionlibrary 
etc.) and the revised components which use these new APIs. Admittedly we 
aren't quite there yet as it does take time to introduce good 
abstractions into code which did not have them before (well, not ones 
which were suitable for a more step-back and provide the ability for 
anyone to extend point of view at least).


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: LC 8 Property Inspector

[Mark Wieder]

On 10/10/2015 01:12 PM, Richard Gaskin wrote:


Weirdest: Replace the IDE with the best of community components
---
Like the "Weirder" option above, this would be independent of the
product build, but would open the door for anyone to do whatever they
want.  Bjornke's BVGDocu could replace the Dictionary, Peter's
lcStackBrowser could replace the App and Proj browsers, your GLX2 editor
could replace the Script Editor, etc.

At that point the IDE becomes a very slender thing, just a tool rack on
which we hang our own tools.  And the tools within it would not only be
the best of what the community has to offer, but could also be
interchangeable.


That, I think is what Ali was implying. There is indeed movement in that 
direction in the IDE... what with publish and subscribe mechanisms and a 
palette abstraction layer... admittedly it's a long ways off yet. The 
palettes are hard-coded for now, and there's still a lot in the IDE that 
doesn't use the abstraction layer: for instance, the newTool handler 
goes directly to the "revTools" stack instead of querying for the 
palette, but I do see some light at the end of a long tunnel.


--
 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: LC 8 Property Inspector

[Mark Wieder]

On 10/09/2015 12:35 AM, Ali Lloyd wrote:


There are two separate issues here:
1) Our out-of-the-box palettes should be as useful as possible for someone
with no plugins. Hence the soliciting of opinion. Disagree? I'm happy for a
million application browsers to exist, I just don't want to maintain them.


Heh.


I can't understand how you're viewing the idea of seeking to improve the
IDE's palettes as somehow a negative.

2) Making it possible to replace the palettes. Gradually the IDE routes all
palette-related opening through a revIDEPaletteToStackName function. So
once everything goes through that, and we provide a hook to override it,
you will be able to use any stack in place of a given palette.

Moreover the better the data provision for *our* palettes, the more useful
IDE functions there are for replacement palettes to use. Whatever we add to
a given object's inspector properties, for example, is parsed into the
properties array that the IDE library passes to the inspector.

Should a user plugin wish to use that array, adding the tooltip fixes it
for them too. Adding tooltip to the old inspector helps no-one in this
particular regard, as far as I can see.


Thanks for the background information. This is indeed promising for the 
future. But we have reached the point where LC8 is no longer "LC7 with 
widgets"... there's a serious divide here. So while I can play around 
with LC8 and try to figure out the new gadgety things that are being 
thrown our way, in order to get any work done I'm using tools that will 
soon be end-of-lifed.


I'm no fan of the current property inspector. Or the application 
browser, for that matter. But right now they allow me to get work done. 
So I'm a bit dismayed that rather than fixing/improving these tools, 
they've just been replaced wholesale, and judging by the controversy 
this has raised it appears I'm not alone. I'm sure I'll get used to the 
new tools in time, although I've been able to avoid the Project Browser 
in all versions up to the latest.


--
 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: LC 8 Property Inspector

[Richard Gaskin]

Mark Wieder wrote:

> ...we have reached the point where LC8 is no longer "LC7 with
> widgets"... there's a serious divide here. So while I can play
> around with LC8 and try to figure out the new gadgety things
> that are being thrown our way, in order to get any work done
> I'm using tools that will soon be end-of-lifed.
>
> I'm no fan of the current property inspector. Or the application
> browser, for that matter. But right now they allow me to get
> work done.
> So I'm a bit dismayed that rather than fixing/improving these tools,
> they've just been replaced wholesale, and judging by the controversy
> this has raised it appears I'm not alone.

I see three options, listed here in order of ascending weirdness, though 
I feel obliged to note that "weird" simply means "of or pertaining to 
the supernatural", which is not necessarily a bad thing:



Weird: Finish Github-compatible tools to allow community contributions
--
Given the variety of array-based and XML-based tools we already have for 
comparing stack files, and that all that needs to happen is some way to 
help the team identify and review changes efficiently, this may not be 
quite as onerous as it once seemed if managed by competent trusted 
community members in a check-in/check-out workflow.



Weirder: Fork the IDE and maintain it through any convenient means
--
The longest-running open source project in the history of the LiveCode 
engine was the MetaCard IDE, managed through an informal 
check-in/check-out process using technology no more sophisticated than 
email.  True, the MC IDE was a far less complex beast, but we were kids 
with far less experience. :)  We can't expect the company to fold our 
updated IDE into the product build (thought they're welcome to if they 
like and perhaps it may be very cost-effective to consider it), but at a 
minimum we could make a simple plugin that installs it and updates 
independently of the product build, just as Jacque did with her MC Setup 
plugin (available in RevOnline).



Weirdest: Replace the IDE with the best of community components
---
Like the "Weirder" option above, this would be independent of the 
product build, but would open the door for anyone to do whatever they 
want.  Bjornke's BVGDocu could replace the Dictionary, Peter's 
lcStackBrowser could replace the App and Proj browsers, your GLX2 editor 
could replace the Script Editor, etc.


At that point the IDE becomes a very slender thing, just a tool rack on 
which we hang our own tools.  And the tools within it would not only be 
the best of what the community has to offer, but could also be 
interchangeable.


I started down this road with the latest version of my devolution 
toolkit, but since I already have it set up with my own favorites I 
haven't spent the time finishing that part of it (see the disabled group 
in the middle of this Prefs window):



The idea there is that the option controls allow the user to pick the 
built-in IDE tool, or any plugin, to be opened when clicking the 
corresponding button to the left.


Finishing something like that wouldn't be hard, merely tedious, so you'd 
be able to assign any stacks to specific menu and/or buttons used to 
access them.


The weird soul using such an IDE could keep any LC parts if they like, 
or replace any parts with any suitably robust plugin, according to their 
whims.


It's like the thing I like most about Linux:  although people in the 
Linux world enjoy arguing about darn near everything, the fact is 
there's actually little to argue about since the system is so flexible 
and has so many components available there's no reason why everyone 
can't have exactly what they most desire.


--
 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: LC 8 Property Inspector

[Ali Lloyd]

On Fri, Oct 9, 2015 at 3:23 AM Mark Wieder  wrote:
>It seems from the App Browser / Project Browser and Property Inspector
>arguments that I've been expecting too much, and we really can't have
>alternatives.

I have no idea why you've drawn this conclusion, as I've repeatedly told
you and said elsewhere that this is not the case.

There are two separate issues here:
1) Our out-of-the-box palettes should be as useful as possible for someone
with no plugins. Hence the soliciting of opinion. Disagree? I'm happy for a
million application browsers to exist, I just don't want to maintain them.
I can't understand how you're viewing the idea of seeking to improve the
IDE's palettes as somehow a negative.

2) Making it possible to replace the palettes. Gradually the IDE routes all
palette-related opening through a revIDEPaletteToStackName function. So
once everything goes through that, and we provide a hook to override it,
you will be able to use any stack in place of a given palette.

Moreover the better the data provision for *our* palettes, the more useful
IDE functions there are for replacement palettes to use. Whatever we add to
a given object's inspector properties, for example, is parsed into the
properties array that the IDE library passes to the inspector.

Should a user plugin wish to use that array, adding the tooltip fixes it
for them too. Adding tooltip to the old inspector helps no-one in this
particular regard, as far as I can see.


On 10/08/2015 02:14 AM, Ali Lloyd wrote:
>
> > 2) The new inspector is *really* flexible for the classic objects. Have a
> > look at this fix for bug 16118 (no way to change a scrollbar's tooltip in
> > the property inspector):
> > https://github.com/livecode/livecode-ide/pull/562/files
>
>
>
> > We'd like to make it as good and useful as possible. If the worst you can
> > say is you can't see any advantages, then I think the non-obvious ones
> > above make it well worth it ;-) Otherwise it would be great to hear
> > constructive criticism and suggestions for improvement.
>
> Well, I've been thinking of the the new IDE framework as just being that
> and allowing for plugin replacement of the various components.
>
> --
>   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: LC 8 Property Inspector

[Richard Gaskin]

Peter Haworth wrote:
> Would be great if you get flexible groupings going.  Having been
> through implementing this, one thing to watch out for is that there
> isn't a way to get a complete list of properties for a particular
> object type.

I know some synonyms are missing, but the properties function was added 
to allow rapid reproduction of an object, so while it may not substitute 
for the Dictionary it should be at least functional for most practical 
development uses.


What properties does a developer need that aren't included?

Let's bug report those and get it behind us.

--
 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: LC 8 Property Inspector

[Peter Haworth]

I've filed several bug reports over the last couple of years regarding
missing properties, mostly related to propertynames and glad to say they
have all been fixed so things are a lot better now than they used to be.
The propertynames still includes things that don't seem like properties to
me, "abbrev" and "working" for example, but no doubt there's a good reason
for that

Regarding your question on which properties are missing that a developer
needs, the answer for me is all the ones that are no longer returned by the
properties of an object and here's why.

As I've mentioned in other emails on this thread, lcStackbrowser gives
users the flexibility to organize properties into groups.  I do this by
displaying a list of all the properties for a particular object type, from
which users can drag and drop their chosen properties into a group list.  I
get that list from the keys of the properties array for the template for
whatever type of object I'm dealing with, but with this change, the list
was suddenly incomplete.

As an example, the height and width properties are no longer included.
Their values can be derived from the rectangle property which is fine if
you want to recreate an object or use their values for some other reason
but I need their names, not their values.

I ended up writing a handler that goes through the propertynames list and
tries to set each one into each of the object templates to determine which
object types it applies to, a time consuming process that really shouldn't
be necessary.

That's all water under the bridge now but I still don't understand why the
contents of the properties property were changed.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Fri, Oct 9, 2015 at 8:46 AM, Richard Gaskin 
wrote:

> Peter Haworth wrote:
> > Would be great if you get flexible groupings going.  Having been
> > through implementing this, one thing to watch out for is that there
> > isn't a way to get a complete list of properties for a particular
> > object type.
>
> I know some synonyms are missing, but the properties function was added to
> allow rapid reproduction of an object, so while it may not substitute for
> the Dictionary it should be at least functional for most practical
> development uses.
>
> What properties does a developer need that aren't included?
>
> Let's bug report those and get it behind us.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Richard Gaskin]

Peter Haworth wrote:


As I've mentioned in other emails on this thread, lcStackbrowser gives
users the flexibility to organize properties into groups.  I do this by
displaying a list of all the properties for a particular object type, from
which users can drag and drop their chosen properties into a group list.  I
get that list from the keys of the properties array for the template for
whatever type of object I'm dealing with, but with this change, the list
was suddenly incomplete.

As an example, the height and width properties are no longer included.
Their values can be derived from the rectangle property which is fine if
you want to recreate an object or use their values for some other reason
but I need their names, not their values.

I ended up writing a handler that goes through the propertynames list and
tries to set each one into each of the object templates to determine which
object types it applies to, a time consuming process that really shouldn't
be necessary.


Personally I feel your approach is quite suitable.

The properties function returns the things needed to reproduce an 
object.  It's not designed to replace the Dictionary, nor encumbered 
with a responsibility to make crafting IDE tools a one-liner.


Toolmaking requires writing code. Any of us making tools - you, me, LC 
Ltd. - wrote some code to take care of what we need and moved on to 
other tasks.


Seems a good balance of effort on all sides.



That's all water under the bridge now but I still don't understand why the
contents of the properties property were changed.


What specifically was the change, and in what version?

--
 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: LC 8 Property Inspector

[Peter Haworth]

On Fri, Oct 9, 2015 at 10:24 AM, Richard Gaskin 
wrote:

> What specifically was the change, and in what version?


The change was that not all properties are returned.  I believe it was in v
6.1.

As I said in my previous post, it's water under the bridge for me now and I
have, as you mentioned, moved on to other tasks.  My original post on this
was simply to point out to the team that if they plan to provide a feature
to allow flexible grouping of properties, they should be aware of this
issue if they plan to rely on the properties property. My last post was
simply in response to your request to elaborate.

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

Re: LC 8 Property Inspector

[J. Landman Gay]

On 10/9/2015 12:57 PM, Peter Haworth wrote:

The change was that not all properties are returned.  I believe it was in v
6.1.


That's odd, I thought it had always been the way it is now. I just 
checked with Rev 2.8.1 (Jan 2005) and it does not have "width" in the 
properties of an object. My test wasn't very comprehensive though..


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

LC 8 Property Inspector

[Ali Lloyd]

So that this does not get lost in the Project Browser / App Browser thread,
I've split it off into a separate topic:

On Wed, Oct 7, 2015 at 8:04 PM Richmond  wrote:

> While I'm on a roll, I could also point out that I cannot see any
> obvious advantages in the complete
> remake of the Preference Palette in LiveCode 8.


There may not be many immediately obvious advantages to the new property
inspector, but there are two extraordinarily significant related ones:

1) Widget properties would not work with the old inspector. You would
perhaps have to create individual stacks for each widget and have its card
copied to the inspector. This is really not practical or viable in the long
term.

The new inspector just requires a few lines of metadata in the widget file
specifying what type of editor to use for a given property. Everything else
happens automatically.

2) The new inspector is *really* flexible for the classic objects. Have a
look at this fix for bug 16118 (no way to change a scrollbar's tooltip in
the property inspector):
https://github.com/livecode/livecode-ide/pull/562/files


We'd like to make it as good and useful as possible. If the worst you can
say is you can't see any advantages, then I think the non-obvious ones
above make it well worth it ;-) Otherwise it would be great to hear
constructive criticism and suggestions for improvement.

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

Re: LC 8 Property Inspector

[Richmond]

On 08/10/15 12:14, Ali Lloyd wrote:

So that this does not get lost in the Project Browser / App Browser thread,
I've split it off into a separate topic:

On Wed, Oct 7, 2015 at 8:04 PM Richmond  wrote:


While I'm on a roll, I could also point out that I cannot see any
obvious advantages in the complete
remake of the Preference Palette in LiveCode 8.


There may not be many immediately obvious advantages to the new property
inspector, but there are two extraordinarily significant related ones:

1) Widget properties would not work with the old inspector. You would
perhaps have to create individual stacks for each widget and have its card
copied to the inspector. This is really not practical or viable in the long
term.

The new inspector just requires a few lines of metadata in the widget file
specifying what type of editor to use for a given property. Everything else
happens automatically.

2) The new inspector is *really* flexible for the classic objects. Have a
look at this fix for bug 16118 (no way to change a scrollbar's tooltip in
the property inspector):
https://github.com/livecode/livecode-ide/pull/562/files


We'd like to make it as good and useful as possible. If the worst you can
say is you can't see any advantages, then I think the non-obvious ones
above make it well worth it ;-) Otherwise it would be great to hear
constructive criticism and suggestions for improvement.

Ali
___



While your points #1 and #2 are true, I'm sure, that does not explain 
why the RunRev team decided

their had to be a complete overhaul in what the thing looked like . . .

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: LC 8 Property Inspector

[Richmond]

http://forums.livecode.com/viewtopic.php?f=6=25526

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

Re: LC 8 Property Inspector

[Rick Harrison]

Hi Richmond,

I looked at the differences in these inspectors
and I came to the conclusion that the new
version is not an improvement.  What was
clear and everyone was used to in the old
version with the words has now been replaced
with smaller icons in the new version. 

While I’m sure we will adjust eventually to
the new version, more silly icons isn’t what
we need.  The human brain has to do the
translation. I’m sure a text tool tip will magically
appear to tell us what the icon means after
a short delay, (I hope), but it won’t speed
along productivity for anyone.

Just my 2 cents.  ;-)

Rick

> On Oct 8, 2015, at 7:31 AM, Richmond  wrote:
> 
> http://forums.livecode.com/viewtopic.php?f=6=25526
> 


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

Re: LC 8 Property Inspector

[Trevor DeVore]

On Thu, Oct 8, 2015 at 11:16 AM, Rick Harrison 
wrote:

>
> I looked at the differences in these inspectors
> and I came to the conclusion that the new
> version is not an improvement.  What was
> clear and everyone was used to in the old
> version with the words has now been replaced
> with smaller icons in the new version.
>
> While I’m sure we will adjust eventually to
> the new version, more silly icons isn’t what
> we need.  The human brain has to do the
> translation. I’m sure a text tool tip will magically
> appear to tell us what the icon means after
> a short delay, (I hope), but it won’t speed
> along productivity for anyone.
>

Rick,

I've actually found the new interface to be much more productive. I always
found that using an option menu to switch property inspector panes was
tedious as it required multiple clicks. Switching around between panes in
the inspector is much quicker now.

-- 
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: LC 8 Property Inspector

[Ali Lloyd]

One thing we can easily do is have a preference which allows you to switch
to the section names instead of icons.

On Thu, Oct 8, 2015 at 4:36 PM Trevor DeVore 
wrote:

> On Thu, Oct 8, 2015 at 11:16 AM, Rick Harrison 
> wrote:
>
> >
> > I looked at the differences in these inspectors
> > and I came to the conclusion that the new
> > version is not an improvement.  What was
> > clear and everyone was used to in the old
> > version with the words has now been replaced
> > with smaller icons in the new version.
> >
> > While I’m sure we will adjust eventually to
> > the new version, more silly icons isn’t what
> > we need.  The human brain has to do the
> > translation. I’m sure a text tool tip will magically
> > appear to tell us what the icon means after
> > a short delay, (I hope), but it won’t speed
> > along productivity for anyone.
> >
>
> Rick,
>
> I've actually found the new interface to be much more productive. I always
> found that using an option menu to switch property inspector panes was
> tedious as it required multiple clicks. Switching around between panes in
> the inspector is much quicker now.
>
> --
> 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
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[J. Landman Gay]

On 10/8/2015 10:36 AM, Trevor DeVore wrote:

On Thu, Oct 8, 2015 at 11:16 AM, Rick Harrison 
wrote:



I looked at the differences in these inspectors
and I came to the conclusion that the new
version is not an improvement.  What was
clear and everyone was used to in the old
version with the words has now been replaced
with smaller icons in the new version.

While I’m sure we will adjust eventually to
the new version, more silly icons isn’t what
we need.  The human brain has to do the
translation. I’m sure a text tool tip will magically
appear to tell us what the icon means after
a short delay, (I hope), but it won’t speed
along productivity for anyone.



Rick,

I've actually found the new interface to be much more productive. I always
found that using an option menu to switch property inspector panes was
tedious as it required multiple clicks. Switching around between panes in
the inspector is much quicker now.



I have to mostly agree with Trevor here. The very first property 
inspector had tabs for navigating panes and it was much faster and 
easier to use. But as new panes were added there was no longer enough 
horizontal space so tabs were replaced by the option menu. This has 
always been awkward to use and there were some complaints about it at 
first. Icons allow us to return to the original quick navigation we used 
to have, so I'm in favor of them -- provisionally.


But as Rick said, it's not always easy to identify icons. Tooltips are a 
must until we learn what they are. But even better would be icons with 
labels, like the IDE toolbar has.


--
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: LC 8 Property Inspector

[Roger Guay]

> On Oct 8, 2015, at 10:50 AM, J. Landman Gay  wrote:
> 
> But as Rick said, it's not always easy to identify icons. Tooltips are a must 
> until we learn what they are. But even better would be icons with labels, 
> like the IDE toolbar has.


Sometimes, a word is worth a thousand pictures!

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: LC 8 Property Inspector

[J. Landman Gay]

On 10/8/2015 11:21 AM, Ali Lloyd wrote:

One thing we can easily do is have a preference which allows you to switch
to the section names instead of icons.


I'd be all for that, if labelled icons aren't possible.

--
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: LC 8 Property Inspector

[Richard Gaskin]

Ali Lloyd wrote:

> Labelled icons are also possible - we could potentially have a
> preference setting for one, the other, or both.

Inspectors are very useful in consumer apps, where the range of 
properties is often smaller and their scope less broad.


In development tools we often see a Property Sheet that shows all 
properties, as opposed to the subset we've had available in all 
Inspectors thus far.


Here's an implementation I've been using whenever I need things not 
found in any Inspector:



The design is largely functional, but suboptimal.  Time permitting it 
would group related properties together under collapsible headers.


And when you think about, even if the Inspector were to continue to 
limit itself to a subset of object properties, once you start down the 
road of horizontal labels the design screams for such an accordion 
design anyway.


Using that according design within a scrollable Property Sheet allows 
for most of what folks are looking for here:


- Ease of access
- Clear labels for related properties

...and adds something that I don't recall coming up here yet but would 
sooner or later:


- Completeness, the ability to see all of an object's properties

The latter is not only very valuable for pros who know about properties 
not commonly used enough to have merited inclusion in an Inspector, but 
also for newcomers who can learn about the scope of properties in an 
object in one place.


--
 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: LC 8 Property Inspector

[Dr. Hawkins]

On Thu, Oct 8, 2015 at 10:56 AM, Roger Guay  wrote:

> Sometimes, a word is worth a thousand pictures!
>

I have the text toolbar set, and don't waste screen space on icons.

OK, so I spend more time in a terminal than the finder; I'm more a unix guy
who's hooked on spotlight and Apple's laptops than a mac guy.



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

Re: LC 8 Property Inspector

[Mark Talluto]

> On Oct 8, 2015, at 8:36 AM, Trevor DeVore  wrote:
> 
> I've actually found the new interface to be much more productive. I always
> found that using an option menu to switch property inspector panes was
> tedious as it required multiple clicks. Switching around between panes in
> the inspector is much quicker now.

I agree that the new interface with panes is a lot faster for me too. I like 
that the grow/shrink animation found in earlier versions of LC has been 
replaced with a super fast no transition model. 

Best regards,

Mark Talluto
canelasoftware.com 
CassiaDB: The rapid development, free local storage database, made for LiveCode 
developers: livecloud.io 





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

Re: LC 8 Property Inspector

[Paul Hibbert]

On 8 Oct 2015, at 14:47, Ali Lloyd  wrote:
> 
> OK, the palette header actually doesn't currently have the option to
> display both icons and labels, so I might rectify that tomorrow.

Ali,

If you are delving into the PI prefs tomorrow you may want to look at the bug 
report I’ve just submitted, http://quality.runrev.com/show_bug.cgi?id=16176 
 (Property Inspector not 
respecting Preference setting).

Hopefully this should be an one to easy fix.

Regards,

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: LC 8 Property Inspector

[Scott Rossi]

Instead of a scrolling accordion list with grouped sets of properties,
allow me to get radical and suggest a fixed index list on the left or
along the top of the palette.  You'd get one-click access to any category,
and no need to expand/collapse panes.  With an accordion control, you'll
likely suffer the same issues found in the current Project Browser: to
much vertical scrolling required to get to what you want, and no constant
reference for all property categories since they can be scrolled out of
view.

I may be voicing dissent here, but as you say "Let 1000 flowers bloom." :-)

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/8/15, 2:20 PM, "use-livecode on behalf of Richard Gaskin"
 wrote:

>Peter Haworth wrote:
>
> > On Thu, Oct 8, 2015 at 11:59 AM, Richard Gaskin wrote:
> >> Here's an implementation I've been using whenever I need things
> >> not found in any Inspector:
> >> 
> >>
> >> The design is largely functional, but suboptimal. Time permitting it
> >> would group related properties together under collapsible headers.
> >
> > Completeness is indeed important, especially to newcomers as you
> > point out.
> > There are some strange omissions from the pre-8 PI, e.g. it doesn't
> > have a place to specify a behavior for an option menu which, when I
> > first started using LC, led me to believe option menus couldn't have
> > behaviors for some reason.  I see that's been corrected in v8.
> >
> > However, once you're past the newcomer stage, showing every possible
> > property is probably something you don't want, which brings me to
> > the issue of layout flexibility, the ability to organize properties
> > together in a way that makes sense for each individual user.
>
>The collapsible headers I referred to is the enhancement a good Property
>Sheet should have to allow users to find properties easily.
>
>Logical groupings allow you to work with just color props, or
>size/location props, etc. as needed, and likely only crazy people like
>me would expand all of them at once in an alphabetic list like the one
>I'd built to see them all at once.
>
>Ken Ray and I discussed having one of the theoretical collapsible
>headers being Favorites, so anyone who finds themselves using a certain
>subset of props frequently can include them there while still keeping
>the logical groupings it would ship with by default.
>
>The real value of the Prop Sheet implementation I shared isn't that it's
>complete in that way, but merely that all of its prop labels and values
>use only one field to display them.  Super easy to build and maintain,
>and efficient to work with.
>
>-- 
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
>___
>use-livecode mailing list
>use-livecode@lists.runrev.com
>Please visit this url to subscribe, unsubscribe and manage your
>subscription preferences:
>http://lists.runrev.com/mailman/listinfo/use-livecode



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

Re: LC 8 Property Inspector

[Richard Gaskin]

Paul Hibbert wrote:
> If you are delving into the PI prefs tomorrow you may want to look
> at the bug report I’ve just submitted
>  (Property Inspector
> not respecting Preference setting).

That raises another question:  If LiveCode is "English-like" then 
shouldn't using the language token be sufficient?   Why have an option 
for some more descriptive text?


If the language isn't readable fix the language, but it slows down 
learning to have words used in the Inspector which bear no resemblance 
to the token a scripter would later use in their code.


--
 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: LC 8 Property Inspector

[Richard Gaskin]

Peter Haworth wrote:

> On Thu, Oct 8, 2015 at 11:59 AM, Richard Gaskin wrote:
>> Here's an implementation I've been using whenever I need things
>> not found in any Inspector:
>> 
>>
>> The design is largely functional, but suboptimal. Time permitting it
>> would group related properties together under collapsible headers.
>
> Completeness is indeed important, especially to newcomers as you
> point out.
> There are some strange omissions from the pre-8 PI, e.g. it doesn't
> have a place to specify a behavior for an option menu which, when I
> first started using LC, led me to believe option menus couldn't have
> behaviors for some reason.  I see that's been corrected in v8.
>
> However, once you're past the newcomer stage, showing every possible
> property is probably something you don't want, which brings me to
> the issue of layout flexibility, the ability to organize properties
> together in a way that makes sense for each individual user.

The collapsible headers I referred to is the enhancement a good Property 
Sheet should have to allow users to find properties easily.


Logical groupings allow you to work with just color props, or 
size/location props, etc. as needed, and likely only crazy people like 
me would expand all of them at once in an alphabetic list like the one 
I'd built to see them all at once.


Ken Ray and I discussed having one of the theoretical collapsible 
headers being Favorites, so anyone who finds themselves using a certain 
subset of props frequently can include them there while still keeping 
the logical groupings it would ship with by default.


The real value of the Prop Sheet implementation I shared isn't that it's 
complete in that way, but merely that all of its prop labels and values 
use only one field to display them.  Super easy to build and maintain, 
and efficient to work with.


--
 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: LC 8 Property Inspector

[Peter Haworth]

Favorites would be a great addition.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Thu, Oct 8, 2015 at 2:20 PM, Richard Gaskin 
wrote:

> Peter Haworth wrote:
>
> > On Thu, Oct 8, 2015 at 11:59 AM, Richard Gaskin wrote:
> >> Here's an implementation I've been using whenever I need things
> >> not found in any Inspector:
> >> 
> >>
> >> The design is largely functional, but suboptimal. Time permitting it
> >> would group related properties together under collapsible headers.
> >
> > Completeness is indeed important, especially to newcomers as you
> > point out.
> > There are some strange omissions from the pre-8 PI, e.g. it doesn't
> > have a place to specify a behavior for an option menu which, when I
> > first started using LC, led me to believe option menus couldn't have
> > behaviors for some reason.  I see that's been corrected in v8.
> >
> > However, once you're past the newcomer stage, showing every possible
> > property is probably something you don't want, which brings me to
> > the issue of layout flexibility, the ability to organize properties
> > together in a way that makes sense for each individual user.
>
> The collapsible headers I referred to is the enhancement a good Property
> Sheet should have to allow users to find properties easily.
>
> Logical groupings allow you to work with just color props, or
> size/location props, etc. as needed, and likely only crazy people like me
> would expand all of them at once in an alphabetic list like the one I'd
> built to see them all at once.
>
> Ken Ray and I discussed having one of the theoretical collapsible headers
> being Favorites, so anyone who finds themselves using a certain subset of
> props frequently can include them there while still keeping the logical
> groupings it would ship with by default.
>
> The real value of the Prop Sheet implementation I shared isn't that it's
> complete in that way, but merely that all of its prop labels and values use
> only one field to display them.  Super easy to build and maintain, and
> efficient to work with.
>
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Richard Gaskin]

Scott Rossi wrote:

Instead of a scrolling accordion list with grouped sets of properties,
allow me to get radical and suggest a fixed index list on the left or
along the top of the palette.  You'd get one-click access to any category,
and no need to expand/collapse panes.  With an accordion control, you'll
likely suffer the same issues found in the current Project Browser: to
much vertical scrolling required to get to what you want, and no constant
reference for all property categories since they can be scrolled out of
view.

I may be voicing dissent here, but as you say "Let 1000 flowers bloom." :-)


At the risk of sounding boring, I think we're talking about the same thing.

If we took the existing Inspector and replaced the icons at the top with 
horizontal labels we'd have something like (where "*this*" indicated 
hilited item):



| Colors   |

|*Size*|

| Behavior |

| Other|

| Favorites|

|  List of |
|  name-value  |
|  properties  |
|  for item|
|  hilited |
|  above   |
|  goes|
|  here|



An accordion style would keep all the labels visible, simply putting the 
scrolling list field of name-value property pairs immediately below the 
selection, taking the same amount of room but just making the header 
more readily associated with the list it delivers:



| Colors   |

|*Size*|

| List of  |
| name-value   |
| properties   |
| for item |
| hilited  |
| above|
| goes |
| here |

| Behavior |

| Other|

| Favorites|




--
 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: LC 8 Property Inspector

[Ali Lloyd]

OK, the palette header actually doesn't currently have the option to
display both icons and labels, so I might rectify that tomorrow.

For now, here's a pull request adding the display preference between icons
and labels.
https://github.com/livecode/livecode-ide/pull/564

The way we have written the property inspector, it will be very easy to
specify where you want particular properties to appear. We intended to add
grouping/folding/customization of this type straight away, but I guess it's
probably better to get the basics working first.

On Thu, Oct 8, 2015 at 10:20 PM Richard Gaskin 
wrote:

> Peter Haworth wrote:
>
>  > On Thu, Oct 8, 2015 at 11:59 AM, Richard Gaskin wrote:
>  >> Here's an implementation I've been using whenever I need things
>  >> not found in any Inspector:
>  >> 
>  >>
>  >> The design is largely functional, but suboptimal. Time permitting it
>  >> would group related properties together under collapsible headers.
>  >
>  > Completeness is indeed important, especially to newcomers as you
>  > point out.
>  > There are some strange omissions from the pre-8 PI, e.g. it doesn't
>  > have a place to specify a behavior for an option menu which, when I
>  > first started using LC, led me to believe option menus couldn't have
>  > behaviors for some reason.  I see that's been corrected in v8.
>  >
>  > However, once you're past the newcomer stage, showing every possible
>  > property is probably something you don't want, which brings me to
>  > the issue of layout flexibility, the ability to organize properties
>  > together in a way that makes sense for each individual user.
>
> The collapsible headers I referred to is the enhancement a good Property
> Sheet should have to allow users to find properties easily.
>
> Logical groupings allow you to work with just color props, or
> size/location props, etc. as needed, and likely only crazy people like
> me would expand all of them at once in an alphabetic list like the one
> I'd built to see them all at once.
>
> Ken Ray and I discussed having one of the theoretical collapsible
> headers being Favorites, so anyone who finds themselves using a certain
> subset of props frequently can include them there while still keeping
> the logical groupings it would ship with by default.
>
> The real value of the Prop Sheet implementation I shared isn't that it's
> complete in that way, but merely that all of its prop labels and values
> use only one field to display them.  Super easy to build and maintain,
> and efficient to work with.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Scott Rossi]

Actually, no drawbacks at all.  In Richard's case, you could expand
multiple panes (as I think he mentioned), and in my case, the categories
could be treated as toggles, being able to select more than one category
to be displayed.  And in both cases, if you're hard core, you could have
an "All" option that would expand/show you everything at once.  So no
drawbacks that I see (the only limitation being screen real estate).

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 10/8/15, 6:25 PM, "use-livecode on behalf of Peter Haworth"
 wrote:

>The accordion list and Scott's suggestion (is that a "MIller list"?) both
>have the drawback that you can only see one set of properties at a time.
>That might be OK but it does mean more clicking around/remembering values
>if you want to do that.



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

Re: LC 8 Property Inspector

[Peter Haworth]

Right, I mentioned the toggle idea as a possible way to view multiple
groups in your multi pane idea. Must have missed the reference to multiple
expansions in Richard's post, that makes it the equivalent pf an expanding
list I guess.

It comes down to vertical vs horizontal preference again.

On Thu, Oct 8, 2015, 7:10 PM Scott Rossi  wrote:

> Actually, no drawbacks at all.  In Richard's case, you could expand
> multiple panes (as I think he mentioned), and in my case, the categories
> could be treated as toggles, being able to select more than one category
> to be displayed.  And in both cases, if you're hard core, you could have
> an "All" option that would expand/show you everything at once.  So no
> drawbacks that I see (the only limitation being screen real estate).
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 10/8/15, 6:25 PM, "use-livecode on behalf of Peter Haworth"
>  wrote:
>
> >The accordion list and Scott's suggestion (is that a "MIller list"?) both
> >have the drawback that you can only see one set of properties at a time.
> >That might be OK but it does mean more clicking around/remembering values
> >if you want to do that.
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[J. Landman Gay]

I like the side-pane idea best, but then, you and I are horizontal 
people. The vertical people probably prefer the expanding/collapsing list.


Regarding ascii-drawing-fu: he cheats, he wrote a gizmo to do it.


On 10/8/2015 7:12 PM, Scott Rossi wrote:

Your ascii-drawing-fu is quite skilled :-)

No boredom at all.  I see the difference you mention in limiting the
height of the property list.  I had understood the selected pane would be
expanded to display ALL properties for the category, which could
potentially scroll Behavior/Other/Favorites out of view.

I had to take stab at the option I suggested:

---
| Colors |   List of   |
  name-value |
|**Size**|   properties|
  for item|
| Behavior |   hilited   |
  at left   |
| Other  |   goes here |
  and maybe   |
| Favorites|  offers|
  more |
   |  vertical space|
   |  for the list  |
--




--
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: LC 8 Property Inspector

[Peter Haworth]

Hi Ali,
Would be great if you get flexible groupings going.  Having been through
implementing this, one thing to watch out for is that there isn't a way to
get a complete list of properties for a particular object type.

The properties array of an object does not include properties which can be
derived from other properties.  That change was made a few releases back
and no method of invoking the prior behavior (perhaps "the effective
properties") was provided.

Also, the propertynames list is missing some entries and includes some
entries that seem more like keywords than properties, e.g. "abbrev".

Hopefully, as a team member you may have access to other resources to get a
complete list,

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Thu, Oct 8, 2015 at 2:47 PM, Ali Lloyd  wrote:

> OK, the palette header actually doesn't currently have the option to
> display both icons and labels, so I might rectify that tomorrow.
>
> For now, here's a pull request adding the display preference between icons
> and labels.
> https://github.com/livecode/livecode-ide/pull/564
>
> The way we have written the property inspector, it will be very easy to
> specify where you want particular properties to appear. We intended to add
> grouping/folding/customization of this type straight away, but I guess it's
> probably better to get the basics working first.
>
> On Thu, Oct 8, 2015 at 10:20 PM Richard Gaskin  >
> wrote:
>
> > Peter Haworth wrote:
> >
> >  > On Thu, Oct 8, 2015 at 11:59 AM, Richard Gaskin wrote:
> >  >> Here's an implementation I've been using whenever I need things
> >  >> not found in any Inspector:
> >  >> 
> >  >>
> >  >> The design is largely functional, but suboptimal. Time permitting it
> >  >> would group related properties together under collapsible headers.
> >  >
> >  > Completeness is indeed important, especially to newcomers as you
> >  > point out.
> >  > There are some strange omissions from the pre-8 PI, e.g. it doesn't
> >  > have a place to specify a behavior for an option menu which, when I
> >  > first started using LC, led me to believe option menus couldn't have
> >  > behaviors for some reason.  I see that's been corrected in v8.
> >  >
> >  > However, once you're past the newcomer stage, showing every possible
> >  > property is probably something you don't want, which brings me to
> >  > the issue of layout flexibility, the ability to organize properties
> >  > together in a way that makes sense for each individual user.
> >
> > The collapsible headers I referred to is the enhancement a good Property
> > Sheet should have to allow users to find properties easily.
> >
> > Logical groupings allow you to work with just color props, or
> > size/location props, etc. as needed, and likely only crazy people like
> > me would expand all of them at once in an alphabetic list like the one
> > I'd built to see them all at once.
> >
> > Ken Ray and I discussed having one of the theoretical collapsible
> > headers being Favorites, so anyone who finds themselves using a certain
> > subset of props frequently can include them there while still keeping
> > the logical groupings it would ship with by default.
> >
> > The real value of the Prop Sheet implementation I shared isn't that it's
> > complete in that way, but merely that all of its prop labels and values
> > use only one field to display them.  Super easy to build and maintain,
> > and efficient to work with.
> >
> > --
> >   Richard Gaskin
> >   Fourth World Systems
> >   Software Design and Development for the Desktop, Mobile, and the Web
> >   
> >   ambassa...@fourthworld.comhttp://www.FourthWorld.com
> >
> >
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Mark Wieder]

On 10/08/2015 02:14 AM, Ali Lloyd wrote:


2) The new inspector is *really* flexible for the classic objects. Have a
look at this fix for bug 16118 (no way to change a scrollbar's tooltip in
the property inspector):
https://github.com/livecode/livecode-ide/pull/562/files


Well, OK, I do have to thank you for fixing that, but I guess I really 
expected it to be fixed in the existing property editor, not so much in 
the experimental one. I guess filing the bug report against dp6 was a 
mistake, but that's the latest I still saw the problem in.



We'd like to make it as good and useful as possible. If the worst you can
say is you can't see any advantages, then I think the non-obvious ones
above make it well worth it ;-) Otherwise it would be great to hear
constructive criticism and suggestions for improvement.


Well, I've been thinking of the the new IDE framework as just being that 
and allowing for plugin replacement of the various components. It seems 
from the App Browser / Project Browser and Property Inspector arguments 
that I've been expecting too much, and we really can't have alternatives.


--
 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: LC 8 Property Inspector

[Peter Haworth]

The accordion list and Scott's suggestion (is that a "MIller list"?) both
have the drawback that you can only see one set of properties at a time.
That might be OK but it does mean more clicking around/remembering values
if you want to do that.

To get round that, my implementation was a simple expandable list of
groups. Expand a group to see its properties, collapse it to get rid of
them.  If you need to see more than one group, expand both of them.  Or
perhaps you could have a checkbox next to each group instead of buttons
that indicates whether or not its properties should be included in the list.

You pretty much have to have something like that to handle custom
properties since there can be multiple custom property groups unless you
have a button for each one or go with a completely different
display/editing method.

Also, just a detail, but the Favorites group should be at the top of the
list and an option to show it already selected/expanded would be good.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Thu, Oct 8, 2015 at 5:12 PM, Scott Rossi  wrote:

> Your ascii-drawing-fu is quite skilled :-)
>
> No boredom at all.  I see the difference you mention in limiting the
> height of the property list.  I had understood the selected pane would be
> expanded to display ALL properties for the category, which could
> potentially scroll Behavior/Other/Favorites out of view.
>
> I had to take stab at the option I suggested:
>
> ---
> | Colors |   List of   |
>   name-value |
> |**Size**|   properties|
>   for item|
> | Behavior |   hilited   |
>   at left   |
> | Other  |   goes here |
>   and maybe   |
> | Favorites|  offers|
>   more |
>   |  vertical space|
>   |  for the list  |
> --
>
>
> :-)
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 10/8/15, 4:33 PM, "use-livecode on behalf of Richard Gaskin"
>  ambassa...@fourthworld.com> wrote:
>
> >Scott Rossi wrote:
> >> Instead of a scrolling accordion list with grouped sets of properties,
> >> allow me to get radical and suggest a fixed index list on the left or
> >> along the top of the palette.  You'd get one-click access to any
> >>category,
> >> and no need to expand/collapse panes.  With an accordion control, you'll
> >> likely suffer the same issues found in the current Project Browser: to
> >> much vertical scrolling required to get to what you want, and no
> >>constant
> >> reference for all property categories since they can be scrolled out of
> >> view.
> >>
> >> I may be voicing dissent here, but as you say "Let 1000 flowers bloom."
> >>:-)
> >
> >At the risk of sounding boring, I think we're talking about the same
> >thing.
> >
> >If we took the existing Inspector and replaced the icons at the top with
> >horizontal labels we'd have something like (where "*this*" indicated
> >hilited item):
> >
> >
> >| Colors   |
> >
> >|*Size*|
> >
> >| Behavior |
> >
> >| Other|
> >
> >| Favorites|
> >
> >|  List of |
> >|  name-value  |
> >|  properties  |
> >|  for item|
> >|  hilited |
> >|  above   |
> >|  goes|
> >|  here|
> >
> >
> >
> >An accordion style would keep all the labels visible, simply putting the
> >scrolling list field of name-value property pairs immediately below the
> >selection, taking the same amount of room but just making the header
> >more readily associated with the list it delivers:
> >
> >
> >| Colors   |
> >
> >|*Size*|
> >
> >| List of  |
> >| name-value   |
> >| properties   |
> >| for item |
> >| hilited  |
> >| above|
> >| goes |
> >| here |
> >
> >| Behavior |
> >
> >| Other|
> >
> >| Favorites|
> >
> >
> >
> >
> >--
> >  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:
> 

Re: LC 8 Property Inspector

[Ali Lloyd]

Labelled icons are also possible - we could potentially have a preference
setting for one, the other, or both.

They do already have tooltips, btw.

On Thu, Oct 8, 2015 at 6:56 PM Roger Guay  wrote:

>
> > On Oct 8, 2015, at 10:50 AM, J. Landman Gay 
> wrote:
> >
> > But as Rick said, it's not always easy to identify icons. Tooltips are a
> must until we learn what they are. But even better would be icons with
> labels, like the IDE toolbar has.
>
>
> Sometimes, a word is worth a thousand pictures!
>
> 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
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: LC 8 Property Inspector

[Peter Haworth]

Completeness is indeed important, especially to newcomers as you point out.
There are some strange omissions from the pre-8 PI, e.g. it doesn't have a
place to specify a behavior for an option menu which, when I first started
using LC, led me to believe option menus couldn't have behaviors for some
reason.  I see that's been corrected in v8.

However, once you're past the newcomer stage, showing every possible
property is probably something you don't want, which brings me to the issue
of layout flexibility, the ability to organize properties together in a way
that makes sense for each individual user.  I want the properties I use the
most to show on a single tab, visible when I open the PI for an object,
with other properties grouped together in other tabs that fit the way I
work, even excluding some which I never use.

In some cases, properties seem like they are in the wrong place to me.  For
example,  the textHeight and firstIndent properties belong in the Text
formatting tab, not the basic tab, particularly textHeight which is
automatically changed when you change the font size.

I'm not sure the team should be devoting time to things like that right now
or maybe ever, so I included the ability to do all of the above in
lcStackBrowser

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 

On Thu, Oct 8, 2015 at 11:59 AM, Richard Gaskin 
wrote:

> Ali Lloyd wrote:
>
> > Labelled icons are also possible - we could potentially have a
> > preference setting for one, the other, or both.
>
> Inspectors are very useful in consumer apps, where the range of properties
> is often smaller and their scope less broad.
>
> In development tools we often see a Property Sheet that shows all
> properties, as opposed to the subset we've had available in all Inspectors
> thus far.
>
> Here's an implementation I've been using whenever I need things not found
> in any Inspector:
> 
>
> The design is largely functional, but suboptimal.  Time permitting it
> would group related properties together under collapsible headers.
>
> And when you think about, even if the Inspector were to continue to limit
> itself to a subset of object properties, once you start down the road of
> horizontal labels the design screams for such an accordion design anyway.
>
> Using that according design within a scrollable Property Sheet allows for
> most of what folks are looking for here:
>
> - Ease of access
> - Clear labels for related properties
>
> ...and adds something that I don't recall coming up here yet but would
> sooner or later:
>
> - Completeness, the ability to see all of an object's properties
>
> The latter is not only very valuable for pros who know about properties
> not commonly used enough to have merited inclusion in an Inspector, but
> also for newcomers who can learn about the scope of properties in an object
> in one place.
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode