This operation produces NAN (0 / 0) and division
by zero when a layer component is zero.
Inline CLAMP to make sure it swallows also NAN.
A NAN is mapped to 1 for backward compatibility.
[the 2variate function comp (in[b], layer[b]) is
discontinuous at layer[b] = 0]
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.
Honor them in gimp_widget_get_color_transform() and make them
configurable in prefs. The code and GUI avoid the negation in
the lcms "NOOPTIMIZE" flag.
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.
Since commit b593462, gimp_text_tool_apply() is a semi-public function
(only to be used from gimptexttool-editor.c). Therefore move it to the
"public functions" section.
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.
to gimp_color_config_get_simulation_color_profile(), along with
various internal "printer" strings. Also reduce the number of
user-visible "print" stuff from the preferences color management page.
Use cmsFLAGS_NOOPTIMIZE only for actual image buffer or single color
transforms, but not for previews or the image display. Makes things a
lot more responsive again.
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).
Rather than just discovering them by chance, a simple grep and some
search and replace are much more efficient! :-)
Cleaning only done on C and automake files.
and update their color transforms with the new monitor's color
profile. A widget is considered changing monitors when its toplevel
window's center crosses, in order to let widgets within one window
have consistent colors.
Which installs a callback that behaves as if GtkWidget had a
"monitor-changed" signal. Additionally, moving widgets around between
windows is handled automatically.
Dimitris Spingos