Adium

An Introduction to making your own Adium message style

Originally written by Mark Fickett (Perez on the Adium forums) in June 2004 with Adium 0.60 in mind. Quote and take code, but give credit.

Contents

Introduction

This tutorial is several years out of date but is in the process of being updated. If you see something that's odd, unclear, or just plain wrong, please post a message on the  Adium Forums. This is intended as a basic introduction, to get you started, and is not expected to get you to the point of making something as fancy as Renkoo (one of the styles included with Adium). It does not require any previous knowledge of HTML or CSS, but you will learn a bit of how each is used in the construction of an Adium message style. You are expected to have a few things: Mac OS X (at least Panther (10.3)), a text editor, Safari, and a copy of Adium. If not, it should still be enlightening, and you can make it work, but it's easier if you have access to the tools described here.

The philosophy of CSS is to separate content and appearance: HTML is the content, CSS is the appearance. The CSS tells the browser what style it should use for displaying the various elements presented in the HTML. I won't go into more detail; if you want to do more than be able to cobble together a message style (and you should, it's fun!), you would really do better to learn HTML (I recommend looking at peoples' source, seeing what they're doing, and learning from that — with a good reference handy) and CSS (which, as mentioned, is pretty straightforward).

But enough of this: Let's make a message style.

How a Message Style is Put Together

A message style is a directory structured like this: 

<stylename>.AdiumMessageStyle [directory]
	Contents [directory]
		Info.plist Resources [directory]
		Resources [directory]
			Main.css
			Footer.html [optional]
			Header.html [optional]
			Status.html
			Incoming [directory]
				Content.html
				NextContent.html [optional]
				Context.html [optional]
				NextContext.html [optional]
				Buddy_icon.png [optional]
			Outgoing [directory, optional]
				Content.html [optional]
				NextContent.html [optional]
				Context.html [optional]
				NextContext.html [optional]
				Buddy_icon.png [optional]
			Variants [directory, optional]
				PrimaryVariant.css
				SecondaryVariant.css [optional]

Message style Xtras live in ~/Library/Application Support/Adium 2.0/Message Styles/ (where ~/ means your home directory). If you click the "install" link on the Xtras site it then Adium will install it here. If you manually download a new message style, you can simply double-click it. Adium will open, copy it to the correct place, and tell you [if] it worked.

Adium chat windows are, in essence, web pages. Really. The Adium Devs have hooked everything up so that as content flows into Adium, it gets stuck onto the end of the web page in a nice way, but as far as anyone writing a message style cares, it's a web site with a very specific focus.

Adium takes the various HTML documents and appends them as appropriate to the end of the current message. Specifically, when you receive a message, Adium sticks Incoming/Content.html into Template.html (a file the message style author can safely ignore) at the end of the current text; a second message from the same person, and it will add on a copy of Incoming/NextContent.html — in each case, replacing various parts of the HTML (name, message, etc) with the appropriate data for the specific message being sent. Either Main.css or one of the stylesheets found in the variants subfolder are used to determine how the HTML should look.

The various other HTML files are fairly straight forward as to when Adium sticks them in the message window: Status.html is what defines the structure of a status or event message, such as an idle, away, or connect/disconnect. The Incoming and Outgoing directories are for messages coming in (theirs) and going out (yours); often they will be very similar, with probably only the classes of some of the elements different so the CSS can distinguish between them. Content.html and NextContent.html are for normal message content as outlined above; Context.html and NextContext.html are the same thing, but for Adium's MessageHistory.

Making a Style: Getting Ready

So now that you have an understanding of the structure and process, it's time to play with some code. There are two basic options for making a style: finding one that's sort of what you want and modifying it (with the author's permission probably; definitely if you're going to redistribute it) or starting from scratch. It's pretty hard to give specific examples and directions if you're modifying an arbitrary style, so I'm going to do the latter. You can make a style with a text editor (you can use TextEdit, or even Word if you save it as plain text — make sure not to use rich text format, .rtf) or something that knows you're writing HTML and CSS. I would caution you against anything that writes or modifies your code for you, since we won't be writing full HTML documents and you are writing for a very focused "browser" (and it's a better learning experience to write it yourself).

