Over the past few months, I’ve been studying up and trying out several cross-platform development solutions and one of the more interesting ones I’ve found, as a web designer and developer, is AppJS. It allows development for the desktop for all three major desktop operating systems using the mix of technologies commonly known as HTML5 and node.js.

Of course, I’ve also been using Adobe AIR since it was introduced, though AIR for HTML isn’t all that great in my experience. AppJS, on the other hand, uses the Chromium Embedded Framework which renders content beautifully, is super fast and has all of the latest and greatest features HTML5 has to offer without awkward workarounds.

Before getting started, it is worth mentioning that AppJS is still a relatively new project and documentation is sparse at the moment, but it is being worked on. I’m also not attempting to compile and package a completed app just yet, so I will be using the distributable version and simply replacing the content files throughout this tutorial.

Downloading and Extracting AppJS

Visit the AppJS website and choose the correct version of the distributable for your operating system. Once the download is complete, extract the ZIP file to a location of your choosing. I am using a local web server to test my app in the browser as well as in AppJS, so I’ve extracted mine to the a home directory for the web server.

The main files associated with an app in the distributable package are:

• app.exe(for Windows, not sure of the naming on other OSes, but it should be similar) – This is the launcher for your app. Double click it to start node and your app with its initial window.
• data/app.js– This is the main JavaScript file for the application. It is responsible for the connection to node.js and the native operating system. You can set options for your initial window in this file.
• /data/contentDirectory – This is where your app’s main content will live. You can create subdirectories to organize your content as you see fit.
• /data/content/index.html– This is the content for your initial AppJS window. We will be editing this file to create our custom chrome and application content.
• /data/content/style.css – Your app’s main stylesheet.

Editing the App’s Content

data/app.js

As mentioned above, the app.js file controls the initial window for your app, and since we want custom chrome, some options will need to be changed. For custom chrome, the system default window chrome needs to be hidden, so in the window variable, inside the call to app.createWindow, change showChrome to false (or add it if needed… it’s just a standard JavaScript object).

Next, we need the web browser’s standard background to be transparent and hidden away (otherwise you’ll just get a white window with no transparency). To enable this in the window, set or add the alpha option inside of app.createWindow to true.

Once those two changes are made, your app is set up to use custom chrome. For ease of use, here is what my app.js file looks like:

var app = module.exports = require('appjs');

app.serveFilesFrom(__dirname + '/content');

var window = app.createWindow({
  width  : 1024,
  height : 768,
  icons  : __dirname + '/content/icons',
  showChrome : false,
  alpha: true,
  autoResize: false,
  resizable: true,
  margin: 0

  /***************************** defaults ********************************
* url            : 'http://appjs', // serve static file root and routers
* autoResize     : false,          // resizes in response to html content
* showChrome     : true,           // show border and title bar
* resizable      : false,          // control if users can resize window
* disableSecurity: true,           // allow cross origin requests
* opacity        : 1,              // flat percent opacity for window
* alpha          : false,          // per-pixel alpha blended (Win & Mac)
* fullscreen     : false,          // client area covers whole screen
* left           : -1,             // centered by default
* top            : -1,             // centered by default
*************************************************************************/

});

window.on('create', function(){
  console.log("Window Created");
  window.frame.show();
  window.frame.center();
});

window.on('ready', function(){
  console.log("Window Ready");
  window.require = require;
  window.process = process;
  window.module = module;

  function F12(e){ return e.keyIdentifier === 'F12' }
  function Command_Option_J(e){ return e.keyCode === 74 && e.metaKey && e.altKey }

  window.addEventListener('keydown', function(e){
    if (F12(e) || Command_Option_J(e)) {
      window.frame.openDevTools();
    }

  });

  this.dispatchEvent(new this.Event('app-ready'));
});

window.on('close', function(){
  console.log("Window Closed");
});

I’ve also added an event called app-ready that will be seen by the main window once the app has finished loading. This will be important later.

If you launch the app, it should launch without any of the default chrome of the OS. To exit, you’ll need to right click on your taskbar (for Windows) and choose Close Window. Or, if you’re adventurous and want to use JavaScript to close the app, press F12 or Command+Shift+J on your keyboard and in the Chrome console, use:

window.close();

data/content/style.css

Inside of style.css, the body of the app needs to be set to be transparent as well or you’ll continue to have an opaque window. The quickest and easiest way to set this up is to paste the following into the stylesheet:

body{
   margin: 0;
   padding: 0;
   background: transparent;
}

Of course, you could edit the existing rule to include the same properties as well. For me, I want a fresh start, so that is the only declaration in my stylesheet for now.

data/content/index.html

Now it’s time to actually build the window’s custom chrome and app’s content. I always start by either deleting the entire index.html file and recreating it or deleting the content in the body tag. Before beginning to add elements, I also link up my stylesheet and any JavaScript libraries I know I’ll be using. For the tutorial, I’ve added jQuery which I’ve placed in a subdirectory called libs inside of the content folder. I also like to prototype in a single file, so I’ve added an extra style element and a script element for when the document is ready. When the time comes, if necessary, these elements can be moved to external files later in the project.

