Tk with CDE or VUE ?
Jim Arnott
Has anyone found a solution for getting tk4.1 to display on an
alternate CDE workspace.
wish -xrm "*workspaceList: Two"
Does not work as expected.
Thanks,
Jim Arnott
jar...@bridge.com
Diefenbach LR
In article <51pg9a$f...@news.bridge.com>,
jar...@bridge.com (Jim Arnott) writes:
>
> Has anyone found a solution for getting tk4.1 to display on an
> alternate CDE workspace.
>
> wish -xrm "*workspaceList: Two"
>
> Does not work as expected.
>
wish -xrm "Dtwm*WorkspaceList: ws1"
--
Later Les...
----------------------------------------------------------------
Les Diefenbach
Computer Sciences Corporation
Email diefen...@lmtas.lmco.com
Everyone who believes in telekinesis, please raise my hand
----------------------------------------------------------------
Jim Arnott
>Try using:
>wish -xrm "Dtwm*WorkspaceList: ws1"
>--
>Later Les...
Nope, does not work.
wish -xrm "Dtwm*workspaceList: Two"
wish -xrm "*workspaceList: Two"
Will not work either. :(
It seems that with does not pass the -xrm to X ???
thanks,
Jim Richardson
With ICCCM compliant X applications, the "workspaceList"
directive can be successfully specified by means of the
'-xrm'(ie, 'X resource manager') argument, as follows:
My_X_App -xrm '*workspaceList: all'
This example would invoke the application "My_X_App" to
display in all present(Or FUTURE) workspaces.
If the user finds any application which does NOT
RESPOND to the workspaceList resource, it is very
possible that it is non-ICCCM compliant. With
respect to "-xrm" style settings, this means that the
application does not write its command line to the
WM_COMMAND property.
The best method for getting the -xrm options to work in
a program is to use the Intrinsic function XtAppInitialize()
to initialize the display and create a top-level shell. If,
on the other hand, the programmer breaks out XtAppInitialize()
into its component parts:
- XtToolkitInitialize()
- XtCreateApplicationContext()
- XtAppSetFallbackResources()
- XtOpenDisplay()
- XtDisplayInitialize()
- XtAppCreateShell()
the individual will find that XtOpenDisplay() has parsed the
command line that was passed into it, removing the -xrm options.
Thus to get "-xrm" to work with any program for which
the source code is available, simply use the function call
XtAppInitialize() to initialize the toplevel shell, and
then verify that the "-xrm workspaceList: ws0" option works.
Alternatively, the developer can use XtOpenDisplay() but has
to be careful to save all of the command line arguments.
--------------------------------
Jim Richardson
Manager Technical Support
TriTeal Corporation E-mail: j...@triteal.com
2011 Palomar Airport Rd. Tel: (619) 930-2077
Suite 200 Fax: (619) 930-2081
Carlsbad, CA 92009-1432 "http://www.triteal.com"
--------------------------------
Michael Salmon
Jim Arnott wrote:
>
> >Try using:
>
> >wish -xrm "Dtwm*WorkspaceList: ws1"
>
> >--
> >Later Les...
>
> Nope, does not work.
>
> wish -xrm "Dtwm*workspaceList: Two"
> wish -xrm "*workspaceList: Two"
>
> Will not work either. :(
>
> It seems that with does not pass the -xrm to X ???
I can confirm this, the above -xrm works with xterm but not wish.
You can see the effect of the above using xprop, the
_DT_WORKSPACE_PRESENCE property is a list of the workspaces occupied.
--
© 1995,1996 Michael Salmon
All opinions expressed in this article remain the property of
Michael Salmon. Permission is hereby granted for use in
followup articles, FAQ's and digests.
Jim Arnott
Jim Richardson said ...
> the individual will find that XtOpenDisplay() has parsed the
> command line that was passed into it, removing the -xrm options.
>
> Thus to get "-xrm" to work with any program for which
> the source code is available, simply use the function call
> XtAppInitialize() to initialize the toplevel shell, and
> then verify that the "-xrm workspaceList: ws0" option works.
>
> Alternatively, the developer can use XtOpenDisplay() but has
> to be careful to save all of the command line arguments.
Well, I guess part of the problem is that Tk is an Xlib application.
It uses XOpenDisplay not XtOpenDisplay.
Anyone know how to do this with Xlib ?
Mike Stroyan
Jim Arnott (jar...@bridge.com) wrote:
|Well, I guess part of the problem is that Tk is an Xlib application.
|It uses XOpenDisplay not XtOpenDisplay.
|Anyone know how to do this with Xlib ?
Use XSetCommand() or use XSetWMProperties() for setting both WM_COMMAND
and other important properties.
--
Mike Stroyan, mike_s...@fc.hp.com
Larry W. Virden
Tk uses nothing in Xt, so an alternative to those functions is used.
See tkAtom.c for the details.
Jim Richardson <j...@triteal.com> wrote:
The best method for getting the -xrm options to work in
a program is to use the Intrinsic function XtAppInitialize()
--
:s Larry W. Virden INET: lvi...@cas.org
:s <URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
:s Unless explicitly stated to the contrary, nothing in this posting should
:s be construed as representing my employer's opinions.
Donal K. Fellows
In article <51ug7h$l...@news.bridge.com>, Jim Arnott <jar...@bridge.com> wrote:
> Well, I guess part of the problem is that Tk is an Xlib application.
> It uses XOpenDisplay not XtOpenDisplay.
>
> Anyone know how to do this with Xlib ?
(Untested, in C)
void
SetWorkspace(tkwin,interp,whatWorkspace)
Tk_Window tkwin;
Tcl_Interp *interp;
char *whatWorkspace;
{
char s[1000]; /* Should be enough for most apps... */
strcpy(s,Tk_Name(Tk_MainWindow(interp)));
strcat(s,Tk_PathName(tkwin));
strcat(s,"*workspaceList: ");
strcat(s,whatWorkspace);
XChangeProperty(Tk_Display(tkwin),
RootWindow(Tk_Display(tkwin),0),
XA_RESOURCE_MANAGER, XA_STRING, 8,
PropModeAppend, s, strlen(s));
}
Make sure you call this routine before the toplevel gets mapped...
Donal.
--
Donal K. Fellows http://r8h.cs.man.ac.uk:8000/ (SAY NO TO COMMERCIAL SPAMS!)
(work) fell...@cs.man.ac.uk Dept. Comp. Sci, Univ. Manchester, U.K.
| do...@ugglan.demon.co.uk 6,Randall Place, Heaton, Bradford, U.K. (home)
+-> ++44-161-275-6137 Send correspondence to my office ++44-1274-401017 <-+
Scott Raney
Jim Richardson wrote:
>
> With ICCCM compliant X applications, the "workspaceList"
> directive can be successfully specified by means of the
> '-xrm'(ie, 'X resource manager') argument, as follows:
>
> My_X_App -xrm '*workspaceList: all'
>
> This example would invoke the application "My_X_App" to
> display in all present(Or FUTURE) workspaces.
>
> If the user finds any application which does NOT
> RESPOND to the workspaceList resource, it is very
> possible that it is non-ICCCM compliant. With
> respect to "-xrm" style settings, this means that the
> application does not write its command line to the
> WM_COMMAND property.
>
>
> a program is to use the Intrinsic function XtAppInitialize()
> on the other hand, the programmer breaks out XtAppInitialize()
> into its component parts:
>
> - XtToolkitInitialize()
> - XtCreateApplicationContext()
> - XtAppSetFallbackResources()
> - XtOpenDisplay()
> - XtDisplayInitialize()
> - XtAppCreateShell()
>
> command line that was passed into it, removing the -xrm options.
>
> Thus to get "-xrm" to work with any program for which
> the source code is available, simply use the function call
> XtAppInitialize() to initialize the toplevel shell, and
> then verify that the "-xrm workspaceList: ws0" option works.
>
> Alternatively, the developer can use XtOpenDisplay() but has
> to be careful to save all of the command line arguments.
What if the application was developed without using Xt? As far as I
know, ICCCM compliance requires neither use of Xt nor the X resource
manager. And certainly an application can be ICCCM compliant without
the ability to handle CDE-specific command-line options (not that
ICCCM compliance is actually worth much: thanks to the misguided
"mechanism not policy" philosophy of the X Consortium, you still can't
even reliably use cut/copy/paste between applications built with
different toolkits).
While we're on the subject, are the *actual* property names and
contents required to interoperate with CDE systems documented
anywhere? And to your knowledge is there any documentation on OSF's
proprietary drag and drop protocol that would allow interoperability
with CDE applications using D&D without requiring licensing OSF code?
Awaiting enlightenment,
Scott
> --------------------------------
> Jim Richardson
> Manager Technical Support
> TriTeal Corporation E-mail: j...@triteal.com
> 2011 Palomar Airport Rd. Tel: (619) 930-2077
> Suite 200 Fax: (619) 930-2081
> Carlsbad, CA 92009-1432 "http://www.triteal.com"
> --------------------------------
--
***************************************************************
Scott Raney ra...@metacard.com http://www.metacard.com
Tcl and ksh: syntactic gymnastics
MetaCard: it does what you think
Mike Stroyan
Donal K. Fellows (fell...@cs.man.ac.uk) wrote:
|In article <51ug7h$l...@news.bridge.com>, Jim Arnott <jar...@bridge.com> wrote:
|> Well, I guess part of the problem is that Tk is an Xlib application.
|> It uses XOpenDisplay not XtOpenDisplay.
|>
|> Anyone know how to do this with Xlib ?
|(Untested, in C)
| void
| SetWorkspace(tkwin,interp,whatWorkspace)
| Tk_Window tkwin;
| Tcl_Interp *interp;
| char *whatWorkspace;
| {
| char s[1000]; /* Should be enough for most apps... */
| strcpy(s,Tk_Name(Tk_MainWindow(interp)));
| strcat(s,Tk_PathName(tkwin));
| strcat(s,"*workspaceList: ");
| strcat(s,whatWorkspace);
| XChangeProperty(Tk_Display(tkwin),
| RootWindow(Tk_Display(tkwin),0),
| XA_RESOURCE_MANAGER, XA_STRING, 8,
| PropModeAppend, s, strlen(s));
| }
Ouch. You should just set the WM_COMMAND property on the
application's toplevel window. It seems very unlikely that the window
manager will reparse the XA_RESOURCE_MANAGER property every time it is
changed. Even if this did work, it would be growing the size of
XA_RESOURCE_MANAGER each time the application was run.
--
Mike Stroyan, mike_s...@fc.hp.com
Jim Arnott
Found that this seems to work for one workspace...
Thanks for all the hints !!
-jim
void
SetWorkspace(tkwin,interp,whatWorkspace)
Tk_Window tkwin;
Tcl_Interp *interp;
char *whatWorkspace;
{
Atom wsAtom[20];
Atom XWS_dthints_atom;
Atom XWS_dtpresence_atom;
XWS_dthints_atom = Tk_InternAtom( tkwin, "_DT_WORKSPACE_HINTS");
XWS_dtpresence_atom = Tk_InternAtom( tkwin, "_DT_WORKSPACE_PRESENCE");
wsAtom[0] = Tk_InternAtom(tkwin, whatWorkspace)
XChangeProperty(Tk_Display(tkwin), Tk_WindowId(tkwin),
XWS_vuehints_atom, XWS_vuehints_atom, 32,
PropModeReplace,(unsigned char *)wsAtom , 1);
XChangeProperty(Tk_Display(tkwin), Tk_WindowId(tkwin),
XWS_vuepresence_atom, XWS_vuepresence_atom, 32,
PropModeReplace,(unsigned char *)wsAtom , 1);
}
Donal K. Fellows
In article <52a2lo$v...@fcnews.fc.hp.com>,
Mike Stroyan <str...@fc.hp.com> wrote:
> Donal K. Fellows (fell...@cs.man.ac.uk) wrote:
>> Jim Arnott <jar...@bridge.com> wrote:
>>> Well, I guess part of the problem is that Tk is an Xlib application.
>>> It uses XOpenDisplay not XtOpenDisplay.
>>>
>>> Anyone know how to do this with Xlib ?
>
>
> Ouch. You should just set the WM_COMMAND property on the
> application's toplevel window. It seems very unlikely that the
> window manager will reparse the XA_RESOURCE_MANAGER property every
> time it is changed. Even if this did work, it would be growing the
> size of XA_RESOURCE_MANAGER each time the application was run.
Is that (WM_COMMAND) what the CDE and Xt use? This is not well
documented (from my POV at least) and I would have thought that
reading the properties themselves would be more likely (and more
reliable). My documentation on WM_COMMAND indicates that it is used by
session managers and should contain the command line required to
restart the program in its current state. That particular resource
could have been set in many other places and is as such not always
going to be reflected in the WM_COMMAND property (I would hope this is
the case at least... :^)
On another point, it is easy to check within Tk for the existance of a
particular property; why add checking in C where it is not all that
easy to do when I can let the user of the code do it instead?
Mike Stroyan
Donal K. Fellows (fell...@cs.man.ac.uk) wrote:
|Is that (WM_COMMAND) what the CDE and Xt use? This is not well
|documented (from my POV at least) and I would have thought that
|reading the properties themselves would be more likely (and more
|reliable). My documentation on WM_COMMAND indicates that it is used by
|session managers and should contain the command line required to
|restart the program in its current state. That particular resource
|could have been set in many other places and is as such not always
|going to be reflected in the WM_COMMAND property (I would hope this is
|the case at least... :^)
Setting the WM_COMMAND property is how to make the "-xrm" hack work.
Setting it is also good because it is required by ICCCM to provide basic
support for session managers. The best CDE specific way for a program
to control the workspaces is to use these functions from CDE's libDtSvc-
Dt/Wsm.h(5) - workspace manager definitions
DtWsmAddCurrentWorkspaceCallback(3) - add a callback to be called when the
current workspace changes
DtWsmAddWorkspaceFunctions(3) - add workspace functions for a window
DtWsmAddWorkspaceModifiedCallback(3) - add a callback to be called when any
workspace is changed
DtWsmFreeWorkspaceInfo(3) - free workspace information
DtWsmGetCurrentBackdropWindow(3) - get the backdrop window for the current
workspace
DtWsmGetCurrentWorkspace(3) - get the current workspace
DtWsmGetWorkspaceInfo(3) - get detailed workspace information
DtWsmGetWorkspaceList(3) - get the names of the currently defined workspaces
DtWsmGetWorkspacesOccupied(3) - get the workspaces in which a window resides
DtWsmOccupyAllWorkspaces(3) - put a window into all workspaces
DtWsmRemoveWorkspaceCallback(3) - remove a workspace callback
DtWsmRemoveWorkspaceFunctions(3) - remove a window's workspace functions
DtWsmSetCurrentWorkspace(3) - set the current workspace
DtWsmSetWorkspacesOccupied(3) - set the workspaces in which a window resides
--
Mike Stroyan, mike_s...@fc.hp.com