There seems to be something wrong with the vertical offset returned by
gtk_entry_get_layout_offsets() in GTK 3, so just don't use it at all, as
we don't need it anyhow.
For consistency with the other platforms, coalesce multiple wxEVT_TEXT
events resulting from a single user action into a single one in wxGTK
too. For example, when pressing a key in a control with some text
selected, wxGTK previously generated 2 wxEVT_TEXT events: one
corresponding to the removal of the selection and another one to the
addition of the new text. Now only a single event with the new text is
generated, as in the other ports.
Doing this requires delaying sending wxEVT_TEXT until GTK itself ends
handling the key press, however we delay it as little as possible, so
hopefully this shouldn't have any visible effects at wx API level.
Closes#10050.
And reuse EnableTextChangedEvents() between these classes as well.
No real changes so far, this is just a refactoring to centralize the
code in a single place before modifying it.
Check whether we should ignore the event and mark the control as being
dirty if necessary in a virtual method, which can be defined in
wxTextEntry and overridden by wxTextCtrl, instead of doing it in GTK
callback itself.
This will allow to reuse wxTextEntry callback for wxTextCtrl too in the
upcoming commits.
No real changes so far.
This is slightly simpler, as it doesn't require checking whether the
control state really changes or not (it always does if DoEnable() is
called) and allows disabling the controls before creating them, e.g.
code like
wxButton* const b = new wxButton();
b->Disable();
b->Create(this, wxID_OK);
works as expected now instead of spewing GTK+ errors.
Add wx/gtk/private/wrapgtk.h wrapping gtk/gtk.h in pragmas disabling
these warnings and include it everywhere instead of directly including
gtk/gtk.h.
Also include wx/gtk/private/gtk2-compat.h from this wrapper header as it
was included by 90% of the files including gtk/gtk.h itself and it seems
to be better and simpler to just always include it.
TAB should be used for navigation by default and only should be inserted
into the control as a literal character if wxTE_PROCESS_TAB is specified
for consistency with wxMSW and because this behaviour is much more
useful by default.
Fix this by calling gtk_text_view_set_accepts_tab() as appropriate for
multiline text controls. For single line ones, the behaviour is
unchanged but it's more reasonable as TAB is always handled as if
wxTE_PROCESS_TAB were not specified and it doesn't seem really useful to
try to support wxTE_PROCESS_TAB for them anyhow, so just document this
limitation.
Also remove the outdated/misleading documentation of this style, notably
don't say that it is required to get char events for TAB presses as
these events are generated both with and without this style in both
wxGTK and wxMSW.
Closes https://github.com/wxWidgets/wxWidgets/pull/704
Use wx_is_at_least_gtk2(minor) instead of gtk_check_version(2, minor)
because it is more clear and also works as expected (i.e. returns true)
when using GTK+ 3 instead of creating difficult to notice bugs in the
code by failing the version check in this case.
See #18004.
So wxNO_BORDER works with other controls, such as wxBitmapButton.
Also use GTK prefix on ApplyCssStyle(), and add an overload that
creates the GtkCssProvider.
The text and background colours are now stored in the rgba array instead
of fg_color and bg_color as with GTK+ 2 (the latter ones seem to have
been repurposed for the underline and strike-through colours!).
Also make the unit test for this method more robust.
Change this method to consider the coordinates corresponding to the last
position (i.e. the one beyond the last text character) as valid, for
consistency with wxMSW and to conform to the documented behaviour.
Also give more information about the failures in the corresponding unit
test to make debugging problems with this function simpler.
This is similar to e74fb5effe for wxMSW
and ensures that we don't consider the last position on the first line
invalid in wxGTK neither.
This fixes TextCtrlTestCase::XYToPositionSingleLine() unit test failure.
This was broken by 1c946a469a and resulted
in test failures in OwnerDrawnComboBoxTestCase::TextChangeEvents() unit
test because wxOwnerDrawnComboBox::Clear() used SetValue("") and didn't
generate any events any more.
Fix this regression by explicitly sending an event if we're returning
early and add a unit test explicitly checking that SetValue("") does
generate an event.
Use wxScopedCharBuffer as we only need the buffer in the current scope.
This avoids a buffer copy done by wxCharBuffer which could be a
significant pessimization for large buffers.
Also don't call strlen() unnecessarily, we already know the buffer
length, so just use it.
This method seems completely unnecessary, the base
wxTextEntry::DoSetValue(), which delegates to Remove() and WriteText(),
seems to work just as well and avoids code duplication between this
method and wxTextCtrl::WriteText().
Notice that gtk_text_buffer_set_text() is just a trivial wrapper around
gtk_text_buffer_delete() and gtk_text_buffer_insert() anyhow, so there
is no efficiency loss in not using it neither.
This could happen if the code calling SetValue() was in a handler
invoked in response to a keyboard action as our insert-text signal
handler believed that it was called in response to this key in this
case, even when it wasn't the case.
This extends the changes of def8247c61
to WriteText() to DoSetValue(), thus fixing the same problem in
SetValue() and ChangeValue() too.
But the question of why do we have two so similar, yet different,
functions, resulting in having to fix the same bugs twice still remains
unanswered...
Several functions of wxTextEntry and wxTextCtrl call to
gtk_entry_get_text_length() API to determine the length of the text in
GTKEntry. This API is available since GTK+ 2.14 so we have to implement
a fallback method for older GTK+ versions.
Dedicated function GTKGetEntryTextLength() is implemented in wxTextEntry
and exposed through its interface because it is also used in wxTextCtrl.
This overrides the default minimum size of 150+ pixels, avoiding swarms of
GTK3 debug warnings about "attempt to underallocate wxPizza's child GtkEntry"
Apply the appropriate style to any text being inserted, not just the text
added by the program. This not only fixes the bug with default style not being
used for the text entered by user, but also makes the code simpler.
Closes#17523.
Implement Freeze() by blocking the GtkWindow "expose-event"/"draw" signal
instead. Since the introduction of client-side windows in GTK+ 2.18,
gdk_window_freeze_updates() is unuseable because the impl_window (and thus the
update_freeze_count) for a given GdkWindow can change unpredictably. See #16795
Don't prevent people from using hints in wxMSW and wxGTK2, where they work
with multiline text controls too, even though they do not work with wxGTK3 nor
wxOSX.
Closes#14456.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78316 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
