Update on what’s going on

Logo

Hi, everyone.

I wanted to try something new, so instead of a blog post, I’ve recorded this ~6 minute podcast for your listening (dis-)pleasure.

Here are the relevant links and time codes in case you want to jump to a specific section:

00:00 – Intro
00:25 – New website (http://www.eternalstorms.at)
00:47 – Yoink (http://www.eternalstorms.at/yoink)
02:46 – ScreenFloat (http://www.screenfloatapp.com)
03:21 – flickery (http://www.flickeryapp.com)
04:06 – GimmeSomeTune (http://www.gimmesometune.com)
05:09 – New apps (http://www.eternalstorms.at)
05:39 – Outro

I hope you enjoy it :)

Podcast-download (best viewed in QuickTime Player or iTunes for chapter selection)

Take care,
Matt

Presenting Yoink 2.0 – the drag’n’drop helper app for OS X Lion

NewImage

Presenting Yoink 2.0

Screenshot of MarsEdit

 

 

 

 

 

 

 

 

 

 

A picture usually says more than a bunch of words.

What is Yoink?

Yoink is an created to make “drag’n’dropping” files easier.
It shows a “shelf” when you start dragging files or content from applications so you can drop them onto Yoink. This way, your mouse is free for you to move between Finder windows, apps, spaces, fullscreen applications, etc.
Once you are where the files are supposed to go, you can drag the files out of Yoink again to drop them to their destination.

What’s new in version 2.0?

I got a lot of feedback on Yoink 1.0 from customers (thank you very much, by the way) and the changes you see in Yoink 2.0 are a direct result of it.

As you can tell from the image above, there’s a new look – done by the very talented Dietmar Kerschner.

Secondly, you can finally drop content from application onto Yoink – meaning images, text passages or links from within websites, for example. Or files on a server from the FTP client Transmit.

Also pictured in the image image above is a file stack. New in Yoink 2.0, when you drag multiple files onto Yoink at once, they’re not separate items in the list but just one item so you can easily drag them out at once again.

I’ve added a hotkey so you can manually show Yoink’s window so you can drag files from a Dock’s stack or applications like iTunes or Adobe Bridge that don’t trigger Yoink’s window for technical reasons – they use a non-standard NSPasteboard instance to do their dragging duties.

There are four new positions available – left, pinned to the top, left, pinned to the bottom, right, pinned to the top and right, pinned to the bottom (additional to the already existing left center and right center).

Availability and Pricing

Yoink is available exclusively on the Mac App Store for $2.99. But as usual, there’s a free, fully functional 15-day trial available at Yoink’s website (direct download). There’s also a quick screencast that shows exactly what Yoink does, and how it does it.

Feedback Appreciated

I really appreciate your feedback, input and criticism, so please do not hesitate to write me if you have any comments on my apps. Thank you kindly :)

Yoink: the Dock’s Stacks and iTunes files [UPDATE]

Yoink

The Feature Request

One of the most requested features for Yoink is being able to drag files from a Stack in the Dock to Yoink’s window. It sounds very simple and were I not the developer of this app, I myself would ask why Yoink hasn’t been able to do that from version 1.0.

Sadly, it’s not that simple.

 

stacks in dock

The Problem

For a reason unknown to me and maybe even a few people at Apple, the Dock does not use the general NSPasteboard used for dragging (NSPasteboard is responsible for being able to copy, cut and paste content from one document to another, but it also handles file drags, most generally with the NSDragPboard type).

No, the Dock uses a custom NSPasteboard for dragging (probably using NSPasteboard’s -pasteboardWithUniqueName method). The thing is, NSPasteboard doesn’t keep a public list around (and I don’t know of a private one, either) of the names of these unique pasteboards, which makes it impossible to check if a drag occurs on those uniquely named pasteboards.

This is not only the problem with the Dock, but also with iTunes – it also uses a unique pasteboard for its drags.

The Solution(s)

The thing is, even though the Dock uses a private pasteboard for its dragging handling purposes, if the Yoink window is visible, it still recognizes those drags. Which is a good thing, because knowing that, I can look for a solution.

As I see it, there are two possible solutions to this problem:

Possible solution #1: Have a hotkey to force Yoink’s window to show.

Although I like it, it does have its drawbacks. For starters, while you’re dragging with one hand, you don’t want to have to press a complex keyboard shortcut with the other. Many people I know use two hands to press shortcuts, so it would have to be an F-key, maybe. But pretty much all F keys are taken by default, and if not, other applications use them.
It’s more obvious than the second solution, but also harder to do while dragging.

Possible solution #2: Have hot corners or hot areas to drag to to force Yoink’s window to show

This one brings up several questions:
Should all corners be hot?
Should the user be able to define them?
Should it be corners only or should it be the entire edge of the screen?
And once the user drags an item to the hot corner to show Yoink’s window, they still would have to drag it from the corner to the window. So it’s a longer way for the mouse.
And of course, in those corners, files can’t be dropped. They corners would be small areas, yes, and even if it’s a rare case that you’d want to drop in a corner (I don’t think I’ve ever done it), it’s still a possible case.

The Decision

I’m leaning towards using hot corners, it kind of feels more natural to me for Yoink.

I’d like to implement hot corners in all four corners of all of your screens. And whichever hot corner you use, on that corner’s screen’s edge the Yoink window will show for you to drag to.

What do you think? Does that make sense? Please leave a note in the comments below, it means a lot to me :)

Addendum: General state of Yoink

Aside from the issue above, the next update for Yoink is coming along nicely.

x) Yoink will allow the creation of clippings (when you drag a selection of text out of an application), accept items from your Browser (images, text, links) or drag out pages of a pdf file in, say, Preview – Clipping Creation Video
x) You’ll have the option to collect several files dragged at once into one item in Yoink (here a video which explains it far better). This way you can more easily drag out several files at once. And yes, there’ll be a button to split those “file clusters” up again :)
x) I’ve also added new position options for Yoink’s window – not only can you put it on the center right or left edge of your screen, but also the top or bottom right and left. I didn’t implement the top center or bottom center (where the Dock is by default), because Yoink uses a tableview to display its items, and tables are based on rows, one below each other. That doesn’t work if the window is not vertical but horizontal.

