Converting List to Enumeration in Kotlin

There’s a bunch of helper extension methods that the Kotlin standard library provides for working with collections. However, it would seem that at the present moment java.util.Enumeration has been left a bit behind. Here is a simple extension method to convert any List to a matching Enumeration:

/**
* Extension function for converting a {@link List} to an {@link Enumeration}
*/
fun <T> List<T>.toEnumeration(): Enumeration<T> {
return object : Enumeration<T> {
var count = 0

override fun hasMoreElements(): Boolean {
return this.count < size
}

override fun nextElement(): T {
if (this.count < size) {
return get(this.count++)
}
throw NoSuchElementException("List enumeration asked for more elements than present")
}
}
}

And here is how you can use it to expose the local file system to the JTree component. First, we create a custom implementation of the TreeNode interface:

data class FileTreeNode(val file: File?, val children: Array<File>, val nodeParent: TreeNode?) : TreeNode {
constructor(file: File, parent: TreeNode) : this(file, file.listFiles() ?: arrayOf(), parent)
constructor(children: Array<File>) : this(null, children, null)

init {
children.sortWith(compareBy { it.name.toLowerCase() })
}

override fun children(): Enumeration<FileTreeNode> {
return children.map { it -> FileTreeNode(it, this) }.toEnumeration()
}

override fun getAllowsChildren(): Boolean {
return true
}

override fun getChildAt(childIndex: Int): TreeNode {
return FileTreeNode(children[childIndex], this)
}

override fun getChildCount(): Int {
return children.size
}

override fun getIndex(node: TreeNode): Int {
val ftn = node as FileTreeNode
return children.indexOfFirst { it -> (it == ftn.file) }
}

override fun getParent(): TreeNode? {
return this.nodeParent
}

override fun isLeaf(): Boolean {
val isNotFolder = (this.file != null) && (this.file.isFile)
return this.childCount == 0 && isNotFolder
}
}

Note a few language shortcuts that make the code more concise than its Java counterparts:

• Since File.listFiles() can return null, we wrap that call with a simple Elvis operator: file.listFiles() ?: arrayOf().
• The initializer block sorts the File children in place by name.
• To return tree node enumeration in children(), we first map each File child to the corresponding FileTreeNode and then use our extension function to convert the resulting List to Enumeration.
• Looking up the index of the specific node is done with the existing extension indexOfFirst function from the standard library.

Now all is left to do is to create our JTree:

val tree = JTree(FileTreeNode(File.listRoots()))
tree.rootVisible = false

Replacing SwingWorker with Kotlin coroutines

Kotlin 1.3 is right around the corner, and one of the major additions to the language is going to be the official graduation of coroutines from experimental to stable. Let’s take a look at how we can replace the old and venerable SwingWorker with something that is a bit more modern.

In the simplest use case, you do some kind of long-running work in your doInBackground() and then process the result of that work in done():

object : SwingWorker<List<StringValuePair>, Void>() {
@Throws(Exception::class)
override fun doInBackground(): List<StringValuePair>? {
return bar.callback.getLeafs(newPath)
}

override fun done() {
try {
filePanel.setFolder(get())
} catch (exc: Exception) {
}

}
}.execute()

There’s a whole bunch of noise, so to speak, around the core of the logic – calling breadcrumb bar’s callback to get the leaf content for the newly set path, and then populating the folder based on the retrieved content. Let’s see how this code can look like with coroutines:

filePanel.setFolder(async {
bar.callback.getLeafs(newPath)
}.await())

In this case, we have distilled the core of the logic flow to its essence – asynchronous loading of the leaf content, followed by updating the UI. Another option is to collapse the async / await block into a single withContext to change the execution context away from the UI thread:

filePanel.setFolder(withContext(DefaultDispatcher) {
bar.callback.getLeafs(newPath)
})

Note that once you switch to coroutines, you also need a larger context for proper synchronization. In Swing, it means wrapping the entire listener with launch(Swing):

// Configure the breadcrumb bar to update the file panel every time
// the path changes
bar.model.addPathListener {
launch(Swing) {
val newPath = bar.model.items
if (newPath.size > 0) {
// Use the Kotlin coroutines (experimental) to kick the
// loading of the path leaf content off the UI thread and then
// pipe it back to the UI thread in setFolder call.
filePanel.setFolder(withContext(DefaultDispatcher) {
bar.callback.getLeafs(newPath)
})
}
}
}

Now let’s take a look at something a bit more interactive – updating the UI on the ongoing progress of a long-running background task.

