An asset manager is undoubtedly  something  needed very badly -

There are some features that would be needed - which Jehan summarized quite
well in an e-mail sent about 2 years ago (I remember the date because I was just
back from Leipzig)

At first, I think requiring all assets to be in a git repository (git
uses URLs - no need
to require a specific provider) - would itself be overkill. So maybe,
just make content
'uploadable" might be enough. On the other hand, gitlab might provide
ownership and content meta-information in a way we would not need to
care about them -
just a system for one to enter a git (gitlab) URL and branch name - maybe
requiring certain information to be in the repository.

Curation of assets remains one of the hardest points - it might be a
_lot_ of _boring_ work -
and even somewhat dangerous - but still, I can imagine 2 categories of assets -
one endorsed by the "GIMP team" - - i.e. curated - with no dangerous
and a "watch yourself"   mode in which anything could be downloadable.

Either way- wathever is designed to register GIMO assets server side,
a Python program can be made, to
run as a GIMP plug-in, that would provide a search, download and
install interface for things
registered on the server side. This program is not a huge thing to do
and would effectively provide GIMP
with its own "asset-store".

Anyway - just to get the ball rolling -
I suppose this could be a topic with its own BoF session in London

On 1 April 2016 at 17:32, Pat David <> wrote:
> Continuing on some discussions from irc...
> is down for the count.
> I was thinking recently about some ideas for a possible replacement.
> Mostly thinking along the lines of what made the registry work well for
> folks.
> In the rest of this email, I'll use the term "asset(s)" to refer to things
> like plug-ins, scripts, or brushes/gradients/curves/other assets.
> Some essential functionality based on the old registry drupal instance:
> 1. Upload/Download assets for GIMP.
> 2. Describe the asset (usually by the uploader).
> 3. Comment on the assets.
> This was handled previously by using drupal, which treated each entry as a
> post/node that included the ability to upload files, write about the files
> as a post, and had comment threads below it.
> Keeping this functionality would be good, I think.  The ability to post an
> asset is a given, but the ability to interact around it helps foster the
> community (and provides nice feedback for the authors).
> From those thoughts, what would be nice to have in a replacement:
> 1. Provide at least the same previous functionality (as listed above).
> 2. Managed or easier to manage and keep updated.
> 3. Easier account management.
> 4. Collaborative environment for shared assets
> 5. Support possible GIMP integration in the future (one-click asset
> install?).
> GitLab?
> ======
> Initially, I had thought Github might be a good option for this but given
> its closed-source nature decided to investigate something like GitLab
> instead.
> I like this idea personally due to some nice infrastructure:
> 1. The service is hosted + managed (and available as Free Software just in
> case we felt we needed to break out and host it ourselves).
> 2. The service integrates OAuth sign-in using a few different account types
> (lowers barrier to entry to participate).
>     a. they use accounts, Google, Twitter, Github, or bitbucket accounts
> for sign-in.
> 3. Projects maintain all the git-goodness for control and tracking
> 4. Projects created as a git project can have a full description/README
> along with issue tracking integrated in the site
> So, we can fulfill the original registry functionality and get the added
> benefit of a git infrastructure for those wanting to contribute, user
> accounts using OAuth to make it easy to participate, and the ability to do
> some interesting things (git submodules).
> In speaking with Jehan about this, we should also consider what might be
> needed to support the ability to install assets from within GIMP in the
> future easily.
> Organization
> =========
> Jehan suggested that each script/plugin/asset have it's own git repo.
> This would be handy, particularly if script authors did this as well (as it
> considerably eases the inclusion of external repos as submodules).
> However, akk points out that many folks don't (won't?) organize their repos
> in this way (it gets a little... unwieldy pretty quickly if you have many
> scripts).
> I'd like some input on what would make the most sense or work best for
> possible organization of repos.
> I was also thinking that we could include some simple metadata in both any
> script files and the files as a means to possibly help parsing
> relevant information for automated inclusion at a later date (GIMP plug-ins
> installer type of idea).
> Curation
> ======
> Initially I was thinking that curating the scripts for inclusion would be
> important.  It's certainly possible for a smaller subset of all of the
> available scripts from the registry now to pick out ones that we use and
> check that they're not malicious and properly tagged/included.  For
> instance, there's a handful of scripts that I personally find myself using
> often and can help validate/curate for inclusion.  I don't mind doing more
> as needed.
> I just wanted to get a discussion started about how we might consider
> moving forward on something like this.  I think the scripts/plug-ins are
> important enough to users that it would be good to try and get something up
> and running soon.
> I have started experimenting with including submodules from other author
> repos and how it might look here:
> I look forward to hearing some thoughts on this!
> pat
> --
> Pat David
> _______________________________________________
> gimp-developer-list mailing list
> List address:
> List membership:
> List archives:
gimp-web-list mailing list

Reply via email to