2024-02-15 Extensions Project

Meetings
,
1

Attendees:

  • Dalai Felinto
  • Francesco Siddi
  • Pablo Vazquez

Recent changes

Blender:

  • Support .zip extensions.
  • Human readable license IDs.
  • User interface updates.

Site:

  • Support for beta badge (it is a feature switch, making the site ready for when it enters beta).
  • OpenAPI support and direct API “application/json” redirects.
  • Support deleting versions.
  • Draggable Get button to install extensions.
  • Several bug fixes (e.g., deleted extensions were listed, …).
  • Add translation tag to most of the website text.

Manifest changes:

New field to hint at which permissions users may expect from an add-on:

  • permissions: [‘network’, ‘files’]

General Topics:

  • Internet
    • The main supported use-case is to ask users once (per online repository) and then automatically connect to the repository server upon opening Blender.
    • If users want to disable repositories, that is possible, but upon re-enabling it, internet access will have to be granted again.
  • Permission
    • We want to give users some clues as to what the extension may be doing.
    • At first we will allow them to say whether the add-on uses the internet (network), and whether it access the file system (files).
    • Blender should give a hint about that as well.
    • The manifest file will be updated to support this optional field.
  • Thank you / donation / sponsor link
    • Allow an extension to have a link to a patreon/ko-fi or other crowdfunding site.
    • It can even point to a premium (paid) version of the extension.
    • This is a way to reinforce the role of the community on keeping this part of Blender alive, and foster a sustainable Open Source culture.
  • API:
    • The site now uses OpenAPI
    • Blender still need to point to the new API to query the extensions.
    • Bonus if Blender can even ignore the protocol (http/https) when entering the URLs.
    • Because we don’t want the URL to change between Blender versions, the URL is the same and we pass the blender_version as a parameter.
    • Internally the server redirects to the correct API entry point based on the version.
    • This is the recommended advice for 3rd-party online repositories as well.
  • Review track
    • This is the biggest remaining task required for the alpha launch.
    • Francesco will implement a simple solution where:
      • A new “Review event” for new submissions.
      • A list for all the “unreviewed” reviews.
      • A detailed view with all the extension info
      • [Approve | Request Changes | Reject ] + a compulsory “Comment” field (which can be LGTM for most cases).
      • Non-moderators can also add comments to the thread.
      • A separate [Publish] button, for approved extensions.
      • The idea is that in most cases one moderator approves, and another publishes it.
    • Only the first version will be scrutinized/reviewed.
  • Change-log
    • In the future it would be nice to have a site-wide change-log.

New Tasks:

The comprehensive list of tasks is here. A few tasks were added to the list:

  • Find a replacement for fcntl (it doesn’t work on Windows).
  • Pass blender_version=<blender_version> when querying the API.
  • Use Blender notifications (instead of custom dismissible ones).
  • Show confirm pop-up every time you try to enable a repository.
  • Manifest changes: optional field: permissions: [‘network’, ‘files’]
  • Redirects to different API entry points depending on the blender_version argument.
  • Add sponsor_link to model (not to the manifest).
  • Check if download count is working
  • Hide alpha/beta badge when on mobile.
  • Analytics: Add code snippet to templates…
  • Splash screen: Add option to enable online repositories on when opening a new Blender.
  • Add Online Repository: Add the option to enable the new repo with a disclaimer.
  • Package and upload Amaranth
  • Privacy page.
  • Terms and condition page.
  • About page.
7 Likes