lmi
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]