The Decision – [UPDATEd]

Even though I stated above that I’m leaning towards hot corners, after a good night’s rest, I’m now more and more for a hotkey instead of hot corners.
First off, it is far more obvious for users since there’s a preference for the hotkey. The hot corners would be just there, whether people knew it or not.  Also I believe the principle of hotkeys is better known than hot corners, but don’t quote me on that.
Additionally, a hotkey would give the user the benefit to be able to hide Yoink’s window even if it’s got files in it, which has been another requested feature.

The more I think about it, a hotkey does make more sense. Wouldn’t you agree?

Thank you and take care,
Matthias

ESSVideoShare – an open source framework for OS X Lion offering video publishing for YouTube, Vimeo, Facebook and Flickr for your Cocoa app

NewImage

Today I released my first open source framework for OS X Lion – ESSVideoShare.

What is ESSVideoShare

It’s a framework for OS X Lion that makes it very easy to implement video publishing to these services:

YouTube, Vimeo, Facebook and Flickr

What you need

Import ESSVideoShare into your project, make sure ti’s being copied to your app’s bundle in a build copy phase.
And of course, for each service, you need an API key.

I explain the process of implementing ESSVideoShare step by step on its github page.

In-Depth

If you’re interested in how it all works, please head on over to the public github repository.

Support

If you have any questions or suggestions for improvement, be sure to let me know either through the comments below or by mail :)

Take care,
Matthias

Presenting: Yoink, taking the drag out of drag and drop in Lion

YoinkIcon

Presenting: Yoink – taking the drag out of drag and drop

Functionality

Have you ever tried dragging something from, say, Finder, to a fullscreen app in Lion? It’s a pain. This is where Yoink comes in. Every time you start dragging a file, Yoink shows a window you can drag those files to. Then you just switch to the space or fullscreen app you’d like to drop the files to and drag them out of Yoink to the app. Very simple. There’s a video on the website which does a pretty good job at explaining what Yoink does, exactly.

The idea behind Yoink

