Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!maverick.ksu.ksu.edu!kuhub.cc.ukans.edu!wuarchive!csus.edu!ucdavis!csusac!unify!openlook!openlook-request Newsgroups: comp.windows.open-look Subject: Re: HELP! I need tool to make tools Message-ID: From: ** Sender Unknown ** Date: 13 Jun 91 17:17:01 GMT Sender: news@Unify.Com Lines: 57 > 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?