home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / windows / openloo / 4579 < prev    next >
Encoding:
Internet Message Format  |  1992-11-18  |  4.2 KB
  1. Path: sparky!uunet!olivea!gossip.pyramid.com!pyramid!unify!openlook!openlook-request
  2. From: fgreco@cfdev1026.shearson.com (Frank Greco)
  3. Newsgroups: comp.windows.open-look
  4. Subject: Re: Alternatives to Xt based toolkits? (Was: Re: SunSoft Windows Positioning)
  5. Message-ID: <rgjceyt@openlook.Unify.Com>
  6. Date: 18 Nov 92 15:50:57 GMT
  7. Sender: news@Unify.Com
  8. Lines: 83
  9.  
  10. > In article <1e0grvINNije@armory.centerline.com> matt@centerline.com (Matt Landau) writes:
  11. > :But on the brighter side, maybe this will get people to take a second
  12. > :look at other non-widget based toolkits.  There are a lot of good ideas
  13. > :out there, and a lot of interesting implementations.  Perhaps if the 
  14. > 
  15. > Okay, what are some of these alternatives that are viable - i.e. development
  16. > is continuing?  
  17.  
  18.     All of these handle *both* OPEN LOOK and Motif.  And all are
  19.     not Xt-based.
  20.  
  21.     ParcPlace's OI is a very nice and "pure" (as pure as pure can
  22.     be with Xlib) C++ toolkit.  Their Resource/GUI builder UIB
  23.     could use a human factors person (it's just not as easy to use
  24.     as Devguide 3.0), but you can add/subtract your own OI objects.
  25.     The Prentice-Hall OI (Gary Aiken) book helps tremendously.
  26.     No C interface, but not really that much of a problem since
  27.     most people are moving to C++ anyway.
  28.  
  29.     Visix Galaxy seems to be a nice alternative.  Company seems to
  30.     take usability and visual appeal seriously.  Abstracts more than
  31.     just GUI.  It's quite a big system with big goals (portability
  32.     among different hardware architectures and OS platforms) and
  33.     fairly expensive.  Seems to comform well to ICCCM unlike
  34.     similar products.  Their icon editor is super (can produce
  35.     usable color icons).  Resource editor a bit hard to use.
  36.     Has a C interface now, pure (ie, non-wrapper) C++ class library
  37.     is in beta.  The C interface is a bit on the awkward side;
  38.     LongHumongoFunctionCallNamesThatAreHardToRemember().  The C++
  39.     API is supposed to help significantly here.  Also has RPC,
  40.     filesystem, memory, etc... abstractions which you may like
  41.     or detest.
  42.  
  43.     Gain Technology (now owned by Sybase, btw) has interesting
  44.     Xlib-based multi-LnF toolkit that their multimedia product
  45.     uses.  Gave great demo at SPARCclassic/LX announcement.
  46.  
  47.  
  48.  
  49.     Of course, there's XVT and Aspect which also give you
  50.     multi-LnF, but they use the underlying Xt-based widget set.
  51.     Most people that I've talked to over the net, say that these do
  52.     not give you that fine degree of control, but for many in-house
  53.     applications they may be suitable enough.
  54.  
  55. > Another possibility is that someone (or ones...) may decide to take XView 
  56. > and slingshot, work out the legal situation with Sun after it is dropped,
  57. > and go on and DO the things that XView programmers have been waiting on
  58. > Sun to do.  Since it appears that the various new features that have
  59. > been mentioned in this group lately are not coming before the EOL perhaps
  60. > it is time for programmers to go ahead and write their own XView
  61. > extensions.
  62.  
  63.     In order to extend XView's life significantly, it must be
  64.     rewritten from scratch to use C++.  Having a wrapper around
  65.     XView (ie, UIT or XV++) will not extend XView into the future.
  66.     It may be useful now, but having a "pure" C++ class library
  67.     will be a necessary attribute of any GUI toolkit in the near
  68.     future.  You must be able to subclass low-level objects
  69.     directly in C++.  And... the varargs approach is not a welcome
  70.     programming model in the C++ household.
  71.  
  72.     Also the obtuse panel design borrowed from Sunview has to be
  73.     completely redesigned.  Scrollbar manipulation has got to be
  74.     improved.  Slingshots must be incorporated at the low-level
  75.     (why weren't Brian W's ideas folded more quickly into
  76.     base-level XView?  Internal politics perhaps?).  Fonts/colors
  77.     in panels, table package, incorporating multi-threading into
  78.     the notifier, etc...etc...
  79.  
  80.     Yes, maybe Larry has an idea.  Let another company take on
  81.     XView and extend it a bit (how about NeWS/TNT too?).
  82.     Unfortunately, if you look at the situation objectively (really
  83.     hard, since I honestly like XView btw), imho it will take too
  84.     much time/effort/money to keep it going.
  85.  
  86.     Besides, you don't have to be a genius to figure out that
  87.     SunLabs is probably working on a NeXTstep-like environment
  88.     judging from what Wayne Rosing was saying during the last
  89.     Sunergy satellite download.
  90.  
  91.     Frank G.
  92. =-=-=-=-=-=-=-=-=-=
  93.