To start out, we need somewhere to put this thing. I'm going to stick mine on the desktop, because it's handy. Then we need to create the directory structure — make the different directories outlined above. Be warned that adding the .AdiumMessageStyle extension will render the directory more difficult to deal with (if you double-click, Adium will try to install it; you have to right-click (control-click) and chose 'show package contents'), so you might want to hold off on that part until you're done.)

And now, all of a sudden, I realize I'm just like my sophomore Chem. teacher: I lied. I'm not really doing this from scratch, because I need a file (and will steal two more just because) that I don't know how to write, offhand: I'm going to filch Info.plist and also snag a buddy_icon.png for the Incoming and Outgoing directories. You can do something fun with the buddy icon files if you want — they appear if your contacts don't have icons, but Info.plist is the only one that we really need to worry about, and we'll get back to it later. For now, grab 2torial.AdiumMessageStyle.zip Download. Download it and, after unzipping, double-click it and Adium will install it into ~/Library/Application Support/Adium 2.0/Message Styles/. Then right-click (or control-click) and select 'show package contents' to see the innards. Find Info.plist} and each copy of buddy_icon.png, and put them where they go (see above).

Making a Style: Writing the HTML

The HTML for a message style doesn't need anything very specific; it just needs to have reasonably logical class attributes. I'm going to write the HTML for Incoming/Content.html like this, to start: 

<div class="incoming">
	<span class="content">
		<span class="buddyicon">
			<img src="%userIconPath%" alt="icon" />
		</span>
		<span class="time">%time% </span>
		<span class="sender">%sender% </span>
		<span class="message">%message% </span>
		<div id="insert"></div>
	</span>
</div>

There are three requirements I'm satisfying with this: content, reasonable structure, and whitespace. The first is easy; I'm just getting in all the pieces that I want to end up with — timestamp, sender's name, icon, and message. (The <div id="insert"></div> is for Adium, so it knows where to put a secondary message. The icon is at the beginning because it's a predictable width, and that will be handy later. And no, I didn't think of that beforehand.)

The second requirement — reasonable structure — is for the CSS. When I want to refer to the timestamp on a first incoming content message, I don't want to have to do anything fancier than I need to; I also don't want to have to specify each separate case where timestamps occur if I decide they should all look the same. The structure also applies to how I've laid it out on the page; I want it to be easy to see, at a glance, that the <span> that contains the time is inside that which specifies content, which is in turn inside the one that specifies incoming.

The last is whitespace, which is why I've used a combination of <span>s and a <div>. Both <span>s and <div>s are generic HTML elements that contain something and let you talk about whatever's inside — text or images in our case. They differ in the default type the browser treats them as, and, relatedly, how text copied out of them looks in a text editor (or pasted into another IM, for example). A division is a block display; when copied (or when you don't tell it to do something else), it starts on a new line and starts a new line after itself. A <span> displays inline by default, and will look and copy just like normal text, along with whatever is on the sides. I used a <div> for the message at large so that each person's message would be on a new line, with a space after the time and sender so time, sender, and message won't run together when copy-pasted.

For the moment, we'll leave the HTML like that; if we decide we want something else we can put it in later if needed for how we want it to look. This particular code goes in Incoming/Content.html. Similar code goes in Incoming/Context.html, except class="content" is changed to class="context". Files similar to each of those two go in Outgoing, except with class="incoming" changed to class="outgoing". Then we need new code for NextContent.html and NextContext.html, which get used if someone sends more than one message in a row (or they did, and it's being displayed as context). I'm going to use this for NextContent.html, with similar code (class="nextcontent" changed to class="nextcontext") for NextContext.html. Note that there doesn't need to be a different version for incoming and outgoing because of the placement of <div id="insert"></div>, which is where the next files end up. 

<br />
<span class="nextcontent">
	<span class="time">%time% </span>
	<span class="message">&raquo; %message%</span>