Let’s add a button and a label to a sample frame, and kick off a 5-second task that updates the UI every second on the progress using SwingWorker.process():

val button = JButton("Start operation!")
val status = JLabel("Progress")

frame.add(button)
frame.add(status)

button.addActionListener {
class MyWorker : SwingWorker<Unit, Int>() {
override fun doInBackground() {
for (i in 1..5) {
publish(i)
Thread.sleep(1000)
}
}

override fun process(chunks: MutableList<Int>?) {
status.text = "Progress " + chunks?.joinToString()
}

override fun done() {
status.text = "Done!"
}
}

val worker = MyWorker()
worker.execute()
}

The first way to convert to coroutines would be with the help of channels:

button.addActionListener {
launch(Swing) {
val channel = Channel()
async {
for (x in 1..5) {
println("Sending $x " + SwingUtilities.isEventDispatchThread())
// This is happening off the main thread
channel.send(x)
// Emulating long-running background processing
delay(1000L)
}
// Close the channel as we're done processing
channel.close()
}
// The next loop keeps on going as long as the channel is not closed
for (y in channel) {
println("Processing $y " + SwingUtilities.isEventDispatchThread())

status.text = "Progress $y"
}
status.text = "Done!"
}
}

Note the usage of Swing context that is passed to the launch() function and the wrapping of the emulated long-running task in the async lambda. Then, as long as that lambda keeps on sending content into the channel, the for loop iterates over the channel content on the UI thread, and then relinquishes the UI thread so that it is no longer blocked.

Now let’s make it a little bit more structured. While code samples found in documentation and tutorials run on the lighter side of things (including this article), real-life apps would have more complexity on both sides of async processing. We’re going to split this logic into two parts – background processing of data and updating the UI on the main thread. Background processing becomes a separate function that returns a data channel:

fun process() : ReceiveChannel {
val channel = Channel()
async {
for (x in 1..5) {
println("Sending $x " + SwingUtilities.isEventDispatchThread())
// This is happening off the main thread
channel.send(x)
// Emulating long-running background processing
delay(1000L)
}
// Close the channel as we're done processing
channel.close()
}
return channel
}

And UI code consumes the data posted to the channel and updates the relevant pieces:

button.addActionListener {
launch(Swing) {
// The next loop keeps on going as long as the channel is not closed
for (y in process()) {
println("Processing $y " + SwingUtilities.isEventDispatchThread())

status.text = "Progress $y"
}
status.text = "Done!"
}
}

Let’s make the background task cancellable so that the currently running operation can be safely canceled without subsequent erroneous UI updates. Background processing returns an object that has two parts – data channel and a job that can be canceled if needed:

class ProcessResult(val resultChannel: ReceiveChannel, val job: Deferred)

fun processCancelable() : ProcessResult {
val channel = Channel()
val job = async {
for (x in 1..5) {
if (!isActive) {
// This async operation has been canceled
break
}
println("Sending $x " + SwingUtilities.isEventDispatchThread())
// This is happening off the main thread
channel.send(x)
// Emulating long-running background processing
delay(1000L)
}
// Close the channel as we're done processing
channel.close()
}
return ProcessResult(channel, job)
}

And on the UI side of things, we keep track of the last job that was kicked off and cancel it:

var currJob: Deferred? = null

button.addActionListener {
launch(Swing) {
currJob?.cancel()

val processResult = processCancelable()
currJob = processResult.job

// The next loop keeps on going as long as the channel is not closed
for (y in processResult.resultChannel) {
println("Processing $y " + SwingUtilities.isEventDispatchThread())

status.text = "Progress $y"
}
status.text = "Done!"
}
}

Finally, we can move away from the existing concept of data communication “pipe” between the two parts, and start thinking in terms of passing a lambda to be invoked by the data producer when it has completed processing the next chunk of data. In this last example, the producer marks itself with the suspend keyword and uses the parent context so that cancellation is properly propagated:

suspend fun processAlternative(progress: (Int) -> Unit = {}) {
for (x in 1..5) {
// Emulating long-running background processing.
// Use the parent job so that cancellation of the parent propagates in here.
async(parent = coroutineContext[Job]) {
println("Running on " + SwingUtilities.isEventDispatchThread())
delay(1000L)
}.await()
// And calling the callback on the UI thread
println("Sending $x " + SwingUtilities.isEventDispatchThread())
progress(x)
}
}

And the UI side of things supplies a lambda that updates the relevant UI pieces:

var currJob: Job? = null

