That's an impressive list… I'd be happy with modernization, so here are my requests:
Animation Engine allows animating any DIV
Remove .HYPE_container_elements and add all the goodies it prevented (Flex, Grid, Blend modes)
Reworked copy/paste/import of symbols (merge conflicts)
Index-based scene addressing
Allow including any JS in the Resources in the generated JS with an order attribute (like priority minus values before and plus after, sort by priority)
Some official extension API (in builder)
HypeDocumentLoad as an official hook in the UI
Drop IE
I'd be happy with that alone. The rest could be delivered over time in the form of extensions, keeping Hype 5 slim and modular.
I suppose that raises the question… what don't you agree with?
It's tabs for code formatting isn't it?
I can see Tumult not being a fan of App exporting (but it doesn't have to be that difficult since Hype has scripting), and Lighthouse is not really a requirement since people can just do it themselves with a web browser that supports it (but it seems like a nice way to expand the warning section, which is kinda useless lately now that the web browsers have more parity), so I'm not sure what else is even debatable?
Is it IE support?
Is it cross platform support? After reading this, I'm shocked Hype is still an exclusive.
What would also be amazing, although less of a priority would be a component library.
Most of the time I'm setting up my image/text elements in html/css, paired with a bunch of javascript functions. Would be amazing if I could save my own elements, and quick add them in the projects I need them for, to mix and match what elements I need specific per project. The same thing with scripts and custom css fonts etc.
You can save symbols and add them to the foremost project by double-clicking on them. Just avoid importing them twice, as that's the mentioned merge problem, which will duplicate all dependencies, including functions that should theoretically be unique by name. This can lead to redundancy and some odd outcomes, with projects becoming messy.
Which is working really well for me and make things more productive.
A snippet library within hype would be great
But im also wondering about if hype also had its own shortcut actions to import , convert import, load symbols, export ...( thinking aloud )
It goes without saying. A labelling/ argument system on timeline actions that call javascript would be really handy in conditional function calls. ( yes there are hacks but a native system would be better)
Gonna say it.
Better coding support.
One of the only reasons I will ever edit a function outside of hype ( and because I hate having to go outside of an app to do a task I should be able do within the app) is to try and find the end or beginning of a closure.
Such a simple thing but one of the most common errors is an unexpected ')' or '}'
Yes a lot of the time this us because you are cutting or pasting which lets be honest we all do...
But finding the error can be ten times as hard to figure out without being able to find closures beginning and start.
Here's another idea, just throwing out there… Should the Hype runtime (or the whole Hype Project) use strict-mode?
The article says this…
Fixes mistakes that make it difficult for JavaScript engines to perform optimizations: strict mode code can sometimes be made to run faster than identical code that's not strict mode.
Here's yet another idea, just thrown out there… export to single file.
This idea was sorta discussed here…
I've been thinking of a topic for the next Photics book. Since ePub is the focus, I was considering the possibility of interactivity. To start things off, I simply tried getting the current time with JavaScript. It was pretty easy.
The problem is that Hype has a directory structure… specifically .hyperesources …but I couldn't add directories in the Calibre. I'm going to experiment with that some more, but it just seems like it would be more ideal if Hype exported to a single file… probably a single HTML file …similar to .swf when Flash was popular.
UPDATE — I was able to flatten the directory structure, so that's not a problem. Yet, I still wasn't able to get a Hype project to work in an ePub using Calibre. So, I suppose those are two separate features.
Single file exporting
Export to ePub — which was mentioned above, but I'm not sure if it's possible.
There was some discussion about exporting to ePub… Export scenes to EPUB3 …but it was centered around OAM Widget & InDesign.
I've considered this, but it is a pretty low priority since the runtime is big enough that any possible performance benefits are unclear from the outset. There's of course other benefits, but it's the type of thing that just can become a big rabbit-hole when the project didn't start this way.
Definitely, I think my question is on appropriate guard-rails. (Like you wouldn't want a large video to be inlined!)
Hype can't export to XML natively, so any ePub export would be pretty opinionated about how it decides to wrap the Hype HTML export and provide lots of settings to setup the book. (Not saying no, just that I know any first version won't be able to handle everyone's use cases...)
Also, I'm not sure if i'm the only one, but I'm ending up using the Hype rectangles more and more to write out big pieces of Html and css. It would be super if we would be able to to get a bigger more convenient code editor for this just like the head part, or even options to edit it with an IDE just like editing scripts.
One reason but not limited to, is I do not have to keep jumping back and forth between the head and the scene.
It would be great if we had a css editor pane. But with room to see what you are doing rather than the small and limited area like the attributes editor.
Wordpress has such a panel in its customise setting settings that is a strip
While the concept of a dedicated CSS tab may seem similar to the existing Head HTML functionality, there are several feature requests that, if implemented, could offer a more versatile solution:
The ability to utilize Hype in a multi-monitor setup by allowing the undocking of tabs such as scenes or Head HTML. This would greatly enhance the user experience for those working with extended desktops.
The option to designate specific files for integration into the generated JavaScript. This could be within the *_hype_generated_script.js file or embedded inline, as determined by the advanced export settings or an export script. The advantage here is the flexibility to bundle any JavaScript or CSS files from resources directly. For CSS integration, currently, one would need to employ JavaScript to insert the code into Head HTML. However, this process could be streamlined if the runtime were equipped with a feature to handle it automatically. The inclusion order would probably need management (either order or priority), though.
I had hummed and erred about spelling that out , as I took it as a given that with the inclusion of using a side panel as shown, it would be a given to included the css into the head inline at export time or a generated resource linked file again export time or a direct integration within the *_hype_generated_script.js at export time.
So absolutely yes, that's the idea , but I did not want to get into the possible pros and cons of fine detail of what would work best for to Tumult consider doing this and honestly I would be happy with what ever thy did (I think) as long as I got the css panel. ( and yes a add/edit css option in the resources much like the functions option)
Certainly, you can cause significant disruptions with CSS in the current version of Hype, as the layout presently relies on the cumbersome use of inline styles and even more problematic container divs. This setup would lead to a nightmare of specificity and layout shifts since the bounding boxes aren't integrated into the HTML WebKit but are instead superimposed. As a result, calculations are based on known values rather than dynamic lookups, such as getComputedStyle. Consequently, any alterations to the layout would necessitate the use of !important, leading to a misalignment with the Hype interface. Moreover, achieving the correct stacking order would prove unfeasible. The level of frustration would be intolerable without a comprehensive overhaul. Although it's a relief that CSS can be loaded as it stands and is effectively applied within the IDE, realistically, the prospect of this advancement being incorporated into Hype seems slim in the near term. However, a significant modernization in Hype 5, potentially even with some disruptive changes, would be welcome. In my view, such an update would be beneficial, allowing older projects to remain accessible in Hype 4
There seems to be some activity going on with Matter.js. There's a "Performance" branch. Also, something about "sub-stepping" was mentioned in the Continuous Collision Detection thread.
Ah cool, thanks for pointing this out. It looks like there are commits that have been merged in from this branch.
I guess substepping is more viable with improved performance, but it still won't fix all passing through walls.
Well, the basic tip from the last post is substepping! Likewise, I don't think this will solve the problem, but may just help it out a bit (though I'm not actually clear why).
, as I took it as a given that with the inclusion of using a side panel as shown, it would be a given to included the css into the head inline at export time or a generated resource linked file again export time or a direct integration within the *_hype_generated_script.js at export time.