</span>
<div id="insert"></div>

Lastly, we need HTML for a status message, which will go in Status.html. It looks only a little different from the others: 

<div class="status">
	<span class="%status%">
		<span class="time">%time% </span>
		<span class="message">%message%</span>
	</span>
</div>

Note that the %status% is replaced with a status keyword.

One other file we may want to create for testing purposes is mockup.html, with a fake conversation in it, pasted in from the various files. It would look like this, with the appropriate substitutions — have fun, make up some messages, names, and times, and replace the %userIconPath% keyword with either Incoming/buddy_icon.png or Outgoing/buddy_icon.png as the case warrants. (For this example, put the mockup file in Resources.) Because it gets very long very quickly, I've put the mockup inside the messagestyle itself, so download that if you'd like to take a look at it. The mockup HTML starts out looking like this: 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
	<head>
		<title>Message Style Mockup (2torial)</title>
		<link rel="stylesheet" type="text/css" href="Main.css">
	</head>
	<body>
	<!-- insert scintillating, demonstrative conversation here -->
	</body>
</html>

Everything's there, but it's certainly not an exciting (or even easily readable) view yet. It does, however, look pretty good if you copy-paste into a plain text document. While it is certainly possible to view the mockups in a browser besides Safari, it won't give you an accurate view of how the message style will look. Adium's messagestyles will be rendered by the same engine used by Safari, and no other browser is guaranteed to render the same way. And since we can count on the message style being rendered by WebKit, we don't have to worry about compatibility.

Time for the CSS!

Making a Style: Writing the CSS

Since CSS is all about how the information (defined in the HTML) is displayed, the first job is to decide what the view should look like. Poking around in all the great view on the  Xtras site, I made a list of some of the features I saw that I liked, along with my own ideas/criteria:

  • Subtle icons
  • Little double-arrow things (») for consecutive messages
  • Big, background-ish timestamps for consecutive messages (inspired by  Silverstone)
  • Time and name in little boxes up at the top of the message box (thanks to  Negative for a code-check on how to do this)
  • Semi-transparent message boxes — just for fun — and a subtle background image to show the transparency off
  • Nothing too fancy: This is a tutorial. (No curved message containers, no toggle-able header, etc.)

Given that list, I came up with this mockup.

Now, time to write the CSS. The first thing to do is set up the basic parameters — background, font, size, and text color; links because we may as well have fun while we're doing CSS. Create a (text) file in Resources called Main.css, and start it as follows (or similarly). I recommend you open up your mockup file and reload it as you edit Main.css so you can see what's changing — and do things differently if you feel like it. 

body
{
	background-color: rgba(255, 255, 255, 1);
	background: url(background.png) fixed no-repeat 50px 30px;
	line-height: 12pt;
	color: rgba(0, 0, 0, 1);
	margin: 0px;
}

In the above, body is a  selector (the link goes to Westiv's CSS guide). It tells the browser which part of the HTML — what element — the upcoming CSS is referring to. After the selector, the statements in the curly-braces are what apply to that selector.

For the most part, the statements in CSS are pretty obvious (especially with a good reference handy). It often provides several different ways to achieve the same thing. You should try to do things in such a way that is is easiest for you to understand and maximizes your flexibility. For Example, there are several different ways to specify color. I prefer using the form you see above, but you may want to  read up on your other options. Similarly, it is possible to specify the background color in the same statement as the other background attributes. However, I find it easier to specify color in a separate statement, especially when I'm l.

This is a good place to mention that there are many different techniques for "optimizing" html and css. You want to avoid most of them. While each Adium chat windows is a miniature web page, things like loading time aren't a factor. Most optimization techniques will only make you slower when you are looking at the code a year later trying to figure out why something doesn't look quite like you expected, or when you decide to adjust a minor parameter but have to work harder not only to find it, but then have to restructure things just to make the change.

The background image is specified by its relative url in url(background.png), and then its repeat after that (the other options being repeat-y, repeat-x, and repeat, defaulting to the last). The background's position is specified as 10 pixels down from the top and 30 pixels out from the edge; there are lots of  other ways to specify similar things. (I just used the flap.png file tucked away in Adium.app and made it grayscale and lighter.) The last line makes sure I know what to expect for the edge of my workspace, so when I set margins for the message boxes I have my reference point right; a browser window usually comes with some margin and/or padding that keeps text from being right up against the edge of the window.

Next, just because, I'll do links (without a lot of explanation — see  Westiv for full coverage). 

a:link
{
	color: rgba(85, 85, 136, 1);
	text-decoration: underline;
}

a:hover
{
	color: rgba(102, 102, 153, 1);
	text-decoration: underline;
}

a:active
{
	color: rgba(119, 119, 170, 1);
	text-decoration: underline;
}

The first line of this next little snippet I don't really understand, as to why it's necessary, but it makes another aspect of CSS act the way I want and expect; Westiv states that absolute positioning "lets a developer say where the top left hand corner of an element should be located with respect to its parent element." Unfortunately, this is not so by default; only if the parent element in question has had its display set — I'm using relative because it doesn't have any effect at all (for some reason fixed, the default, does). Anyway, the following lets me position the internal elements of the messages (be they peoples' or status notifications') absolutely — put them wherever I please, exactly.

The second line is so that if you get a long link, the URL will make a scrollbar happen, instead of just waltzing out off the right side of the window.

The selectors in this case refer to the class="incoming" (or outgoing, or status) in the HTML. 

.incoming,
.outgoing,
.status
{
	position: relative;
}

.message
{
	overflow: auto;
	padding-right: 1px;
}

Next, let's set up the basic flow and appearance of the document: the boxes in which the various messages reside. These are things with a class of incoming, outgoing, and status. The two smaller pieces which will look similar have classes of sender and time. We aren't worried that some of the times won't be in little boxes (as we're about to specify), because we can always contradict ourselves by saying something later and/or more specific. The CSS looks like this: 

.incoming,
.outgoing
{
	margin-top: 12px;
	margin-right: 10px;
	margin-bottom: 8px;
	margin-left: 10px;
}

.status
{
	margin-top: 8px;
	margin-right: 25px;
	margin-bottom: 8px;
	margin-left: 29px;
}

.incoming,
.outgoing,
.status,
.sender,
.time
{
	border-color: rgba(204,204,204,.25);
	border: 1px solid;
	background-color: rgba(255,255,255,.25);
}

The incoming and outgoing messages will be laid out on the page the same way: a margin of 12 pixels on the top, 10 pixels on each side, and 8 pixels underneath. (More room on the top for the sender and time boxes, which protrude). The status containers' margins have the same margin of 8 pixels top and bottom, and larger margins left and right. (Here's some evidence of my having worked out the message view beforehand, and come back to explain the CSS later: those side margins are so that the status messages' senders and times will line up with those of the regular incoming and outgoing messages. And no, I didn't write it all perfectly in one pass; I rewrote the CSS once, totally, and revised both CSS and HTML a couple times.)

Finally, we want all these parts we've been talking about (selecting) to be semi-transparent boxes with light grey (rgba(204,204,204,.25)) borders. Borders can also be dashed, dotted, different widths, etc. The background is specified as red, green, blue, and alpha channels; the range for the RGB part is 0 to 255, so it's white, and 25% opaque. While we're on the subject, let's put the sender and time <span>s where they go. We want to position them absolutely with respect to their parent element (the incoming or outgoing message box). The tops should be a few pixels above the top of the message box (-6px down) for both of them, the text should be lighter than the actual message text, and there should be a little padding (3 pixels) on the sides, though we don't need any for the top and bottom. Padding and margins can be specified in several ways. For the same of easy understanding and changing I prefer to make separate statements for one side (top, right, bottom, left) unless I'm using the same value for every side ( as I did in the body) And remember — padding is inside, margins are outside. If in doubt, stick a border on whatever you're playing with, and see what it's doing.)

