Conference bulova::decw_jan-89_to_nov-90

I agree on all counts.  But don't be so quick to cut down DECburger - at least
it's something people can understand and can get them started.  However,
DECburger has one undeniable advantage - it exists.  I haven't seen anyone
propose a different example to demonstrate DECwindows coding.  Do you have
one to share, Pat?

I have been told that the DECwindows folks are going to devote at least
half a developer to the examples, which is better than the current situation,
where they rely on "the kindness of strangers".  I've spent a fair amount
of time translating and debugging the DECburger and HELLOWORLD examples
into Ada and FORTRAN, keeping them updated as I learn new things (though
my latest changes didn't make it into DECwindows V2.)

I do agree that there is far too much emphasis on Xlib - most applications
should never have to deal with Xlib at all.  

			Steve

    Re .1:

> I do agree that there is far too much emphasis on Xlib - most applications
> should never have to deal with Xlib at all.  

    While I do agree that Xlib is probably not the first thing you want to
    learn how to use, I'm not so sure about your statement, Steve. I
    understand this is pretty much a rat hole, but... Basically, when
    designing an application's User Interface, you should let your
    imagination go wild: if there's one thing you don't want to do is
    having your ideas constrained by what the toolkit offers. Once you have
    a grand plan, you should try to approximate what you had in mind using
    toolkit widgets and UIL and all that: this will be good enough to
    validate the idea. In doing that, you are very likely to hit the
    constraints of code reuse: performance, and it doesn't quite do what
    you wanted to do. In some cases, it will be very worthwhile to dump
    what you just wrote, and redo it as a custom widget with Xlib calls:
    you then stand a good chance of being blown away by the performance you
    get.

    We've done this for DECwindows Calendar with the mini months in the day
    view: the first implementation was a bunch of label widgets... Same
    thing with the icons: they were toggles with pixmap initially. And the
    V1 day view was essentially a bunch of text widgets: in V2, it's a
    bunch of special purpose widgets. And Calendar is still far too slow...

    There at least two problems with that approach: it's VERY, VERY costly,
    and you need to become a proficient widget programmer. The cost is a
    real problem on most projects, and becoming a proficient widget
    programmer can be quite an experience... which leads back to the topic
    of .0 

    Regards,
    Denis.

The de-emphasis of Xlib bothers me too...

Somebody please expalin to me how one understands the guts of X ..
(how the damn thing works) without understainding Xlib.  

Maybe, what is really needed is a graphical tool that teaches the
new user the structure of X.  Call it a CAT tool ;-)

Kris...

It ought not to be necessary to understand how Xlib (or X) works in
order to develop applications.  The simplest applications should be
done using the Toolkit and UIL.  If your imagination starts to wander
beyond that, THEN start learning about Xlib.

To me, it's like teaching people about microcode when all they want to
do is write FORTRAN programs.

Sometimes I think that we, as engineers, fixate on the gee-whiz complicated
stuff that makes us feel like wizards when we understand it, and don't
readily grasp that those who are new to this whole world don't know how
to separate what they need to know from what they don't.

Let me put it this way - if everyone should use Xlib, why did we develop
the toolkit?

					Steve

    People have used terminals for writing applications without knowing
    what specific command sequences do.
    
    The fundamentals of the MIT X Window System need to be expressed: it is
    a network-based window system, it is transport-independent, operating
    system independent, and within reason drawing hardware independent.
    
    Details of the window manager protocol, graphics contexts, event
    processing, etc. require a lot of X code, and in teaching terms you're
    not getting much bang for the buck.  We're talking here about the first
    forty hours, I'm not asking for copies the the X Window System to be
    burned.
    
    The Xlib emphasis is a leftover from the time when Xlib was the single
    most documented aspect of DECwindows.  Happily, this is no longer the
    case.

    Re .4: "if everyone should use Xlib, why did we develop the toolkit?"
    
    To sell memory upgrades.
    
    Seriously I agree very much with Denis. Xlib is fundamental. Many
    applications require custom widgets, for tolerable performance or to
    display graphics, and custom widgets require Xlib. Plus you need to
    have an idea of what's going on underneath and only Xlib provides it. 

  Ahhhh....let us remember though...

  The toolkit was never meant to completely occlude Xlib.  The toolkit provides
