At least one WM (KDE's KWin) does not generate X11 configure events when dragging
a window using gtk_window_begin_move_drag(). We need the configure events so we
can generate wxMoveEvent, which AUI needs in order to re-attach a floating pane.
This is functionally a revert of b8789b9d6f for backends other than Wayland.
See #18372#18669
Instead of checking for all text-like controls one by one in
wxCommandEvent::GetString(), call a virtual function checking for this.
This is simpler, less error-prone and faster -- at the cost of
increasing the vtbl size of all wxWindow-derived classes.
Closes https://github.com/wxWidgets/wxWidgets/pull/1696
It defaults to 1, but can be set to 0 to force using the generic version
of the control even under GTK or Mac, where the native version is used
by default.
This can, unfortunately, be useful to work around various but multiple
native control limitations.
This makes more sense for a page of a GtkNotebook, which is always
positioned at (0, 0) relative to its client area, and is also more
compatible with wxMSW.
Closes#18548.
Closes https://github.com/wxWidgets/wxWidgets/pull/1670
This method of wxGtkStyleContext uses a GTK function only available
since 3.20, and so can't be implemented for the earlier versions, hence
don't even define it in this case.
Note that the caller still needs to test for the run-time version.
Ensure that the entry is always (just) big enough to show any value
valid in this spin control.
This also ensures that GetBestSize() doesn't need to be overridden to
use GetSizeFromTextSize() any longer as the best size will be determined
correctly by GTK itself.
For GTK2, get the "inner border" the same way GTK does it. And for GTK3,
provide an actual implementation. Also, don't return a wxPoint for a size.
See #18567
This is not really an option as building requires it to be 1, so don't
make it one in setup.h/configure/cmake and just hardcode it as 1 for
compatibility.
Closes#18558.
This is always 0 for any still supported compiler, so remove the option
and configure checks for it.
Still define it as 0 for compatibility, just in case it's used outside
of the library.
Under wxGTK+2 bitmap data with mask and without it (raw) should be stored
in the separate GdkPixbuf buffers - just like it's done in wxGTK+3. These
two buffers are necessary because only GdkPixbuf with raw bitmap data
(original, non-masked) should be copied when wxBitmapRefData instance is
cloned e.g. in SetMask(). GdkPixbuf with masked data is not copied and is
created on first use in wxBitmap::GetPixbuf().
Closes#18508.
See #18498.
It's generally wxWidgets policy not to include platform-specific headers from our own
to avoid namespace pollution issues, in this case with names like "None" and "Window".
This parameter is not modified by wxColourDialog (this might have been
the case, or at least the plan, some long time ago) and so has no reason
not to be "const".
Just add the qualifier to ctor and Create() in all ports.
Closes https://github.com/wxWidgets/wxWidgets/pull/1421Closes#12511.
Don't lose window position when the window is iconized, as this prevents
it from being correctly saved by wxPersitentTLW, for example, resulting
in failures in the corresponding unit test.
Unfortunately there doesn't seem to be any simple way to just ignore the
bogus (0, 0) configure events that we get from GTK when the window is
iconized, as explained in the comment, so we're reduced to remembering
the last position and restoring it when we realize that the window got
minimized and not moved, after all. This is obviously not ideal, as
there is still a lapse of time when (0, 0) is returned, but there just
doesn't seem to be anything better to do.
Add default ctor for this struct as it was too easy to forget to
initialize it otherwise, ending up with bogus values in it, as it
happened with wxTLWGeometry::m_decorSize, which resulted in a failure in
wxPersistTLW unit test and, probably, real code too.
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.
There was confusing with the method GTKIMFilterKeypress() in wxGTK
wxTextEntry: it was called the same as wxWindow virtual method of the
same name, but didn't override it, of course, as wxTextEntry doesn't
derive from wxWindow.
It also wasn't called for wxComboBox which inherited from wxTextEntry
but didn't override wxWindow::GTKIMFilterKeypress() to actually call its
method.
Fix this and rename the wxTextEntry to use a different name for clarity.
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.
Tick marks were not available for wxSlider under GTK+ 2 or GTK+ 3
implementations of wxWidgets. However, tick marks have been available
for the GtkScale widget since GTK+ 2 version 2.16.
This change adds similar functionality in relation to tick marks
as was already available in wxMSW builds.
Closes https://github.com/wxWidgets/wxWidgets/pull/1355
Under wxGTK, wxGauge was returning fixed values for height and width.
This meant that the gauge would not center correctly in a sizer,
particularly under GTK+ 3 where the default gauge height is just a few
pixels.
Following this change, wxGauge renders correctly on GTK+ 3 and matches
the reference widget display in the gtk3-widget-factory app.
Note, this change will also result in a slimmer widget on GTK+ 2, but
the gauge height can be forced using wxGauge::SetMinSize() on the older
toolkit.
The gauge presentation is totally theme dependent under GTK+ 3. For
example, the user can have thicker gauges by setting the following in
their ~/.config/gtk-3.0/gtk.css file:
progress, trough {
min-height: 20px;
}
Closes https://github.com/wxWidgets/wxWidgets/pull/1353
The names of these methods were confusing because they implied that they
were the actual implementations of the public [SG]etLabel(), while this
wasn't at all the case.
Give them then ames describing what they really do and also update the
comments to hopefully be more clear.
No real changes.