The specific alignment of the sender and time are different only in left- and right- alignment. The sender <span>'s left edge should be (oh, offhand) 18 pixels out from the left edge of the message container; the time should have its right edge 14 pixels from the right edge of that same parent container. 

.sender,
.time
{
	position: absolute;
	top: -6px;
	color: rgba(102, 102, 102, 1);
	padding-top: 0px;
	padding-right: 3px;
	padding-bottom: 0px;
	padding-left: 3px;
}

.sender
{
	left: 18px;
}

.time
{
	right: 14px;
}

As long as we're talking about times, it has become clear that something bad has happened to the times in the status containers (.status .time selects things with class="time" inside class="status"). We want them to be, not up-and-in, but aligned with the outside of the 1-pixel border on the status container, so they blend in. 

.status .time
{
	top: -1px;
	right: -1px;
}

Next up, let's deal with those unsightly icons (and make them a little more sightly). 

.buddyicon
{
	position: absolute;
	top: 4px;
	left: 4px;
	width: 32px;
	height: 32px;
	opacity: .25;
	z-index: -1;
}

.buddyicon img
{
	width: 32px;
	height: 32px;
}

We want all the pieces involved — the icon image itself (another 'child' selector on the last line there), and its container — to be 32x32 pixels. The icon is 4 pixels down and to the right from the top left corner of the message container; it should also be 'lower' than the other contents of the message container (z-index: -1). 

.message
{
	display: block;
}

.status .message
{
	margin-top: 0px;
	margin-right: 5px;
	margin-bottom: 0px;
	margin-left: 5px;
}

.away_message .message
{
	margin-top: 0px;
	margin-right: 5px;
	margin-bottom: 3px;
	margin-left: 5px;
}