button.addActionListener {
currJob?.cancel()

currJob = launch(Swing) {
// This will run until all the sequential async blocks are done
processAlternative { progress ->
println("Processing $progress " + SwingUtilities.isEventDispatchThread())

status.text = "Progress $progress"
}
status.text = "Done!"
}
}

If you want start playing with replacing SwingWorker with coroutines, add org.jetbrains.kotlinx:kotlinx-coroutines-swing and org.jetbrains.kotlinx:kotlinx-coroutines-jdk8 to your dependencies. The latest version for both of the modules is 0.24.0.

The art and craft of screen graphics – interview with Gladys Tong

Continuing the ongoing series of interviews on fantasy user interfaces, it’s my pleasure to welcome Gladys Tong. She started her company G Creative Productions about 20 years ago, and since then the studio’s work was featured in a wide array of productions such as I, Robot, Fantastic Four, 2012, Watchmen, Man of Steel, Ender’s Game, Elysium, Chappie, Godzilla, Altered Carbon, The Cloverfield Paradox, Batman v Superman and Star Trek Beyond.

Screen graphics for Batman v Superman: Dawn of Justice. Courtesy of G Creative and Warner Bros.

Kirill: Please tell us about yourself and your path so far

Gladys: My name is Gladys Tong and I run a small company called G Creative Productions. I have always loved art and science so when I discovered that I could make a living combining the two, I jumped in with both feet! When I started 20 years ago, there were not a lot of people doing what I do today so the path for me has been relatively uncharted. It has led me to an interesting career and some wonderful people whom I have had the good fortune to work with.

Kirill: What drew you into the field of interactive motion graphics, and how has that changed since you’ve started working professionally in this field?

Gladys: As I mentioned, I was always interested in art and science. From drawing at an early age to learning about multimedia with computers it was a natural evolution for me to be drawn to interactive motion graphics. Twenty years ago most people including my friends and family did not understand what I did. Now with more exposure through films and tv shows as well as online access to information it has exploded and now there are more people and companies in this field. It’s an exciting time.

Screen graphics for X-Men: Last Stand. Courtesy of G Creative and 20th Century Fox.

Kirill: What can you tell us about G Creative?

Gladys: I started the company in Canada and chose the name in a hurry. I wanted something short and simple – just a letter but wasn’t allowed to incorporate a company with just one letter of the alphabet so I had to come up with a longer name. Many people assume that the G stands for Gladys but it actually represents more than me – graphics, geek, gear, green (for green screen) to name a few. I like the ambiguity and endless possibilities. Much like what we do there are no right answers to everything but many possible answers.

G Creative’s mission statement is to fuse compelling imagery with targeted technology to present a story that inspires, entertains, and informs an audience. This represents a philosophy that I try very hard to achieve in practice through the work we do both in hardware and software services as well as the people I work with. I have a great collective of talented artists, designers, and technicians whom I am thankful for.

Screen graphics for The A-Team. Courtesy of G Creative and 20th Century Fox.

Kirill: When you meet a new person and they ask you what you do for a living, how do you describe it?

Gladys: When I meet a person that I don’t know I tend to describe what I do with words that are more general and easy to comprehend. So I tend to say computer graphics as that seems to be received with nods of understanding. If the conversation goes further, I usually elaborate with the film industry which yields similar nods of familiarity. If I actually describe what I do, I get perplexed facial expressions that suggest a need to decipher this cryptic job I have.

What I do for a living is not as common so people have a harder time grasping the fact that there is a job like this and that it involves a seemingly unusual combination of tech and creativity. Even people that I work with within the film industry sometimes find what we do strange or surprising. In a world that’s increasingly converging I think that will be less so.

Screen graphics for Robocop. Courtesy of G Creative and Columbia.

Continue reading »

Cinematography of “Ozark” – interview with Ben Kutchins

Continuing the ongoing series of interviews with creative artists working on various aspects of movie and TV productions, it is my pleasure to welcome Ben Kutchins. In this interview he talks about his early experiments with film and the influence of that phase on his work, the importance of learning from mistakes, hiding the technical complexity around the shots and making them look effortless, and the transition of the industry from film to digital. Around these topics and more, Ben dives deep into his work on the first season of the critically acclaimed “Ozark” on which he shot six of the ten episodes.

Kirill: Please tell us about yourself and your path so far.

Ben: When I was 12, I found my dad’s old 35mm camera buried in a drawer collecting dust. There was a drug store near my house that sold film and processing, so I started taking pictures of my friends. I became more and more interested in what the world looked like through a lens.