widgets and intrinsics.

  A truely robust client/application will undoughtedly need to use Xlib.  Also
since the toolkit is nothing more than Xlib calls I think having a good, basic,
understanding of Xlib can only help with understanding the toolkit.

  If you think of a widget, or more to the point, an intrinsic, it is just a
procedure call that in turn makes Xlib calls.  This gives you basic OOD, but
in this environment it helps in knowing how something was implemented not just
what "these series of Xlib calls" do.

  I think of it as learning to crawl (Xlib) before learning to walk (DECtoolkit)
and then run (UIL).

  Ok...I'm off the soapbox...next speaker...

					-=> Jim <=-

    With all due respect, Pat, I believe you underestimate the need
    to understand *well* what goes on at the Xlib level.  Granted, this
    is not needed to write many simple, text-based applications. But
    the world is more complex than simple, text-based applications!
    
    I have yet to write a single serious program in which I did not
    have to work at the Xlib level as well as the toolkit level. 
    Sometimes I've been able to confine the Xlib code to a custom
    widget for the application, which is by far my preferred method.
    Until a much more robust and diverse set of widgets is available,
    Xlib in the Toolkit context is a fact of life.
    
    I believe we need a training curriculum that begins with an
    architectural overview of X, goes on to preach the object-oriented,
    toolkit philosophy, expounds the benefits of the UIL, provides
    lots of practical exercises using the UIL, and then moves on
    to writing widgets. The last step is critical for programmers
    in a production environment who need to build up a library of
    user-interface objects that meet *their* application requirements,
    not those of the XUI or Motif development team.
    
    The widget-writing instruction requires extensive coverage of
    Xlib, and should not be reserved for the chosen few. We need
    to de-mystify widget writing and equip application writers to
    build objects to model real-world programming concepts.
    
    Dave

    this discussion is a really hot topic here in Europe as Ed. Services
    mgt decided to turn the 5 days DECW programming course to 8 or 10
    days precisely because 5 days are not enough to teach all of it.
    
    Personaly, I show the slides on XLIB but *don't* teach the exercises
    coded in X. My labs are only UIL-based (and in FORTRAN because I
    don't know C - sorry)
    
    Didier_who_spent_his_own_DECW_training_translating_C_labs_to_FORTRAN
    (Educational Services, Geneva, Swiss)

    
    I submit that Xlib programming is just too difficult for the average
    programmer not familiar with graphics programming, indeed I've seen
    people with graphics experience throw up their hands and walk away.
    It is quirky, semi-documented and a bitch to debug.
    
    The current widget set is far too confining and must be greatly
    expanded, the GObE widget is an example of the type expansion it
    needs.
    
    _Fred (up to his elbows in Xlib programming)
    

    I think there are three issues here:
    
    	1. Who is the audience
    	2. What topics to teach (and the time spent of each)
    	3. What order to teach them in
    
    
    I agree that to be an advanced DECwindows devo (and one must be
    advanced in order to write a sophisticated application) one needs to
    know about UIL and customized widgets and Xlib.  However, I *strongly* 
    disagree with .7 that learning Xlib is learning to crawl and learning
    UIL is learning to run.  Quite the opposite.  Learning UIL is like
    learning to drive a car; learning Xlib is like learning to build a car.
    
    
    Are the students experienced devos who will be writing sophisticated
    application systems or are they beginners who will be writing simple
    apps?  I would recommend a beginner course and a follow-on advanced
    course.
    
    In the beginner course, I would focus on the user interface "look and
    feel" features (menus, pull rights, work areas, dialog boxes, slider
    bars) and how to create them quickly using UIL and callbacks. This
    introduces the student to UIL, the basic toolkit, widgets and gadgets,
    callbacks, and OOP in general.  This shows the student the power of the
    toolkit by enabling them to go from knowing nothing about DECwindows
    programming to designing and building a sophisticated user interface in
    a matter of three days.  Also, the student is introduced to the
    limitations of this approach.
    
    In the advanced course, I would focus on how to overcome the
    limitations that the students "discovered" in the beginner course. 
    This is where they would learn all the nitty-gritty details of
    overriding the widget defaults, low level Xlib calls and how to use
    them to write customized widgets and gadgets in order to improve
    performance.  This course would probably run a week.
    
    
    John B.
    ex-course developer and 
    DECwindows performance analyst
                                                        

    Who is teaching using DECburger as an example? The three courses
    that I was involved in don't even mention it!
    
    Have you guys sen the outlines of the two new DECwindows courses?
    DECwindows Programming I concentrates on XUI and creating the user
    interface. The only mention on Xlib is on day 1 to get across the
    aync nature of things and give them a taste of what they'd be up
    against without the toolkit. The rest of the week is widgets and
    how to use them (using low- and high-level and UIL).
    
    DECwindows Programming II picks up with more advanced concepts.
    Things like event management using alternate sources, cut and paste,
    multiple application shells. It then moves into using graphics (i.e.
    Xlib). This cover pointer motion, gcs, color, regions, and graphics
    primatives. But in a window WIDGET, not a window! It ends with an
    intro to widget architecture.
    
    If anyone wants to see outlines shout.
    
    Ron