The idea came to me while trying to drag a file from Finder to a new message in fullscreen Mail.app. I just couldn’t do it. Then I tried to drag images from Finder to Xcode in fullscreen. Not very easy either. Thus, Yoink was born.

The name

The original app for this little app was DragHelper. Yes, I know – why did I ever change it?
Well, I was watching the Simpsons, in the episode where Bart takes the last Doughnut or bearclaw or whatever it was from Kent Brockman’s plate by exclaiming “Yoink!” (to which Brockman asks himself: Yoink?!?) and I thought – that’d be a great name for an app that “yoinks” the dragged files.

Why Lion only?

The main reason is because I didn’t see the problem on Snow Leopard. The other reason is that I really wanted to try out the new NSTableView view-based APIs :) They’re very nice and shiny.

The menu bar icon controversy

The number one request I get from customers is to put in an option to remove the menu bar icon (the black down arrow). Well, I didn’t want it in there in the first place.
The first time I submitted Yoink to the Mac App Store, it got rejected because it didn’t have a way to quit the app if Yoink’s window wasn’t visible (the rejection note stated (somewhat paraphrased) “The app can’t be quit if the window is not visible”).

So I thought to myself: what’s the least obtrusive way to make it quittable at any given time _without_ putting an icon in the menu bar. Because why for the sweet love of God would Yoink need a menu bar icon? It’s a background app, for crying out loud.
So I put in a global hotkey for quitting Yoink and made it clear in the splash screen. Submitted it again.

Another rejection followed. This time, the rejection note stated “There needs to be a menu bar or an application menu or a status menu to include a quit item” (why this wasn’t stated in the first rejection is beyond me, but to err is human, and I’ve erred quite a couple of times, so I’m not complaining). Since it’s a background app, the first two were not possible, since background apps do not have their own menu bars – the only thing that was left was the menu bar icon. So I put it in there, and that was that.

Since I was pressed for time, I didn’t implement an option to hide the menu bar icon, but believe me, the upcoming update will include such an option. As I said, I don’t want that menu bar icon either. I just don’t see it make any sense.

The no launch on login controversy

The second most requested feature was to add a “Add to login items” button in Yoink’s preferences.
I tried to implement it, but in the sandbox environment of Lion, in which Yoink is running, it is currently not possible to do. I’ll have to wait until Apple fixes this until I can implement it.

Pricing and availability

Yoink is available exclusively through the Mac App Store for $2.99/€2.39. A free 15-day trial is available at the website (direct download link)

As always, I very much appreciate your feedback, bug reports and feature requests, so please keep them coming :)

Thank you and enjoy,
Matthias

OS X Lion App Sandbox and its implications on applications

sandboxPhoto credit: livingindryden.org

I’m very excited about the new operating system and the APIs it holds for developers.

One new feature that is going to be very popular amongst users and holds real benefits for them is the App Sandbox.

What is App Sandbox?

Entitlements

Basically, the App Sandbox needs developers to specify what kind of access to user data an application they create needs.

You basically start with no privileges (so called “entitlements”) at all and work your way up for what your app needs. 
Does it have open or save panels? You need an entitlements for that.
Does it need access to the network? More entitlements.
Does it need to access iCal or Address Book? Even more entitlements.

Apple states there are currently 15 entitlements, but the list may change in the future.

Containers

For data saved by applications, like preferences files, Core Data storage, “Shoebox” data, basically everything except Documents the user saves or are autosaved by OS X Lion, each application gets its own Container in /Users/yourname/Library/Containers/, like /Users/matthias/Library/Containers/at.EternalStorms.ScreenFloat/

An application that has no entitlements for file system access can not access anything beyond that folder without the user’s consent (a user can give their consent with selecting files in open or save panels or by drag’n’dropping items onto or out of the sandboxed application).

Deny, deny, deny!

Anything an application requests it doesn’t have the proper entitlement for gets denied by a process called sandboxd, the sandbox daemon. It manages the sandboxed applications and their access to things they are or aren’t entitled to.

This is what your Console looks like when something gets denied:

27.07.11 16:56:14,480 sandboxd: ([2460]) screencapture(2460) deny file-read-data /usr/sbin/screencapture

XPC

