Scaled Icons in the toolbar need overhaul

[GWRon]

The scaled variants of the toolbar icons miss some "black surroundings" around the "white surrounding" around the icons. Maybe it is because of ResizePixmap() using a simpler "resize algorithm".

On my Linux box it looks fine - but on Windows 10 ....

zoomed:

... it looks a bit "damaged".

Also I wonder why the arrows have a blueish taint on my linux box but are black in my Windows box (did I miss an update?)

[woollybah]

I blame inkscape :-p I can add the original SVGs to the project if that helps?

[GWRon]

Didn't your bah.mods contain something allowing handling of svg files (so makeicons can do it on its own)?

Else I could try to use the svg files if you provide them.

[GWRon]

Seems you once already had some "SVG viewer" thingy ready (QT): http://mojolabs.nz/posts.php?topic=86562

I opened the SVG files in various programmes - and they seem to have certain "issues".

(older Adobe) Illustrator:

Inkscape + Inkscape-export: (see the greyish area on the right of the scissor in the SVG view already?)

Think the icons need to get saved by a tool displaying it properly. So at the end it might become compatible to (my) inkscape's capabilities of reading SVG files.

[woollybah]

Well, they come straight out of the Visual Studio icon library. I can't really vouch for Microsoft.. for anything really :-p

[GWRon]

Ok, your reply came meanwhile, so no edit of the old message ...

librsvg2-bin (rsvg-convert in out or convert) results in similar black rectangles than illustrator on certain SVGs.

I tried this to convert multiple variants:

#!/bin/bash
mkdir "$PWD"/png64
for file in $PWD/*.svg
    do
        filename=$(basename "$file")
        #--without-gui
        inkscape -z -e "png64/${filename%.svg}.png" -w 64 -h 64 "$file"
        convert -size 64x64 "$file" "png64/${filename%.svg}_convert.png"
    done

(convert somehow creates 16x16px files tough ...

[GWRon]

I converted them now "by hand" via this online tool here: https://jakearchibald.github.io/svgomg/ (was pretty straight forward)

The "black rects" are gone, but Inkscape still has eg. issues with the scissor in the screens above. "[C]onvert" (or librsvg2-bin) was able to produce nice images afterwards - with exceptions (and nope, this is a single exception, other images - like "step in" looked like they should!)

I've gone back to the above said tool - and tried to uncheck some of the optimizations. I needed to uncheck "Remove unknown & defaults".

The resulting SVGs only differed in the first two lines:

broken

<svg xmlns="http://www.w3.org/2000/svg" width="16" height="16">
  <style>
    .icon-vs-out{fill:#F6F6F6}
  </style>
  <g id="outline">
    <path class="icon-vs-out" d="M10 7.414l2 2V4.586l-4-4-4 4v4.828l2-2V10h4z"/>
    <circle class="icon-vs-out" cx="8" cy="13" r="3"/>
  </g>
  <path d="M8 11a2 2 0 1 1-.001 4.001A2 2 0 0 1 8 11z" fill="#424242" id="iconBg"/>
  <path d="M11 5v2L9 5v4H7V5L5 7V5l3-3 3 3z" fill="#00539C" id="colorAction"/>
</svg>

working as expected

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" x="0" y="0" width="16" height="16" xml:space="preserve">
  <style type="text/css">
    .icon-vs-out{fill:#F6F6F6}
  </style>
  <g id="outline">
    <path class="icon-vs-out" d="M10 7.414l2 2V4.586l-4-4-4 4v4.828l2-2V10h4z"/>
    <circle class="icon-vs-out" cx="8" cy="13" r="3"/>
  </g>
  <path d="M8 11a2 2 0 1 1-.001 4.001A2 2 0 0 1 8 11z" fill="#424242" id="iconBg"/>
  <path d="M11 5v2L9 5v4H7V5L5 7V5l3-3 3 3z" fill="#00539C" id="colorAction"/>
</svg>

Why do I write this? We all want to learn something ;-)

[GWRon]

Sources miss "Go_16x.svg" - I think I just open up the "stop" and replace the color ...

[GWRon]

Ok, added new build and build-run icons (with a similar grayish-outline than the rest).

Ready to PR it for now - next step is to add the newly created 16x16px icons for win32 builds.

[woollybah]

Looks great. Thanks!

What's the 16x16 for?

[GWRon]

I was sure to have seen them scaled to 1616 on win7 ... Will check that out later. Maybe it was 2424 but then we need to "flatten" the symbols so they do not have multiple transparency colors.

[GWRon]

Above: maxIDE Below: toolbar example from the CreateToolbar-help (Maxide: F1)

there must be something happening in MaxIDE to make it look different (disabling alpha channel or so)

[GWRon]

Seems the call to "SetMode EDIT_MODE" in maxide calls "RefreshToolbar()" - which is the source of these "borders". So what is done there? It enables or disables gadgets.

Once you disable icons in the "toolbar example" they look borked-up the same.

[woollybah]

So it's just Windows being... Windows. I'm happy to live with it :-)

[GWRon]

It's not Windows ... it is MaxGUI I think - the way it draws "disabled" icons.

[woollybah]

So, it's Windows then :-p MaxGUI just sends a message to indicate the current state of a particular toolbar button.

[GWRon]

But why does it work "nicely" in other applications?

Just open up "Paint" and the "insert" icon will be "grayscale + semi-transparent", copy something of the canvas and it gets colored nicely. This is how I expect to look MaxIDE too.

[woollybah]

Maybe it's to do with that white border? I dunno.

[GWRon]

What's that

    Method OnDrawItem(pDrawItemStruct:DRAWITEMSTRUCT)

in win32maxguiex.bmx for? I tried disabling it ... without visual differences (but it contains stuff for checking disable-state or pressed-state. Only Buttons?

[GWRon]

If there was an option to render the toolbar elements on our own (similar to that OnDrawItem) thing then we could prepare icons accordingly (convert to grayscale and lower transparency). My Dig-Framework-code already contains some helpful functions for it).

[GWRon]

If we really want to stay with a "MaxIDE" then maybe it is better to realise the whole thing in with wxMax then. Filesize would increase but maybe some advanced features would become easier to achieve (layout, specific widgets, wizards).

[GWRon]

According to MS there is "TB_GETDISABLEDIMAGELIST" https://docs.microsoft.com/en-us/windows/desktop/controls/tb-getdisabledimagelist

and there is "TB_SETDISABLEDIMAGELIST" https://docs.microsoft.com/en-us/windows/desktop/controls/tb-setdisabledimagelist

Doesn't this mean we could extend MaxGUI to allow setting a custom "TIconStrip". If so we could prepare a "toolbar.png" and a "toolbar_disabled.png" which has some nicely faded-out-grayscale variants of the icons.

[woollybah]

In the scheme of things (in relation to other outstanding issues), I don't think it is a hugely important problem ;-)

[GWRon]

Ok, I added a "SetDisabledIconStrip()" to TWindowsToolbar. That way one could define a custom TIconStrip to get used for disabled icons on Win32 environments.

I could now add a "automated" approach to desaturate and "alpha-fade" the given iconstrip - or we have this code within MaxIDE. So one approach would help all MaxGUI applications - but it might look different to the default "gray out icons"-approach of Windows. The other one keeps the MaxGUI-module clean of this "hack".

This is the result:

• with opened document the "cut copy paste" are enabled
• without they are grayed out too
• 3rd shows current MaxIDE with new icons

Edit my desaturation formula would allow to keep a certain amount of color information. I calculate the luminance of the RGB value and then adjust the RGB according to the percentage of luminance we want. If we wanted an absolute gray/monochrome variant then we could save 4 lines of code (woohoo!).