[comp.windows.x] Xw on Sparc? Xaw vs Xw vs XView? Interp layout contraints?

jorice@swift.cs.tcd.ie (03/15/90)

First, a genuine Paddy's Day goodwill wish from me in Ireland to all the nice
people who are going to answer my questions. You see, I want to know about the
Hewlett-Packard widget set Xw...    and about XView...

(1) Why no discussion of Xw? Is noone using it because it's unsupported, or
because it's horrible in some way that I haven't found yet, or are all the Xw
users so serenely happy with their system that they have no need to ask
questions?

(2) The original reason why I thought of using Xw is that it was the widget set
used in Douglas Young's book "Window Systems Programming and Applications with
Xt" and it seemed to look better and work better than the old version of the
Athena widgets (Xaw) that I was using at the time. What particularly pissed me
off about the old Xaw was its totally stupid method of laying out sub-widgets
in Forms that seemed to require that you map a widget before you could use its
outline coordinates for the relative positioning of another widget. Xw seems
better at this. Any comments? Are there any reasonably small widget sets that
use *dynamic* constraints for laying out sub-windows? What I'm talking about is
the sort of thing that's possible in Smalltalk, where all you have to say is
something like "window A is above window B, window A is to the left of window C
and window B is left-aligned with window C" and the system will reinterpret this
high-level specification each time a re-layout is necessary. I know there's
this lispy thing winterp for Motif, but this whole non-free thing about Motif
is bad news.

(3) After getting the version of Xw from the contrib section of the X11R4
release tape and compiling it, I was disappointed to see that it's not the 3-D
version that's used in Young's book (3-D as in buttons looking slightly raised,
text input boxes slightly sunken, etc.). Can this be got? I presume it has the
same programming interface so that all that's needed is a relinking?  What
other widget sets exist with a 3-D look that are reasonably small? XView offers
this, doesn't it? But that's a very large system. no? I don't have much disk
space here.

(4) On the subject of XView, how is it to program? I'm wary of it because I
found programming in SunView needlessly difficult and I think that SunView
applications look really clutzy. How much better is XView? How much disk space
does it take up when compiled, roughly?

(5) Some of the test programs that came with Xw don't seem to work correctly -
can someone tell me why? Generally, the little sash sub-widgets in VPaned
widgets don't work right. They always come up as blank white instead of black,
for a start, but the real hassle is that unless the server is switched to bug
compatibility mode, things bomb out when you try to grab the sash with the
pointer. The other odd problem is in the test program menuTest1, where the
pop-up menus brought up by clicking on the two lowest buttons just flash up on
the screen and then vanish again. My machine here is a Sun Sparcstation1
running SunOS 4.0.3c. Yes, I'm running Release 4 of X with at least some
patches applied. I've tried compiling the problem programs with both cc and gcc
with exactly the same effect.


Sorry this has been a bit long. Anyone who got this far, thanks for getting
this far.

moraes@cs.toronto.edu (Mark Moraes) (03/17/90)

jorice@swift.cs.tcd.ie writes:
>(1) Why no discussion of Xw? Is noone using it because it's unsupported, or
>because it's horrible in some way that I haven't found yet, or are all the Xw
>users so serenely happy with their system that they have no need to ask
>questions?

Mostly because it's unsupported, I guess.  I found Xw very nicely
designed, fairly solid, well documented and easy to use.  It got used
in a few programs here.  I still prefer Xw.

There's also the fact that the Xw with R3 didn't work with R3 Xt
without major mods (I'm told Xw sort of evolved into Motif, which could
explain why Xw isn't supported any longer.  Or maybe HP just got tired
of giving away their work) It's unfortunate - many of us hoped it
would become the standard widget set when it came out; technically it
is really nice.

For those people writing freely redistributable programs for X, who
don't care too much about look/feel, Xaw remains the preferred choice
because the people at MIT do fix bugs, it's sort of guaranteed to be
in most X distributions despite the fact that it isn't a Consortium
standard.

I wish the X Consortium would adopt Xw, or at least some of the Xw
widgets to fill holes in the Xaw line -- at present, Xaw is sort of ok
for simple user interfaces; feels kind of clunky.  Xw feels smoother,
and had good documents, a nice class hierarchy.

Motif is the official party line, it would appear.  People who've used
Motif tell me it's very solid, much better than Xaw and Xw, and worth
paying for.  Said people have lots of disk space and memory, of
course.  Doug Young's book is now out in a Motif version.