XPC helps take the sandbox paradigm even further, making apps even more secure. Instead of having one executable that does it all (access the web, access iCal data, access Address Book data, write stuff to disk, read stuff from disk), a developer splits these tasks up and basically creates for each of these operations a executable with just enough entitlements to do its work.

So if you have an application that can access your Address Book and the web, there’s nothing from stopping the app, had it been compromised, from sending that data to a server.

However, if you have two different executables, one with just the Address Book entitlement and another with just network access, it’s not that easy anymore for intruders to do their dirty business.

XPC lets these two executables talk to one another, inside their shared sandbox.

What is App Sandbox good for?

Something that has been said a thousand times in the WWDC sessions to make abundantly clear what App Sandbox is good for:

It’s a last line of defense against evil-doers.

If an application has been compromised, it can’t do anything beyond its entitlements. That’s a very good thing.

So what does it all mean for users and developers?

Users

For users, it’s a great thing to have in terms of security and privacy of your data and I think every user should be excited about it. I know I am. It’s a great solution to a problem that has been dragging on too long, and Apple stood up and took a shot at it, and I think they did very well. For the most part.

In terms of what app developers will be able to make for those users, well, that’s another story which I’ll explain next.

Developers

In general, for most cases, developers won’t have any trouble with the App Sandbox. Version 1.2 of ScreenFloat – which is currently in Review for the App Store – already is a client of the sandbox and I ran into no trouble with adopting the entitlements, what so ever. It does what it does, just like before, but now, it’s safer, and I’m very excited about that.

What worries me, however, and, judging from what I’ve read on Apple’s developer forums, worries quite a lot of other developers as well, are the so-called temporary entitlements.

Temporary entitlements are for certain cases where it’s not really safe to do something, but Apple hasn’t figured out a safe way to let the app do it yet, so they made an entitlement for it. A temporary one.

Let’s take, for example, iTunes. There are a lot of applications out there that can “remote control” iTunes with global hotkeys.
In the background, the application is sending out an Apple Script, or doing its work over the Scripting Bridge, or are sending Apple Events directly (Apple Scripts and Scripting Bridge work with Apple Events in the end, but it’s at a higher abstraction level API wise for developers like me, who have no idea how to create Apple Events in the first place).

For this case, Apple has created a temporary entitlement. Alright, so it works.

What bothers developers however is the term “temporary”. What _is_ temporary, exactly? Will there be a replacement once the temporary entitlements vanish?

Let’s look at a perfect example for this:

GimmeSomeTune and the App Sandbox

Some of you might have read it on Facebook, others may have on twitter, for those of you who haven’t, here’s what happened:

I’ve halted development on GimmeSomeTune because of the temporary entitlements, more so because of the questions I asked above that have yet to be answered by Apple.

But let’s take it one step at a time:

GimmeSomeTune gets notifications with userInfo payload objects from iTunes. That’s no problem yet, since iTunes is yet to be sandboxed. But once it is, it can only send notifications without userInfo payload objects, and that object contains all the necessary information, like Title of Song, Album, Artist, etc.

So GimmeSomeTune, in its current form, could work for some time, until Apple decides to sandbox iTunes. Boom! Rien ne va plus.

GimmeSomeTune downloads artwork and lyrics and sends them to iTunes through the Scripting Bridge. The Scripting Bridge is essentially sending Apple Events to the app you target, in my case, iTunes.

The sandbox allows for Apple Events to be received by an application (without entitlements), but can not send any, without the temporary entitlement. When the entitlement is no longer valid, the main functionality of GimmeSomeTune breaks. Boom! Rien ne va plus.

So what it comes down to is this:

GimmeSomeTune would work right now in its current state, with temporary entitlements and hoping that Apple will never sandbox iTunes so it will continue to send notifications with userInfo payloads (which is doubtful, since iTunes is your digital hub and all, so they’ll be sure to sandbox it at some point, I guess).

But what happens if iTunes was sandboxed?
GimmeSomeTune would break, it would not know what song is playing in iTunes and hence wouldn’t download information and send it to iTunes, rendering the application useless.

And what if the temporary entitlements go away without a proper replacement API?
Again, GimmeSomeTune would break and it couldn’t send downloaded data to iTunes anymore, again rendering the application useless.

