evan's stuff - integration matters

TweetBot UI

2011-12-24T09:18:00.000+10:00

After the recent changes to the official Twitter iPhone app, I've done as others have - and looked at options.

At the moment, I'm trying TweetBot - self described as a Twitter app with personality.

And I'm really liking it. The transitions, animations and sounds make for an enjoyable experience.

But, there's a few little things which I think would improve it even further - one of which has been annoying me slightly (disproportionately to it's actual impact) - and that's the shape of the custom back button.

Let me illustrate ... here's a comparison shot between TweetBot - and the standard iOS back button:

I've highlighted the "problem" area - which shows:

the standard button has a much steeper angle, and finishes with a slight curve to the line
the TweetBot button is essentially a straight line (of a shallower angle) with a small curve at the end.

Like I said - not a major issue. But every time I see it, I think how it would be nice to have it as the standard shape.

Commuting with Helvetica

2011-09-08T15:10:00.000+10:00

Wow, Queensland Rail have recently upgraded their corporate branding - but it's only now that they seem to be rolling out the new station identities:

New Station Signage

And, they seem to have chosen Helvetica for the station signage as well - one of my favourite fonts. Who would have thought we would finally get some good design in our every day commuter life?

Strangely enough, some stations which have recently received new signs have had a similar version - but in italics! Quite bizarre. I'll update the post when I can take a picture.

Google Code - Part 1

2008-02-04T14:09:00.000+10:00

As I've mentioned earlier, I'm using Google Code to host the apselex project - an Adobe Photoshop Elements Explorer.

It is very easy to get started, and quite easy to use.

But, one thing was eluding me - how to use images in the wiki. I know - the help page has some examples, but as with all these things, the devil is in the details.

the image needs to be an external link
as such it needs to be hosted, and available
a "makes sense" approach is to store images in the wiki directory itself
and then simply point to the image with a link like this:

[http://apselex.googlecode.com/svn/wiki/ScreenshotExplorer.png]

Simple!

Naturally, using Eclipse, it was pretty straight forward to put some images in this directory. The approach I took was:

create a separate Eclipse project - mine was called ApselWiki
share this as a Team project (using subversion), and use the wiki as the URL

https://apselex.googlecode.com/svn/wiki

Note, that the wiki directory is outside the /trunk directory. That is, it's in the root of your project.
You can then simple paste new images into the Eclipse project - and also edit your wiki pages if you really like.
Then simply perform a "Team -> Synchronize"

Easy!

Photoshop Elements - Explorer Part 2

2008-01-29T16:17:00.000+10:00

Due to overwhelming demand (well, at least 1 person :-)), I've put up my initial code for exploring the Photoshop Elements database. For a small bit of background info, see my previous post.

I thought I'd give google code a try for hosting - as such, the project is located here.

Drop me a line in the comments if you're interested in participating.

Real World Usability

2008-01-08T15:40:00.000+10:00

This is a post on usability - in the "real world" - which may become something of a series.

The subject today is a ticket vending machine - not super exciting, but it's a a new model being rolled out in south east Queensland, so could be considered topical.

First, a picture:

Mmmm, what ever could be a problem with this shiny new design.

Well. A few things unfortunately. Let's see.

the coin slot. There's not enough room for a right handed person to insert coins, without constantly scraping them up against the side of the machine. Why?
the "ticket/change/receipt" hopper is too low. I understand that the machine needs to cater for people of all heights, including wheelchair access - but this is just too low. It requires constant stooping to fetch change and tickets.
the touch screen. I'm not sure where to start with this one, since there are so many aspects ...
1. the responsiveness (or lack of). there's a lag in the response - so that after you've pressed a soft button, you're not really sure if it's really pressed or not
2. the angle - unless your eyes happen to be perpendicular to the screen, your screen presses will be off the mark - it seems that there is enough of a gap between the surface of the touch screen, and the actual LCD screen that this is a real problem.

Then there's the interaction flow. The series of screens you have to wade through to get a ticket is just plain cumbersome. Some issues are:

To select a destination station, you need to go through a multi level alphabetical menu, or select from a "map". The map isn't too bad, but in combination with the "angle" problem, it's a little hard to use as well.

