Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!ico!auto-trol!marbru
From: marbru@auto-trol.UUCP (Martin Brunecky)
Newsgroups: comp.windows.x
Subject: Re: Dec Toolkit PIXMAP/Label question
Message-ID: <267@auto-trol.UUCP>
Date: 1 Sep 89 14:56:44 GMT
References: <226@xpiinc.UU.NET> <5840022@wdl1.UUCP> <1459@riscy.dec.com> <1462@riscy.dec.com>
Reply-To: ncar!ico!auto-trol!marbru (Martin Brunecky)
Organization: Auto-trol Technology, Denver
Lines: 43

>There ARE people out there that do not automatically make the identification
>between DECwindows and X.  Let's not confuse them further by abusing our
>terminology.
>
>If this is true, then it rather unfortunate....
>MIT's implementation of X  should be seen more
>like specs, and how-it-should-be-done....rather than branding it the de facto
>everything (adherence to the specs is the most important thing)...

	Mhmmm. Then I have a problem. My experience shows that EVEN
	though DECwindows is BASED on X/Xt, it:
	1) is not identical (for example, DECWindows Xt is NOT Xt R3)
	   (I'v spent countless hours debugging widgets which run under
	    XtR3 but not DECwindows, just to discover that SetValuesHook
	    is called with a "clone" widget in DWT...etc.etc.)
	2) very often does NOT FOLLOW "how-it-should-be-done", primarily
	   because - VMS engineering aparently knows better than MIT
		   - they try to support other languages than "C", and
		     thus had to sacrifise here and there....

>
>Does anyone have an example which *really* shows how to use the DEC toolkit
>to do  something simple (like make a label widget with a pixmap label) without
>having to pull one's hair out?
>
	We will see a LOTS of remarks like this one. The problem is that
	Xtoolkit is object oriented (but neither Smaltalk-80 nor C++),
	and not many programmers out there understand what that really means.

	DECwindows (and Motiff seems to follow) made that fact less clear
	by providing bunch of convenience routines, which pretend that
	Xt is NOT OBJECT oriented - making it look like "yet another subroutine
	library".
	In part, it makes things LOOK familiar and easy, but on the other hand 
	causes lots of confusion. Whenever the poor user wants to something
	more than the toolkit developer had in mind, he is thrown into the 
	reality which he is NOT prepared to face. 

###############################################################################
Martin Brunecky, Auto-trol Technology Corporation,
12500 North Washington Street, Denver, CO-80241-2404
(303) 252-2499                                        ncar!ico!auto-trol!marbru
###############################################################################