Changelogs

Overview

These changelogs reflect the history of all files in the Subversion repository. The changelog has been generated at 2016-05-09 08:38:04

Changes per page:

25 50 100 250 500 1000 2000

Changelog for wxWidgets (70435 changes):

2013-12-07 16:50 JS, revision 75360

Clicking on a floating (non-container) object no longer sets the caret position. Double-clicking on a floating (non-container) object selects it instead of selecting a word. Selection refresh now takes floating objects into account. The last line of a paragraph now takes floating objects into account.

2013-12-07 16:12 JS, revision 75359

Backported r75354: Fix layout of content within a floating object by using Move and not SetPosition; prevent creeping of floating objects on layout.

2013-12-07 13:30 VZ, revision 75358

Don't build wxOSX/Cocoa twice in wxOSX buildbot. Both trunk builds were using Cocoa, change the one supposed to be Carbon to use Carbon instead. Also add Carbon stable branch build as this is probably even more important than testing Carbon in the trunk.

2013-12-07 12:59 VZ, revision 75357

Clarify wxGetTopLevelParent() behaviour for TLWs. It doesn't return the parent of a TLW but TLW itself. Whether this is a good idea or bad one, this is how it works since a very long time and we don't want to change it any more.

2013-12-07 12:55 VZ, revision 75356

Big Galician translation update from Nuria Andión.

2013-12-07 12:55 VZ, revision 75355

Big Galician translation update from Nuria Andión.

2013-12-05 20:56 JS, revision 75354

Fix layout of content within a floating object by using Move and not SetPosition; prevent creeping of floating objects on layout.

2013-12-05 20:16 SC, revision 75353

backporting SDK 10.5

2013-12-05 10:13 SC, revision 75352

support 10.5 SDK build

2013-12-04 15:33 VS, revision 75351

wxOSX Retina fixes: wxImageList::GetSize(). wxImageList returns size of its bitmap as pixel size, i.e. twice the displayed screen on HiDPI screens. Unfortunately, wxImageList::GetSize() is used heavily in (generic) GUI drawing code, e.g. to properly size wxListCtrl's icon columns. As wxImageList is used primarily by controls, it seems reasonable to adjust for scaling here, rather than requiring all users of the class to do it.

2013-12-04 15:33 VS, revision 75350

wxOSX Retina fixes: size wxStaticBitmap and wxBitmapButton properly. The size is expressed in logical coordinates and needs to use bitmap's scaled size, otherwise it would appear twice as large in both dimensions.

2013-12-04 15:32 VS, revision 75349

wxOSX Retina fixes: wxImageList::GetSize(). wxImageList returns size of its bitmap as pixel size, i.e. twice the displayed screen on HiDPI screens. Unfortunately, wxImageList::GetSize() is used heavily in (generic) GUI drawing code, e.g. to properly size wxListCtrl's icon columns. As wxImageList is used primarily by controls, it seems reasonable to adjust for scaling here, rather than requiring all users of the class to do it.

2013-12-04 15:32 VS, revision 75348

wxOSX Retina fixes: size wxStaticBitmap and wxBitmapButton properly. The size is expressed in logical coordinates and needs to use bitmap's scaled size, otherwise it would appear twice as large in both dimensions.

2013-12-04 14:23 VS, revision 75347

Auto grow the last wxDataViewCtrl column on all platforms. The GTK+ implementation always did this and it doesn't make much sense to let the space be wasted, so do as GTK+ does: expand the last column to cover the remaining unused space in the OS X and generic implementations too. Don't do anything if the space is insufficient. Respect the last column's minimal width. See #13904.

2013-12-04 13:38 VS, revision 75346

Fix fixed-width progress columns in generic wxDataViewCtrl. Both native wxDVC implementations grow the progress column, the generic one didn't. This change fixes it and _seems_ not to break other things. As a consequence, progress columns no longer have a 40px minimal width, but that should be OK. Fixes #15745.

2013-12-04 13:36 VS, revision 75345

Fix fixed-width progress columns in generic wxDataViewCtrl. Both native wxDVC implementations grow the progress column, the generic one didn't. This change fixes it and _seems_ not to break other things. As a consequence, progress columns no longer have a 40px minimal width, but that should be OK. Fixes #15745.

2013-12-03 19:41 JS, revision 75344

Applied patch #15744: wxRichTextCtrl: HitTest can't find top-level floats (dghart)

2013-12-03 19:41 JS, revision 75343

Applied patch #15744: wxRichTextCtrl: HitTest can't find top-level floats (dghart)

2013-12-03 15:53 VZ, revision 75342

Fix crash when Destroy()-ing a TLW with a non-TLW parent. Generalize the code in wxTopLevelWindowBase dtor checking for the children of the TLW being destroyed pending for deletion themselves to work when the child TLW is an indirect child, i.e. was created with a child window of this TLW as parent and not this TLW itself. Closes #15743.

2013-12-03 15:53 VZ, revision 75341

Fix crash when Destroy()-ing a TLW with a non-TLW parent. Generalize the code in wxTopLevelWindowBase dtor checking for the children of the TLW being destroyed pending for deletion themselves to work when the child TLW is an indirect child, i.e. was created with a child window of this TLW as parent and not this TLW itself. Closes #15743.

2013-12-03 14:38 VZ, revision 75340

Work around wrong vsscanf() declaration under HP-UX. Under this system vsscanf() is declared as taking a non-const char* as first argument which prevented our code using it from compiling. Wrap it in wxCRT_VsscanfA() adding the necessary const_cast<> to fix this. Closes #15638.

2013-12-03 14:36 VZ, revision 75339

Work around wrong vsscanf() declaration under HP-UX. Under this system vsscanf() is declared as taking a non-const char* as first argument which prevented our code using it from compiling. Wrap it in wxCRT_VsscanfA() adding the necessary const_cast<> to fix this. Closes #15638.

2013-12-02 18:46 VS, revision 75336

Minor clarifications to wxTextEntry::SetHint() docs. Update platforms support docs. Mention event handlers interaction in the generic implementation.

2013-12-02 18:46 VS, revision 75335

Implement wxTextEntry::SetHint() natively for GTK+3.

2013-12-02 18:46 VS, revision 75334

Don't use native cue banners in wxTextEntry::SetHint() on XP. The code apparently expected EM_SETCUEBANNER to return false on pre-Vista systems (where the cue banners don't work). This isn't the case in practice, so check for Vista explicitly and use the generic implementation on XP.