[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] using standard icon sizes and wxArtProvider
From: |
Greg Chicares |
Subject: |
Re: [lmi] using standard icon sizes and wxArtProvider |
Date: |
Fri, 03 Oct 2008 14:46:48 +0000 |
User-agent: |
Thunderbird 2.0.0.16 (Windows/20080708) |
On 2008-10-02 16:02Z, Greg Chicares wrote:
> [...] commit your patch
> https://savannah.nongnu.org/patch/?6597
> but suppress scaling for now
Thanks again for that patch. As usual, I want to understand everything
deeply; rewriting the art-provider module from scratch myself was merely
my way of learning, and implies no criticism of what you submitted. Also
as usual, I have numerous questions....
Should wxArtProvider::DoGetSizeHint() be part of the documented
interface? It seemed to me that GetRealSize() here:
http://cvs.savannah.gnu.org/viewvc/lmi/lmi/icon_monger.cpp?annotate=1.1
is like a virtual override. Grepping the wx-2.8.7 sources, this virtual
function doesn't seem to be used internally by wx, so is it intended
for wx users to override?
(BTW, grepping for /GetSizeHint/ throughout the sources finds
msw/mdi.cpp: // but allow GetSizeHints() to set the min size
but no function GetSizeHints() seems to exist anywhere.)
If you'd like to add a fancier algorithm for icon downsizing to wx,
I'd welcome that; we could discuss it privately. Here's a side-by-side
comparison of the present box-averaging result to a Lanczos resizing:
http://cvs.savannah.gnu.org/viewvc/lmi/lmi/gwc/resize.png?hideattic=0&revision=1.1&view=markup
This isn't really important for lmi today, but someday it could be
helpful. It's always better to design customized small icons than to
rely on any algorithm when converting, say, 24x24 --> 16x16. However,
I conjecture that this might be a beneficial enhancement for converting
16x16 --> 16x15, which apparently would happen in the following
wxArtProvider::GetSizeHint() case:
#else // !GTK+ 2
// NB: These size hints may have to be adjusted per platform
if (client == wxART_TOOLBAR)
return wxSize(16, 15);
(BTW, I wonder why any platform would choose 16x15 over 16x16: why
not perfectly square? I find:
http://lists.wxwidgets.org/pipermail/wx-dev/2005-February/058369.html
| 16x15 at least used to be the standard bitmap size under Windows
http://management.cadalyst.com/cadman/article/articleDetail.jsp?id=408730
| What sizes are the bitmap images used in AutoCAD toolbars? The correct
| answer has varied over time, but one thing has stayed constant for the
| past six releases, and that is that AutoCAD gives the wrong answer.
[variously, 16x16 vs. 16x15, 32x32 vs. 32x30, and sometimes 24x22]
...and I conclude that it's probably just arbitrary. But I'd be glad
to hear any explanation that makes more sense.)
In 'README', today we have:
new.png from stock_new.png
new-16.png from stock_new-formula.png
but is the second quoted line correct, or should I replace both by:
new[-16].png from stock_new.png
? Here's a standard 'stock_new-formula.png':
http://svn.bosslinux.in/boss-trac/browser/boss-artwork/24x24/stock/document/stock_new-formula.png?rev=96
Re: [lmi] using standard icon sizes and wxArtProvider, Greg Chicares, 2008/10/04