dwallach@nas.nasa.gov (Dan Wallach) (06/21/91)
I'm curious if anybody can complete this picture for me. If you do a strings on one of those SGI programs with all the cute buttons (like vadmin) you see lots of things like "tkButton", "tkObject", etc. There are also things in there like "tkButton.c++". One might assume that SGI's user interface thing is written in C++ and called tk. Is this available externally? Next, if you look at Forms (the excellent public domain user interface system by Mark Overmars), you see a suprising similarity between Forms and some of these SGI programs, although the shadows on the 3-D buttons are different... Now, Overmars has told me "Almost certainly Silicon Graphics is going to supply the Forms Library as part of their developers package. This means some sort of support for the future." When can I expect to see such a thing from SGI itself? There weren't any Forms on our Cypress Alpha 182 compact disk. Essentially, we're trying to decide what user interface to use on a number of future projects, here, and Forms would be a favorite, if it were supported by SGI. (Nobody wants to mess with supporting Panel-lib any more...) I assume I'm not the only person curious for the answer, so I'm posting the question, here. Curiously yours, Dan Wallach dwallach@nas.nasa.gov
Dan Karron@UCBVAX.BERKELEY.EDU (06/22/91)
>Organization: NAS Program, NASA Ames Research Center, Moffett Field, CA > > >Essentially, we're trying to decide what user interface to use on a number >of future projects, here, and Forms would be a favorite, if it were supported >by SGI. (Nobody wants to mess with supporting Panel-lib any more...) > >Curiously yours, > >Dan Wallach >dwallach@nas.nasa.gov > Well, I have done quite a bit of messing with the Panel-lib, and have used it to build a quite elaborate package. I have reworked the internals in such a way that it is multi-threaded, and can reach into your running application from the GUI thread, lookup the symbol table for the address you want to attach the actuator to, and either read or write values in your application thread (via the /debug/<PID> debugger low lever interface). I have concentrated on making the panel lib a tool to support my applications by reducing the overhead code in the application(how about zero UI code in the application). I use the panel editor daily, and I have panels with 100+ actuators in various threads using sgi brand shared memory (Arenas). I have put in a real time scripting/playback for animation camera and object path tracking, and lots of real neat stuff for my own projects. However, I have been enjoined from releasing ANY code for the panel library, and I am casting around to build on another gui from source. My mods are too extensive to release as diffs on the 9.7 source, and while the panel lib may be dead for the rest of the world, I like using its framework to build and elaborate on. It may be more the case that I have become used to it (and all its bugs, but then I find it easier to fix'em than to get bothered by them.) than have made an informed choice from the broad selection of freeware GUI's avaiable today :-> . My main thrust is my application, not the GUI, but I could not have written my application without the panel library, and being able to mung the source. I like the idea of a c++ rewrite, and I may look into the Forms library when it comes time for my next major re-write. However, I will have to re-engineer my mods into Mark's library, and that will be a challange, unless he is ahead of me. I must say that having a good gui really changes the way I work for the better. I can concentrate on my application, not the GUI. But that only came after spending months and months on the GUI... Cheers! dan. | karron@nyu.edu (e-mail alias ) Dan Karron, Research Associate | | Phone: 212 263 5210 Fax: 212 263 7190 New York University Medical Center | | 560 First Avenue Digital Pager <1> (212) 397 9330 | | New York, New York 10016 <2> 10896 <3> <your-number-here> |
tpm@ecs.soton.ac.uk (TP Monks) (06/22/91)
In <1991Jun20.225914.26517@nas.nasa.gov> dwallach@nas.nasa.gov (Dan Wallach) writes: >Now, Overmars has told me "Almost certainly Silicon Graphics is going to >supply the Forms Library as part of their developers package. This means >some sort of support for the future." I heard the same tale. If this is the case, presumably SG will put some effort into doing the thing properly. Perhaps it would be helpful to have some kind of discussion about the kind of things that people would like to see changed/improved in the forms library before it gets handed over. Presumably, as Mark Overmars pointed out, changes will be more difficult to instate once its an sg supported product. For example, why not allow users to 'tap into' a callback to an object so that their routine is called before the objects callback. This would allow extra functions to be added to an object by a program. For instance, I've written a class that allows you to display scrollable sgi imagelib files (works a bit like the positioner, but with an image moving across the background); it would be handy to be able to tap into the callback to such an object to read the colour of the pixel under the mouse, without having to add a free object. This function is implemented in Windows, and presumably other guis. Perhaps other people have other suggestions or comments? I'm not trying to create extra work for Mark, just to tell SG what users want from such a package! - not that it isn't already an excellent piece of work! Tim Monks Southampton university.
portuesi@tweezers.esd.sgi.com (Michael Portuesi) (06/22/91)
In article <1991Jun20.225914.26517@nas.nasa.gov>, dwallach@nas.nasa.gov (Dan Wallach) writes: |> |> I'm curious if anybody can complete this picture for me. I'll give it my best shot... |> If you do a strings on one of those SGI programs with all |> the cute buttons (like vadmin) you see lots of things like |> "tkButton", "tkObject", etc. There are also things |> in there like "tkButton.c++". |> |> One might assume that SGI's user interface thing is written |> in C++ and called tk. Is this available externally? Silicon Graphics has never offered its own user interface toolkit. This is still an area of active consideration within SGI. The WorkSpace and System Manager were both developed in C++ using a common body of software called "tk". However, "tk" is not a complete user interface toolkit that can support a diverse variety of applications software. Furthermore, it is not possible to develop "tk" into such an environment. For that reason, it was decided not to make it available externally, and its use within SGI has been limited primarily to the WorkSpace and System Manager products. Most new software projects within SGI are designing their user interfaces using OSF/Motif. Some projects, such as Showcase, have implemented their own user interface code. |> |> Next, if you look at Forms (the excellent public domain user |> interface system |> by Mark Overmars), you see a suprising similarity between Forms and |> some of |> these SGI programs, although the shadows on the 3-D buttons are |> different... |> I've looked at the Forms package. Mark has done a very good job emulating the look of the buttons and scrollbars in System Manager and WorkSpace, but he certainly didn't have an ``inside line'' on the development of those products. |> Now, Overmars has told me "Almost certainly Silicon Graphics is |> going to |> supply the Forms Library as part of their developers package. This |> means |> some sort of support for the future." |> |> When can I expect to see such a thing from SGI itself? There |> weren't any |> Forms on our Cypress Alpha 182 compact disk. SGI has never made a commitment to offer or support the FORMS library as an SGI product. Currently, we officially support the OSF/Motif user interface toolkit, and the Showcase developers option (which contains source code for the Showcase user interface widgets). |> Essentially, we're trying to decide what user interface to use on a number |> of future projects, here, and Forms would be a favorite, if it were |> supported |> by SGI. (Nobody wants to mess with supporting Panel-lib any |> more...) |> |> I assume I'm not the only person curious for the answer, so I'm |> posting |> the question, here. I hope you find the answer helpful. At the recent Developers' Forum, we solicited input on what the future of the SGI desktop environment should look like. If you feel that SGI should commit itself to producing high-quality user-interface and software development technology for its developer community, then we urge you to respond to that survey and tell us what you want. If you didn't attend the Developers' Forum, we will value your input just as highly. Thanks, m. -- __ \/ Michael Portuesi Silicon Graphics, Inc. portuesi@sgi.com
markov@cs.ruu.nl (Mark Overmars) (06/25/91)
>|> Now, Overmars has told me "Almost certainly Silicon Graphics is >|> going to >|> supply the Forms Library as part of their developers package. This >|> means >|> some sort of support for the future." >|> >|> When can I expect to see such a thing from SGI itself? There >|> weren't any >|> Forms on our Cypress Alpha 182 compact disk. Well, I think I do have to comment on this. The sentence above was definitely not meant for general distribution and was maybe a bit too enthousiastic from my side. I am discussing things of this nature with SGI but let us say at the moment that SGI "might" do this. Note however that I only was talking about supply, not modify, extend, etc. By the way, release 1.4 will be out by the end of this week. Fully compatible with 1.3 this time but with some extensions and bugs removed. Mark Overmars