beau1029@mstr.hgc.edu (donald beaudry) (05/26/91)
Neuron Data has recently released an interface builder for Motif, Open Look, MS Windows, OS/2 PM, and Macintosh. They claim that you get the superset of all "widgets" on all platforms. I have seen a demo and it is most impressive. Wait - it gets better... You also get every look and feel on every platform! With the click of a button, your Open Look application running on a Sun will redraw itself to look like it is running on a Mac. You can get MS Windows look and feel under X, or on the Mac. The quality of the widget set is impressive. They have created a virtual graphics machine that runs on all platforms. Using this VGM, they developed their own widget set formed from the superset of all widgets on all the aforementioned platforms. That means that you get tear-aways and modeless menus under Motif, a multi-column list that looks very impressive, etc. Instead of relying on Xt and Widget sets, the VGM relies solely on Xlib on X platforms, and draws its own interface components on other platforms. This was very noticable on the Mac, running 6xx Mac OS. The application built with Open Interface had the System 7 3-d buttons. And with a click, the application redrew itself on the Mac with a Windows 3 look. This product seems like a cure-all, perhaps too good to be true, but from what I have seen, it appears to be real. I have only seen the product roll out so far. Has anyone used this product? Impressions?
rdthomps@vela.acs.oakland.edu (Robert D. Thompson) (05/27/91)
In article <1991May26.044051.5284@mstr.hgc.edu> beau1029@mstr.hgc.edu (donald beaudry) writes: >Neuron Data has recently released an interface builder for Motif, Open Look, >MS Windows, OS/2 PM, and Macintosh. They claim that you get the superset >of all "widgets" on all platforms. I have seen a demo and it is most >impressive. Wait - it gets better... > [ stuff deleted ] But, is the "interface builder" an extension of Nexpert Object? In other words, what does it provide to say, C++ developers? There are a lot of tools coming out that are very impressive, but do not answer issues of speed, efficiency, and integration. For instance, Object/1 (which I have) is a very rich environment with a lot of tools for comprehensive development and automatic class generation from dialogs. BUT IT WOULD BE AN UNDERSTATEMENT TO CALL THIS ENVIRONMENT SLOW!!! I have to be fair to mdbs, and say that they targeted the product for corporate MIS, where high-end desktop systems are prevalent - I mean 486's of course (Object/1 is still v-e-r-y s-l-o-w on my 386/20 with 4MB RAM and a 22msec 70MB disk). Anyway, I would appreciate more information on what development area the product is related to - i.e. what does it create - C++ classes, C source code, or some interpreted pseudo-language??? Thanks...Regards |(8> --- Robert rdthomps@vela.acs.oakland.edu
beau1029@mstr.hgc.edu (donald beaudry) (05/28/91)
In article <6592@vela.acs.oakland.edu> rdthomps@vela.acs.oakland.edu (Robert D. Thompson) writes: > > But, is the "interface builder" an extension of Nexpert Object? > No. Open Interface was created to ease the port of Nexpert from its original platform (Mac) to multple platform. It is a completely separate animal. You do get several interesting browser widgets developed for the Nexpert interface. > > In other words, what does it provide to say, C++ developers? > Open Interface produces ASCII resource files which can be compiled on a per-platform basis to speed things up at startup. It also produces a C template which contains the calls used to build an application or dialog box (or whatever), and callback stubs, and a makefile. > > There are a lot of tools coming out that are very impressive, > but do not answer issues of speed, efficiency, and integration. > Open Interface is incompatible with Xt and anything based on Xt like Motif or OpenLook libraries. It uses its own event management scheme, providing the same set of events under all supported windowing systems. I am looking for performance info on Open Interface-based applications under MAC OS, OS/2 and Windows 3. Under X, performance should be significantly improved due to the "X-windowless" nature of the archictecture. A single X window is created for the application. (I would guess that each dialog box would also get an X window...). All "widgets" (not to be confused with Xt-based widgets) are drawn on that X window. Sounds like Xt gadgets. Neuron Data claims that unused widgets can be "stubbed out" to reduce the size of the executable. They claim that performance on Mac and PCs is comparable to the native toolkits, and that X performance is better than Xt-based toolkits. > Anyway, I would appreciate more information on what development > area the product is related to - i.e. what does it create - > C++ classes, C source code, or some interpreted > pseudo-language??? It is supposed to produce C - they said that C++ was preferable, but is not fully available on all the platforms they want to support. You can choose ANSI C (they strongly recommend this for portability reasons) or K&R. And, you can customize the code generator - come to think of it, I think they mentioned that you can make this thing produce FORTRAN. So you probably can get it to produce C++.
raney@yertle.Colorado.EDU (Scott Raney) (05/30/91)
Read the fine print. Open Interface costs $12,000 for the development system and from $200-$500 per copy. It doesn't look quite so appealing anymore, does it? -- ====================================================================== Scott Raney No other person or organization raney@boulder.colorado.edu can be held responsible for my (303)499-9855 opinions or actions
jfr@locus.com (Jon Rosen) (05/30/91)
In article <1991May26.044051.5284@mstr.hgc.edu> beau1029@mstr.hgc.edu (donald beaudry) writes: >Neuron Data has recently released an interface builder for Motif, Open Look, >MS Windows, OS/2 PM, and Macintosh. They claim that you get the superset >of all "widgets" on all platforms. I have seen a demo and it is most >impressive. Wait - it gets better... >You also get every look and feel on every platform! With the click of >a button, your Open Look application running on a Sun will redraw itself >to look like it is running on a Mac. You can get MS Windows look and feel >under X, or on the Mac. >The quality of the widget set is impressive. They have created a >virtual graphics machine that runs on all platforms. Using this VGM, >they developed their own widget set formed from the superset of all >widgets on all the aforementioned platforms. That means that you get >tear-aways and modeless menus under Motif, a multi-column list that >looks very impressive, etc. Instead of relying on Xt and Widget sets, >the VGM relies solely on Xlib on X platforms, and draws its own interface >components on other platforms. Some interesting questions about Neuron (for anyone who knows)... Does it have compatible graphic primitives available in all environments? Does it simulate those that are available in some but not others? What about fonts? The Mac, Windows and X font management is pretty dissimilar... Resizing fonts is easily available on the Mac whereas it is essentially nonexistent on X (you HAVE to have the exact font bit maps available for each size you want or you have to do your own font resizing like Framemaker does)... Are Neuron widgets easier to build than Motif or Xt widgets? Is there an extended text manager like on the Mac that supports tabs, font changes, highlighting, etc? On the other hand, have they added the Form widget functionality into the Mac and Windows environments? This is one of the best features of X/Motif going... Jon Rosen
jfr@locus.com (Jon Rosen) (05/30/91)
In article <1991May29.175544.19397@colorado.edu> raney@yertle.Colorado.EDU (Scott Raney) writes: >Read the fine print. Open Interface costs $12,000 for the development >system and from $200-$500 per copy. It doesn't look quite so >appealing anymore, does it? If this means that you need to spend $200-$500 dollars for each workstation on which you RUN an Open Interface product, this is prohibitive (IMHO)... However if it is just the cost for development versions, it ain't bad... If you get royalty free code and no need for a run-time, the initial cost of the development system isn't that bad... Jon Rosen
marti@mint.inf.ethz.ch (Robert Marti) (05/30/91)
In article <1991May29.175544.19397@colorado.edu> raney@yertle.Colorado.EDU (Scott Raney) writes: >Read the fine print. Open Interface costs $12,000 for the development >system and from $200-$500 per copy. It doesn't look quite so >appealing anymore, does it? No surprises there if you know Neuron Data's pricing for their Nexpert Object expert system shell: reasonable product, but way too expensive, IMHO. Robert Marti | Phone: +41 1 254 72 60 Institut fur Informationssysteme | FAX: +41 1 262 39 73 ETH-Zentrum | E-Mail: marti@inf.ethz.ch CH-8092 Zurich, Switzerland |
wbrand@krishna.shearson.com (Willy Brandsdorfer) (05/31/91)
Neuron Data's OIT is not completely ICCCM compliant. Although they say that they are working on it. ------------------------------------------------------------------------------ William Brandsdorfer | UUCP: !uunet!shearson.com!wbrand Lehman Brothers | ARPA: wbrand@shearson.com 388 Greenwich St. | Voice: (212) 464-3835 New York, N.Y. 10013 | Yell: "Hey Willy" -------------------------------------------------------------------------------
stripes@eng.umd.edu (Joshua Osborne) (06/18/91)
In article <1991May28.064919.16358@mstr.hgc.edu> beau1029@mstr.hgc.edu writes: [...] >I am looking for performance info on Open Interface-based applications >under MAC OS, OS/2 and Windows 3. Under X, performance should be >significantly improved due to the "X-windowless" nature of the archictecture. >A single X window is created for the application. (I would guess that >each dialog box would also get an X window...). All "widgets" (not >to be confused with Xt-based widgets) are drawn on that X window. Sounds >like Xt gadgets. So how do window-less objects make something faster? Less windows for the server to deal with, smaller working set, easyer to decide where events go. Bigger working set on the client side, larger working set, harder to decide what events go with what objects. What if you have objects that change look when the mouse rolls into them, or just change the mouse cursor? If objects had windows assoc'ed with them they could use Enter/Leave events (or just set the window cursor, and let the server do it all, no context switches there :-)). With no windows the only thing I can think of doing is asking X to tell you each time the mouse moves (or sit in a polling loop, which is worse). -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "CNN is the only nuclear capable news network..." - lbruck@eng.umd.edu (Lewis Bruck)
ed@visix.com (Ed Devinney) (06/18/91)
In article <1991Jun17.184618.10500@eng.umd.edu>, stripes@eng.umd.edu (Joshua Osborne) writes: |> So how do window-less objects make something faster? Less windows for the |> server to deal with, smaller working set, easyer to decide where events go. |> Bigger working set on the client side, larger working set, harder to decide |> what events go with what objects. This is all very true, but when discussing something like a multiplatform UI toolkit, one needs to keep in mind that nice pedagogical abstractions available in X (windows for minor objects, servers, etc) may not be available in all environments. Depending on your definition of efficiency, windowless objects can be way preferable, as they are much easier to implement on non-X systems, they probably carry less code-baggage around (unlike, say, Motif apps), and they may (or may not) run faster overall. |> What if you have objects that change look when the mouse rolls into them, or |> just change the mouse cursor? If objects had windows assoc'ed with them they |> could use Enter/Leave events (or just set the window cursor, [...] Again, while X may have nice abstractions for elegant problem solving, those abstractions do not exist on the majority of machines that people write for. I realize that this doesn't address your technical questions about windowless objects, but in the context of multiplatform development one must bow to some compromises ... and then create elegant mutliplatform solutions :-). -- ed devinney ed@visix.com Visix Software Inc., Reston, VA ...!uunet!visix!ed "Better to die on your feet than live on your knees" - Midnight Oil
toml@marvin.Solbourne.COM (Tom LaStrange) (06/18/91)
> So how do window-less objects make something faster? Less windows for the > server to deal with, smaller working set, easyer to decide where events go. > Bigger working set on the client side, larger working set, harder to decide > what events go with what objects. I can think of a couple things that I've encountered. What about creating a scrolling menu(list) with 1000 entries (which is not uncommon). If you used a sperate window for each menu item, it'll certainly take longer to create. If you have a popup menu with 50 items, each with it's own window, you would have to handle at least 50 expose events to paint the thing. If they're windowless, a simple intersection test tells you if you need to repaint a given item. You may consider menus a special case but the original twm code used a seperate window for each menu item because I thought that was the "right tool for the job" (haven't I heard that someplace before? :-) Windowless menu items make menus MUCH faster. In general, I agree that using windowed objects is much easier for the application writer / toolkit developer to deal with, but there are times when the baggage of a window is just too much to carry. -- Tom LaStrange toml@Solbourne.COM
aissing@blue15 (Gerrard Aissing) (06/19/91)
Hi! I am new to Mac programming. I try to use the Think-C TCL to create an application. At a certain point I want to use a dialog to enter some data. After closing the dialog, the program crashes in DoDeactivate(). There does not seem to be a Class for Modal dialogs in TCL, bu using the standard routines seems to couse a crash? So what should I do? Does anyone have experience in implementing a class for modal dialogs? Thanks. Gerrard Aissing (aissing@qtp.ufl.edu)