RE: .12

Yes, that is the correct approach to Xlib:  it should be regarded as something
that one uses to scribble graphics in a window widget.  Of course, it's also
something that one must be very familiar with when designing custom widgets.
One can go very, very far without having to do custom widgets, however.

--PSW

[soapbox alert]

>>One can go very, very far without having to do custom widgets, however.

Unfortunately, one usually cannot go far enough (with the widgets DEC
supplies) to build a "real" application.

Believe me, I've talked to a lot of frustrated customers who have spent weeks
or months trying to figure out how to use the toolkit to build, for example, a
simple table-based editor.  And none of them have succeeded without writing
their own widgets.

And to say that XLib calls should be limited to a window widget shows
real widget-phobia and I suspect comes from someone who has never
written a widget.  Try it, you'll like it.

Seriously, though, I believe that an understanding of the basic XLib
primitives should be taught very early.  After all, we teach about
numbers before we teach how to add.  Knowing what the XLib primitives
are makes understanding the toolkit a snap.  I'd even go so far as to
start with the X protocol requests - there aren't as many of these as
there are XLib calls, and they show very clearly what is and is not
possible.  Build knowledge from the bottom-up for a strong understanding.

And while I'm here (on my soapbox), I might as well add (in response to
another note) that I believe that to teach X in anything other than C is
a disservice to the customer, and to try to teach X without knowing C is
a crime.

-steve-

    RE .14
    
    Actually I have written widgets. Neither course is geared to actually
    teaching them how to *write* widgets. DWPII only offers an introduction
    to widget architecture and a look at some simple (read COMMON) class
    widgets (oh - and a constraint widget).
    
    The approach taken with Xlib is as is since window widgets are all
    we have available for customers to draw in. Last I checked drawing
    in other widgets was unsupported! (And they don't know about Gobe).
            
    Someday we may have the resources to add real seminar on widget
    writing. Some kind soul may even decide to put together some training
    on DECimage. (Motif is on the way). Until then, we're stretching
    it trying to cram all that info into two weeks and still give the
    customers the amount of lab time that they want. 
    
    Like you said though, it is fun. Only wish I had more time to write
    code...After teaching for a couple of weeks, my own code sometimes
    looks foreign when I get back to it! 
    
    Ron
    

	I feel that steve has the right approch. Myself I would start at
	some of the client server concepts and use some of those brilliant
	tools available out there like Xliddy and the window/event watcher to
	show the protocol working in a real way then start from the top of
	the tool kits and work slowly-fast down explaining tool kit structure
	
	The advantage is that the victum (student) actually before start 
	to write with a toolkit actually has a practical insight into what
	is going on without having to loadup on Xlib first.

	Karl "My Opinion entirely of course" Mutch

    re: .16
    
    Idealy it would be a good approach. The problem is that you have
    a number of restrictions which limit what you can cover:
    
    1) It's hard to get people up here for training for more than 
       one week.
    2) The students demand ample lab time for programming exercises
       (and evening hours is not a viable solution due to security
       restrictions in many facilities).
    3) In teaching DECwindows over the past year I can very definitly
       state that in order to allow for #2 it is not possible to 
       provide adequate coverage of Xlib and DECtoolkit. The X Protocol
       would be unthinkable since most students would not even be able
       to use it.
    
    Ron
    

    re .14:
    
