Re: Running an application more than once

Tom Harrington <tph@xxxxxxxxxxxxxxxxxxxxxxxxx> writes:
In article <haberg-0806071939060001@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
haberg@xxxxxxxxxx (Hans Aberg) wrote:

If one can run applications more than once, then, with two displays, one
can for example choose to combine them to single display, or run multiple
Finders, just as one can do with X11.

Well OK but I still don't see the point. Why run multiple copies of an
application to do something that a single copy is already more than
capable of doing? You're proposing a more complex situation than the
present, for no readily discernible reason.

I also want this feature badly as it accomodates my work style,
which is more complex than most users. (I am sure that I've
written about this before; here we go again...)

I generally want several instances of certain apps running
because I switch back and forth on unrelated projects,
and don't want to have to manually re-establish state.

One example is: I want one instance of the web browser open
for accessing a site that I am developing, and another instance
of the browser open for accessing developer documentation while
I am working on the site. And perhaps even third for accessing
the administrative interface of the web site.

Another example is that I run a program called "Emacs", which is
actually an entire application platform -- the single program
can be used for a variety of different purposes. For example,
it can be used as a web browser, an email system, a Usenet news
reader, a source-code editor, and an IDE with a remote debugger.
You can also play the game of hangman with it. And while you
can do all those things (and many more) simultaneously, I like
to sometimes segregate them. I normally run at least three
instances of Emacs (under OS X) all at once, all the time.

The feature being asked for is to have logical "workspaces" inside
an application: the application supports multiple windows (as they
do now), but those windows can further be arranged into groups.
This is similar to the idea of tabs in your web browser,
except it's window-oriented.

For example, when I run the web browser, there are a group of
windows corresponding to the site I am developing, some other
windows that are documentation, etc., and I can switch from
group to group.

A critical part of this feature is an implementation detail:
they must really be seperate running instances of the app.
This is because we want to be able to kill an instance,
forcibly closing out that workspace. This is because all
apps are buggy to some degree, and we don't trust them to
stay up indefinitely without getting wedged or leak.
It is therefore very important that we be able to kill them
off in this way --- and luckily it's also the most natural
way to implement the desired feature and basically already
works in OS X. the Mach process resources correspond to a
group of windows: an application's workspace corresponds to
an instance of the application;

No problem there, except that most Apple-conforming applications
assume that they are the only running instance, and can therefore
access data files (eg. Preferences, Cookies, etc.) without interference.
Fixing this would not be all that difficult to program correctly,
but existing programs don't handle it. (Note that for some programs,
especially ones ported from Unix, it does not matter.)

A further improvement beyond app-multiple-workspace-instances is
the ability to link those application workspaces into a "desktop".
An application instance can appear on one or more desktops,
so that logically related applications can be grouped together,
and there can be more than one set of them (possibly with
overlapping instances).

So on one desktop you could have a couple of instances of Safari
(each of which has a set of windows open) and an instance of
iTunes and an instance of Mail -- and then you could switch to a
seperate desktop that had some other combination of those or different
apps (similar to logging in to another account). There might be only
one instance of Mail, shared across all those desktops.

Desktops are almost the same thing as simply logging in more
than once, except that they can share (and communication with)
application instances. On a given desktop, there can be more
than one instance of an application running.

Unix already has the features described above, supporting multiple
instances of apps, arbitrarily arranged on multiple desktops.
(Even MS Windows supports the multiple instances part.)

I thought that both Vista and Leapord were going to support
something like (or hopefully exactly) what is being asked for.

Now, on to the communication problem...

Except for cut-and-paste, I don't use any application integration
features under Unix, so I don't know how they do any inter-app
communication ala Applescript. Probably there isn't any.

For OS X, The only problem with any of this is Applescript,
which generally uses the name of the application to route events.
If there is only one instance of each app on the desktop, there's
no problem: apps on the same desktop talk to each other.
When there are multiple instances of one of the involved apps,
generally only the user knows which one is which. (When apps
launch other apps they could automatically be paired, though.)
The obvious solution would be a GUI that pops up when there is
an ambiguity. It would somehow show the app instance (of all
the instances of that app in the current workspace) that is
originating the event, and ask you to pick the destination,
and by default checkbox make all AS events route between
those two instances.

======================================================
{this here flashing} iTunes wants to talk to "Safari".
There are 3 instances of Safari running.
Please select the desired Safari instance.
[x] pair these instances together for all
future AS events in this session.
======================================================

Other refinements on the routing/pairing solution are possible,
perhaps more default routing rules, non-GUI instructions, etc.

So this whole thing seems to me like a pretty easy thing to put into OS X.
Are there issues I didn't think of, offhand?
.

Relevant Pages

  • Re: Problems with WMIPRVSE.exe (100% CPU load) after Advanced Clie
    ... Why have a second remote control application installed when SMS ... provides this feature? ... multiple RC apps will cause problems. ...
    (microsoft.public.sms.setup)
  • Re: Problem with Internet Explorer
    ... You can use popup blocker to stop popups from loading and covering your IE Window. ... Whenever I am starting multiple IE windows it is enabling "always on top" ... disable the "always on top" feature for windows xp professional. ...
    (microsoft.public.windowsxp.general)
  • Re: Vista so secure it doesnt need Anti-Virus
    ... something that's not generally required in Windows ... apps. ... to me that's a "feature" rather than a flaw. ... accidentally access a window just because I accidentally bump my mouse ...
    (comp.sys.mac.advocacy)
  • Re: Slow...but not the usual suspects. A hand, anyone?
    ... >minimum for Windows XP ... and I find 128M is pretty uneventful as well. ... you want to run big apps as well as the OS, ... To disable the 'Tip of the Day' feature... ...
    (microsoft.public.windowsxp.general)
  • Re: Slow...but not the usual suspects. A hand, anyone?
    ... >minimum for Windows XP ... and I find 128M is pretty uneventful as well. ... you want to run big apps as well as the OS, ... To disable the 'Tip of the Day' feature... ...
    (microsoft.public.windowsxp.help_and_support)