gjc@mitech.com (12/11/90)
In article <3132@gazette.bcm.tmc.edu>, etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) writes: > |>Is 3D effect really the reason that you would use such a toolkit? > > > Well, I'll tell ya. Everytime I come out with some X-based > product using the Athena Widget Set, ... > > In answer to your question ..... YES!!!! Here is a question. How difficult is it to conditionalize or abstract ones code such that different widget sets can be used depending on the local configuration/availability? Then if somebody has the MOTIF set on his system your application could look 3d/MOTIF, and if *not* then you would use Athena (and the person would probably not notice the difference, not being *used* to the 3d look, since he doesn't have it on his machine). -gjc p.s. Just a suggestion in the form of a question.
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (12/13/90)
|> Here is a question. How difficult is it to conditionalize or |> abstract ones code such that different widget sets can be used |> depending on the local configuration/availability? |> |> Then if somebody has the MOTIF set on his system your application |> could look 3d/MOTIF, and if *not* then you would use Athena |> (and the person would probably not notice the difference, not being |> *used* to the 3d look, since he doesn't have it on his machine). |> |> -gjc |> |> p.s. Just a suggestion in the form of a question. Sometimes it is not too hard. It your application is nothing but a bunch of buttons then it is a snap. However, sometimes it is not so easy. For instance, toggle widgets are handled completely differently in Athena Widgets than they are in MOTIF (when using mutually exclusive toggles). Mutually exclusive toggles in MOTIF code must all be children of the same widget. The Athena analog can be spread out all over creation. Layout widgets are also fairly different from toolkit to toolkit. I have my own layout widget that I use to exclusion in which I have MOTIF flags. That helps some, but not always. MOTIF is awfully dependent upon itself. It is very easy to use Athena widgets in any other Xt-based toolkit, but not MOTIF. MOTIF widgets do all sorts of different things based upon the class of its parent. -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bcm.tmc.edu (713) 798-3776
dex@hpcvlx.cv.hp.com (Dex Smith) (12/14/90)
The desire to support multiple user interfaces for a single application
is certainly a real-world problem. I've talked with several developers
that want to support a concurrent products on Motif, Presentation Manager,
and MS Windows.
As mentioned in a previous response, implementation of some user
interface components can vary widely. Therefore, developers that force
good design upon themselves will come out ahead. This calls for a
separation of user interface and application functionality, and some
form of semantic communication between the two. (Some would call this
"dialog management," but I'll stay away from the terminology war for
now.)
My recommendation is that you develop your application in a modular fashion
so you can build versions with different user interfaces. I would expect
that "ifdef-ing" different interface code within the same modules of code
could get quite ugly, fast.
- Dex Smith
Interface Technology Operation
Hewlett-Packard Company
Corvallis, Oregon
dex@hpcvlx.hp.comuad1077@dircon.uucp (Ian Kemmish) (12/14/90)
In article <3165@gazette.bcm.tmc.edu> etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) writes: > > >|> Here is a question. How difficult is it to conditionalize or >|> abstract ones code such that different widget sets can be used >|> depending on the local configuration/availability? >|> >|> Then if somebody has the MOTIF set on his system your application >|> could look 3d/MOTIF, and if *not* then you would use Athena >|> (and the person would probably not notice the difference, not being >|> *used* to the 3d look, since he doesn't have it on his machine). >|> >|> -gjc >|> >|> p.s. Just a suggestion in the form of a question. > > >Sometimes it is not too hard. It your application is nothing >but a bunch of buttons then it is a snap. > >However, sometimes it is not so easy. For instance, toggle >widgets are handled completely differently in Athena Widgets >than they are in MOTIF (when using mutually exclusive toggles). > Hmmm, my news program appears to have dropped one or more attributions. Sorry. If you know beforehand that you want a portable program, then life is not too bad. I have a 15,000 drawing program, based loosely on Freehand from Aldus for the Mac. Of this, about 2,000 each are for Motif or Athena. They are in separate files. The main body of the program is driven almost entirely by callbacks from this code. There are only a couple of dozen lines with ifdefs in the rest of the program. These are mostly to handle interrogating and forcing sets of radio buttons. The biggest problem so far was getting *just* a shift button press event. In Athena it works no problem. In Motif, I only ever seemed to get it at the next `normal' event. Yuk. The second biggest problem was having dialogue boxes that can accept text. Motif seems to be very picky about exaclty what type of shell widgets you use. Athena is a lot more permissive. The third biggest problem was the general size, sloth and bugginess of Motif, both in design and implementation. Still struggling with that one. Compared to Motif, doing NURBS in a window system with no graphics library to speak of was almost easy! Hope this helps. -- Ian D. Kemmish Tel. +44 767 601 361 18 Durham Close uad1077@dircon.UUCP Biggleswade ukc!dircon!uad1077 Beds SG18 8HZ United Kingd uad1077%dircon@ukc.ac.uk
graham@fuel.dec.com (kris graham) (12/14/90)
> From: etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) > Subject: Re: MOTIF vs Athena. Practical to conditionalize? > Date: 12 Dec 90 16:42:07 GMT > > > MOTIF is awfully dependent upon itself. It is very easy to use > Athena widgets in any other Xt-based toolkit, but not MOTIF. > MOTIF widgets do all sorts of different things based upon the class > of its parent. It is tempting to believe the above until you see TeleUSE.....they allow you to mix and match Xt widgets freely using a mouse. Motif and MIT widgets can coexist without problems. Rememeber, this is not a product endorsement......just my personal observations. Christopher Graham Internet: graham@fuel.enet.dec.com Digital Equipment Corp UUCP: ...!decwrl!fuel.enet.dec.com!graham Ultrix Resource Center New York City.
jf@ap.co.umist.ac.uk (John Forrest) (12/15/90)
In article <3165@gazette.bcm.tmc.edu>, etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) writes: |> |> |> |> Here is a question. How difficult is it to conditionalize or |> |> abstract ones code such that different widget sets can be used |> |> depending on the local configuration/availability? |> |> |> |> Then if somebody has the MOTIF set on his system your application |> |> could look 3d/MOTIF, and if *not* then you would use Athena |> |> (and the person would probably not notice the difference, not being |> |> *used* to the 3d look, since he doesn't have it on his machine). |> |> |> |> -gjc |> |> |> |> p.s. Just a suggestion in the form of a question. |> |> |> Sometimes it is not too hard. It your application is nothing |> but a bunch of buttons then it is a snap. |> |> However, sometimes it is not so easy. For instance, toggle |> widgets are handled completely differently in Athena Widgets |> than they are in MOTIF (when using mutually exclusive toggles). |> |> Mutually exclusive toggles in MOTIF code must all be children |> of the same widget. The Athena analog can be spread out all over |> creation. |> |> Layout widgets are also fairly different from toolkit to toolkit. |> |> I have my own layout widget that I use to exclusion in which I |> have MOTIF flags. That helps some, but not always. |> |> MOTIF is awfully dependent upon itself. It is very easy to use |> Athena widgets in any other Xt-based toolkit, but not MOTIF. |> MOTIF widgets do all sorts of different things based upon the class |> of its parent. If you use the Widget Layout Manager from the Xcu toolkit, you are able to migrate from one toolkit to another. This is because the widget tree is described in a config file rather than the actual source, and also the config file can cope with first level ``callback handling''. Whether the toggle widgets are under one parent or spread out is thus in the config file, and not in the program itself. The program is thus ``reduced'' to providing the main functions of the application, and it would appear that most functions can be written in ways that are independent of the widget set. John Forrest Dept of Computation UMIST
marbru@attc.UUCP (Martin Brunecky) (12/15/90)
>> MOTIF is awfully dependent upon itself. It is very easy to use >> Athena widgets in any other Xt-based toolkit, but not MOTIF. >> MOTIF widgets do all sorts of different things based upon the class >> of its parent. (and child, of course...) > >It is tempting to believe the above until you see TeleUSE.....they allow >you to mix and match Xt widgets freely using a mouse. Motif and >MIT widgets can coexist without problems. > Coexist or cooperate ? What about Motif traversal. What about accelerators, mnemonics ... Sticking a widget into a DialogBox and making it appear on the screen is not all you need to write an application. (though all UI editor vendors will try to convince you that way). -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
nazgul@alphalpha.com (Kee Hinckley) (12/16/90)
In article <1990Dec14.164540@ap.co.umist.ac.uk> jf@ap.co.umist.ac.uk (John Forrest) writes: >If you use the Widget Layout Manager from the Xcu toolkit, you are able to >migrate from one toolkit to another. This is because the widget tree is >described in a config file rather than the actual source, and also the config >file can cope with first level ``callback handling''. Whether the toggle >widgets are under one parent or spread out is thus in the config file, and not >in the program itself. The program is thus ``reduced'' to providing the >main functions of the application, and it would appear that most functions can >be written in ways that are independent of the widget set. Sure, if you don't want to take full advantage of the toolkit, don't care about having an efficient application and don't worry about being style-guide compliant and/or easy to use. I need to do stuff like ensure that I can tab out of a multi-line text widget and go to the next field if the text widget is readonly. Or create a cascade menu without a label where the I override Motif's menu history functionality. Or create a popup where there is one popup for the entire application, but which items are sensitive depend on which item you popped up over. Or dynamically create the correct types of widgets on the fly in a mail reader window as you view messages that contain different kinds of enclosures (forwarded messages, text, Frame documents, GIF files...). And of course the menubar layout needs to conform to Motif, with the help menu off on the right, so I have to tell it which pulldown is the help pulldown. And there are some quirks in layout of paned windows, so it's critical that I manage the paned window (and its parents) before I add the children. And then there are dialog boxes that have text fields, where I need to tell the toolkit which text field should have the initial focus, or need to make sure that the initial text in the field is pre-selected, so when the user starts typing it gets replaced. And then there's the Xerox-style hierarchical folder browser where I need to shift all of the contents of three scrolling lists quickly to the right or to the left as the user moves around through the folder hierarchy. Of course I didn't *need* to do all of that stuff - but I wouldn't have a good interface if I didn't. Sure, I can abstract some of it for my application - but I can't just casually use some UIMS, higher-level toolkit or layout manager and automagically switch widget sets. I'd love to be proven wrong, but I'm still waiting. -kee -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
alan@metasoft.UUCP (Alan Epstein) (12/18/90)
... >|> MOTIF is awfully dependent upon itself. It is very easy to use >|> Athena widgets in any other Xt-based toolkit, but not MOTIF. ... Does this mean that an application cannot use Motif and Athena widgets together, or that they cannot co-exist in the same widget hierarchy, or that sometimes there are problems with some organizations of these widgets? ----------------------------- Alan Epstein Meta Software Corp UUCP: ...bbn!metasoft!alan 150 Cambridgepark Dr Internet/ARPA: alan%metasoft@bbn.com Cambridge, MA 02140 USA -----------------------------
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (12/19/90)
In article <2024@metasoft.UUCP>, alan@metasoft.UUCP (Alan Epstein) writes: |> |> ... |> >|> MOTIF is awfully dependent upon itself. It is very easy to use |> >|> Athena widgets in any other Xt-based toolkit, but not MOTIF. |> ... |> |> Does this mean that an application cannot use Motif and Athena |> widgets together, or that they cannot co-exist in the same widget |> hierarchy, or that sometimes there are problems with some |> organizations of these widgets? Well first of all, the MOTIF version I have requires its own version of Xt called Xtm. MAJOR bummer. However, I have been informed that there is a version of MOTIF that uses normal Xt. This being the case, you CAN put Athena widgets inside of MOTIF widgets and vice-versa, however, they won't always act like you want them to. IE You could never get a MOTIF toggle widget to align in anything other than one of the MOTIF layout managers. Layout managers should *NEVER* check the classes of its children or should the child widget check the class of its parent. This makes your widget very unfriendly and non-portable (sometimes). -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bcm.tmc.edu (713) 798-3776
marbru@attc.UUCP (Martin Brunecky) (12/19/90)
In article <2024@metasoft.UUCP> alan@metasoft.UUCP (Alan Epstein) writes: > ... >>|> MOTIF is awfully dependent upon itself. It is very easy to use >>|> Athena widgets in any other Xt-based toolkit, but not MOTIF. > ... >Does this mean that an application cannot use Motif and Athena >widgets together, or that they cannot co-exist in the same widget >hierarchy, or that sometimes there are problems with some >organizations of these widgets? > co-exist: Depends on defintion of "co-exist". For the most part, you can create any widget as a child of (almost) any Motif manager. For the most part, you can also realize (display and see) such a child. In Motif 1.0, I'v run into instances of code which, being unable to decide what type this child is left the case statement without assigning any values - but using those later. (I assume that's fixed in 1.1). organization: Again, what is organization ? If you mean geometry management, it is most likely to work as good or as bad as for other Motif widgets. Note that most Motif geometry managers have some other specific purposes, such as XmRowColumn which primary purpose is to held together Motif's menu subsystem. XmRowColumn is therefore really picky about it's children. Most of the problems are in the areas of STYLE and BEHAVIOR enforcement along with KEYBOARD TRAVERSAL. Motif managers assume (in some cases) that children have particular translations and or callbacks, sometimes even directly access child's instance structure (for known children) to accomplish the desired behavior. How can they do it for an unknown child ? Thus, you can put a non-Motif widget into Motif hierarchy. But you should also expect that some of the Motif functionality may be lost in that combination. Depending on situation, you may be able to compensate for it (configuring your widget), or not. The least damaging places for non-Motif widgets seems to be XmBulletin board and XmMainWindow. Motif-izing other widget is not an easy task. My experience is that to achieve the full Motif compatibility, most of my widgets had to subclass off of some existing Motif class, such as XmPushButtonGadget or XmRowColumn, carrying over tons of useless resources and un-doing operations of superclasses Intialize and SetValues code. In other instances, such as my own WsText widget, where I could not subclass off of Motif, I had to duplicate /steal lots of Motif code - and to make the widget play with Motif I have to augment translations on per-instance basis. However, even with the problems above, Motif is still a great toolkit. The problems are due to the effort to make the use (creation) of the *typical* UI components as easy as possible. Considering a complex functionality, such as Motif keyboard equivalency, and the development deadlines, something had to be left for "later" - in particular provisions for extensibility and other widget accomodation. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
bonnett@seismo.CSS.GOV (H. David Bonnett) (12/28/90)
In article <2024@metasoft.UUCP>, alan@metasoft.UUCP (Alan Epstein) writes: |> |> ... |> >|> MOTIF is awfully dependent upon itself. It is very easy to use |> >|> Athena widgets in any other Xt-based toolkit, but not MOTIF. |> ... |> |> Does this mean that an application cannot use Motif and Athena |> widgets together, or that they cannot co-exist in the same widget |> hierarchy, or that sometimes there are problems with some |> organizations of these widgets? I have been able to mix Athena widgets into my Motif app. I am stuffing an Athena-based group of widgets, including a homegrown table widget inside a motif xmform. Getting the form to handle the alignment correctly is a tad tough, but then again, it is without the addition of Athena stuff ;-) -dave bonnett; Center for Seismic Studies, Arlington VA bonnett@seismo.css.gov-