haines@bbn.com (Ted Haines) (10/11/89)
I am in the process of trying to learn a little X
programming. We would like to be able to create simple
graphics such as circles and rectangles connected by lines.
I would like to be able to work at as high a level as
possible within the standard X environment. In particular I
would like to use the Athena widgets as much as possible.
There are lots of examples of simple widget programming and
it was easy to get them working. I have been trying for
several days without success to find or create a simple
example of using graphics within a widget window. The
example below is one of dozens of failed attempts to do it
myself. The environment is X11R3 on Sun 3/x.
The widget graphics I have seen always create their own
special purpose widget. Is this necessary? Isn't it possible
to use Xlib calls within a widget environment?
Could someone send me a simple working example.
What is wrong with my attempt below? (The thing compiles
and executes without error but does not draw the rectangle.
I have tried variations using different widget types,
various graphic routines, and various ways of setting up a
graphics context but have never gotten graphics to come
out.)
Where could I have found the answer to this problem myself?
What is good reference material and where can I find simple
examples?
Ted Haines
Haines@bbn.com
___________________________________________________________
The following program creates a label widget but does not
display a rectangle.
#include <X11/Intrinsic.h>
#include <X11/StringDefs.h>
#include <X11/Label.h>
Arg wargs[] = {
XtNlabel, (XtArgVal) "Hello there, X",
};
main(argc, argv)
int argc;
char **argv;
{
Widget toplevel, labWidg;
Display * display;
Drawable d;
GC gc;
XGCValues xgcv;
toplevel = XtInitialize(argv[0], "XLabel", NULL, 0, &argc, argv);
labWidg = XtCreateManagedWidget(argv[0], labelWidgetClass,
toplevel, wargs, XtNumber(wargs));
XtRealizeWidget(toplevel);
display = XtDisplay(labWidg);
d = XtWindow(labWidg);
gc = XtGetGC(labWidg, 0, &xgcv);
XDrawRectangle(display, d, gc, 5,5, 10,20 );
XtMainLoop();
}klee@gilroy.pa.dec.com (Ken Lee) (10/11/89)
In article <46739@bbn.COM>, haines@bbn.com (Ted Haines) writes: > The widget graphics I have seen always create their own > special purpose widget. Is this necessary? Isn't it possible > to use Xlib calls within a widget environment? Drawing on arbitrary widgets is usually not a good idea because 1. many widgets have multiple windows, so you don't know which window you're drawing on 2. event handling is somewhat complicated, and you do need to handle Expose events A better solution is to use a widget that supports arbitrary Xlib drawing. The major widget sets (DECwindows, HP, Motif) have widgets like this. They have straightforward callback interfaces for Expose event handling. The Athena widget set does not have such a widget built in, but the design for one is outlined in the manual. If you won't or can't use one of these widgets, at least try to draw on a core widget so you can be reasonably sure there's only one window there. That's probably the problem you're having now. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@decwrl.dec.com uucp: uunet!decwrl!klee
swick@ATHENA.MIT.EDU (Ralph R. Swick) (10/11/89)
> What is wrong with my attempt below? (The thing compiles > and executes without error but does not draw the rectangle. MostFrequentBeginningXProblemNumber9 (in a slightly different guise :-) - You've got to wait for the server to send you an Expose event before assuming that anything you draw will be displayed. In the case of widgets, this is normally accomplished by moving all your drawing code into the 'expose' widget class procdure. Since you're attaching your drawing code to an existing widget, you don't have this option, so instead you could add an event handler. You could still loose, though, as there's no guaranteed call ordering between the event handler and the class expose procedure. Your best bet is to read the last part of the Athena Widgets documentation and customize the Template widget to your heart's content, or to use a bare Core widget (class 'widgetClass' in R3) which has no expose procedure and therefore won't destroy any drawing you do in an expose event handler.
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (10/12/89)
> Drawing on arbitrary widgets is usually not a good idea because > A better solution is to use a widget that supports arbitrary Xlib > drawing. [ jumping up on the ol' soap box. ] A better, better solution is to write your own widget to do the job. This is after all one of the main design goals of the toolkit (easy subclassablility.) Writing your own widget is not nearly so difficult as most people fear and the Athena Template widget provides a good place to start. Besides if you write enough widgets you too can distribute a widget set :-) [ I will get off my soap box now. ] Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213
mart@ele.tue.nl (Mart van Stiphout) (10/12/89)
In article <8910111913.AA14172@expo.lcs.mit.edu> kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) writes: >A better, better solution is to write your own widget to do the job. This is >after all one of the main design goals of the toolkit (easy subclassablility.) What I don't understand is why neither widget set available has a widget just for drawing. Doesn't anyone want to draw??? In fact drawing is my main activity (schematics entry, simulation output postprocessor). Is this such a weird action?? Mart van Stiphout mart@ele.tue.nl (It's not the fall that kills you, it's the sudden stop)
lwh@harpsichord.cis.ohio-state.edu (Loyde W Hales) (10/12/89)
>What I don't understand is why neither widget set available >has a widget just for drawing. Doesn't anyone want to draw??? YES! >In fact drawing is my main activity (schematics entry, simulation >output postprocessor). Is this such a weird action?? NO! It is, too, mine! I find this odd as well. There is, however, the WorkSpace widget and its sub-classes (if there are any in the up-coming release) in the HP set. While these are not "drawing widgets", they are to provide ``an empty widget for graphics output'' [Young's Xt book]. I intend to use this as a starting point for now. -=- Department of Computer and Information Science Loyde W. Hales, II The Ohio State University lwh@cis.ohio-state.edu 2036 Neil Avenue Mall, Columbus, Ohio 43201
swick@ATHENA.MIT.EDU (Ralph R. Swick) (10/12/89)
> What I don't understand is why neither widget set available > has a widget just for drawing. Doesn't anyone want to draw??? The Athena widget set doesn't have a special-purpose drawing widget because I fought (hard :-) not to include one. What we provide instead is the Template widget and documentation on how to customize it to do exactly what you want. The problem with a "general-purpose" drawing widget is that either A) It handles every possible anticipated contingency; i.e. number of pixels (how many? 1, 2, 5, SizeofColormap()?), number of callbacks (one for Expose, one for ConfigureNotify, one for KeyPress ...), etc. B) It makes some choice of a "reasonable" subset of A. In the case of A you wind up with a very bloated widget and an application that instantiates even a few of them gets very big and we get lots of flames about how inefficient Xaw/Xt is. And 'every possible anticipated contingency' turns out not to cover some crucial area for somebody so we get 'enhancement requests'. In the case of B you wind up with a widget that is probably bigger than most applications need but too primitive for many and you still haven't educated people about how to live without Mommy and Daddy. And we get lots of flames about howcome the application can get 7 pixels through the widget resources but has to call XAllocNamedColor to get the 8th and 9th, or howcome our drawing widget can't handle input, or... And 'reasonable subset' turns out not to cover very many interesting areas for most people so we get 'enhancement requests'. So it's all my fault and I don't apologize for it. At some point developers aren't being provided a service when the silver platter gets too large. Soapbox complete.
net@tub.UUCP (Oliver Laumann) (10/13/89)
In article <124@euteal.ele.tue.nl> mart@ele.tue.nl (Mart van Stiphout) writes: > What I don't understand is why neither widget set available > has a widget just for drawing. It depends on what you mean by `neither widget set'. The OSF/Motif widget set has a widget called `drawing area'. It exports callback lists for expose, resize, and keyboard and mouse events. Is this what you are looking for? Regards, -- Oliver Laumann net@TUB.BITNET net@tub.UUCP
chan@hpfcmgw.HP.COM (Chan Benson) (10/14/89)
> The problem with a "general-purpose" drawing widget is that either > > A) It handles every possible anticipated contingency; i.e. > number of pixels (how many? 1, 2, 5, SizeofColormap()?), > number of callbacks (one for Expose, one for ConfigureNotify, > one for KeyPress ...), etc. > > B) It makes some choice of a "reasonable" subset of A. > > In the case of A you wind up with a very bloated widget and > an application that instantiates even a few of them gets very big > and we get lots of flames about how inefficient Xaw/Xt is. How is this different from any other widget? The HP WorkSpace widget and the Motif DrawingArea widget have been adequate for any drawing application I've had to do *except* that I can't select a specific visual and colormap. This seems to be more of an Xt limitation. > In the case of B you wind up with a widget that is probably > bigger than most applications need but too primitive for many > and you still haven't educated people about how to live > without Mommy and Daddy. > > At some point developers aren't being provided a service when the > silver platter gets too large. I'm sorry, this is a piss-poor attitude. As someone who is firmly entrenched in Xt and widget writing, it's very easy for you to say "write your own." Most application writers don't care to know how to write a widget. They just want to write their application, not be indoctrinated into the great church of Xt. What do you know about what services developers want? Have you asked them? When you're "silver platter" is already ten feet in diameter, adding another canape' or celery stick is not going to make a difference. -- Chan Benson HP Fort Collins
swick@ATHENA.MIT.EDU (Ralph R. Swick) (10/17/89)
> [two existing widgets] have been > adequate for any drawing application I've had to do *except* > that I can't select a specific visual and colormap. This seems to > be more of an Xt limitation. Xt limitation? I don't follow. It would have been simple for the developers of those widgets to provide a visual resource and some alternate handling of the colormap resource without any change to Xt. Seems they didn't anticipate your need.
pusateri@macbeth.cs.duke.edu (Thomas J. Pusateri) (10/18/89)
In article <1210019@hpfcmgw.HP.COM> chan@hpfcmgw.HP.COM (Chan Benson) writes: >I'm sorry, this is a piss-poor attitude. As someone who is firmly >entrenched in Xt and widget writing, it's very easy for you to say >"write your own." Most application writers don't care to know how to >write a widget. They just want to write their application, not be >indoctrinated into the great church of Xt. What do you know about >what services developers want? Have you asked them? Although I don't feel as harshly about this as Chan Benson does, I don't think that a drawing or even graphing widget is an unreasonable request. If nothing else, maybe you could take Bhalla's and Uhley's Athena Graph Widget written at Caltech and clean it up a little. (It's colormap implementation and restrictive fonts make it undesirable to use as a general tool.) Just my $0.02 Tom Pusateri pusateri@nbsr.duke.edu
dmc%satori@Sun.COM (Doug Cook) (10/20/89)
In article <15802@duke.cs.duke.edu> pusateri@nbsr.duke.edu (Thomas J. Pusateri) writes: >Although I don't feel as harshly about this as Chan Benson does, I >don't think that a drawing or even graphing widget is an unreasonable >request. If nothing else, maybe you could take Bhalla's and Uhley's >Athena Graph Widget written at Caltech and clean it up a little. (It's >colormap implementation and restrictive fonts make it undesirable to >use as a general tool.) You might also investigate the canvas package in the XView toolkit if you don't want to write your own widget and your application doesn't require the use of Xt. Granted, it's not a "widget" per se, but will provide you with an optionally scrollable drawing pane. -Doug Doug Cook dmc@sun.com XView Group cook@gandalf.ucdavis.edu Sun Microsystems, Inc.
dierick@brsopi.enet.dec.com (Dominique Dierick) (10/23/89)
Company : Digital Equipment Corporation (Software Services) Brussels - Belgium Mail : dierick@brsopi.enet.dec.com or dierick%brsopi.DEC@decwrl.dec.com > A better, better solution is to write your own widget to do the job. This is > after all one of the main design goals of the toolkit (easy subclassablility.) > Writing your own widget is not nearly so difficult as most people fear and the > Athena Template widget provides a good place to start. I aggree it is not difficult to create a widget, but since in most widget toolkits exist allready the drawing widget (DEC : window , MOTIF : drawing_area, ...) ... why re-invent the wheel ? For the original question : if you did not got it working yet, take it offline and send me a mail. Dominique Dierick
stumpf@lan.informatik.tu-muenchen.dbp.de (Maex) (10/24/89)
Why not simply use the Simple widget provided with the standard X11 distribution. You'll have to install your own event-handler et all but I use it frequently and it works fine for me! \Maex / Markus Stumpf local: lan.informatik.tu-muenchen.dbp.de \ | TU Muenchen, Inst. f. Informatik stumpf%{local}@{unido.uucp|relay.cs.net}| | Arcisstrasse, D-8000 Muenchen 2 BITNET: infrza02@dm0tui1s.bitnet | \ Federal Republic of Germany /
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (10/27/89)
> > A better, better solution is to write your own widget to do the job. > I aggree it is not difficult to create a widget, but since in most > widget toolkits exist allready > the drawing widget (DEC : window , MOTIF : drawing_area, ...) ... why > re-invent the wheel ? I did not mean that you should write a widget to do generic drawing, I meant that you should write a widget to do whatever task it is that you feel requires these graphics. For instance write yourself a BarGraph widget, or a Plotting widget, etc. Use Xt to build yourself an object that will do the task. This will not only make for a more compact program, but will make things easier to understand since all the Xlib calls will be wrapped up in widgets, and not in the main body of the program. Modularity, and Object-Oriented programming, what a great idea :-) [ Okay, I'll get off my soapbox now... ] Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213
marbru@auto-trol.UUCP (Martin Brunecky) (10/28/89)
In article <8910262037.AA16779@expo.lcs.mit.edu> kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) writes: > >>> A better, better solution is to write your own widget to do the job. > >> I aggree it is not difficult to create a widget, but since in most >> widget toolkits exist allready >> the drawing widget (DEC : window , MOTIF : drawing_area, ...) ... why >> re-invent the wheel ? Just an opinion... There are some other things you would like to do with a "graphics" widget, such as input processing etc., which are not quite supported by the widgets above. Or, to provide full symetry between windows and pixelmaps. Or ... However, writing a "universal" graphics widget is close to impossible. We have done the "minimum" job to satisfy our most obvious needs, and eneded up with three widget classes plus two object classes. Not quite what I'd call simple widget. -- ############################################################################### Martin Brunecky, Auto-trol Technology Corporation, 12500 North Washington Street, Denver, CO-80241-2404 (303) 252-2499 ncar!ico!auto-trol!marbru