Kornel, 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. Cheers, Peter -----Original Message----- From: "Kornél Pál" <[EMAIL PROTECTED]> To: <mono-devel-list@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 >Hi, > >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 >name >rather than on MIME type. And I added special icon handling that can >provide >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 >patch: > >ImageList.cs: Modified to copy Images when adding or getting them. > >ChangeLog: > >System.Windows.Forms.dll.sources: Added SizedIcons.cs and >Win32ShellIcons.cs. > >XplatUIStructs.cs: Added SpecialIcons enumeration. > >XplatUIDriver.cs: Added LargeIcons, SmallIcons, GetIconIndex and >GetSpecialIconIndex for system icon handling. Default implementation uses >MimeIconEngine. > >XplatUI.cs: Added LargeIcons, SmallIcons, GetIconIndex and >GetSpecialIconIndex. > >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 >provides >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. >Added >special icons to PlatformDefaultHandler. > >Mime.cs: Removed code that assumed it is used on Windows. > >Kornél > _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
