[Mono-dev] [PATCH] Win32 Shell Icons in MWF with high levelsystemicon abstraction layer in XplatUI
kornelpal at hotmail.com
Thu Sep 22 13:34:38 EDT 2005
Some comments on the things you have written:
Using ImageList is the best solution as ListView only accepts ImageLists.
This means that if we return Images then we have to store them in an
internal ImageList. As MimeIconEngine and Windows Shell stores file icons in
ImageLists the most effective solution is to use these ImageLists directly.
This entire solution is internal to MWF so there should be no problem. Note
that system image list of Windows Shell is exposed outside of Shell and you
could modify it if you want so this solution is still more safe.:)
And if you look at system icon consumers you will see that only 5 Buttons
need Images while thousends of ListView and if we implement icon handling in
folder browser hunderds of TreeView items as well need ImageLists. So it's
easier to get Images from ImageLists for that 5 button than adding hundereds
of Images to ImageLists. In the latter case we should take care about index
mapping as well (like in SizedIcons). Note that I think those buttons should
be replaced by a single ToolBar that uses ImageList as well.
Moving things to themes is simple as icon handling functions can be added to
the theme interface as well that can either use XplatUI or provide it's own
implementation. As functions in Theme will have the same signature as in
XplatUI this change can be made only by changing XplatUI... to
ThemeEngine.Current... in the code. This change can be done at any time so I
think we should do it only when it will be needed as our needs may change
when we will be about to do such things.
Using the same indexes for large and small icons seems to be the best
solution so we don't need separate functions or flags. Both MimeIconEngine
and Windows Shell loads and chaches large and small icons in a single step.
And if ListView items weren't reloaded from file system if you change view
using same indexes could save time.
The directory flag comes from the current MimeIconEngine based solution if
MimeIconEngine checks for directories there is no use to have that flag. I
simply don't wanted to mess up MimeIconEngine.
You did not mention the open flag but I think that should stay because it
lists more cool and more Windows-like if the currently open folder has open
icon. And I think open folder icon exists in KDE and GNOME as well.
----- Original Message -----
From: "Peter Dennis Bartok" <peter at novonyx.com>
To: "Kornél Pál" <kornelpal at hotmail.com>; <mono-devel-list at lists.ximian.com>
Sent: Thursday, September 22, 2005 5:29 PM
Subject: Re: [Mono-dev] [PATCH] Win32 Shell Icons in MWF with high
levelsystemicon abstraction layer in XplatUI
> Thanks for all the work you put into the patch. I did a quick review, I
> need more time before approving it. One thing that already know needs to
> 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
> to call into the theme to get them. The theme then has the choice of
> 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
> 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
> 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.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list