Add wxToolBarBase::DoSetToolBitmapSize() which does everything that
SetToolBitmapSize() used to do and make SetToolBitmapSize() itself also
remember the size passed to it in a new field, so that we could check
that we don't decrease the bitmap size below the size requested by the
application, while still being able to decrease it if necessary due to a
DPI change.
This allows SetToolBitmapSize() to continue working as before, i.e.
scale the bitmaps up if necessary without ever scaling them down, but
also allows them to resize in both directions when DPI changes.
Closes#22105.
It didn't do anything since wxBitmapBundle-related changes, as could be
seen by toggling the bitmap size in the toolbar sample -- the bitmaps
size didn't actually change.
Make it work again by only using the best bitmap size if it's greater
than the currently set bitmap size, but not shrinking the bitmaps to it
if it's smaller. This doesn't seem especially useful, but this is how
the code behaved with single bitmaps before and there doesn't seem to be
any good reason to change this.
At least document that calling SetToolBitmapSize() is unnecessary and
normally shouldn't be done.
Move the code for determining the size preferred by a bunch of bitmap
bundles from wxToolBar to wxBitmapBundle itself to allow reusing it from
other classes.
No real changes, this is just a refactoring.
This commit is best viewed with --color-moved git option.
This avoids resizing the bitmaps in some common use cases and is similar
to the previous commit doing the same thing for wxButton.
Notice that this introduces a slight change of behaviour, as
AdjustToolBitmapSize() now can reduce, as well as increase, the size of
bitmaps used, which is necessary in order to shrink the bitmaps when
moving from a higher DPI resolution display to a lower-resolution one.
This is not 100% backwards-compatible, but should only have not very bad
cosmetic effects.
This first version provides only a generic implementation of
wxBitmapBundle using a collection of bitmaps and only supports using it
in wxToolBar in wxMSW and wxGTK.
More methods of creating wxBitmapBundle will be provided later and more
functions taking wxBitmap will be changed to take wxBitmapBundle later
too and, of course, all the other ports will be updated to use the new
API too.
Display "long help" text associated with the toolbar items in the status
bar of the parent frame even if the toolbar is not a direct child of the
frame.
Closes#17897.
wxOSX's wxToolBar code uses toolbar size computed by
AdjustToolBitmapSize() to determine which of the builtin toolbar sizes
to use. Because AdjustToolBitmapSize() returned 2x the "logical" size,
it would always pick NSToolbarSizeModeRegular regardless of icon size,
resulting in differently-sized toolbar on HiDPI and low-DPI screens.
Use scaled size instead.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@78087 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
There were several problems when the toolbar style was toggled to not show
icons, fix them by adding missing checks for wxTB_NOICONS style.
Closes#13578.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@75846 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use the same short names as are used by the event table macros for the event
type constants themselves. This makes them much more comfortable to use, e.g.
Bind(wxEVT_BUTTON) compared to Bind(wxEVT_COMMAND_BUTTON_CLICKED).
The old long names are still kept for backwards compatibility and shouldn't be
removed as it doesn't really cost anything to continue providing them, but all
new event types should only use the short versions.
Closes#10661.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73850 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is useless and can apparently result in some problems as of r25877 and
r25877 (from 8 years ago) added explicit checks preventing processing such
events in wxToolBar and wxMenu. Instead, simply don't generate these events in
the first place and also remove the now unnecessary checks for them.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70179 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Additionally renamed wxOSX' private wxNativePrinterDC::Ok() function to IsOk().
Didn't deprecate the various Ok() functions: given the amount of changes already introduced in 3.0 a trivial one like this seems more suitable for after 3.0.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67681 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Comment in wxToolBarBase::Realize() was probably copied from some
port-specific file but didn't make sense any more in common code.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62992 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Stretchable spaces consume all extra toolbar space not allocated to the fixed
size items. They can in particular be used to right-align (some) toolbar tools.
Add and document the new API, change the sample to show it and implement it
for MSW, GTK and OS X/Cocoa.
Also refactor MSW background erasing/repainting code to avoid duplicated calls
to DrawThemeBackground(), call it from a new helper MSWEraseRect() function.
Note that we may want to add support for "invisible" separators, IOW
non-stretchable spaces. This could be easily done for MSW after the changes in
this commit and is supported natively by GTK+ and Cocoa so implementing this
would be trivial if there is any interest.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62850 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Added a helper DoInsertNewTool() function to avoid code duplication and ensure
that we never forget to delete a new tool if inserting it into the toolbar
failed.
Also explicitly document that the tool passed to the public InsertTool() is
not owned by the toolbar and so must be deleted by the caller if its insertion
failed.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@62846 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
1. Don't destroy the control in wxToolBar::RemoveTool() as this prevents
it from being added back with is the purpose of using RemoveTool() rather
than DeleteTool().
2. Call wxToolBarTool::Attach/Detach() from the base code, not just from wxMSW
and wxMac (wasn't called by wxGTK at all).
3. Allow adding back the removed control tool in wxGTK.
4. Add test for removing/adding back a control tool to the sample.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@52840 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
removing it could silently break existing user code overriding this function.
Fix the problem with not restoring the original status bar text when the mouse
pointer left the toolbar by simply calling DoGiveHelp() with false as second
parameter only if there was no valid tool under mouse, not if the help string
(for a valid tool) was empty.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@45240 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use DeleteTool in ClearTools instead of just destroying the internal
list, so the toolbar is kept fully in sync with the removal of all
tool types. Also fix wxMSW version to actually Destroy() the controls
when they are deleted from the toolbar.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@37615 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Changed default for WXWIN_COMPATIBILITY_2_4 to 0.
Added WXWIN_COMPATIBILITY_2_6 (defaults to 1).
Ran build/update-setup-h.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@35858 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
