Category Archives: Developer

how to get Eclipse and Java to play on Yosemite

eclipse_by_a4size_ska-d2dvgyj

If you’re trying to launch the Eclipse IDE with Apple’s old 1.6 JDK installed and find that you’re having trouble updating your Java installation, try the following procedure.

1. Remove Apple’s JRE
First up, let’s get rid of the end user plug in. In Terminal, do

sudo rm -rf /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin

2. Remove Apple’s JDK
Next, we need to uninstall the Java Development Kit. Do not mess about in the System’s Frameworks/JavaVM.framework folders. You’ll need those. Rather, in Terminal do

sudo rm -rf /System/Library/Java/JavaVirtualMachines/1.6.0.jdk

If you’ve got later versions of the JDK (like 1.7), change the file name in the above command appropriately.

3. Install Oracle’s JDK for Mac
Next go to the Oracle Java page and look for the latest JDK. It’s important that you get the JDK for developers and NOT the JRE for end-users if you want to use Eclipse.

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Download and run the installer. You should now be able to launch Eclipse without problems. 🙂





Picture: Eclipse by A4size-ska

Cocoa: how to show a popover under selected text

Screen Shot 2015-03-25 at 20.49.31

Showing a popover underneath a piece of selected text is a trick widely made use of across OSX, not least in Xcode itself, but also in many other apps. In this post we’re going to look at a simple way to achieve this effect.

1. First of all, in IB drag out a Popover and View Controller and drop them in the Document Outline area. Drag a custom view to the canvas, and hook them all up thus:

Popover’s Outlets
delegate –> App Delegate (or class that will control the Popover)

Popover View Controller’s Outlets
view –> Custom View

Click the Popover object in the Outline area, and in the Attributes Inspector, set the Behaviour to Transient.

In the appDelegate.h file, or the .h file of the class that will control your popover, include the PopoverDelegate in the @interface declaration:

@interface AppDelegate : NSObject <NSApplicationDelegate, NSPopoverDelegate>

2. Still in the header file, you need to make sure the window that the NSTextView is in has a View outlet in its header file.

@property (weak) IBOutlet NSView *aView;

For my purposes, I just have a single window in the appDelegate class, so I just created a view property by control-dragging out of the Window’s view object to the header file. You’ll need to switch to the dual-view Assistant editor to do this:

viewProperty

While you’ve got the Assistant editor open, drag out an outlet from the Popover to the .h file and name it ‘popover’. Finally, in the same way create a similar outlet for your TextView.

4. Next, go into the implementation .m file for the appDelegate (or you class). You’ll need an IBAction to trigger the showing of the popover. In my case, I have an ‘Enter’ button the user hits after making a selection attached to a method I called enterSelection:(NSButton *)sender.

In this method, I first get the rect for the user’s selection with:

NSRect rect = [_textView firstRectForCharacterRange:[_textView selectedRange] actualRange:NULL];

That will return a rect in screen coordinates for the selected text. However, I need to convert that into the window’s coordinates with:

NSRect converted = [_window convertRectFromScreen:rect];

Now we’re ready to call the popover by supplying this rect to the first parameter and the View property we created earlier to the second parameter:

[self.popover showRelativeToRect:converted ofView: _aView preferredEdge:NSMinYEdge];

And that’s it. Your popover should show underneath the selected text whenever your method gets called. If you want to see how this is done step by step in Xcode, check out the video:


 

how to view nib files as xml (or not)

Screen Shot 2015-03-02 at 08.19.50



Xcode being the vast IDE that it is, it’s sometimes the simplest things that flummox you. It’s rare that I ever want to look at the XML code for any of my interface files, unless I’m copying one from one project to another or hunting down some forgotten outlet that’s throwing a warning. But when I do, I invariably forget how to get back to IB view.

If that’s you, fortunately it’s easy to return to the Interface Builder view from the source code view. Just right-click (aka ‘Control click’) on your nib file in the project navigator sidebar and choose “Open as…” and “Interface Builder XIB Document”. Unlike myself, you’ll remember that for next time, too (me, I’ll be looking for this post again in six months time! 🙂 ).



Screen Shot 2015-03-02 at 08.25.23


how to sit down safely

osxclock 1

Well, Tim Cook says sitting is the new cancer…and since I don’t envisage myself in the market for an iWatch, but do need to be reminded to get up and take a break from the desk every 60 minutes, I wrote OSXClock.

I also need a clock for displaying the time on a large screen on occasion when conducting timed-based tests. In the past, I’ve used timeanddate.com for this, but it has a couple of disadvantages: first, you have to be connected to the internet; second, it doesn’t have an alarm or timer.

Hence, OSXClock was born, Applehelpwriter’s answer to the Apple Watch :p, and considerably cheaper! 😀


Xcode: wrap code in comment tags

While AppleScript’s Script Editor has long had a built-in function for wrapping or unwrapping code with comment tags, for some reason this seems to be missing in Xcode.

Not to worry, nothing a bit of AppleScript and Automator can’t sort out. This will work in most text editors as well as in Xcode. Here’s what it does:

Install the Service by double-clicking on the downloaded .workflow file and clicking through the dialog boxes. When it’s installed, you can assign it whatever hotkey you want in System Preferences | Keyboard | Shortcuts.

Download Toggle Comments for Selection workflow.zip

Screen Shot 2014-11-29 at 12.28.59

If you want to use it for languages that have different comment tags you can adjust the code in Automator. Likewise, it would be fairly simple to have the script detect a number of different tags and respond appropriately, but here I’ve just stuck with the /* …. */ tags.

A note on usage: when uncommenting, it’s best to ensure that the selection begins at the leading forward slash and ends at the trailing forward slash (in other words that there’s no whitespace at either end of the selection). I have built in some attempt to strip leading and trailing whitespace, but an accurate selection will always be the most reliable.

Download Toggle Comments for Selection workflow.zip

Enjoy 🙂

App Fixer beta now available! 💥

app fixer
I’ve just released the first beta 0.1 version of App Fixer over on my software distribution site, Sqwarq.com.

App Fixer aims to help you remove corrupt preference files and window Saved States that can sometimes cause apps to crash on launch or during normal operation. Traditionally, we have to go hunting through the user library hoping to identify the correct files to remove. Now, App Fixer does it for you.

If you have an app that won’t launch or that’s behaving badly, or you just want to start with a clean slate by removing user defaults/preferences (I’m looking at you Photoshop!), App Fixer will do it for you in a click.

Grab a free copy of the beta from here: http://sqwarq.com/appfixer

🙂


return the difference between two strings

FastTasks 2 Profiler
If you’ve ever looked at trying to compare and evaluate two strings in Objective-C, you’ll find a whole host of methods to help you out. What you won’t find, however, is a method that will actually return the substring (or substrings) that belongs to one but not the other of the two strings you’re comparing.

I spent some time trying to figure out how to do this last week for one of my apps, and finally decided the best way was to break the strings down into arrays and then compare the arrays by removing items that belonged to one not the other.

I chose a fairly simple equivalence test based on length, and then set out to determine which was the longer of the two, before removing all the objects of the shorter one from the longer one. Here’s how I did it:

 


-(NSString *)getDifference: (NSString *)aString and:(NSString *)anotherString {

int i = aString.length;
int j = anotherString.length;
NSString *result, *longest, *shortest;

if (i == j) {
result = @"";
return result;
}

if (i > j) {
longest = aString;
shortest = anotherString;
} else {
longest = anotherString;
shortest = aString;
}

NSArray *fa = [longest componentsSeparatedByString: @" " ];
NSArray *sa = [shortest componentsSeparatedByString: @" "];
NSMutableArray *remainder = [NSMutableArray arrayWithArray:fa];
[remainder removeObjectsInArray:sa];
result = [remainder componentsJoinedByString:@" "];
return result;

}

Here’s an example of how to call the method:


NSString *t1 = @"Mary had a little lamb";
NSString *t2 = @"Mary had a little lamb yesterday";

NSString *changes = [self getDifference:t1 and t2];
NSLog(@"%@", changes); //"yesterday"

