[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

2687.0. "DECwindows VMS/ULTRIX Display Consistency" by HARPY::FULLERTON () Mon Apr 30 1990 17:52

With DEC/Test Manager's DECwindows testing capabilities, we have had several
uses note that the screen output of their applications varies significantly
when run on VMS and ULTRIX DECwindows.  Users have discovered that some fonts
are different, sizes of STEXT widgets are different, height of title bars are
different, and postitioning of text within buttons is different.  So . . .
my question is this:

Are there any plans to get consistency in display output from our various
Xlibs and DECwindows toolkits?  Will there be any testing plan implemented to
assure such consistency?

Regards,

George Fullerton,
DEC/Test Manager Project Leader

T.R	Title	User	Personal Name	Date	Lines
2687.1	I don't think this can be done	STAR::VATNE	Peter Vatne, VMS Development	`Mon Apr 30 1990 18:41`	6
	VMS and ULTRIX share the same set of fonts, so normally there shouldn't be any differences. However, the fonts do change from release to release, so if you are not using the exact same font versions, you will not get the exact same results. Which fonts have you found to be different?
2687.2	How different are they?	SMURF::COUTU	He who will not risk, cannot win.	`Mon May 14 1990 14:34`	6
	And how different is everything anyway? If it's a matter of pixels here and there then is it worth the bother? If the difference is not perceptible to the user then why waste valuable development time making things match perfectly? Dan
2687.3	DTM is pickier than the average human being 8^{)	CLTMAX::dick	Schoeller - Failed Xperiment	`Mon May 14 1990 14:57`	7
	The problem is that DTM remembers specific mouse activity. If each label is 1 pixel bigger (or worse, each character) you start to accumlate location errors that will make your tests invalid. Differences that are imperceptible (or marginally perceptible) to users can be disasterous to a computer trying to simulate a user. Dick
2687.4	pixels count (in some applications)	R2ME2::OBRYAN		`Mon May 14 1990 17:09`	26
	re:.3 > -< DTM is pickier than the average human being 8^{) >- Depends on the human being ;-). There are clear cases in which differences as small as a pixel are quite relevant. DTM is unable to "tell the difference" between relevant and irrelevant diffs... DTM cannot divine meaning while operating from the server-level. To place DTM higher "in the food chain" would make it highly invasive into the various toolkits and applications. While this may indeed be what we need, it is not easily implemented (and requires buy-in from a lot of different development groups.) re:.2 >is it worth the bother (fixing servers/toolkits) ? I think it is reasonable to ask that the toolkits and servers behave consistently (at the pixel level) across platforms. (Only version skews should account for diffs.) These pixel differences add up and result in "ugly" dialogs, inaccessable interface objects, and generally makes the DW application developer (and the company) look incompetent. If application devos have to start conditionalizing their interface definitions, then the concept of platform independence goes out the window. $.02