postmaster (Larry Poleshuck) (09/24/90)
There has been some discussion about X-builders and development environments
for Motif. I'd like to share some of my investigations and experiences.
I have studied various development platforms for X-Window development.
In my personal opinion the best is TeleUSE.
The features of TeleUSE that put it ahead of the others are:
1) It is more mature than any of the others. Many of them are still in
beta; we are currently on using the 1.1 of TeleUSE.
2) It lets you build re-usable pieces of your applications. These
are what they call templates -- sets of widgets which can be re-used.
(For example, we could build a set of templates which includes the
widgets required to display a specific type of data. This would consist of
all of the text and label widgets, as well as the callbacks for edit-checks.)
Templates can be copied into new screens with the click of a button and
then particular attributes can be over-riden. If a change to an
attribute of the original template is made, that change is
automatically carried forward to all inheritors of the template,
without affecting any of the specifically over-riden attributes.
This is feature is very useful for building large complex applications.
To my knowledge none of the other builders have it.
3) It will display your application as a hiearchy tree. This allows an
overall view of your entire application and gives the ability to make
changes either from the graphical view, or the tree view. I found this
to be a nice convenience for a simple test application -- it is
almost essential for a large, complex application. Again, none of the
other vendors have this feature yet (to my knowledge).
4) It has a dialog language that makes window development easier. The
dialog language is an X window specific language that requires much
less code to manipulate X widgets, compared with a C language/UIL
interface. For example, to get the value of an XmText string widget in
a C/UIL program requires four or five lines of code, but in the dialog
language requires a single expression.
Some people have mentioned the dialog language as one of the drawbacks to
TeleUSE. To me, it is one of its strengths. It is an object oriented language.
You can build your own types and define the methods using C code (which can
include embedded SQL or whatever file access you desire). You can
then use your data types in simple D lines of code. E.g.,
t : myType;
ui : wr; -- wr (widget rep) points to the top level shell
then
ui->myDialog.value := t.name;
-- the widget with name myDialog is found and the
-- XmNvalue attribute is set to the name attribute of
-- my user defined type.
Another e.g. To pop up a dialog box:
ui->myWindow->myHelpDialog.Unmanaged := false;
In practice, I think most of my complex applications will probably use
C and the TeleUSE run-time library because of the difficulty of accessing
my complex data types from D language. However, D is an excellant tool
for prototyping an application. When you've completed you prototype,
you can take the interface as is and add the necessary C code.
We are currently using TeleUSE to develop a medium sized user interface.
I will post more as I learn more about the pluses and minuses of this
product.
I would be interested to see other notes of this nature regarding
some of the alternatives.
Larry Poleshuck
Citibank
111 Wall Street
New York, NY 10043
Phone: 212-657-7709
Fax: 212-657-0068
E-Mail: uunet!ibism!lcp
--
Larry Poleshuck
Citibank
111 Wall Streetrlh2@ukc.ac.uk (Richard Hesketh) (09/28/90)
In article <1990Sep24.163032.3930@uunet!ibism!postmaster> lcp@uunet!ibism!postmaster (Larry Poleshuck) writes: >There has been some discussion about X-builders and development environments >for Motif. I'd like to share some of my investigations and experiences. >1) It is more mature than any of the others. Many of them are still in >beta; we are currently on using the 1.1 of TeleUSE. I'm probably jumping the gun on this one, but I am currently alpha testing my own UI Builder which has been designed to support any Xt Intrinsics based Widget Set. I intend making it freely available to anyone with ftp access sometime before the end of the year. Anyway, I have heard conflicting reports about TeleUSE but no specific technicalities. >2) It lets you build re-usable pieces of your applications. These >are what they call templates -- sets of widgets which can be re-used. >(For example, we could build a set of templates which includes the >widgets required to display a specific type of data. This would consist of >all of the text and label widgets, as well as the callbacks for edit-checks.) >Templates can be copied into new screens with the click of a button and >then particular attributes can be over-riden. If a change to an >attribute of the original template is made, that change is >automatically carried forward to all inheritors of the template, >without affecting any of the specifically over-riden attributes. >This is feature is very useful for building large complex applications. >To my knowledge none of the other builders have it. I believe Apollo/HP's Open Dialogue (which is more of a UIMS than a builder) has a similar concept to templates (infact they are also called templates). Its been around in various forms for about 5 (?) years. I use templates in my builder as well. The only difference between mine and TeleUSE appears to be the idea that if you change the original template all the copies are changed. My templates are infact just collections of Widgets instances that have had their attributes set to certain values. When a copy of a template object is made, you get a completely independent copy; changes to the original does not affect the copies. I find this useful for both object re-use and for use as "scratch" areas to perform prototyping experiments. >3) It will display your application as a hiearchy tree. This allows an >overall view of your entire application and gives the ability to make >changes either from the graphical view, or the tree view. I found this >to be a nice convenience for a simple test application -- it is >almost essential for a large, complex application. Again, none of the >other vendors have this feature yet (to my knowledge). I have this as well. The interface you are building is always on the screen and you can interact with it as well as edit it. There is no edit/run mode, just one interactive one 8-). There is a separate tree heirarchy (currently displayed as an indented list of names) which can be selected to edit objects or objects can be PICKed directly from the screen. >4) It has a dialog language that makes window development easier. The >dialog language is an X window specific language that requires much >less code to manipulate X widgets, compared with a C language/UIL >interface. For example, to get the value of an XmText string widget in >a C/UIL program requires four or five lines of code, but in the dialog >language requires a single expression. My builder does not support any programming constructs apart from editing translation tables and callback lists. It uses the Widget Creation Library to implement the created interface (the UI is generated as a Resource file and a some bootstrapping C code), therefore it generates very little traditional C code. The widgets can be manipulated using Wc actions and callbacks or in C directly from the widget id.s that are automatically created. I've toyed with the idea of incorporating a C interpreter to allow development of application specific callbacks and actions. This requires quite a bit of work though and I haven't the time. The UIMX builder incorporates a C interpreter I believe. Mine would certainly be better with some form of programming but I would like to incorporate a constraint language similar to the one used in Serpent. However the Xt Toolkit currently does not have the level of support for constrained objects that is really needed and I don't have the time to write it. This level would include all graphical objects; arcs, rectangles, filled polygons, lines, arrows. These objects would be constrained to each other using extremely simple mathematical or symbolic constraints. It would be up to the toolkit to enforce these constraints. Even without a specific interface language my builder can produce more than just static interface layouts. The Widget Creation Library includes a set of general actions and callbacks that can be used whilst developing the interface to implement typical dynamic behaviour. The interface to the builder was built mostly with itself, which seems to be a common test these days for builders. >Another e.g. To pop up a dialog box: > > ui->myWindow->myHelpDialog.Unmanaged := false; In Xt (and probably Xm 1.1) you only need one two lines of C code to extract a piece of data from an object: String text; XtVaGetValues(text_widget, XtNstring, &text, NULL); or one line to popup a dialog box: XtPopup(myHelpDialog, XtGrabNone); I don't know about UIL, I looked at it once, barfed and then went off and wrote an interactive UI Builder 8-). >Larry Poleshuck >Citibank >111 Wall Street My builder currently supports the Athena Widget Set, the 2-D HP Widget Set and my Widget Set. The only reason it does not yet support Motif is that I haven't got Motif yet. I hope that by the time it is publically released I will have folded the Motif Widgets into it. Richard Hesketh : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk : rlh2@ukc.ac.uk ..!mcsun!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 7620/3682
rlh2@ukc.ac.uk (Richard Hesketh) (09/28/90)
In article <5559@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh), I write: >My builder currently supports the Athena Widget Set, the 2-D HP Widget Set >and my Widget Set. The only reason it does not yet support Motif is that I >haven't got Motif yet. I hope that by the time it is publically released I >will have folded the Motif Widgets into it. Umm, maybe I ought to cover myself on this one. What I meant to say was I will fold in the *names* and widgetClass pointers of the Motif Widgets into the internal tables of my builder and I will then check with OSF so that I can then give away the source to my builder without it contravening any copyrights or licences. It will not require users of the builder to have anything more than the Motif libraries and header files. It does not generate any Motif code apart from declarations such as: #include <X11/Xm/Box.h> Now will OSF allow this? If not then it will be up to the installer of the builder to enter the one line per widgetClass into the builders internal table. Actually this seems a bit of a legal minefield which I would like to get a straight answer on. From the reading of the Motif licence agreement an acceptable Run-Time Copy (i.e. one that can be given away or sold without royalities to OSF) is one that does not generate any "object" part of the OSF/Motif (tm) User Environment. Comments? Richard Hesketh : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk : rlh2@ukc.ac.uk ..!mcsun!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 7620/3682