> Seriously, though, I believe that an understanding of the basic XLib
> primitives should be taught very early.  After all, we teach about
> numbers before we teach how to add.  
    
    The fundamental problem with this argument is that there is a
    fundamental difference between academic child education and industrial
    adult education.  Industrial education is time critical and results
    driven.  Also, adults have a really high level of failure-anxiety.  
    
    If you were to use the academic approach to teach adults who needed to
    learn how to add to do their job, they would either quit or throttle
    the instructor at the end of the first day.  Why?  Because at the end
    of the first day they would not have anything to show for their
    efforts.  That means they failed at their job, therefore they failed
    their families and themselves.  No kidding.
    
    Steve, I fully agree that in order to be an expert DECwindows devo, one
    needs to know ALL of DECwindows, right down to reading Xliddy traces. 
    
    soapbox begin
    	IMHO any DECwindows devo worth his/her salt who doesn't look at the
    	traffic on the wire is just begging for trouble.
    soapbox end
    
    But get the order correct.  For industrial adult education, that means
    providing at least one new skill each and every hour that can be
    applied *immediately* on the job.  You simply cannot expect the
    students to sit through several days of Xlib classes and still not be
    able to write a style guide compliant pulldown menu.
    
    
    John B.

    >But get the order correct.  For industrial adult education, that means
    >providing at least one new skill each and every hour that can be
    >applied *immediately* on the job.  You simply cannot expect the
    >students to sit through several days of Xlib classes and still not be
    >able to write a style guide compliant pulldown menu.
    
    
	Oh, I get it.  You're saying that adults have an even
    	shorter attention span than the average 5 year old, so
    	they need even more coaxing to get them to learn something!

    I don't know how .19 meant me to take that statement, so at the expense
    of screwing up a perfectly wonderful (as in full of wonder) joke, I'll
    treat it seriously...
    
    There is nothing short about an adult's attention span (other than the
    fact that it is 45 minutes or the time until lunch, which ever is
    shorter).  There is, however, a limit to an adult's patience.  A child
    may do something just because the teacher says so, but an adult demands
    to know "Why are you telling me this?"  A child's mind is (more or less)
    a blank slate, an adult is constantly trying to fit new concepts into
    their old view of the world.  
    
    So while a child may think the XCreateGC function to be some sort of
    game of dubious interest, an adult will want to know why they have to
    go through all these convulutions just to draw a stupid little line on
    the screen and wonders when are they going to learn how to write a menu
    bar and pulldown menus.
    
    And an adult will crucify you when they find out there is a shortcut...
    
    
    John B.

Steve Klein is correct that the off-the-shelf DECwindows widgets are not the
end-all and be-all for every application.  It is still possible to get quite far
just with the DEC-supplied widgets.  VMS Mandelbrot, VAX NOTES, VAX DEBUG, 
DWCI, TPU, LSE, and VAX PCA's DECwindows UIs were all done without writing
custom widgets.

The basic structure that I think is appropriate for a course on DECwindows
programming runs as follows:

DECwindows has the following structure:  there is your application, which does
calls into the DECwindows toolkit and Xlib to make graphics happen.  The
toolkit saves you a lot of grunge work and also assures that all the DECwindows
applications have a similar look and feel.  The toolkit also calls Xlib to do
its graphics stuff.  Xlib in turn uses the X protocol to send the graphics
requests to the X server, which babysits the actual graphics hardware.  The
use of protocol messages means that the client (your application, the toolkit,
and Xlib) don't need to be on the same physical hardware as the server and the
actual graphics hardware. [I wouldn't spend more than 10 minutes total on this]

Your application should use the off-the-shelf toolkit routines whenever
possible. [lots of detail on how to use the toolkit, UIL, etc.]

To do graphics, you need to do Xlib calls in to a window widget. [detail on
GCs, X graphics routines, etc.]

Where existing widgets don't provide the functions you need, you may have to
write your own. [detail on widget writing and more Xlib stuff]

I would leave out all of the Xlib stuff that's only useful in writing window
managers and session managers.


The main message should be that custom widgets and raw X are things you resort
to when existing code won't do.  They're not preferred ways to develop
applications.

--PSW

    Hi Guys,
    
    I see the discussion here is mainly about the benefits and drawback
    of learning Xlib and UIL and in what proportion they should be taught.
    Do we know there is a big wide world out there that DOESNT use the
    DECwindows toolkit and could quite possibly be incorporating its
    thinking into future toolkits. X however is a "standard" (or so
    I am lead to belive), it is not likely to go through major overhauls
    as DECwindows toolkit is (for historical note look at C). So Xlib
    must be important. UIL and dwtoolkit are shortcuts and it seems
    to me that teaching them would be a good introduction, but very
    little else (a real programmer would probably end up building their
    own libraries anyway). 
    
    I like the sound of the introduction course and the advanced course
    in DECwindows programming. But what do we have now? EY-9459E-LO
    is not billed as DW progging I or II (in europe that is), when can
    we UKers and Europeans expect the split courses?
    
    Another point that seems to have been missed is that DECwindows
    and X run very much on TWO or more DEC operating systems, namely
    VMS *AND* ULTRIX, very different beasties. Are future courses going
    to be OS indepentdent and is this possible? Is Ultrix to be catered
    for (separate courses?). I know the X libs and toolkits are supposed
    to be identical, but in the real world that is not the case, VMS
    and Ultrix DECwindows are different products and different products
    deserve special attention.
    
    Les
    (Who is on the DW progging course in Nov in UK)
    (An Ultrix person in a VMS world)

    You can remove the quotes from standard.
    
    The MIT X Window System is a standard under the control of the X
    Consortium.  The standard included the specification of the X Toolkit
    Intrinsics.  The MIT X Window System has proposed as a standard to FIPS
    (US Government) and to the European Community.
    
    XUI, a Digital product, is layered on the X Toolkit Intrinsics.  XUI
    was accepted by the Open Software Foundation as the basis for the
    application programmer interface for its prooduct Motif.  Motif has
    also been proposed as a standard.
    
    Programming without a toolkit is a topic for another note.
                                                              
    I hope that these basic facts are not overlooked in teaching employees
    and customers DECwindows in favor of such details as how the
    FocusChange event should be processed.

.22

Libraries allow reusability.  Any programmer that doesn't attempt to maximize
their use of pre-defined libraries isn't a real programmer  8^{).  When was
the last time you went and tried to rewrite math or stdio just because it
wasn't quite exactly what you needed?

As far as XUI not being a standard, that is true.  But most of the principles
involved in XUI toolkit programming can be applied to programming in any
other toolkit based on the Xt intrinsics.  This even includes the use of
UIL if you want to give that one a shot.

Dick

    Besides, you can *never* remove the quotes from around "standard".

OK, it's a rathole, but I couldn't resist...

>Libraries allow reusability.  Any programmer that doesn't attempt to maximize
>their use of pre-defined libraries isn't a real programmer  8^{).  When was
>the last time you went and tried to rewrite math or stdio just because it
>wasn't quite exactly what you needed?

According to the module header, I last tried to rewrite stdio on
29-Jun-1989.  OK?	:-)

/* Copyright (C) 1989
 * by Digital Equipment Corporation, Maynard, Mass.
 *
 * FACILITY:	MicroLES kernel
 *
 * ABSTRACT:	This module contains routines which are replacements
 *		for the standard I/O routines in the C runtime library,
 *		but can be used in a standalone kernel.
 *
 * AUTHOR:	Dave Porter, 29-Jun-1989
 *
 */

