Hi,
On 2005-03-14 22:04:03 +0000 Stefan Urbanek <[EMAIL PROTECTED]>
wrote:
Hello again,
(...)
Workspace should be full of those triggers based on notifications.
Basically, Workspace should send a notification on any significant
action that happens.
Installation of a package:
1. user drags a .pkg into */Library/Packages
2. WorkspaceWillCopy/WorkspaceWillMove notification is posted
3. handler recognises: file type = .pkg, destination =
*/Library/Packages
4. handler invokes any additional mechanisms required for silent
installation
5. .pkg in Packages directory is replaced by some 'receipt' marking
that
there is such package installed
Deletion of a package:
1. user drags a .pkg from */Library/Packages into Trash
2. WorkspaceWillDelete notification is posted
3. handler recognises: file type = .pkg
target = trash
4. handler invokes mechanisms, perhaps in the installer.app, to remove
the package
Deletion triggered by moving an application to trash:
1. user drags a .app from */Applications
2. WorskpaceWillDelete notification is posted
3. handler recognises: file type = .app , target = trash
4. handler invokes installer app mechanisms for app removal
5. installer looks for packages where the app belongs
6. installer tells user that he is about to delete an application and
whether it should remove all app related things
Ehe, this reminds me of an idea I had (probably not original...) to
have inside a Mail folder folders with names of people, when a file
was DnD there GNUMail would automatically send the file to the user.
It's more or less the same thing you are proposing, but with .pkgs. I
like the idea, and as you said it is somethings that doesn't affect
the ability of the Installer being used "normaly". It would just call
it in a "use every default, present minimal UI overhead, don't ask
questions, don't give feedback unless an error occurs" way.
There is a small twist one should consider... it would probably be
better to invoke the trigger when a receipt is draged out of the
Receipts directory. This because not all apps are self-contained, and
the part being removed can actually be only part of the overall
installation. I'll say it again, although having everything neatly
inside an app bundle is great, there are situation outside of our
control that demand fixed location and multiple directories.
Furthermore, while most of you regard the ability to have the apps
scatered where the user puts them as friendly, I personally enjoy the
fact that apps will reside in certain locations, i.e., it's an hous
cleaning I don't have to do by myself.
This is not directly related to your suggestion though, that is both
general, implementable cleanly and sound.
Unresolved issue is: how to undelete from trash by drag and drop?
Requirements:
- everything should be transparent (no user interruption if not
necessary)
- user uses only workspace to manipulate files
- experienced users should know about those mechanisms
... and should also be able to go trough the regular UI if they really
want it.
Frameworks/bundles/resources should have reference counting and there
should be retain/release mechanism for them, so frameworks are not
removed when they are still used by an application. The
workspace/environment manager should know about all installed
frameworks
and should know whether a framework is used or not. It can be done by
explicit retain/release mechanism or from looking into all application
bundles from known places (*/Applications). The manager should not
care
about misplaced applications.
OSXGNU effort is implementing extra Info.plist keys to check for
dependencies (looks sort of like the retain/release you mention), I'll
investigate it further.
This is not exactly how it should be done, it is only rough sketch
which
needs to be deeper specified. For example, we will need:
- list of posted notifications
- mechanism in the environment for registering handles/observers for
those notifications
- installer framework/application
What do you think? This definitely needs to be more refined (on the
wiki?).
I'm all for it, not only in Installer bur as a general mechanism that
allows general, well known default actions to be taken transparently,
without any UI overhead and interaction. I think that it should not be
the only mechanism, users should be able to use the underlying apps if
they want to.
Best regards,
fsmunoz
