Re: [lmi] using standard icon sizes and wxArtProvider

[Greg Chicares]

On 2008-08-03 18:19Z, Vaclav Slavik wrote:
> On Tue, 2008-03-18 at 20:29 +0100, Vaclav Slavik wrote:
>> > But in this case I think the smart thing is to ask whether you would
>> > pick the best solution and implement it, because it's beyond my wx
>> > expertise. 
>> 
>> I'll think about it, but I'm indeed leaning towards custom 
>> wxArtProvider.
> 
> And that's what I finally did. I uploaded the patch to Savannah, because
> part of it is 30kB tarball with PNGs:
> 
>     https://savannah.nongnu.org/patch/index.php?6597

I'd like to thank you for the great care you've taken, for example,
even in modifying 'README' thoughtfully. After many days of focused
labor in a completely different part of the program, it's pleasant to
dig into my mailing-list backlog and see so many nice things from you
and Vadim both.

> I converted all GNOME icons to PNGs with alpha channel and both 24x24
> and 16x16 sizes, but I didn't touch LMI-specific icons. Unfortunately,
> leaving them as-is is not very usable: in addition to looking out of
> place because of missing alpha channel (as discussed here), they don't 
> scale down to 16x16 well and this makes their use in menus ugly:
> http://tinyurl.com/6pzfsu

Agreed.

> So we need to update these icons too, both to use alpha channel and to
> have 16x16 variants. The former means "simply" replicating your
> modifications to GNOME icons they are derived from (having access to
> icon files split into individual layers would be useful here, if they
> still exist somewhere).

They never existed. What I did to those GNOME icons was barbarically
unsophisticated. I merely replaced small rectangular areas by changing
one pixel at a time in the GIMP. For example, to print output for one
person, I overwrote a few pixels with this representation of a human:

      X X X
      X X X
        X
    X X X X X
        X
      X X X
    X       X

Probably the originals had an alpha channel that I obliterated by
saving the files in an incorrect manner.

For numerous persons (blank = white; G = green; V = violet; B = blue):

      G G G
      G G G   V V V
        G     V V V   B B B
    G G G G G   V     B B B
        G   V V V V V   B
      G G G     V   B B B B B
    G       G V V V     B
            V       V B B B
                    B       B

Summoning all my drawing skill, I drew a new 'print-case-16.png' [0]
that attempts to accomplish something similar with fewer pixels. It
really isn't good; but if your artistic skill doesn't exceed mine,
then it would be good enough for now, and can be improved later.

> The latter is more tricky, because these custom icons are very detailed
> and differ only in small details, which is something that is bound to be
> even less recognizable in 16x16 size.

Indeed.

> Should I update the icons, or do you prefer to do it yourself (for some
> value of "you")?

Let me ask you to update them. You can't do worse than I would.

I'd welcome a better idea. For instance: instead of human figures
that can't be recognized at 16x16 resolution, how about Chinese
"rod" numerals [U+1D360, U+1D361, U+1D362]...

一 = 1 [U+1D360]; 二 = 2; 三 = 3

...superimposed on GNOME icons? This cartesian product of icons:

  {edit|print|run} X {cell,class,case} X {large,small}

represents the most common operations. The middle factor means
groups of people, in cardinality order cell <= class <= case. Thus,
e.g., there really are three distinct "print" operations that vary
by the cardinality of the aggregate to which each applies.

Alternatively, is there a better way of distinguishing, e.g., three
print operations, iconically? Differentiating them only by color
might work, and would at least be visually discernible.

Yet another option is to revert to the icon set used by our legacy
application. (Let me know if you don't have it handy, and I'll send
it to you.) I think those icons are clearer, but they're also cruder,
and might not mix well with the highly-polished GNOME icons; then we
might choose to use no GNOME icons, because a consistently-crude icon
set would at least be consistent. What do you think?

It would be great if you could devise icons for these menuitems
as well:

        <object class="wxMenuItem" name="copy_summary">
            <label>_Copy calculation summary\tCtrl-C</label>
        <object class="wxMenuItem" name="wxID_COPY">
            <label>Copy full illustration _data\tCtrl-D</label>
        <object class="wxMenuItem" name="preview_summary">
            <label>Pre_view calculation summary\tCtrl-V</label>
        <object class="wxMenuItem" name="print_summary">
            <label>_Print calculation summary\tCtrl-P</label>