<!doctype html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>AppJS Project</title>
<link rel="stylesheet" href="style.css">
<script src="libs/jquery-1.8.2.min.js"></script>

<style>

</style>
<script>
$(function(){

});
</script>
</head>

<body>

</body>
</html>

The Basic Window

Now to build the actual window itself. You can use any HTML and CSS that you’d like to build your window. I use a basic structure that has a wrapper for the entire app window, a title bar, a body/content section for the app itself and then finally a status bar (sometimes). For the sake of simplicity, I also just use div elements. You can use any valid HTML5 elements you wish.

<div class="app">
	<div class="title-bar">
		<!-- Title Bar Elements go here... -->
	</div><!--.title-bar-->
	<div class="app-content">
		<!-- App content goes here... -->
	</div><!--.app-body-->
	<div class="status-bar">
		<!-- Status Bar elements are here... -->
	</div><!--.status-bar-->
</div><!--.app-->

The Title Bar

A basic title bar has three main elements: the title of the app, an icon and window controls. Again, to create these, use any HTML you’d like. Also, start to think cross-platform at this point. Windows users will expect the window controls to be on the right while Mac OS users will expect them on the left. Titles are also placed in different places depending on the operating system. To be able to move these around later, I use simple containers to hold the things that will change positions.

For the final HTML inside the .title-bar div:

<div class="title-drag"></div>
<div class="app-title">
	<span class="app-icon"></span><!--.app-icon-->
	<span class="text"></span>
</div><!--.app-title-->
<span class="button-container window-controls">
	<ul class="inline">
		<li><a class="button minimize-button" href="#minimize-app">Minimize</a></li>
		<li><a class="button maximize-button" href="#maximize-app">Maximize</a></li>
		<li><a class="button close-button" href="#close-app">Close</a></li>
	</ul>
</span><!--.window-controls-->
<span class="button-container fullscreen-button-container">
	<a class="button fullscreen-button" href="#fullscreen-app">Full Screen</a>
</span>

I added an extra div with a class named title-drag for a bit later. For the Mac side, I’ve also added an extra button that can be used to launch the app into a fullscreen experience.

If you were to run the app now, you would not be impressed. You’d see a floating blue list of links that do nothing except hover on a transparent background over your screen.

Here’s the final HTML for our app:

<!doctype html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>AppJS Project</title>
<link rel="stylesheet" href="style.css">
<script src="libs/jquery.js"></script>

<style>

</style>
<script>
$(function(){

});
</script>

</head>

<body>

<div class="app">
	<div class="title-bar">
		<!-- Title Bar Elements go here... -->
		<div class="title-drag"></div>
		<span class="app-icon"></span><!--.app-icon-->
		<span class="app-title"></span><!--.app-title-->
		<span class="button-container window-controls">
			<ul class="inline">
				<li><a class="button minimize-button" href="#minimize-app">Minimize</a></li>
				<li><a class="button maximize-button" href="#maximize-app">Maximize</a></li>
				<li><a class="button close-button" href="#close-app">Close</a></li>
			</ul>
		</span><!--.window-controls-->
		<span class="button-container fullscreen-button-container">
			<a class="button fullscreen-button" href="#fullscreen-app">Full Screen</a>
		</span>
	</div><!--.title-bar-->
	<div class="app-content">
		<!-- App content goes here... -->
	</div><!--.app-body-->
	<div class="status-bar">
		<!-- Status Bar elements are here... -->
	</div><!--.status-bar-->
</div><!--.app-->

</body>
</html>

Dressing the Window

With the title bar elements in place, our window is ready to be dressed with some CSS and brought to life using JavaScript. This is the part where you can unleash your creativity to make your app’s window look however you want. For the tutorial, I’ve keep it relatively simple with simple buttons and solid colors. Since you have the WebKit engine for rendering, you can use CSS gradients, SVG, box-shadow, border-radius, canvas, regular background images, border-image, and whatever else you’d like to style your window. I’ve even seen mention of Flash content being deployed in AppJS – is that even possible? – so if that works, you can use it too.

After styling, here’s what my window looks like… all 8 variations for different operating systems and versions:

Without going into the gritty details of all of the CSS, I used basic box model techniques, floats, the new flexible box model and every other trick in the book that you’d use on a normal website to style and position the controls in the title bar. The Windows controls use normal floats and absolute positioning while the Mac OS and Linux variations use absolute positioning, flex boxes and the order property to reorder the buttons appropriately for the platforms.

Styles switch simply by adding and removing classes on to the body tag of the app. Just imagine using a single CSS class to switch around all of the required buttons in dialog boxes later in your project!

I didn’t add any symbols for the demonstration which kills the usability of the Windows 8 style. In a real application, of course it would be a good idea to include the proper icons.

