--===============1697961978==
Content-Type: multipart/signed;
  boundary="nextPart1267259.cSKsNGVoNG";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1267259.cSKsNGVoNG
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

I'm on a bit of a Q3 and K3 cleanup drive at the moment. I'm writing to ask=
=20
what properties from the old KIcon (now known as K3Icon) we want to retain =
in=20
Qt4.  Here's a refresher:

    /**
     * The group of the icon.
     */
    enum Group {
	/// No group
	NoGroup=3D-1,
	/// Desktop icons
	Desktop=3D0,
	/// First group
	FirstGroup=3D0,
	/// 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=20
different icon for a specific icon name on the toolbar vs on the desktop vs=
=20
on the panel etc.

Do we want to keep this distinction anymore?  I.e., is there an interest in=
=20
providing different icons for a specific named icon in different situations=
 -=20
was it even used much in KDE < 4?


    /**
     * These are the standard sizes for icons.
     */
    enum StdSizes {
        /// small icons for menu entries
        SizeSmall=3D16,
        /// slightly larger small icons for toolbars, panels, etc
        SizeSmallMedium=3D22,
        /// medium sized icons for the desktop
        SizeMedium=3D32,
        /// large sized icons for the panel
        SizeLarge=3D48,
        /// huge sized icons for iconviews
        SizeHuge=3D64,
        /// enormous sized icons for iconviews
        SizeEnormous=3D128
    };

Now that KIcon is a size-independent representation of an icon, I think the=
se=20
sizes are irrelevant - any disagreements?

    /**
     * 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 }

=2E. so I can't see any reason to keep this.


    /**
     * 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=3D0x100, ///< a file is locked
      ZipOverlay=3D0x200,  ///< a file is zipped
      LinkOverlay=3D0x400, ///< a file is a link
      HiddenOverlay=3D0x800, ///< a file is hidden
      ShareOverlay=3D0x1000, ///< a file is shared
      OverlayMask =3D ~0xff
    };

Overlays are not supported by QIcon, so I would imagine that this will stay=
=20
(and get moved to KIcon).  Is the current list of overlays comprehensive=20
enough?

Any other ideas for improvements in KIcon also welcome...

Cheers,
Hamish

PS.  I am not subscribed, so please cc me

--nextPart1267259.cSKsNGVoNG
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBFOv4gH8BtnSmIlUYRAueXAKCnwbrKgKLKTkpj4cRJaK4Rqhp7/gCg0zKF
gUId5yAA6YoXIEs+4ij081I=
=q2Tt
-----END PGP SIGNATURE-----

--nextPart1267259.cSKsNGVoNG--

--===============1697961978==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1697961978==--