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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com