Why not just release it and hope for the best?

Sure, I could release GimmeSomeTune with temporary entitlements and hope they stay around forever or that there’ll be a replacement API for them.

But I have to consider what happens if they don’t (which is, in my opinion, 100% certain) – angry users, having paid for software that doesn’t do its job.

I am not willing to take that chance. I will wait to see what Apple comes up with.
And if there is a replacement for temporary entitlements in the works, and when I’m certain GimmeSomeTune will work with it, without the fear of having the application break at some random point in the future due to functionality that is ripped out from under it, only then can I release GimmeSomeTune with confidence and the knowledge that its users will be able to actually use the app.

And I believe this is the right choice.

Sandbox at its finest

Would you like an example of what kind of apps are completely unsupported in the sandbox environment?

Applications that change developer-signed files inside of app bundles that are a) developer-signed and b) running in the sandbox environment.

May I present the worst case Scenario: PresentYourApps

Some of you may know this little app of mine. PresentYourApps lets you hide the menu bar and / or dock for applications you specify, making more screen real estate available. Or at least, it _let_ you.

On OS X Lion, it works some of the time, but I highly discourage you from using it on that system, and I will take down the download link in the next couple of hours.

I discourage you, because it breaks apps you use it on.

I got an e-Mail from a user who tried it on Preview.app on Lion, and after he restarted Preview.app, it crashed on launch. Luckily, PresentYourApps keeps backups of the file it edits, so the user could make Preview.app work again, but it was scary.

Well, PresentYourApps has been long overdue and begging for an update, but because of these circumstances, I decided to discontinue working on it all together and removing it from my website, since it will do more harm than good on Lion systems.

 

If you have any thoughts regarding all of this, or GimmeSomeTune especially, please be sure to leave a comment or contact me in any other way!

Thank you kindly for reading,
Take care,
Matthias

Ready for Lion

As the release of OS X Lion comes closer and closer, you’re maybe wondering if Eternal Storms Software is ready for the new cat.

Yes, all my software available on the Mac App Store will be ready for Lion.

NewImage
flickery

flickery is, in its current version (1.9.24), not ready for Lion, but the update to make it compatible with it (1.9.25) is in review, so once it’s reviewed, it will be ready for Lion.

Screenfloat 3  dragged
ScreenFloat

ScreenFloat is ready for Lion as of version 1.1.1! I’ve tested every aspect of the app and everything seems to work just as expected.

GimmeSomeTune 3  dragged
GimmeSomeTune

As you might know, GimmeSomeTune is not yet available, but I wanted to let you know that I’m writing it for Mac OS X Snow Leopard 10.6 and OS X Lion. I’m constantly booting into Lion to test if what I’m working on is running on Lion just as well as on Snow Leopard.

 

A good website to keep track of software that is (or is not) compatible with Lion is roaringapps, it gives you a great overview of lots of software and its status regarding Lion.

Take care,
Matthias

Another 180 turn in GimmeSomeTune

gimmesometune

One 180 turn plus another 180 turn means – we’re back where we started.

A few months back, I said GimmeSomeTune would make a 180 turn by using Gracenote as its source of information (lyrics, song info, artwork).

Although I really wanted this to happen, for all the reasons I mentioned in that previous blog post, it doesn’t seem like it will happen. I’ve contacted Gracenote numerous times and never heard back. Either they’re very, very busy or they just don’t care and don’t want my business. So be it.

So be it!

I’ll do what lots of other apps (including GimmeSomeTune) do – turn to websites that have the according information available. I’ve done it before, I’ll do it again – only better. I’ll use several sources for lyrics and artwork, many of which you, the users, have suggested – thank you for that. I have several sources for lyrics and artwork, so if one service goes, there’ll be a backup service I can turn to.

Truth be told…

I really was looking forward to using Gracenote, because they do offer a great service.

When it became clear that Gracenote couldn’t be bothered to at least write me a “buzz off” e-Mail, I looked into other options. I still have no clue what Gracenote is charging, but it can’t be more than what the others are. It is really hard for an indie developer to use these services and not go hungry while doing so.

