T.R | Title | User | Personal Name | Date | Lines |
---|
1774.1 | SOLD ! | BZERKR::DUFRESNE | VAXKLR - You make'em, I break'em | Tue Nov 21 1989 12:19 | 11 |
| 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
|
1774.2 | Needs to be "expected" | CASEE::CLEOVOULOU | Marios Cleovoulou | Tue Nov 21 1989 13:52 | 38 |
| 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
|
1774.3 | Thats ok... | CRLMAX::jg | Jim Gettys, Cambridge Research Lab | Tue Nov 21 1989 14:18 | 36 |
| 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
|
1774.4 | re .1 & .3 | ERIS::CALLAS | Hey, heads we dance? | Tue Nov 21 1989 15:04 | 3 |
| Huzzah! I'm sick of being stuck with fonts I can't read!
Jon
|
1774.5 | | SITBUL::KLEINSORGE | So sue me. | Tue Nov 21 1989 16:16 | 20 |
|
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 :-)
|
1774.6 | Support is a different issue... | CRLMAX::jg | Jim Gettys, Cambridge Research Lab | Tue Nov 21 1989 16:46 | 18 |
| 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
|
1774.7 | | LESLIE::LESLIE | Andy ��� Leslie | Tue Nov 21 1989 16:50 | 1 |
| <Applause>
|
1774.8 | | 1075::WARWICK | Trevor Warwick | Tue Nov 21 1989 18:30 | 14 |
|
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
|
1774.9 | | STAR::MFOLEY | Rebel without a Clue | Tue Nov 21 1989 18:57 | 21 |
| 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
|
1774.10 | Jumping on the band wagon | GVRIEL::SCHOELLER | Who's on first? | Tue Nov 21 1989 23:38 | 10 |
| 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
|
1774.11 | Customization is not just visual attributes.. | IO::MCCARTNEY | James T. McCartney III - DTN 381-2244 ZK02-2/N24 | Wed Nov 22 1989 00:53 | 75 |
| 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.
|
1774.12 | Not how it's done, but that it's done! | XCUSME::DLUGOSZ | The past is but the beginning of a beginning | Wed Nov 22 1989 10:00 | 10 |
| 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
|
1774.13 | on maintaining the .Xdefaults file | REGENT::LOMICKA | Roy Lomicka | Wed Nov 22 1989 10:29 | 10 |
| 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.
|
1774.14 | Orthogonal issues | MELTIN::dick | Gvriel::Schoeller | Wed Nov 22 1989 11:41 | 25 |
| .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
|
1774.15 | | PSW::WINALSKI | Careful with that VAX, Eugene | Wed Nov 22 1989 14:55 | 19 |
| 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
|
1774.16 | That's the word - TYRANNY
| GYRO::COBURN | | Tue Dec 05 1989 10:09 | 9 |
|
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
|
1774.17 | no resources == no modparams.dat | TOOLEY::B_WACKER | | Tue Dec 05 1989 12:15 | 18 |
| 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
|
1774.18 | Questions: | VINO::WITHROW | Mass. recall petitions available here! | Tue Dec 05 1989 12:25 | 13 |
| 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.
|
1774.19 | Much bigger than ootb | TOOLEY::B_WACKER | | Tue Dec 05 1989 14:52 | 20 |
| > 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.
|
1774.20 | | LEOVAX::TREGGIARI | | Tue Dec 05 1989 17:14 | 30 |
| 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
|
1774.21 | Why not give customers the UIL files? | HANNAH::MESSENGER | Bob Messenger | Wed Dec 06 1989 11:07 | 8 |
| 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
|
1774.22 | Still trying to understand... | VINO::WITHROW | Mass. recall petitions available here! | Wed Dec 06 1989 12:54 | 16 |
| >> 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?
|
1774.23 | Expand on that... | MELTIN::dick | Gvriel::Schoeller | Wed Dec 06 1989 14:39 | 22 |
| 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
|
1774.24 | But I still don't like the consequences | TOOLEY::B_WACKER | | Wed Dec 06 1989 16:05 | 18 |
| >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.
|
1774.25 | UIL support of non Latin1 character sets | HANJA::GREENWOOD | Tim. Asian Base-Systems | Fri Dec 08 1989 14:32 | 6 |
| 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
|
1774.26 | | MDVAX3::SOCHA | | Tue Dec 19 1989 17:11 | 8 |
| 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
|
1774.27 | The "Style Guide" is all important | RCOJDS::SHOWALTER | Jay Showalter | Mon Jan 29 1990 23:41 | 39 |
| 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.
|
1774.28 | Keeping the topic open; how-to question | TLE::ROUTLEY | Kevin Routley - VAX/VMS & XD DEBUG | Fri Feb 16 1990 18:35 | 19 |
|
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
|
1774.29 | Some possibilities for argument "checking" | LEOVAX::TREGGIARI | | Sat Feb 17 1990 08:09 | 31 |
| > 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
|