There are no direct keys for common stations

why not allow a one touch "daily to Central" from suburban machines?

I realise that these concerns will not be as prevalent once the smartcard side of things is operational (since most commuters will just use them to top up the value on their cards) - but they will still be relevant for paper tickets.

A little bit of research shows that these machines aren't a one off design for Translink - they're a customized version of an existing design which goes by the name of "Universal Vendor 1000". I wonder how much usability testing they did?

Photoshop Elements - Migrating to Version 6

2008-01-04T14:15:00.000+10:00

Well, I thought my migration to Adobe Photoshop Elements Version 6 was complete - and I was very happy with the way things had gone.

Until, I needed to print one of my pre-migration dated images.

I was greeted the following, rather unfriendly dialog, and could not print.

Wtf? I was concerned to say the least.

I re-traced some of my steps ...

newly edited photos would print ok
new (Version 6) photos were ok
old (pre-version 6) photos were ok
old, edited photos were NOT ok

I smelled a rat with the migration process for edited images. The edited images had seemed to be imported as version sets correctly. I did a bit more checking. The following grab shows a typical (albeit) sample image:

Note that the original image in the Version set is selected, and the Size attributes are displayed correctly in the Properties window.

Now, have a look at this next one, with the newer image from the Version set selected:

I've highlighted the problem area - the image width and height are missing. This was pointing to all not being well with the edited image.

I waded through the information on the Adobe support site here, I couldn't find any exact match. I even resorted to the forums, which are extremely painful to use - and still no match.

So, I thought - there's nothing for it but to submit a bug report. This itself was fairly painless, but disappointing:

no reference number, or tracking information was returned.
no acknowledgment that a bug had even been reported (via email, for example).

However, I was determined not to be beaten by this. I went back to the support documents, and found that a number of suggested fixes finished with the recommendation to use the "Update Thumbnail" command. What the? I didn't think that this would be appropriate for me - since my thumbnails looked fine, thank you very much.

Well, I thought - what could possibly go wrong ?

I'm pleased to report that - it actually fixed the problem!! Woo hoo. I was a little surprised, but relieved to say the least. A few years of editing had not been lost.

I was wondering why I needed to do this though - I used the supported Catalog conversion process. If PSE needed my thumbnails to be updated, I would have preferred them to be done as part of the migration process.

However, this exercise did open my eyes to the strange support mechanisms provided by Adobe. When the product itself sports a gleaming new interface, it's a little sad that the support facilities are somewhat lacking - and in case of those forums, downright primitive.

If any Adobe guys are around - I guess you can close my bug report too :-)

Cheat Sheet Extensibility - Part 2

2008-01-04T12:04:00.000+10:00

Oops.

I forgot to mention one of the little tricks required to make the cheat sheet actually usable - you need to be able to signal it's completion :-)

There are a few things required to make this happen:

the task requires a UI control which allows the user to signal that the task is complete. I used a form hyperlink control, similar to the following:

ImageHyperlink link = toolkit.createImageHyperlink(
form.getBody(),
SWT.WRAP);
Image img = AbstractUIPlugin.imageDescriptorFromPlugin(
Activator.PLUGIN_ID, "/icons/complete_task.gif").createImage();
link.setImage(img);
link.addHyperlinkListener(this);

a reference to the task being edited must be obtained. Fortunately, this is made available when the setInput method is called. In this method, use some code like this:
```
public void setInput(IEditableTask _task, IMemento memento) {
task = _task;
}
```
attach a listener to the control

when the link is activated, your listener will be fired. When this happens, the task should be set to complete. This is then just a simple method call using the task instance which has already been saved:
```
task.complete();
```

Cheat Sheet Extensibility

2008-01-02T16:06:00.000+10:00

I've been looking at the Eclipse Cheat Sheet capability recently - with a view to using it more as a workflow assistance tool, rather than a "follow these instructions" helper.
As such, the idea of crafting specific tasks that the user can interact with seems an appealing idea.
Here's a screen shot of a simple first attempt.

Note that I've used the Eclipse Forms controls to blend in with the "flat look" layout.
This was pretty easy to get going:

Define a task extension in your plug-in.

