CanvasGUI problems

Your repo isn’t following the standard way for versioning! :warning:

You have a /dist/canvasgui/ folder where you keep all your minimized version release subfolders.

Although that’s OK if we wish to keep all releases in 1 place, that’s improper for CDN distribution links!

The proper way is to always have the latest version at the repo’s root and then create repo releases for it:

If you click the link above and are the owner of the repo, you’ll see a big green button labeled “Create a new release”.

Given canvasGUI’s current latest version is 0.9.6, choose a tag name:
v0.9.6 (the v prefix is optional, but recommended)

Those repo tags are the way CDNs identify releases!

If you add release v0.9.6 and have “gui.js” file at the repo’s root, the jsDelivr CDN links are gonna be like:

  1. https://cdn.jsDelivr.net/gh/quarks/canvasGUI@0.9.6/gui.js
  2. https://cdn.jsDelivr.net/gh/quarks/canvasGUI@0.9.6/gui.min.js

BtW, jsDelivr automatically generates a minimized version if we use extension “.min.” if 1 doesn’t exist.

But of course, you can explicitly make “gui.min.js” and place it at the repo’s root along w/ the non-minimized “gui.js” version.

Also, if we omit the “@0.9.6” version, we’ll get the “@latest” 1 by default:

  1. https://cdn.jsDelivr.net/gh/quarks/canvasGUI/gui.js
  2. https://cdn.jsDelivr.net/gh/quarks/canvasGUI/gui.min.js

I believe if you follow that style, it’ll increase the chance to be approved by the Open Processing sketch hosting site. :folded_hands:

P.S.: Of course you can do all that and still keep your “/dist/canvasgui/” folder. 1 doesn’t exclude the other. :grinning_cat_with_smiling_eyes:

1 Like

I have already sent the link to OP. I have not heard back yet. Please let me know ASAP if the link is changed. Thanks.

Richard

1 Like

Hi Richard,
I will be following the guidance from @GoToLoop so the version number and link will change so perhaps ask OP to wait a bit until I get the release setup right.
Thanks
Peter

1 Like

I’ve noticed you’ve already released v0.9.6 as version 1.0.0:

However, you’ve forgotten to add file “gui.js” and/or “gui.min.js” to your repo’s root folder!

So this link still doesn’t work: =(
https://cdn.jsDelivr.net/gh/quarks/canvasGUI/gui.js

You still can delete both the release and its corresponding tag v1.0.0; add “gui.js” to the root; and then re-release it as either v0.9.6 or v.1.0.0.

P.S.: You can take a look at q5.js repo as a model:

1 Like

It seemed to me that key advice was to create a Release in github which can then be accessed using the CDN. The actual location of the library files is not that important so I decided to leave them where they are as I wasn’t keen on having them in the root folder (personal preference). Admittedly it makes the CDN link longer but then it will be copied and pasted rather than typed from scratch.

All the versions of canvasGUI prior to 0.9.6 where created during the development stage and I believe it is now production ready for release, hence the new version number (1.0.0). I will be not be creating Releases for earlier versions as making them available via CDN is superfluous.

So to use canvasGUI the user just has to copy and paste this link into in the head section of their webpage.

<!-- =======  canvas GUI  ==============  -->
<script language="javascript" type="text/javascript"
  src="https://cdn.jsdelivr.net/gh/quarks/canvasGUI@1.0.0/dist/lib/gui.min.js">
</script>

This is the final link which I have tested in p5js web-editor and have updated all pages on my website that use canvasGUI. Obviously I can not test this in Open Processing.

@rbytes you can send this final link to Sinan :grin:

@GoToLoop thanks for your help and advice. :+1:

1 Like

Could you at least add that path to “package.json”'s “main” property for the next release?

{
  "name": "canvas-gui",
  "version": "1.0.1",
  "description": "On canvas GUI for p5.js",
  "main": "dist/lib/gui.js",
  "browser": "dist/lib/gui.min.js",

“main” points to the non-minified version, while “browser” points to the minified 1.

Anyways, to always get the latest version, we can use this link:
https://cdn.jsDelivr.net/gh/quarks/canvasGUI/dist/lib/gui.min.js

This explanation differs from the npm docs. So I will not be changing these for the moment especially since canvasGUI does not use modules. I will change the version number - just an over-site on my part :innocent:

You are correct there and I will be making a formal announcement of canvasGUI 1.0.0 and include links for both current (1.0.0) and latest versions that users can copy. Before that I will be including these links in github and my website documentation. So much to remember :grin:

Creating github releases and CDN links has been a useful learning experience for me so thanks again for your help.

1 Like

In Node.JS, JS files are always treated as a module, regardless it’s CommonJS (.cjs) or ESM (.mjs), or it’s just using extension “.js”.

Even though the entry “main” has a specific meaning in Node.JS, some CDNs may read the root “package.json” and identify paths for it and other properties, such as “browser”, “types”, “module”, “exports”, etc.

BtW, “index.js” doesn’t even exist in your repo’s root, and having “main” pointing to the actual library file “dist/lib/gui.js” can help CDNs and, if you end up publishing your library as an NPM package as well, identify the real executable file!

As an example, p5.js 1.x.x has a “main” entry pointing to “lib/p5.min.js”:

And that’s why some CDNs allow this very short URL for it:
https://cdn.jsDelivr.net/npm/p5

Although it seems like they’ve replaced “main” w/ “browser” for its next major release 2.x.x:

Not sure why wouldn’t they keep both. But anyways, 2.x.x is already a compatibility wreck.

There is no control of type ‘Titles’ but from your description I assume you mean CvsTextField controls.

When I created canvasGUI my priority was to provide a range of colour schemes for users to choose from so they could quickly create an attractive GUI and then get on with the code logic needed for the actual sketch.

So at the moment it is not possible to change the colour of individual elements of a control, including font colour.

There seem to be two options

  1. add functionality to change individual colour elements on a control-by-control basis
  2. enable users to create and apply their own colour schemes, probably using one of the predefined schemes as a starting point.

I have not decided on which approach I might take as I need to consider how it will affect the current implementation and the user experience.

If you are interested having this features please add an issue to the github repo