This chunk of code deals with the actual messages inside status containers generally and then (because they're different) away message containers. (Recall that we get this distinction from the %status% keyword.) We want a little padding to the sides of status messages, though we don't need any to the top or bottom, and the display: block is so that if the message is more than one line long, lines after the first also get padded away from the sides. (We want this to be the case for all messages, so it's a separate selection.) For away messages, we want a little extra padding on the bottom, just because it looks better.

Now it's time to deal with the content (and context) messages, which have until now been flapping in the wind. They've already been told to act like blocks, so we don't have to do that again; we just need to set up the margins so they sit where we want 'em. 

.content .message,
.context .message
{
	margin-top: 15px;
	margin-right: 4px;
	margin-bottom: 10px;
	margin-left: 4px;
}

.nextcontent .message,
.nextcontext .message
{
	margin-top: -25px;
	margin-right: 4px;
	margin-bottom: 10px;
	margin-left: 5px;
}

Why such strange margins? Because I couldn't make min-height do anything. Therefore, the first message must be tall enough to stretch the message container so that the icon appears entirely inside it, with a comfortable bottom margin — and then consecutive messages have to make up for that ridiculous bottom margin (but retain it themselves, so that later consecutive messages, which will have the same big negative margin, get in the right place).

Now, recall how we were going to have cool, big, in-the-background, greyed-out times for consecutive messages? It's time for that. 

.nextcontent .time,
.nextcontext .time,
.away_message .time
{
	border: none;
	background-color: rgba(255,255,255,0);
	color: rgba(204, 204, 204, 1);
	font-weight: bold;
	font-size: 18px;
	z-index: -1;
}

.nextcontent .time,
.nextcontext .time
{
	position: relative;
	float: right;
	top: -24px;
	right: 20px;
	height: 11px;
}

.away_message .time
{
	top: 15%;
	right: 8px;
}

First, let's define the general appearance (and make away messages' times look like that too, since they usually come right after a 'so-and-so went away' notification and we don't really need the timestamp). We have to undo the border we put around all times and take off the background we put behind the same things (noticeable to varying degrees depending on background) a while back, make these times especially lighter, bolder, and bigger, and stick 'em in the background (like we did for icons).

The positioning for nexts' times is different from that of away messages', so we do them separately. We want them to be on the right (float: right makes an element 'float' to the right end of the code in its parent element, so in this case the class="time" will be the last, and therefore rightmost, element in the class="next*" (content or context) container). Then we want to push them around a little bit relative to where they would be otherwise; up 24 pixels (see what those nasty margins on the next messages are doing to us?) and out 20 pixels. The height specification is so that the times don't run into each other; even though the text doesn't actually touch, the containers are too big otherwise, and the times push each other around. (If you want to play around with snipping out parts of the times, fiddle with overflow: hidden and height.)

Away messages' times are different, because it's more fun if they can be further down for multi-line away messages. They are, therefore, left as position: absolute, and the top is specified as a percentage, not a pixel-value. They're also a little closer to the right edge.

Now that everything's (more or less) where we want it, let's tweak how it looks a little: time to take advantage of the %status% keyword. 

.status .message
{
	color: rgba(102, 102, 102, 1);
}

.online .message
{
	color: rgba(102, 136, 102, 1);
}

.offline .message
{
	color: rgba(136, 102, 102, 1);
}

.away .message,
.return_away .message
{
	color: rgba(136, 136, 102, 1);
}

.away_message .message
{
	color: rgba(102, 102, 85, 1);
}

.idle .message,
.return_idle .message
{
	color: rgba(136, 136, 136, 1);
}

.date_separator .message
{
	color: rgba(68, 68, 68, 1);
}

This should be pretty self-explanatory at this point.

Lastly, let's make the context message look different from regular content — a little faded out. 

.context .message
{
	color: rgba(136, 136, 136, 1);
}

.context .buddyicon
{
	opacity: .1;
}

First, the messages themselves are lightened. (Note that this gets overridden if the person you're chatting with happens to use some specific color.) Then we make the icon a little less opaque — 10% works for me.

That's it for now — but feel free (and encouraged) to tweak it to your liking. Maybe you prefer colored senders' names, and want .incoming .sender and .outgoing .sender to be different colors. Maybe you don't want to see icons at all (display: none for the appropriate classes). Or maybe you just want to make the whole thing a little less subtle. Depending on how sweeping your changes, you might just want to make a variant.

Info.plist (I)

Before we can get Adium to talk to our message style, we have to give it a proper introduction. For starters we need to give our style a name and make the default font family, default font size, and the default background match what we chose earlier. So open up Info.plist in a text editor, and let's change some keys.

Here's what I'm doing: Skip MessageViewVersion, change the CFBundleIdentifier to 2torial.style, change CFBundleName to 2torial, change CFBundleGetInfoString to 1.0, change the DefaultFontFamily to Arial, and (as it happens) leave DefaultFontSize and DefaultBackgroundColor as they are. Just to be sure, here's what mine looks like now: 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
	<dict>
		<key>MessageViewVersion</key>
		<integer>4</integer>
		<key>CFBundleIdentifier</key>
		<string>2torial.style</string>
		<key>CFBundleName</key>
		<string>2torial</string>
		<key>CFBundleGetInfoString</key>
		<string>1.0</string>
		<key>DefaultFontFamily</key>
		<string>Arial</string>
		<key>DefaultFontSize</key>
		<integer>10</integer>
		<key>DefaultBackgroundColor</key>
		<string>FFFFFF</string>
	</dict>
</plist>

Yours may well have a more interesting title, a different font, things like that — just so long as the fields are filled in usefully. (I'm purposefully ignoring all the variant stuff until we've gone and made a variant to play with.

Making a Variant

The variant I'm going to go through making is just a dark version — complete with an Evil Duck background. As I've been saying, feel very free to do your own thing, and just refer here for how it's done.

In order to make a variant, we need the directory Resources/Variants, if it's not already there, and in it the CSS file for the variant — for this example, we'll call it BlackBackground.css.

(You may also want to make a new copy of the mockup file in which (if it's in Resources) references Variants/BlackBackground.css; that is, the mockup file should be the same as the other(s) but modified so that the stylesheet line reads <link rel="stylesheet" type="text/css" href="Variants/BlackBackground.css" />. Again, here's my mockup Download.)

Then we need to edit the CSS file, the first line of which is this: 

@import url(../Main.css);

The @import imports the file Main.css in the directory one level up, in Resources, which means we don't have to rewrite (or even copy) all the positioning code — just the things that are different between the original version and the variant.

After that, the CSS launches right into changing stuff around. In general, we want a black background with (I decided) a nice silhouette of the Evil Duck, scourge of the night that he is. (Since I made the image as a mostly-transparent PNG, it should show up well on any near-black background, though it's almost invisible against white.) 

body
{
	color: rgba(255, 255, 255, 1);
	background-color: rgba(0, 0, 0, 1);
	background: url(evilduckmask.png) left bottom fixed no-repeat;
}

This time, I specified the placement of the background image using the keywords left bottom, since I think that's where the silhouette looks best, instead of the top/left offset values in pixels I used before.

The most glaring fault with the new background is that all the boxes are the wrong color: they stand out as light, look layered atop each other, and have none-too-subtle borders. 

.incoming,
.outgoing,
.status,
.time,
.sender
{
	border-color: rgba(34, 34, 34, 1);
	border: 1px solid;
	background: rgba(0,0,0,.5);
}

So, selecting the box-like elements, let's make their borders darker and make the backgrounds 50% opaque black.

After that, it's the big and bold next times which show up as very wrong. 

.nextcontent .time,
.nextcontext .time,
.away_message .time
{
	color: rgba(51, 51, 51, 1);
	border: none;
}

To fix them, we lighten the text color and (since we just put the border back from the original @imported state) strip off the borders.

Finally, let's make the faded icons blend in with our new black background, — the 50% opaque for normal messages, and 25% opaque for the context messages. 

.buddyicon
{
	opacity: .5;
}

.context .buddyicon
{
	opacity: .25;
}

Although the variant isn't totally beautiful, it's workable, and all the major changes have been made. I'll leave the tweaking up to Dear Reader, so you can have something all your very own (and I don't have to do it). (If you come up with a variant you really like, send a note my way and I'll probably be happy to include it.)

Info.plist (II)

Now that we have a variant (I told you we'd get back to that reference to variants we ignored), we can fill in a little more of Info.plist. Referencing the list of available keys, there are a couple things we might (and do) want to add, the first of which is a variant-specific setting. Open up Info.plist again, however you did it before, and just after DefaultBackgroundColor (or anywhere else, but I feel like putting it there), add in: 

<key>DefaultBackgroundColor:BlackBackground</key>
<string>000000</string>

That should do it, since we already named the CSS file BlackBackground.css. Because "normal" sending colors (say, black) just plain aren't going to be visible on your default background" we should also set AllowTextColors to false. 

<key>AllowTextColors:BlackBackground</key>
<false/>

We also need to make sure the default style has a useful name in the sub-menu (WhiteBackground sounds likely). To do this create a new file in Variants named WhiteBackground.css. This file only needs to contain the following: 

@import url(../Main.css);

All done! Now, go make your own variant, or style, and have fun! And feel free to post questions, comments, suggestions, etc to  the Adium forums.

Submitting Xtras

Depending on how much you've departed from my example, or if you've followed this and then gone and done your own, you may have a message style that you want to post on the  Adium Xtras site. The submission process is simple: Go to the Xtras site, click and click on the "Submit" tab, then on  Sign up now! After you've registered, confirmed by e-mail, and logged in (back at the "Submit" tab, or using the Log In link at the bottom of every page), the "Contribute" tab will let you submit the Xtra. For a message style, you can submit:

  • The Adium message style itself
  • Title, description, credits, version number
  • Previews
  • Thumbnail

If you don't have the non-required bits ready, you can go ahead and submit your Xtra, and then come back and update the listing (in the "My Xtras" tab) when you've got them ready.

Resources

These are links which you may find useful in getting more information for making message styles (or writing HTML/CSS in general). Most of them appeared in the text of the tutorial.

Attachments

Page last modified by zacw, 3 years ago