flickery

Here’s an update on the state of my apps regarding macOS Big Sur and Macs with Apple Silicon.

In short: All my apps are ready for both, and the updates mentioned below will be released when macOS Big Sur is available at the latest (depending heavily on App Review and whether or not macOS Big Sur’s release is going to be the same, fun catastrophe of a surprise as iOS 14’s).

Let’s get into a little more detail.

Yoink for Mac (website | Mac App Store)

Yoink 128 2xFor Yoink – your file shelf that simplifies and improves drag and drop on your Mac –, all I had to do to make it fit nicely within Big Sur was to resolve some UI issues.
Recompiling for Apple Silicon went without further intervention on my part.

– Firstly, I updated the preferences window to the new style (which you can read more about here).
2

– Secondly, macOS Big Sur introduces larger insets for most (if not all) of its scrollable views, so I’ve had to make Yoink’s window a little wider to make everything fit nicely again, while maintaining the new inset and selection look.
1

– Last but not least, I asked Alex Käßner to update Yoink’s icon, and he certainly delivered (see above).

ScreenFloat (website | Mac App Store)

ScreenFloat for Mac App Icon

For ScreenFloat – which lets you create floating screenshots to keep almost anything visible in whatever app, space or window you are – my priority was to get it running natively on Apple Silicon and fix the most glaring UI issues on Big Sur (like the preferences window, again).
A bigger update is in the works, so my attention goes into that, but I wanted to make sure that – until the big update drops – it’ll run as efficiently and well as it can.

flickery (website | Mac App Store)

flickery for Mac App Icon

flickery – a full-featured client for flickr – will run natively on Apple Silicon and received, like ScreenFloat above and the apps below, a minor face-lift of its preferences window.
I’ve also had to remove QTKit (which I mostly did with a previous update of the app for macOS Catalina – but some more references I had kept around came up as an error in Xcode, so those had to go as well).
It was used to allow the user to edit videos before uploading them. It’s gone for the time being, but there are plenty of free tools (including QuickTime Player) that can step up here for the user in the meantime.

Transloader for Mac (website | Mac App Store | iOS App Store)

Transloader for Mac App Icon

Transloader – which lets you start downloads on your Mac remotely from your iOS device – also will receive a minor update. I had to remove some shadows from texts so it would look nicer in Dark Mode (and who does shadows nowadays anymore, anyways…).
I’ve also had to update its use of CloudKit, because some APIs were deprecated and replaced (in particular, I was using CKSubscription instead of the newer CKQuerySubscription). In the end, it was easy enough.
Transloader 3.0 is still in the works (some bits of progress you can read about here, here and here), so, like with ScreenFloat, I wanted to make sure it runs on macOS Big Sur (and natively on Apple Silicon) until the bigger update is available.

Glimpses (website | Mac App Store)

Glimpses for Mac App Icon

Glimpses – an app that lets you effortlessly create still motion videos – will receive a more substantial update.
After I fixed a glaring UI issue where the progress bar that Glimpses shows for the render progress was almost invisible, I gave the video creation algorithm an overhaul, which makes it up to 4x faster than before, which I’m really happy with. Multi-threading ftw! The app, too, will run natively on Apple Silicon.

SiriMote (free, website)

SiriMote for Mac App Icon

SiriMote didn’t require any UI fixes for Big Sur, but v1.3.9 which I recently released fixes a couple of connectivity issues – and already runs natively on Apple Silicon!
The app allows you to control your Mac and apps with your Apple TV Siri Remote.

I’m glad I was able to make all my apps ready for macOS Big Sur, and am very curious where things are going with Apple Silicon!

– Matthias
mail | website | twitter | instagram | facebook

Read more

flickery icon

flickery v1.9.45, a critical bug fix release, has just been released both on the Mac App Store and via the app’s update mechanism.

What’s flickery?

flickery is a full-featured desktop client for flickr, allowing you to manage your photo stream, favorites, albums, galleries and more.

That’s still around?

I admit, flickery hasn’t seen an update in quite a while (the last one on October 24th, 2014 – it’s quite embarrassing).
Managing and maintaining five different apps is quite a task for one person, and in the case of flickery, one thing just lead to another and I somehow was never able to keep updating it regularly.

