argv%turnpike@Sun.COM (Dan Heller) (02/23/90)
this message attempts to answer a general question rather than the person's specific questions. however, I do reference his message for clarity. In article <22697@mimsy.umd.edu> folta@tove.umd.edu (Wayne Folta) writes: > At work, we have to make a decision as to which way to go: move our > Sun 3 SunView operations to xnews and XView, or move to X11R4 and use > other toolkits. They are not mutually exclusive -- you can run XView on X11R4 as well as R3. You don't need xnews, but you probably shouldn't attempt XView without an Open Look window manager. If you are having problems getting XView running under R4, there are solutions -- followup in a separate article. > Questions: > 1. Is it really advantageous to stay with Sun on the move to X or > is MIT's X11R4 generic tape a viable option? (e.g. is the fact that > Open Windows is supported by Sun a big advantage over the more generic > X11R4?) This is strictly my humble opinion -- If you are a sun user and are planning on using lots of Sun-provided products, then I recommend you stick with xnews because of the support for the postscript apps. They are nice, convenient, *written*, and interact well in your general user environment. xnews doesn't have to use be used, but you don't lose anything by using it. With respect to R4 -- yes, it's faster and nicer than R3, but it is the common denominator, so to speak --you're not going to get anything from R4 that xnews won't give you. Which you use depends on your application. If you are going to sell xnews specific software, then there's your answer, but if you are going to develop generic X applications, then you can choose one or the other without it affecting the outcome of your program. > 2. Do most toolkits (other than XView) allow mixing and matching > among themselves are they mostly exclusive? (I am thinking particularly > of Xcu.) You should never mix and match toolkits. At least well written ones. You see, a toolkit is supposed to implement a particular "look and feel". If you mix in elements from other toolkits, you will break that look and feel paradigm and potentially confuse the user. You can mix Xt-based toolkits only because they all depend on Xt to act as the base layer for widget creation and manipulation. That doesn't mean they were intended to be merged. You should *choose an interface* and then go with the toolkit that supports it. Or even better yet, you should develop your applications such that multiple toolkits could be integrated in easily. In other words, a well designed application should allow you to plug in a Motif module or a Open Look module or an XCu toolkit module without having to change the baseline design of the product. For example, you shoul.d call higher level functions like: InitToolkit(&argc, argv); CreateTopLevelWindows(); MainLoop(); This portion of the code shoud never change. However, if you're going to use XView, then the "XView module" should have the function InitToolkit(argc, argv) int *argc; char *argv[]; { xv_init(XV_INIT_ARGC_PTR_ARGV, &argc, argv, NULL); } whereas the XCu or other Xt-based toolkits would have a module that looked like: InitToolkit(argc, argv) int *argc; char *argv[]; { top_level = XtInitialize(argv[0], argv[0], options, XtNumber(options), &argc, argv); } Of course, this is somewhat trickier than it looks, but at least if you attempt to -design- your software openmindedly, then your life will be much nicer when you suddenly get a new client that wants your software to run under the "foobar" toolkit. the point is, all "toolkits" have certain fundamental elements that are predictable -- there are going to be scrollbars, pushbuttons, menus, labels, and callback routines. And all applications have certain properties to them -- they have command line arguments (resources of some kind), require some sort of IO with the usert( and have to "compute" something. Make as much effort as necessary to separate all these fundamental building blocks of an application so you can modify any one particular part of it without affecting the other parts. > 3. Do most toolkits (other than XView) have an object-orientation with > inheritence? Xt does as well as any others I've seen. > 4. Will a mixture (Sun's server, other people's X11R4 toolkits) be possible now > or in the near future? Possible now.. dan ----------------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com 632 Petaluma Ave, Sebastopol, CA 95472 800-338-NUTS, in CA: 800-533-NUTS, FAX 707-829-0104
mike@BACH.CS.BYU.EDU (Mike Burbidge) (02/24/90)
XView is not very object-oriented. It is simply a static set of objects for building user interfaces. It does not support inheritance. If there is not an object in the toolkit that does what you want, you build one from scratch. You can put XView objects together in a statically prescribed manner, but very often in real world applications that is not what you want to do. Mike Burbidge. mike@cs.byu.edu
argv%turnpike@Sun.COM (Dan Heller) (02/25/90)
In article <9002240235.AA10428@bach.cs.byu.edu> mike@BACH.CS.BYU.EDU (Mike Burbidge) writes: > XView is not very object-oriented. It is simply a static set of objects > for building user interfaces. It does not support inheritance. If there is not > an object in the toolkit that does what you want, you build one from scratch. > You can put XView objects together in a statically prescribed manner, but very > often in real world applications that is not what you want to do. I think you're confusing XView with SunView. What you said above is true of SunView, not XView. Xview's model is pretty much the same as the intrinsics (Xt). It uses static subclassing (C doesn't support dynamic subclassing as far as I know) and the inheritance methods are the same as Xt. For example, the "panel" package is subclassed from the "canvas" package. It's implementation clearly shows that it uses inheritance. dan ----------------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com 632 Petaluma Ave, Sebastopol, CA 95472 800-338-NUTS, in CA: 800-533-NUTS, FAX 707-829-0104
tomj@eng.sun.COM (Tom Jacobs) (02/27/90)
>From: mike@bach.cs.byu.edu (Mike Burbidge) >Subject: Toolkit decisions (was: XView v. other toolkits, advice wanted) > > XView is not very object-oriented. It is simply a static set of objects >for building user interfaces. It does not support inheritance. If there is not >an object in the toolkit that does what you want, you build one from scratch. >You can put XView objects together in a statically prescribed manner, but very >often in real world applications that is not what you want to do. > >Mike Burbidge. >mike@cs.byu.edu Mike, the concept of a toolkit being object-oriented is not strictly limited to Smalltalk-style environments. XView is an object-oriented system with static subclassing. This simply means that the heirarchy of classes need to be defined at compile time (the same is true of the X Intrinsics). Additionally, all XView objects are "opaque" and do not expose the internal representation/implementation of the objects. XView objects have their contents/values retrieved/set using attributes (used as "messages") with generic functions [xv_get() and xv_set()] while other generic functions are used to instantiate/destroy all objects [xv_create() and xv_destroy()]. Your comments about creating new objects are misleading. Existing objects are easily changed within the scope of their attributes. Features/changes outside this scope do require building your own, but since XView source is widely available and freely distributed, having to "build one from scratch" is more clearly described as "clone one from existing code". It is also our stated policy to "take back" such additions into mainline XView source (where the this is reasonable for the general user community and the programmer is amicable with his/her changes). Tom Jacobs ARPA: tomj@eng.sun.COM Window Systems Group UUCP: sun!tomj Sun Microsystems, Inc.
chan@hpfcmgw.HP.COM (Chan Benson) (02/28/90)
> Our group decided to use either Xview or InterViews for the main > reason is that they are entirely in public domain > and run well on most types of computers. > First, history shows that public domain packages, UNIX (early AT&T, GNU), C++ (GNU), > and X Windows win out over their possibility superior competitors > (VMS, Objective C, NeWS) because academic hackers evolve them and write > useful applications for them. Be careful with the way you use the term "Public Domain". Hell, Unix isn't even *free*, let alone public domain. To my knowledge, none of the software mentioned above is public domain. -- Chan
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (02/28/90)
In article <9002261946.AA00365@snowking.Eng.Sun.COM> tomj@eng.sun.COM (Tom Jacobs) writes: >Mike, the concept of a toolkit being object-oriented is not strictly >limited to Smalltalk-style environments. XView is an object-oriented >system with static subclassing. This simply means that the heirarchy >of classes need to be defined at compile time (the same is true of the X >Intrinsics). This is probably drifting off the original topic (what was it anyways?)... Since we're talking about using OOP with Xt and/or Xview, I thougt I'd throw this in: WINTERP uses XLISP's OOP extension to allow the instantiable Motif widgets to be subclassed "dynamically". XLISP's OOP extension is somewhat smalltalk-like. WINTERP uses the C-implemented Motif widgets but makes them look like XLISP objects, which can be subclassed. You can also add and/or override "methods" on widget classes (for example, adding a :FIND-FILE method to the XM_TEXT_WIDGET_CLASS)... Here's a trivially simple example of using a subclassed widget in WINTERP in order to simplify the use of a "radio box" selection mechanism: ; -*-Lisp-*- ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ; File: radiobox2.lsp ; RCS: $Header: radiobox2.lsp,v 1.1 89/11/25 04:00:36 mayer Exp $ ; Description: A better (?) way of creating a radio box, using subclassing of ; togglebutton. Note that this version doesn't waste as much ; memory as radiobox1.lsp because it defines a single ; entry-callback on the rowcolumn widget instead of forcing each ; toggle-button to have separate copies of very similar ; callback-closures. Just load this file to see the example. ; Author: Niels Mayer, HPLabs ; Created: Sat Nov 25 01:24:00 1989 ; Modified: Sat Nov 25 01:26:42 1989 (Niels Mayer) mayer@hplnpm ; Language: Lisp ; Package: N/A ; Status: X11r4 contrib tape release ; ; (c) Copyright 1989, Hewlett-Packard Company. ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (setq toplevel_w (send TOP_LEVEL_SHELL_WIDGET_CLASS :new :XMN_GEOMETRY "500x500+1+1" :XMN_TITLE "Radio-Box-Test #2" :XMN_ICON_NAME "Radio-Box-Test #2" )) (setq rowcol_w (send XM_ROW_COLUMN_WIDGET_CLASS :new :managed :radio_box "rc" toplevel_w )) (send toplevel_w :realize) (send rowcol_w :set_callback :xmn_entry_callback '(CALLBACK_ENTRY_WIDGET CALLBACK_ENTRY_SET) '( (if CALLBACK_ENTRY_SET (send CALLBACK_ENTRY_WIDGET :print-which-button) ) )) ;; make a subclass of XM_TOGGLE_BUTTON_GADGET_CLASS (setq My_Toggle_Button (send Class :new '(button_name) ;a new ivar for this subclass '() ;no class variables for subclass XM_TOGGLE_BUTTON_GADGET_CLASS)) ;; override XM_TOGGLE_BUTTON_GADGET_CLASS's instance initializer (send My_Toggle_Button :answer :isnew '(name &rest args) '( (setq button_name name) (apply 'send-super `(:isnew ,@args :xmn_label_string ,name)) )) ;; add a method that prints which button (send My_Toggle_Button :answer :print-which-button '() '( (format T "option ~A selected\n" button_name) )) ;; put up 20 toggle buttons inside the radio-box/row-column manager (do* (;; local vars (i 0 (1+ i)) ) (;; test and return (eql i 20) ) ;; body (send My_Toggle_Button :new (format nil "Button ~A" i) :managed rowcol_w) ) ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *