In priniciple, Spaces is already superfluous. The real problem with Spaces is that hiding applications + minimizing windows does basically the same thing. Hiding applications allow for the creation of any combination of virtual spaces by unhiding a set of applications (and de-minimizing windows). That is what most users, particularly power users, do constantly. Unfortunately, minimizing does not really work. One cannot easily enough discern the content of minimized window s and similarly to switching spaces, OS X de-minimizes windows when and if it feels like. Moreover, I at least tend to forget about minimized windows and usually open a new one with the same content instead.
An alternative solution:What is needed is a sort of a shelf for currently un-used applications and windows. The Dock does a good job for applications but a less good one for individual windows. Something like Expose for minimized (or shelved) windows, perhaps optionally restricted to those within an application should complement it. Spaces already has this Expose-like view of your different shelves, pardon, spaces.
Therefore I think, Spaces should be replaced with Shelf. Shelf should allow you to move windows to different shelves (like Spaces does). One could simply select any shelf to be the current desktop. Hidden applications would not be assigned to any shelf but would simply be added to your desktop when unhiding them. If a hidden application has windows distributed over different shelves, unhiding it would bring up the Expose view of Shelf. Hiding applications would hide their windows on all the shelves as well. This would mean that one would have to arrange any ‘desktop’ one app and one window at a time (if the app only has only one window or all windows in the same shelf, that simply would mean clicking the app’s Dock icon; if the app had windows on multiple shelves, one would have to drag multiple windows). The only real disadvantage compared to Spaces (or a true multiple desktop feature) would be that it would not be possible to quickly switch between multiple window configurations, ie, the positioning of windows (if an app has windows on more than one shelf) has to be re-done every time. The only tricky question is how to differentiate between switching to an application and unhiding it. One solution could be to always unhide and switch only (or a open a new window in applications configured for that) upon shift-click.
The only other alternative would be completely separate desktops with no switching except for intentional switching.
The primary organisation of images in Aperture is via projects (and blue folders containing projects). Every image belongs to one and only one project. Albums provide a secondary organisational structure which is independent of projects but can be freely combined with them.
The main difference is that the same image can appear in several albums. That means that dragging an image from one album to another, ‘copies’ the image, it does not move it (dragging from project to project moves the image). The same image can therefore appear in albums within different projects. And albums themselves can appear outside of projects. Pressing alt, while dragging from album to album moves the image, but only from album to album, the master still remains in its original project.
My advice would be to that any organisational criteria that is exclusive (eg, holiday locations or trips, customers) should be implemented via projects. Any organisational structure that is topical (eg, people vs. landscapes) should be done via (smart) albums. Any output oriented structure (eg, web site, book, presentation) is also best done via (smart) albums, with the build-in web galleries being just a special kind of albums.
Since every image has to be associated with a project, it can be that when topical and exclusive criteria lead to the same structure, a structure based on projects already provides the necessary topical division.
To summarize, first think what ‘exclusive’ organisational structure you want, ie, a structure that is unambiguous, that says this picture should be here and not anywhere else, and implement that structure using projects and blue folders.
Secondly, think about how else you want to access your images and use albums for that (and group with folders when necessary).
A lot of people choose the date as an unambiguous criteria. That is the lazy and unimaginative way (but it naturally works). I think it is worth to make the effort to create a more descriptive structure.
In Leopard, Apple introduced Spaces, a multiple desktop tool. So far, I have not been able to figure out what it is really good for. Most often when my monitor(s) become(s) cluttered, it is because I have too many Finder windows open, some needed for one task and one application, some for another. I can distribute these windows over several spaces but as soon I close all windows in one space and then click back into the Finder to open a new one, I’m switched to another space where there are still open Finder windows. So, Spaces is useless for the task of distributing Finder windows.
In contrary to ubiquious apps like Finder, Terminal, Mail, or Camino, some apps are only used for one task. They could be assigned to one space. Or a combination of two apps could be assigned to one space. Yes, that actually works, but instead of switching between spaces I can just hide and unhide apps, thereby creating my own virtual spaces. What is the point of Spaces if clicking on one app moves you to that app’s space and therefore hides all other apps? Geez, I can do this with alt-click on the app as well. If you could distribute different windows of the same app over multiple spaces, without being transported back to the space with the last-used open window of that app when in fact you want to create a new window for that app in your current space, Spaces would be usefull. Right now, it is pretty useless and just provides a fancy way of hiding and unhiding groups of apps.
After a week with Leopard surprisingly the machine seems to settle down (and I as well, I presume). The hiding issues are becoming less frequent. Mounted servers no longer ask for a password but still sometimes take very long (20 seconds) to mount. The spinning beachball has become less frequent also. Still, fixing and researching all these small issues and exploring all the new functinality takes a lot of time. These pretty minor issues but can easily take one to several hours to figure out. Here is my list of what I had to after the upgrade (necessary even with perfect hindsight):
Necessary installs:
- Developer Tools
- Fortran compiler
- Acrobat plug-in
- VPN client
- Latex subsystem
- Onyx
- Cocktail
- GnuPG (?)
- GPGMail
- LaTeXit 1.14.3 (1.14.4 hangs)
Required reconfiguration:
- repoint svnX
- repoint server alias
- recreate IP printers and obtain their PPDs
- Xcode 3 preferences & shortcuts (took some time to figure things out here)
- redo the Dock (described earlier)
- fix set-up of SMTP server in Mail
- re-adding of ignore-locations for Spotlight
- add the full path back to the Terminal prompt
Do not upgrade to Mac OS X 10.5, at least not now, unless you have really nothing else to do. Wait maybe another six months and make sure to take a week off then, you will need it. Not that 10.5 is in any way a particular problematic update but you will probably find about half a dozen minor issues and each will take about a day to fix. That is why you need that week, and a box of tranquilizers. And hopefully they have fixed one or two of these half dozen issues by then.
Apple may manage to fix in the order of about 100’000 bugs in a major OS release but they also may introduce about new 100 bugs (remaining after the .2 release) and out of these 100’000 fixed bugs one notices possibly ten, but out of these 100 new bugs one also notices about ten. That is the truly amazing part. To give you just a few examples. In Tiger, only a few Adobe apps would not hide with cmd-h (but they would hide if alt-clicked on another app). In Leopard, half of the time when you try to hide an app it will not hide, not by any method. Restarting the app will bring back the hiding capabilities. Or take mounting a server, in Tiger one authenticated ones and that was it for the rest of the year, in Leopard one has to authenticate about every second time, it is pretty random. And the server used to appear in the sidebar, now it may appear or it may not.
All these are rather minor issues but one spends hours first mounting and unmounting servers trying to figure out what is happening and then scouring the net for any indications of what is going on. That is why you need a week to install Leopard. And if during every month waited one issue is fixed then every months waited might save you one day of your life (and possibly even a few weeks of your life, considering the frustation that is avoided).
Macs had a really great Finder. Or at least they had one feature which made working in the Finder very neat when one had to deal with folders containing large numbers of files. Something I regulary run into whenever I start ‘coding’ projects. This includes larger Latex documents and all kind of programming languages where you keep amassing files, source code, supporting files (eg, images in Latex documents), documentation files, output and results files etc.
Sure, one could create subfolders for every kind of file, but as the project went along, ever more files were created, ever more subfolders were necessary and one constantly had rethink the folder structure to keeps things tidy. And then re-adjust the code so that it looked for and placed its files in the right subfolders. And one kept running into trouble because some older code thought a file should be in subfolder A, but now subfolder A was within subfolder B.
On Macs, the easy solution was to simply use a flat folder structure with subfolders only for files which were generated in large numbers. Keeping files listed by recently modified brought a lot of files already into an easy reach. But the coolest thing was that whenever one could not immediately find a file, one just typed a few letters of its name (or content) into the search box and instanteneously the selection of visible files narrowed down to much more practical selection.
I said ‘was’. Because in 10.5, Apple decided that this was a fairly unimported feature and that what people wanted when they typed something into the search box was most of the time finding a file that they had no idea where to find and that therefore should be looked for on the whole drive. Alas, what I considered one of the coolest features of the OS, was considered secondary by Apple. In 10.5 the default behaviour when typing something into the search box is search the whole computer. Sure, one can click on a button and restrict the search to the current folder. But that easy, instanteneous narrowing down of the current folder view is gone. Maybe somebody finds a plist to reverse that behaviour but most people using Macs will longer experience this great feature.
What I am missing with Spotlight in Leopard: Quickly seeing the top five results for different categories. Dito for seeing images as thumbnails and the rest as a list…
svnX is an open source subversion client (svn) for Mac OS X. It requires the installation of the svn command line back end (Leopard includes it already). When it is presented with file conflicts of binary files, it might not be obvious how to resolve them.
In short, pressing ‘Resolved’ retains the local version, pressing ‘Revert’ retains the remote version.
Using Platypus (http://sveinbjorn.org/platypus), a development tool for Mac OS X, all sorts of shell or other scripts can be converted into proper applications. The Perl script to do a ‘Replace all’ presented in a previous post has to be modified somewhat to handle the handover of arguments and file paths.
The code below has to be saved as a .pl file. In Platypus the path of the script has to be selected and the ‘Is droppable’ option has to be chosen. The resulting application can be used as follows. Dropping the text file in which one wants to replace a number of words, characters (to be precise, strings) onto the application. It takes the two lists in a file ‘list-of-changes.txt’ and searches for all instances of the string in the left column and replaces it with the string in the right column and saves the file with the prefix ‘new-‘. The file ‘list-of-changes.txt’ has to be in the same folder as the ‘replacetext.app’.
To be more flexible with the list about what to replace, one can drag two files, the file one wants to modify and the file with the list of changes onto the app as well. This overrides the hardcoded ‘list-of-changes.txt’ file. One, however, has to make sure to select first the file to be modified and then the file with the list of changes.
#! /usr/bin/perl
# Select file to be modified (if no cmd line input present, take file below)
use File::Spec::Functions;
my $dir = catdir $ARGV[0], qw/Contents Resources/;
chdir $dir;
$filename = @ARGV[1];
$changelist = @ARGV[2];
@ARGV = $filename;
# Read file to be modified
while (defined($line = )) {
$content .= $line;
}
# Read list of changes
@ARGV = qw# ../../../list-of-changes.txt #;
if (defined($changelist)) {
@ARGV = $changelist;
}
while (defined($line = )) {
$cta += 1;
@old[$cta] = substr($line, 0, index($line, “\t”));
@new[$cta] = substr($line, index($line, “\t”)+1, index($line, “\n”)-index($line, “\t”)-1);
if (substr(@old[$cta],0,1) eq ‘\’){
@old[$cta] = substr(@old[$cta],1, length(@old[$cta])-1);
@new[$cta] = substr(@new[$cta],1, length(@new[$cta])-1);
}
}
# Apply changes
foreach (1 .. $cta){
$content =~ s/@old[$_]/@new[$_]/g;
}
# Get filename
my $nameonly = substr($filename, rindex($filename,”/”)+1, length($filename) - rindex($filename,”/”));
# Save file
my $name = “../../../new-” . $nameonly;
open my $NEWFILE, ‘>’, $name or die
“Unable to open $name for output: $!”;
truncate $NEWFILE, 1;
print $NEWFILE $content;
close $NEWFILE;
