... to reset its position via right-click menu
This commit adds the ability to restore the original position of the
on-canvas text editor after it has been moved, by accessing the option
from the context menu opened with a right-click on the text box.
Once the on-canvas text editor has been moved, its position should be
preserved across editing sessions. This commit stores the editor's
position per text layer and restores it when the layer is activated again.
After the on-canvas text editor has been moved, it should remain fixed
on the screen when zooming or panning the canvas. This commit preserves
the current behavior when the editor is in its original position, and
fixes its position on-screen after it has been moved.
The analogue of Control key on macOS is the Command key, this means that
`GDK_CONTROL_MASK` has not the expected behavior on macOS. This commit
changes the modifier for unformatted paste in text tool from Control to
Primary, which maps to Command on macOS and Control on other platforms.
This patch adds a Paste Unformatted Text item inside the
right-click menu of Text Tool, which allows user to paste
previously copied, possibly formatted (marked) text as plain
text with no markup.
...for toggle bold/italic/underline.
This commit adds support for common formatting shortcuts in the Text Tool:
- Ctrl+B: Toggle bold
- Ctrl+I: Toggle italic
- Ctrl+U: Toggle underline
It's actually not enough to get proper colors for inner text tags. The
main color is correct, but color for subtext is currently not managed.
This must be fixed.
When replacing a selection, take and apply markup (if any)
from the first character of the selection for the entered
text.
This fixes the case when you no longer can change the
global layer text properties after replacing the text.
Also, this changes the behavior introduced in #1220.
Fixes: #7948 (GNOME/Gimp tracker)
After 59cb3e36, the GimpOverlayFrame that contains
the on-canvas text editor is still partially visible as a dot.
This patch now hides and shows that as well based on
the "Show On-Canvas Editor" option.
This adds a new boolean to text options, "Show on-canvas editor".
When toggled, it immediately hides (or re-shows) the current
text layer's on-canvas text editor.
It uses the same signal and function as the "use-editor" property.
Pre-GIMP-3.0 code logics would re-allocate several GimpMenuFactory or
GimpUIManager for no good reason. While it was still working with old GtkAction
code, with our new GAction-based code, we were ending up overriding an action
with a new version of the same action, while keeping reference to old actions.
This made for discrepancies of the enabled or visible state of actions.
The new code keeps singleton of some objects and references to already
registered GimpUIManager or GimpActionGroups objects and make sure no actions
with the same name are created twice.
So it seems that pango_attr_iterator_range() could return G_MAXINT for
a Pango attribute when it is at the end of the preedit string. Looking
at Pango code, I see they initialize the attribute end property to
PANGO_ATTR_INDEX_TO_TEXT_END (G_MAXUINT), later clamped to G_MAXINT by
pango_attr_iterator_range(). So I guess for the specific case where we
are at the text end, it is normal. Only weird thing is that this didn't
happen at all on X11, only in Wayland.
So let's do our own pre-check. Also double the check by adding a UTF-8
validation.
This fixes preedit text not being displayed and the following warning:
> Gtk-CRITICAL **: 12:31:25.118: gtk_text_buffer_emit_insert: assertion 'g_utf8_validate (text, len, NULL)' failed
Even worse, this was potentially an out-of-range reading, though
fortunately checked early enough.
...when overwriting existing text
gimp_text_tool_enter_text(): when replacing a selection, use the text
properties from the text style editor for the entered text, otherwise
the style of the text before the selection will be used.
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06fa1a753fda5b4d46af01698c344154e
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
...selection on the canvas
if the editor dialog is active do not copy to the
clipboard the text selected, copy it instead when
selected with keys <Shift>-left/right.
Whereas some IME would just cancel any preediting on IM context reset,
others would commit their preedit (for instance Ibus-Hangul).
Unfortunately it is not necessarily immediate, even after
gtk_im_context_reset() and gtk_im_context_focus_out(), so when switching
text layer, any preedit text is committed on the new layer.
Let's recreate the IM context on abort to make sure we don't share any
input between text layers.
The IM should be the one taking care of it by sending the proper
signals, and I would assume this should be done when we run:
gtk_im_context_focus_out ().
But it doesn't and leaves a dangling styled preedit text on leaving
a text layer, either because the IME is not properly implemented (not
reacting to the context leaving the focused widget), or GTK+2 is bugged,
or maybe we just don't understand exactly how this all works. Anyway
let's explicitly clean preedit text, not waiting for preedit-end or
commit signals on IM abort.
With left gravity, the mark is moved back 1 character to the left of the
cursor, whereas with right gravity, it is right after newly-inserted
text. This resulted sometimes into non-deleted preedit characters.
I don't understand all the subtleties since the problem only occurred
for the first character of a text layer, at least in my tests.
Anyway now it should be good.
Japanese IME emits the preedit-commit before preedit-end (Hangul or
Unicode don't, but we could assume other IMEs may be doing the same).
As a consequence, the undo step was not pushed, thus breaking undo
history and consistency.
The solution is to simulate preediting end then restart when a commit
happens during preediting.
Commit cd147a4 reintroduced the crash. The culprit was the idle function
gimp_text_tool_apply_idle() which may not have been processed when
gimp_text_tool_move_cursor() is called, resulting in inconsistencies
between the text in the text tool's pango layout and its buffer.
Force any pending text commits to be applied before moving the cursor.
In the text tool editor code, connect to GtkIMContext::preedit-start
and introduce a boolean text_tool->preedit_active which indicates that
a preedit is going on.
Remove the new preedit-removal code from gimp_text_tool_reset_im_context()
because it was not reflecting the IM's internal state and made things
worse. Instead, added gimp_text_tool_abort_im_context() which really
gets rid of any ongoing preedit by force.
In the main text tool code, check for preedit_active and if TRUE,
apply any edits directly widhout pushing undo steps. Factored out
gimp_text_tool_apply_list() for that purpose in order not do
duplicate a lot of code.
On undo and on button_press, force-abort any ongoing preedit. This is
the right thing to do on undo, but not really on button_press, but I
don't see another way to keep states consistent.
The new gimp_text_tool_im_delete_preedit() also makes sure that
text_tool->preedit_string is non-NULL when modifying the buffer,
so it can be used as indication whether or not a preedit is
going on (in order to skip undo stuff while preediting).
In particular, I don't want the preedit foreground colors to be
displayed in the text style editor UI. They are only temporary hints
and should not be taken into account as user-chosen style.
When gtk_im_context_get_preedit_string(), we have to inspect the
returned Pango attributes, so that the preedit string can be displayed
in the expected fashion (i.e. as in other programs).
Some input methods in particular would even break the preedit strings
in several chunks of text displayed differently (for instance Japanese),
depending on the cursor position within the preedit string.
... and improve input method UI. IM should not use some floating overlay
frame to display the preedit text. Instead it is now directly inserted
into the text tool box, as selected text. It permits redimensionning of
the text box while typing, and push the rest of the text when inserting
in the middle (instead of superimposing an overlay box over the current
text box, making everything unreadable).
Input methods still have a few more issues, but this fixes the main UI
weirdness as well as the crash with Hangul IM.
There is now a preference option that determines whether windows
should be opened on the same monitor as before. It should be disabled
when the machine gets monitors plugged/unplugged dynamically ("laptop")
and enabled when there is a static multi-monitor setup ("wokstation").
This is merely the current simplistic policy on top of the newly added
underlying infrastructure:
- pass integer monitor numbers around in all places where we already
pass around a GdkScreen. Pass the "current" monitor to these changed
APIs, where "current" is either the monitor where the action-triggering
widget is, or if that is unavailable the monitor where the mouse is.
- add gimp_widget_get_monitor() in order to easily get to the monitor,
just like gtk_widget_get_screen().
- add screen and monitor parameters in some places that were missed
before.
- in sessionrc, save all window positions relative to the window's
monitor, and save the monitor separately, if it's not the screen's
primary monitor.
- when restoring window positions, use the stored monitor when the new
prefs options says so (use the screen's primary monitor if there is
no stored monitor), otherwise use current monitor that is now passed
around.
when it was in the floating text style editor. While this doesn't fix
anything by itself, it enables fixing text style setting to behave
reasonably when there is no selection.
Check for pango_layout_move_cursor_visually() returning a new index of
G_MAXINT, which indicates that we moved beyond the end of the layout,
and do nothing instead of trying to access the memory there.
One possible way to decrease the incompatibilities
between letter spacing in a tagged gtk_text_buffer
and in an equivalent pango_layout
Remove also a valgrind reported invalid write in
gimptextbuffer.c