Here is the full CSS for the example windows (including maximized and fullscreen states and simple styling for the little bit of app content):

The Window Shadow…

When using custom chrome, you lose the OS default window shadow, which is a bummer because it can’t really be faked to perfectly match the system. They are possible to create in this layout, though, with just a simple box-shadow around the .app div element. To make it show, add some padding to the body element to match the size of the shadow. It takes a little experimentation to get it right. Also keep in mind that the padding will affect any media queries you plan to use for your app’s content since your visible window will not be the same size as the real window that is being queried.

Aside from not matching the OS shadow, the padding required on the body element also has a drawback. Unlike Adobe AIR which allows click through to underlying applications and the desktop environment in transparent areas of the window/stage, AppJS will capture all mouse events on the transparent areas. This isn’t specifically the fault of AppJS though. From my understanding Chromium doesn’t have the mechanisms in place for it to happen. Because of this, the smaller the shadow, and thus the body padding, is, the better. The Windows 8 style shadow is a perfect example, though it could still be a little darker and larger.

A Note on Maximize and Full Screen

Since this windowing experiment is basically a window within a window and has a drop shadow which requires padding on the body element, when maximizing the window or going full screen, the actual transparent window that holds our HTML-created window will be scaled appropriately, but our custom window retains the shadow and padding… and border-radii. This leads to a really weird looking maximized or full screen app window.

To fix that, when going into the maximized or fullscreen state, another class is added to the body and new CSS takes over to remove the shadow, the padding and the various instances of border-radius that keep the window from occupying the full space of the real app window.

Note: At the time of writing, AppJS has a bug in the Windows implementation that causes maximized windows using custom chrome to cover the taskbar. For the moment, maximize and fullscreen do essentially the same thing.

Wiring it all Together

Up until this point, our AppJS window is basically just a pretty picture rendered by WebKit. To make it interactive, we’ll use a bit of JavaScript to call the AppJS functions that will allow us to control the window. The functions we’ll be using are listed in the AppJS docs at Github.

The Main Window Controls

We’ll start with the minimize and close buttons because they are easy and only require a single click handler each. For both, select the button with jQuery (or plain, vanilla JavaScript, or any other library loaded in your app) then add a call to the correct functions from window and window.frame in AppJS.

$('.title-bar .close-button').on('click', function(event){window.close();});
$('.title-bar .minimize-button').on('click', function(event){window.frame.minimize();});