<taskEditor
class="mypdeproject.tasks.MyTaskExtension"
icon="icons/sample.gif"
id="MyPdeProject.taskEditor1">
</taskEditor>

Define the class referenced above. It needs to implement org.eclipse.ui.internal.provisional.cheatsheets.TaskEditor
Implement the required methods. The main one of which is the createControl method - to create the UI controls used to edit the task.
```
public void createControl(Composite comp, 
     FormToolkit toolkit) {

 form = toolkit.createForm(comp);
 form.setText("Hello, Eclipse Forms");

}
```
Obviously, you may want to define a few more fields in there than this.

Define a complex task, and then reference our newly defined task extension.

<task id="t2" kind="MyPdeProject.taskEditor1" 
  name="Extended task" 
  skip="false">
  <intro>
   Introduction Extended
  </intro>
  <onCompletion>
   This is the Conclusion
  </onCompletion>
</task>

And that's it! Simple really.
Next, I'll take a look at how you can use task variables to communicate between your tasks.

Getting started with XProc using Eclipse

2007-12-05T11:22:00.001+10:00

This post looks at how to get started with Norm Walsh's XProc implementation - using Eclipse.

XProc is an XML Pipeline Language, which is being defined by the folks at the XML Processing Model Working Group. Norm has an experimental implementation, hosted at https://xproc.dev.java.net/. The release notes are here.

Naturally enough, this is as a Netbeans project - but I thought I'd give it a try using Eclipse. It was pretty easy in the end:

Start your favourite Eclipse version - I used 3.3
Add in a Subversion plugin (since dev.java.net uses subversion). I've been using Subclipse lately. See http://subclipse.tigris.org/ for more details.
Point your SVN explorer to the repository https://xproc.dev.java.net/svn/xproc
Check out as a new Java Project using the Wizard.
Download (some of) the required frameworks ... I found that I could get by with Saxon 6.5 and Saxon 9 to get started. Add these .jars to the build path. Also note that you should add saxon9-s9api.jar as well as saxon9.jar.
Adjust the build path - so that these two directories are used as the java source:

java/src
java

The second is required, since a number of configuration files are referenced using a path like /etc/configuration.xml and as such, they need to be findable on the classpath. Eclipse will make sure that you exclude java/src from this include. Your classpath should look something like this:
I used the xproc.Driver class to do a simple test. It was not long before I realized that things were not happy due to my running on a Windows box. I needed to change this line:

hash.put(port, "file://" + fn);

to this:

hash.put(port, "file://" + "/" + fn);
I then needed to use this sort of command line arguments:

-i source=c:\fred.xml java/samples/count.xpl

Simple.

Here's a screenshot of the project contents:

Note that some errors are shown (since not all required libraries are provided), and that all three of the saxon libs are required.

And for good measure, here's a screen shot of a successful run:

Declarative Eclipse Branding with SVG

2007-11-27T14:43:00.000+10:00

Recently, I had need to add some Eclipse branding graphics to an RCP application.

Rather than take the "easy" route of using an image editor, I thought I'd explore the use of SVG to produce the required images in a declarative kind of way.

Using SVG for this purpose has a number of advantages ...

they are cross platform
the declarative, text file nature allows the content to be generated
they can be created using open-source tools

The downside is that the bitmaps required for Eclipse branding must be in BMP format - not the newer PNG alternative. This is covered in detail in this Eclipse bug report - https://bugs.eclipse.org/bugs/show_bug.cgi?id=21315.

Fortunately, this can be overcome by converting the SVG images to a bitmap format by using a conversion program called a "rasterizer".

A good example of a rasterizer is Batik - an open-source toolkit for manipulating SVG images.
See http://xmlgraphics.apache.org/batik/tools/rasterizer.html for further details on the Batik rasterizer.

Round Trip example

Here's a simple example of some SVG source to get started.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="500"
height="330"
id="drawing">

<defs>
<g id="mytext">
<text
xml:space="preserve"
style="font-size:40px;font-weight:normal;text-align:start;line-height:100%;text-anchor:start;font-family:Bitstream Vera Sans"
x="200" y="125">Hello</text>
<text
xml:space="preserve"
style="font-size:40px;font-weight:normal;text-align:start;line-height:100%;text-anchor:start;font-family:Bitstream Vera Sans"
x="200" y="170">World ...</text>
</g>
</defs>

