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.com http://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
