A Plugin System


#1

Issue

I am sure there are many features we would like to see in Hype. I for one would love to see a bezier pen tool.

Request

I would like to both request a feature and also discuss some good alternatives that might suffice for adding new features to Hype.

I am requesting a plugin system based off of the already flexible system in place. This way Hype developers won’t have to update Hype with new features all of the time.

Alternatives

  • Knowing that we can use external libraries, I started experimenting with paper.js and was able to do get some cool stuff working in Hype. But there still is no pen tool.
  • Perhaps we can create Hype Javascript Libraries that load dependencies for us and allow us to add tools to our document via code. But, I would still like to see tool icons.

Solution

N/A

Please discuss any solutions or ideas you might have for good alternative solutions.


(Mark Hunte) #2

I am constantly thinking “If I could only write a plugin for Hype, to do this or that”

Like ;

  • code completion, code folding and inline syntax warnings. Or simply when you double click a bracket it shows you it’s partner.

  • New types of event actions in the inspector.

  • bezier pen tool, which many of use have request in one form or another…

I have actually written a text replacement app for Hype, that allows me to type a keyword in Hype functions and my app will expand to the matching stored text.

Here is a quick video of it.

( I am actually, trying to find the time to re write it, as although it works really well, some of the storage methods need changing… )

There are problems with the idea of plugins that directly tap into the code of an app to alter it’s display and functions as you describe

A badly written plugin could cause havoc with Hype where in the end the Hype team would have to possibly waste a lot time trying to put out the fires.

Also how many of Hype uses could or would write such plugins… would the effort of introducing a plugin framework be fully realised by us the users!


Update. Put the video on my own site due to dropbox being .S…t


F.ing Dropbox ban!
#3

Yes. Things like IntelliSense and code folding would be very useful. It seems though that the Hype API isn’t very large other than the few functions you have to use that are Hype specific like hypeDocument.getElementById() rather than document.getElementId().

I found myself using Brackets for this purpose. I am thinking of a Hype plugin for Brackets. A common practice is to use external editors anyhow.

I would really like to discuss alternatives here as well (something like companion apps of the sort you have created above). Such apps can even be built using node.js fairly easily.

I will be doing a bit of research on this myself and report my findings here. Any more solutions or alternatives are welcome.


(Pete) #4

Yep, Hype is missing out on of the biggest feature, which is to let developers write plugins? I know Jonathan mentioned something about that.


(Jonathan Deutsch) #5

Hype 3.6 has the Export Scripts feature, which allows for some plug-in capabilities. Also several of the features listed are upcoming :slight_smile:.

Ultimately “full access” plugins either A) destabilize the app or B) paralyze us from making changes. (or C) are vectors for security/privacy issues). So any access is carefully considered and slowly rolled out.


(Pete) #6

I know about the scripts and I’m thankful for that at least. Though, I still feel like the developers should be able to have their own plugins with versioning to support for future iteration of Hype much like in any other applications wether it be Final Cut, Motion, Illustrator, Photoshop, After Effects…

When you say ‘Paralyze us from making changes’ or ‘Destabilize the app’ sounds like a mass paranoia on your behalf :wink:. Maybe you should look into how Apple or Adobe handles third party plugins?

One Idea would be if developers can write and submit their plugins/addons/extensions maybe directly to Tumult for beta testing if checks out with Tumult they can release it. Update: According to Mike its not a good idea

“Slowly rolled” out like in Version 10 perhaps? :sweat_smile:

plugins


(Mark Hunte) #7

The app could easily become unstable because a plugin would need to not only interact with it’s UI but also with if core code.

I am not sure thats a good way to go. It would just pass on a workload to Tumult that the developer should do.

If it was possible, one way would be to have a sand boxed /dedicated UI area and access to some public functions similar to how a service handler in an App works.

This way Tumult keep some control over access in the same way they do with the Javascript API


(Pete) #8

That works too.


(Jonathan Deutsch) #9

It is not. I was specifically referring to “full access” plugins. It is the easiest solution for an app to implement, but also laziest and will cause issues. Historical examples off the top of my head that have caused tons of problems:

  • Browser plugins (like Flash!)
  • InputManager/SIMBL
  • Sketch plugins
  • Mail.app plugins
  • Xcode plugins

I dealt with a lot of the fallout of these while at Apple. Now they are even significantly locking down items like kernel extensions due to the havoc they can cause, not to mention SIP, and also Mac App Sandboxing makes it really hard to load or run external code in apps as well.

Plugins should follow an API contract with the host app, and ideally be sandboxed to avoid compatibility issues or bugs from simply bad programming on the plugin author’s part. This is how all modern and smart apps deal with it.


(Pete) #10

I wasn’t specifically referring to full access plugins. It can be in a form of an extension, add on or what have you by third party/developer and not necessary a plug in system that would bring about havoc.


(Mohammad Khan) #11

Hey Jonathan,

What about making an SDK for developers to write plugins or extensions in a secure way that does not compromise the Hype application. The problem that I would see here is how would you “vet” or “approve” plugins… would you do an “App Store Style” model where you would approve the plugins before they are available for public download by the community?

Thanks,
Mohammad


(Mohammad Khan) #12

I would love a more robust code editor, I think a lot of people are used to Xcode and other IDEs where code completion, syntax warnings, etc. are just the norm.


(Hans-Gerd Claßen) #13

upcoming 4.0 you can use the codeeditor of your choice …


(Jonathan Deutsch) #14

It isn’t so much approval or vetting that is the problem, but that a plugin SDK is a contract from me to a plugin developer that the APIs will not change. Having a specific API is great for stability but limits freedom since we would need to provide useful entry points to the app (and would definitely miss some). Further, too great of an API surface area can hurt Hype’s feature development - both the pace as there’s more QA to do, and what features are offered, since we can’t really remove a feature that the API vends!

I think it is probably better to get a grasp on what folks are trying to do. For example we needed highly dynamic export flexibility in packaging for ads, thus the Export Script plugin API was made. For more flexible code editing, I think the v4 approach of allowing external editors hopefully will solve that problem. You’re always welcome to chime in with other use case needs – as some of these might more favor a plugin API.


#15

It’s funny. Lately, I haven’t felt that Tumult is lacking in features… other than cross-platform support (Windows / Linux) and better Physics. The Export Scripts option is very powerful. And if Hype doesn’t do something, I can just add some JavaScript to make it do what I want…

I thought about the importance of AppleScript / JXA support for Hype, but Apple itself doesn’t seem to have a clear direction with that. When macOS is not clear with a direction for automation, it doesn’t seem like a realistic expectation for Tumult Hype to support it too.

That’s why I think Tumult should focus on marketing and/or a Marketplace – rather than features. The world doesn’t really know how powerful this software can be. Projects like this…

…can be lost in the noise. I think most people would say, “A Virtual Keyboard” is a nice feature to add to Hype… but Tumult doesn’t need to waste time developing it, not when people can create it themselves. Particles, Export-to-App, Charts, JSON… it could be available for Hype users, where third-party developers and Tumult can both profit.

Although, that’s just trading the technical debt of managing an API for the burden of managing a digital store. I suspect Tumult is not keen on such projects.

Still, I feel like this software is really mature. It’s just not really popular. The focus should be on the latter. That’s better for the community and Tumult.