[Mono-dev] [PATCH] Win32 Shell Icons in MWF with high level systemicon abstraction layer in XplatUI

Peter Dennis Bartok peter at novonyx.com
Thu Sep 22 11:29:48 EDT 2005


Thanks for all the work you put into the patch. I did a quick review, I will 
need more time before approving it. One thing that already know needs to be 
different is where the special icons are pulled from. We need to allow 
themes to provide the special icons to be used, so the file dialog will need 
to call into the theme to get them. The theme then has the choice of pulling 
it from the driver or from somewhere else. But, we possibly might go one 
step further and move the complete composition of the file dialog into the 
theme, which could allow a theme using the native openfile dialog (assuming 
the theme finds a way to have a match in features)

Also, I think the methods for the icons in the driver are not 
straightforward enough. I want something along the lines of "Image 
GetIcon(string path)" or maybe "Image GetIcon(string path, bool 
wantLargeIcon)". The rest should be hidden underneath. There's no reason to 
pass in a bool whether or not the path is a directory, the code returning 
the icon can check that itself. Returning an index instead of the actual 
image just makes it more complicated to use above.

More later when I had some time to review.


-----Original Message-----
From: "Kornél Pál" <kornelpal at hotmail.com>
To: <mono-devel-list at lists.ximian.com>
Date: 22 September, 2005 05:54
Subject: [Mono-dev] [PATCH] Win32 Shell Icons in MWF with high level 
systemicon abstraction layer in XplatUI

>Originally I only wanted to create a shell icon handler for Windows but it
>figured out that the current abstraction of icon handling is not abstract
>enough. So I created a new abstraction in XplatUI that is based on file 
>rather than on MIME type. And I added special icon handling that can 
>system specific icons for OpenFileDialog for example.
>Please review the patch and please approve it.
>Note that special icons should either mapped to KDE and GNOME icons or
>resources from Default handler should be used in MimeIconEngine. I didn't
>implement this. Unless it will be implemented unknown/unknown icon will be
>used for undefined special icons. Optionally and open folter icon could be
>implemented in MimeIconEngine as well by using directory/open for example.
>This is the expected behaviour of ImageList and is required by the other
>ImageList.cs: Modified to copy Images when adding or getting them.
>System.Windows.Forms.dll.sources: Added SizedIcons.cs and
>XplatUIStructs.cs: Added SpecialIcons enumeration.
>XplatUIDriver.cs: Added LargeIcons, SmallIcons, GetIconIndex and
>GetSpecialIconIndex for system icon handling. Default implementation uses
>XplatUI.cs: Added LargeIcons, SmallIcons, GetIconIndex and
>Win32ShellIcons.cs: New shell icon handler for Windows. Supports 32-bit
>icons with alpha channel and caches system image list icons in managed
>ImageLists to provide compatibility with ListView.
>XplatUIWin32.cs: Implemented LargeIcons, SmallIcons, GetIconIndex and
>GetSpecialIconIndex using Win32ShellIcons.
>SizedIcons.cs: New icon handler that wraps XplatUI icon handler and 
>ImageLists with constant size.
>FileDialog.cs: Modified to use XplatUI and SizedIcons instead of
>MimeIconEngine and GetResource.
>MimeIcon.cs: Removed GetIconForMimeTypeAndSize as it is superseded by
>SizedIcons. Removed code that prevented MIME types returned other than
>inode/directory and unknown/unknown when using PlatformDefaultHandler. 
>special icons to PlatformDefaultHandler.
>Mime.cs: Removed code that assumed it is used on Windows.

More information about the Mono-devel-list mailing list