>>According to the module header, I last tried to rewrite stdio on
>>29-Jun-1989.  OK?	:-)

Funny you should pick up on that.  A "programmer" friend of mine just
rewrote much of stdio last month for a x10 performance improvement in random
file access - which was critical for the success of his application.

Real programmers don't hesitate to "do it" if it needs to be done.

-steve-

And were these rewrites of stdio submitted back for inclusion in the
"standard" library, so that they would not have to be rewritten in the
future?  Or were you all intent on making people rewrite them over and
over?  8^{)

Dick

    RE: .22
    
    Les,
    
    DWPI and DWPII exist. I've taught DWPI twice now, and next week
    will be the first pass at DWPII (with an audience > 2 that is).
    They were developed for SWS (Deb Koppes would, I believe, be the
    contact) by ESD&P back in August.
    
    I'm using somewhat modified versions for the ISV training. I 
    replaced Module 2 of DWPII (Cut/Paste) with my own version,
    and added more indepth XImage coverage. Also tend to use my 
    own lab exercises or add to existing ones.
    
    If you want more info about the content, modifications (or
    why they were made), or results of the first few passes buzz
    me at EXLIB::DLUGOSZ (XCUSME::DLUGOSZ through tomorrow).
    
    As far as OS independence goes, they're about operating system
    independent as they will probably ever get. I actually run into
    more hardware (read PMAX and FIREFOX) dependencies than those
    that are os related.
    
    Ron

>And were these rewrites of stdio submitted back for inclusion in the
>"standard" library, so that they would not have to be rewritten in the
>future?  Or were you all intent on making people rewrite them over and
>over?  8^{)
	
	I didn't expect the Spanish Inquisition!	:-)

	Well, if you read my module header, my rewrite was to
	allow stdio to be used standalone (i.e., no O/S, or
	to be precise, so I could use it to write an O/S).  
	I'm not sure the VMS runtime library needs that...

	However, I did ship my source code for sprintf/sscanf
	to someone in the VAX C group, in case it could be
	of any use to him.

	Do I qualify as "responsible" ?		

    
    
    Someone mentioned looking at the wire a few replies ago.
    
    It would be helpful if this were possible with a small 
    program (a debug widget?) rather than requiring a huge 
    application that runs only on VMS. 
    
    Its embarrassing to have to refer people to Dave Rosenthal's
    (of Sun) utility for reading the wire.
    
    As for teaching UI versus Xlib... a UI designer should, ideally,
    be concentrating on human factors, not on the obscurities of
    Xlib (or whatever API you happen to be using). If a UI generator
    can insulate a designer from the actual code, its my opinion that
    more cycles can be spent making an app usable, and less in enhancing
    the designers Xlib learning curve.

RE: .30

	Nobody expects the Spanish Inquisition.  For that, I sentence
	you to the Comfy Chair!

							mike

    Re .-1
    
    	Aren't you in the wrong conference? (should be in MONTY_PYTHON!)
    
    Re .29
    
    	"DWPI and DWPII exist"
    	
    	So which one is EY-9459E-LO (dec windows programming?)? (in
    Reading Uk 20/11/89). and is there provision for both O/S's (!)
    in the equip (probably not the right place to ask but I'll ask anyway!)
    
    Les
    

    Re. -1
    
    >     So which one is EY-9459E-LO (dec windows programming?)? (in
    > Reading Uk 20/11/89). and is there provision for both O/S's (!)
    > in the equip (probably not the right place to ask but I'll ask anyway!)
        
    I was never very good at remembering part numbers for the courses.
    I'll check Monday norining and post it. 
    
    By 'provision for both O/S's' do you mean kits for the lab examples
    that can run on both? If so yes.
    
    This would seem to be the place to ask...although a discussion on
    some other topic seems to have broken out...reminds me of a good
    hockey fight...er game.
    
    Ron

    RE: -.1
    
    Well, as the plans of mice and men go, I wound up in the hospital
    Sunday night. I get those part numbers to you as soon as I get back
    into the office.
    
    Ron