SUMMARY: CDE - Start app in a given workspace

From: Birger A. Wathne (birger@Vest.Skrivervik.No)
Date: Fri May 09 1997 - 10:12:33 CDT


Thanks to: (email addresses withheld to protect from spammers)
Mark Belanger
Robin Marquis
Christopher Haggard
Teng Renyu

Mark is the prize winner. His email got my brain on the right
track:

> I hope I did not misunderstand the question.
>
> Most Xapps can be started with a -xrm switch. For example,
> the following command would start 1 xterm and display it
> in Workspace 1 and 4.
> xterm -xrm '*workspaceList: One "Four"'
>
> Some clients also support a -workspaceList option directly
> to do the same thing.
>
> Hope this helps
>
> -Mark

This held true for some of the appplications, but not for others.
Some of these apps were built using high-level tools, and in these
cases some did the right thing with -xrm and others didn't.

Also note that for some of the applications, we hadd to specify
the -xrm flag as the last flag. I guess those programs
handle their own flags first, and then hand the rest
over to the X libraries.

One of the apps wouldn't listen to us at all, and that app had to be started
during login. Luckily, it was ok to have this application's workspace
as the default workspace on login. Most of the sub-apps started by
this application seem to be ok, so we just wrapped them with shell wrappers
that added -xrm to the command line.

Note that adding the same resource to the application's resource file
had no effect at all. It had to be specified on the command line.
I guess resources specified in the resource file are not communicated
to the X resource manager?

One application now gets started in an xterm window where the user
is prompted to press return to start the application. This assures
that the user switches to the correct workspace before the application
starts. This is done by something like
xterm -xrm '*workspaceList: Two' -fn <some big font> \
-geometry <center the window> -e /bin/csh \
-c "echo Press return to continue ; read tmp ; start_app ; echo Press return
to exit ; read tmp"

The customer had a preference for using csh, I would prefer always using
sh for programming...

For the longer term, one set of apps will be updated to pick up a
resource from their resource file, and use CDE API calls to set the
desktop. The API calls involved should be
DtWsmGetWorkspaceList - Return list of desktops
DtWsmGetWorkspaceInfo - Get info (including name) of a given workspace
DtWsmSetWorkspacesOccupied - Set which workspace(s) the application should use

There are programming examples in /usr/dt/share/examples.

The original question:
>
> I have a customer with a simple problem. I don't know if the
> solution is equally simple :^I
>
> The customer has 2 different applications. Each has a lot of
> windows. The applications should be started at boot time
> or through menus.
>
> The problem is that one CDE workspace should be used for
> each of these applications. All windows for a certain
> application should automatically start up in the applications
> own workspace, not in the current workspace.
>
> I know there are API calls to do this from within the program,
> but we don't have the time to modify the application. Is it
> possible to do this through X resources or from the command line?
>
> Just to add to the complexity, one of the applications has a
> window that should always come up in all workspaces. The other
> one has a window that does a server grab, so I guess that one
> should also come up on all workspaces so it doesn't deadlock.
>
> Again. Can this be done from the 'outside', or do we have to
> modify the program code? I have found nothing in the CDE manual pages
> or the CDE FAQ.
>
> Actual code showing the usage of the DtWsm* calls would also
> be welcome.
>
> Platform: Solaris 2.5 or 2.5.1 on SPARC.
>
> Please reply directly to Birger.Wathne@skrivervik.no, and I'll
> summarize the responses.
>

-- 
Birger Wathne
Birger.Wathne@skrivervik.no           |  These addresses may *not* be
Birger.Wathne@sdata.no                |  used for unsolicited mailing



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:54 CDT