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.