On 23 Apr 2005, at 13:34, Nicolas Roard wrote:
an user could then use theses components to do what he will do with garageband. But the UI will truely, absolutely, sucks.
Perhaps we could provide a lightweight scripting language, with a UI like Automator (or, at least, how I assume Automator works - I haven't actually used it) for combining components, perhaps built on StepTalk? `Applications' would be sets of components, perhaps including some fairly specialised ones that probably won't be used elsewhere, combined using a simple script. This way, we can give the user a well thought-out UI for a particular task, while giving them the complete freedom to customise it. Ideally, these scripts should refer to rôles / interfaces, rather than specific components, so a user can replace supplied components with a custom one (e.g. replacing the colour picker system wide simply by replacing that component with a different one, and assigning a higher priority to the new one).
Ideally, we would combine the application scripts with a simple download and install tool, so a user could download just the application script, run it, and have the required components that are not available installed automagically.
On an unrelated note, there was some mention of inode-based aliases earlier. I am not entirely sure what this is intended to mean. In UNIX, we have two things like aliases - soft links and hard links. A soft link is just a pointer to a file name. A hard link is just another reference to a file's inode. Creating a hard link increments the file's reference count, and the file is not deleted until the last hard link is removed. These are not really aliases, however, since they are have first-class status. On MacOS, aliases are a higher level construct. They point at files in an abstract file space, which is shared across all drives connected to the system. This allows the destination of an alias to be moved around between drives without breaking the alias, which seems a much better solution than depending on inodes.
