~vcs-imports/gimp/+git/gimp:wip/alxsa/mypaint-brush-v2

Last commit made on 2023-08-04
Get this branch:
git clone -b wip/alxsa/mypaint-brush-v2 https://git.launchpad.net/~vcs-imports/gimp/+git/gimp

Branch merges

Branch information

Name:
wip/alxsa/mypaint-brush-v2
Repository:
lp:~vcs-imports/gimp/+git/gimp

Recent commits

5928898... by Alx Sa <email address hidden>

Add pressure gain control

e696a4d... by Alx Sa <email address hidden>

paint: Add support for MyPaint Brushes v2

2c98965... by Yuri Chornoivan <email address hidden>

Update Ukrainian translation

3729557... by Yuri Chornoivan <email address hidden>

Update Ukrainian translation

c64d7a7... by Martin Srebotnjak

Update Slovenian translation

c42e205... by Ekaterine Papava <email address hidden>

Update Georgian translation

22f1203... by Jehan <email address hidden>

Issue #9655: both @blurb and @help arguments should be localized.

Looking further, the @help is only used in gimp_proc_view_new() so far (for the
Procedure Browser) where the blurb and argument descriptions are already
localized. It makes no sense to only keep this in English. So let's ask to have
both arguments translated.

Now clearly we should not ask for @help to be mandatory. Very often, it makes no
sense to have a longer help string (the small blurb and the few arguments may be
very self-explanatory). So I make this argument nullable.

There is only the @help_id which I wonder if we could not have a simpler
function gimp_procedure_set_documentation_uri(). Indeed while having a unified
infrastructure with a XML summary and help IDs and whatelse makes sense for GIMP
as a whole, I think that many third-party plug-ins would work much better with a
very simple direct URL. Or it could even be a GFile to a local file (for
plug-ins which want to embed their documentation in the plug-in folder for
instance). To be continued…

ce0a840... by Jehan <email address hidden>

libgimp, libgimpconfig: GimpResource can now be (de)serialized.

I add a new class method deserialize_create() to GimpConfigInterface which
returns the GimpConfig object per deserialization, instead of modifying an
existing bare object.

This matters for cases like our GimpResource (and later our GimpItem) classes
which are fully managed by libgimp and should be unique objects per actual
resource. It should even be possible to compare the pointer itself for identity.
That's why we need to let GimpResource create the object (in reality request it
to the infra and only ref it) through this new class method.

With this commit and the previous ones, all GimpResource are now properly stored
as plug-in settings (e.g. the "film" plug-in has a font setting which is now
properly remembered).

These identifiers are not portable (across various installations and therefore
not for XCF either), but at least they are reasonably identifying data on a same
installation (unlike GimpResource's int ID which is only valid within a single
session) which makes them very fine for plug-in settings storage.

When a data file disappears, we fallback to the context default data instead.

38c717b... by Jehan <email address hidden>

app, libgimp, pdb: private _gimp_resource_get_by_identifiers() PDB function.

This finds the core resource knowing its type, name, collection and internal
state (in other words, the values returned by _gimp_resource_get_identifiers()).

fe58de7... by Jehan <email address hidden>

app, libgimp, pdb: new private PDB call _gimp_resource_get_identifiers().