Gravit Designer discussion

How does an API will look like?

Hey,
Did anyone have an idea how the API will looks like? And which language it will use?

Max

Taking advantage of one question and doing another. How to begin? Where is the repository? And what structure should we follow to develop the plugins? Will it be necessary to have a plugin manager like Atom and VSCODE?

Ok.

Will it be necessary to have a plugin manager like Atom and VSCODE?
I think it would be nice.

I thing so! :relaxed:

Wouldn’t it be best if it were in JavaScript since Gravit is technically web based?

Hi everyone,

We’re actually just starting and invited some people to discuss the best and most comfortable way to develop plugins before “just doing” it on our own and doing it wrong.

Here’re a few first thoughts:

  • There’ll be a global repository in our backend so we have a central place
  • Every plugin actually should link to a github repository so we can utilize tags for versioning automatically
  • There’re two APIs – The Gravit Designer API and the Document API
  • Plugins are supposed to be written in plain Javascript / HTML / CSS
1 Like

Hi,
is your system based on electron? If so, it should be possible to port the Atom Pluginmanager to gravit.

Max

In javascript … you are using something like angular, react, vue, etc…? I want start a local plugin, and in future migrate this to Gravity… I think that do with the same technology is a good idea.

@zeugmedia yes the desktop apps are based on it. However, the web version, the chrome version nor the iPad / AndroidTablet versions are based on it obviously so we need to brew our homemade sauce for it :wink:

1 Like

@jhoylucas74 Nope we actually do not use ANY framework. We’ve written all ourself so you’re free to use plain html. The only thing we’re using (from the old times ;)) is jQuery. We have quite some jQuery plugins that plugin developers should re-use to give a common look and feel like property rows.

We will actually discourage the following techniques from plugins:

  • Webpack / Modules
  • ES6
  • External Frameworks

The reason is the loading time and complexity of plugins should not overtake the main application itself.
Not sure if that’s the right way but we want to prevent users having a (potential) bad experience. What you think?

1 Like

sure. Is there any plan to “opensource” the webversion/electron version? Or can someone contribute in other ways?

1 Like

The concern makes sense. I’m excited with this … i will make my local plugin with plain html and ES5 and when the plugin management system is ready … I will migrate then to he.

1 Like

Currently there’s not. The issue is that we actually want to keep the Designer REALLY free and thus our business model is to sell our framework / engine to others. If we’d open source it we’d lose our business model after all our designers and developers need their payment :wink:

Its a pity I know as sometimes we could really use more help being so short on resources here already ;(

1 Like

@jhoylucas74 sounds cool keep us in the loop on that!

One thing we’re thinking about right now is what’s the best way to make easy plugin development possible. I mean, you need a running instance but you can currently not develop within the Designer.

If you have any ideas anyone please let us know

(yes you can execute scripts on the console)

1 Like

I think executing scripts via the console could be pretty annoying, especially for debugging.

Can’t electron inject external javascript into the webview? If so, would it make sense to allow the desktop clients to load local files (js, css) into the view and somehow use a main execution class to run all loaded injections?

Otherwise this also feels incomplete and also I wouldn’t know where to put my html files to edit the UI.

Any other ideas?

Maybe a Web Worker plugin system? Run the plugin in a box(worker)… The problem is the DOM. One api with the Gravit will solve this too. Is a Idea… The plugin will running in parallel, and in theory, not block the Gravit. And run in all web based platform.

What about some kind of developers mode in the desktop applications? Like Google Chrome has when developing extensions. That could work I think, enable the dev mode and then have some sort of form to load your plugin from a directory or something.

1 Like

@jhoylucas74 yes that’s the problem workers have no access to the DOM etc

@liammartens yes that’s what we thought. The problem is you’d need a way to reload the app every time you change something as otherwise you can not update your plugin ;(

Well it’s built on electron is it not? at least on the desktop? So you can probably implement some kind of live reload by checking the file modification times of the loaded development plugins and reload based on that (or something)