<rect style="fill:black" width="500" height="330" x="0" y="0" />
<use xlink:href="#mytext" style="fill:white" />

</svg>

This produces a result like this:

In order to produce this image for the web, I used the Batik rasterizer. For example, the command I used was this:

C:\>java -jar c:\jshare\batik-1.7\batik-rasterizer.jar drawing5.svg
About to transcode 1 SVG file(s)

Converting drawing5.svg to drawing5.png ... ... success

Once you have a PNG format image, it's a "simple" matter of converting that to a BMP format. The simplicity involved depends on your platform:

if you're on Windows - you can use Microsoft Paint: open the PNG and then save as BMP
if you're on Linux - you can use GIMP

Refining your Image

Well, that's produced a very simple image. But one of the advantages of SVG is that you can get very nice effects with a minimum of effort.

Step 1 - Background Gradient

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="500"
height="330"
id="drawing">

<defs>
<g id="mytext">
<text
xml:space="preserve"
style="font-size:40px;font-weight:normal;text-align:start;line-height:100%;text-anchor:start;font-family:Bitstream Vera Sans"
x="200" y="125">Hello</text>
<text
xml:space="preserve"
style="font-size:40px;font-weight:normal;text-align:start;line-height:100%;text-anchor:start;font-family:Bitstream Vera Sans"
x="200" y="170">World ...</text>
</g>

<linearGradient id="top">
<stop offset="0%" style="stop-color: black;"/>
<stop offset="100%" style="stop-color: #484848;"/>
</linearGradient>

</defs>

<rect style="fill:url(#top)" width="500" height="330" x="0" y="0" />

<use xlink:href="#mytext" style="fill:white" />

</svg>

This produces a result like this:

Nice enough, but the default direction for a gradient is from left to right.

Step 2 - Background Gradient - in the correct direction

Here, we use another gradient - with a direction specifier - and embed the first.

<linearGradient id="top">
<stop offset="0%" style="stop-color: black;"/>
<stop offset="100%" style="stop-color: #484848;"/>
</linearGradient>

<linearGradient id="topa"
xlink:href="#top"
x1="0%" y1="0%" x2="0%" y2="100%"/>

</defs>

<rect style="fill:url(#topa)" width="500" height="330" x="0" y="0" />

This produces a result like this:

Step 3 - Background Gradient - with a horizon effect

This refinement adds a horizon - by splitting the image in two - at 200 px down, and using two gradients.

<linearGradient id="top">
<stop offset="0%" style="stop-color: black;"/>
<stop offset="100%" style="stop-color: #484848;"/>
</linearGradient>

<linearGradient id="topa"
xlink:href="#top"
x1="0%" y1="0%" x2="0%" y2="100%"/>

<linearGradient id="bottom">
<stop offset="0%" style="stop-color: #707070;"/>
<stop offset="100%" style="stop-color: black;"/>
</linearGradient>

<linearGradient id="bottoma"
xlink:href="#bottom"
x1="0%" y1="0%" x2="0%" y2="100%"/>

</defs>

<rect style="fill:url(#topa)" width="500" height="200" x="0" y="0" />
<rect style="fill:url(#bottoma)" width="500" height="130" x="0" y="200" />

This produces a result like this:

Step 4 - With a Graphic

Naturally, if we are doing a nice, modern style image, we should use some modern styled clip-art to give the image a lift. Since we are using SVG, there is a whole world of choice at the Open Clip Art project. For my Hello World example, I've chosen a nice clean globe.

In order to use a graphic, download the source to separate file. It can then be included in two different ways:

cut and paste the source code into your SVG file
save it to a separate file, and reference it as below using the image tag.

Note that I have applied a scale transformation to make the image fit in.

<g id="globe">
<image xlink:href="globe.svg"
width="500" height="500" x="0" y="0"
transform="scale(0.25)"/>
</g>

</defs>

<rect style="fill:url(#topa)" width="500" height="200" x="0" y="0" />
<rect style="fill:url(#bottoma)" width="500" height="130" x="0" y="200" />