This method is pretty basic as it stands. For one thing, the length equivalence test will certainly fail under some conditions of change; for another, you’d need to extend it to return items that are in the shorter string but not the longer (though that wouldn’t be that difficult). Nonetheless, the core of the method could be used as a basis for something far more robust. For example, this vastly more complex set of match patch and diff libraries appear to be essentially based on the same principle of breaking strings down into NSMutableArray’s and adding and removing objects, but with a vast army of conditions and other checks built in to improve reliability.

Still, the basic method I’ve posted above is the core idea I’m using in the new system profiler feature coming in the 1.5 release of FastTasks 2 (see the screenshot above), and at least at this stage of beta testing, seems to be doing the job it was designed for quite nicely.

applescript: make your own battery health meter

main
A couple of weeks ago, I posted about how to extract numbers from strings. That led one reader to wonder what use they could make of such a handler. That sounded like an invitation for a little AppleScript tutorial, so in this post we’re going to build our own, colourful and highly useful battery health meter. In the process we’ll not only use the numbersInString handler I posted last time, but learn how to make our AppleScript displays a little more colourful by adding images, and we’ll take a quick look at some very useful Bash utilities that will do some of the heavy lifting for our little app. So, open up your AppleScript editor and let’s get started!

Step 1. Grab the returnNumbersInString(inputString) handler I posted here, and paste the code into a new, blank AppleScript editor window. Hit ‘cmd-K’ to turn it into ‘pretty text’ and check that it compiles OK.

Step 2. Underneath that, hit return a couple of times to create some white space, and define a new handler like this:

on powerstats()
set iconAC to ""
display dialog iconAC & "Power Source: " with icon 1
end powerstats

Hit ‘Cmd-K’ again to compile, then underneath our new powerstats handler, hit return to make some space again and type

powerstats()

Hit ‘cmd-R’ this time, which will build and run our code at the same time, and you should get the nice if not terribly useful result as so:

icon1

Believe it or not, that’s all it takes to get the core of our app, and all that remains now is to fill out the powerstats() handler and the display dialog command with the details.

Step 3: You might have been wondering what that ‘iconAC’ variable at the beginning of the display dialog command was doing, since all we did was set it to an empty string with “”. That was a placeholder. Let’s put something in it.

First, place the cursor between the two quote marks in the line that reads

set iconAC to ""

Now, either use the keyboard shortcut control+command+spacebar, or open the Character Viewer from the Keyboard menu bar (check the System Preferences > Keyboard | Keyboard: Show Keyboard & Character Viewers in menu bar item if necessary). Pick an image you like to represent AC Power. You can find the same image as I used by typing plug in the search/filter bar, but feel free to choose any image you like.

When you find the image you want, double-click it, and you should see it inserted between the quotation marks in your AppleScript. With the cursor placed immediately after the plug character but before the final quotation mark, hit the space bar three times. That’ll position it just nicely with our ‘Power Source:’ text:

icon2

OK, we’re going to set the other images we need in the same way. So, now place the cursor after the quote marks on the ‘set iconAC ‘ line, and hit return to create a space between that line and the display dialog line.

Now add the following lines, but do not include the words in orange like #battery after each set of quote marks. I’ve included those here just as search tips to help you find appropriate characters in the Character Viewer. As before, put the cursor between each set of quote marks and use the suggested orange words to find the images. Of course, you can use any image you like, but don’t forget to add the three spaces after the ASCII image.

set iconBatt to ""    #battery
set iconCharge to ""    #voltage
set iconTime to ""    #clock
set iconHealth to ""    #clover
set iconCycles to ""    #cyclone
set iconWarning to ""    #warning

Now we’re going to update our Display Dialog command so that we get the images at the beginning of a new line. We do that by adding

& return &

between each variable. Also, we don’t need all the images (iconBatt and iconAC are alternatives, and the warning sign appears elsewhere), so we’ll just add the ones we know will always be displayed. Finally, we’ll add an extra

return &

between iconTime and iconHealth to create some space. Update your Display Dialog command so that it now looks like this:

display dialog iconAC & "Power Source: " & return & iconCharge & return & iconTime & return & return & iconHealth & return & iconCycles with icon 1

When you hit ‘cmd-R’ it should now give you this:

iconsAll

