02 Aug 2014, 13:06
That's good news - I thought it should work fine, but nice to have it confirmed, thanks!
I'm afraid I haven't gotten around to installing Yosemite just yet ... after the holidays, I think!
09 Sep 2014, 09:50
Hey watsona (or anyone who has installed FP on a Yosemite beta),
A favour: any chance you could - using the Yosemite Finder - create a new folder TestFolder on the Desktop, and place an alias to TestFolder inside your FinderPop Items folder, then create a new folder called AAA inside of that so that TestFolder is not empty.
Then invoke FinderPop by clicking in the unused menubar - does TestFolder show up with a submenu containing AAA ? Please post the result here (and the version of Yosemite you've installed.)
Another user is seeing an issue where "TestFolder" menu item shows up, but empty - no submenu. Only happens on Yosemite. Folders he'd created in FinderPop Items before upgrading to Yosemite all worked fine, but newly-created ones don't work for some reason. The permissions look fine and there aren't any ACLs. Disk First Aid et al all report perfect health. In the Finder everything looks fine.
So I'm a bit stumped - is this specific to a couple of users, or does FinderPop have a problem with Yosemite?
Unfortunately I will have to do some serious spring cleaning to get Yosemite installed on my Mac, and I have little spare time at the moment, in the process of finishing off the works for our new flat and then hopefully moving in over the next couple of weeks.
Thanks for any help you can give here!
Edit: User clarified that issue seems to be with newly-created aliases to folders - explicitly creating a real folder inside FinderPop Items works fine.
09 Sep 2014, 11:48
Just checking in, in case there are any replies here, Turly.
17 Sep 2014, 19:37
turly wrote:Hey watsona (or anyone who has installed FP on a Yosemite beta),
A favour: any chance you could - using the Yosemite Finder - create a new folder TestFolder on the Desktop, and place an alias to TestFolder inside your FinderPop Items folder, then create a new folder called AAA inside of that so that TestFolder is not empty.
Then invoke FinderPop by clicking in the unused menubar - does TestFolder show up with a submenu containing AAA ? Please post the result here (and the version of Yosemite you've installed.)
Another user is seeing an issue where "TestFolder" menu item shows up, but empty - no submenu. Only happens on Yosemite. Folders he'd created in FinderPop Items before upgrading to Yosemite all worked fine, but newly-created ones don't work for some reason. The permissions look fine and there aren't any ACLs. Disk First Aid et al all report perfect health. In the Finder everything looks fine.
So I'm a bit stumped - is this specific to a couple of users, or does FinderPop have a problem with Yosemite?
Unfortunately I will have to do some serious spring cleaning to get Yosemite installed on my Mac, and I have little spare time at the moment, in the process of finishing off the works for our new flat and then hopefully moving in over the next couple of weeks.
Thanks for any help you can give here!
Edit: User clarified that issue seems to be with newly-created aliases to folders - explicitly creating a real folder inside FinderPop Items works fine.
So, I tried the experiment, and I see the same flawed results: Testfolder shows witn no subfolder. I'm in Yosemite Beta 3.
I have a folder alias for my Manuals folder in FinderPop Items (created months ago); it contains a subfolder named Bento Manual, which has six or seven files in it. I created a new folder in Bento Manual, checked FinderPop's menu, and the new folder DOES show up. ??
Then, I created a new subfolder in Manuals and, guess what? It does not show up in FinderPop's menu! So the problem may not be with the alias. It may lie with items created within the aliased folder. If that makes any sense. Because the Manuals folder was created way before Yosemite betas.
Using PathFinder, I created a SymLink instead of an alias and put that into FinderPop Items. It worked as the alias should work; the sub-menu and folder showed up in FP's menu.
17 Sep 2014, 20:02
Urk! Caught by my own cleverness.Forget that part about the subfolder in Manuals not showing. It DOES show up. I named it with a leading space to force it to sort to the top of a very long list of files, and then promptly forgot I had done so, and scrolled down to the Ts...and it was not there, of course. But it is sitting right at the top of FP's menu. So, back to the problem being in the newly created alias. Older aliases (aliai?) still work.
17 Sep 2014, 22:35
Watsona, so it appears that you are confirming what I have already explained to Turly; that is, that apparently some changes were made in Yosemite which are apparently breaking aliases of folders, which are being placed in FP's "FinderPop Menu Items" folder.
Turly, as an update, I wanted to let you know that I am now using Yosemite DP8.
It appears that some of the very strange and annoying Finder behavior that you and I discussed earlier has been resolved. Namely, I can now make duplicates of files and folder in a tabbed window again, without the Finder crashing on me.
I can also copy a file or folder to another tabbed window, either using FP's "Copy to" script, or by holding down the option key and simply dragging the file or folder to the other tab.
Copying items into that sparse image that I mentioned to you before, also now works without the Finder crashing.
So, maybe Apple took notice of my feedback reports and crash reports.
At any rate, it seems that we are down to finding out why FinderPop is having these issues with Yosemite.
You are the programmer, not me, so have LOTS of fun with that.
Take care my friend.
18 Sep 2014, 09:13
Just a thought:
I understand that aliases in the FinderPop Items folder that existed before the upgrade to Yosemite continue to works as expected, but that aliases created in Yosemite do not. Correct?
Apple seems to have changed the alias (alias, not simlink) file format before. Aliases used to be small (in bytes) and, if I remember correctly, all about the same size. In more recent OSX versions (since 10.7 or 10.8?) they are of very different size and some are quite large. Maybe Apple changed the alias file format again in Yosemite?
18 Sep 2014, 12:59
FinderPop doesn't look "inside" alias files, it just uses the _FSResolveAliasFile system call to resolve them.
This and other alias-related system calls have been deprecated in 10.8 and later but I'm still using it.
The FinderPop Daemon - which handles clicks in the "unused" menubar - is a Carbon app using _FSResolveAliasFile, and by all accounts cannot resolve these new Yosemite aliases which leads one to suppose that maybe - maybe - Apple changed the Finder alias format so comprehensively that existing Carbon apps using aliases will no longer work.
I've looked at the Yosemite release notes but see nothing about Apple changing the Finder alias format, but their release notes are sometimes lacking (rich coming from me :-)
Unfortunately I'm no closer to being able to run Yosemite, up the walls with 'real' work and preparing a house move :-(
26 Sep 2014, 01:09
I am on a late 2009 iMac. I am unable to get folders to give me the pop out files from a folder alias. If I copy a "test folder" with 2 files in it to the FP item folder I can then get the pop out files from the folder. I have installed for all users and have clicking in unused menubar area involked. Any new insights to this problem?
26 Sep 2014, 07:40
Yes, I'm still not running Yosemite but I think I've fixed - or at least worked around - the problem.
Apple appear to have changed the Finder alias format in Yosemite in such a way that all Carbon apps which work directly with aliases (ie call _FSResolveAliasFile) will break. Yosemite Finder aliases now internally use Bookmark URLs. I've changed FinderPop so that it understands these too.
Here's a beta which should work better with Yosemite. Please don't publicise this, I still have a few more things to fix before I officially release 2.5.7 at the weekend (I hope, this dratted moving house business is dragging on and on... :-/)
26 Sep 2014, 21:22
I have just used Mountain Lion to make aliases of my folders then copied "FinderPop Items folder" to Yosemite user/library and all is working well again.
Thanks to all.
26 Sep 2014, 23:19
You could also use symlinks, which work on all systems.
Anyway, it's fixed in the 2.5.7 beta I referred to earlier.
26 Sep 2014, 23:39
Just wanted to confirm the broken alias behavior continues on Yosemite 14A361c and that symlinks work as expected, though aliases do not.
I am not convinced that the difference is simply between Yosemite-created (or at least newly-created) aliases and older ones.
In my case the aliases "failed slowly". When I first started using Yosemite, I had a handful of aliases in my Finderpop Items folder, and they all worked correctly in the first few days, that is they had |> symbols, and popped their subfolders correctly.
Then one day I noticed one was missing, and a day later, another, this morning only one remained with a |> and by afternoon it had disappeared. Perhaps a background update task, like (or even part of) mdworker is converting those aliases.
For those who want a quick fix and don't know the terminal well:
Assuming you want a symlink for /Applications/Utilities in Finderpop Items:
- Code:
cd ~/Library/FinderPop Items
# the simplest case, make a symlink in the current dir, with the same name as the source
ln -s /Applications/Utilities/
# make another symlink, giving it a different name than the original, adding a 'util' entry to finder pop.
ln -s /Applications/Utilities/ util
The man page for ln and link are a bit confusing. In unix parlance a link has a "source", the original file or folder being linked, and a "target", the new entry (link) being created. This never made sense to me. In my mind, you'd follow a link (the source) to the real file (the target), so I have to look up ln every time I use it :(
27 Sep 2014, 06:55
So did you look at the symlinks that started to misbehave? Are they still valid symlinks?
I just now released FinderPop 2.5.7 which should fix the issue of FinderPop not understanding the Yosemite Finder's alias files.
28 Sep 2014, 21:19
turly wrote:So did you look at the symlinks that started to misbehave? Are they still valid symlinks?
I flubbed that remark, writing "In my case the symlinks "failed slowly". When I first started using Yosemite, I had a handful of symlinks in my Finderpop Items folder, and they all worked correctly in the first few days"
When what I meant was "In my case the aliases "failed slowly". When I first started using Yosemite, I had a handful of aliases in my Finderpop Items folder, and they all worked correctly in the first few days"
Epic fail, completely misleading, and I am fair ashamed
I corrected my original post. Regarding your question, I didn't think to poke at the failing aliases beyond confirming that "Show Original" still led to the folders they'd been aimed at.
29 Sep 2014, 12:00
Ah, OK, that explains it!
Aliases can get updated as the Finder sees fit, in your case changing the format from the old-style alias (which the Carbon File Manager call _FSResolveAliasFile as used in FinderPop 2.5.6 could grok) to the new-style bookmark aliases (which _FSResolveAliasFile was unable to resolve.)
Note that the Carbon File Manager's FSRef interfaces have been deprecated as of 10.8, so at some point in the future I'm going to have to do a serious rewrite of much of FinderPop.
01 Oct 2014, 01:30
The amazing part of this, if I remember my MacOS history, is that Carbon was essentially obsolete by the end of the 20th century, when Jobs brought BSD & NextStep into Apple. But Apple still managed to support most of it nicely all the way through a CPU change, and a dozen years of OS improvements. (well, mostly they were improvements
) I suppose that once committed to supporting HFS, they were stuck with all the old FS<mumble> APIs. By no means am criticizing you for using the Carbon APIs. FinderPop has been my goto tool for ignoring the dock and finder for so long I can't remember when I bought you my first pint
In fact, in recognition of 2.5.7 and Yosemite, which rather looks like the no-color-pencils-in-the-box Mac UI of the 20th century, I just stepped over to paypal and hoisted you a beer. Thanks again, for the first utility I install in every fresh instance of OS X.01 Oct 2014, 08:53
Well, first, thanks muchly for the pints - I'll raise my glass to you next time I'm down the pub!
As for the Carbon APIs, a lot of the FinderPop file manipulation code is still based on that -- there's quite a bit of surviving Carbon code from 1997 (except it wasn't called Carbon then of course.) And the amount of MacOS software using "Carbon" APIs completely dwarfed the amount of NextStep/BSD software back then - suddenly telling Mac developers that they now have to use NextStep APIs would have resulted in mass defections to the likes of BeOS or (shudder) Windows. I still wonder what would have happened had Apple bought Be Inc. instead of NeXT... would they even be around today?
I still have my Inside Macintosh volumes I to VI ... around 3000 pages, currently weighing down one of my bookshelves and causing cracks to appear in the plaster of the wall. I vividly remember the first time I devoured IM I-III back in 1986 or thereabouts, my jaw dropped ... here was a company doing computers right!
Mind you, it wasn't exactly easy reading, one wag quipping that "it consists of 40 chapters, each of which requires that you read the other 39 in order to understand it." :)
01 Oct 2014, 18:37
When I first started writing for the Mac, around 1987, it was the first time, for me, while working deep inside an OS, that familiarity had not bred contempt. Object Pascal, MacApp, and the still-unreleased Mac II and color QuickDraw were just miraculous! Ah those halcyon days of wonder <3