I had started development of version 2.0, but as that Yahoo sale happened, I paused again, not knowing where things would go.
Now flickr is in the hands of SmugMug, and after a very brief first conversation with them, I’m thinking flickr’s in a good place. Let’s see where things go from here.

What’s New in flickery v1.9.45?

  • A crash was fixed that occurred when loading galleries (which sometimes lead to a crash during authorization)
  • A crash was fixed when cancelling an upload
  • A bug was fixed where you couldn’t take screenshots anymore from within flickery’s upload section
  • Due to the Mac App Store’s API restrictions, flickery now uses AVFoundation for its video playback instead of QuickTime, leading to increased system requirements (macOS Lion 10.7.3 or newer is now required)

Increased System Requirements

flickery used to use the QuickTime and QTKit frameworks for video editing and playback. Trying to compile that code lead to several errors, as the frameworks are not available anymore on macOS High Sierra (possibly earlier), so (with invaluable help from Phil Dennis-Jordan (twitter) ) I had to copy them over from macOS Snow Leopard, since that’s the version of macOS I was targeting.
Building worked, and I was confident I could release right away, but then this happened:

Xcode warning: Deprecated API usage

Apparently, Apple no longer accepts apps that use the QuickTime or QTKit APIs (even if you’re targeting very old versions of macOS). So back to Xcode I went, assessing how much work it would be to move everything from QuickTime/QTKit over to AVFoundation.

The most critical parts were, of course, video playback so you could watch videos posted to flickr. Other parts where I used those APIs were recording photos and videos with your Mac’s FaceTime camera and trimming videos that were longer than allowed for upload, but I decided to scrap those features for now so I could release quickly. I’m guessing they were rarely used anyway, if at all.

Updating the remaining code turned out to be a couple of hours of work (it wasn’t all that difficult, to be honest), but resulted in increased system requirements, as AVFoundation is only available on macOS Lion (10.7) and up.

I wanted to keep supporting macOS Snow Leopard (10.6) with flickery 1.x, but I would have had to take out video playback for that build, and I didn’t want to.

Availability

Version 1.9.45 of flickery is a free update for existing customers of the app, both on the Mac App Store and from the website.

Eternal Storms Software Logo

– – – Do you enjoy my blog and/or my software? – – –
Stay up-to-date on all things Eternal Storms Software and join my low-frequency newsletter (one mail a month at most).
Thank you 🙂

Read more

OS X 10.11 El Capitan

I’m happy to say that all my applications, Yoink, Glimpses, ScreenFloat, Transloader and flickery are compatible with OS X 10.11 “El Capitan” and work perfectly on Apple’s new operating system, which will be released tomorrow, September 30th.

I’ve tested all my apps on the Golden Master of the upcoming Mac system upgrade and haven’t found any showstoppers or issues.

Should you, however, discover anything you feel is a bug, an annoyance or an issue, please be sure to get in touch with me either by mail, twitter or Facebook – I highly appreciate your help.

I hope you’ll enjoy tomorrows upgrade of OS X, I know I am very much looking forward to it!

Read more

(I apologize for the delay with this post, I had to work on updates for Yoink, ScreenFloat and Briefly and of course lots of work happened on flickery 😉 ).

To finally continue with my promised series of blog posts about flickery 2.0’s development, here I am back with: Uploading.
A minor disclaimer before we start: Any interface you see below isn’t anything near final, subject to change, etc etc. 

If there is one part that’s integral to any flickr client, it has to be uploading. So with 2.0, I want to make darn sure that it’s the best you can get.
Let’s dive in! 

Activity (Background Uploading)

In flickery 1.x, uploading blocked the entire app so you couldn’t do anything else but wait. Sure, you got a beautiful sheet window to look at with the currently uploading image slowly transitioning from blurry to focused representing the upload progress, but it wasn’t very user-friendly.
I wanted to change that with 2.0, so now uploads will be in the background, in the app-wide Activities panel where you can track the progress and potential errors of Up- and Downloads.

