Hi-Resolution Icons

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Hi-Resolution Icons

Rik-4
2/13/15

Octave ships with just a single fixed size icon (png or ico) and an svg
for a scalable version.  Many operating systems want more fixed sizes in
order to display an attractive version of the icon for different
situations.  There is a bug report about this at
https://savannah.gnu.org/bugs/?37062.  The issue has already been solved,
twice, on the bug report.

One way is to create the icons "by hand" and store them under Mercurial
version control.  This uses about 450 KB of disk space.  I just checked the
price of a 1TB hard drive on Amazon and found $55 so this solution costs
.$0.00002 dollars.  Of course, every time the logo changes the icons would
have to be re-done, but re-branding happens every few years at most.

The second way is to base everything off the scalable icon format svg and
create the necessary sizes algorithmically.  This is less "wasteful" of
disk space, but it requires two new additions to the build dependencies for
Octave: icotool and rsvg-convert.  Maybe this isn't such a problem because
only developers need to worry about this, whereas users can download a
tarball with the files already generated.  Distribution maintainers like
Debian would need to add these to the "build-dep" target for apt-get.

I don't care which solution we use, but lets pick one ahead of the 4.0
release so we can have nice looking icons.  Please vote, and or comment on
the mailing list about which one is preferable.

--Rik



Reply | Threaded
Open this post in threaded view
|

Re: Hi-Resolution Icons

Mike Miller
On Fri, Feb 13, 2015 at 16:02:59 -0800, Rik wrote:
> The second way is to base everything off the scalable icon format svg and
> create the necessary sizes algorithmically.  This is less "wasteful" of
> disk space, but it requires two new additions to the build dependencies for
> Octave: icotool and rsvg-convert.

This is my preference (obvious if you read the bug report).

As the primary proponent, let me clarify that to me it's not at all
about saving disk space. More important to me is the philosophy of only
adding true "source" files to the hg repository. In this case, the SVG
is the source, the PNG are "compiled" from the SVG. If someone decides
to update the logo later (either change it completely or add some small
detail), will they know which files to update and which tools to use to
update them? If we instead rely on build rules, it's a solved problem.

I hope that even if we do decide to check in a dozen differently sized
PNG files, we can still have a make rule or a script that tells how to
generate the PNGs from the SVG source for future reference.

Can anyone say whether Windows is happy with PNG these days and we don't
even need the ICO file anymore? In

 http://octave.1599824.n4.nabble.com/RFC-icon-fix-requires-additional-tools-to-build-Octave-from-hg-tt4665545.html#a4665552

Philip wrote that he uses PNG files for launchers in Windows. Better if
we can get away with PNGs only, and no need for the icotool program.

I also notice that mxe-octave keeps a copy of octave-logo.ico in its
repository. Can NSIS use a PNG file instead? And can we copy the icon
from the Octave build directory instead of having a copy of it checked
in to mxe-octave?

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Hi-Resolution Icons

Torsten-2
On 14.02.2015 01:42, Mike Miller wrote:

> On Fri, Feb 13, 2015 at 16:02:59 -0800, Rik wrote:
>> The second way is to base everything off the scalable icon format svg and
>> create the necessary sizes algorithmically.  This is less "wasteful" of
>> disk space, but it requires two new additions to the build dependencies for
>> Octave: icotool and rsvg-convert.
>
> This is my preference (obvious if you read the bug report).
>
> As the primary proponent, let me clarify that to me it's not at all
> about saving disk space. More important to me is the philosophy of only
> adding true "source" files to the hg repository. In this case, the SVG
> is the source, the PNG are "compiled" from the SVG. If someone decides
> to update the logo later (either change it completely or add some small
> detail), will they know which files to update and which tools to use to
> update them? If we instead rely on build rules, it's a solved problem.
>
> I hope that even if we do decide to check in a dozen differently sized
> PNG files, we can still have a make rule or a script that tells how to
> generate the PNGs from the SVG source for future reference.
>
> Can anyone say whether Windows is happy with PNG these days and we don't
> even need the ICO file anymore? In
>
>  http://octave.1599824.n4.nabble.com/RFC-icon-fix-requires-additional-tools-to-build-Octave-from-hg-tt4665545.html#a4665552
>
> Philip wrote that he uses PNG files for launchers in Windows. Better if
> we can get away with PNGs only, and no need for the icotool program.
>
> I also notice that mxe-octave keeps a copy of octave-logo.ico in its
> repository. Can NSIS use a PNG file instead? And can we copy the icon
> from the Octave build directory instead of having a copy of it checked
> in to mxe-octave?
>
What about the window-icons of the gui's dock-widgets? Currently, these
are 32x32 png files in libgui/src/icons. I guess they should also be
available as svg only in the repository.

Torsten


Reply | Threaded
Open this post in threaded view
|

Re: Hi-Resolution Icons

Philip Nienhuis
In reply to this post by Mike Miller
Mike Miller wrote
On Fri, Feb 13, 2015 at 16:02:59 -0800, Rik wrote:

<snip>

Can anyone say whether Windows is happy with PNG these days and we don't
even need the ICO file anymore? In

 http://octave.1599824.n4.nabble.com/RFC-icon-fix-requires-additional-tools-to-build-Octave-from-hg-tt4665545.html#a4665552

Philip wrote that he uses PNG files for launchers in Windows.
I can't reproduce that png icon usage anymore these days with the mxe builds. But newer Windows versions definitely support PNG icons.  IIRC support for (compressed) PNG was introduced in Windows Vista.
Documentation for it is not easily found, but I didn't search very hard. There are some stumbling blocks anyway, see here:
https://social.msdn.microsoft.com/Forums/en-US/2c807b02-ea85-497d-8342-a971c6a3c4a6/png-icon-format?forum=windowsgeneraldevelopmentissues

As to icon size: Windows doesn't require a multitude of icon sizes as its icon display isn't very flexible (just two display sizes: regular and small; AFAIU it'll scale icons down itself for "small icon" settings).
Perhaps PNGs allow more flexibility, but from what I've seen that flexibility isn't used in Win7; maybe win 8+ is more configurable. Perhaps it is used in alternative GUIs/"desktop managers" for Windows (I've tried a few in Win2000 several years ago) but very very few people would use those, their existence is not widely known.

Philip
Reply | Threaded
Open this post in threaded view
|

Re: Hi-Resolution Icons

Carnë Draug
In reply to this post by Mike Miller
On 14 February 2015 at 00:42, Mike Miller wrote:

> On Fri, Feb 13, 2015 at 16:02:59 -0800, Rik wrote:
>> The second way is to base everything off the scalable icon format svg and
>> create the necessary sizes algorithmically.  This is less "wasteful" of
>> disk space, but it requires two new additions to the build dependencies for
>> Octave: icotool and rsvg-convert.
>
> This is my preference (obvious if you read the bug report).
>
> As the primary proponent, let me clarify that to me it's not at all
> about saving disk space. More important to me is the philosophy of only
> adding true "source" files to the hg repository. In this case, the SVG
> is the source, the PNG are "compiled" from the SVG. If someone decides
> to update the logo later (either change it completely or add some small
> detail), will they know which files to update and which tools to use to
> update them? If we instead rely on build rules, it's a solved problem.
>
>> I don't care which solution we use, but lets pick one ahead of the 4.0
>> release so we can have nice looking icons.  Please vote, and or comment on
>> the mailing list about which one is preferable.

Mike's argument makes sense to me.  I vote on keeping only the SVG
and generate the icons for the release.

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: Hi-Resolution Icons

Rik-4
On 02/16/2015 04:39 AM, Carnë Draug wrote:

> On 14 February 2015 at 00:42, Mike Miller wrote:
>> On Fri, Feb 13, 2015 at 16:02:59 -0800, Rik wrote:
>>> The second way is to base everything off the scalable icon format svg and
>>> create the necessary sizes algorithmically.  This is less "wasteful" of
>>> disk space, but it requires two new additions to the build dependencies for
>>> Octave: icotool and rsvg-convert.
>> This is my preference (obvious if you read the bug report).
>>
>> As the primary proponent, let me clarify that to me it's not at all
>> about saving disk space. More important to me is the philosophy of only
>> adding true "source" files to the hg repository. In this case, the SVG
>> is the source, the PNG are "compiled" from the SVG. If someone decides
>> to update the logo later (either change it completely or add some small
>> detail), will they know which files to update and which tools to use to
>> update them? If we instead rely on build rules, it's a solved problem.
>>
>>> I don't care which solution we use, but lets pick one ahead of the 4.0
>>> release so we can have nice looking icons.  Please vote, and or comment on
>>> the mailing list about which one is preferable.
> Mike's argument makes sense to me.  I vote on keeping only the SVG
> and generate the icons for the release.

That's two votes for Mike's solution which is good enough.  I had dinner
with Mike last night and happen to know that he is on a plane today.  But
he should go ahead and commit his solution in the next few days.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Hi-Resolution Icons

John W. Eaton
Administrator
On 02/16/2015 10:50 AM, rik wrote:

> That's two votes for Mike's solution which is good enough.

I agree that we should try to avoid keeping generated files in the repo.
  Or, even if we do, we should still write down the rules for generating
the files and have a "maintainer super clean" target that removes the
generated files and exercises the rules.

I also think that these icon files should be treated like the configure
script, the flex and bison generated files, and doc files for tar file
distributions.  Users who build from tar files should not need to
generate these files unless they modify the corresponding source files.

jwe



Reply | Threaded
Open this post in threaded view
|

Icons for the GUI (was: Re: Hi-Resolution Icons)

John W. Eaton
Administrator
In reply to this post by Torsten-2
On 02/14/2015 06:09 AM, Torsten wrote:

> What about the window-icons of the gui's dock-widgets? Currently, these
> are 32x32 png files in libgui/src/icons. I guess they should also be
> available as svg only in the repository.

I think it would be preferable if they can also be generated in various
sizes as required from some resolution independent format.

Overall, I think we need to take a look at the icons we are using and
try to come up with a consistent set.  It currently seems as though we
have a random collection of various icons.  Some are color, others are
not and they don't appear to me as if they have any kind of consistent
styling.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Hi-Resolution Icons

Mike Miller
In reply to this post by John W. Eaton
On Mon, Feb 16, 2015 at 12:50:27 -0500, John W. Eaton wrote:

> On 02/16/2015 10:50 AM, rik wrote:
>
> >That's two votes for Mike's solution which is good enough.
>
> I agree that we should try to avoid keeping generated files in the repo.
> Or, even if we do, we should still write down the rules for generating the
> files and have a "maintainer super clean" target that removes the generated
> files and exercises the rules.
>
> I also think that these icon files should be treated like the configure
> script, the flex and bison generated files, and doc files for tar file
> distributions.  Users who build from tar files should not need to generate
> these files unless they modify the corresponding source files.

I believe the changeset I pushed does all of this correctly:

  http://hg.savannah.gnu.org/hgweb/octave/rev/1687269e31e4

The icotool and rsvg-convert programs are now required to build from hg
and to make the `dist` target. The icons are generated, are in the tar
source distribution, and are also installed to what I think are the
correct paths for freedesktop compatible systems:

  http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html

The Windows icon is generated but not installed, it can be copied and
used wherever it's needed by the mxe-octave build. It now contains
multiple resolutions so it should scale correctly when used on Windows
systems.

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Icons for the GUI

Torsten-2
In reply to this post by John W. Eaton
On 16.02.2015 18:54, John W. Eaton wrote:

> On 02/14/2015 06:09 AM, Torsten wrote:
>
>> What about the window-icons of the gui's dock-widgets? Currently, these
>> are 32x32 png files in libgui/src/icons. I guess they should also be
>> available as svg only in the repository.
>
> I think it would be preferable if they can also be generated in various
> sizes as required from some resolution independent format.
>
> Overall, I think we need to take a look at the icons we are using and
> try to come up with a consistent set.  It currently seems as though we
> have a random collection of various icons.  Some are color, others are
> not and they don't appear to me as if they have any kind of consistent
> styling.
>

What do you think of the tango icon set (http://tango.freedesktop.org/)?
Since qt has an svg icon engine (I have not yet tested it) we could
directly use the svg-icons included in the tango set.

Torsten




Reply | Threaded
Open this post in threaded view
|

Re: Icons for the GUI

John W. Eaton
Administrator
On 02/24/2015 03:12 PM, Torsten wrote:

> On 16.02.2015 18:54, John W. Eaton wrote:
>> On 02/14/2015 06:09 AM, Torsten wrote:
>>
>>> What about the window-icons of the gui's dock-widgets? Currently, these
>>> are 32x32 png files in libgui/src/icons. I guess they should also be
>>> available as svg only in the repository.
>>
>> I think it would be preferable if they can also be generated in various
>> sizes as required from some resolution independent format.
>>
>> Overall, I think we need to take a look at the icons we are using and
>> try to come up with a consistent set.  It currently seems as though we
>> have a random collection of various icons.  Some are color, others are
>> not and they don't appear to me as if they have any kind of consistent
>> styling.
>>
>
> What do you think of the tango icon set (http://tango.freedesktop.org/)?
> Since qt has an svg icon engine (I have not yet tested it) we could
> directly use the svg-icons included in the tango set.

Is there a location for a full set of samples?  From what I've seen they
look OK to me and certainly more consistent than what we currently have.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Icons for the GUI

Daniel Sebald
In reply to this post by Torsten-2
On 02/24/2015 02:12 PM, Torsten wrote:

> On 16.02.2015 18:54, John W. Eaton wrote:
>> On 02/14/2015 06:09 AM, Torsten wrote:
>>
>>> What about the window-icons of the gui's dock-widgets? Currently, these
>>> are 32x32 png files in libgui/src/icons. I guess they should also be
>>> available as svg only in the repository.
>>
>> I think it would be preferable if they can also be generated in various
>> sizes as required from some resolution independent format.
>>
>> Overall, I think we need to take a look at the icons we are using and
>> try to come up with a consistent set.  It currently seems as though we
>> have a random collection of various icons.  Some are color, others are
>> not and they don't appear to me as if they have any kind of consistent
>> styling.
>>
>
> What do you think of the tango icon set (http://tango.freedesktop.org/)?
> Since qt has an svg icon engine (I have not yet tested it) we could
> directly use the svg-icons included in the tango set.

What icons are people referring to?  It seemed to me that at first the
Octave GUI was supplying it's own icons, but Qt has many definitions for
standard operations like "open", "clipboard", "alert", etc.  When these
are used, the icons match the look and feel of the user's desktop.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Icons for the GUI

Torsten-2
In reply to this post by John W. Eaton
On 24.02.2015 22:29, John W. Eaton wrote:

> On 02/24/2015 03:12 PM, Torsten wrote:
>> On 16.02.2015 18:54, John W. Eaton wrote:
>>> On 02/14/2015 06:09 AM, Torsten wrote:
>>>
>>>> What about the window-icons of the gui's dock-widgets? Currently, these
>>>> are 32x32 png files in libgui/src/icons. I guess they should also be
>>>> available as svg only in the repository.
>>>
>>> I think it would be preferable if they can also be generated in various
>>> sizes as required from some resolution independent format.
>>>
>>> Overall, I think we need to take a look at the icons we are using and
>>> try to come up with a consistent set.  It currently seems as though we
>>> have a random collection of various icons.  Some are color, others are
>>> not and they don't appear to me as if they have any kind of consistent
>>> styling.
>>>
>>
>> What do you think of the tango icon set (http://tango.freedesktop.org/)?
>> Since qt has an svg icon engine (I have not yet tested it) we could
>> directly use the svg-icons included in the tango set.
>
> Is there a location for a full set of samples?  From what I've seen they
> look OK to me and certainly more consistent than what we currently have.
>

This is the archive:
http://tango.freedesktop.org/releases/tango-icon-theme-0.8.90.tar.gz

Some special icons are missing like the ones for debugging or setting
breakpoints

Torsten



Reply | Threaded
Open this post in threaded view
|

Re: Icons for the GUI

Mike Miller
In reply to this post by Daniel Sebald
On Tue, Feb 24, 2015 at 15:42:27 -0600, Daniel J Sebald wrote:
> What icons are people referring to?  It seemed to me that at first the
> Octave GUI was supplying it's own icons, but Qt has many definitions for
> standard operations like "open", "clipboard", "alert", etc.  When these are
> used, the icons match the look and feel of the user's desktop.

My recollection is you are correct that the user's desktop theme will
indeed be preferred when you use standard icon names. But I don't
think that works if you need a non-standard icon, say an icon for "set
a breakpoint" (just to pick a random example). Or if you run on an
older system that may not have an up to date set of icon names. Or if
you run on Windows. So Octave must include a default set of icons as
an internal fallback for when the theme fails to provide a named icon.

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Icons for the GUI

Torsten-2
In reply to this post by Daniel Sebald
On 24.02.2015 22:42, Daniel J Sebald wrote:

> On 02/24/2015 02:12 PM, Torsten wrote:
>> On 16.02.2015 18:54, John W. Eaton wrote:
>>> On 02/14/2015 06:09 AM, Torsten wrote:
>>>
>>>> What about the window-icons of the gui's dock-widgets? Currently, these
>>>> are 32x32 png files in libgui/src/icons. I guess they should also be
>>>> available as svg only in the repository.
>>>
>>> I think it would be preferable if they can also be generated in various
>>> sizes as required from some resolution independent format.
>>>
>>> Overall, I think we need to take a look at the icons we are using and
>>> try to come up with a consistent set.  It currently seems as though we
>>> have a random collection of various icons.  Some are color, others are
>>> not and they don't appear to me as if they have any kind of consistent
>>> styling.
>>>
>>
>> What do you think of the tango icon set (http://tango.freedesktop.org/)?
>> Since qt has an svg icon engine (I have not yet tested it) we could
>> directly use the svg-icons included in the tango set.
>
> What icons are people referring to?  It seemed to me that at first the
> Octave GUI was supplying it's own icons, but Qt has many definitions for
> standard operations like "open", "clipboard", "alert", etc.  When these
> are used, the icons match the look and feel of the user's desktop.
>

Are you refering to QIcon::fromTheme ()? This does not work on Mac and
Windows (http://doc.qt.io/qt-5/qicon.html#fromTheme). However, we can
use theme icons and provide fallback icons. This is already done for the
icons of the file->close... menu entries in the editor.

Torsten




Reply | Threaded
Open this post in threaded view
|

Re: Icons for the GUI

Daniel Sebald
On 02/25/2015 12:01 AM, Torsten wrote:

> On 24.02.2015 22:42, Daniel J Sebald wrote:
>> On 02/24/2015 02:12 PM, Torsten wrote:
>>> On 16.02.2015 18:54, John W. Eaton wrote:
>>>> On 02/14/2015 06:09 AM, Torsten wrote:
>>>>
>>>>> What about the window-icons of the gui's dock-widgets? Currently, these
>>>>> are 32x32 png files in libgui/src/icons. I guess they should also be
>>>>> available as svg only in the repository.
>>>>
>>>> I think it would be preferable if they can also be generated in various
>>>> sizes as required from some resolution independent format.
>>>>
>>>> Overall, I think we need to take a look at the icons we are using and
>>>> try to come up with a consistent set.  It currently seems as though we
>>>> have a random collection of various icons.  Some are color, others are
>>>> not and they don't appear to me as if they have any kind of consistent
>>>> styling.
>>>>
>>>
>>> What do you think of the tango icon set (http://tango.freedesktop.org/)?
>>> Since qt has an svg icon engine (I have not yet tested it) we could
>>> directly use the svg-icons included in the tango set.
>>
>> What icons are people referring to?  It seemed to me that at first the
>> Octave GUI was supplying it's own icons, but Qt has many definitions for
>> standard operations like "open", "clipboard", "alert", etc.  When these
>> are used, the icons match the look and feel of the user's desktop.
>>
>
> Are you refering to QIcon::fromTheme ()? This does not work on Mac and
> Windows (http://doc.qt.io/qt-5/qicon.html#fromTheme). However, we can
> use theme icons and provide fallback icons. This is already done for the
> icons of the file->close... menu entries in the editor.

No, I'm referring to what is called the standard pixmap:

http://doc.qt.io/qt-5/qstyle.html#StandardPixmap-enum

The definitions work with the standardIcon member function.  There is
enough variety there (about 70) to cover a lot of functions.  Perhaps
they aren't scalable vector graphics though.  Maybe they match the
desktop theme, maybe not.  I've not explored all the various
possibilities of definitions and icon sizes--only a few uses in other
applications for information and help icons (which comes out like a
round, red-white life preserver).

The icons needed to supplement common file routines (e.g.,
debugger-related functions, and whatever else comes up) don't appear in
the icon set at the link you provided.  At least, not what I saw.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Icons for the GUI

rocketsound
In reply to this post by Torsten-2
Also, take the Oxygen icon set into consideration as it is shipped with most KDE 4.xx releases. Compared to the Tango icon set it looks way more up to date IMO. Oxygen is licensed under the LGPL and I don't know if this is a problem with Octave's GPL. More infos here https://techbase.kde.org/Projects/Oxygen, sadly the link http://www.oxygen-icons.org/ they point us to isn't working anymore, maybe someone else knows where to get the official, most recent version?

Here is a PNG-only git repository: https://github.com/pasnox/oxygen-icons-png
This icon set contains some debug-***-icons but no icons related to breakpoints.
Reply | Threaded
Open this post in threaded view
|

Re: Icons for the GUI

Torsten-2
On 25.02.2015 12:23, rocketsound wrote:

> Also, take the Oxygen icon set into consideration as it is shipped with most
> KDE 4.xx releases. Compared to the Tango icon set it looks way more up to
> date IMO. Oxygen is licensed under the LGPL and I don't know if this is a
> problem with Octave's GPL. More infos here
> https://techbase.kde.org/Projects/Oxygen, sadly the link
> http://www.oxygen-icons.org/ they point us to isn't working anymore, maybe
> someone else knows where to get the official, most recent version?
>
> Here is a PNG-only git repository:
> https://github.com/pasnox/oxygen-icons-png
> This icon set contains some debug-***-icons but no icons related to
> breakpoints.
>

I am preparing a patch for testing that uses the icons from the current
theme and as a fallback (windows and mac) the tango icons. Since there
exists a naming convention for icon files we can easily switch to
another icon set.

Torsten




Reply | Threaded
Open this post in threaded view
|

Re: Icons for the GUI

Torsten-2
On 25.02.2015 18:47, Torsten wrote:

> On 25.02.2015 12:23, rocketsound wrote:
>> Also, take the Oxygen icon set into consideration as it is shipped with most
>> KDE 4.xx releases. Compared to the Tango icon set it looks way more up to
>> date IMO. Oxygen is licensed under the LGPL and I don't know if this is a
>> problem with Octave's GPL. More infos here
>> https://techbase.kde.org/Projects/Oxygen, sadly the link
>> http://www.oxygen-icons.org/ they point us to isn't working anymore, maybe
>> someone else knows where to get the official, most recent version?
>>
>> Here is a PNG-only git repository:
>> https://github.com/pasnox/oxygen-icons-png
>> This icon set contains some debug-***-icons but no icons related to
>> breakpoints.
>>
>
> I am preparing a patch for testing that uses the icons from the current
> theme and as a fallback (windows and mac) the tango icons. Since there
> exists a naming convention for icon files we can easily switch to
> another icon set.
>

The patch is ready for test and can be found at
https://savannah.gnu.org/patch/index.php?8614

Under windows, the location of the necessary qt-dlls for svg-icons is
important. They are currently located in subdirectories of "plugins" in
the installation directory. The icons are only visible in windows when
"plugin" is located in the "bin" directory.

Torsten




Reply | Threaded
Open this post in threaded view
|

Re: Icons for the GUI

John W. Eaton
Administrator
On 02/28/2015 11:50 AM, Torsten wrote:

>> I am preparing a patch for testing that uses the icons from the current
>> theme and as a fallback (windows and mac) the tango icons. Since there
>> exists a naming convention for icon files we can easily switch to
>> another icon set.
>>
>
> The patch is ready for test and can be found at
> https://savannah.gnu.org/patch/index.php?8614
>
> Under windows, the location of the necessary qt-dlls for svg-icons is
> important. They are currently located in subdirectories of "plugins" in
> the installation directory. The icons are only visible in windows when
> "plugin" is located in the "bin" directory.

This change looks good to me.  Is there any reason not to commit it?

jwe



12