[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-artists
Subject:    Re: [kde-artists] KIcon
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2006-10-22 6:51:01
Message-ID: 453B14D5.6090607 () acm ! org
[Download RAW message or body]

Hamish Rodda wrote:
> Hi,
> 
> I'm on a bit of a Q3 and K3 cleanup drive at the moment. I'm writing to ask 
> what properties from the old KIcon (now known as K3Icon) we want to retain in 
> Qt4.  Here's a refresher:
> 
>     /**
>      * The group of the icon.
>      */
>     enum Group {
> 	/// No group
> 	NoGroup=-1,
> 	/// Desktop icons
> 	Desktop=0,
> 	/// First group
> 	FirstGroup=0,
> 	/// Toolbar icons
> 	Toolbar,
> 	/// Main toolbar icons
>         MainToolbar,
> 	/// Small icons
> 	Small,
> 	/// Panel (Kicker) icons
> 	Panel,
> 	/// Last group
> 	LastGroup,
> 	/// User icons
> 	User
>    };
> 
> With this, icons can be assigned to groups, so (iirc) you could have a 
> different icon for a specific icon name on the toolbar vs on the desktop vs 
> on the panel etc.
> 
> Do we want to keep this distinction anymore?  I.e., is there an interest in 
> providing different icons for a specific named icon in different situations - 
> was it even used much in KDE < 4?
> 
AFAIK, we currently make no use of this property, so I would drop it.

[OT] I have also wondered what use the different subdirectories:

	actions
	apps
	devices
	filesystems
	mimetypes
	stock

are put to??
> 
>     /**
>      * These are the standard sizes for icons.
>      */
>     enum StdSizes {
>         /// small icons for menu entries
>         SizeSmall=16,
>         /// slightly larger small icons for toolbars, panels, etc
>         SizeSmallMedium=22,
>         /// medium sized icons for the desktop
>         SizeMedium=32,
>         /// large sized icons for the panel
>         SizeLarge=48,
>         /// huge sized icons for iconviews
>         SizeHuge=64,
>         /// enormous sized icons for iconviews
>         SizeEnormous=128
>     };
> 
> Now that KIcon is a size-independent representation of an icon, I think these 
> sizes are irrelevant - any disagreements?
> 
Yes, the icon selection should be independent of size -- that is, they 
should all be the same as long as you can find a suitable sized one.

>     /**
>      * Defines the possible states of an icon.
>      */
>     enum States { DefaultState, ///< The default state.
> 		  ActiveState,  ///< Icon is active.
> 		  DisabledState, ///< Icon is disabled.
> 		  LastState      ///< Last state (last constant)
>     };
> 
> QIcon (from which KIcon is derived) provides this already:
> enum QIcon::Mode { Normal, Disabled, Active, Selected }
> 
> .. so I can't see any reason to keep this.
> 
This is clearly obsolete since KDE now generates these states on the fly.
> 
>     /**
>      * This defines an overlay, a semi-transparent image that is
>      * projected onto the icon. They are used to show that the file
>      * represented by the icon is, for example, locked, zipped or hidden.
>      */
>     enum Overlays {
>       LockOverlay=0x100, ///< a file is locked
>       ZipOverlay=0x200,  ///< a file is zipped
>       LinkOverlay=0x400, ///< a file is a link
>       HiddenOverlay=0x800, ///< a file is hidden
>       ShareOverlay=0x1000, ///< a file is shared
>       OverlayMask = ~0xff
>     };
> 
> Overlays are not supported by QIcon, so I would imagine that this will stay 
> (and get moved to KIcon).  Is the current list of overlays comprehensive 
> enough?

I note that I have noticed that "link" doesn't always work.

> Any other ideas for improvements in KIcon also welcome...
>
I would like to see icons such as the attached created by overlay rather 
than having to have an icon for each one.

-- 
JRT

["folder_document.png" (image/png)]
["folder_home.png" (image/png)]
["folder_personal.png" (image/png)]
["folder_video.png" (image/png)]

______________________________________________________________________________
kde-artists@kde.org |  https://mail.kde.org/mailman/listinfo/kde-artists


[prev in list] [next in list] [prev in thread] [next in thread]