<use xlink:href="#mytext" style="fill:white" />
<use xlink:href="#globe" x="60" y="80" />

This produces a result like this:

Step 5 - With a Reflection

No self-respecting modern image would be complete without the "reflection" technique! This is amazingly simple using SVG - just apply a transform effect on the use tag.

<use xlink:href="#mytext" style="fill:white" />
<use xlink:href="#mytext" style="fill:white;opacity:0.25" transform="matrix(1 0 0 -1 0 400)"/>

<use xlink:href="#globe" x="60" y="80" />
<use xlink:href="#globe" style="opacity:0.25" x="60" y="80" transform="matrix(1 0 0 -1 0 400)"/>

This produces a result like this:

Photoshop Elements - Explorer

2007-11-02T10:35:00.000+10:00

As a way of investigating the internals of the Adobe Photoshop Elements (PSE) meta tags, I thought I'd whip up a little Eclipse plug-in to do some experimentation.

The primary purpose was to provide a means of exporting my metadata. I do a little editing within PSE, but my largest investment is in the metadata attached to (almost) every photo.

I realize that you can (and should) backup your PSE catalog using the supplied tools, but this approach also provides a degree of independence should I ever wish to decamp to another product.

Plug-in Structure

The following diagram shows the plug-in dependency hierarchy. The diagram was produced using the brilliant Plug-in Dependency Visualization Tool from Ian Bull, also described here on his blog.

As can be seen from the hierarchy, I make use of a number of libraries, packaged as plug-ins.

XOM - to provide XML support. See here for more details on XOM.
SQLite JDBC driver. See here for more details.

I had a few choices about how I was going to deploy it - workbench, RCP or even scriptable via Eclipse Monkey ... but I thought the workbench plug-in would be the simplest thing to get started.

Workbench Integration

Since I was aiming for the workbench, it made sense to provide some integration with the functionality you get for free! The two most obvious points are:

workbench properties
an image viewer

It's very easy to integrate with the workbench Properties View. This is very well documented - in particular in this article.

I have also encountered a great image viewer, courtesy of Wayne Beaton - see here for more details.

The great thing about making use of these functions is that they simply require an adapter to the required class to exploit the functionality.

the Properties View needs an adapter to an IPropertySource implementation
the Image View plug-in requires an adapter to an ImageProvider implementation.

To keep things simple, I initially coded up the getAdapter code directly into the model - but, with a teeny bit of thought - and prompting from Wayne's latest "adapters" articles here - it made sense to extract them into an AdapterFactory. And after doing this, it made sense to extract the whole model to it's own plug-in.

Plug-in Functionality

It's pretty basic - a simple PSE Explorer View, which lists the contents of the catalog, and two menu options:

one to load an existing PSE catalog file (SQLite database)
one to export the loaded PSE catalog as an XML Document.

The following screen shot shows the plug-in in action - with the PSE Explorer view on the top half of the screen, and the properties and Image View on the bottom.

The plug-in functionality is initiated by the two command handlers (corresponding to the menu items) - that is, import and export.

The import function is facilitated by a simple DataProvider class. This provides the means of accessing the SQLite database and populating the model used by the viewer. The SQL used is similar to my earlier experiments.

The export function merely provides an XML transformer for the populated model. The results of the export looks like this:

Summary

This is just a starting point, but it has provided a easy way for exploring the PSE metadata. With a bit more polish, I'll see if I can release some of the code.

Photoshop Elements - User Interface

2007-10-24T14:53:00.000+10:00

In my recent experimentation with Photoshop Elements 6 (PSE6), I was quite surprised by some of the user interface (UI) techniques employed.

For example, with the "Albums" and "Keyword Tags" palettes, there is a "New" button, as shown below - the bright green cross -

When you hover, the tooltip text shows as below:

But what if you wanted to collapse or expand the tree? There doesn't seem to be any actions available for that. Let's click the "New" button - which is a pull-down, and see what happens ...

Aaahhh. There they are. At the bottom of the "New" menu.

what the?

It seems that it's basically overloading that first tool bar button. I'm not sure why. For fear of cluttering up the tool bar perhaps.

