Redesign Fonts and Colors handling to be not confusing

Peter's mock-up of a Text Inspector panel.

How the text inspector works:

Setting the plain-text fonts

The plain-text font is used for the display of plain-text.

1. Go to Preferences→Messages.
2. Click “Configure Incoming Plain-Text Font” or “Configure Outgoing Plain-Text Font”.
3. Operate the Text Inspector.

The Reset buttons are never enabled in this case.

Setting the current font of the selection, overidding the plain-text font

1. Be in an inputline or status field.
2. Choose “Text Inspector” from the Format menu.
3. Operate the Text Inspector.

The Reset buttons are enabled when the relevant attribute is present in the selection. Thus, for example, the fgcolor Reset button is not enabled when the selection does not possess a fgcolor.

Advantages

• It is possible to set the font and/or fgcolor and/or bgcolor to be the same as the plain-text font, but explicit rather than display-only.
• Totally unambiguous.

Disadvantages

• No UI precedent.
  • OTOH, there's also no UI precedent for having plain and rich text in the same field. IMO, we can do whatever we want here—the only test is what makes sense to the users.

Other points

• Wording of “Foreground [color]”—could be “Text” instead.
• Wording of “Configure (Incoming|Outgoing) Plain-Text Font” buttons is subject to change.
• When no message or status field is in the responder change, the contents of the Text Inspector (which is non-resizable) change to “Nothing to Inspect”.

Also, see CFM's mock-up on #1882.

Part of me feels that #3234 is relevant/related to this ticket.

The inspector mockup currently misuses radio buttons to set a context for the rest of the window; in my opinion it should be using tabs instead.

Preferences pane allowing user to set custom colors

I added a new file - duboisj.ColorPrefsWindow.png. This is what I put together for allowing the user to customize colors. The labels on the UI could be improved to make it more clear what the colors are set for. The advantage to having the color picker here is that when the user attempts to set prefs from the prefs pane, they see right away what the changes will be in the preview.

This way, if the user sets a custom background (a custom image or an unusual color), it is easy to pick fonts for messages that will show up well.

Some functionality should be added, IMO, such as the ability to determine which color 'wins' if there is a message coming over the wire in something other than the default color. Maybe a discussion on the developer list will help determine the optimal behavior?

There was something recently on adium-devl discussing this... did it bear any fruit?

There wasn't a lot in the way of conversation, and I set it aside for a couple of weeks. I had it working for a while, then let the code rot for a week or two. Yesterday afternoon, after I saw discussion of the next beta release going out, I checked out the latest and started merging some changes into that. I won't try to check it into the next beta, but I will submit the patch after the beta, or the release, is out the door.

Excellent, we'll leave it at 1.4 then for now, if someone wishes to bring it forward then we can always change that later.