Step 4: Ok, we’re done with the images, but not quite with the Display Dialog command. We need some more static text in there, so edit the command to look like the following:

display dialog iconAC & "Power Source: " & return & iconCharge & "Current Charge: " & return & iconTime & return & return & iconHealth & "Battery Health: " & return & iconCycles & "Cycles: " with icon 1

Be careful to ensure you close every quote and add an ampersand between every term and every return, or your code won’t compile correctly. Feel free to cut and paste it from above if necessary, but you should now have something like this:

add static text

This is all the ‘static text’ — text that will appear every time we run the script. As you can see, there’s some parts missing, as they will need to be added depending on the state of our battery.

Step 5: Coding time! We need to get our data for the battery before we can do much else, and for that we’re going to use a couple of unix utilities. Rather than messing around in Terminal, though, we’re going to let AppleScript manage them for us using the ‘do shell script’ command. First, we’ll ask pmset for a load of information about the machines power management settings, then we’ll ask grep to narrow it down to just the bits we’re interested in. To do all that, we’ll add the following short but powerful command to our powerstats() handler. Place the cursor on a new line after all the set icon commands, but before the Display Dialog command. Then type the following:

do shell script "pmset -g everything | grep Cycles"

Now run the script again and hit the “OK” button. The dialog will look the same as before, but this time we’re interested in what is in the ‘Replies’ (not ‘Result’) panel in the lower half of the AppleScript editor:

pmset

Note you won’t see this until after you hit the “OK” button on the dialog panel. What we need to do now is capture this result in a variable so that we can start extracting some of those useful numbers, so immediately underneath this line, add:

set x to the result

set x to the result

Step 6: In order to understand what follows, temporarily add the following two log lines:

log word 1 of x

Now run the script. Run it once with the power supply connected, then again with the machine running on battery power and compare the output in the ‘Replies’ field after you’ve hit the “OK” button.

The output of the log lines is shown in the Replies field between

(* *)

and they tell you the values of the variables. “Word 1” is the first text item in the result (exactly what delimits text items in a script depends on a built-in AppleScript variable called text item delimiters, which you can read about here).

If the AC Power is connected, word 1 should be “AC”, otherwise, it should be “No”. Similarly, word 2 should be either “charging” or “not” (sometimes the battery doesn’t charge due to a poor connection or if its more than 95% full). If AC is not connected, Word 2 should be “AC” (Word 1 and 2 together, in this case read “No AC”). However, different macs may have different power management options, so do some tests and check that you get the same results. If you don’t, you’ll need to experiment logging different words to find out which words correspond to my ‘word 1′ and word 2’. Here’s a summary again of the word numbers you need to determine for each of the values, with those on my machine given in brackets:

AC connected: word (1)? = “AC”; word (2)? = “charging” or “Not”
On battery power: word (1)? = “No”; word (2)? = “AC”

If your machine gave different results, make a note of which word number corresponds to my word 1 and word 2, and wherever I mention ‘word 1’ and ‘word 2’ in the scripting below, substitute those for the correct word numbers you found in your tests.

That these words always appear in the same position on the same machine is a very handy fact that makes it easy for us to determine whether the mac is running on battery or mains power, and in the latter case whether the battery is charging or not.

In the next step we’ll now put this information to good use in our script. First, however, remove all the log messages from the script.

Step 7: It’s time to add some more code to our powerstats() handler. Add this conditional test to your script, remembering to substitute any differences in word number you found in your logging tests:

iconWarning

This code assumes the AC is connected and sets the variable ‘charger’ to display whether the battery is charging or not. However, we need to set that variable to an empty string if the mac is running on battery power, so immediately underneath add another conditional:

pwrsource

In the Display Dialog command, replace iconAC with pwrSource as indicated in the image above. This will allow the Display to change the image accordingly. At this point, compile and test your script, both with the power supply connected and disconnected, ensuring that the icon changes accordingly.

If that’s working as expected, add the variable _t to the Display Dialog command immediately after the iconTime variable. Don’t forget to add another ampersand along with it as shown:

_t
Again, compile and test your script, both on battery and AC Power.

