Creating Custom Skins For RealOne
Tutorial:
Customizing the RealOne Player
Contents
The Über-Remote
Your TV has a remote. So do your TiVo, VCR and DVD player. All told, your coffee-table command center has enough buttons to launch Sputnik, but chances are that you rarely make use of more than two or three buttons per remote. The rest of the buttons control features that you'll rarely -- if ever -- use. All that idle controller capacity in your living room is eating into your usable coffee-table real-estate.
If you're a turbo-nerd, you might go out and buy a customizable LCD touchscreen remote, program a few strategic and ergonomic buttons and prune your remote-control thicket to a single, elegant stalk of backlit liquid-crystal. The Uber-remote would be just big enough to accomodate all your favorite features, keyed to the contours of your hand and the fit of your life.
Such systems are the playthings of zillionaires, hi-fi nuts, and X.10 hobbyists, not mortal computer geeks.
No, we're more concerned with our screen real-estate. Pixel-for-pixel, your computer's display is worth far more than even the swankiest James Bond penthouse. It doesn't take much effort to plaster your desktop with MP3 controllers, newsfeeds and webcasts, each noisesome mediafeed greedily gobbling pixels that could be more usefully occupied by Web pages, code, tool-palettes, email and word-processors.
That's where skins come in. Skins allow you to create a virtual super-remote, a single, compact command center to manage all of your streams and feeds. Skins are surprisingly easy to build. The skin you use defines the look and behavior of your media-player of choice.
Skin Basics
In this article, we'll show you how to create custom skins for RealOne. RealOne is the successor to both RealPlayer and RealJukebox, and uses the same skin format as RealJukebox.
Every media-player needs its own skin -- you can't combine all your media-players under a single skin. That's because skins aren't just pretty faces: they're application-specific interfaces that need to conform to the competing APIs of the various players.
Skins are nothing more than ZIP-compressed collections of images (for backgrounds and buttons) and a config file (skin.ini), that defines the behaviors of your skin -- play, volume, stop, back and forward, and more.
When you launch your media player, it looks in the folder in the ZIP file for the pieces it needs to assmeble to render and control your skin. The skin.ini file specifies which images are used in the skin, and your player loads those images and displays them according to the specifications set out in the skin.ini file. The skin.ini file is a plain text file, the images can be either .bmp or .jpg files.
No matter what app you're skinning, you'll need the same tools:
RealOne skinning notesStand on the shoulders of giants.:
HTML jocks learn their craft by opening up the source to their favorite Web pages and seeing how they were made. Skinners can do the same: If you find a skin you like, you can rename its extension from .rjs to .zip. Then you can unzip the skin archive and have a look at the skin.ini file and the graphics, learning from those who've come before. Mistakes happen.:
Your first skins will likely be extremely wonky, possibly entirely nonfunctional. If you find yourself stymied by your imperfect handiwork, you can switch back to the default skin by right-clicking anywhere on the skin and selecting "Switch to default skin" from the context menu. Know your player's limits:
RealOne's controls are pretty primitive. Your sliders can only follow straight horizontal or vertical lines, not curves (so forget about making the smile in your happy-face skin into a volume control). Likewise, forget your fantasies of cranking a volume knob up to 11: Real's volume can only be controlled by sliders, not knobs. Previous and Next buttons can be used to skip tracks, but not to fast-forward or rewind within a track (you can use a slider to control play within a track). |
The first step in designing your skin is getting the layout right. A skin's graphics are composed of individual files -- one for the background and one for each of the controls. When it comes time to writing your skin.ini file, you're going to need to know the position of the top-left corner of each control in relation to the top-left corner of the background, and you're going to need to generate composite graphics for each control representing its states.
There are three basic controls: buttons (default and custom), sliders (used to control volume and to skip to different parts of the current track) and status windows that display text about the current track. The different button actions are covered later on, as are the different kinds of information that can be displayed in status windows.
All of your skin's graphics -- buttons, sliders and background -- need to be square, but you can make parts of them transparent by filling regions with pure magenta (255,0,255 in RGB, FF00FF in hex). If you want curved edges, you're going to have to anti-alias the edges to their background. This kind of transparency-fu is old hat to Web-head who've had to do it with GIFs for years -- you can get a good grounding on the subject from reading tutorials like this one.
There is one major difference between transparency for the Web and transparency in a skin, though: Transparent regions in a skin object are not clickable -- they're not just invisible, they're not there.
In this tutorial, we've generated a "curved" background image -- the image itself is square, but the corvers have been masked out with transparent magenta.
This section assumes proficiency in your image editor of choice. Tutorials for Photoshop, the GIMP, and other, suckier editors (like Corel's crapware products) abound on the Web. Editing images is good, addictive fun, but it takes a lot of practice to get right. You probably could use custom skin-design as an excuse to learn the ins and outs of image-editing, but frankly there are easier projects to start with.
Start by designing your background, at the size that you want it to appear.
Now, add your controls, on their own layers. Each control needs its own layer, so that you can easily create the individual files and the button state images.
We used Photoshop, but there are a number of free graphics editors that could do the job.
Your images have to be .bmp files by the time you are done with them, you won't be able to do any advanced graphics work without being in RGB mode.
First, open up your background graphic up in your graphics editor. You'll need to create a new file that has the same dimensions as your background graphic.
Make sure you're in RGB mode so the color and layers features of your graphics program will be enabled.
Now create a new layer and name it "mybackground" to distinguish it from the white "Background" layer that your new file is assigned automatically by default. It is a good idea to create a new layer for your background because only ever want a white "official" background when you are working with a number of different layers.
Now create a new layer and name it "play", "previous" etc. (One for each of your control graphics).
The sample file contains images with the following names; when we were creating it, we used the same names for our layers:
- background.bmp
- play.bmp
- previous.bmp
- stop.bmp
- exit.bmp
- fullmode.bmp
- menu.bmp
- next.bmp
Name those layers!As with any image-editing project, named layers are your best defense against confused, frustrating errors. Avoid the temptation to create a bunch of untitled layers as you work. |
Cut and paste all of your images into layers and move them around using the move tool.
Once you've got everything lined up all nice and kentucky, it's time to measure. Using your image editor's tools (which tool you use varies from editor to editor), measure and note the location of the top-left corner of each of your control graphics.
TK: Infographic, roughly:
<---------------------- 250 ---------------------> 0,0+------------------------------------------------+/+\ | /+\ | | | | | | | | | | | | | | | BACKGROUND | | | 100 | | | | | | | | | | |150 | | | | | | | | \+/ | | | <-- 20 --> +------+ | | | | | | | | | play | | | | | | | | | +------+ |\+/ | | +------------------------------------------------+250,150
The play button's top left corner is at 20,100, relative to the background.
Once you're done, you'll end up with a list like this:
PLAY: 52,20STOP: 86,20PREVIOUS: 120,20NEXT: 154,20MENU: 222,20EXIT: 290,22FULLMODE: 231,60
Save that list, you'll need it when you work on the skin.ini file.
RealOne's buttons and sliders automatically change in response to user-interaction. In other words, when you mouse over a button, it changes to another graphic (in the Web world, this is called a "roll-over" effect). All told, buttons have four states:
- Disabled (button is not available in the current context -- a fast-forward button may be disabled when the player is stopped)
- Normal (ready to be clicked, but the mouse is not over the button)
- Hover (mouse is over the button, but the user isn't clicking)
- Active (the button is doing its thing -- i.e., the Play button is "Normal" during playback)
Sliders have three states:
- Disabled
- Non-filled
- Filled
RealOne expects a controls states to be present in its corresponding image-files. Each button and slider graphic is a little three- or four-frame comic-strip, with a different button state in each frame, like so:
TK: infographic, like so:
Disabled Normal Hover Active +---------+---------------+------------+---------------+ | | | | | |<- 25% ->| <- 25% -> | <- 25% -> | <- 25% -> | | | | | | +---------+---------------+------------+---------------+
Button states
Disabled Non-filled Filled+---------+-------------+---------------+| | | || | | || | | || | | || | | || | | || | | || | | || | | || | | || | | || | | || | | || <-33%-> | <-33%-> | <-33%-> || | | || | | || | | || | | || | | || | | || | | || | | || | | || | | || | | || | | |+---------+-------------+---------------+
Vertical slider states
+-------------------------------------------------------+ | /|\ |Disbled| 33% | | \|/ | +-------------------------------------------------------+ | /|\ |Non-fld| 33% | | \|/ | +-------------------------------------------------------+ | /|\ |Filled | 33% | | \|/ | +-------------------------------------------------------+
Horizontal slider-bar
Additionally, each slider has a "thumb" (the bit you drag along the slider), with two states: disabled and normal.
TK: infographic
Disabled Normal+---------+---------+| | ||<- 50% ->|<- 50% ->|| | |+---------+---------+
RealOne automatically displays the appropriate slice of each button and slider's graphic based on its state.
Status fields are text-boxes that display information about the track playing and the next track in the queue. You don't need to create any graphics for your status-fields, but you do need to mock them into your layout at the size you want them rendered, so that you can specify their size and location later on.
Images are identified by distinctive, case-insensitive filenames.
Your background image needs to be called background.bmp (or background.jpg if your background is a JPEG image).
"Default" buttons have predetermined names. "Custom" buttons have custom names.
Volume sliders need to be called VolTrack.bmp, while volume thumbs must be called VolThumb.bmp.
Progress sliders need to be called PosTrack.bmp, while progress thumbs must be called PosThumb.bmp.
Click here for Part 2 of this article