Instead of using a state freeze as a PLIST, I would prefer an actual HTML state. This change would facilitate third-party integration and adopt an open file format (HTML). A translation engine could be implemented to convert HTML to the internal PLIST and the new storage adaptor format, streamlining loading and saving processes without necessitating significant refactoring.
Have you found a workaround for this problem?
Not really, I always need to hack my way into PLIST to do anything in import related in Hype. Especially with the change of macOS to binary PLIST, one can't effortlessly open PLISTS anymore without translating them to the string representation. At least Hype can still read the unpacked text PLIST.
Are there examples of other apps with this feature? Or, have you seen examples of this elsewhere on the web? (Please include a URL)
Many HTML apps use HTML itself as storage, allowing users to continue with the project even if the editor is not installed or use other editors interchangeably.
How high of a priority is this for you?
I guess, aspirational for me… but low for most.
[ x ] Nice to Have
[ ] Important
[ ] Can't use Hype without it
I was trying to figure out what was the feature being presented here. The numbering with the bullets was confusing enough.
But after thinking about it, this is not a “Nice to have” feature. It's at the core of what's stopping Hype from being more popular software…
Mac only — Plist?! That's an Apple thing. It's another barrier preventing Hype from being cross platform. It's for web animation and web development. The web works cross platform, but this software does not. It's a critical and crippling flaw of the application.
One-man army — Hype is basically software for soloists. Collaboration and Hype is not really a thing. That was OK in the days of Flash and even the early days of Hype. But now, the days of a “Webmaster” are not common. It's more than just one guy that is expected to do everything. Modern web development involves git and version control. Dumping that into a single data.plist ProperyList is not ideal.
Easier project uploading — If Hype's native format was HTML, that might make it easier to update files. Instead of uploading everything, only changed files could be uploaded. Again, that goes back to git and version control.
There are downsides though… complexity, perhaps security, lots of development time required to switch.
Yes, the numbering is sadly part of the feature request template provided by the forum when adding a new post to this category. It could be reworked into a headline-based sections—totally!
I'm pleased to hear you find it important as well. Interoperability is indeed a significant issue and challenge, particularly with its attached sanitation challenges. However, it has the potential to simplify portability and facilitate the integration of Hype into various workflows, including importing, exporting, postprocessing, and on-the-fly Hype file generation.
We had considered .html during initial development. The issue is this would encourage editing (as you want to do) and then require a very sophisticated parser - one that can deal with the myriad of html capabilities and also be resilient to faults. Otherwise our support would be endless requests to fix up documents that users had mangled in some way. Hype needs a very strict view of the world to operate, but browsers are able to be much more resilient.
Basically the plist format was easier for development and meant to discourage folks from doing what you want to do .
As an Xcode user, I definitely feel this problem with plists too.
Well hope it’s not the end of the request. I don’t mind a very strict parser that fails on anything it doesn’t know or like (ignore or fail). At least it’s an open text format.
It isn't the end - I do understand the need of the request. However, mucking with the file format is unsupported and will become harder (zipped flat file) before it gets easier. I'd rather add automation capabilities to accomplish most of your goals.
On the more version control case, I'd love if this were better too, but the reality is that version control rarely works well on machine-produced structured data, even if there's text formats that are better in some small change use cases. Collbaoration on visual tools is also more useful when done visually (see: figma).
.
.