Hi, I attached a patch that does what I want. Note that however this patch is far from final but it's functionality complete. Only the code should be cleaned up and reorganized.
As you can see it's quite easy to use system image list. The only unusual thing is that small, normal and large icons are returned in size accoring to the last call to SHGetFileInfo so there has to be different normal and small size GetSystemIconIndex method. There are three icon sizes in most recent versions of Windows but ListView only supports two sizes so I decided to use 16x16 and 32x32. My first problem is that the current abstarction of icon handling is not abstract enough. As you can see Windows returns icon indices based on the file name, but independently from mime type. In addition directories can have their own icons. This means that there should be a more abstract, path based icon handling abstraction. On Windows icons of shell folders (Desktop, My Documents, My Computer, ...) can be obtained as well so I think these well known folders should have functions in the abstraction. For example: GetDesktopIcon() I don't want/need to modify ImageList to use native Windows image lists but ImageList is sealed, has no specific base class, and is required by ListView. This means that system image list handling can only be implemented in ImageList. Either using if's or using different implementation classes that are wrapped by ImageList. Note that the current system image list implementation is minimalistic and it should be a fully functional read-only image list for theming compatibility. That's the cause I asked what to do with ImageList. And I want to create a more abstract icon handler as the current MIME type based is too specific. Kornél ----- Original Message ----- From: "Jordi Mas" <[EMAIL PROTECTED]> To: "Kornél Pál" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Tuesday, September 13, 2005 10:28 PM Subject: Re: [Mono-winforms-list] Implementing file icons on Windows
El dt 13 de 09 del 2005 a les 13:40 +0200, en/na Kornél Pál va escriure:Hi, Unlike Linux, Windows associates icons based on extension and optionally on custom icon handler DLLs and don't care about MIME types. I want to implement icon handling using SHGetFileInfo and system image list. This meas however that I have to modify ImageList to use and interface based multi-implementation design like our theming system because system image list is a native Windows image list. Is it OK to to so?Kornél, keep in mind that this is a "managed" Windows implementation of System.Windows.Forms. We are trying to share as maximum as possible between platforms. I think that is better if you come up with a way where adding little code to the already existing managed implementation you can archive what you need specifically for Win32. Re-implementing ImageList and having separate implementations I do not think is an option and will break our current design. Can you please explain a bit more that you need, which members and behaviour of ImageList will affect? Thanks Kornél, Jordi, -- Jordi Mas i Hernàndez - Mono development team - http://www.mono-project.com Homepage and LiveJournal at http://www.softcatala.org/~jmas _______________________________________________ Mono-winforms-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-winforms-list
WindowsIcons.diff
Description: Binary data
_______________________________________________ Mono-winforms-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-winforms-list
