Your favorite Apple, iPhone, iPad, iOS, Jailbreak, and Cydia site.
Thread: Color Keyboard Guideis a discussion within the
Skinning / Themes Discussionforums, a part of the
Design and Media For the iPhone / iPod Touchsection;
Hey, I'm not aware of any themes that handle Alert and Standard separately and I had never tried it before, but here's a very quick attempt to test it and...
09-09-2011, 04:33 PM #161
Hey, I'm not aware of any themes that handle Alert and Standard separately and I had never tried it before, but here's a very quick attempt to test it and it seems to be working with the bare minimum number of images necessary for this method. I basically combined the two different themes that use this method I pictured recently, so neither has two keys for More/Int, but they do change as expected. The Red kb is set to Standard and the Black is set to Alert. I'm seeing the Red in instances where expected, and the Black where I had described. (Facebook "status" and App Store login. As well, in the instances where there are two fields (like App Store full login) it is using my different images for the "Normal" and "Email" ControlStates. Might be jumping the gun in haste thinking this shows it working properly as you are changing the 1/2 key thing, but I'm guessing that if my "Alert-Normal CState" images had the two keys, that would be working properly.
Take a look and let me know...
CK Alert Test.zip
Huh, might have also inadvertantly proven that this is not going to work.
It's seeming like "Alert" mode may only be used when sensitive info (Username/Password) entry is somehow specifically a part of an app's functionality.
To look at that type of entry in a third party browser for instance where it is a functionality of the web site (not the app), the same symbol changes happen, but using the Standard kb.
It's seeming more and more like the one key option is the only option using the "Hybrid" method.
09-09-2011, 05:37 PM #162
Yeah, it also does not work in Wifi login alerts. So in essence, the only place it works is if there is a modal dialog that pops up as in the App store. Bummer. I'll use the one-button approach then. Thanks for your heroic efforts.
The Following User Says Thank You to armadillo For This Useful Post:
09-09-2011, 05:45 PM #163
09-09-2011, 09:37 PM #164
09-09-2011, 10:51 PM #165
09-09-2011, 11:31 PM #166
09-11-2011, 01:16 PM #167
Hey, guys. I've been working on reorganization and expansion of this guide and I'm extremely interested in any input I can get.
I've had a hard time figuring out how to break things up without having to include endless duplicate info, and work within use of the first 5 posts that I had "reserved". Here's a mock up of the first Post (though not complete), which I hoped to include enough info that the individual method explanations could be trimmed down a good bit. As well, usability is almost dependent upon viewing the full site. As much as I love the mmi app, it is super hard to set things up in a readable way with no control over formatting.
Figured I'd see if I could get some input before traveling too far down my current path... any would be hugely appreciated (and in my case, well needed).
There are 3 general approaches or "methods" to creating themes for Color Keyboard, which I will quickly describe here to help the user decide just what information they're looking for.
1. Hex Color Method
This method only requires one "text" code file called a Colorkeyboard.plist. This method can be used with as little on hand as a text editor and a method of SSH, and only requires altering Hex (RRGGBB) Color values to assign colors to all of the parts of the keyboard.
Imagine that each part of the native iOS keyboard (Background, Keys, Text, etc...) has a code value that controls it's color, and the Colorkeyboard.plist file allows you to assign your own colors to all of those parts.
2. Background Image Method
This method uses the ColorKeyboard.plist to make the "Hex Color Method" values transparent, and display an image that you will create to reproduce all of those parts. This method requires Photoshop and/or similar applications to create these images.
Imagine that everything you see on the native iOS keyboard (Background, Keys, Text, etc...) is part of one static image, and you will create your own "image" to replace it.
3. Hybrid Method
This method mixes the first two by using the ColorKeyboard.plist to display images providing the background and keys, and leave the native iOS text visible and their desired colors. This method provides a few advantages over the Background Image Method, including higher compatibility with international setups that may include varying symbols, and use of the same font as the rest of the device whether native or Bytafont controlled.
Post 1: General Info / ColorKeyboard.plist / Definitions
Post 2: Hex Color Method
Post 3: Background Image Method
Post 4: Hybrid Method
Post 5: Popups
These are the folders used for Color Keyboard theming and their physical locations:
This is where your individual theme's folder will go (This folder will contain at least your ColorKeyboard.plist, and at most everything except popup images).
This is where the folder with your Popup images will go.
These two folders are used to simply insert your own Background images to be applied in the ColorKeyboard settings app.
Background Image Sizes:
Landscape - 480x162
Landscape@2x - 960x324
Portrait - 320x216
Portrait@2x - 640x432
Color Keyboard makes use of Property Lists or "plists", which are found in many forms throughout the theming realm. A plist is a hierarchically formatted code file that uses a variety of <tags> to reference native commands as well as assign and implement custom values. A ColorKeyboard.plist specifically references all of the natively defined parts of the keyboard and allows the user to assign custom values to properties such as color, opacity, positioning, shape and size. In addition, the plist is able to assign backgrund images to be displayed behind the keyboard's native keys, allowing a variety of options for creating a unique theme.
The "hierarchy" within the plist is a format that can be easily learned. It is generally structured in a directory/sub-directory style, and <tags> are used to "begin and end" individual values and lists of values. The generic syntax is <tag>value</tag>. The "value" can be from as little as one parameter, to a list of "sub" <tags> containing many parameters. Spacing outside of the <tags> is not read, meaning that the entire plist could be written entirely on one line with no spaces, or set up as an "outline" for optimal ease of viewing.
Here is a simplified generic example of a ColorKeybord.plist, spaced and color coded to emphasize the hierarchy of <tags>:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
It is advisable to use iFile "on device" to edit your plist for a few reasons. iFile's Text Viewer is able to read and save as .plist files, and even check the syntax of the code when opening the file. Mac users may have an easier time on their computer working with these files, but on Windows machines, specific software is needed to read and save as a .plist file. This can be overcome if needed by changing the extension of the file from .plist to .txt and using any text editor, then changing the extension back when complete. Different text editors will read the spacing included in the original file differently, so you may need to try a few to find one that formats the text as viewable as possible. The laundry list of other benefits to having iFile aside, for me the ability to retain the .plist format and check my work with a respring and a flip to the Spotlight page is invaluable.
** If using iFile and you make a mistake that breaks the rules of syntax and causes an error, don't be alarmed when you open the file and nothing is there. Close it and change the extension to .txt, open it and you will be able to look for your error.
Here are some generic slections from the ColorKeyboard.plist with explination inserted to give a general understanding of the main parts of the plist and what they will be used for. Each part will be explained in much more depth throughout the rest of the guide, and most terms in red are included in the following Definitions section:
This is the header and will always be present as shown:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
This <key> can be used to callout images for the Background Image Methods or to simply include 1 image to be used behind Hex Color keys like the CK Settings app allows:
<key>Orientation;iPhone-Alert or Standard;ControlState</key>
This <key> is used to define your own custom colors to be applied later in the plist. Create as many of the individual <arrays> as necessary:
<string>Custom Color Names</string>
If the following and like strings are included, they will set colors here and will not be called out later in the plist.
This key can be used to define custom linear gradients to be used if desired for Key Foregrounds. This can be used as well in the Background Image Methods to set a very transparent gradient, for example, that can be applied to "pressed" secondary keys to create animation. Include as many of the individual <arrays> as necessary.
<string>Custom Gradient Names</string>
<string>Begin color defined above</string>
<string>End color defined above</string>
This <key> includes two <keys>, iPhone-Alert and iPhone-Standard. Those two <keys> should be identical, so it is advisable to complete the iPhone-Standard, and then copy it's entirety for iPhone-Alert. As many of the individual DisplayType <arrays> can be included as are needed to separate control over the desired keys and key parts to assign color and/or transparency.
<string>Custom Color Names or UIKBColor Commands</string>
<array></array> and <dict></dict>
Both are <tags> that will contain sets of "sub" <tags>.
<key></key> and <string></string>
Both of these <tags> are used in many ways together and separately to make callouts (or references to native code) and create definitions to be referenced in the rest of the plist.
Number values included in various <keys> to denote the different "States" that the Keyboard or individual Keys can be in:
0 = Shift Key Pressed
1 = Normal
2 = Numbers
3 = Symbols
1 = "Pressed" - When a Key is pressed.
2 = "Disabled" - e.g. "Search" Key with no text in the input field.
3 = "Normal" - Normal state of a Key when no other [ControlSates] are affecting it.
4 = "Caps Lock On" - When the Shift Key is double tapped to enable Caps Lock.
6 = "Shift Key Auto Pressed" - When Apple presses it automatically.
7 = "Shift Key User Pressed" - When the user presses it.
Custom Color Names
You can name the custom colors you define in <key>CustomColor<key> as you like. I advise naming these colors to describe what they will actually theme rather than to describe the color. This way your plist can be used for multiple themes and only the hex codes will need to be altered.
Custom Gradient Names
Just like Custom color names, advisable to name along the same lines.
The callout for the different theme-able native actual Keys.
Delete = Delete Key
DynamicString = The Monetary Symbols only ($, etc.)
International = The "Globe" key present with International keyboards such as EMOJI enabled
More = ABC/123 Key
NumberPad = All keys on the Settings App Passcode Entry, etc. Number Pad
Return = Search/Enter/Return/Go/Next/Route Key
Shift = Shift Key
Space = Spacebar Key
String = QWERTY/Number/Symbol Keys
Top-Level-Domain = The ".com" and "." Keys on the URL and Email Layouts respectively
Top-Level-Domain-Variant = The "unpressed" Keys on the ".com" and "." Alternate Popups
Color Keyboard uses Hex triplets, which are comprised of 3 sets of characters representing Red, Green and Blue in that order and then a fourth set to control opacity.
(2 for Red, 2 for Green, 2 for Blue, 2 for Opacity) Basically: RRGGBBOO
Each character can be numbers (0-9) and letters (A-F). The letters are used to go beyond 9 basically, meaning that there are 16 possible values for each character (Zero-F).
Zero is no value, F is full value. Here are a few examples:
000000 = Black
FFFFFF = White
FF0000 = Red
00FF00 = Green
0000FF = Blue
This value works exactly the same way.
00 is completely Transparent
FF is completely Opaque
So for example:
000000FF = Completely Opaque Black
00000011 = Very transparent Black
00000000 = Completely Transparent
These <keys> will be used in the DisplayType <strings> to apply desired color and/or tranparency to the individual parts of the keys.
<key>EtchColor</key> - The "drop shadow" on the Symbol.
<key>HighlightColor</key> - The thin "highlight" at the top of the Keys.
<key>ForegroundColor</key> - Uses a solid defined color for Key Foregrounds.
<key>ForegroundGradient</key> - Uses a defined CustomLinearGradient for Key Foregrounds
<key>SymbolColor</key> - The Letter/Number/Symbol on the keys.
<key>SymbolSecondaryColor</key> - The Shift Key Arrow and NumberPad Letters
The three different layouts of the Keyboard, and reference to the passcode entry NumberPad.
"No Value" = Normal - The layout you normally see.
3 = URL - The layout that includes the ".com" Key for web address entry.
4 = NumberPad - Used to callout your NumberPad image
5 = NumberPad - Both of these are needed for the NumberPad
7 = @email - The layout that includes the @ symbol for email address entry.
Landscape and Portrait
"Standard" and "Alert". Both use the exact same Control States and Layouts. The main difference natively is the use of a "Silver" or "Black" Background Gradient respectively, and both must be referenced so that your theme works in both instances.
Stardard - Almost all instances you encounter.
Alert - Instances where entering sensitive information such as passwords.
These are like Custom Color Names, only they already exist natively to be used for standard colors. Use them anywhere that you would alternatively use a Custom Color. Here are a few examples:
UIKBColorClear - Define a part as transparent without having to make a Custom Color.
and so on...
This <string> will use it's included <keys> and <strings> to set EtchColor and SymbolColor for "unpressed" Alternate Popup text only in the instance where the normal Etch and Symbol are set to be transparent. It seems to only be useful when using the Background Image Method, as "String" Etch and Symbol are set to be transparent.
This is a useful <string> that can be used in place of <string>DisplayType=</string> to make it's included <keys> and <strings> true across all Keys.
Besides the normal Key Parts, the next few definitions are <keys> that might be best used in this <string>.
This <key> moves the Etch away from the Symbol along the X-axis (left and right).
A positive number (shown) moves it right, a negative number moves it left.
This <key> moves the Etch away from the Symbol along the Y-axis (up and down).
A positive number moves it down, a negative number (shown) moves it up.
This can be used to force the desired key radius for your theme, though it can be overridden by the user in the CK Settings App using the provided slider. "0" is no radius, and can be replaced with the radius you desire.
This is an alternative to setting the Key Foregrounds to be transparent using UIKBColorClear, a CustomColor or a CustomLinearGradient.
The Following User Says Thank You to Phatmartino For This Useful Post:
It's Mi (10-18-2011)
09-11-2011, 01:18 PM #168
The Following User Says Thank You to Jahooba For This Useful Post:
09-11-2011, 01:26 PM #169
Glad I still keep tabs on this post.
First for your Cydia app there are a few things I've learned through updating all of my package.
Depiction icons are a way to link the average user to where you'd like them, all you need is a URL. So All you need is a 32x32 pixel icon that kinda represents what they are going to (like for my theme I have a link to paypal for donations, my colorboard theme, and the facebook page I made for it.
You can use up to three depiction links and make sure if you want to change them use the replace button and completely redo them (better chance of modmyi.com getting it exactly how you want it.
Lastly, I think your talking about an app's description format on Cydia through modmyi.com. I've finally figured out how to indicate to them how to put paragraphs!!!
just use <p> at the beginning of a paragraph and </p> at the end, in this way your description can become 200 times more readable, especially if your including URL's in the description. Hope that helps, look at any of my theme packages to see how it looks.
09-11-2011, 01:28 PM #170
The Following User Says Thank You to iZangetsu For This Useful Post:
09-11-2011, 02:29 PM #171
Just stopped by and wanted to say thanks again for your great help with h1 CKB! Very seldom you meet as nice and helpful guys as Phatmartino ... Thank you man for sharing your genius!
Last edited by henftling; 09-11-2011 at 03:35 PM.
09-11-2011, 02:33 PM #172
@Jahooba - Thanks, and glad things didn't turn out as badly as they could have for you in the hurricane. Apologies, read about it on the Neurotech thread a day or two too late to wish you luck. Hope all is well!
@VerizonIphone4_help - Awesome! I've actually been so busy helpin' others that I haven't released a darn thing on Cydia yet. I'm trying to reorganize this thread along the lines of your suggestion a while back, but I will make good use of your info when I do start releasing! Thanks for your continued help!!!
@iZangetsu - Nice! All the Star Wars lingo prompted me to take a break from this last night and watch through Eps. IV and V. Some Yoda action strengthened my resolve! I will continue on... err... these blast points are too accurate for Sand People... Darn it! I got nothin'.
@henftling - Absolutely! One thing I'll always love more than CK is helping others!
09-11-2011, 11:40 PM #173
Well thanks to you my friend Shift HD2 theme may well be released with a Hybrid 5-row that I put together for it. I just can't stop thanking you for it. I also had a special request to put together a bg for a Greek keybord layout for the one I did for Leg1on lol I guess you gotta look into international support as well....some time far, far, away..... a mission that will be, once completed the first post is me thinks
On another note forgot to ask. Will the same size bg images work for SD once it's not named as @2x.png or does it have to be resized to 320? also popups?
Last edited by iZangetsu; 09-11-2011 at 11:45 PM.
09-11-2011, 11:57 PM #174
You'll need to resize ALL images (BG and Pops) by half for SD compatibility. (and, of course, remove the @2x)
Hey, let me know (if you're aware) if there are differences in International kb's such as the mentioned Greek other than the text...
09-12-2011, 01:41 AM #175
heres the bg i had to custom make for the greek layout just to get an idea of the difference. if you need any more info about it let me know so i can get in contact with the person who asked for it lol reading Greek i cannot...
09-12-2011, 10:53 AM #176
09-12-2011, 11:13 AM #177
09-12-2011, 03:28 PM #178
09-13-2011, 09:03 AM #179
Yeh I think that should be per request. What I did was I had the guy snap me a screenshot of portrait n landscape so I could see where the "keys" had To be placed
09-13-2011, 05:43 PM #180
Quick question---(Congratulations! You Won!)---Damn that annoying! back to question lol
if possible, where would I look to change the color of the shift key halo? the white is getting to be an eyesore especially on a dark bg.
The Following User Says Thank You to iZangetsu For This Useful Post: