Use pango_font_description_copy() to copy fonts instead of
pango_font_description_to_string() and pango_font_description_from_string()
via wxNativeFontInfo::{To,From}String() respectively.
This is not only more efficient but also preserves the original family whereas
wxNativeFontInfo::FromString() helpfully replaces any fonts it doesn't know
about with the normal font name. That behaviour is probably wrong on its own,
but for now at least avoid silently changing fonts when copying them.
Don't interpret them relatively to the current path, so that an URL like
"/pictures/foo.png" in the file "/webpages/bar.html" is resolved correctly and
not as "/webpages/pictures/foo.png" as it was previously.
See #17148.
Dragging the mouse (even accidentally by a pixel or two) resulted in a
confusing "Unknown event" line in the log, so don't log these messages neither
just as we already don't log the mouse motion events.
On wxGTK, wxFileDataObject::SetData calls g_filename_from_uri which
percent-decodes URIs. No corresponding percent-encoding was done in
wxFileDataObject::GetDataSize/GetDataHere. Use g_filename_to_uri instead in so
that filenames are properly escaped.
This commit also fixes the data being truncated if it contains non-ASCII
characters on wide-character builds, see the memcpy arguments in the original
code.
Sibling windows (like labels and radio buttons) need to be explicitly
refreshed when foreground or background colour is changed. This is implemented
by invoking newly implemented method wxSubwindows::Refresh every time the
colour of the control is changed.
Note: Setting foreground colour of wxRadioBox still doesn't work correctly
when themes are enabled.
Closes#17142.
When using Whole Program Optimization, pItem->OnDrawItem() incorrectly calls the
base class wxOwnerDrawn::OnDrawItem() instead of the appropriate override, for
example wxCheckListBoxItem::OnDrawItem(). The problem can be avoided by not
using an unnecessary cast to wxListBoxItem*.
Make scrolling upwards (positive delta) go to the past (i.e. decrease the
date) for consistency with the native calendar controls.
See 50daf1feab (commitcomment-13087042)
Mimics the scrolling behaviour of native MSW and GTK calendars by allowing to
increment/decrement the month by scrolling anywhere on the generic calendar.
Additionally, use horizontal scrolling to increment/decrement the year.
Closes https://github.com/wxWidgets/wxWidgets/pull/88
Allow to disable maximize and minimize buttons dynamically just as we already
allow to disable the "Close" button using EnableCloseButton().
Currently implemented for MSW and OSX only.
Closes#17133.
Unexpectedly, minimizing the window by clicking on its taskbar icon resulted
in a wxActivateEvent. This broke the focus handling in wxTLW and resulted in
debug messages about ::SetFocus() failure whenever the window was minimized in
this way.
It also seems that other existing code doesn't take into account the
possibility of getting an "active" activation event when the window is
minimized and this doesn't happen in the other ports, so don't send this event
in wxMSW neither.
Closes#17128.
Deleting a tool from its own event handler resulted in at least in an assert
and could also lead to a crash as an already deallocated pointer was
dereferenced.
Fix this by checking if the tool with the same ID is still available after the
event handler finishes.
See #16762.
Added messages to show that Copy tool intentionally influences Print tool and
Cut tool influences Help tool, as this is rather unexpected behaviour and
could be seen as a bug.
This ensures that the messages always appear in the correct order, even if the
user clicked somewhere in the middle of the control -- which would previously
result in inserting the next message at the cursor position, not the end.
Ensure that the count of the Print tools is always correct, even if more tools
were inserted and then the toolbar was recreated (in a different position).
On OS X (tested on 10.10.5) calls to window.open() with a different target
than _self were simply ignored. No navigation and no EVT_WEBVIEW_NEWWINDOW as
expected.
Unfortunately WebKit does not call the decidePolicyForNewWindowAction delegate
method in these cases. A new delegate method createWebViewWithRequest has been
implemented to handle this case and send EVT_WEBVIEW_NEWWINDOW as in other
ports.
Closes https://github.com/wxWidgets/wxWidgets/pull/85
wxOSX and wxGTK previously used their own methods for handling the enabled
state and the attributes of the items being rendered, change them to reuse the
same methods as the generic implementation, i.e. SetEnabled() and SetAttr()
and remove the port-specific GtkSetAttr(), OSXApplyAttr() and so on.
This has the advantage of ensuring that the logic is the same for all
platforms (e.g. item enabled status wasn't handled in the same way in wxGTK as
in the other ports previously) and hopefully makes the code simpler by cutting
down on the number of virtual methods.
Notice that GtkSupportsAttrs() optimization was removed as it didn't seem to
be worth the bother (we basically saved a call to a virtual model method at a
price of a virtual renderer method call) and preserving it would have
complicated things needlessly.
There were many problems if some options selecting the build of wxWidgets to
use were not specified at all, i.e. if the corresponding string was not used
in WX_STANDARD_OPTIONS() argument or if WX_STANDARD_OPTIONS() was not used at
all (which is perfectly possible and allowed).
In this case, the output of WX_STANDARD_OPTIONS_SUMMARY_MSG() was corrupted
(e.g. it could output "WX_DEBUG is" without any value and "PORT:" value was
empty) and, worse, as that macro is only cosmetic, WX_LIKE_LIBNAME() didn't
work correctly neither, making it difficult to check for the libraries using
it to construct their name (as many libraries from wxCode do).
Get rid of all these problems by simply treating empty/undefined variables as
meaning "auto detect" instead of having to set them to the special "auto"
value first. This makes sense as now we have just 3 states: 0, 1 or null,
instead of previous 4 (+ "auto") and is much more robust.
The code set WX_PORT to $TOOLKIT only if the latter was empty which made no
sense and also set WX_PORT to the never used nor documented anywhere else
$PORT if $TOOLKIT was not empty which made even less of it.
Just assign $TOOLKIT to WX_PORT if the former has a valid value.
Remove the never used 4th and 5th arguments of _WX_SELECTEDCONFIG_CHECKFOR
macro.
Also update the comment to better explain what does the macro actually do: it
doesn't "output the message" but rather sets a variable, with the message
being an optional side effect.
Because on some ports native renderers require a valid reference to the windows be drawn then it is necessary to implement and use new wxPGCellRenderer::DrawCaptionSelectionRect method which passes this additional argument.
Move the checks for the type mismatch between the type of the value returned
by wxDataViewModel and the type expected by wxDataViewRenderer into common
code. This avoids duplicating the same code in wxGTK and wxOSX and, more
importantly, means that this check is also performed in wxMSW when using the
generic version, so that the problems such as the one fixed in 3ff8c3c ("add
missing wxDataViewDateRenderer::GetDefaultType()") would be visible there too.
When specific colours are turned on then custom colours are assigned to both category properties and their sub-properties. But when specific colours are turned off then only category properties are reverted to default colours what is misleading.
Now, all properties are reverted to default colours.