Who knows, maybe I’ll get an e-Mail from Gracenote some time this lifetime, then I may reconsider.

Status right now

So what’s the status of GimmeSomeTune right now?

Well, I lost a little time due to my work on Records (which is currently exclusively available through the MacBuzzer bundle) which had to be done for the bundle, so there’s that.

That being said, artwork, lyrics, last.fm and song recognition are all working right now, and beautifully, might I add. It’s almost magical.

Now you might ask, great, so when’s the release, because what’s there left to do?

Everything else. The interface, the popup window, keyboard shortcuts and testing, testing, testing (especially for song recognition, which is quite tricky).

One more thing on iPod last.fm scrobbling

In the blog post I mentioned before, I promised you last.fm scrobbling for tracks you played on your iPod. Turns out it’s not that easy to do.
I will try to implement it for the 1.0 release, but if it takes too long, I’ll move on to other things and get back to it when I’m working on a later update.
Sooner or later, it’ll be in there. But I don’t think it’s that important for a 1.0 release to spend a lot of time on it if I want a timely release (which I, and I assume most of you, do). I hope you understand.

 

As always, I’m open for suggestions and feedback, so please leave a comment, contact me on twitter (see below) or write me an e-Mail. Whichever you prefer is fine with me :)

Thank you for your time and interest,
Matthias

 


My applications and the iCloud

icloudPhoto credit: geeky-gadgets.com

iCloud is a big deal for me, and, I believe, for lots of other developers out there as well. Syncing data has become a lot easier with this new service and the according APIs. I once took a glimpse at the MobileMe syncing APIs and my head still spins a little.

What does it mean for flickery?

I’m still thinking of the implications for flickery. I got some nice ideas from users of flickery on twitter and I’m already looking into what is possible and makes sense in terms of flickery.

I could see flickery syncing the items yet to be uploaded or loocking into iCloud’s photo queue and offer an option to upload those items or at least present them in some way in flickery’s upload view.

What does it mean for ScreenFloat?

For ScreenFloat, In a nutshell, it will sync your shots between your devices (I don’t know if a iPhone/iPad version of ScreenFloat is useful, but I’m certainly entertaining the idea of having the shots on, say, your iPad, as well).
It will sync which shots are currently open and floating, which are hidden, which are in your shots browser, it will sync your categories in your shots browser, and their contents.

This is something I wanted to do from the beginning and I’ve been looking into services like DropBox to implement it. Now with iCloud (and yes, I realize it’s still a few months away) it’s even easier, faster, more reliable and more secure to implement.

What does it mean for GimmeSomeTune?

I don’t believe GimmeSomeTune could have any advantages of iCloud in terms of sync. If you find one, leave a comment or write me an e-Mail :)

Upcoming Stuff?

I have an upcoming app where iCloud will be perfect and will replace a server-client environment with tedious networking stuff. Stay tuned on that :)

[Update (18.06.2011)]

My good friend and honored developer colleague Christian Kienle wrote about the impact that iCloud may have on his applications on his blog.
It’s an interesting read, especially if you’re interested in how you will benefit from iCloud in the near future.


 

Keeping up with me and my software

© search engine journal

photo credit: search engine journal

I just wanted to let you know of the different ways you can keep up to date with me and my software and how to get in touch with me (besides eMail, of course).

1. This blog

Obviously, I’ll be using this blog to let you know about stuff that’s going on, coming up or has happened some time ago to keep you up to date on new version of my apps, new apps, and some thoughts of mine on different subjects.

2. Twitter

I use twitter quite a bit and have twitter accounts for my different applications:




Feel free to follow us ;)

3. Facebook

I have a Group on Facebook which you can use to tell us about things you’d like to see, or discuss stuff amongst others!

4. Flickr

Though my flickr stream doesn’t primarily have to do with my software (though I do post preview pics of stuff I’m working on occasionally), you might be interested in what I do besides coding.

5. Last.FM

If you’re like me, you’re having music playing day in, day out. On last.fm, you can see what kind of music I’m into (spoiler: oldies!) ;)

Bottom Line

Please get in touch with me :) I’m looking forward to all your comments, feedback, inquiries and critique! Thank you!