GNOME Bugzilla – Bug 631934
Interaction between Old text parameters and new region specific text attributes
Last modified: 2018-05-24 12:52:11 UTC
Since we now have a much more advanced text editor than the one present in 2.6, setting the font size, the text color and some more paramters globally using the tool-options dialog is not really good since these do not appear inside the on-canvas editor. We should make it clear that these are "Default values" which will be overridden by the on-canvas editor, and we should make them appear in the on canvas editor by adding tags around the entire text that specify these. Then, any editing of the text would create inner tags, that will overrid the outer ones if necessary. Detailed Example (ignoring all the properties except for color): The default color is black, and the text is "Hello World". At the begining, the inner markup will be <markup>Hello World</markup> And the actual rendered markup will be <markup><span foreground="#000000">Hello World</span></markup> And the user now selects a part of the text using the on-canvas editor and makes it green. The inner markup will be: <markup>He<span foreground="#00ff00">ll</span>o World</markup> And the actual rendered markup will be <markup><span foreground="#000000">He<span foreground="#00ff00">ll</span>o World</span></markup> Now, the user can change the "default" color to red, and then all the parts except for the one that was green'ed will become red - since the inner markup won't change but the outter markup will be: <markup><span foreground="#ff0000">He<span foreground="#00ff00">ll</span>o World</span></markup> Now, when reseting the style using the clear button on the on-canvas editor, the inner markup will be cleared, and so we'll see only the outer markup generated by the default values. Now, why go through this complex way? Why not get rid of the old global/default parameters? The answer is backward compatiability - this way we allow all plug-ins that created and manipulated text, to continue to work. Since, if a layer has no markup (that was the state when the old plug-ins were written) then only the outter markup affect the text, and it will affect all of it. So we change the existing functions to operate on the default markup, and introduce new functions to manipulate regions of the text. Also, currently the rendering of the text inside gimp is done by setting the values from the tool options dialog (the default values) explicitly, and then by setting a markup on top of it. There are some issues with setting a markup after setting some other attributes explicitly - for example when setting the markup after, it will change all the unmarked areas to black and it will ignore the "default" color specified in the tool-options dialog. However, if we set everything using markup then we won't have such bugs, and the current style will appear inside the editors (the editors use a gtktextbuffer which is styled in synchrnization with the markup). Right now, placing your cursor inside unstyled text won't show any attribute value (such as size) even if this was already set in the tool-options dialog. See also Bug 625273 regarding fixing the differences between the on-canvas editor and the dialog editor.
It would be good to get guiguru's input on this too (maybe you already talked to him?)
Fixed the actual bug here. The fate of the GUI around these GimpText options is still open. commit dcdc09872dcdec71c24b8204bfa9ff41238eefb8 Author: Michael Natterer <mitch@gimp.org> Date: Fri Oct 29 04:45:12 2010 +0200 Bug 631934 - Interaction between Old text parameters and new region specific text attributes This patch inserts GimpText's property values as attributes into the rendered markup and work transparently for both the tool options and the text PDB API. app/text/gimptextlayout.c | 129 ++++++++++++++++++++++++++++++++++---------- 1 files changed, 99 insertions(+), 30 deletions(-)
We desperately need to get 2.8 out, let's look at this for 2.10 instead. In fact, what is the problem right now, in one sentence? The original description has too much text for me to read right now :/
The core is 100% fixed (all legacy options are embedded in the markup now), the only thing left is cleaning up the GUI. I'm moving it back to 2.8, because there are a few minor glitches in the text UI I need to sort out. We can moive it back to 2.10 if it doesn't happen.
Err, I take that back. There is still work to do in this area, like it's totally unclear which unit the text style overlay's size spinbutton is using. Will fix that too.
*** Bug 688002 has been marked as a duplicate of this bug. ***
When just a text layer is selected and the tool is enabled, we see properties (thought not all of them) in the text toolbox. If you just want to quickly change a property, like color or size, it is not enough to set it from the text toolbox but you have to edit the text, select whole the text and apply a color from the on-canvas editor. Most of the time it also works from the text toolbox, without selection, but sometimes I've noticed it doesn't. Being able to change properties without editing the text can be really helpful especially when you have overlapped layers and it's quite easier to select from the layer's list, apply the tool and tweak it with the toolbox options. What are in details the limitations to achieve such functionalities? Thank you
You can only ever change the default properties of the text in the tool options, once you edit the text in the floating style editor, it's set on a text span and overrides the default options. You can select all and then clear the text style to reset to default.
Is there a keyboard shortcut to edit the text in the editor?
In the on-canvas editor? No there are no shortcuts to activate tools, you have to click. In comment 8 I was only describing the current state, not how it should be.
I meant in general. I'd like to select the layer than have a shortcut to enter in edit mode for the text. Right now I've seen it works with the click on the canvas or double click on the layer.
*** Bug 689729 has been marked as a duplicate of this bug. ***
*** Bug 697426 has been marked as a duplicate of this bug. ***
2010??!! really??? and this bug HASN'T been fixed yet??? Gimp devs must not care too much about bugs in Gimp!! I think this is AT LEAST the 4th bug I reported that seems to be a duplicated of a pre 2011 bug!! MOST software developers fix bugs right away but you guys let them sit!!
Moltres_rider: Feel free to fix all the 716 open bug reports in the next days by providing software patches, or 50 volunteer coders. If you cannot, please refrain from adding such untechnical comments in Bugzilla that are unrelated to this specific bug report. Bugzilla is not a webforum.
Moltres_rider: by participating in bugzilla; you have already elevated yourself from being a free-riding user of GIMP to a contributor (note that it is possible to have negative contributions..). You are already among the people you are criticizing; what probably deserves more criticism is wasting peoples time. Like filing bugs without checking if they already exist, or expressing entitlement over how volunteer contributors are spending their time.
*** Bug 704309 has been marked as a duplicate of this bug. ***
*** Bug 720492 has been marked as a duplicate of this bug. ***
*** Bug 732967 has been marked as a duplicate of this bug. ***
*** Bug 753711 has been marked as a duplicate of this bug. ***
This doesn't look like something we're going to fix for 2.8 anymore, does it?
*** Bug 760339 has been marked as a duplicate of this bug. ***
I reported bug 760339, which is now marked DUPLICATE--it's okay, I get it. I next read through the historical details of 631934--its parent bug report. I'm attaching a png (Hello-world-text-interface-button-suggestion.png) suggesting a GUI addition to educate users, and to highlight, and clarify many of the competing issues. If the attachment doesn't show up, it's because I don't understand bugzilla's bug reporting interface. It still needs to be viewed. If it's not visible, help me post it, please. It's complicated, I know. Also, can instructions be added to GIMP HELP explaining how the GUI actually is designed to work between Tool Defaults? That would help both A) the users as well as B) accommodate the devs who are doing the right thing, but of which the users don't have a clue.
Created attachment 318681 [details] Possible text interface indicator treatment for 631934 Clicking at the four points in a text block, see how the radio buttons indicate whether a user is modifying A) the default block settings, or B) the text settings established in a previously existing block. This would educate the user AND explain how the text blocks hidden assumptions add up to its functioning in real time.
Created attachment 328181 [details] [review] quick hack What aboout making the text style editor overlay visible only when there is a selection? I've just watched a screen cast where a user showed its difficulty understanding that the style editor works on the selected text. So why not hiding it until the user select something. Attached a silly quick hack to experiment a bit.
Except that we actually want more on-canvas controls and less tool options.
-- 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/344.