The Con has now a "colored" flag

[setzer22]

- The flag is set whenever a Con's custom color is set with the color command.
- Whenever the color command is called, the default colors get copied in the
  colorclasses unspecified by the command.
- Instead of checking for color == 0 to see if the color is changed, the colored
  flag is used.

[setzer22]

I had forgotten to push some changes on the first commit.

[Airblader]

I don't really like this approach. Having a boolean flag sounds like duplication to me. The information should be whether there is a color set or not and if there is, use it. Also, this approach doesn't allow only overwriting certain color classes and not others.

I only wrote super ugly in my patch because I just compared one random value against 0 which of course has to be done in a much smarter way. It'd be possible to use a pointer and check it against NULL, for example.

We should discuss this more in the i3 ticket.

[setzer22]

I agree that the possible inconsistencies between the colors themselves and the flag might lead to trouble at some point, but I had already given this some thought and looked like the most clean alternative to me.

The thing is, that if we're to store pointers to colors instead of the colors themselves in the Con to properly check against NULL we should be thinking where the custom colors should be allocated. I don't think having them scattered across the heap is a good idea, that's why I proposed the boolean flag. Maybe some other allocation method could be used, but at this point this approach didn't seem that much of a bad idea, because having a "color-pool" just looks weird to me. Lastly, having both the colors and the pointer inside the Con would essentially be the same as having a boolean flag, or the equivalent to have many boolean flags, one per color, so I don't think it's a better alternative either.

The changes do allow overwritting some colorclasses only, the only problem is default colors are copied instead of referenced from the config. That could only be a problem when resetting i3 with a default color change in-between.

Anyway we should define what happens when i3 resets and the default colors change (or default colors change at runtime in any other way, not sure if there's any).

Even if these changes lead nowhere they helped me as an exercise in becoming familiar with i3 development, so no worries :D.

[Airblader]

Restarting i3 won't be a problem. I left a TODO in my patch saying that we need to dump the con's color properties and read it when we reload the layout. So that should work fine.

I think it makes sense if you work on a good PR (with the rest as discussed in the ticket) and we see what Michael says. There'll just be some iteration necessary, I believe, but that's how development works. :)