Conference bulova::decw_jan-89_to_nov-90

In general, applications have a "geometry" resource which goes "=WxH+X+Y".
If you put the following line in SYS$LOGIN:DECW$XDEFAULTS.DAT:

wm*geometry:                            =90x580-0-0

you will get an icon box shoved on the bottom right hand side of your
screen. You can, of course, play with these numbers for better results.

    This one pushes it on the very right side of you screen for the whole
    length (and beyond, I don't like horizontal scroll bars ;)
    
wm*geometry:                    =150x1030+903+1
    
    I don't use the +0+0 feature of the geometry to make it flush with the
    top right corner because I actually want it a little bit beyond. 
    Namely, I don't care to even see the re-size button on the title bar.
    However, it is handy to know about:
    
    -0+0	Top Left Corner
    +0+0	Top Right Corner
    +0-0	Bottom Right Corner
    -0-0	Bottom Left Corner
    
    I think I've got that right :)
    
    I also prefer the icon box to be sticky, such that it stays behind or
    on top unless I specifically push the "push-back" button on the title
    bar.  You do this by:
    
wm*sticky:                      True
    
    Regards,
    
    	 	== ken miller ==
    

    Is there any way to force an ICON to a certain position in
    the icon box *VIA* the defaults file.
    
    Context:
    
    The icon for FileView changes size as I move around my
    various views.  I have my icon box set up for two rows
    of large icons.  I would like to force the icon for
    FileView to always be at a certain position in the second
    row.
    
    Thanks in advance for any thoughts on this,
    Tony
    

!
! These are some goodies from DECW$XDEFAULTS.DAT
!
wm*sm.iconStyle:		1
sm.initialState:		3
sm.iconBoxX:			0
sm.iconBoxY:			0
!
wm*DECW$MAIL.iconStyle:		1
DECW$MAIL.initialState:		3
DECW$MAIL.iconBoxX:		3
DECW$MAIL.iconBoxY:		0
!
wm*iconBox.background:		Black
wm*iconBox*background:		Yellow
wm*iconBox*foreground:		Red
wm*iconBox*borderColor:		SkyBlue
wm*iconBox*title:		Gvriel
wm*iconBox*sticky:		true
wm*geometry:		=100x250+0+0

To refresh my memory, could you list the meanings of the "initialstate"
property values?

	paul

    re: .3,.4
    
    Perhaps it is worth mentioning that I'm running 
    on a Vaxstation II/GPX running Ultrix 3.0 with
    UWS 2.0.
    
    In the .Xdefaults file that resides in my home
    directory (on my workstation) I have the following
    lines (among various others).
    

    wm*iconBox*sticky: true
    wm*iconBox*title: Blitos Bullpen
    #
    # FileView Resources
    #
    *FileView.iconBoxX: 443
    *FileView.iconBoxY: 72
    
    On restarting the session it ignored all of these settings.
    
    The little pushdown control in the iconbox for the wm
    did not have the gray highlight that I can obtain via clicking
    a shifted MB1 on it.  The Icon box still had the title
    of Icon Box.
    
    FileView (which I start back on a VMS cluster (via various magic)
    and display on my workstation) just comes up in the first available
    space in the icon box.  The X, Y coordinates that I used for the
    FileView were obtained via a MOUSE_TRAK.exe with the cursor being
    at the upper left corner of the icon for FileView.
    
    If anyone has any more thoughts at to how this can be
    made to work (or what I did wrong) please let me know
    with a reply to this note.
    
    Thanks in advance,
    Tony

Here is a bit of my .Xdefaults file. I normally have my window manger window
about a 1/2 screen wide and 4 (small) icons high. My mail icons are big.

  dxmail*iconBoxY:	2
  dxmail*main.iconBoxX:	0
  dxmail*read.iconBoxX:	2
  dxmail*pick.iconBoxX:	6
  dxmail*pick.iconBoxX:	4
  Calendar*iconBoxY:	2
  Calendar*iconBoxX:	10
  wm*iconStyle:		1
  wm*dxmail.iconStyle:	0
  wm*Calendar.iconStyle:	0

I am running Ultrix and the VMS mail application has somewhat different
widget names, so your mileage may vary.

PK

re .6:

Not sure why your "sticky" line isn't working but the iconBox*title
and FileView resources simply aren't being set by their respective
applications.  As far as I know, you're outta luck.

For "sticky", try "wm*sticky: True"

Regards,

                 == ken miller ==

>>    *FileView.iconBoxX: 443
>>    *FileView.iconBoxY: 72

Aren't the resources called "iconX" and "iconY"?

-steve-

    
    re: .9
    
    So, is there a particular document that lists all the resource names
    and corresponding values/descriptions that can be used as a reference?
    Does each application document its own resources, and if so, where
    (which manual - programmer's guide, user's guide, etc.) will we find 
    this valuable information?  If it's not documented, will we find
    the data by reading various notesfiles?
    
    Mike_who_likes_to_customize_everything

>>    So, is there a particular document that lists all the resource names
>>    and corresponding values/descriptions that can be used as a reference?

The "document" I used was SHELL.C in the DWT sources.  Sorry 'bout that.
On VMS, applications do not "support" customization through user-defined
resource files.  This means that on VMS, application resources will probably
not be documented (for some time, at least).  Access to the sources is
the only way I've been able to get this information.

You can probably get a pretty good idea of what resources exist by searching
the .H files for resource names (usually XtN... or DwtN...).  The toolkit
documentation may help out, too, but this would be for the common widgets, not
whole applications.  Certainly, there are additional resources for the
applications themselves, and you can only guess at the widget hierarchy
by looking at the application's SYS$LIBRARY:*.DAT file.

Remember that the long-term "goal" (?) of converting everything to UIL will
"break" your customization via .DAT files!  This is one "good" reason why
we don't "support" this type of customization.

I'm not taking sides - I just try to live with (and work around) the
way things are.

-steve-

	re .9: iconBoxX and iconBoxY exist and are interpreted as units
	equal to a legal icon position (i.e., iconBoxX: 2 puts the icon at
	the third possible position across). I believe iconX and iconY
	are interpreted as pixels.

	Mike

Well, the actual fact is that I overlooked the iconBoxX and iconBoxY resources
when writing the shell widget for FileView.  Another item for the worklist.
Thanks.

For now, you'll have to settle for iconX and iconY when it comes to FileView.

:(

-steve-

    Where's the documentation for DECW$XDEFAULT.DAT?
    
    Steve

>>    Where's the documentation for DECW$XDEFAULT.DAT?

You realize, don't you, that user-munging of the .DAT files for the
VMS-supplied DECwindows applications isn't supported?  Information
about resources, etc, is only supplied informally and is likely to
change in any future release.

We've been around this point many times in these notes files.  I don't
know if it is a good idea or a bad one, but I don't think you'll find
any documentation about the format of .DAT files in the VMS DECwindows
doc set.

-steve-

On the other hand, I have been told that the Ultrix documentation does
describe the resources for the ootb applications.  Some of these will
be identical to the VMS ones.  I suspect that the window manager is
among these.

Dick

    I have finally gotten enough things going at once that I can't fit my
    icons on one row of the default horizontal box. So I started tryng to
    adjust the size of the box to allow two rows without using unnecessary
    screen real estate. "What's necessary" is the issue.
    
    First, using mouse resize: the icon box expands by fixed increments?
    Can this be turned off or adjusted? The next increment up seems
    unnecessarily big. 
    
    Second, using wm*geometry: the figures I give are rounded up to the
    same size increments that mouse resize allows me. Again, it seems
    wasteful.
    
    But perhaps not. I find if I let the box be as big as it wants to be,
    and it looks like it could almost hold three rows of (small) icons, I
    bump into the mechanism that insists icons must be so far apart.
    Can this be turned off or adjusted? It seems to insist on more than
    half the height of an icon worth of space being left between the rows.
    
    Any other good ideas about icon box management, besides making the box
    vertical? 
    

    re: 21.11
    >Remember that the long-term "goal" (?) of converting everything to
    >UIL will "break" your customization via .DAT files!  This is one
    >"good" reason why we don't "support" this type of customization.
    
    I'm confused by this statement.  As far as I understand DRM isn't
    intended to replace XRM, but supplement it.  Doesn't that mean that the
    resource names will still be accessable through .DAT files?  (Granted,
    the names are liable to change over time...)
    
    Dan
    

>>    I'm confused by this statement.  As far as I understand DRM isn't
>>    intended to replace XRM, but supplement it.  Doesn't that mean that the
>>    resource names will still be accessable through .DAT files?  (Granted,
>>    the names are liable to change over time...)

Any resources that are specified in the UIL file cannot be overridden at
runtime by a .DAT file.

This implies to me that DRM does not "supplement" XRM, but
"supplants" it.  They can coexist only where DRM does not specify
ANY value for a particular resource, and then, a .DAT file is REQUIRED
to specify the resource (unless you're willing to settle for the
widget's built-it defaults).

This seems bad to me, but what choice do we have at this point?
Some products are shipping both .UID files and .DAT files, with
run-time (read "user") customizable resources specified only
in the .DAT file.  This isn't very good either, especially if
a user wants to customize something other than what the application
developer had in mind.

-steve-

Here's some wisdom imparted on me when I was just a DECwindows tadpole by
the developers, and amplified by myself

UIL defines the structure (everyone else seems to call this a
hierarchy) and the instance names of some of the widget instances.

The application invokes and extends the structure and instaniates (and names)
more widget instances

The toolkit provides the widget class and their names, the widget resources
and their names.

HOW DO RESOURCES GET VALUES?

The ASCII ".DAT" resources files have lowest priority
The UID resource files override them
The application can override anything.

Public widgets have public resource names like "background" and "highlight"

The Application programmer decides what resource values are required to get
program to basically run and typically they are in the UIL like the text of
a label or the attachments in an attached dialog box.

The values that can be set for customization are exported to a ".DAT" resource
file, and are bound to the widget instance name.

The science of what goes into "UIL" and what goes into "DAT" awaits further
research

HERE COME THE PROBLEMS

The qualified widget instance names are undocumented and internal to the
program.  They may be changed without notice between versions

The resources that may be customized, could be customized in a way by a user
that breaks the application's appearance or behavior in a major way: for a
widget instance there are no access rights, for example, to "foreground" but
not to "font".  To know a widget instance name (and it's class) is all the
license one needs to change its resource values

Not all widget instance names are exposed in .DAT files, so the customization
potential is incomplete.  (Say what? You can always disassemble the binaries)

Finally, the application thinks it owns those .DAT files and not the user's
text editor.

Since the application has the "final say", why not provide a
DRM$GET_USER_DEFAULTS() call to read a .DAT file and XSetValues what's in it.

John

>Since the application has the "final say", why not provide a
>DRM$GET_USER_DEFAULTS() call to read a .DAT file and XSetValues what's in it.

In theory an application could do this by re-reading the defaults files 
the appropriate XRM routines.  However, in practice, most applications rely
on the intrinsics to get their XRM resources and ignore the fact that they
may get overridden by DRM.

As Pat pointed out, you should really try to avoid setting resources
in the DRM that are not critical to the workings of the user interface.

Dick

    Hi,
    
    I'm not sure if I've missed something that everyone knows but me...
    
    I'm running Decwindows under VMS v5.4 and I can't seem to find this
    file called decw$login.dat.
    
    If it's on my disk somewhere, where is it, and how can I edit a system
    file when i can't do that with other system files ??
    
    Perhaps you've noticed that I'm quite numb when it comes to
    VMS/Decwindows, but plase help me !!! 
    
    

    Thanks, but I found out that in v5.4 the only thing you have to do is
    use the customize pulldown menu in the icon box and then save it.
    (I think...)
    But thanks anyway.
    
    "The new one" Niklas

    O.k., I'll bite, can someone tell me what I'm doing wrong then please.
    
    I'm trying to change the initial startup shape and postioning of my
    icon box, and it's name as well.
    
    I've put 
    
    wm*geometry:		=90x580-0-0
    wm*iconBox*title:		Fred
    
    in sys$login:decw$xdefaults.dat AND decw$system_defaults:decw$login.dat
    but still the little tinker refuses to change for me. I'm running VMS
    5.3-2 if this makes any difference.
    
    Gissa clue,
    
    Thanks in advance,
    
    
    Steve