Apple

NewImage

© Image by Apple, Inc.

OS X Mountain Lion

OS X Mountain Lion has hit the shelves on the Mac App Store and it’s off to a very good start.

So where are the updates for Yoink, ScreenFloat and flickery?

For all of my apps, I’ve submitted updates to the App Store at the beginning of July but they’re still “In Review” or worse, “Waiting for Review”. Here’s the run down of what’s working or not working on OS X Mountain Lion.

Yoink

Yoink works perfectly fine in the currently available version (2.1.1). The upcoming update is a bugfix and minor feature release.
Nothing really changed for Yoink in OS X Mountain Lion that would break the app.

ScreenFloat

ScreenFloat has some minor issues. It works well, but you’ll notice that the “Launch ScreenFloat at Login” checkbox in the preferences is enabled although it shouldn’t be and will crash the app when clicked.

Another issue is with running ScreenFloat with the Dock icon enabled. Floating shots will not follow you to fullscreen apps or spaces. I’m currently looking into that. In the meantime, you can disable the Dock icon and it will work.

flickery

flickery is the most troubling. Not because of OS X Mountain Lion (some minor issues aside – like, the “Nearby” search doesn’t show up – it works well).

The troubling part is that flickr is shutting down their flickrAuth authorization mechanism by July 31st. Yes, that’s very soon and there’s no update out yet for flickery.
I’ve requested an expedited review by Apple for it and I hope they grant it.

If they don’t (and still, if they do, there’s a chance), it might take longer than July 31st for Apple to review the app. What that means is that authorizing flickery to work with your flickr account will not be possible. Also, although flickr doesn’t explicitly state this, it’s inferred that anything done over the flickr API with an old authorization token (an authorization token is what an app receives from flickr when the user authorizes the app to work with their flickr account) will not work anymore. So browsing, uploading, really anything you can do with flickery, will not work.

Please be aware that the upcoming update does include the new OAuth authorization and will make flickery work again with flickr. Until it is reviewed and released by Apple on the App Store, please have a little patience. I know it’s not ideal, but at this point, I’ve done all I can do.

Concluding,

aside from some minor issues with ScreenFloat and flickery, everything basically works on OS X Mountain Lion. For these issues, updates are currently “In Review” or “Waiting for Review” by Apple and should be released soon.

As for flickery, I’ve requested an expedited review and I urge you one more time to consider having a little patience 🙂 Trust me – it troubles me more than anyone.

Thank you for your time,
Take care,

Matt 

[twitter-follow screen_name=’eternalstorms’ show_count=’yes’]

[twitter-follow screen_name=’flickeryapp’ show_count=’yes’]

[twitter-follow screen_name=’screenfloatapp’ show_count=’yes’]

[twitter-follow screen_name=’gimmesometune’ show_count=’yes’]

Read more

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

Read more

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

Read more