Richard Jones' Log: Some updates
I'm still loving the new job. As part of it I've been developing a GUI framework which integrates with and uses some of the design patterns from pyglet. GUIs may be defined wholly in Python code or in a combination of Python and XML files. There's the beginnings of a GUI designer tool to create the XML files. A simple, dumb example:
<frame is_transparent="true">
<frame is_transparent="true" id="left-frame" width="50%" height="100%">
<vertical align="top" halign="center" padding="20">
<frame scrollable="true" width="256" height="256" class="draggable">
<image file="kitten.jpg" id="kitten" />
</frame>
<frame scrollable="true" width="128" height="128" class="draggable">
<xhtml>
<h1>Synopsis</h1>
<p style="font-size:12px">Lorem ipsum dolor sit amet consectetuer
adipiscing elit. Suspendisse vel tellus. Nam sem massa, accumsan id,
sollicitudin at, feugiat non, felis. Etiam nunc. Nam augue mauris,
semper in, hendrerit vitae, congue viverra, massa. Suspendisse at lacus.
Proin mollis dui ut sem. Donec auctor, pede nec hendrerit tincidunt,
lacus diam laoreet diam, ut varius odio felis eget enim. Curabitur dui
sem, rutrum sed, mattis eu, rhoncus ultrices, erat. Maecenas eu tellus.
Vivamus bibendum facilisis orci. Aliquam risus. Aliquam erat. Aenean
dignissim fringilla diam. Quisque dapibus, nulla non consectetuer iaculis,
velit urna ornare orci, quis sodales neque sapien id turpis. Etiam urna
lacus, vulputate congue, vulputate in, aliquet vitae, tellus. Maecenas
sem. Ut sed massa. Etiam non ipsum eget nibh cursus placerat.
Vivamus at mauris.
</p>
</xhtml>
</frame>
<button class="draggable" text="Drag me, press me!" id="press-me" />
<textinput value="Enter text" width="128" />
<movie file="/Users/richard/Desktop/movies/Sunshine SD.mov" />
</vertical>
</frame>
<frame class="droppable" width="50%" height="75%" x="512" y="128">
<label>Drop here!</label>
</frame>
</frame>
So this splits the window into two halves. On the left half we have a picture of a kitten (larger than the containing frame and scrollable), some XHMTL (again scrollable), a button to click, a text input field and a movie. Take note of the classes and ids, they're used...
And then some Python code to make this GUI do fun things:
from pyglet.window import *
from pyglet import clock
from pyglet.gl import *
from pyglet import media
import gui
from gui import event, dialog, dragndrop, anim
window = Window(width=1024, height=768, vsync=False)
gui = gui.GUI.fromXML(window, 'test_gui.xml')
window.push_handlers(gui)
@gui.select('frame')
def on_mouse_press(widget, x, y, buttons, modifiers):
if not buttons & mouse.MOUSE_RIGHT_BUTTON: return event.EVENT_UNHANDLED
def _f(*args):
print 'Dialog returned', args
dialog.FileDialog(gui, 'Select file to open', _f).run()
return event.EVENT_HANDLED
gui.push_handlers(dragndrop.DragHandler('.draggable'))
@gui.select('button')
def on_click(widget, x, y, button, modifiers):
print 'BUTTON PRESS', widget
return event.EVENT_UNHANDLED
@gui.select('button#press-me', 'on_click')
def on_press_me(widget, x, y, button, modifiers):
fr = widget.getGUI().getByID('left-frame')
if fr.scale == 1.:
anim.TranslateProperty(fr, 'scale', .5, duration=.5)
else:
anim.TranslateProperty(fr, 'scale', 1., duration=.5)
return event.EVENT_UNHANDLED
@gui.select('.droppable')
def on_drop(widget, x, y, button, modifiers, element):
element.reparent(widget)
widget.bgcolor = (1, 1, 1, 1)
return event.EVENT_HANDLED
@gui.select('.droppable')
def on_drag_enter(widget, x, y, element):
widget.bgcolor = (.8, 1, .8, 1)
return event.EVENT_HANDLED
@gui.select('.droppable')
def on_drag_leave(widget, x, y, element):
widget.bgcolor = (1, 1, 1, 1)
return event.EVENT_HANDLED
while not window.has_exit:
clock.tick()
window.dispatch_events()
media.dispatch_events()
glClearColor(.2, .2, .2, 1)
glClear(GL_COLOR_BUFFER_BIT)
gui.draw()
window.flip()
So the fun bits of this code is where we assign behaviors to gui elements based on the CSS-style selectors. All items that are of class "draggable" are draggable, and the right-hand frame is designated a drop area. The kitten, XHTML and button are draggable into that frame. The frame highlights as you hold a dragged item over it. A right-mouse click will open a file dialog. A click on the "press me" button is fun - it scales the left-hand frame (smoothly animated and still fully interactive even during the animation).
I have permission to release this code, which I will eventually do once I have some spare tuits here at work. The designers here have just handed me some more storyboards to implement :)
Speaking of whom -- when they heard about the addition of "wet floor" to the OS X dock, the reaction was quite fun. They can be quite bitchy about designers over-using the latest cool effect (see also spiral logos suddenly abounding when Illustrator got the spiral tool). "Do Apple designers have a big red 'wet floor' button on their computer or something?"
Also, it's a pain to lay out GUIs in code ;)
Wow, your post covered a lot of different interesting things... so here's some stream of consciousness to throw at you(spew at you?). Ok, I just had two cups of coffee, and couldn't seem to stop typing...
----------
Design influenced from tools is so funny hey?
There's heaps of design trends generated by tools. And it makes sense - graphic designers are asked to make things that look like something within a budget. They very rarely are they supposed to come up with new things.
You may notice that many things that come out of photoshop look similar, and that many things that come out of indesign look similar.
It's the same with tutorials too. People follow, and expand from tutorials in similar ways.
Some other examples are the 'design arrow'. You'll see heaps of arrows straight from photoshop that look the same. Drop shadows, Bee hive patterns, triple verbs, splattered geometric shapes, etc etc. Even the use of layers has dramatically changed the style of graphic design(ten years ago).
I don't think some people realise their designs are so heavily influenced by their tools or the books they read.
Grab a street press and study the patterns of font use. People see a style and copy it. If a font gets in a few lists of 'ten best fonts' articles then you'll see them everywhere.
It's quite fun spotting the design trends in the designs around you - as you walk down the street, or browse the web.
Designers really aren't artists. If you want something interesting, meaningful, and that looks good get an artist.
If you want something made efficiently that achieves a purpose then get a designer who can use tools to do these requested and unoriginal effects. Designers work to a brief. If you don't know the brief, then you can not judge a designer - intelligently.
Often designers are asked to copy a style, or have a very limited budget to create something. Naturally people will use easy tools and techniques to achieve their goal. They know something works for a certain purpose, so they reuse techniques.
Designers talk to each other, and write articles. Or techniques are made easier to do with tools, so people use them. Things like a drop shadow used to take a while to do in photoshop. Now it's a tick box.
It's interesting to compare how tools like python affect the different ways we do things with code. eg. Because processes in python are so heavy weight people use threads, or events. Or because the for loop is so easy, people hardly ever manually increment a loop counter. Another example is datatype choice. It may be more efficient to use a purpose built container like a heap, but some times using a list is just easier. A list maybe not be the best choice, but it'll do.
It's also interesting to compare how a print designer, a web designer, a flash designer, an information architect, an interaction designer, and an animator could all approach a given task. Or even a game developer, verses someone who does a lot of visual communication. Or a photographer.
Using xml and css for UI design is a pretty good idea, so that people can reuse skills.
In flash there's often much better ways to express animation in code versus using the visual tools.
It might be cool to incorporate ideas from flash animation tools like ziggo. Or some of the popular javascript animation toolsets. They seem to be best way to do things for many types of flash, and javascript animation at the moment.
Another technique which seems to be cutting edge for shareware game UIs is to use your level design tool as the gui design tool. It probably doesn't make sense to do if you don't have a level design tool already though. However it does result in some pretty interesting, and fun interfaces.
An in-game design tool is good too. So unlike things like flash, or gui designers - you interact with the gui/game, and can make changes from within it. As you make changes you just serialise it back to disk. Examples come from platform games, and things like duke nukem level editor, and the cube engine. It's much easier to tweak things then. So much so that you can often take designers out of the equation too.
Taking it to another level would be an in-game editor which could be used with a distributed version control system. So anyone could make changes - then submit the changes when they're done.
Tools which can work with designs made within eg 3dsmax, or photoshop can save a lot of time. Then prototypes/mochs can be turned into interfaces a lot more rapidly. There are some good tools for flash, which can export a PSD file into an fla file - with all layers in tact. Similarly there are tools which can export gimp layers into separate images ready for animation. There's even a tool which can export blender animations into a series of .png images, and xml files defining an animation.
Wow, thanks for the long reply. Lots to think about in there!
Others might implement their GUI designer in their level editor. I just added PONG mode to my GUI designer :)
Great Stuff.
you said you could release some code.
Are you about to do so ?
Thks,
--OPQ
Yes, a release is imminent.
After having finally (roughly) learned GUI programming I now see why declarative GUI layout is the way to go. Programmatically defining a GUI can be such a pain in the rear.