Tool to edit plugin.json manifests

Development
1

Sanguine PJ Editor Infomercial

V.O: Hey developers! Are you tired of editing your plugin manifests by hand?

<Audience agrees and cheers>

V.O: Did you know there are plugins without tags?

<Audience boos>

V.O: Fret not! We at Sanguine R&D, may have the solution for you!

Ada (an English lassie): Wow! So many programmers here today! Niklaus! I’m so glad you could join us!

Niklaus (a Swedish gentleman with a thick accent): I could not miss this opportunity. I really dislike editing my manifests by hand.

Ada: Then you are in the right place. Our latest concoction lets you create and edit existing plugin manifests!

Niklaus: I have been waiting for such a program for a long time. Can I edit module tags with it?

Ada: Yes! You can!

Niklaus: I am so happy… there are so many!

Ada: Fifty-seven, in fact.

Niklaus: Amazing! No wonder so many modules do not use them to their full extent.

Ada: Some don’t even use them at all.

Niklaus: The Sanguine PJ Editor can help change that!

V.O: Want to get your own copy? The Sanguine PJ Editor can be yours now for the low, low price of zero dollars!

V.O: You heard that right! It can be yours for zero dollars!

V.O: Call now! 1-800-LAY-Z-DEV! That is 1-800-LAY-Z-DEV! Or visit our github website!

V.O: But wait! There’s more! If you call within the next three hundred and sixty-three microfortnights, you will also get the Sanguine Tag Updater: turn your deprecated tags into current ones right from the command line!

V.O: Remember! 1-800-LAY-Z-DEV! Call now!

Niklaus: We have learned a lot today!

Ada: Indeed we have! I hope our viewers find the software useful.

Niklaus: I am certain they will.

Ada: Time to go now, Niklaus. It was a pleasure.

Niklaus: The pleasure was all mine!

Ada: As my father used to say: “If I do not write to empty my mind, I go mad.”

Niklaus: I do not know what that has to do with plugin manifests; but I hope the viewers like our software.

V.O: Remember 1-800-LAY-Z-DEV! Or visit:

V.O: Get your copy today!

The package is GPL-v3 Free Software.

Binaries are available for Windows and Linux (64 bits only). Provisions are present to create versions for Apple; but no binaries are provided; if you want to contribute them, contact me!

The code requires Free Pascal to build the command line tool and Lazarus to build the GUI editor.

I hope you find it useful :slight_smile:

Some screenies!

pjedwin
pjedwin1443×873 23.5 KB
Windows version editing the Sanguine Monsters plugin info.

pjedlin
pjedlin1445×883 122 KB
Linux version editing the module information for Alchemist, part of the Sanguine Monsters plugin, and showing our pajama wearing monster.

7 Likes
2

Version 1.1 of the tool has been released.

This version aims to make operation friendlier to the user: commits are now per manifest instead of separate per plugin and per individual module: less clicking and less forgetfulness.

The makefile has been fixed for all platforms as well.

Binary releases for Linux and Windows can be found here:

Still no Apple binaries; if you want to contribute them, please contact me :slight_smile:

A piccie of the GUI editor running under MacOS:

applescreenie
applescreenie1376×879 55.9 KB

3

I like the concept in some ways, but I worry that it may be impractical except for editing manifests for your own plugins in development.

If you modify a manifest of some arbitrary plugin, say to add your own tags, then won’t you have to re-edit the manifest every time there is a new release of the plugin?

4

Yes; but preventing that is beyond the scope of this tool.

The intended audience is developers so that users don’t have to add useful tags to their plugins after the fact.

The best user-facing solution, I suppose, would have to be either built into Rack itself (but pull-requests are not accepted) or an alternative module browser (Stoermelder has one; but doesn’t offer that functionality, I believe, also, I saw a thread about building another one; but it seems to have gone to discussion heaven); both could be implemented using an extra json database, to build upon capabilities already present in Rack: something akin to slug → tag-overrides → [some tags added, some removed], that way the original manifest is left untouched; but users can add whatever tags they think are helpful for finding certain modules and remove those they deem just contribute to category clutter, I think.

Third party tools, such as the PJ Editor, could offer some sort of solution; but I think it’s more hassle: a daemon (or equivalent) that keeps an eye on certain files and adds/removes stuff? Something that latches onto a process and injects tags? Doable, at least under Windows, but not very nice and prone to trigger AV software.

The best solution, right now, for what you mention, I think, is convincing devs to use/update/refine the tags for their modules. These tools strive to make that easier.

1 Like
5

OK, I see where you are coming from.

I have never felt any burden editing the manifest by hand. But if the tool helps some developers improve their manifest, that is fantastic.

2 Likes
6

I agree. The json format is straight forward and easy to read/edit.

The json format only lacks comments, but no editing-tool could help here in the first place.

7
8

I’m aware of json5, but if I add a comment to my plugin.json file, I get an error like that:

image

but lines like that are possible in VCV:

"__comment": "here goes my comment content",

9

Well yes, you would need to transpile the json5 into regular json as part of your build process… should be fairly easy to do if a dev really wanted to use the extra features in their manifest

edit: a quick search gave me this GitHub - mortie/json5cpp: A JSON5 parser for C++ built on JsonCpp. (if you didn’t want to use the node.js implementation)

edit 2: I wonder, perhaps @Vortico would consider building json5 support directly into Rack itself? Not sure if the effort/benefit ratio is high enough…

1 Like
10

I don’t think the lack of comments is the problem for this particular case: the key names are, I’d say, pretty self explanatory; the issue, in my eyes, is the amount of tags and how they are documented (a long list without consistency [some tags don’t have descriptions], index and with deprecated tags interspersed between the current ones); and json itself, from my Drawer of Unpopular Comments(T.M): I prefer XML (it has comments out of the box, too).

The use case I see for comments is temporarily disabling a module.

1 Like
11

I simply use "hidden": true,

1 Like
12

Indeed.