Activityview

It’s out of the way, you can close it and leave it running in the background (and of course the little image also transitions from blurry to focused 😉 ). When the activity (Up- or Download) is finished, you’ll get an OS X notification letting you know the activity is done.

Notification

Another advantage of background uploads is that you can queue them up. You can begin one Upload and while that is running work on the next. And when you start that one, it will wait for any previous Uploads to finish and then begin uploading.

Adding to Photosets and Groups

Adding to Photosets or Groups for uploads is not very straightforward in flickery 1.x for Uploads. You can’t assign photosets right from the Upload view but have to wait until the upload finishes and the button bar at the bottom changes to “Add to Set” and “Add to Group”. By the time the upload is finished, you might not know anymore which photos you’d like to add to which photoset or you forget altogether. It’s not really a “set it, then forget it” approach.

This is going to change in flickery 2.0. Here, you’ll be able to set everything up beforehand and once the upload itself is done, photos are added to the photosets and groups you have set. So you can set everything up and leave it to flickery to do its thing.

Screenshot of flickery  03 04 2014 18 02 34

Location and Maps

In flickery 2.0, it will be even easier to assign locations to selected items (both photos and videos) using Apple’s MapKit features.

Screenshot of flickery  03 04 2014 18 20 01

The big improvement here is that you can now search for locations and flickery will reverse-geocode that info into a latitude/longitude pair that Maps can understand. If you have a camera without GPS and want to assign a specific location, this comes in very handy.

Sorting

I’m adding better sorting to flickery with version 2.0. As you can see in the screenshot below, you can sort by Date and Title (booooring) but also by location, for example, based on the distance from the selected item. Items without a location will be sent to the end of the list.

Screenshot of flickery  03 04 2014 18 26 00

Using Google’s Maps APIs (because Apple’s reverse-geocoding is a little bit limited), flickery will also let you sort by Country, City and ZIP/Postal Code.
This comes in very handy when you’re deciding which photosets to add to, for example, or just for the general order of the uploaded items and how they will appear on flickr.

Sadly, Google’s APIs are limited as well (2,000 requests per day per IP address), but it’s better than Apple’s limitation (which gives out after about 50 consecutive requests – bug report filed! – and yes, I am not geocoding all items at the same time but one after the other, as “demanded” in Apple’s CoreLocation documentation). But I don’t think too many will run into issues with that.

Filtering

Dealing with many items for upload, it can become overwhelming trying to keep track of everything. With flickery 2.0 I want to simplify that by implementing filters, so you can quickly view only photos or videos, items with or without description, tags, location and if you’ve assigned a photoset/group or not.

Menu

That wil make it easy for you to keep on top of everything and make sure you’ve done everything you had planned for your upload.

Importing unsupported files

Just like in flickery 1.x, flickery 2.0 will let you quickly convert RAW files (which flickr doesn’t accept) to JPEG files, trying to keep as much EXIF data as possible (which is new in 2.0).

Import

Trimming videos has been in flickery 1.x as well, but is now done with AVKit instead of QuickTime and is quicker and more reliable. It offers the same trimming interface you already know (and hopefully, love) from QuickTime Player:

Trim

Editing

I’m not sure yet about how deep I want to go into editing (if at all) with flickery 2.0. I figure, most items will come from iPhoto or Aperture anyway, already post-processed by an app that can do it better and is focused on it more than flickery ever would be.

Perhaps I will include very basic editing functionality like rotating and mirroring, but I think that will be about it.

Quick Uploads

With all this detailed uploading stuff, there needs to be a way to quickly upload something into your stream, a photoset or a group.

So with flickery 2.0, when you drag an image- or video file onto your stream, a photoset or a group it won’t fuzz about and just directly, quickly upload it without you having to do anything else.

 

I think that’s it for this time, I’ll see you next time with some more insights on flickery’s development 🙂

Thank you for reading!
Take care and I hope to see you again next time 🙂

—-
My name is Matt, and I’m the developer of Eternal Storms Software. You can follow me on twitter here: [twitter-follow screen_name=’eternalstorms’ show_count=’yes’]

Read more