[Pitch] Hex color literals


(Yonas Kolb) #1

Hi Swift Evolution

Color literals in their current state are in practice only useful as an Xcode utility feature, because creating, editing, or reading them in code is a pain.
Currently the only autocomplete provided opens the color picker, which once a color is selected adds something like this to the code: #colorLiteral(red: 0.9254902005, green: 0.2352941185, blue: 0.1019607857, alpha: 1).
Xcode provides a nice color swatch to preview the color, but if viewing this in raw source from a git diff or a 3rd party editor it becomes hard to tell what the color is, or edit it, especially as the rgb components are a fraction of 1 instead of the more readable and standard 1-255.

I propose adding a hex initialiser like this #colorLiteral(hex: “DB8B09", alpha: 0.5). Hex values are the industry standard for colors which makes this feature much easier to use. Now we can actually grok what a color is in source code without reaching for a convertor or calculator, as well as being to define these by simply pasting in hex strings.

Possible alternative to the above syntax could be:

  * hex string param name: #colorLiteral(hexString: "DB8B09", alpha: 1)
  * include alpha as last 2 characters: #colorLiteral(hexString: "DB8B09FF")
  * including #: #colorLiteral(hexString: "#DB8B09", alpha: 1). This should probably be optionally allowed either way.

I’m proposing adding this new hex init in addition to the old one, so it’s still backwards compatible. While outside the scope of swift evolution, the goal would be to get this to also be the default way Xcode would write values from the color picker, as well as being able to render them in the first place.
Having an extra autocomplete with the new init hex would be useful too, so you can just provide a hex string without opening up a color picker, and I don't think this would require xcode support.

I’m unsure if this proposal would require changes in UIColor, NSColor or Xcode, so I’m not even sure this is the right place to propose such a thing.

I haven’t drafted a proposal yet, as I just wanted to check if there was any interest first, or if this is even feasible.


(Paul Neave) #2

This sounds like a positive move but there will probably be problems for wide gamut colors that go beyond 0-1 values. The decimal values for #colorLiteral allow extended RGB values to be set.

Writing an extension can enable passing a hex value into UIColor, such as:

extension UIColor {
  convenience init(hex: UInt32, alpha: CGFloat = 1) {
    self.init(red: CGFloat(UInt8((hex & 0xFF0000) >> 16)) / 0xFF,
      green: CGFloat(UInt8((hex & 0xFF00) >> 8)) / 0xFF,
      blue: CGFloat(UInt8(hex & 0xFF)) / 0xFF,
      alpha: alpha)
  }
}

let color = UIColor(hex: 0xDB8B09)

Paul

···

On 2 May 2017 at 16:55:04, Yonas Kolb via swift-evolution (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) wrote:

Hi Swift Evolution

Color literals in their current state are in practice only useful as an Xcode utility feature, because creating, editing, or reading them in code is a pain.
Currently the only autocomplete provided opens the color picker, which once a color is selected adds something like this to the code: #colorLiteral(red: 0.9254902005, green: 0.2352941185, blue: 0.1019607857, alpha: 1).
Xcode provides a nice color swatch to preview the color, but if viewing this in raw source from a git diff or a 3rd party editor it becomes hard to tell what the color is, or edit it, especially as the rgb components are a fraction of 1 instead of the more readable and standard 1-255.

I propose adding a hex initialiser like this #colorLiteral(hex: “DB8B09", alpha: 0.5). Hex values are the industry standard for colors which makes this feature much easier to use. Now we can actually grok what a color is in source code without reaching for a convertor or calculator, as well as being to define these by simply pasting in hex strings.

Possible alternative to the above syntax could be:
hex string param name: #colorLiteral(hexString: "DB8B09", alpha: 1)
include alpha as last 2 characters: #colorLiteral(hexString: "DB8B09FF")
including #: #colorLiteral(hexString: "#DB8B09", alpha: 1). This should probably be optionally allowed either way.

I’m proposing adding this new hex init in addition to the old one, so it’s still backwards compatible. While outside the scope of swift evolution, the goal would be to get this to also be the default way Xcode would write values from the color picker, as well as being able to render them in the first place.
Having an extra autocomplete with the new init hex would be useful too, so you can just provide a hex string without opening up a color picker, and I don't think this would require xcode support.

I’m unsure if this proposal would require changes in UIColor, NSColor or Xcode, so I’m not even sure this is the right place to propose such a thing.

I haven’t drafted a proposal yet, as I just wanted to check if there was any interest first, or if this is even feasible.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Adrian Zubarev) #3

Besides the fact that those literals are an IDE gimmick supported only by Xcode and Playgrounds (AppCode does not support them) and not compatible with IBDesignable, I personally would recommend to use an UInt32 instead of a String.

#colorLiteral(rgba: 0xDB8B09FF)

···

--
Adrian Zubarev
Sent with Airmail

Am 2. Mai 2017 um 17:55:05, Yonas Kolb via swift-evolution (swift-evolution@swift.org) schrieb:

Hi Swift Evolution

Color literals in their current state are in practice only useful as an Xcode utility feature, because creating, editing, or reading them in code is a pain.
Currently the only autocomplete provided opens the color picker, which once a color is selected adds something like this to the code: #colorLiteral(red: 0.9254902005, green: 0.2352941185, blue: 0.1019607857, alpha: 1).
Xcode provides a nice color swatch to preview the color, but if viewing this in raw source from a git diff or a 3rd party editor it becomes hard to tell what the color is, or edit it, especially as the rgb components are a fraction of 1 instead of the more readable and standard 1-255.

I propose adding a hex initialiser like this #colorLiteral(hex: “DB8B09", alpha: 0.5). Hex values are the industry standard for colors which makes this feature much easier to use. Now we can actually grok what a color is in source code without reaching for a convertor or calculator, as well as being to define these by simply pasting in hex strings.

Possible alternative to the above syntax could be:
hex string param name: #colorLiteral(hexString: "DB8B09", alpha: 1)
include alpha as last 2 characters: #colorLiteral(hexString: "DB8B09FF")
including #: #colorLiteral(hexString: "#DB8B09", alpha: 1). This should probably be optionally allowed either way.

I’m proposing adding this new hex init in addition to the old one, so it’s still backwards compatible. While outside the scope of swift evolution, the goal would be to get this to also be the default way Xcode would write values from the color picker, as well as being able to render them in the first place.
Having an extra autocomplete with the new init hex would be useful too, so you can just provide a hex string without opening up a color picker, and I don't think this would require xcode support.

I’m unsure if this proposal would require changes in UIColor, NSColor or Xcode, so I’m not even sure this is the right place to propose such a thing.

I haven’t drafted a proposal yet, as I just wanted to check if there was any interest first, or if this is even feasible.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution