By Steve on Saturday, April 21, 2012

Before we do anything in code, we should experiment with LiveCode's inspector palette to work out the properties that need to be applied to the button to give it the desired appearances in both normal and pressed states. These will then be applied in code and we'll set things up so all instances of the button behave and draw the same way.

So to start, create a new stack and then a new rounded rectangle graphic. You'll notice that the corners are way too rounded, so let's set them to 4. As we're going to be applying filled effects to the control, it's best to change its transparency to opaque.

At this stage, you should be looking at something like this:

The normal state has a fairly soft gray gradient applied to it, with the change from one shade to the next occurring mostly about two thirds of the way down.

Open up the Property Inspector and switch to the Gradient property set. We'll be editing the Fill gradient (Stroke is for the outline of the graphic) and applying a Linear gradient type.

The block of colour in the middle of the inspector is known as a gradient ramp. You can click on it to add colour points to it and their spacing helps to determine how quickly the gradient switches from one colour to the next. In building our ramp up, I reckon that a gray of 75% to the left looks good and 100% to the right is perfect (use the gray scale colour slider to choose these values, rather than RGB values).

You'll notice that the angle of the gradient goes from left to right but a button needs to go from top to bottom. We therefore need to rotate the gradient by 90°. Unfortunately, the gradient inspector doesn't allow for a rotation value to be entered, so you'll need to use the handles to drag the gradient control points into position.

If the handles prove fiddly to use, you can enlarge the graphic or zoom using the control key and the mousewheel (assuming you have zooming in this way turned on).

You should end up with this:

The next step is to add the slight halo and drop shadow that can be seen on the button. You won't be able to see these on a white background, so change the stack's background colour to something darker or more vibrant like bright magenta.

In the Property Inspector, select the Outer Glow set. As the halo is very subtle indeed, we don't want to go overboard on the settings. Therefore, change the colour to a dark gray (about 38%) and bring its opacity down to about 64. The Size needs to be just one pixel.

Note that the Blend Mode is set to Colour Dodge, so it blends in well with the background.

It's a similar affair with the drop shadow. Be sure to change the angle to 90°, so it sits directly beneath the rectangle. The colour is changed to a lighter gray and the opacity reduced, so the background can come through.

Note again that the Blend Mode is set to Colour Dodge.

Now we're ready to see what we've created. In this image, I've changed the height of the rectangle to 23 pixels, which is the actual height that the control will be. We can really get a good idea of how we're doing.

Super. I think we're finished with this button state. Tune in next week for the pressed version! 

By Steve on Sunday, April 15, 2012

Being a multi-platform development environment, the main focus of LiveCode has always been to provide the developer with controls and styles that are common to all operating systems that you can deploy to. If Apple and Microsoft could agree on doing everything exactly the same way, this would be great. But they don't and each OS has its own style variations, layout rules and various other quirks.

As a developer, I like to make my work look like it's always been coded for the intended platforms. Take Data Tree, which is now being looked after by NativeSoft. This multi-platform control looks great on Mac OS X and Windows by adapting itself to match the styles and behaviours of the host operating system. It takes work to do this but the results pay dividends.

In this series of blog posts, we're going to look at how to create a custom gradient button for Mac OS X. We'll seem how I overcome my aversion to gradients and use behaviours to make the control work.

Before we start…

In my old site, I used to have a gradient button library that composed the button out of a couple of bitmaps. This was before the days of gradients, graphic effects and behaviours. It's very much due a revist.

The key advantage of using graphic objects, rather than bitmaps, is that they resize very nicely indeed. The trick that I used with bitmaps was to split the body of the control into three. The two ends remained fixed but the bit in the middle was stretched to fit the width of the button. In taking this approach, I needed six images: two ends and a middle for both normal and pressed versions.

Apple also likes to apply some very nice text effects to their controls, giving them a very subtle drop shadow. Some controls have further graphical emphasis on them, which is not possible to recreate with just one field alone. The technique that I used in Data Tree, especially in the highlight, is to layer a couple of fields over the top of each other, each with a different text colour and the anti-aliasing blended them together for me. However, in this library, I've used the graphic effects alone to accomplish this for me and so therefore just need the one field for the label.

Dissection class

To understand what we're trying to recreate, I've snapped and blown up a textured button from Apple's Pages application. Most graphic manipulation packages will smooth and blur an image that's been enlarged, making the pixels fuzzy and harder for us to work out which subtle effects have been applied. I've therefore applied an aggressive sharpen filter to it, so we can better see the pixels.

 

We can see that the key features of the button includes:

  • rounded rectangle
  • gradients
  • an inner shadow on the pressed version of the button
  • a drop shadow or some other halo effect beneath and around the button
  • same again on the label of the button

Whenever you create a custom control, the chances are it will be composed of a number of other controls and objects that make it up. Just as my bitmap version consisted of six images and two fields, this control needs at least one graphic for the body of the button and at least one field for its label. They'll be fused together and with a little bit of coding, will work just like any other native control.

The button has two states: normal and pressed. In creating a custom button, I have two options in achieving this:

  1. Use just one rounded rectangle graphic and change its graphical properties in code to display each button state.
  2. Use two rounded rectangle graphics and show or hide them to display each button state.

Although the second option is easier to do, one of the goals of this exercise is to reduce the number of objects inside the controls. I'm therefore going to go for the first option.

End of part one

That's quite a lot of words for now and so I'll leave things there for today. Tune in next week for more!

By Steve on Sunday, November 13, 2011

It's been some time since I last posted (in fact back in June) and now I'm back with some important news.

I'm very pleased to announce that Data Tree has been sold to NativeSoft, developer of the excellent NativeGeometry and NativeDoc add-ons for RunRev's LiveCode.

As many of you know, I have had a major update to Data Tree in progress for some time but due to work commitments, has sadly stalled. This work will now be completed by NativeSoft.

NativeSoft will also be taking over support queries for the versions currently in circulation. Downloads and information about the product can still be obtained from my site but will be transferring to NativeSoft's site in due course. Licences can still be purchased from RunRev's Marketplace site.

I'd like to thank the many, many customers of Data Tree who have bought the product over the last two years. I'm proud to say that many more licences were sold than I ever thought would be.

 

 

 

Login Copyright ©2011-2013 theworcestersource.com