Springy Services (SpringyCM life after death)
Dragan posted Oct 4th 2009 at 9:25PM
In the previous blog post I explained in detail the full life cycle of the Springy contextual menu plug-in. The reason it will start dying slowly and finally pass away with support for Leopard is Apple’s decision to kill contextual menu plug-ins (together with other means of loading arbitrary code into 64-bit Cocoa applications) in Snow Leopard. This effectively prevents Finder in Snow Leopard (which is a full 64-bit Cocoa application) from using third party contextual menu plug-ins.
Apple suggests using of system Services Menu as a replacement for CM plug-ins, so I decided to go that route and not to try to invent some unsupported way of loading CM code into Finder, which could break with every OS update. Services Menu has undergone complete overhaul in Snow Leopard. It’s much more configurable now and more pleasant to use. Also, the OS provides Services Menu items on more places, not only in the standard, well known, Services Menu.
Springy will become so-called “services provider” application in version 1.6. It will offer its services not only to Finder, but also to every (Cocoa) application which can provide file names list in the pasteboard for Services system to use. I didn’t check it myself, but this people will enable using of Springy commands from other file managers (like Path Finder and ForkLift), even from other applications, such as Apple Mail for example, where you’ll be able to invoke Springy commands on e-mail message attachments.
Now, the time has come for small show-off. The following shots show different ways Springy commands will be invoked:
This one shows Springy commands in the Services Menu in Finder:
Here, you see Springy commands in the menu of the Action button in Finder:
And off course, Snow Leopard provides showing for Services Menu items in a contextual menu, so you can see it here:
When any of these actions is selected, Springy application will start, but not in its normal mode (window which shows the contents of an archive), but in “services provider mode”, with the UI similar to that of CM plug-in:
Upon finishing a task, Springy application will automatically terminate, unless some other processing is ongoing or there is at least one open archive with window showing its contents.
As you can see, you’ll be able to use Springy application in “services provider mode” just like old SpringyCM plug-in. But you can also find its command elsewhere in the system, and all this flexibility is provided by the OS.
Unfortunately, like stated here, there will be no more possibility to browse archive contents using hierarchical contextual menu. Implementing this would require much more dynamic nature of the Services Menu architecture. I’ve already filled a bug report/request for Apple to provide such architecture, hopefully they will listen. Some users have already said to me that while they found CM-browsing of archives very impressive, they personally did not find it as fundamental as the other functionality that Springy will continue to be able to provide in Snow Leopard. I hope most users feel the same way, but I’m pretty sure some will be very disappointed by this. I myself, am very disappointed and I really hope something will change in that regard very soon.
One unanswered question is when Springy 1.6, with all this goodies, will be publicly available? My intention is to release it at the very beginning of November. The only thing preventing me of doing it sooner is fixing some bugs and improving some aspects of reading and extracting of 7Z archives. Yes, in version 1.6 Springy will finally offer some kind of support for 7Z archives! In the beginning, this support will include only opening/browsing/extracting files from 7Z archives, but during 1.6.x development cycle all other operations on 7Z archives should be in place for users to try them out.
I hope you all are looking forward to release of Springy 1.6, especially those who have already switched to Snow Leopard.
Dragan
The life and death of Springy contextual menu plug-in
Dragan posted Aug 26th 2009 at 9:20PM
A while ago, in April when I started this blog together with releasing version 1.5 of Springy, I promise myself I’d write a post about how the whole story of Springy started and evolved; why I decided to make it, when the development started, what were the main obstacles during the process, why at one point I almost decided to abandon it even before the first release hit the public…
I’m still committed to writing that blog post. But recent events surrounding a near release of the new version of Mac OS X 10.6 (also known as Snow Leopard) reversed things a bit. So instead of writing how Springy was born first, I’ll start the opposite way and first write about the certain death of one of its components: that’s contextual menu plug-in.
The idea of making contextual menu plug-in which would execute menu archiving tasks didn’t come at the same time when the overall idea of making Springy. It came much later, when the application was nearly finished, needing only some polishing, minor tweaks and deciding on and implementing licensing model and purchase processor. The idea wasn’t even mine, it came from a person who, together with some others, served as kind of beta tester during the development of Springy, trying it out, reporting bugs and strange behaviour and also providing a lot of useful suggestions and remarks. For what it matters, the name of the person is Mladen Đurić. He was using CM plug-in which came as part of StuffIt Deluxe bundle a lot. And while some other people trying out the application being developed also used that plug-in, Mladen was very loud and quite convincing in asking for similar thing in Springy.
So I decided to listen to him and implement it. Once it was nearly complete, and the whole package consisting of Springy application and Springy CM plug-in was ready for release, Mladen made a new request, to implement one specific feature for which StuffIt CM plug-in was unique: ability to browse an archive using hierarchical contextual menu and than extract only single file/folder from it by clicking its menu item (StuffIt decided to remove this particular feature when introducing version 11 of their DeLuxe package). I investigated the way that feature worked in StuffIt CM plug-in and I didn’t like it much for two main reasons: (1) the plug-in would open archive for browsing even before Finder would show contextual menu, regardless whether user really wanted to browse archive, or perhaps just to change colour label of a file. This could lead to a significant delay of contextual menu appearance, especially with large archives. And if user wanted, for example, just to select “Get Info” item, the delay could be really annoying. (2) Second, when browsing archive StuffIt CM plug-in would show one menu item for a file, but two menu items for a folder! One of them was there just to make extraction of the folder possible; a click on it would start folder extraction. The other one was having a submenu, consisting of folder’s children. It was there to enable further browsing through archive hierarchy. This was the consequence of parent menu items not being “click-able” in CM plug-ins by default. You can see how it looked like in the picture below.
Needless to say, I really disliked this implementation and surely didn’t want to go the same route. I wanted: (1) archive being open only if a user really choose to see its contents (at moment of highlighting menu item with archive name) and (2) click-able menu items with children, which would represent folders, enable further browsing through archive hierarchy, but also extract the whole folder on a click on it. In order to achieve these goals, I had to avoid usage of standard CM plug-in API for this particular feature. And since it would require more time for investigation, implementation and testing, I was reluctant to go for it. But then again, Mladen was very convincing in that would be “a killer feature” of Springy CM plug-in. So at the end, I obeyed his request and implement it. It took some time though, but I was really satisfied, perhaps even impressed by my own work. The improvements over StuffIt CM plug-in are clearly visible in the picture below.
Finally the complete Springy package was ready for public eye (licensing and purchasing processor issues were solved meanwhile). CM plug-in worked beautifully. Well, some users saw some crashes when trying to show contextual menu in Finder and in other application and all that was caused by my modifications of Sparkle framework and the way I embedded it in the plug-in (since it was meant for usage in application bundles only). But even in those cases, fixing the problem was fairly easy: just re-install (delete and copy back) the plug-in. This was finally fixed in version 1.5.
The happy hour didn’t last long though, since Apple started kicking in. The first big disturbance came when Mac OS X 10.5 (Leopard) was introduced. It basically caused two issues: (1) all third party CM plug-ins were moved out from the root of Finder contextual menu into the “More” submenu. As a result, menu users immediately started asking if I could move Springy menu item back into the root, since they really disliked having to go one more level into menu hierarchy to do things they were used to do quickly. And (2), the moment third party CM plug-ins got initialised was also changed (I should better say: delayed) which required moving of cool archive browsing menu item even one level deeper into menu hierarchy, which even more annoyed some users. The reasons why Apple decided to make those changes are out of scope for this post, but they caused a lot of arguments among CM plug-in developers.
As I felt a bit pressed and responsible for many users requesting Springy back to the root of the contextual menu, I started playing around in an attempt to achieve that. And after some time I made it. In version 1.5, Springy CM plug-in item was moved back into the root of the menu even in Leopard (in Tiger, it was always there). It required almost complete work around standard CM plug-in API, but I got it fully functional eventually. Not everything was perfect though, a user has to give a “push start” to Springy CM; “More” menu item has to be disclosed at least once after every restart/login in order to make Springy appear, but I think it’s a small price to pay for those who wants it in the root, saving them time for deep menu hierarchy navigation. Eventually, some users were not happy with Springy back in the root, they wanted it in “More” submenu, so starting from version 1.5.5, one can set location in the preferences.
Then, Apple kicked in again, this time with the release of Mac OS X 10.6 (Snow Leopard). According to what can be read in this messages thread, “There is currently no way to extend contextual menus in 64-bit apps. Snow Leopard includes some significant enhancements to the Services architecture that are designed to partially replace the capabilities of contextual menus.“ and “As far as I know, it was made for exactly the reason I specified — the Cocoa team really doesn’t want to load arbitrary code into every Cocoa process because of the risk of malware being loaded. Please take me at my word.“ says Eric Schlegel from Apple (sorry for citing you Eric, I hope you don’t mind it). Since the Finder in Snow Leopard is 64-bit, this essentially means no third party CM plug-ins for Finder in Snow Leopard. This eventually is the final nail in the coffin of Springy CM plug-in.
What is the aftermath of this? CM plug-in will still be offered for Leopard users for some time in the future, as long as Leopard is supported by Springy. The same applies for Tiger, although for much shorter time period (1.6.x cycle will probably be the last one supporting Tiger). But, there will be no further development of the CM plug-in. It will stay as it is now, slowly dying together with user base of Leopard and Tiger. As of the “bright” future… Almost all functionality offered today by the CM plug-in will be offered in form of Services menu in Snow Leopard, as suggested by Eric. Springy application will have its current feature set, but will also become a Service Provider for Finder and other applications what can handle files placed on the pasteboard. This is a clear benefit, since one would be able to use Springy services not only in Finder, but also in Path Finder, ForkLift, Apple Mail (with attachments embedded in messages) and many other applications.
What about cons? Didn’t I mention “almost all” in the last paragraph? Well, the current Services architecture is not dynamic at all; all menu items offered by an application have to be hard coded. Also, in Snow Leopard Services menu cannot have more than one level in hierarchy. Three particular features of Springy CM will suffer (won’t be possible any more): (1) no ability to browse recent and favourite locations through menu hierarchy to extract files into one of them. (2) No dynamic change of menu item titles when using modifier keys (feature introduced in Springy 1.5). And finally (3) the BIG ONE: no more ability to browse archive and extract particular file/folder using hierarchical menu items! Yes, “the killing feature” of Springy CM plug-in will be gone in Snow Leopard. Sad, but true.
Of course, there is always possibility that Apple will change something in Services architecture and provide some dynamism for its menus and menu items. I know that many developers are not very pleased with the changes mentioned above, so they filled bug requests, asking for more dynamic behaviour and suggested to me to do the same, which I did. But at the end, it’s up to Apple to listen. If at any time Apple makes changes which enable implementation of the above mentioned sacrificed features, you can be sure they will be back soon afterwards.
One more information at the end; the version 1.6, with Springy application being a Service Provider, will not be available at the time Snow Leopard is released, since I want it properly tested. I expect it going public at around October 15. Hopefully this is not much waiting for users. By that time, we will probably have the first upgrade version Mac OS X 10.6.1, fixing some bugs and issues which skipped final testing. At least that was the chain of events with previous OS versions.
Springy 1.5.6 released
Dragan posted Aug 16th 2009 at 1:45PM
This sunny Sunday came perfectly to spend some time on making a new release of Springy, version 1.5.6. This release is made solely for maintenance purposes. It just fixes some annoying bugs and irregular behaviour, not bringing any new features. Two of those bugs could crash some applications when user tries to show their contextual menus and also caused collision between SpringyCM plug-in and Springy application, preventing application from showing its own contextual menu. I found those bugs quite annoying and fixing them important, so I opted for a new release quickly after the version 1.5.5.
As usually, the full list of changes is available on the version history page.
Worth mentioning is that work on the version 1.6 is in progress in parallel with regular maintenance activities for the current version 1.5.x cycle. The version 1.6 will make Springy “compatible” with the new release of Mac OS X 10.6, also known as Snow Leopard. Application already works in Snow Leopard just fine, but contextual menu plug-in won’t work at all due to some architectural changes in the OS made by Apple. The functionality of current CM plug-in will be offered in form of Services menu commands, which undergone significant change and enhancements in Snow Leopard.
More information on making Springy “Snow Leopard compliant” you will read in the next blog post in a few days. Meanwhile, enjoy using this new version.
Dragan