An alternative would be to make the buttons explicit - perhaps like the Eclipse style ones shown here (as the boxed "-" and "+"):

A little more thought needs to go into style guides for these interfaces I think.

Photoshop Elements - Smart Albums

2007-10-23T10:53:00.000+10:00

My investigations are continuing with Adobe Photoshop Elements 6 (PSE6). And this post looks at the new feature called Smart Albums.

They are based on the same concept as the Smart Playlist in iTunes. That is, they are defined searches - rather than specific, static items - so that the Album contents always stays current.

It is a good feature to include, and in general seems well done. But, I've encountered a few usability issues which seem important.

1. User Interface to Modify a Smart Album

This seems strange. The problem is that there are two different "edit" operations - the most obvious seems to be to select the Smart Album, and then the Edit toolbar icon. In this case, I've selected the album called "Smart Taxis".

Indeed, the hover text indicates "Edit Smart Taxis Album". When you select this action, you get a dialog which only allows you to change the name! It conveniently tells you about the criteria though.

To modify the search criteria, you instead need to follow this process:

Active the smart album, by selecting it from the Album palette
From the organizer, select the Options pulldown
Then select "Modify Search Details"
You then, finally, see the dialog - which is entitled "Find by Details (Metadata)"
You then still need to make the changes you need, and if you want to change that same album, select the check box and type your original name, and press "Search" ??
A helpful dialog then tells you that this album exists, and would you like to replace it.

OMG! In doing this post, I've just realized that it doesn't replace your album - PSE6 adds another album - with the same name.

To be slightly fair, the dialog text doesn't actually say it's going to replace that album - it says "Click OK to create a Smart Album with this name anyway". I guess it could be seen as helping to provide some form of version control. But still, it doesn't seem terribly obvious.

What's going on here?

It seems that there is a basic disconnect between the two halves of the screen - the Organizer on the left - with the find bar showing Search Criteria - and the Album palette on the right - which talks in Albums.

2. Smart Album search criteria

Unfortunately, some of the search criteria available seems a little restrictive - that is, a bit lacking in flexibility. Some examples may help to illustrate:

Can't use "not Include" with the "Keyword Tags" search - only Include:
Can't use Smart Albums as the argument with the "Albums" search. The only albums presented in the list are standard (static) Albums.

This would allow for a tree structured, or nested style search. This is also something which iTunes seems to manage ok.

I'm sure there are others, but these are the ones which seem to leap out.

Conclusion

Smart Albums is a good start - but it would nice to see them just a little bit smarter ... and easier to use.

Exploring the PSE6 Database

2007-10-16T15:52:00.000+10:00

Curiosity has got the better of me, and I needed to see a little bit more of the Photoshop Elements 6 (PSE6) database.

You can use standard SQL to poke around, but for simple things I found a great tool in SQLite Expert Personal. It's a simple database exploration tool. The main screen looks like this:

Naturally, I also needed to try some SQL too. This query retrieves the Star rating (from 0 to 5) for all images:

select media.id as recid, media.full_filepath
, mdint.value as rating
from media_table as media
join media_to_metadata_table as mm on media.id = mm.media_id
join metadata_integer_table as mdint on mm.metadata_id = mdint.id
join metadata_description_table as mdesc on mdint.description_id = mdesc.id
where mdesc.identifier = "xmp:Rating"
and mime_type = "image/jpeg"

Another test query is to retrieve the user tags for an image:

select media.id as recid, tt.name
from media_table as media
join tag_to_media_table as t2m on media.id = t2m.media_id
join tag_table as tt on t2m.tag_id = tt.id
where media.id = 276
and type_name like 'user%'

I think that I'll put these to further use soon.

Eclipse Commands

2007-10-15T15:11:00.000+10:00

The new command framework for Eclipse looks quite good. But I found it a little hard to get started with it.

I've found some really useful info here though:

One problem I've encountered though, is how to determine the command Id for an existing workbench function. In this case, I wanted the "Help -> About" function to be present in my RCP app.

I stumbled across a simple solution - cheat! That is, use the Cheat Sheets wizard to give a helping hand. (Thanks to Chris Aniszczyk for his informative article on Cheat Sheets - reading it gave me the inspiration for this!)

