Hi,
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
makes
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.
Kornél
----- Original Message -----
From: "Peter Dennis Bartok" <[EMAIL PROTECTED]>
To: "Kornél Pál" <[EMAIL PROTECTED]>; <mono-devel-list@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
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
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
