I’ve been working on overhauling the UI experience in the back end systems we use at work and decided that I wanted some tool tips to help tell users what things do without them having to ask us. The only decent tool tip library I’ve ever found was Prototip by Nick Stakenburg but I knew I wouldn’t be able to get away with buying a license for it so I needed to create my own. After my experiences doing the emile.js version of zebedee I decided to give myself a bit of a challenge and go completely frameworkless to create a standalone widget.

First up was finding out how to do encapsulation in javascript so that I was only giving access to the methods that needed to be accessible from outside the class. The way this is done is to return an object with the public methods defined in it, rather than doing return this. For purposes of scope I defined the methods before the return statement, then returned references to them. Like so:

Once I had that that figured out it was down to creating the various methods and setting up the event listeners. The main requirement was handling the positioning of the tool tip in relation to it’s trigger element. As the position could either be fixed to a point on the trigger or follow the mouse, I ended up creating an object with either the element properties or the mouse coordinates and using that as the starting reference to perform the calculations from, then scanned the position option for one of the y position possibilities and set the top and did the same for the x position options. I later expanded this to have an optional element passed through which would be positioned instead of the tooltip, for use with the animations.

I spent a lot of time going through prototype and zepto to find out how to do the various things I needed to do without the frameworks and ended up stealing various little bits of code, like the user agent regular expressions from zepto so I could determine whether the browser was running webkit, I also tweaked this to check for gecko 2 as well. This was so I could use css animations where available for the transitions. When it came to dealing with the animation, emile.js ended up being my main source of reference, to the point that when I needed to expand my original animation function to be more flexible I ended up taking emile’s animation code and a few of it’s helpers and tweaking them for my own purposes.

The biggest challenge with doing the animation was the scale transition and positioning it, particularly the css animations. With the javascript animation it was easy to make the box appear to grow and shrink from it’s trigger element, as I just needed to call the position method each time I adjusted the size. But with the css couldn’t call anything on each iteration so I had to create a test element that was a clone of the tool tip, alter that, reposition it and get the end values, to then pass through to the animation function. In the end it worked out but I’d like to play around with it to see if I can get something less long winded. I also want to have a play to see if it’s possible to make the text grow and shrink with the box, by using ems. Another interesting thing I discovered while working on the CSS transitions is that both Gecko 2 and Webkit have their own version of the transition end event, in Gecko 2 you can use transitionend but in webkit you need to call webkitTransitionEnd. Also this event will get called for each property you are animation, so in the case of the scale transition,where I was animating width, height,left and top, the event was being called four times. Remember to check for this when writing your handlers.

I ended up namespacing the tool tip function inside a tipBox object, so I could add the scan method and keep them together. This means that while the calls are a bit longer, the functions are kept neat and secure, and shouldn’t conflict with anything.

The scan method enables you to have a load of elements on a page (preferably a tags for semantic reasons) with a given class name that you can turn into tipBox triggers with one function call. All you need to do is pass the class name and the options you want to use to the method and it will scan the page and set up the tipBox for each one, using the title attribute to supply the text.

I found getting the initial stages of the widget working were a lot easier than I expected, which I take to be a good sign that my understanding and knowledge are improving (either that or it’s easier than I thought and I’m just being a numpty). The animations presented my biggest challenge and took as much time to work round as everything else did to create but were without a doubt the most rewarding part of it to complete. The whole coding without a net approach forced me to explore and learn more, and work out my own solutions to how to do things, which was great fun, and will hopefully result in an improvement in my javascript work from now on.

Code and demos are available on GitHub:

tipBox | Demos

Ok, there’s only 3 more but still, it sounds more exciting. Yes, zebedee has made it to version 0.2, my first actual version increment on any of my projects, I feel quite proud! So what’s new in version 0.2? Well the main additions are the versions for Scriptaculous, Scripty2 and emile.js Check out the readme for details on what files are needed and how to use them.  In addition there are also a few bug tweaks, minor reworking of the zepto version to cope with a major restructuring of zepto and the addition of a default panel option.

For the large part I’ve kept the code the same on the new versions, the main changes being updating the open and close methods to use each individual library.  I’ve also removed functions that were duplications of methods available now available to me in Prototype for the Scriptaculous and Scripty 2 versions.  I did however keep my own object merge function as it merges more recursively than Prototypes version.  Emile however was much more of a challenge as it is solely an animation framework and therefore contains no helper methods whatsoever.  Cue a trip deep into zepto’s code and the Mozilla Javascript Docs to find out how the frameworks do things. I ended up adding a few helper methods to deal with manipulating the classnames, just to make life easier.

I’ve also added in the facility for the Scripty 2 version to use Scripty 2’s ability to use css transitions where available. This is only available on linear and sinusoidal transitions at the moment but the library will fallback to javascript for the unavailable transitions. In the case of emile the transition calculation functions have to be provided as an option so I’ve added a zebedeeTransition object with a selection of functions.  The default object just includes the linear and sinusoidal transitions but by including the zeb-transitions.js file you can get access to all the transition types of Scripty 2.  The calculations are taken from Scripty 2’s included calculations that are based on Robert Penner’s original AS2 easing equations.

Coming up in version 0.3 will be a jQuery version, callbacks for when the panel opens and closes, at both the start and finish of the animation, and the option to keep one panel open at all times.

Zebedee

Okay, so this month I finally got chance to delve into Python. I’m using version 3.1, as obviously there’s no point learning something thats going to be obsolete fairly soon, although this did make finding examples and stuff harder as the majority of stuff I found was for Python 2.

While I know python is a popular, and very capable, web programming language, I’m not really interested in that side of it. As far as I’m concerned I’ve got PHP which I use for regular development, and am pretty competent with, and Ruby on Rails, which I’m starting to try and get my head round, I neither need nor want yet another contender vying for position as my chosen tool when it comes to developing for the web. What I am very interested in python for, is desktop apps. From what I’ve heard python is a pretty good cross platform language with good tie-ins to the operating system and file structure. It also looks a hell of a lot simpler than C++, which I have tried to master on a few occasions and only ever succeeded in achieving basic competency with.

Now if you’ve seen any of my other posts you’ll know that I tend to do a lot of work with Javascript, and also know Actionscript, so you may be wondering why I don’t just use Air for building desktop apps. I’ve used Air before to build small desktop widgets using Actionscript, and will undoubtedly at some point end up playing around with it a bit more, but for users to run Air apps they’re required to download the Air runtime, and the last time I looked the Linux version was a bit behind. What I’m hoping to get with Python is something I can write once, maybe with some os specific tweaks, and compile to a valid executable/installer for any system.

So onto my first impressions. For someone that is used to languages like PHP, Javascript and Actionscript, Python is something of a shock to the system. The lack of curly braces to enclose functions and statements was something I was starting to come to terms with from Ruby, but the lack of any form of closing statement made reading through the code a somewhat strange experience. My learning project is a file renaming utility so I found the os functions, particularly os.rename() really useful. I started off just building the app as a command line script, then once I’d got that basic renaming functionality figured out, (not really that difficult when it’s just a call to one built in function), I started looking into adding a gui.

I ended up going with PyQT4, mainly because it was the only free, cross browser GUI framework that worked with Python 3. The hardest part about getting it all working was finding out how to actually create the window and use the ui. I’m using the following code:

Where main.ui is my layout xml file. One of the things I liked about PyQT was that it came with a GUI designer utility which lets me just layout the gui as I wanted it and save it to xml. Makes building the layout much easier. At the moment I’ve not really done much more than set up a basic gui with ultra simple file renaming (you select a file, type a new name and hit the big rename button) but I’m intending to add batch renaming with various renaming actions such as regular expressions, substringing, extension changing and more.

The main challenge at the moment is understanding how to use PyQt as I’m afraid the documentation isn’t particularly novice friendly, being more of a reference library. Some examples would be handy, especially as I struggled to find anything on google. I think when I’m a bit more comfortable with things I’ll post some examples/tutorials. I’ll also write a bit more about my python experiences as I get to spend more time with it.

Zebedee is an accordion widget for multiple frameworks. At the moment it is only at V0.1, which only supports zepto.js, but I will be adding support for various different animation frameworks as I have time. I wanted to play around with Zepto, Thomas Fuchs' new mobile javascript framework and decided it would be fun to do an accordion widget to see if I could use the CSS3 transitions to animate the opening and closing of the accordion sections.

It was good fun having to go back to basics on it as I was used to having Prototype and Class.Create() to work with when creating new objects. Thankfully zepto provided a few good utility functions to keep my code neat and simple. The jQuery like chaining also came in handy in that regard.

I’ve purposefully kept the functionality simple, as I don’t really think it needs to be all singing, all dancing! At the moment it supports vertical and horizontal accordions and I will probably be adding the ability to set the the actual trigger event for the accordion to be bound to a child of the header object. Also the duration, transition type and trigger event are all configurable, as well as the class names assigned to the various components.

I should hopefully be adding support for Scriptaculous in the next month or so, and Scripty 2 should follow soon after that, so watch this space. In the meantime checkout the project page at the link below for more information and links to the GitHub source. I’ll also be popping up some demo pages when I get the chance.

Zebedee | Demos

Well my post for this month was going to be a tutorial on customising Flash UI components, but unfortunately doing it properly is going to take more time than I have available to me at the moment so I’m just going to keep working on that in the background and will post it when it’s ready.  In the meantime I’m going to put up more information about some of my Open Source projects and hopefully get them better known, which in turns should, I hope, accomplish one of the aims of this blog.  Getting people to help improve my stuff and, by proxy, improving my skills and knowledge.

So first up, purely by virtue of being my most recent, is Easel, a colour (I’m english, so yes it is spelt right!) manipulation library for Actionscript 3.  Easel came about from a need to take a randomly generated colour and get colours that would work well with it for dynamically generated objects in a recent project at work.  At first I just managed to find the Tint library by RevokeLabs which provided me with a darken function which did the trick for me.  However I then needed more, so I managed to find an algorithm to calculate the complementary colour on a forum somewhere, which I’m afraid I can’t remember, but have subsequently replaced so I don’t feel too bad about not crediting it.  From there I had the idea of replicating the colour manipulation functions of Sass, which I’d read about in a recent .Net tutorial, but hadn’t had a chance to play around with (I have now and will no doubt be writing more about this down the line, watch this space!).

I was struggling to find the algorithms to accomplish what I needed in AS3 so I ended up pulling the source for Sass from GitHub and wading through that to find what I needed.  I then proceeded to rewrite the functions to AS3 which involved rewriting the original manipulation functions from the Tint library as they relied on manipulating the RGB values whereas Sass was working with the HSL.  I did however keep the getHex and getRGB functions as there seemed to be no real difference in them.  The upside to this approach was that I learnt a bit about colour manipulations, and got more experience with Ruby code, always a good thing!

Please check out the link below or on the right for the project page which contains links to the GitHub source and the Demo.

Easel