Conference bulova::decw_jan-89_to_nov-90

    right on..I happen to have a very bad astigmatism, easily corrected by 
    glasses coupled with hyperhopia (I can see far very well- usefull for
    reading signs on freeways). I also read a lot & my optometrist tells me
    my eyes are muscle bound.
    
    the loong & the short of this is that I'm verysensitive to font shape
    and size (not too big, not too samle) and the glare generated by the
    screen (white window background is a no-no).. Adjustemtn is a must for
    me !!
    
    md

    Before this note degenerates into a why-Xdefaults-is-an-ugly-thing-to-
    give-to-customers (as I'm sure it will :-), let me say this much:
    
    Jim, your note seems to be directed at devos.  However, I don't think
    you'll find most devos think as you assume.  In fact, I suspect that
    it's the devos that customize their environments the most.
    
    You say "generally small amount of additional work required to be a
    good citizen", well, it isn't always a small amount of additional work
    -- esp. if you consider the "more extensive testing, deal with layout
    in more intellegent ways, etc." -- but leaving that point aside, what
    does being a "good citizen" mean?
    
    Am I a "good citizen" if I "sneak in" capabilities that aren't in the
    project plan?  If the schedule is tight (as it was through all of DW V1
    and V2), how do I tell my manager (and DW project leaders) that I feel
    it's right to spend time on, what they deem, non-required features.
    
    Furthermore, would I be a "good citizen" if I used what are deemed to
    be "unsupported" features to provide these "unrequested" capabilities?
    
    Most DW devos I know would love to have more customization capability,
    but these devos (a) don't have the time FORMALLY allocated to do the
    work and (b) have been told that the "style" is to offer customization
    (if any) via the app. interface, not Xdefaults.
    
    People did global select, that's a pain;  people handled input focus,
    that can be a real pain too;  people coded double-clicks and drags
    together, a _real_ pain!  they did all this 'cos they were told to (by
    the XUI Style Guide).
    
    I think you are directing your gripe at the wrong place.  It's not the
    devos that are not implementing customization features, it's the corp.
    that is not providing any support/backing for those devos to do so.
    
    Regards,
    
    Marios

I'm happy to complain to anyone.  Yesterday I complained to Jake.  If there
are others that need to be educated, I'd be happy to take them on too....

And who writes the project plans?  If you don't put the time in the plan, then
your managers don't have to take the heat for cutting it out.....  Or plan
to allow you the time in future releases.  They can't make proper time
estimates if you don't give them estimates that cover all the reeal work.

My soapbox speech is a long term issue.  Note I didn't make the speech several
years ago.  I fully appreciate the press of time; X nearly killed me, and
I hope it hasn't killed others.  But we did worry about the issues in the
design.

But we will be doing ourselves and our customers a long term disservice
if we ignore the issue.

Note that a global style file does not help the individual needing 
customization.  I can't edit it in my environment (without disturbing
everyone else), which is not atypical of many customers.
That is what Xdefaults is about, to allow the user to
do what he needs above and beyond the application's default behavior
which needs to be customized for internationalization.

Note that I am a STRONG believer that applications should work well
without customization, and in fact, without even application default
files existing (on environment robustness grounds; you'll get more than
slightly upset if the tool you need to fix a system problem won't work
until the system problem is fixed!).

The real point here is that most of us have normal eyesight, normal
motor control, and use these systems in a normal office environment.

The real world is not as forgiving.  We should all come up for air and
remember all the things we didn't have time to do in the first releases....
					- Jim

    Huzzah! I'm sick of being stuck with fonts I can't read!
    
    	Jon

    
    Writing real software instead of toy software requires a lot more work.
    When you can code up something spiffy and throw it over the wall and
    not worry about supporting the product - it's a piece of cake.  Like it
    or not, when we sell software we must support it and as such there is a
    finite support cost for every bell, whistle and knob.
    
    Now this *isn't* an argument for facist software, and I've been known
    to have written some software that could be customized until you had
    some serious problems (I'm using a nice font on my VWS workstation). 
    Someone using 99% of my software *can* get a full screen window with
    mondo fonts - because it seemed something reasonable for the
    application, and the risk/cost seemed acceptable.
    
    I *do* live in starK terror of accidentally hitting MB3 on my DECwindows
    system.  Heaven only knows what will happen in any given window.  And
    God help me if I'm pressing a KB key at the time.  Somehow I haven't
    found the customization setting that disarms the dangerous parts for
    all applications :-)
    

I don't necessarily claim that Digital can provide formal
support to customers who have customized things in more than trivial ways.

However, for the reasons previously stated, I claim our applications should
be customizable.  This is a different statement, entirely.  I am unwilling
to close off people and/or circumstances out of the ordinary that quickly.


In the specific example I gave of the receptionist with terrible eyesight,
it is pretty clear some things would always be beyond his capability.
But most things I've seen would be, if minimal provisions were made.
And I don't think customers are unrealistic about support in those
circumstances.


As far as MB3 goes, maybe there should be some way required to enable
customization in general.
					- Jim

    <Applause>

    
    Maybe this is the beginning of Marios's predicted Xdefaults rathole. Oh
    well, I'll say it anyway.
    
    I *much* prefer the kind of customisation that DECW$Calendar gives you,
    rather than random Xdefault hackery. I got Calendar looking how I
    wanted in a few minutes - it's taken me *hours* to get the Motif window
    manager looking reasonable on my system, and that was after someone did
    most of the hard work.
    
    Maybe there's a place for Xdefault hackery as a last resort, but I
    think it's a terrible first-line customisation tool.
    
    Trevor

RE: .8

	Here, here!!

	I'm truly dissapointed with the availability of customizations on
	DECwindows applications, specifically for Fonts and such. I'm sitting
	here in front of a VR160 (the 15" color screen) and have a VR290
	on the floor. I'm trying to decide which is better. To be quite 
	honest with you all, DECWINDOWS IS MAKING ME GO BLIND!  I NEVER had
	this problem on VWS thanks to the beautiful Sans Serif fonts that
	Fred provided.  132 column full screen with a decent font on DECwindows?
	Hell no.

	Here's yet another vote for much better fonts for us poor nearsighted
	people who are seriously thinking of charging DEC for their next
	pair of glasses cuz our eyes have been screwed up by DECwindows 
	applications.. >phew, one breath<

	I wish I had the Sony monitor..

								mike

I definitely agree with Marios that the right place to get customizations
is by providing it as a feature of the application.  That said, it is
still wrong to move the specifications of critical resources (colors, fonts
and accelerators most notably) out of Xdefaults before providing a way to
customize them in the applications UI.  Fortunately applications (esp.
Calendar and DECW$MAIL) are making great progress on implementing the
customization interfaces.

Dick

While I generally agree with the need for free customiztion and the existing 
customization provided by most DECwindows applications is not enough, we must
realize that some apsects of the UI are coupled to how the application works.
Thus beyond the postion, size, color and other visual aspects of the application
I believe that it is unreasonable to say everything can be customized using the 
existing X Toolkit. While you may be able to move where the application prompts
for some information and maybe the type of valuator used (text widget vs slider),
you (the end-user) are not able to eliminate the fact that the application
requires that value.

Unfortunately, the X Toolkit doesn't really make it easy for the user to change
a text widget to a slider - the callbacks of the widgets are different, the 
application program is too tightly coupled to the user interface, and unless 
you have access to data stored in the application, making this type of change
is difficult.

The X Toolkit does some work toward separating form and function. It does not 
go far enough. The application must still be tightly involved with interface 
management. It must know that it's dealing with a slider or a button or a text
widget. This is painfully apparent from the problem of "Who's minding the 
mainloop?". Managing multiple displays or constructing a callable (non-widget)
runtime library, like GKS or PHIGS, is very difficult.

Applications should be more distantly separated from the UI. Generally speaking
most applications request information in units meaningful to the application, 
and does not want to do such low level processing as translating keystrokes.
The exchanges between the application and the UI should pass complete values 
across the interface - the low-level processing being done by the UI runtime.

The user interface runtime takes care of all the display management. The 
interface, expressed in a semi-procedral language, controls the actions and 
reactions of the interface. Dynamic appearances like highlight on enter, dialog
box popup and field-to-field navigation can be staticly declared in the 
interface description. If the interface is not adequate, it can be easily
changed to fit the new need. As long as the protocol for exchanging requests
between the application and the user interface is not changed, the UI artifacts
can easily be modified. It is entirely possible to change from a text widget
to a slider or an option menu to a row-column radio box - completely transparent
to the mainline application code. If the user finds the "predefined" flow 
of the application dialog confusing, the order of dialog box visitation can 
be changed - panels can be combined or split to fit the need of the user. 

This model is different from the toolkit model in that object with which the 
application is interacting is the user interface and not the objects which 
are used to construct the interface. We're moving the level of abstraction
further away from the bits that light ups the screen and the keys on the 
keyboard.

The model can be graphicly shown as:


    +-------------+     +---------------+     +-----------+
    | Application |---->|User Interface |---->| Display   |
    | Program     |     | Control System|     | Station   |
    +-------------+     +---------------+     +-----------+
                                ^
                                |
                        +---------------+
                        |User Interface | 
                        | Description   |
                        +---------------+

Once this level of separation is obtained, there are now three things which
must be specified, the application (what must be done, function), the methods
the application uses to interact with the user interface, and the user interface
itself. As long as the methods don't change, the function of the application
and the form of the interface are completely independent! This model provides 
for the customization that I believe customers need - beyond just superficial
changes in appearance and color. 

Customization is a bigger problem than just visual attributes. Customization 
also extends to providing natual support for devices not available when the 
application was first constructed, for instance the DECtalk. I should not be 
forced to do major surgery in the application to support a new device (even one
so different as DECtalk), I should only need to redesign the user interface.

    I don't see that it makes much difference whether customization
    is implemented through menus and dialog boxes (or buttons and 
    dialog boxes - that's one I've never given much thought to) or
    resource specifications in defaults files - as long as it is 
    provided for somehow AND adequetly! 
    
    I still get a major headache from trying to figure out where my
    cursor is on the screen when using UWS! 
    
    Ron

I like the idea of the .Xdefaults file for centralizing the customization 
settings, but I wish there was an application or widget or something better 
than just an ascii editor to maintain the file.  And I wish that applications 
that are responsive to settings in the .Xdefaults file would each provide 
something like a .CLD file which enumerates all the variables and their 
possible values.  Then the application that maintains the .Xdefaults file 
could read all the .CLD-like files and give the user an interface for 
customizing everything in his X Window System environment.  With such a 
facility available, application developers would not need to put so much 
effort into each providing their own customization menus and dialog boxes.

.11 makes some very good points about good application architecture.  It also
misses some points.

1) Most of .11 is orthogonal to the issue of user customization of the
   UI.  It just changes the place where you need to provide customization.
   It does enhance the ability of devos to provide a variety of UI styles
   for a single underlying application.

2) Using the architectural approach in .11 does not preclude or conflict
   with the X Toolkit approach.  The UI part of the application (or at
   least major parts of it) can and should be implemented using a UI
   toolkit of one sort or another where the X Toolkit approach is at
   no particular disadvantage.  The only diffence between that and the
   implementation of many Toolkit based applications is that the path
   of communication between the UI and the underlying application is
   narrowed to a single path.

Most of the above has been discussed at length in the internal CAD
tools arena.  CTC has produced a style guide and other documents for
their Compass framework and Vantage CAD system.  The Senior CAD Managers
Forum launched a task force to research porting our CAD environments to
DECwindows.  That task force made many of the same recommendations
described .11.

Dick

RE: .0

Hear, hear!

I also agree with Marios that application-specific customization through dialog
boxes is preferable to Xdefaults as a way to do customization.  However, most
DECwindows V1 applications don't have customization dialogs, and those that do
exist aren't anywhere near extensive enough.  In such cases, Xdefaults at least
lets me do the customization.  It may not be easy, but it's at least possible.

Worst of all is the tyranny of .UID files.  It was a big, BIG mistake to have
UIL definitions override Xdefaults.  It should be the other way around.

Until we get our act together in the customization department, we should
document the Xdefaults resources for customers to use.  Leave it unsupported if
you have to, but at least give people the information and let THEM decide if
they want to take the risk.

--PSW

  If the UID overrides the Xdefaults, knowing the resource name doesn't
  help me.  These fonts are killing my eyes, and they were getting better!

  Paul has the right word - tyranny.  That's what it feels like from this
  side.  Times have changed, and it's time we changed and put the power
  of computing back into the user's hands!

  Vaughn

Does OSF/Motif understand what our uil/uid is going to do to
customization?  I can understand how our nazis can eliminate it, but
to think that the rest of the world goes along with it is unsettling. 

The hardest customer calls to deal with on VMS X are customization.  
I've already gotten a "worthless" survey rating from one of them 
because I wouldn't tell him exactly how to do it.  If the rest of the 
world has customization and we don't in our "standard" implementation 
then we're going to turn a lot of potential friends and supporters 
into enemies and leave a wide opening for the competition.

Please make resource files override uids and provide a logical to turn 
off the resource files for supportability checking.  Unsupported but 
working is a lot better than unsupported and not working and no way 
out!

Bruce
CSC/CS DW Support

Can anyone answer these:

 1) Is the UIL distributed with DEC applications, or isn't it?

 2) If 1) is no, then how does one modify applications behavior for
    things not modifyable via ``customization'' menus?  (Noteing that
    almost nothing is modifiable via these menus in current software). 

 3) How does UIL ``solve'' the I18N problem in a way that an xdefaults.dat
    file does not?

P.S., I don't want to go down the rathole of WHY someone might want to do
what 2) asks about.  If you don't know why then PLEASE, just hit KP-COMMA.

> 1) Is the UIL distributed with DEC applications, or isn't it?

no

> 2) If 1) is no, then how does one modify applications behavior for
>    things not modifyable via ``customization'' menus?  (Noteing that
>    almost nothing is modifiable via these menus in current software). 

you can't

> 3) How does UIL ``solve'' the I18N problem in a way that an xdefaults.dat
>    file does not?

It allows the owners of the uil to hard code their i18n stuff and 
makes the original program easier to write.

Realize the the issue is much bigger than OUR ootb applications.  If 
users, 3rd parties, etc. are really going to be convinced to use UIL 
we have to solve all their customization needs in an efficient way, 
too, especially if other vendors provide an easy mechanism.

OSF/Motif does, and will continue to, ship UIL.  Architecturally, it would take
major modifications to both Xlib and the Intrinsics to allow attributes
specified in a UID file to be overwritten by XRM data.  Also, there are many
things that can be specified in a UID file which cannot currently be
represented in an Xdefaults file, including:

 o Widget hierarchy

 o Callbacks

 o Multi-segment compound strings

But, you are all correct that an all-encomposing customization architecture
for customizing application written using UIL or XRM or both has not been
defined.  It is definitely a "hole" that needs filling...

In the mean-time, there are some things that can help.  Today, applications
which use UIL should NOT be specifying values for the things that users
typically want to customize, like fonts and colors.  Most applications
which do use UIL also have a application defaults file where they put
the values of resources which they will allow to be overriden.

For the "near" future we are proposing to OSF that the UIL language be
extended in Motif V1.1 to allow the UIL compiler to write out both
a UID file and an XRM application defaults file.  The application will
then be able to specify whether a resource value should be placed into
the UID file or the XRM file.  It will be much easier for an application
developer to allow attributes to be overwritten by the user.

Leo

I think we should include UIL files for all our applications on the
distribution kit, along with the UIL compiler.  That way our customers can
customize the user interface by editing and re-compiling the UIL files.
The customer would have the problem of having to re-apply these changes
each time s/he upgraded to a new version, but that's better than not allowing
the user interface to be customized at all.

				-- Bob

>> 3) How does UIL ``solve'' the I18N problem in a way that an xdefaults.dat
>>    file does not?
>
>It allows the owners of the uil to hard code their i18n stuff and 
>makes the original program easier to write.

You are saying two things, and I am not certain that I understand the
distinctions you are making.  Could you elaborate?

1)``It allows the owners of the uil to hard code their i18n stuff''.  I dont
  see how this differs from using an XRM style of customization, unless you
  use ``hard code'' to mean that the UIL is not distributed, and thus the
  user can not change it.

2) ``and makes the original program easier to write''.  In what way is
  the program made easier to write?

UIL makes toolkit programming easier because you can create a large, complex
user interface with a descriptive language rather than having to write lots
of verbose, ugly C (or other language) code to instanciate the widget tree.

It makes internationalization easier because you can provide layouts that
are (for the most part) label size independent and you can isolate all of
the text strings for labels and messages to a single location.  The
application is internationalized by translating the text into whatever
language you desire.  The application can ship with multiple .UID files
(compiled UIL files) for each of the multiple supported languages and only
require 1 executable.  Part of what will make this approach better in the
long run is that the mechanisms for compound strings with mixed character
sets are much more clearly defined in UIL than they are in XRM.  (That
does not mean that a standard couldn't be created but it doesn't exist now).

The short coming of this approach is that some applications will have resources,
which the users would want to modify, hardcoded (either in a .UID file or in
the executable).  It is the resources which tailor the application to the
individual user (as opposed to particular categories of users) that need to
be accessible either through Xrm or run-time customization.

Dick

>1)``It allows the owners of the uil to hard code their i18n stuff''.  I dont
>  see how this differs from using an XRM style of customization, unless you
>  use ``hard code'' to mean that the UIL is not distributed, and thus the
>  user can not change it.

Say something grows so much due to i18n that the layout has to change 
or the natural progression from one widget to the next changes because 
they'll be used in a R to L fashion.  With UIL you hard code it and
forget it while 

>2) ``and makes the original program easier to write''.  In what way is
>  the program made easier to write?

to handle all the possible wierd variations of potential changes would 
require much more coding to, for instance, rearrange the layout at 
runtime.  Not that it couldn't be done from resource files.  It would 
just be harder.

The main support for i18n that UIL gives is support for character sets other
than Latin 1. It enables you to mix ASCII, Latin 1, Kanji (Japan), Hanzi (PRC),
or indeed any character set for which you have a font. You cannot do that in 
xdefaults files in any standardized manner.

Tim

	I'd like to see the Style Guide define a standard mechanism for
application customization.  At least for common customizations such as
fonts and colors.  Perhaps this could be done in a manner similar to how
pulldown menu entry help is invoked.  Something like click and hold on
the item to be customized and then press Select (or some other key strokes).
This would bring up a standard interface for changing that type of resource.

Kevin

Dare a newcomer continue this topic?

It was interesting to find this topic and its replies.  I was feeling many of
the same frustrations that have been expressed and tempted to post such a topic
at the risk of being branded a trouble-maker.

One thing that is prompting my late entry is that somehow, I have set up a
rather nice environment for my 15" screen.  All of my icons are of a readable
size and it seems that all of my windows have readable fonts shown.  But, a
new user is trying to set up their VAXstation to have the same appearance as
mine and we can't figure out how I got my system looking the way it does!  What
a frustrating situation!  (VMS V5.3, DECwindows V2)

One of these days, I need to curl up with the DECwindows Style Guide and see
just what it says.  I feel strongly (as does the person who wrote reply 26) that
customization should be covered in the style guide and therefore be a part of
every DECwindows application.  After all, don't we say that they will all have
help?

I realize that every application has its own characteristics that will lend to
customization.  However, they should all have "Customize" on the menu bar and
there should be a "Window ..." dialog box available.  This dialog box should
allow the font size (at least big vs small), startup state of iconized or 
window, and the ability to save current screen geometry settings.  This last
one would simple be a button to press in order to cause the current settings to
be saved by the application.  It would be the application's responsibility to
look at the current window size and location on the screen and save these
values in the appropriate file.  (I'm tired of finding that ever elusive file
and use my least favorite editor to enter pixel entries for obscure attributes.)

Yes, I write software.  And, I have at times dropped my lofty principles in the
face of deadlines.  Unfortunately, it always seems to come back and haunt me
when I do this.  If we don't overdo it with hundreds of options, maybe we could
come up with an easy enough set of customizations for all applications to have
and handle most of the simple problems that face us all.

DECwindows is wonderful.  The applications under it are great.  Unfortunately,
as we get better and better applications and user interfaces, we always end up
finding little picky things to push for.

I'm concerned that .21 missed the point in the first paragraph of .11.  It
might be possible to ship UIL to be customized by the users, but the minute
that someone adds or deletes a widget the application will blow up.  UIL is
a great way of specifying ones widget hierarchy, but there isn't enough
separation of the application from UIL to be able to arbitrarily modify the
UIL.  Now, if the truly customizable portions of UIL (text, x/y positions,
etc) could be in a separate UID file, then that could be shipped.  But I'm
not sure off-hand how well that would work.

regarding .15-20:
With an application using UIL, how would one go about getting settings from
an XDEFAULTS file?  Especially when you want some widget attributes to be a
certain way (for example, mono-spaced font.  You don't care what _size_ it 
is, but it _has_ to be mono-spaced).  How do you guarentee this, while 
letting the users do what they want?  I am not presenting arguments against
this, I want to know _how_ to do it!  It is not obvious to me.

Kevin

> With an application using UIL, how would one go about getting settings from
> an XDEFAULTS file?  
    
    Any widget attribute you want to be customizable cannot be specified
    currently in UIL.  It can be specified in the application xdefaults
    file.  For MOTIF V1.1, the UIL group had proposed a syntax which would
    allow the UIL compiler to generate both .UID files and application
    xdefaults files.  Through some very simple syntax, you could then
    allow some widget attributes to be customizable while still defining
    them through UIL.  Unfortunately, this was an optional task for V1.1
    and I don't think it will make it.
    
> Especially when you want some widget attributes to be a
> certain way (for example, mono-spaced font.  You don't care what _size_ it 
> is, but it _has_ to be mono-spaced).  How do you guarentee this, while 
> letting the users do what they want?
    
    I can't think of any *easy* way to do this, but I can think of two
    possible ways:
    
    1.  Before you create the widget, use XRM calls to find out what value
        the widget is going to get for an attribute.  If it is unacceptable,
        either put an entry into the creation argument list to override it,
        or write an entry into the XRM database to override it.
    
    2.  After the widget has been created (e.g. in a creation callback),
        call XtGetValues to see what it got, and if it is unacceptable,
        call XtSetValues to override it.
    
    Leo