Yes, quartz composer is a flow based editor but this isn’t really (putting some flow lines on the panel is a total optional idea, but possible). It’s more of an aggregate overview of the actions and commands used in your project. It’s also not free flowing as flow based editors, as position means something here. Horizontal positioning is used to differentiate scenes, symbols etc. and vertical positioning is used to list stuff in one of these groupings (like elements).
To address the why: if a project becomes bigger you start attaching clicks handler and other stuff into nested structures. You are in a way creating interactions all over the place and it is easy to lose oversight. Specially when things start to get nested over multiple scenes. You’d have to remember every element that got code in it and click your way there and then click through to the corresponding panels to find the spot where the interactivity is setup up (handlers, listeners).
This is meant as an optional and progressive way to accomplish that. With progressive, I mean it’s like “Edit Head-HTML”, a button that opens this optionally and this view and doesn’t “overload” the interface from the get go. You can totally not use it in a simple project… but when your project gets big and complex, you have to review it for someone or haven’t opened it in a while it will be a marvelous way to see what’s going on in that file.
If I’d implement it I’d probably first make it an overview with backlinks to the corresponding panels. Further edit possibilities (some outlined in the drawings above, like in-place editing on that screen) would be added later if there would be a demand. The overview aspect of it and the backlinks are the core functionality to start with, from my perspective.
It’s interesting how quartz composer solved the wiring issue when wires cross a panel. Wires are always in the back and the panels are actually slightly transparent so you can see wires crossing panels in the background. As said wiring is not the main goal here but could be done with scene transition commands and custom behavior calls.
now I’m on the right track, thanks.
I think this would be a good alterantive to build a scene with the basics; but a complex project will always be too complex to understand even with the graphic structure.
but I agree that the graphic tree is useful, maybe faster than the timeline, but I wonder if the effort (you did some good examples) makes sense in Hype.
I remember some work in 3dStudio max for particle systems, it was a nightmare to connect the function to only some elements in large projects with a complex relationship between elements.
I think your still slightly over complicating the board. It actually lists the stuff you got on the panels anyways. Nothing more nothing less
It’s just a birds eye view of these settings.
Even if I outlined some future possibilities and the graphics of quartz composer certainly doesn’t help. I tried to bring it back in the last reply to the core idea of oversight.
To the point that complex projects will always be complex projects. That is entirely true. But it can become “less” complex.
The other thing is that a complexity is one thing. Hidden complexity is an entirely different beast. If you actual aren’t aware of some function you attached to a element nested three groups deep you easily forget about it. #BringingItBackToOversight
So the first version with only listing the triggers (if they are set) and backlinks to the panels in the current UI would be the baseline.
I can’t do it as I am on the road. But the idea for the overview doesn’t include fine grained conditional programming as it only surfaces current functionality … as the panels are plain call stacks in Hype (command stacks). You can find their functional depth in any current element panel or the document panel. More complex things are reserved for Hype functions. I suggested in a previous post in this thread that a function to convert a call stack to a function would be great to get started with programming for people on the verge of hitting the limits of plain call stacks
I can certainly say that having better overview modes for Hype like what you sketched out would benefit me the most .
I just watched a tutorial for this. It is interesting; I'm not sure Hype would go for this model but there are good ideas in regards to states that might apply.
That would be a start*! The full document view would be even better!
*although putting it there still doesn’t solve nested hidden functionality
Update: but @MarkHunte sketch shows that this visual flowview/overview could be used on multiple locations once implemented. In an document overview but also with limited scope on individual scenes and on the panel command themselves (as sketched by mark).
The other day I dropped a svg file in the resources and used fetch() to read the response as text and insert it into the innerHTML of an element.
Accessing the path etc was easy enough after that.
Why I bring this up here is it just struck me that this threads idea of a map/tree etc could be used for importing svg files
I.e
We add a file to the resources.
When we select it we get a map/ tree that lists its main key elements and their properties.
We can then assign these as a Hype scoped objects. .i.e let Hype know about them by assigning a special class name to them.
Then drop an element into the scene editor and give it that class were it basically becomes an instance of the svg
When we can then also get an inspector that can display the properties of the svg and allow us to adjust them.
Wiring up stuff is a very “tangible” way of making connection or assignments.
Although in the long run Hype will support or have a greater toolset for working with native SVG. I am pretty confident about it now, based on the feedback so far from @jonathan in this forum.
Thanks for your thoughts. I can’t say for certain since it hasn’t been spec’ed out, but I suspect the default would be that SVG would get imported as a DOM element instead of a file reference as it is now. Then it would behave similar to a symbol - you could double click in to enter it and there’d be the object hierarchy in the element list and special tools for dealing with it. This would probably allow setting properties like IDs on paths that you may care about.
This is all subject to change and not a feature promise.
Hello everyone. A few days ago I was busy with my stuff … Here I shared to start the idea and I would like you to also contribute the ideas in the same document (SVG) to arrive at a complete global with different points of view.
For now I start with SVG that can do thousands of things.
It has been many days without talking about this very interesting topic. I’ve already made something clearer and I hope the developers understand that? So you can developed this tool. something similar Visual Scripting but without nodes.
but then you can create an FSM as a group of functions.
Group:
*type: for, Switch, collision, condition, trigger
Trigger:
* Type: Pressed (keyboard), collision(item)
* To: items
collision:
On or Off: ClassAnimation, video, sound, physical.
Switch:
* NumeberCase: Class trigger, Class Collisor, Class Switch,
As you included me in the list. In recent days I am more on the side of learning actual JavaScript. If it needs an intermediary step. I still think that could help! I root for a scratch like Interface replacing the regular linear block stack. Because scratch like blocks can be used in the linear fashion current action stacks work so nothing new to learn but can scale to include new commands and conditional logic and loops.
.
