Conference bulova::decw_jan-89_to_nov-90

    I have been searching for the magic commands 
    to restore my previous environment

    *Session Manager.iconName:                      SM
    *Session Manager.title:                         SM
    *PauseDialog.PauseLabel.label:                  .
    *PauseDialog.PasswordLabel.label:               ?
    *PauseDialog.ScdPasswordLabel.label:            ??

    The best I have found are notes 16.5 and 1496.6.
    But since these notes imply a change in behavior so drastic 
    that the user can not recover, I find them hard to believe.
    What are the new names and where should they go this time?

    thanks,
            mike

    Hmmmm. BlinkRate: 0 seems ignored too.
    
    However, V5.3 is, on balance, faster than previous versions on my 14mb
    VS2000 GPX. Tried deleting 90% of your MODPARAMS.DAT and Autogenning?

	re .2

	Ive tried an autogen already, Other people in the group are also
	moaning about some response times (Mail seems especially slow).

	Could it be because its a field test version ??

	re .1,

	the 16.* series points to a decw$session.dat file. Ive never heard
	(or seen) that mentioned or used. 1496 must be the wrong note, its
	not applicable to .dat files.

	None of which helps in 5.3 by the way....

	jim	

> (Mail seems especially slow)

	What's slow about it? Our experience is the same as Andy - it
	should be noticably faster (we're still on T5.3-426).

	Mike

    I have a question about a resource for the login window.
    
    When your workstation is at the DEC logo display, the box below the
    logo that prompts for username and password says "Start Session". 
    Anyone know which file and what resource needs to be changed so that
    the line can say "Unauthorized access prohibited"?
    
    Thanks,
    Mike

    You can find all this stuff in DECW$SYSTEM_DEFAULTS:DECW$LOGIN.DAT
    
    			Dung HOANG
    			TSC EVRY FRANCE

	Whats the realtivity between fast and slow ? Mail is an example
	of slow on 5.3 only because it seems slow compared to what i
	remember it being on 5.1

	When clicking on read new mail, say 2-3 new mails in inbox,
	no read window present it can take anything from 3-10+ seconds,
	no other processes grabbing cpu, mail cpu is about 85-95%
	(according to banner) To me the low end is ok, the high end
	is slow.

	This is t5.3 -462 on a 14mbyte ws 2000

	jim

	If you've only got a couple of mail messages in your deliver
	folder, and the new message is not huge, it shouldn't take
	that long to bring up the read window even if it's the first
	time you're reading (i.e., the window is being created). I
	get better performance than that on a 9-meg GPX with several
	other applications run locally. Combined with the other things
	you've mentioned, my conclusion is that your workstation is
	mis-tuned - as .2 said, clean out MODPARAMS.DAT and go through
	a couple iterations of AUTOGEN with feedback (give it a couple
	days between AUTOGENs so it has something to base changes on.

	You mentioned running Banner - Keep an eye on the page faults
	and free pages, those may give you a clue to where the problem
	is.

	Mike

	the page file thing may be the problem with slowness, i notice via
	banner that the page file & page fault lines go high (100% and 50%
	respectivly) on window creates (mail & notes). BUT, as i dont know
	exactly how to control these, any ideas ?

	by the way the modparams file is small, see below, but autogen with
	 feedback doesnt change much...

	modparams = 

EXPECTED_VOTES=1
RECNXINTERVAL=20
DISK_QUORUM="                "
QDSKVOTES=1
QDSKINTERVAL=10
ALLOCLASS=0
LOCKDIRWT=0
NISCS_CONV_BOOT=0
NISCS_LOAD_PEA0=1
NISCS_PORT_SERV=0
MSCP_LOAD=0
MSCP_SERVE_ALL=0
WINDOW_SYSTEM=1
NISCS_LOAD_PEA0=1
VAXCLUSTER=2
VOTES=0
PAGEFILE=0
SWAPFILE=0
INTERCONNECT="NI"

	regards
	jim

    RE: .0:
    >	How do you get the following 5.1 commands to work in 5.3:
    >
    >	*Session Manager.iconName:      On, Off, etc...
    
    I asked the same question (among others) in 1469.0, and didn't get any
    more of an answer than you have. I can only conclude that "they changed
    their minds"...
    

> I asked the same question (among others) in 1469.0, and didn't get any
>    more of an answer than you have. I can only conclude that "they changed
>    their minds"...
    

	I cant beleive that, surely someone clever eneough to create
	decw must have left a loophole in there so he/she can change
	their own environment to something better than the default.All
	he/she has to do now is spread the word

	by the way, i now agree with .1 that 1469.6 (and not 1496) is useful,
	but there must be a better way.....

	jim

	if you add make the folowing change to the code shown in 1469.6
	the you can set the sm title as well as the icon...

		ie sm :== $code...

		   sm icon_name title


    if ( smWindow )
    {
        XSetIconName( theDisplay, smWindow, argv[1] );
  
        if (argc > 2)
        {
                XStoreName (theDisplay, smWindow, argv[2]);
        }
    }
  
	Looking at the origonal code, it should be possible to get to
	 any window in this way ?

	regards
	jim

	well i think i now can manipulate any icon & window title 
	field using the resource name & class.

	These resource names can be obtained from tweaked treewalk
	 type examples and by feeding them into the previous demo 
	as parameters which replace the parts hardcoded for the screen 
	manager	you can change what you want...in 5.3 at least.

	if you use the following...

$ change :== $changes
$ change CMS CMS$DW_DEFAULTS "cms" "library"
$ change "tpu" "Tpu" "lse" "edit this"
$ change MAIN_SHELL NOTES$DEFAULTS notes notes
$ change "READ_SHELL" "NOTES$DEFAULTS" "notes read" "read and enjoy"
$ change "CONF_SHELL" "NOTES$DEFAULTS" "notes dir" "directory"
$ change "MAIN_WORK_BOX_shell" "NOTES$DEFAULTS" "wip" "wip"
$ change "Mail" "DECW$MAIL" "post" "post office"
$ change "MailSend" "DECW$MAIL" "post this" "post this"
$ change "MailRead" "DECW$MAIL" "post read" "post read"
$ change "EDIT_SHELL" "NOTES$DEFAULTS" "makeanote" "makeanote"
[EOB]
	if anyone wants the source, let me know and i'll post it.

	the only one that doesnt work well is the mail, since 5.3 resends
	the old one on reciept of newmail.

	regards
	jim

    
    In V2, session manager text can no longer be changed in a resource
    file.   In order to support the international market, all applications
    had to move text from resource files into UIL files.   The UIL files
    are then translated.   Putting a resource in UIL means that it cannot
    be overwritten by a resource in a .dat file.   Don't shoot the
    messenger, please.  I hear this may change in future releases.
    
    The pause text can be changed by using the Customize Session menu from
    the Session Manager.   
    

Re: .14

Who propagated that nonsense? Not you I hope. Strings in app-defaults and
defaults.dat are just as internationalizable as in a UIL file. All it takes
is changing the type of the resource (in the application), providing the
appropriate type converter (string --> CompoundString), and publishing the
string representation of CompoundStrings.

There may be valid reasons to put all labels into the UIL files, but
internationalization isn't one of them. The additional implication that .dat
files aren't i18nable is simply wrong.

Using a bogus technical excuse to justify a decision based on politics or
expediency is contemptible. Who is this "message" from, so I can shoot at them
and not the messenger?

	-- Charles (designer of the Xdefaults mechanism and XRM)

Charles,

I couldn't agree with you more.  I was not happy about spending 3 months of
my life converting FileView from XDefaults to UIL, but we grunts were given
absolutely no choice.

When I pushed the issue, the reason I was told for why we had to go to UIL
rather than providing instructions on how to "internationalize" the .DAT
files was that the internationalization "group" (the people doing the
translations) only had time to learn one mechanism, and that mechanism
was going to be UIL - not XDefaults language.  "So do it and stop whining."

Alas, another elegant, flexible, and portable solution bits the dust.
And the rhetoric continues.

JMO

-steve-

Given what you say....

   Would it be possible to get access to the UIL source associated with certain 
applications like the sesssion manager and the terminal. As I see it, the reason
why most people want to access XDEFAULT files/ know what resource names are 
available, is that they wish to configure their environment to suit their own
tastes. This is because they are dissatisfied in some way with the current 
environment being offered to them.


Is providing these UIL files totally out of the question??


� j.

I'm sure its "possible" (see other discussions of XUI source) but painful.
As far as I can tell the long term strategy revolves around run-time
customization of applications and tools for customizing what can't be done
at run-time.  We seems to have gotten out of synch and switch our implementation
to match a future customization capability that isn't available yet and in
the process took away what customization capabilities were there.

Dick
getting the cart before the horse can be hard to avoid (esp. on ice  8^{)

Mini-flame:

Personally, I agree with the .-*s that bemoan the systematic genecide of 
the xdefaults mechanism.  I believe that it is another example of management
types exhibiting a bad case of ``customization phobia''.  You know the type;
the ones who say ``What if everyone did it?  No, we don't want to coufuse
people.  Will give 'em one way of doing things, and if they don't like it, 
tough!''

Actual question:

I am interested in the apparently authoratative source's (I think .-2) method
of I18n-ing resource names.  How can they be translated without modifying
the source code?  I didn't exactly understand his prior explaination...

> I am interested in the apparently authoratative source's (I think .-2) method
> of I18n-ing resource names.  How can they be translated without modifying
> the source code?  

If you were talking about my reply (.15 = .-4) then you misunderstood slightly.
Resource VALUES are easily internationalized. Internationalizing Resource NAMES
(or CLASSES) would harder, not technically, but because the code is quite
solidly frozen. Making resource names and classes compound strings should
actually be pretty straightforward... I bet we could even preserve compatibility
with existing .dat files... hmmm... Anyway, every resource value that appears in
your .dat file is read in as type "String". The resource manager knows what
type of resource the widget really wants, from the resource list. If there is
a resource type converter from "String" to the desired type, the resource
manager converts the resource and returns the converted value. There are
built in (actually pre-registered) converters for string to many types including
integer, color, font, and so on. It would be straightforward to add a
converter from "String" to "Compound String" that would allow you to put
compound strings into a defaults.dat file (in fact I bet you could steal
whatever UIL uses for the same purpose).

Note that we didn't have to make all resources of type "String" when read in,
that is just an artifact of the fact that we wanted .dat files to be text and
have a simple format. There were plans to make a binary represenation of
defaults files that would keep type information associated with the stored
value, allowing a much richer set of possibilities for resource representation
and editing. There is nothing conceptually to prevent type converters from, say
"Color" to "Pixel" (in fact that one exists) or "DDIF" to "Pixmap" say if you
wanted to get really fancy. It is even possible to make converters from things
like "String" to "Widget" if you want to get REALLY fancy. I really wish
someone would take this ball and run with it...

> I didn't exactly understand his prior explaination...

I hear that this is a chronic problem with my "explanations"... :-) keep asking!

	-- Charles

> I really wish someone would take this ball and run with it...

I do too.  Does UIL solve this problem?  I am sure that it is annoying
to a Frenchman to have to diddle his Xdefaults file in english, just as
it would annoy me to have to diddle mine in French to please a French
written application.