I took pictures all the way to the college, when I got a summer internship with Lucasfilm at Industrial Light & Magic, and that was the first time that I saw people making movies. Like for most people, it was a complete mystery what happened behind the curtain. When I saw the craftsmanship that goes behind making something, I was hooked.

I saw a cinematographer lighting a miniature set from Jumanji that was going to get blown up. He spent a whole day lighting a miniature that was going to be on screen for something like two seconds, and most of that time it would be exploding. But he was giving so much care to every flag placement and every detail of how it was lit. That fully captured my interest. It was at that moment, I thought to myself, “I want to do that.”

I worked at Lucasfilm for a few years. It started as the internship, and then they offered me a full time position in the still photography department. They had a full photo lab and I was given time and materials to experiment and learn about film. My background is in film and photochemical process, and Lucasfilm is where I started developing different looks, cross-processing, over-exposing, under-exposing, using different stocks to see how they reacted. It’s not something that I utilize today at the technical level, but it fully influences what I do creatively. Most of choices are made in a digital world, but the idea of strong color choices, strong grain and texture, creating a vibe or a mood comes from the photochemical process and that time of experimentation.

There came a point during my time at ILM that it became clear that if I stayed there, my job would end up being creating computer-generated graphic work. When Lucasfilm originally offered me the job, I had quit school. I knew that I didn’t want to spend my life at a computer, so I decided to go back to school and study filmmaking.

I transferred to NYU and it was an amazing experience. I shot around 60 films in two years. There were only about four or five students interested in cinematography, and the rest wanted to be directors. The four of us included Rachel Morrison who just shot “Black Panther” and Reed Morano who directed “The Handmaid’s Tale” and a handful of other productions. It was a great opportunity for us to be able to shoot all those films for all the people who wanted to be directors. It’s where I learned the basic language of filmmaking. The majority of those I did hand-holding the camera in one hand, sometimes a china ball lantern in the other, running around the streets of New York shooting.

I only learn by making mistakes, and it was a great opportunity to make lots of mistakes. Some of those “mistakes” I love and I use today, and some of those taught me lessons and I try to never repeat them [laughs].

Kirill: Was there ever any disappointment in those days to see those tricks that almost fool the viewers to believe into seeing something on the screen that is not there on the set?

Ben: I was fascinated by the extreme amount of hard work that it takes, and I was never obsessed with thinking that we were fooling the audience. I am fascinated today still, and I am always deeply engaged in the process. When you are right in the middle of a setup or a shot, and you are trying to figure out the brutal honesty of the story that you want to tell, everything else falls away.

That is the reason why I keep on coming back to filmmaking. It’s the reason why I will always love it. Everything else falls away and time doesn’t matter. There is no moment where I’m thinking about the external world or what I should have for breakfast tomorrow. So there is no moment where I feel that we are lying to people. The reality is that we are not lying. At that moment I am fully engaged in the story that I am trying to tell, and I am looking for the truth and honesty of that moment.

You can view it as a trick, or you can view it as my truth. What is my memory of when somebody really hurt my feelings? What is my memory of pure joy? What is my memory of someone being dishonest? What does that feel like, and how do I translate that onto the screen so that the viewer feels just a tiny bit of what I am feeling? If I can transmit just the tiniest bit of that feeling, then I’ve done my job. For me, it’s the search for the truth.

Kirill: Is there anything that still surprises you when you join a new production and start working on it?

Ben: One of the things that I love is that each production is its own living breathing entity. It’s always a collaboration of a large group of people. We rely on everybody to make this dream come true. Everybody needs to get things done, no matter which level of the production hierarchy they are on.

It’s an ever-changing group of people. It’s a new group of people that work and think differently. The pace is different, the aesthetic is different, and there’s a difference about what is important. The environment is ever-changing and you have to adapt. I can’t come in and force my will on a production. I have to be malleable. I have to adapt myself to the situation that presents itself.

Kirill: When you meet somebody new at a party and you talk about what you do for a living, do you think they realize how much goes into what you do?

Ben: When I talk about what I do, I think that they imagine me with the camera on my shoulder running around and pointing the camera at things. They might also think that we can shoot the whole movie in a few days, and they might not even understand why that is impossible.

People that know me, people that I have real relationships with, know how much I work and how hard that work is, even though they are not in my field. But I don’t think that there’s any way, until you’re there, to really understand what we are doing and why it takes so much time. Sometimes it’s mind-numbing to think about all the details that go into making a particular shot work. You can spend multiple days doing just one complicated shot. It would be two days rehearsing it and then one more whole day shooting it. I think that is really hard to comprehend.

People would probably just think that we’re lazy or stupid from the outside [laughs].

Continue reading »