Width and height were exchanged in the loops, so the conversion code didn't
work correctly and overflowed the pixel buffer (due to extra padding in the
row stride) for non-square bitmaps. It also resulted in a completely wrong
bitmap appearance, but somehow this managed to go unnoticed, unlike the memory
errors.
Closes#17633.
Apparently this can happen when a directory is deleted just before the watch
is removed and it is impossible to avoid it, so just send a warning message so
that the program could react to this, if necessary, but don't annoy the user
with an error in this case.
See #17122.
Native ID2D1RenderTarget::SaveDrawingState method stores in ID2D1DrawingStateBlock only transform, antialiasing mode, text-rendering options and tags but not currently set ID2D1Layers (which are used in wxD2DContext for clipping purposes). Therefore current stack of layers has to be stored "manually" alongside ID2D1DrawingStateBlock in a dedicated data structure (LayerData) in PushState() and restored also "manually" in PopState().
Closes#17626.
This wasn't documented anywhere until now, so copy the contents of the table
in src/common/accelcmn.cpp to the documentation to have them all in one place.
Use pango_font_description_copy() to make a lossless copy of the original font
instead of doing it using wxWidgets API which is less direct and, in addition,
currently is completely broken as SetXXX() methods don't create the Pango font
description if it doesn't exist as they ought to.
Closes https://github.com/wxWidgets/wxWidgets/pull/312
Solution with full conversion from device to logical coordinates in wxGCDCImpl::DoSetDeviceClippingRegion doesn't seem to work under WXOSX (wxMacCoreGraphics) so we have to use for this port legacy implementation without full conversion of coordinates. Only offset of the origin is taken into account in this case (but not e.g. scale) but this should be enough for simple cases.
Closes#17609
1. Under GTK+ 3 wxDC is implemented as wxGCDC (with underlying Cairo renderer) and hence there is no need to test wxDC individually.
2. wxRegion is implemented under GTK+ 2 using GdkRegion but under GTK+ 3 it is implemented using cairo_region_t so some region attributes can be slightly different in some circumstances for both ports. This happens e.g. for non-rectangular regions which can have slightly different clip extents for GTK+ 2 and 3. We have to take this into account in the tests of non-rectangular clipping region and accept that actual clipping box position can differ of few pixels from expected position (so comparing clipping box positions shouldn't be exact but with some error tolerance).
If transformation matrix of wxGraphicsContext with Direct2D renderer is e.g. rotated then rectangular clipping region represented by layer created with ID2D1RenderTarget::PushAxisAlignedClip is invalid because this kind of layers create axis-aligned clipping regions which edges are always horizontal or vertical (not e.g. rotated).
To take into account current transformation matrix when clipping region is set there is necessary to represent all clipping regions (even rectangular) by generic layers (ID2D1Layer) created with ID2D1RenderTarget::CreateLayer.
Closes#17622
This skeleton of documentation was replaced by (minimal but still more
valuable) real documentation in fcd5284aed but
the old classes were accidentally left in.
In a wxFontEnumerator, if false is returned from OnFacename() or
OnFontEncoding(), the enumeration is supposed to stop. This was not happening
on wxGTK.
Closes https://github.com/wxWidgets/wxWidgets/pull/311
Send this event to the toolbar own event handler instead of sending it to the
parent, the event will be propagated upwards anyhow, but doing it like this
also allows to process it in the toolbar itself and is consistent with the
other events generated in this code.
Closes#17613.
If wxExecute() is called without the wxEXEC_NODISABLE flag, it disables
all toplevel windows and then creates a helper dummy window. This moves
focus to the helper window and when it's destroyed, back to the first(?)
of the re-enabled application windows, thus loosing original focus.
Remember previously focused window instead and try to restore focus to
it. This still results in some flicker, but is better than completely
changing focus and e.g. even changing the currently active window
without user's input.
Currently region given in device coordinates is decomposed into the stripes which are next transformed to the logical coordinates required by underlying wxGraphicsContext::Clip() function. Some of these stripes given in device coordinates can have 1-pixel height what after transformation to logical coordinates can give zero-height stripes (after rounding). This can lead to the situation that in the region transformed to logical coordinates some stripes can disappear and final transformed region shape is different from the source shape (it has gaps).
To fix this issue device coordinates of the region are not manually transformed to the logical coordinates but instead wxGraphicsContext's is temporarily set to the state where its logical coordinates are equivalent to device coordinates and thus clipping region can be applied directly.
Closes#17609
Although "base" is not actually a toolkit, allow both the automatic toolkit
detection and the configure flag --with-toolkit=base find and use a base-only
library.
Closes https://github.com/wxWidgets/wxWidgets/pull/310
The transient top-level window might have been already deleted by the time the
idle callback is executed, so check that the widget still exists before using
it.
This fixes multiple GTK+ errors on startup of an application showing any kind
of temporary windows (e.g. a splash screen) since the changes of the commit
bc4df78421.
Added section to group similar functions in the documentation of wxGraphicsContext.
Fixed references to the section describing wxPGProperty attributes.
When wxImage is rescaled with wxIMAGE_QUALITY_BILINEAR, wxIMAGE_QUALITY_BICUBIC or wxIMAGE_QUALITY_BOX_AVERAGE algorithm then for proper interpolation there is necessary to uniformly (linearly) map entire pixel range in the new image to the entire pixel range in the current image, i.e. pixels positions (integer values) in range [0..newDim-1] has to be mapped to "virtual" pixel positions (not necessary integer values) exactly in the range [0..oldDim-1].
[0..oldDim-1] range of target mapping is required because for proper interpolation every "virtual" pixel has to be located between two physical pixels in the current image.
Thus scaling ratio used to find corresponding pixels in the current image should be (oldDim-1)/(newDim-1) and not oldDim/newDim (which is used now).
When image is e.g. upsampled oldDim/newDim ratio then some new rightmost/botommost pixels are mapped to old pixels > (oldDim-1) and their values are improperly interpolated (in the current implementation their positions are just truncated to (oldDim-1) to bypass the problem and upsampled image looks like it was shifted left/up). The larger scaling ratio the effect is more visible.
Note:
Because reference images used currently in the unit tests were created with improper scaling there is necessary to upload new reference images created with fixed scaling.
Closes#17594
When entered wxFloatProperty, wxIntProperty or wxUIntProperty is out of range then there is displayed a warning message presenting a valid range. Instead of displaying in this message numeric values in default (and fixed) format we should display values which are formatted based on to the current attributes of the property (like wxPG_UINT_PREFIX, wxPG_UINT_BASE, wxPG_FLOAT_PRECISION).
To do so, we shouldn't format respective values on our own in NumericValidation() but instead call wxPGProperty()::ValueToString() which returns value string formatted in line with attributes.
Closes#17601
In the edit mode property's value should be displayed in the pure numeric form without any textual prefixes because all non-numeric characters will raise a warning in wxNumericPropertyValidator.
Some coordinates of clipping regions given in device coordinates has to be slightly modified to avoid rounding errors in conversions from device to logical coordinates.
While setting a clipping region there is necessary to intersect it either with current clipping region location if such region exists or with wxDC surface extents if no clipping region is set. This way effective clipping box will be always inside the wxDC surface. Effective clipping box can be an empty region.
Clipping box parameters are calculated and stored in logical coordinates.
For compatibility with wxGCDC (Cairo and all native MSW renderers) current clipping region shouldn't be explicitly destroyed if empty clipping region is requested. It should be handled as any other region.
Rectangular clipping region with negative size is accepted by wxDC::SetClippingRegion() (for compatibility with wxGCDC and Cairo) but for internal calculations we need to have this box defined by (x,y) at top-left corner and having non-negative size so we need to recalculate box's parameters in wxWindowDCImpl::DoSetClippingRegion() if necessary.
GdkRectangle used to represent a rectangle region should have (x,y) parameters pointing to the top-left corner of the box with non-negative width and height so if a rectangle with negative values of the width or height is passed to wxRegion::InitRect() (what means that (x,y) doesn't represent top-left corner) we need to recalculate passed parameters to get rectangle with (x,y) at the top-left corner.
