After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 724101 - [PATCH] Add gimp-text-layer-set-markup pdb function
[PATCH] Add gimp-text-layer-set-markup pdb function
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: libgimp
git master
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2014-02-11 07:29 UTC by Ian Munsie
Modified: 2018-05-24 14:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to add gimp-text-layer-set-markup pdb function (12.25 KB, patch)
2014-02-11 07:29 UTC, Ian Munsie
reviewed Details | Review

Description Ian Munsie 2014-02-11 07:29:11 UTC
Currently the GIMP provides a pdb function to get the markup of a text layer, but has no corresponding function to set the markup from a script - only the plain text can be set, losing all formatting.

The attached patch provides such a function, including adding the root <markup> node if required, and running the markup text through pango_parse_markup() to check for errors before actually setting it on the text layer.
Comment 1 Ian Munsie 2014-02-11 07:29:55 UTC
Created attachment 268768 [details] [review]
Patch to add gimp-text-layer-set-markup pdb function
Comment 2 Michael Natterer 2014-02-11 08:28:44 UTC
Thanks, that patch looks 100% correct and can be used as a first step,
however the reason this API didn't exist so far is that the text tool
only understands a specific subset of markup, the one it created itself.

We either need to mark this layer as uneditable by the text tool, or
add whatever validating that makes sure only that subset gets set.
Comment 3 Ian Munsie 2014-03-26 23:51:20 UTC
Sorry for the delay in replying - I've been too busy recently to look at this and the patch I submitted has been sufficient for my immediate needs.

I've been thinking - I don't want to restrict what markup can be set by a script, but it might make sense for the text tool to warn when trying to edit a text layer with unsupported markup - similar to how it currently warns when editing a text layer that has been modified by other tools. It could ask to discard all unsupported markup, or attempt to edit anyway.

I guess the gimp_text_layer_set_markup API should also document this limitation and recommend sticking to the subset of markup supported by the text tool.


It seems that the text tool actually already behaves somewhat reasonably when editing a text layer with unsupported markup - unsupported tags (big, small, sub, sup, tt and spans that start with an unsupported attribute) seem to be dropped as soon as the layer is edited, but not before - just selecting a layer with the text tool does not discard them. It might be a good idea to have it recognise simple aliases (foreground == fgcolor == color) and in the long run perhaps even preserve unsupported tags.

It will probably be a while before I get round to coding any of this up, but what do you think? Do any of these ideas seem reasonable?
Comment 4 Michael Natterer 2014-03-27 00:21:51 UTC
You sound totally reasonable. Given that we need a PDB API for text
layers at some point, we should get started with something :)
Comment 5 Jehan 2016-11-07 02:08:24 UTC
Mitch, didn't your comment 4 mean that you validated the patch to be pushed in its current version (and later we could improve it, likely with warning when using unsupported markup as comment 3 suggests)?

If that's what it meant, let's check it still applies fine and let's push, no?! :-)
Comment 6 Michael Schumacher 2016-12-30 21:38:49 UTC
This still applies, with one minor change (in an auto-generated file, anyway).
Comment 7 GNOME Infrastructure Team 2018-05-24 14:17:41 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/534.