Comments by user "zog"
Registered since: August 10, 2008
iTunes: add tracks in order
Ahh, so really what you're after is sub-sorting. Just like "Album by Artist" and "Album by Year" are pre-packaged sub-sort combinations, you're looking for "Album by Date Imported" -- or that effect.
That clarifies the intent behind the original post a great deal.
Still, changing the system-level code that hands iTunes the list of files to import is far from the only way to solve this problem. Direct support in iTunes for the sorting criteria you're looking for (whether in an "Album by Date Imported" column or something else) would be simpler to implement and make more sense.
In the meantime, I'm sure an AppleScript would be capable of creating a playlist sorted in the manner you want. Maybe there's one out there already.
Otherwise, perhaps a Smart Playlist could at least give you some of the utility of what you're looking for. For example, I have Smart Playlists for "Imported in the Last Month", "Imported This Year", and so on.
Sorry if the community aspect of promotion/demotion is frustrating you, but I hope these suggestions are helpful.
Folders mixed with files in the Finder
There *MUST*? Once and forever?
Just go download Path Finder (http://www.cocoatech.com/download.php). It has customizable smart sorting where you can get exactly the feature you're looking for, as well as umpteen others.
Better picture viewer
This is unnecessary, as Preview already has the ability to view several files at once. If you want to view the entire contents of a folder, simply hit cmd-A to select all files in it, then open them with Preview.
Moving files via Finder
Grey's comments are spot on. You could also use List View, and navigate, expand, and collapse folders from the keyboard that way, if you prefer.
Better mouse acceleration curve / Better "mousing feeling"
"If you're happy with the current mousing feeling, you shouldn't demote this one."
That doesn't make sense to me, because your first solution is to change the default. I don't know if your idea of a "better" default curve would equal mine, and I'm quite satisfied with the current default.
If your solution had omitted the part about changing the default and *only* read "Add a way for people to select different curves via the command line," I would have promoted it instead of demoting it.
Folders mixed with files in the Finder
While you could still segregate manually by moving your folders to a separate folder from your files, I definitely agree that richer support for tagging in the Finder would be a godsend! One day, hopefully...
Folders mixed with files in the Finder
The user already has unbounded organization options. They're just not expressed in exactly the way you were expecting.
Adding another preference option adds complexity, however small. In principle, I'm against added complexity, but sometimes the payoff justifies added complexity.
In this case, there's no payoff because you already have multiple ways to segregate your folders so that you aren't required, as was originally written, to hunt for that specific folder you want to drop things in.
Complexity + no payoff == bad for the UI. The user already has choice, so all I'm downvoting is needless complexity.
Icon inconsistency
IMHO the two examples given are representative of two different ideas and don't support the same change request.
The folder one is quirky, but something that perhaps should be updated if only to shed the "branding" of previous OS incarnations.
The eyeball icon, on the other hand, is an example of using the same icon to perform two different functions. A key mitigating factor, though, is that the two buttons occur in completely different *contexts*. In one context, the symbol means one thing; in another context, the symbol means something else.
Now, I agree, using two different symbols would make their different functions more explicit. But I see nothing wrong with reusing a symbol to mean something else as long as the other meaning occurs in another context.
We use context to change meaning all the time. The word "fire" refers to one thing in front of a warm hearth, but something very different when used on a battlefield.
Key combination Cmd+Tab doesnt cycle windows, only Apps
The Mac's window paradigm is built on layered applications as well as layered windows. Windows, KDE, etc., on the other hand, are only window-based.
The command-tab key shortcut works *in concert with the layered application paradigm* just fine as is. To create a global key shortcut for cycling through all windows across all applications undermines application layering and introduces an inconsistency, though perhaps one that you would find convenient.
If you think the application layers are a bad idea, then that's okay, but that should be addressed as a far larger interface redesign beyond the scope of the command-tab shortcut in order to preserve consistency.
Left handed system or customizable positions and colours of window elements.
The directionalities you mention have less to do with the user's right- or left-handedness, and more to do with conventions of information organization. We read English text left-to-right, regardless of whether the reader is right- or left-handed. Hierarchical trees tend to be rooted at the left, regardless of the biology of the user. Windows has its close boxes in the top right, and the Mac on the left, and yet surely their user bases are not dominated by right- or left-handers.
Movie/Video files and folder mess
Though there's nothing to prevent it, the contents of an iTunes library isn't really intended to be browsed via the file system. In fact, it could get confusing to do so since iTunes usually manages that folder structure, causing files to move and get renamed independent of user actions.
On the other hand, you do have a point about using the Music and Movies folders to contain what they say they contain.
Considering all these points, why not keep the entire contents of an iTunes library in ~/Library/Application Support instead? That'd keep it browsable by a user in the Finder, it'd keep things together under one parent folder to facilitate iTunes' automatic managing, and it doesn't violate the naming conventions of the Music and Movies folders.
Folders mixed with files in the Finder
If a segregation between folders and files is desired, simply segregate them into their own folders. Or sort by type.
The real quirk lies in UI's that *prohibit* mixing of folders and files.
iTunes: add tracks in order
Wrote on December 16, 2008, 7:03pm
This discussion seems to highlight one of the pitfalls in how this community is set up: we're not just identifying problems, we're also proposing specific fixes to them. The former are easier to agree on than the latter.
I think we can all agree that the sorting quirk in the iTunes UI which migueld identified is, at the very least, a potentially annoying inflexibility in iTunes. That is, it would simply be nice, somehow, to be able to sort albums by the date they were added, but by track within the album.
But several of the mechanisms proposed so far are quite unpalatable to me, including adding a "date album added" metadata property. iTunes already has the "date added" metadata for each constituent song -- if you're looking for "date album added", all that remains is to use some aggregate function (min, max, first, last, average, whatever) to *infer* it from the constituent dates.
As I peruse Aqua Task Force, I can easily agree that most of the quirks identified are legitimate problems. But most of the solutions proposed would either cause another problem, or break UI consistency, or introduce needless complexity, or otherwise interfere with something about the Mac I like. Perhaps the original submitter didn't think of those side effects, or perhaps they simply don't agree that the side effects are undesirable. Regardless, I end up voting them down, as I did with this one.
I would be curious to see how much the voting results would change if the structure of the community were different -- if solutions were separated from problems.
People could submit quirks they notice, simply describing something as a problem, and then the community could vote on whether they agree to acknowledge the quirk as a problem. Then, for every quirk, people could submit potential solutions, which would have their own, separate voting structure.
As things stand right now, there's no way to tell if someone voted "no" because they don't see the problem or because they don't like the proposed solution. All we know is that "yes" means they agree it's a problem AND they agree with the proposed solution.
Perhaps that helps offer an explanation of why there are so many "no" votes that puzzle and frustrate the original submitter. Unfortunately, I think the submitters will simply have to live with it as long as the site stays structured the way it is, or unless their proposed solutions are obviously and indisputably an improvement to the status quo.