The second is just wxID_COPY, for which a stock icon seems perfect.
The other menuitems are like standard operations that have stock icons,
except that they use a dataset that's an order of magnitude smaller.
I would probably try to alter the stock icons to suggest the smaller
dataset, but I'm no graphic designer, and you might think of a much
better approach.

BTW, are there stock icons for menuitems on the MDI "Window" menu,
and if not, would you like to create some?

> Also, on a somewhat related note, should we convert the rest of XPM
> icons (not used in menus and toolbars) in use to PNGs for consistency,
> or do you prefer to leave them as they are?

Let me ask you to convert them, too, please. Consistency is a good
enough reason. Another good reason is that firefox doesn't display the
XPM icons that I have embedded in html help (though wxHTML does), and
I'd like the user manual to be browsable online. Using your PNG icons
in the html solves the firefox problem.

---------

[0] "I drew a new 'print-case-16.png'":

/* XPM */
static char * print_case_16_xpm[] = {
"16 16 81 1",
"       c None",
".      c #000000",
"+      c #FFFFFF",
"@      c #83A67F",
"#      c #887FA3",
"$      c #7590AE",
"%      c #BCBBBB",
"&      c #ABABAA",
"*      c #CECECE",
"=      c #BCBCBC",
"-      c #C5C5C5",
";      c #6D6D6C",
">      c #929292",
",      c #C2C2C2",
"'      c #FBFBFB",
")      c #FAFAFA",
"!      c #F8F8F8",
"~      c #F4F4F3",
"{      c #BEBEBD",
"]      c #9F9E9B",
"^      c #F7F7F7",
"/      c #E5E5E4",
"(      c #8D8D8D",
"_      c #EEEEEE",
":      c #D1D1D1",
"<      c #E2E2E2",
"[      c #DADAD9",
"}      c #DEDDDC",
"|      c #DCDCDA",
"1      c #D8D7D4",
"2      c #B3B2B0",
"3      c #B2B0AD",
"4      c #1B1B1B",
"5      c #C7C6C6",
"6      c #D6D4D2",
"7      c #DDDBDA",
"8      c #DCDCDB",
"9      c #DEDDDD",
"0      c #DFDEDD",
"a      c #DDDCDB",
"b      c #D9D9D8",
"c      c #DBDBD9",
"d      c #DAD9D7",
"e      c #D9D8D6",
"f      c #81807E",
"g      c #949390",
"h      c #CFCDCD",
"i      c #9E9D9C",
"j      c #615E59",
"k      c #54514E",
"l      c #54524E",
"m      c #514F4B",
"n      c #52504C",
"o      c #504D49",
"p      c #4D4B47",
"q      c #4F4D49",
"r      c #514F4C",
"s      c #939291",
"t      c #CBCAC9",
"u      c #C0BFBC",
"v      c #B9B8B5",
"w      c #B3B1AF",
"x      c #B1B1AE",
"y      c #AFAEAC",
"z      c #B0AEAC",
"A      c #ACACA9",
"B      c #A6A6A4",
"C      c #ABAAA7",
"D      c #AEADAA",
"E      c #9B9A98",
"F      c #949290",
"G      c #807E7C",
"H      c #898785",
"I      c #898885",
"J      c #807F7C",
"K      c #7F7E7C",
"L      c #7F7E7B",
"M      c #706F6C",
"N      c #6F6E6B",
"O      c #6B6A67",
"P      c #61605E",
"                ",
"    .........   ",
"   address@hidden  ",
"   .@@@+#++++.  ",
"   address@hidden  ",
"   address@hidden@+#+$$$.  ",
"   .+++#+#+$+.  ",
"   .++++++$+$.  ",
"  .%&*=====-;>. ",
" .,'+)+)'')!~{].",
" .)^/(_:<[}|1234",
" .567890abcdefg.",
" .hijklmnopqrsg.",
" .tuvwxyzABCDyE.",
" .FGHIJJKLKMNOP.",
"  ............. "};