Create a new cheat sheet, by selecting File -> New ... and then selecting "Cheat Sheet".
Just use any name, and specify a "Simple" cheat sheet.
Once in the editor, select the "Item" - and on the right hand side of the form, you will be able to specify a command - using the gift of Browse.
Click on the Browse button, and you'll be presented with a list of common workbench commands. For example:
You can then select the Command, and even press "Execute" to try it.

I've found this a handy trick.

Photoshop Elements

2007-10-12T13:36:00.000+10:00

Well, I finally took the plunge - and upgraded my Photoshop Elements 3.0 (and Photoshop Album) to the new Photoshop Elements 6.0 (PSE6).

A few things caused the change:

the old version was starting to creak a little bit
lots of annoying little bits -like no alternative date format
the ability to use star ratings
the shiny new interface looked cool!

The upgrade went really well. As other people have noticed - you need to then manually go and convert your old catalogs using the "Catalog Manager" (File -> Catalogs ...).

One disappointment is that there (still) does not seem to be an adequate interface to Flickr. What is with the whole Adobe Partner Services thing? As such, in the past I've whipped up some Java to scan my PSE catalog (stored in an Access/Jet style) database, and reconcile that against my Flickr account - using the flickrj project as the framework.

One pleasant surprise is that the framework used to store the database has been updated. It now uses something called SQLite. This looks really interesting, as it is a well featured SQL database, which stores it's entire contents in a single file. (Apparently, Lightroom also uses SQLite, but I think a different schema.)

Naturally, I needed to check out the schema. Two ways spring to mind:

Native access - via the SQLite facilities
JDBC access.

A few little notes on each follow below.

Native SQLite Access

download the executable from here. This gives you a zip. Simply extract the contents - a single .exe to a location of your choice.
locate your PSE catalog location - an easy way is to use the Help -> System Info ... menu option.
use the command sqlite3 filename

This gives you a simple command line interface. The commands are all "." prefixed - for example, use ".help" to get started.

JDBC

There is a JDBC interface available. I decided to try the one available here. It was a simple matter of:

create an Eclipse project (or IDE of choice)
add the jar file to the class path
use the sample code to start exploring

It does seem very straightforward. I'll post some code, etc after a bit more digging.

Serving it up

2006-05-09T20:03:00.000+10:00

Isn't it about time that we got the mainframe to actually serve up something useful - you know, in a server kind of way.

Working in a support role, a common task involves checking the output of previous jobs via ISPF - and, more specifically SDSF. Well naturally, there's always a better way.

For a while now (must check when), z/OS has provided an FTP interface to the JES facilities. This allows for all sorts of goodness:

being able to list jobs
retrieving all output datasets for a job
submitting jobs.

... all from the comfort of your FTP client!

What's that? You'd rather use SDSF than an FTP command line to inspect output. Of course you would. But what if you could craft a custom Java interface! Now we're talking. Say tuned for more details.

Monkey Matters

2006-03-30T14:54:00.000+10:00

The Eclipse Monkey scripting stuff looks cool. The ability to easily wire-up your own (& others) DOMs will make for handy little apps. Wayne Beaton has a great example here.

I thought I'd give it a go - but hit a small hurdle when trying to access my own DOM. The notes on the Eclipse site give the syntax:

DOM: http://update-site/plugin-id

My problem was - I didn't have an update site: I was doing this all on a local PC.

As ever, the answer was in front of my nose - or rather, in the code ... A quick check of the monkey code reveals that the metadata is simply extracted using a regular expression. In this case, it's this:

DOM:\s*(\p{Graph}+)\/((\p{Alnum}|\.)+)

meaning, anything before the slash is considered the URL, anything after is the plugin-id. And reading a little more reveals that Monkey will try and see if your plugin is loaded first - before using the update-site.

It was then a simply matter of:

exporting the plugin containing my DOM.
then installing my plugin in my workspace (copy to plugin directory)
and then running the script!

I finally had access to my DOM !! plus, learnt a little of the Monkey internals on the way :-)

My First Post

2006-03-11T14:01:00.000+10:00

Ok, I guess that everyone does one of these ...

fingers crossed X.