dlou@ECE.UCSD.EDU (Dennis Lou) (06/09/91)
Is there a tool that helps me make tools by dragging and dropping? For instance, say I wanted to make a popup window with 3 buttons. I could code it all up in xview or OLIT (Xt), but if I had a tool to make tools, I could bring up a pallete of objects, create a window and drag and drop some buttons from this pallete to the window. In case you haven't guessed, I want something like Interface Builder on the NeXT or a little like (gack) Hypercard. -- Dennis Lou || "But Yossarian, what if everyone thought that way?" dlou@ucsd.edu || "Then I'd be crazy to think any other way!" [backbone]!ucsd!dlou |+==================================================== dlou@ucsd.BITNET |Steve Jobs and Steve Wozniak went to my high school.
naftaly@supergas.NoSubdomain.NoDomain (Naftaly Stramer) (06/10/91)
In article <9106090211.AA02424@kurosawa.ucsd.edu>, dlou@ECE.UCSD.EDU (Dennis Lou) writes: |> |> Is there a tool that helps me make tools by dragging and dropping? |> |> For instance, say I wanted to make a popup window with 3 buttons. |> I could code it all up in xview or OLIT (Xt), but if I had a tool |> to make tools, I could bring up a pallete of objects, create a window |> and drag and drop some buttons from this pallete to the window. |> |> In case you haven't guessed, I want something like Interface Builder |> on the NeXT or a little like (gack) Hypercard. |> |> -- |> Dennis Lou || "But Yossarian, what if everyone thought that way?" |> dlou@ucsd.edu || "Then I'd be crazy to think any other way!" |> [backbone]!ucsd!dlou |+==================================================== |> dlou@ucsd.BITNET |Steve Jobs and Steve Wozniak went to my high school. There is a program calles DEVGUIDE from Sun Microsystems that allow you to do that It is only $250. -- Naftaly Stramer (303)581-1477 DAZIX, An Intergraph Company Internet: naftaly@dazixco.ingr.com 6285 Lookout Road UUCP: ..uunet!ingr!dazixco!naftaly Boulder, CO 80301 Please excuse my english
openlook-request@openlook (06/11/91)
uunet!ECE.UCSD.EDU!dlou (Dennis Lou) writes: > Is there a tool that helps me make tools by dragging and dropping? For XView, on Suns you can get devGUIDE (I think they so spell it) pretty cheaply, which is about what it's worth. You can paint things and spit out C to be modified. This general way of working falls apart when you later want to modify the user interface after heavily modifying the original code templates. (Note I'm not saying GUIDE is any better or worse than the dozen or so other paint-the-screen-and-spit- out-a-template programs.) If GUIDE doesn't come with Open Windows, I think it is less than $300. Sun's support of OLIT doesn't extend to devGUIDE, even though there seems to be no technical reason. On the other hand, for [34]86 machines you can get Open Look Express from AT&T (Computer Systems Division, not Unix Software Laboratories). It's a version of UIMX for Open Look, which means you have a screen painter for widgets AND a C interpreter,` and can build a functional application directly from the tool (compiled or interpreted). On the other hand, it costs money. (This is the same program as HP's Interactive Architect, which is for Motif, naturally.) I don't know the current price, but at one time it was around $2000. If you create apps for others and your time and theirs is not free, it's worth it. Failing either of those, try Wcl, the Widget Creation Library (available from export.lcs.mit.edu or uunet). It adds a couple of converters to Xt (for String to widget class and String to Callback) and lets you specify the entire widget hierarchy and callbacks in the resource file. You need write NO widget creation code. Basically your chores are to write callbacks. Of course, you do have to understand resources. Once you know what you're doing, this approach may be faster to finished application than a painter, since you never merge with template code. An interactive developer partly based on Wcl is available, called Dirt (also on export). It needs some modification to work with OLIT.
fgreco@fis1026.govt.shearson.com (Frank Greco) (06/13/91)
> uunet!ECE.UCSD.EDU!dlou (Dennis Lou) writes: > > Is there a tool that helps me make tools by dragging and dropping? > > For XView, on Suns you can get devGUIDE (I think they so spell it) > pretty cheaply, which is about what it's worth. You can paint things > and spit out C to be modified. This general way of working falls apart > when you later want to modify the user interface after heavily > modifying the original code templates. (Note I'm not saying GUIDE is Minor correction: devGUIDE does not produce C directly. It spits out a descriptive template in what is called GIL format (Graphical Intermediate Language). You postprocess this file with a source code generator to produce C or C++ or Lisp (or others) in any of several OPENLOOK toolkits. We all know about "gxv" that produces C/XView from a .G (GIL) file; Sun has made it no secret that they intend on producing other generators for OLIT and TNT. Also, at the last X Conference Sun tech folks described international versions of devGUIDE that were in the pipeline. > Sun's support of OLIT doesn't extend to devGUIDE, even though > there seems to be no technical reason. I wouldn't agree with the first phrase, but I would with the second. Frank G.
** Sender Unknown ** (06/14/91)
> uunet!fis1026.govt.shearson.com!fgreco (Frank Greco) > > uunet !erik!rbrown (Randy Brown): > > > uunet!ECE.UCSD.EDU!dlou (Dennis Lou) writes: > > > Is there a tool that helps me make tools by dragging and dropping? > > You can paint things > > and spit out C to be modified. This general way of working falls apart > > when you later want to modify the user interface after heavily > > modifying the original code templates. > > Minor correction: devGUIDE does not produce C directly. It > spits out a descriptive template in what is called GIL format > (Graphical Intermediate Language). You postprocess this file > with a source code generator to produce C or C++ or Lisp (or others) > in any of several OPENLOOK toolkits. You are right about the intermediate file, which I knew about but forgot. But change "spit out C" to "spit out source code after post-processing" and the weight of my original comment stands. Any scheme that requires modifying code templates leads into a swamp. The useful way to produce a file for OLIT is to post-process into a X resource file that includes the instance tree (parent-child relationships) and callback specifications. Then a few hundred lines of application-invariant code can interpret the resource file, given converters from String to widget class and from String to callback (which has to have an application-specific data table or know more about the format of object files than is good for it). With this approach, there is *NO* WIDGET CREATION CODE written for the application. The only application-specific routines needed for the GUI are the callbacks. As a matter of fact, an instance of this exists--it's called Wcl, the Widget Creation Library, and it's freely available from comp.sources.x and from export and other archive sites. It requires a very small amount of added code to understand the OLIT widget classes. The nut of Wcl, the part that interprets the new resources, creates the widget hierarchy, and sets the callback resources, is only about 1000 lines. The Wcl approach minimizes the impact of changes in the GUI layout on the semantics of the application. > We all know about "gxv" that > produces C/XView from a .G (GIL) file; Sun has made it no secret > that they intend on producing other generators for OLIT and TNT. > > Sun's support of OLIT doesn't extend to devGUIDE, even though > > there seems to be no technical reason. > > I wouldn't agree with the first phrase, but I would with the second. Well, you see, I was writing using verbs in the present tense:-) I actually have work to do, not strategic plans to make. Further, I HOPE that the post-processor for OLIT, when it arrives, will take account of the Xt resource mechanism, or even the concepts of Wcl, and be useful, instead of being so XView-centric as to do all GUI creation and value setting in procedural code. Is anyone at Sun listening?
sundvall@perrier.embnet.SE (Mats Sundvall) (06/14/91)
>and from export and other archive sites. It requires a very small >amount >of added code to understand the OLIT widget classes. I have got it. For OLIT! From a nice guy in the states! >The Wcl approach minimizes the impact of changes in the GUI layout on >the semantics of the application. I agree! >> We all know about "gxv" >that >> produces C/XView from a .G (GIL) file; Sun has made it no >secret >> that they intend on producing other generators for OLIT and >TNT. >> > Sun's support of OLIT doesn't extend to devGUIDE, even though >> > there seems to be no technical reason. >> >> I wouldn't agree with the first phrase, but I would with the >second. >Well, you see, I was writing using verbs in the present tense:-) I >actually have work to do, not strategic plans to make. >Further, I HOPE that the post-processor for OLIT, when it arrives, >will >take account of the Xt resource mechanism, or even the concepts of >Wcl, >and be useful, instead of being so XView-centric as to do all GUI >creation and value setting in procedural code. >Is anyone at Sun listening? Actually I talked to Sun Sweden about this a couple of weeks ago. Nothing was really in the pipelines that they knew about. But he should give me a contact in US to talk to. I have not got that name yet. The reason I called them was to get the spec for the next GIL version. As you have already realized, as well as me and probably a lot of others as well (sun?) it should be very easy to make a postprocessor that parses the GIL file and writes the resource code. But if I am going to do it I want to start with the latest GIL spec. But of course it would be much better if Sun did it. They are the pros :-> I am just a medical PhD :-< Mats Sundvall
harling@pictel.uucp (Dan Harling) (06/15/91)
In article <9106090211.AA02424@kurosawa.ucsd.edu> dlou@ECE.UCSD.EDU (Dennis Lou) writes: > >Is there a tool that helps me make tools by dragging and dropping? > >For instance, say I wanted to make a popup window with 3 buttons. >I could code it all up in xview or OLIT (Xt), but if I had a tool >to make tools, I could bring up a pallete of objects, create a window >and drag and drop some buttons from this pallete to the window. > >In case you haven't guessed, I want something like Interface Builder >on the NeXT or a little like (gack) Hypercard. It sounds like you're talking about 'guide,' which was (I believe) provided along with OpenWindows on our Sun SPARCStation network. It allows you to build your interface graphically, by dragging and dropping icons for various objects and controls. Each object has a properties window which allows you to specify various characteristics, including event handler and notifier functions. I don't know what system you are using, but if it is OpenWindows on a SPARC, they have exactly what you're looking for. >Dennis Lou ______________________________________________________________________ Daniel A. Harling PictureTel, Inc. Rockport, MA Peabody, MA Opinions expressed herein are not necessarily those of PictureTel, Inc.; they are MINE, ALL MINE! (So there.) ---- === ====
toone@looney.Corp.Sun.COM (Nolan Toone) (06/16/91)
Well, I am nobody official but let me clear up a few things. writes: > > uunet!ECE.UCSD.EDU!dlou (Dennis Lou) writes: > > Is there a tool that helps me make tools by dragging and dropping? > > and spit out C to be modified. This general way of working falls apart > when you later want to modify the user interface after heavily > modifying the original code templates. (Note I'm not saying GUIDE is > any better or worse than the dozen or so other paint-the-screen-and-spit- > out-a-template programs.) If GUIDE doesn't come with Open Windows, I > think it is less than $300. As mentioned in a previous followup Devguide produces a *.G file which gxv parses and creates a *_ui.c and *_stubs.c files (along with a couple of others). the *_ui.c file SHOULD NOT BE TOUCHED. The *_stubs.c file however is exactly that. It contains the calbacks(stubs) and the main routines that you do want to edit. Then when you want to change your interface you rerun guide then INSTEAD of useing gxv use gxv_merge (I am not sure if it is documented or supported but it work fine and I believe in the next release it will be built into gxv). gxv_merge redoes the files and merges your changes back into them. > > Sun's support of OLIT doesn't extend to devGUIDE, even though > there seems to be no technical reason. As for this issue . . . . . who knows what the future may hold. ;-) Nolan Toone
watson@spot.Eng.Sun.COM (Robert Watson) (06/27/91)
> Is anyone at Sun listening ?
As there seems to be some interest in the design of our new code
generators, our marketing dept. put togther this piece.
-bob watson
-manager Devguide
Dear developers:
tHE OpenWindows Developer's Guide (Devguide) 3.0 now has code generator
support for all the OPEN LOOK toolkits provided by OpenWindows.
The Xview code generators, gxv and gxv++, have both been enhanced to take
advantage of the enhancements to XView (i.e. internationalization).
In addition there are two new code generators, golit for the OPEN LOOK
Intrinsics Toolkit (OLIT), and gnt for the NeWS Toolkit (TNT).
Each code generator has been specifically designed to enhance the strengths
and design of the toolkits, and to address the needs of the specific developers.
Hence the output of each code generator is uniquely designed to best support
its specific toolkit. This white paper will highlight the design goal of each
of the code generators as well as specify issues to consider when using
each of the code generators.
GXV, GXV++
The Devguide gxv and gxv++ code generators are designed to generate C and
C++ compliant C code respectively for the XView toolkit. The generated
code is much like code a programmer would write, therefore it is very
readable. The generated code is not "machine generated", or in a
proprietary format that is difficult to decode and understand.
The files that are created contain user interface code as well as some
application specific code, such as the code found in the stubs.c file which
contains the XView main loop with the stub call back procedures.
Developers should only need to modify the stubs.c file to add their
application specific code. This file is maintained and updated whenever
the developer modifies the user interface and regenerates the code.
A code generator that generates real toolkit code for the application has
both advantages and disadvantages. One of the advantages is that
it generates real code that can be easily be read, modified and maintained.
In fact, developers who are unfamiliar with XView can easily take
the generated code to learn XView.
The disadvantage is that the code generator can generate voluminous
amounts of code. For example, gxv generates both executable code and
resource data that grows in proportion to the complexity of the user interface
implementation. In an application that contains a large or intricate user
interface, the ui.c file can contain thousands of lines of code. This code,
which is frequently only executed once during the user interface
intialization, takes a long while to compile and creates a very large
executable file. In addition the user interface is not easily separated
from the application so user interface modifications cannot be dynamically made.
Both gxv and gxv++ support the internationalization (I18N) features of XView,
producing code which allows the resulting application binary to be
localized. There are two flags which enable this feature:
-g causes "dgettext" wrappers to be placed around all strings associated
with the interface, allowing easy extraction of the text by the
"xgettext" utility. "xgettext" produces a portable object file
(.po file) that can be localized, compiled into a text database, and
supplied at runtime. The localized database string values will
override the string values in the binary code, presenting the
user with a localized version of the product.
-r Devguide, by default, uses an absolute layout scheme for all user
interface objects. This layout scheme can cause problems when the
localized strings are not the same length as the original text
strings (i.e. buttons can overlap). The developer can use
Devguide to relay out the user interface, using the new localized
text strings, and then set the -r flag to invoke the XView XV_USE_DB
wrapper around object attributes associated with object size and
positioning. These wrappers cause the application to check
the resource database file for object size and position information
when the localized application is run.
Note that Devguide provides a group layout features that eliminates the
need to use the -r flag. Group layout allows for relative layout at
runtime. The group layout is the preferred and recommonded method to
use for applications that will be localized.
GOLIT
The Devguide golit code generator for the OLIT toolkit was designed to
provide an OLIT programmer with a fast and efficient method to implement
a user interface with OLIT. Golit was not designed to teach novice programmers
how to program in OLIT. Instead of generating toolkit code, golit generates
data structures which define the user interface widget hierarchy and their
associated resources. A small runtime component enumerates this widget table
and instantiates the hierarchy when the application is intialized.
This particular approach has the following advantages and disadvantages:
1. The executeable code size is invariant with the complexity
of the user interface.
2. The description of a particular user interface object (widget)
is highly efficient relative to the equivalent hand written code
needed to create a similar specified object.
However the specification of some attributes in the user interface
cannot be customized externally from the X defaults because of the
relative priorities of resource application to objects during
instantiation.
3. The concise API to libgolit provides the developer with a very
simple to understand/use collection of functions that also enable
great flexibility in the manipulation and control of the instantiation
of user interface elements within the hierarchy.
4. The user interface is more easily separated from the application.
GNT
The Devguide gnt code generator for the TNT toolkit follows the model of
the gxv code generator for XView in that it generates toolkit code. TNT
and NeWS is an environment with a fairly steep initial learning curve.
Once that learning curve is topped, the benefits of the environment can
be fully utilized. Gnt assists in that learning curve. It not only
generates the user interface code, it also provides assistance to the
developer learning TNT and NeWS by providing example code. Gnt opens the
door to TNT and provides enhancements to the toolkit (i.e. internationalization
support and linking of controls).
The gnt design allows for the following advantages and disadvantages:
1. Gnt allows for flexibility in the client server split. Callbacks
can be defined as either client side or server (PostScript) only).
2. Gnt supports incremental downloading of windows to the server.
Using Devguide's project organization, gnt only downloads interface
files which contain open windows. When a new window is requested
gnt checks to see if the interface has been downloaded and if
required, downloads the interface (including all internationalization).
3. Gnt supports subclassing of OPEN LOOK objects. To replace a
menu with a pie shaped menu, turn on subclassing, define the
pie shaped menu subclass, and gnt automatically utilizes the new
subclass.
4. Gnt assists the developer by minimizing the modifications which
have to be made when the interface changes. The user interface
which is downloaded to the server consists of three separate files,
of which only one is changed when the interface is modified. The
other two files define subclassing and initialization routines
and therefore do not need to be changed.
5. Gnt provides control areas in "border bags" which allow text or
graphics panes to resize both vertically and horizontally.
6. Gnt computes the layout of control objects so that the objects
can move logically upon resize of the window. This scheme
also allows for string substitution for easy
internationalization/localization.
For more technical information on each of the code genertors please refer
to the OpenWindows Developer's Guide 3.0 User's Guide and the appendices for
each of the toolkit code generators that is included with the beta software.warsaw@nlm.nih.gov (Barry A. Warsaw) (06/28/91)
>>>>> "Robert" == Robert Watson <watson@spot.Eng.Sun.COM> writes:
Robert> tHE OpenWindows Developer's Guide (Devguide) 3.0 now has
Robert> code generator support for all the OPEN LOOK toolkits
Robert> provided by OpenWindows.
Was Devguide 2.x ever released? If so, I better talk to my
maintenance person because version 1.1 is the latest version that
*I've* seen here.
-Barry