Step 8: Time to do some math. You may remember we started the script by adding the returnNumbersInString(inputString) method, and now it’s time to use it. We want to extract all those numbers returned by the do shell script command, and currently stored as a text string in our variable, x. We’re going to need some of them as numbers because we’re going to perform some math on them to get the battery percentage health.

Start by adding the following line, which calls the handler and gets the numbers back as a list of integers:

numbersInString
Item 1 of nums should be the battery’s current charge. Test this by adding a temporary log statement immediately after the set nums line:

log "item 1 of nums is " & item 1 of nums

Run the script, hit “OK”, and examine the Replies panel. Compare the output of the do shell script statements, and it should be clear whether you’ve got back the battery percentage or not. If not, continue logging till you hit the right item number. I’m going to assume that you got item 1 (if you didn’t, replace my mention of ‘item 1’ with whatever yours was in the following lines), so let’s remove the log statement, and replace it with this:

set percentage to item 1 of nums & "%".

Now, down in the Display Dialog command, add the variable ‘percentage’ and another ampersand in the place shown:

Screen Shot 2014-08-25 at 21.24.08
Run the script and hopefully you should now see that your battery percentage is correctly shown:

show battery percentage
Looking at the display reveals we haven’t added in the Power Source variables to the Display Dialog which we defined earlier, so do that now:

pwr & charger

Step 9: The next step is to add the time, but this is tricky on several counts. First, if you examine the number returned by do shell script in the Replies panel, you’ll note the hours and minutes are colon-separated. As far as our list is concerned, that makes them two different items, so we have to get the hours and minutes separately (items 5 & 6 on my machine; use logging to check what they are on yours).

Secondly, if the minutes are between “00” and “09”, AppleScript will just return a single-digit between 1-9, cutting of the “0”. That’ll mean we’ll end up with a weird display for say “1:05” as “1:5”. To counter that, we’ll have to test whether the minutes is less than 10 and add a “0” back in to the string if so. Also, we’ll have to add “hr”, “hrs” or “mins” depending on how much time is remaining or left to fill the charge.

As if that wasn’t enough, there’s a problem with the power manager: if you use Apple’s battery/power icon in the menu bar, you’ll notice that if you click on it straight after changing the power source, you’ll get a “Calculating Time till Full” or “Calculating Time Remaining…” message. That’s because it takes a minute or so for the power manager to update. The menu bar icon will update live, but we don’t have that luxury. Instead, we’ll add a warning later to alert users to this and ask them to run the script again after a short delay.

Woah. That’s a lot of conditions, so here goes. Add the following immediately above the Display Dialog command:

if item 5 of nums = 0 then
set hrmins to " mins"
else if item 5 of nums = 1 then
set hrmins to " hr"
else
set hrmins to " hrs"
end if
if item 5 of nums is greater than 4 then

if pwr is "AC" then
set t to "Calculating...try refresh in 2 mins"

end if

else
if item 6 of nums is less than 10 then
set theMins to item 6 of nums as string
set theMins to "0" & theMins as string
else
set theMins to item 6 of nums as integer
end if
set t to item 5 of nums & ":" & theMins & hrmins
end if

And for all that code, we only need to add one variable and an ampersand to our Display Dialog:

Step 9 v2


There is one remaining problem, which is that if you run the script immediately after changing the power source, although the message “Time to Full” or “Time Remaining” will change, the time itself may not. This is for the reason stated earlier: its inherent to the way the power manager works. We’ll do our best to help the user by adding a Refresh button later, but otherwise this is a shortcoming we’ll have to live with.

Step 10: It’s now time to get down to the real point of this script, which is to tell the user something that the battery meter in the status bar does not: the battery health and the battery cycles. The number of charge cycles the battery has been through is, naturally, given by the ‘Cycles’ figure. Battery health, however, is not data outputted natively by the power manager. Rather, it is a percentage of the Battery’s design capacity and its current ‘fully charged capacity’ or FCC. As you might expect, these two figures are represented in the do shell script output by “Design” and “FCC”, and it is largely because we need to do a mathematical operation on these that we needed the numbersInString handler.

To figure out the Battery health, we’ll divide the Design capacity by 100 to obtain 1%, then divide the FCC by this number to figure out how many percent it is of the Design capacity. That bit of math is represented by the function FCC/(design/100). In order to avoid a whole load of decimal places, we’ll also use AppleScript’s built-in round() handler to return a whole number. Finally, we’ll add the “%” sign to the string and add the ‘battHealth’ variable to the ‘Display Dialog’ command.

Here’s the code to be added, again after the last line and before the Display Dialog command (reminder: don’t forget to check using the logging technique I showed earlier that your item numbers are the same as mine, and to substitute your own for mine if they are different):

set FCC to item 3 of nums as integer
set designCap to item 4 of nums as integer
set battHealth to (FCC/(designCap/100))
set battHealth to round(battHealth)
set battHealth to battHealth & "%"

battHealth

Don’t forget to add the battHealth and ampersand to the Display Dialog, as shown above.

Step 11: Almost there. Let’s add the Cycles, which is fortunately a simple one liner:

Cycles
Does that say minus 3? Yes indeed it does! A little trick with AppleScript lists and strings is that you can count items backwards from the end using the minus sign,where -1 is the last item, -2 the item before it and so on (I thought I’d just throw that in as an extra since this command was so straightforward!). As always, check the position by using logging in your own script.

Step 12: If you run your script now you should find it’s complete. To wrap up, we want to go back to where we started, and that’s improving the look and functionality of our Display Dialog box. The first thing to do is fix the buttons. We don’t need a “Cancel” button, since the “OK” button does the job of dismissing the script, but we would like a “Refresh” button, so the user can run the script again from the dialog box. To add the the buttons, change the Display Dialog command and add a conditional statement after (not before this time) it. We’re also going to add a title for the box while we’re at it:

refresh button

final

Step 13: Your script is done, but to really finish it off, we should turn it into an app that we can run off the Dock, and to which we can add a custom icon. To create an app, choose “File > Export” and change the File Format to App. Give your script a name like “batteryPowerStat” and save it in your Applications folder.

Step 14: All you need now is an icon. You can either make your own, or you can download mine. Once you have an icns file, change its name to ‘applet.icns’ and add it to the Application bundle. To do that, control-click on your new app in the Finder, and choose ‘Show Package Contents’. Navigate to Contents > Resources, delete the file that currently exists there called ‘applet.icns’ and replace it with your custom icon.

You may need to log out and log in again before OS X flushes the old file from its memory and displays your new one.

Step 15: Only kidding! There is no step 15. 😀 I just wanted to stay “Congratulations”. If you made it this far, I hope you picked up a few AppleScript tricks along the way to creating your own battery health meter. If you need the complete code, you can find it on my Pastebin site here.

Enjoy! 🙂

FastTasks 2 update available 💥

I’ve just released an incremental update for FastTasks 2. Update 1.3 adds the ability to quickly see whether TRIM is currently on  or off for your SSD disks. Since TRIM support for non-Apple SSDs requires editing a kernel extension, TRIM is regularly disabled on non-Apple SSDs every time users update or upgrade OS X. FastTasks 2 v1.3 now lets you see TRIM status in the information section of the menu.

FastTasks 2 Trim

Get the latest release of FastTasks 2 by going directly to the FastTasks support page, or if you already have FastTasks 2 running, you can use the Preferences > Check for Update > Check now menu item. 🙂


FastTasks 2 – take the toil out of Terminal 💥

FastTasks 2.0 I’ve just released the first build of FastTasks 2 over on my software website Sqwarq.com.

FastTasks 2 is a menu-bar app that takes the toil out of Terminal and offers at-a-glance display of key system info, the ability to quickly toggle hidden files, free memory, remove login items and create a super-fast RAM disk.

All told, FastTasks 2 offers more than a dozen tasks that you can accomplish with little more than a click. Check out the screenshots below to get an overview of the main features.

When you’re ready, head on over to the FastTasks home page to download your free copy, and forget looking up tiresome Terminal commands – just click and the task is done! FastTasks 2 contains no adds, nags or in-app purchases and is currently on offer for free, so go get one now!

FastTasks 2 requires OS X 10.9 or higher.



Toggle system settings


FreeMemoryMonitorIP



RAMdisc

%d bloggers like this: