I wrote a custom firefly script. Feel free to dig it out of the simple demo and do as you please with it. It will take a config which is all commented in the script.
It may be a component one day. But if you know what you are doing you can use it today.
[link removed]
that looks mental
Very fun! Looks great too… thumbs 
You can download the packaged up script and css from the demo above now.
Easy to call.
Can be called on the body, or a container by ID.
Lots of config options can be included in the call.
Can have multiple instances on the same page.
I’d say dont go mental with the number of fireflies in the config call. the demo is 25.
Turned out pretty sweet as a component. I’ll prob get time to add the remaining controls and make it available tomorrow.
A little guidance (if you want)
Downloaded opened the .js in text edit
Copied and created a custom HTML component
Also tried the JavaScript below the html setting…
Sorry to be a pain… please feel free to ignore this 
Hard to explain if you are not familiar with js scripts and how to call them and reference them in elements. To be honest I’m not that familiar with the html component, not sure where the javascript goes when you stick it in the javascript section, or the correct way to access it in there. I always just work with components inside dev packs. It’s probably the same and you need to use the asset path you’d need to define in hooks 
Like I say though. I’m almost done bundling it into a component I will release tomorrow.
Just a few nice features to add.
Ok thanx for responding - no worries 
nice logo for the firefly
Hi Gary. I’d love to download the Firefly script to use it with a container inside my Foundation 6 projects: [link removed] But unfortunately the button on the Firefly page doesn’t do anything…
love it! thanks for sharing
As promised, it’s now available as a component. There is a little video overview on the demo now.
[link removed]
Bought!
Hey Everyone (and @Doobox),
I know we’ve talked about this on here before, but it’s probably got lost in the sheer volume of posts, but this is VERY important, so here goes:
An Element Dev Pack (.devpack) is designed strictly for local development. These are uncompiled and unencrypted versions of your components that allow for live editing and testing during development.
Every file inside a Dev Pack is actively monitored by Elements and the system, which enables real-time updates as you work in third-party editors, a huge benefit while building components.
However, this live monitoring comes at a cost. If too many Dev Packs accumulate over time, Elements (and macOS) can run out of file handles, leading to components failing to load or update. To avoid performance issues and ensure system stability, Dev Packs must never be shared or sold.
That said, Dev Packs are fine for internal use. If you’re collaborating with a small team, doing client work, or running a closed beta, it’s okay to share Dev Packs privately for testing and feedback. Just be mindful that these packs aren’t encrypted or optimised, and should never be used as a final delivery format.
Before distribution, all Dev Packs must be compiled and encrypted into standard .elementpack files. This process protects your code, improves load times (down from seconds to milliseconds), and ensures the pack is safe and optimised for use by others.
For more detailed information on this please check store distribution docs here.
Hope that all makes sense, and please do let me know if you have any further questions.
Hi @dan simply either open the store for 3rd parties. They missed the opportunity of Black Friday sales via the store already. Or provide the tools for creating Elements Packs to them. You are shipping components on the store every week and the 3rd party devs are left behind. Sorry if that sounds harsh, but the current situation is not fair from my pov.
Hey @herbing,
I get the frustration but we’re not going to rush this or open things up before the system is ready. Building a proper pipeline for third-party packs is complex and it has to be solid, otherwise it creates bigger problems for everyone.
We’re actively working on the tooling and the store, but we also have to balance this with shipping features and fixes for the main app. Elements is still a young product and it needs time to mature properly.
I hear the feedback, but this isn’t something we can just flip on overnight.
EDIT: Just out of curiosity; what’s the priority from your side? Do you want us to focus on bug fixes, and finishing features in the main app, or tooling for third-party add-ons?
We can’t do all three at once at full speed, so it really helps to know what you feel is most important. Elements will get there, but we have to build things in the right order.
If Elements is using FSEvents to monitor devPacks there is no limits.
If and lets assume its using DispatchSourceFileSystemObjectThen there is a hard limit of 1024 handles (per app process). 1024 dev packs.
I thought I hadn’t seen any issues, and I have over 100 dev packs installed I have been working on.
@dan But you clearly already have something that works, as you are developing and selling components. So why not have a BETA program for developers that will at least allow them to get started with the process of creating elementpacks.
This will help them get up to speed and also allow you to get feedback and more testing.
In fairness, I doubt there is a backend system we would be able to to login to and manage a dev account at yet.
Bug fixes and sanding the rough edges in main app would be my choice.
Hi @dan re your edit: question. I would suggest to be fair and cease shipping of paid components until you are ready for 3rd party devs. Otherwise you will disappoint them from the platform and I think in less than 6 month they will be all gone und you have a Realmac only eco system left. Elements is a real nice product and I enjoy using it, but to have a sustainable future, 3rd party devs must be on board.