Next, the maximize and fullscreen button are a little more complicated because they are more like toggle buttons than the single-click minimize and close buttons that hide the window when clicked. For these, I use a couple of helper functions that set up the toggle action (these are very similar and could probably be combined into a single function with a little thinking time.

//Helper function with logic to toggle the action of the maximize 
//button between maximize and restore.
var maximizeWindow = function(event){
	switch(window.frame.state){
		case 'maximized' :
			window.frame.restore();
			$(document.body).removeClass('maximized');
		break;

		case 'normal' :
			window.frame.maximize();
			$(document.body).addClass('maximized');
		break;
	};		
};

//Helper function with logic to toggle the action of the fullscreen 
//button between fullscreen and restore.
var fullscreenWindow = function(event){
	switch(window.frame.state){
		case 'fullscreen' :
			window.frame.restore();
			$(document.body).removeClass('fullscreen');
		break;

		case 'normal' :
			window.frame.fullscreen();
			$(document.body).addClass('fullscreen');
		break;
	};		
};

$('.title-bar .maximize-button').on('click', function(event){maximizeWindow(event)});
$('.title-bar .fullscreen-button').on('click', function(event){fullscreenWindow(event)});

These final function calls are almost identical to those used for minimizing and maximizing, except they call the helper functions which figure out which action to take and ultimately call on window.frame to complete the task.

The Title Bar as a Drag Handle

The final interaction our custom window needs is a little bit of movement, specifically being able to move the window around the screen by dragging the title bar. As of the time of writing, AppJS only supports this action on Windows and Mac OS X according to the docs, but as the framework matures, it should be the same for all platforms.

To accomplish the moving, simply listen for mousedown on the title bar or an element in the title bar (in this case, I’ll be using the extra title-drag div from the original code of the title bar) and calling window.frame.drag() from AppJS.

$('.title-drag').on('mousedown', function(event){window.frame.drag();});

And with that, our window can be placed anywhere on the screen simply by dragging the title bar as one would expect.

A Few Small Details

So far, even though our window is fully functioning, it is missing a couple of small details. First, it has no title. The original HTML already has a place for the title text, so we’ll just fill it in with a little JavaScript that pulls the title text of the HTML page into the title bar’s .app-title .text element. This could also be hard-coded into the HTML, but the JavaScript approach leaves a little flexibility and shows how to change the window title if needed later.

$('.app-title .text').text(document.title);

With adding the title text, which is selectable by default, the drag action used to move the window could be interrupted if the user initiates the dragging over the text (if you’ve just attached the event to the title bar element itself, that is). In this example, the problem is already fixed with the addition of the .title-drag div element. Through its CSS properties, it covers the title and makes the text unselectable. It accomplishes this using absolute positioning and the z-index property to make sure the .title-drag element is above the .app-title div in the z stacking order.

Next, because some of the CSS used for floating nad aligning buttons on the Windows Vista and 7 variation causes the buttons to overlap, if the traditional Windows glow is added to the buttons on hover with a simple box-shadow, the glow may be obstructed by the other buttons. Luckily, this is easily fixed with another small bit of JavaScript.

$('.window-controls .button')
	.on('mouseover', function(event){
		$(this).css('z-index', 2);}
	)
	.on('mouseout', function(event){
		$(this).css('z-index', 0);}
);

All this does is manipulate the z-index property of the buttons on hover so that the currently hovered button is always higher in the stacking order. As a result, if the button has a glow or other effect, it will always render on top of the other buttons. I’ve used mouseover and mouseout events, but in jQuery, the hover event could also be used.

Of note, for this z-index trick to work, the position property of the buttons must be set to either absolute or relative. Default positioning does not allow reordering by using the z-index property.

Finishing Up

With a  fully functioning custom window, the only thing left is to add your app’s content to the .app-content div. Again, since WebKit is powering the rendering, you can use any and all techniques you would normally use in a browser-based app to produce the app content. With AppJS, you can also reach out to the native side using node.js to do things that would normally not be possible in a web app. For this example app, I just added a few buttons to change the window style using plain jQuery, but the sky is the limit. Can’t wait to see what you all build!

Here is the final app, with code:

Update

I’ve broken the code for this tutorial into files and organized Starter for AppJS on Github. Extract the downloaded repository into your already extracted copy of the AppJS distributable package of your choice for everything needed for a custom chrome app.

11/07/2012 – Updated Starter for AppJS with new minor styling, including removal of the window shadow, and merged a patch by Simon Horton to include compatibility with his new AppJS packaging solution.

Ahead of the Windows 8 release, Ratio Interactive, a design agency in Seattle, WA launched a design contest for Windows 8 apps. It gave me the perfect excuse to begin exploring the design possibilities of the new operating system. For my entry, I chose to design an app for Digital Art Academy.

For those interested, in another post I’ll talk about some of the steps taken and decision-making processes through the design process. For now, though, here’s the final result:

Live Tiles for the Start Screen

The tiles for the Start Screen are minimal in appearance using simply a background color and icon to identify the app. They are are available in two variations, both in two sizes:

1. Non-live tiles for those that may choose to opt out of live tiles. They show only an icon and name on a solid background as described above.
2. Live tiles, which are the default for Windows 8, that show the app icon and various other useful information from the app right on the Start Screen. As shown in the screenshot, the DAA tiles may show new activity in an enrolled course, reminders for Live Sessions or information related to course download activity.

Splash Screen: Stage 1

DAA’s splash screen, shown while the app is loading, mirrors the view from the tiles from the Start screen.

Splash Screen: Stage 2

Once loaded, the splash screen animates to show the DAA login form. Logging in is required for students to access their own personal dashboard and to allow access to their enrolled courses. New users may access the app in Guest mode or create an account from this screen as well. Of course, Guest mode users will need to sign in officially to take part in DAA courses.

Home Screen

Once logged in, users are taken to the Home screen, which is the main portal for the entire app, much like the Start screen is the main portal for Windows 8. It is broken into several groups that cover all of the main destinations in the app.

Courses

The Courses group contains all of the student’s classes that are currently in session and active. The tiles may show either a poster image or slideshow for the course or an alternative live tile that is similar to the main app tile shown on the Start Screen, only with information dedicated to the specific course being represented.

Social

In the Social group, students will find their Friends list along with user-customizable tiles, complete with online indicators, that link directly to their friends’ profiles. Private messages and watched forum topics are also included.

Catalog

The Catalog group is the gateway to the entire DAA Course Catalog. Along with access to All Courses, live tiles are shown for specific categories and groupings and allow the student to browse quickly. The Wishlist feature of the Catalog is also front-and-center and allows students to add courses that they would like to participate in later. Being an official Corel Training Partner, of course Corel Painter courses are very easily accessible through a category tile. The remaining tiles in the Catalog group are for featured courses.

History

While not visible, the History group allows students to browse a snapshot of course content from classes that have completed in a familiar format.

Course Enrollment Screen

Accessed from the Catalog, the Course Enrollment screen gives a basic description of the course along with a slideshow of images used to demonstrate the techniques taught in the class as well as other helpful info that may help the student decide whether or not the course is a good fit for their needs. As shown the other info may include a short syllabus for the course as well as a preview of course materials and events.

The background used in this screen and other course-specific screens is chosen by the instructor during course creation. The app analyzes the background and chooses a complementary color for UI elements. In this case, the background is the image shown in the slider and a rich golden yellow was chosen as the complementary color.

For consistency and clarity throughout the app, when shown with user interface elements, the background is blurred and covered by a dark overlay. While it fades to the back, as a background should, the color mixing between the overlay and image establishes depth and helps the overall UI environment from feeling flat and boring.

Classroom Overview Screen

The main classroom remains simple and easy to navigate by showing only one week of course materials at a time. This view also shows the context menu for the student’s avatar with options to view private messages, edit/view their profile and log out of the app.

Resources

The course materials are front and center in the Resources group. They are organized by type, pre-downloaded where available and cached for ease and speed of access.

Videos are downloaded and play in the app itself. Finding a proper player has been a problem for students in the past, so the built in player removes one of the pain points of the current web experience.

Since Files are usually reference photos, sketches and brush files, during the download stage, they are saved to the student’s Documents library so they are easy to access in their digital painting software. PDF lessons may be viewed and commented on in the app with forum integration or through external apps like Adobe Reader or the new Reader app in Windows 8.

Events, usually webinars and live sessions, are coordinated through online conferencing and display through an in-app browser, so the student doesn’t have to open a dedicated web browser to register or participate. Of course, webinars may also be accessed through external web browsers.

Discussion

The weekly forums occupy the Discussion group. The two main forums available in each week of a DAA class are for asking questions and discussing the weekly assignments and related content. Each forum has a live tile indicating the unread counts since the last visit. Under the main love tiles are secondary tiles for popular or watched topics with new replies.

Gallery

The Gallery group gathers all of the images posted by the students in the weekly Show & Tell forum into an easy to browse wall of images. Students have requested a feature like this many times in the past. While the current platform isn’t particularly well-suited for the feature, the underlying platform and API necessary to build the DAA app would make it very easy to construct. Gallery tiles would also allow access to the original forum posting for another way to browse the weekly Show & Tell forum.

Nav Bar for the Weekly Classroom Overview

Original concepts for the app had a screen dedicated to switching between the weeks with some secondary content. In the final concept, the entire screen was replaced with a simple nav bar that removes a step in accessing course materials. Students are always returned to the last week they viewed when entering the classroom, or the new week when it becomes available for the first time.

The buttons in the nav bar show the status of each week, much like live tiles would in a conventional screen. In this view, the week 04 is locked and unavailable to students, so it is showing a disabled state. At the proper time, the week will unlock and be accessible with its button becoming fully opaque.

The ring around the week numbers, in addition to matching the styling of Windows 8 navigation and buttons, shows the download status for the course materials in the week. Week 03, in this case, is currently being downloaded and is approximately 65% complete. Weeks 01 and 02 are fully downloaded.

While not designed for the contest entry, and perhaps unconventional since the weeks cannot simply be scrolled into view with a single finger gesture, Windows 8′s Semantic Zoom feature from the Weekly Overview could be used as another way to switch between weeks.

Weekly Forum Topics Screen

The forums inside of DAA courses are where all of the discussion and sharing of work take place. They are accessed via the Discussion tabs in the weekly course overview screen. In the app, the traditional list of topics is replaced by a tile list showing the title of the thread, the author, number of new replies since the last visit and a thumbnail of the image being discussed (or the avatar of the first post author if no image is uploaded into the topic).

Watched

The Watched group is a student-customizable group that contains topics the student has chosen to follow closely.

New

Topics with new replies since the last forum visit are shown in this group. They are arranged newest to oldest by the last reply by default.

All

As the name suggests, all topics are listed in the All group. They are arranged newest to oldest by the original topic date by default so that the order of topics remains consistent as replies and new topics are posted.

Notifications

This screen also shows an example of in-app notifications that appear in the top right corner of the screen. Notifications can be shown when new private messages are received, course content downloads complete, a watched topic receives a new reply or other important events happen within the app and DAA environment.

Gallery Overview Screen

The Gallery overview screen collects all of the large images from the weekly forums for the course for display. As mentioned previously, this is a requested feature from students. It enables students to quickly see what their classmates have worked on throughout the course. Images can also be opened in a single-image, fullscreen view. Context menus provide other navigation options, such as opening the original forum thread for the image.

Gallery Overview Semantic Zoom

Semantic Zoom is used in the Gallery to allow students to quickly browse through large collections of images either by the original artist, predominant colors, or through thumbnails of the included images. Other metadata from gallery images could be included as a browsing group as well.

Conclusion

The final app design is vastly different from the DAA web interface, but feels right at home in Windows 8. The screens have been slimmed down and place course content easily within the grasp of students… quite literally with Windows 8′s emphasis on touch.

Downloaded course content is available in all situations, so the student is free to unplug from the Internet and learn and paint anywhere. Just imagine relaxing by the lake, watching a few lesson videos and then going straight into Painter or Photoshop to capture the sun setting over the water on a Surface Pro tablet.  If it were more than a design comp, Digital Art Academy for Windows 8 would enable exactly that! One can dream.

For credit where it’s due, the pencil, pen and brush icons used on the live tiles were designed by and can be downloaded from Brankic1979.

It has been a while since the last FruitBat update was made available and since then, a lot has changed. BlackBerry 10 is on the way and Tablet OS updated to 2.0 with 2.1 in beta. WebWorks also continues to evolve in the BlackBerry github repository. With all of the activity around BlackBerry development, FruitBat needed some attention to keep up as well as improve some of its basic functionality.

For instance, while working on a new, exciting WebWorks project, I discovered WebWorks support at a place it needed to be for any serious use. It was severely broken for all but the most basic apps, so I rewrote it from scratch, squashed every bug I could find, and now it is working beautifully and completely as intended. Packaging raw HTML, CSS and JavaScript files into a fully working app and installing directly to a PlayBook simulator or tablet is a one-click affair; it couldn’t be easier. Of course, there’s a lot more including a brand new Console window; check the Change Log for details.

Download links for the previous version will remain active for the time being if you need to downgrade for some reason. Please do send in any bugs you encounter so that I can work on fixing them, and if you’ve found FruitBat to be helpful, please consider donating to keep the project going.

If you already have FruitBat installed, updates are enabled and accessible through the Help menu (Help > Check for Updates) on both Mac OS and Windows. If it isn’t already installed, Mac users may need to download and install/update to AIR 3.3 before installing FruitBat. Windows should automatically update to AIR 3.3 if an earlier version is installed.

Change Log

FruitBat 1.5 includes the following changes:

• CHANGE: Updated to use Adobe AIR 3.3.
• BUGFIX: WebWorks packaging automatic ZIP file creation could create a ZIP file with a name considered invalid by the WebWorks packager. ZIP files are now simply called “app.zip” for WebWorks packaging purposes. The final BAR file is renamed after your application.
• BUGFIX: WebWorks ZIP files did not maintain the original directory structure of your app’s source folder as intended. This would cause 404 errors in your final app when resource URLs pointed to the original directory structure. ZIP files are now formatted properly and directory structure is maintained.
• BUGFIX:When creating a ZIP file for the WebWorks packager or packaging an AIR application for Tablet OS, Git-specific files were included by mistake. ‘.gitignore’ and ‘.gitattributes’ have been added to the exclusion list and will not be added to your app’s final archive. For those using Dreamweaver to build WebWorks apps, the _notes folder is now excluded as well if Design Notes are enabled for your Dreamweaver site. Final ZIP files should be 100% clean. The total exclusion list now consists of:
  • hidden files
  • symbolic links
  • .gitignore
  • .gitattributes
  • thumbs.db
  • _notes
  • __MacOSX
  • .trash
  • .ds_store
  • any files with names beginning with “._”
  • all of the following file extensions: EXE, MSI, BAR, BAT, INI, COM, VB, VBS, DMG, APP, SEA, AIR, TMP, DEB, RPM, SCRIPT
  • any files that are 0 bytes in size
  • empty directories
• BUGFIX: WebWorks app icons were sometimes not shown in the FruitBat app panel, even when properly specified in the loaded config.xml file due to XML parsing errors. FruitBat now uses more lenient matching to find the icon and should always display it properly.
• BUGFIX: Version 1.4 required the WebWorks SDK folder chosen to be the “bbwp” folder inside of the WebWorks SDK’s main directory. Now, you may choose either and Fruitbat will not complain or throw another folder select dialog in your face. “bbwp” is automatically appended if the main directory is chosen and it truly exists.
• CHANGE: Slightly modified the process for requesting a debug token from RIM. The setting for Debug Token Location is now a directory instead of a file. FruitBat will create the debug token inside of the specified directory and the final token will simply be called “debug_token.bar”. If a directory is specified already, a token will be automatically generated without asking you to select a file location.
• CHANGE: Settings/Preferences window content updated to use HTML and JavaScript instead of Flash components.
• CHANGE: Console window updated to use HTML and JavaScript instead of Flash components.
• NEW: When choosing files and folders from the Settings/Preferences window, the console will show error messages if incorrect files are chosen from the file/folder browse dialogs based on the current browsing requirements.
• NEW: Console messages are now color-coded and styled for readability. Messages with the FruitBat icon to the left are from the FruitBat app, green messages are from the command line interface of your operating system and error messages are red.
• NEW: Console themes for accessibility that change the red and green color scheme to blue and gold to maintain a difference between normal and error messages for those with color blindness. To change the theme, choose a different option from the select menu labeled “Console Color Assist” in the new Accessibility section of the Preferences window.
• NEW: Copy and paste from the Console window (thanks HTML).
• NEW: Clear function added to the Console window.
• NEW: More messages added to the console to show what FruitBat is doing or any errors it may encounter.
• BUGFIX: Browse buttons in the Settings/Preferences window did not always correctly open a file browsing dialog when clicked. Fixed July 4, 2012, but doesn’t need an entirely new post.
• BUGFIX: Changed app panel to look for bar-descriptor.xml as well as blackberry-tablet.xml to support both 1.0 and 2.0 versions of the PlayBook AIR SDK. Fixed July 5, 2012.

• BUGFIX: (Mac Only) Automatic updates did not function in 1.4.0127 (sorry guys – you’ll have to download the installer from the site this time). This was fixed and tested in an intermediate unreleased version 1.4.0130.
• BUGFIX: Auto-generated WebWorks ZIP file name could possibly be invalid when attempting to package a WebWorks app. This would cause packaging to fail. All ZIP file names should be fully valid now, every time.
• BUGFIX: Register Signing Keys item in the Publish menu was not linked to its action, so it did nothing when selected. Now, registering signing keys via this menu item should function properly.
• CHANGE:  The process for installing debug tokens was changed to allow file selection if the Debug Token Save Location in the Settings/Preferences window did not contain a valid file location.
• NEW: Added messages to the console for:
•  loading XML from any of the available options (drag & drop, shortcut key, menu item)
• creating/refreshing the package file list
• updating the main app panel
• installing standalone BAR files
• uninstalling standalone BAR files

Windows users may use the update feature to download and install the update automatically. Mac users should use the download button below for this time. There is no need to uninstall the previous version before installing this one. The old version will simply be replaced on install.

This beta installation will expire and no longer run at midnight on December 31, 2011.

Updates have been enabled for all current installations. To install the current version, use “Check for updates” from the Help menu. Settings are not compatible between the two versions, so they will have to be redone via the new Settings window. Update is not required if you would like to stay with version 1.3, despite it’s display bug.

Download links, release notes, known issues, etc after the jump.

New Features

• Compatibility with Mac OS X (Snow Leopard & Lion)
• Platform specific interface features & language
• Easily switchable, dedicated simulator and tablet launch targets
• No longer relies on batch files or standard Windows Command Prompt commands (except ping)
• Floating, transparent Settings/Preferences window for quick changes
• Compatibility with the BlackBerry® WebWorks™ SDK [the works!]
• Everything FruitBat will do for the AIR SDK, it will do for WebWorks
• Access to the FruitBat console in case you want to see the command line fly past as FruitBat works
• Link to order signing keys from RIM
• Automated registration for both your code signing key and debug token
• Create debug tokens
• Install debug tokens
• Package and sign final releases of your app with one click (Okay, it’s two, but at least you don’t have to touch the command line tools!)

Bug Fixes

• “undefined” app title, version and BAR file name issues have been resolved

Known Issues & Incomplete Features

There are a few lingering issues in this release, but it’s been far too long since the last release (especially with the display bug) to hold onto the release any longer. If you run into issues, feel free to leave a comment here or get in touch via the contact form (forums are coming).

These issues will all be addressed and do not need to be reported:

• “Copy FruitBat Settings/Preferences” menu item not enabled or implemented yet.
• Activate/Deactivate menu items do not perform any action yet.
• No alerts, notifications or messages are available outside of the Console window, so to see what’s going on, open it.
• Installing a debug token does not ping the tablet first, like the other actions, so it is slow to fail when the tablet cannot be reached via its IP address (debug tokens not required in the simulator).
• “Register Signing Keys” from the Publish menu does not perform any action. It was meant to be in this release, but it will be in the first update to the beta. Fixed in 1.4.0132.
• When choosing files and folders for the various settings, checks are performed on the selected files to make sure they are valid and what they’re supposed to be. If the check fails, no error is currently shown, but the file/folder browse dialog will open again immediately. Error dialogs are forthcoming and will ask for confirmation before opening the dialog again.
• I’ve tried to add messages to the console so you can see that something is happening (outside of the standard SDK output), but some actions may be missing their additional messages.
• Mac version has not been tested for registering signing keys, debug tokens or packaging a final release (which includes signing). If these do not work, please let me know. These commands are identical to the Windows version, which all work properly from my testing.
• WebWorks basic functions work, but you must have the WebWorks SDK set up properly, according to RIM’s instructions (especially regarding debug token and certificate [sigtool.p12]) before using any of the WebWorks features.
• For WebWorks, be sure to assign a build ID in your config.xml file by adding a fourth set of digits (between 0 and 999) in the version number [1.0.0.XXX]. FruitBat will use “0″ if no build ID is found. Opinions and comments welcome on whether FruitBat should add its own configuration file to your project folder to store an auto-incrementing build ID and any other project-specific settings that may be required in the future. This, of course, would be excluded automatically from any BAR files created via the app.

Not really an issue, but do not attempt to sign a BAR file created by clicking the “Package & Install” button on the main screen. For AIR applications, the debug flag is set, and for WebWorks, the browser inspector is enabled. Use the Publish menu to create final packages.

Please, let me know your thoughts and interest in the continued development of FruitBat in the comments section. Reporting bugs is also greatly appreciated.

Update

12:09: Just found a bug with ZIP file name generation that may stop WebWorks apps from packaging properly. Will issue an update later today to address it. Fixed in 1.0.0132.

The fix has already been completed for the next update.

MXSMaker Main Window

MXSMaker is a minimal application with only one button that does one thing – make MXS files for Painter, and it is as easy to use as it looks:

1. Click the Select Image button
2. Choose an image from the dialog
3. Save the converted file

In addition to the button, there are three other ways to create Mixer Pad files with MXSMaker, and all are just as easy and fast.

• Drag any JPG, PNG or GIF file over the application window and drop the file
• Copy and paste any compatible file from your OS’ filesystem using standard OS shortcuts
• Copy and paste any image data from any application (ex. a selection from Painter’s canvas, Photoshop, SnagIt or your web browser)

Automatic updates are included in the application and are checked every time the application starts if an active internet connection is available. This behavior cannot be turned off; however, downloading and installing an update is your choice.

Special thanks to Kaburaya for the first Mixer Pad online converter and David Gell for sharing it.

Using an MXS File

To load a converted MXS file into Painter, first make sure the Mixer panel is open. If it isn’t the panel can be accessed through the menu Window > Color Panels > Mixer or by using Ctrl/Cmd+2 from the default keyboard shortcuts.

Painter 12 Mixer Panel

Next, be sure to save the current Mixer Pad file if you’d like to use it again later. Painter will not ask you to save before opening the new MXS file, and the old Mixer Pad will be lost forever. The save command is in the Mixer panel’s menu at the top-right of the panel.

After saving, click the menu button once more and choose Open Mixer Pad. After choosing your file, it will be loaded and ready for color mixing and picking.

Known Issue

Copy and paste only works with Ctrl+V in Mac OS instead of Cmd+V because the default Paste shortcut from the application menu is taking over the command. An update will be issued to address this at a later date.

Update issued as version 1.0.101 that corrects all known issues.

1. Open the Settings panel by clicking the wrench icon in the title bar.
2. Leave your settings the way they are, especially User Mode which should be set to YES for most users. If you use a location that isn’t one of the default locations for Painter (ex. a folder on D: drive), skip steps 3 and 4.
3. For consistency choose Painter 11 from the Painter Version drop down.
4. Click the button that says Set to Default Location, then check the checkbox beside it for using a custom path.
5. If your path uses Application Data or AppData in Windows or Application Support on Mac OS, change 11 (or your version number) to 12 — this should be most users. If your path uses Program Files on Windows or Applications in Mac OS, change “Corel Painter 11″ to “Painter12″ with no spaces. Windows 64-bit users should also remove ” (x86)” — the space in front of it too–  from the Program Files folder name.

That’s it! This will install brushes into the Default workspace in the Painter Brushes library. Changing “Default” to another workspace name will use that workspace instead. Changing “Painter Brushes” to another library name will use that library instead. It’s all pretty straightforward.

If you do choose to use a different workspace or library, my recommendation is to use the Browse button that opens beside the path’s text box, just to make sure spelling and spacing are exact. The folder selection dialog that opens will be set to your current location and you should be able to see the folders for your other workspaces. Expand a workspace along with its Brushes folder and choose a library (any folder inside of the Brushes folder) and click OK. Now Brush Manager will install into the chosen workspace and library.

The BlackBerry PlayBook is finally here! This update to FruitBat adds the ability to install in-development apps to the PlayBook hardware for testing while using a debug token. It also has the ability to install and uninstall signed BAR files to and from the device.

Current users can update by choosing Help > Check for Updates from the application menu.

FlashDevelop Template Update

Along with FruitBat, the FlashDevelop template has been updated for the latest version of the Tablet OS SDK. Several fields have been added to the blackberry-tablet XML template. A new icon template and two splash screen templates (one for landscape orientation and the other for portrait) have been added as well. All of these items match the current BlackBerry application design guidelines.

Release Notes

• -devMode added to Package & Install command
• Install button removed from the multi-button
• On-screen icon display resized to 86×86 pixels
• Successful actions will close the command prompt window automatically
• Install command (Ctrl+I) from the application menu tested with signed BAR files
• Graphic templates added to FlashDevelop template
• blackberry-tablet.xml template updated for current SDK

Troubleshooting

The newest version of the Tablet OS SDK doesn’t show error messages in the same way it did in 0.9.4, and the errors I have seen may not match what’s really going on (or tell what needs to be fixed). If something happens, the FruitBat script will only give an generic error message and may or may not show the error message from the SDK. If you run into an error, the following list may help you locate the problem:

• Are you using the latest version of the SDK?
• Check the “Simulator IP Address” from the settings panel
• Make sure the password for the simulator/device is correct
• Make sure the device is in development mode
• If installing a debug version of an app, check to see if a debug token has been installed and is still valid (these installs only last 30 days)
• In the blackberry-tablet XML file, make sure you’ve used your exact vendor name from App World and have filled in the Author ID field with the correct value