>(3) After getting the version of Xw from the contrib section of the X11R4
>release tape and compiling it, I was disappointed to see that it's not the 3-D
>version that's used in Young's book (3-D as in buttons looking slightly raised,
>text input boxes slightly sunken, etc.). Can this be got?

Not easily, no.  If you happen to have a pre-R3 copy around (the one
that was on expo.lcs.mit.edu for a while before the R3 release), that
had the 3d look.  It got taken out possibly because of the look and
feel litigation, or perhaps because HP just wanted to keep the spiffy
looks for their product release only.  Since I personally don't see
why 3d is so desirable, I didn't care much.  It's probably feasible to
put it back in (I remember taking the 3d stuff out of the button code
to try and get xpic to start in finite time -- on the R3 Xsun, drawing
the 3d stuff was agonizingly slow)

>(4) On the subject of XView, how is it to program? I'm wary of it because I
>found programming in SunView needlessly difficult and I think that SunView
>applications look really clutzy. How much better is XView? How much disk space
>does it take up when compiled, roughly?

XView seems considerably better than SunView in the programming
interface -- it's got some of the Xt object-oriented approach.  But
it's big.  Some of the code in the internals of the notifier looks as
if it would be painful to port to a system without Berkeley style
signals.  (We have one of those:-) Has anyone gotten XView running on
non-Sun machines?

One possibility for a small toolkit would be to use olgx, and bits of
olwm for the spiffy 3D look.  olgx is fairly small.  Building a set of
widgets with it, or retrofitting it onto Xw might be nice.

Given the great response of the XView people to questions on the list,
and to bug reports, it's might be a good alternative for those of us
too broke to buy widget sets, or those of us that want source with few
strings attached.  (Obviously, just like Xw, there's the possibility
that at some point in the future, XView src may stop appearing in MIT
X distributions)

>(5) Some of the test programs that came with Xw don't seem to work correctly -
>can someone tell me why? Generally, the little sash sub-widgets in VPaned
>widgets don't work right. They always come up as blank white instead of black,
>for a start, but the real hassle is that unless the server is switched to bug
>compatibility mode, things bomb out when you try to grab the sash with the
>pointer. The other odd problem is in the test program menuTest1, where the
>pop-up menus brought up by clicking on the two lowest buttons just flash up on
>the screen and then vanish again. My machine here is a Sun Sparcstation1
>running SunOS 4.0.3c. Yes, I'm running Release 4 of X with at least some
>patches applied. I've tried compiling the problem programs with both cc and gcc
>with exactly the same effect.

Probably bugs in Xw.  Hammering it through lint or a fussy compiler
(gcc -O -W, or the IBM RT/PC hc) would be a step in the right
direction.  Doing a code walkthrough wouldn't hurt -- there may be
things in the R2 to R3 conversion that got missed, despite the
comprehensive job Marty did.

	Mark.

klee@wsl.dec.com (Ken Lee) (03/17/90)

In article <6873.25ff8b27@swift.cs.tcd.ie>, jorice@swift.cs.tcd.ie writes:
> (1) Why no discussion of Xw? 

Xw is nice, but it doesn't work with X11R4.  I believe that the version
on the X11R4 tape is not supported by anyone officially or
unofficially.  HP is now shipping Motif with its hardware.

> (2) The original reason why I thought of using Xw is that it was the
widget set
> used in Douglas Young's book "Window Systems Programming and
Applications with
> Xt"

The latest edition of this book uses Motif examples.

> (3) After getting the version of Xw from the contrib section of the X11R4
> release tape and compiling it, I was disappointed to see that it's not
the 3-D
> version 

HP's 3D look went into Motif.

> (4) On the subject of XView, how is it to program? 

The semantics of XView are similar to those of the X Toolkit.  There
are some advantages to XView, such as more UNIX-specific support.
Disadvantages of XView are incompatibility with X Toolkit widgets, no
subclassing, no separation between "intrinsics" and "widgets", and no
support for popular X Toolkit user interfaces such as configuration
through translation management and resource management.  Also, some
customers are now requiring (to some degree) their purchases to be
based on the X Toolkit (e.g., the recent U.S. Government FIPS).

Ken Lee
DEC Western Software Laboratory, Palo Alto, Calif.
Internet: klee@wsl.dec.com
uucp: uunet!decwrl!klee

moraes@cs.toronto.edu (Mark Moraes) (03/17/90)

klee@wsl.dec.com (Ken Lee) writes:
>Xw is nice, but it doesn't work with X11R4.

On our Sun[34]s, it seems to work reasonably well with R4 (xwebster,
xpic work with it, so do all the demos, even though menus need fixing)
even without the fix I put on expo.  (which will not make it into
comp.sources.x since it isn't official)

wf08+@andrew.cmu.edu (William Frank) (03/17/90)

> Excerpts from netnews.comp.windows.x: 16-Mar-90 Re: Xw on Sparc? Xaw vs
> Xw .. Mark Moraes@cs.toronto.e (4816)

> >(3) After getting the version of Xw from the contrib section of the
> X11R4
> >release tape and compiling it, I was disappointed to see that it's not
> the 3-D
> >version that's used in Young's book (3-D as in buttons looking slightly
> raised,
> >text input boxes slightly sunken, etc.). Can this be got?

> Not easily, no.  If you happen to have a pre-R3 copy around (the one
> that was on expo.lcs.mit.edu for a while before the R3 release), that
> had the 3d look.  It got taken out possibly because of the look and
> feel litigation, or perhaps because HP just wanted to keep the spiffy
> looks for their product release only.  Since I personally don't see
> why 3d is so desirable, I didn't care much.  It's probably feasible to
> put it back in (I remember taking the 3d stuff out of the button code
> to try and get xpic to start in finite time -- on the R3 Xsun, drawing
> the 3d stuff was agonizingly slow)


The widget set with the 3d look was turned into a the X Common Interface
by HP; the book states that the examples were compiled using this.  I
believe that they are source compatible.  The 3d look is also
incorporated into Motif.

> Excerpts from netnews.comp.windows.x: 16-Mar-90 Re: Xw on Sparc? Xaw vs
> Xw .. Mark Moraes@cs.toronto.e (4816)

Doug Young's book is now out in a Motif version.

And it's very cool.


-will frank
wgf@cs.cmu.edu

hvr@kimba.Sun.COM (Heather Rose) (03/19/90)

In article <90Mar16.165337est.242@smoke.cs.toronto.edu> moraes@cs.toronto.edu (Mark Moraes) writes:
>jorice@swift.cs.tcd.ie writes:
>
>>(4) On the subject of XView, how is it to program? I'm wary of it because I
>>found programming in SunView needlessly difficult and I think that SunView
>>applications look really clutzy. How much better is XView? How much disk space
>>does it take up when compiled, roughly?
>
>XView seems considerably better than SunView in the programming
>interface -- it's got some of the Xt object-oriented approach.  But
>it's big.  Some of the code in the internals of the notifier looks as
>if it would be painful to port to a system without Berkeley style
>signals.  (We have one of those:-) Has anyone gotten XView running on
>non-Sun machines?
>
>One possibility for a small toolkit would be to use olgx, and bits of
>olwm for the spiffy 3D look.  olgx is fairly small.  Building a set of
>widgets with it, or retrofitting it onto Xw might be nice.
>
>Given the great response of the XView people to questions on the list,
>and to bug reports, it's might be a good alternative for those of us
>too broke to buy widget sets, or those of us that want source with few
>strings attached.  (Obviously, just like Xw, there's the possibility
>that at some point in the future, XView src may stop appearing in MIT
>X distributions)

XView runs on non-Sun machines: DecStation 3100 with Ultrix (with patch2), 
System 5 release 4 (with graphics update tape for AT&T source licensees), 
and more before the end of the year.  Sun is also folding back in the porting
work into the main XView source which will be donated back to MIT.

olgx is not really a toolkit, but you're free to use it as you like.
The legal issues are outlined in the Copyright file.

I do not see Sun discontinuing donating XView source to MIT.  We will be
making another source donation of XView this summer.

__________________________________________________________________
Heather Rose
Window Systems Group                      internet:  hrose@sun.com
Sun Microsystems, Inc.                        uucp:  ...!sun!hrose

bcripe@hpcvlx.cv.hp.com (Brian E. Cripe) (03/20/90)

> (I'm told Xw sort of evolved into Motif, which could
> explain why Xw isn't supported any longer.  Or maybe HP just got tired
> of giving away their work) It's unfortunate - many of us hoped it
> would become the standard widget set when it came out; technically it
> is really nice.

HP proposed Xw (a.k.a. CXI) to OSF.  OSF chose a mix of Xw and DEC
widgets and called it Motif.  They awarded the developement of Motif
to HP, so the programming team that developed Xw switched all of their
efforts to developing Motif.

Xw is now pretty dead.  I would definitely recommend developing new
applications on Motif instead of Xw.

	Brian Cripe
	bcripe@cv.hp.com

P.S. The source of my information is that I sit across the aisle from
the Motif development team.

hvr@kimba.Sun.COM (Heather Rose) (03/20/90)

In article <3044@bacchus.dec.com> klee@decwrl.dec.com writes:
>In article <6873.25ff8b27@swift.cs.tcd.ie>, jorice@swift.cs.tcd.ie writes:
>
>> (4) On the subject of XView, how is it to program? 
>
>The semantics of XView are similar to those of the X Toolkit.  There
>are some advantages to XView, such as more UNIX-specific support.
>Disadvantages of XView are incompatibility with X Toolkit widgets, no
>subclassing, no separation between "intrinsics" and "widgets", and no
>support for popular X Toolkit user interfaces such as configuration
>through translation management and resource management.  Also, some
>customers are now requiring (to some degree) their purchases to be
>based on the X Toolkit (e.g., the recent U.S. Government FIPS).

It's encouraging to see Digital has taken such an interest in XView.

First, XView has semantics similar to SunView which predates the X
Toolkit.  Both Xt and SunView are based upon some research done in 
the late 1970's.  The net result of differences between Xt Intrinsics 
and XView intrinsics is very close; however, the chosen implementations 
of those semantics differ in substantial ways.  Sun seriously considered
moving XView to Xt Intrinsics; however, too many problems as far as loss
of functionality and implementation details.

Second, what one considers advantages to XView depends on a person's needs
and past experience.  Here are some that we consider advantages:  more 
UNIX specific support, extensible (more easily than Xt if you look over
the tutorial slides on the subject), familiar API for SunView programmers,
source is free, potentially large platform base (Sun ships 1/3 of all 
workstations in the world), will be provided for IBM, DEC, and H-P 
platforms as well, supported by a vendor using it as primary applications 
delivery platform, spot help facility.

Third, if a Sun customer truly needs an Xt solution, we offer Xt+ with the
release this summer.  XView meets a different class of needs than Xt+ 
(e.g.  the quickest way to port from SunView to X11).  Also, extensibility 
in any toolkit is useful, but in many fewer cases than one would have 
you believe i.e. most toolkit users just want to get their work done 
without having to become toolkit or window system experts.  The ability 
to add a new class is useful for certain cases, so XView provides this 
functionality.  It's not fully documented yet, but we are addressing 
this point.  There's slides from a tutorial one can ftp from expo, or 
send the message, 

	send doc tutorial.extensions.ps
to
	xvstuff@kimba.eng.sun.com

Fourth, the statement about extensibility is false.  XView is extensible in
the same way Xt is extensible.  They both are extensible when the application
is compiled.  Neither Xt nor XView allow subclassing while the program is
running.  That's difficult to do in C.

Fifth, the statement about separation of intrinsics is also false.  XView has 
intrinsics, we've just never given them the publicity that Xt Intrinsics enjoy.
Most application programmers want to use some user-interface toolkit to
provide a useful set of objects, or better yet some GUIDE tool which
interfaces to the user interface toolkit.

The XView intrinsics are stable and mature.  The notifier library, a major 
portion of XView intrinsics, has been stable since the mid 1980's.  XView 
objects are as opaque as is possible from C, and has had the same basic 
functions to manipulate these objects for all releases (going on it's 
third release this summer).

Both Xt and XView provide a true object model, as close as one can get in
C with very similar methods for subclassing.  However, neither one 
incorporates the runtime object creation one has in say SmallTalk.

Sixth, configuration through translation management is not as complete
as that in Xt.  Certain packages implement some schemes (i.e. .textswrc
or .ttyswrc), but the concept is not included in the XView intrinsics.
This is a very good point for a request for enhancement (RFE) to add to
a future release.  Thanks for pointing that out.  

Seventh, XView does not provide a nice wrapper on the X11 resources
(yet); however, an application programmer can use the X11 resources as
much as they like.  XView does not prevent their use.  The ideas behind
user preferences are a different approach in OPEN LOOK.  OPEN LOOK
specifies that every application should have a property sheet to
present configuration options to the end user.  The application may
choose to implement the configuration options via the X11 resources or
a separate file, or another database which may apply to more than just the
window system. 

Also, OPEN LOOK specifies a much more consistent look and feel across
different applications to make life much easier on the end user.  The
objective of OPEN LOOK is to make UNIX as easy to use as a Mac, since
UNIX has not been available to the majority of computer users.  XView
incorporates many dynamically customizable things such as setting the
default menu choice with Control-SELECT, pinning menus, pinning popup
frames, and menus are either stay-up or not depending upon usage.

XView does lack a large set of toolkit defaults (for example, all scrollbars
should be on the left instead of the right, or all TTYSW should have this
font, foobar), but we're working on these issues.  The extent that Xt goes
to to define defaults is a bit of overkill, and would be a performance hit 
to add to XView. The current interfaces to resource changes in Xt based
toolkits requires that the end user know something about the implementation 
of the toolkit.  Sun does not think it's reasonable to expect all UNIX 
users to edit some bizarre dot file to specify these things.  The 
environment should present options to the end user in a very obvious way 
via property sheets.  The best way to add resources to XView would be an
automatic property sheet generator for a package.  Whether the properties
mechanism uses the X resource database is an implementation detail.  The
end user only cares about provided functionality.  The programmer cares
about ease of adding that functionality.

Given those last two points, I think it's fair to say XView is currently
less customizable than Xt.  However, it is something we can and most likely
will do something about in future releases within the guidelines provided
by OPEN LOOK.

Eighth, what the FIPS states is that for a hardware company to participate
in the bidding process for government contracts, they must include an Xt
based toolkit in their offering.  Sun will be supplying Xt+ as part of their
window offering just as we include Ada as part of our language offering. 
The government requirements specify many things, like one must
use the Ada programming language.  This has not stopped C from becoming 
the most widely used programming language.


__________________________________________________________________
Heather Rose
Window Systems Group                      internet:  hrose@sun.com
Sun Microsystems, Inc.                        uucp:  ...!sun!hrose

mccoy@ils.nwu.edu (Jim McCoy) (03/20/90)

In article <100920199@hpcvlx.cv.hp.com>, bcripe@hpcvlx.cv.hp.com (Brian
E. Cripe) writes:
> > (I'm told Xw sort of evolved into Motif, which could
> > explain why Xw isn't supported any longer.  Or maybe HP just got tired
> > of giving away their work) It's unfortunate - many of us hoped it
> > would become the standard widget set when it came out; technically it
> > is really nice.
> [Xaw and some DEC widgets became Motif under OSF (what a name!) and
>  HP dropped Xw]
> 
> Xw is now pretty dead.  I would definitely recommend developing new
> applications on Motif instead of Xw.

Sounds like a good idea.  Do you wnat to send me the source for the
libraries and widgets?  Oh, they cost money?  Well, I guess I will
stick with the stuff available and work on making it better.


jim

------------------------------< Jim McCoy >------------------------------------
mccoy@acns.nwu.edu                  |  "...far too many notes for my taste"
#include <disclaimer.h>             |        -Phantom of the Opera
-----------------------<"To thine own self be true">--------------------------

denio@beno.CSS.GOV (Dennis O'Neill) (03/20/90)

In article <3044@bacchus.dec.com> klee@decwrl.dec.com writes:
>
> Xw is nice, but it doesn't work with X11R4.  I believe that the version
> on the X11R4 tape is not supported by anyone officially or
> unofficially.  HP is now shipping Motif with its hardware.

Xw as distributed with x11r4 has worked fine for me.

Dennis O'Neill

thp@westhawk.UUCP ("Timothy H Panton.") (03/21/90)

I didn't see the origional message, assuming the question was 
"how can I get Xw for sparcs?"

It's difficult, the version on the R4 tape has a heap of bugs 
(mostly int vs Dimension) and causes pretty serious resource leaks at both
ends (client and server). 
This is only a problem for relatativly complex cleints, and I too would advise
against starting a new application with Xw.

I've fixed a good many of the bugs (those that were a problem for my clients).
It may be possible for me to contribute these changes to the net (I'll have to
check with "those who pay" ). 

Tim.
+----------------------------------------------------------------------------+
|Tim Panton, Westhawk Ltd.    "... avoiding vague and profane babblings"     |
|Phone: +44 92822574           	                             1 Timothy 6:20  |
|uucp : ..!mcvax!ukc!westhawk!thp                                            |
|Paper: Westhawk Ltd. 26 Rydal Grove, Helsby, Cheshire, WA6 OET. UK.         |
+----------------------------------------------------------------------------+