rlh2@ukc.ac.uk (Richard Hesketh) (08/14/90)
Two (probably) major additions to the Xt Intrinsics would be nice:
1) Provide detailed support for "graphics objects", by this I mean
rectangles, circles, points and polygons. These should be scalable
and can be overlaid on top of each other, have their own graphics
contexts and have the ability to dump their description somewhere
(a sort of meta-file I suppose). If anybody has seen the
InterViews demo (!) program "Idraw" they will known the type of
objects I mean.
2) Provide a mechanism to allow tracking of resource values. For example
this would allow an application to register interest in a particular
resource in a particular widget instance and be informed via a callback
when this resource changes. I suspect this would be easier to implement
than a more general mechanism that would allow applications to register
interest using a wildcard scheme (i.e. "*Background" = tell me about
any changes in any resource whose class is "Background" in any widget
instance) but of course not being as powerful.
I would see this being implemented as part of the SetValues functions.
It would of course have to have no impact on existing widget code.
1) may fill the gap left by the toolkit when it comes to doing any graphics
operations in a toolkit based app .. i.e. having to delve in deep in to Xlib.
2) would help direct manipulation applications including user interface
builders (my interest) no end.
1) and 2) together could make a neat ``graphical constraints'' system
making it easier to create graphical languages and other direct manipulation
applications using Xt.
Richard Hesketh : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk
: rlh2@ukc.ac.uk ..!mcvax!ukc!rlh2
---
Computing Lab., University of Kent at Canterbury,
Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 7620/3682markham@cadence.com (Jeff Markham) (08/16/90)
In-reply-to: rlh2@ukc.ac.uk's message of 14 Aug 90 12:36:16 GMT
Newsgroups: comp.windows.x
Subject: Re: An R5 wish for the X Toolkit
References: <5276@harrier.ukc.ac.uk>
Distribution:
I like what Richard has suggested alot ...
re: 1. ( graphical lists )
I've done one of these (its commercial so I can't post it) ..
and boy are they handy. The only thing I can add here is that
I did it using a parasite approach .. so you can attach these
display lists onto any existing widget or gadget. If you do
the graphics layer right, you can get some really good
performance.
re: 2. ( resource change callbacks )
Again .. a good idea , but could lead to severe performance
degradation. I would think it would be OK if one could be
called back as a preSetValues->postSetValues pair so that
you don't branch out in the middle of a propagation.
re: (graphical constraints)
Maybe what's needed here is an active constraint system. The
current offering of Constraint class widgets are quite passive,
and the constraints they understand are too atomic. It would
be really neat if we could have some Constraint widgets that
could incorporate some of the features found in a Constraint
Programming Language .. where more than trivial constraints
could be described and satisfied via a constraint satisfaction
system. Then .. things like graphical contraints would be quite
easy to do ... "Put this over here and line this group up
N apart and with their top edges aligned". Most of the time,
you wind up creating a complex widget tree just so the
contraints won't screw up. MIT has alot of experience here,
so the right people are around to make it happen.
I'd like to also add a few things to the Xt wish list ...
1). The way resources are passed and cached really needs to be
re-examined. A significant part of the widget creation time
comes from creating and merging arg lists .. and then searching
through the class hierarchy to find the class that cares about
this resource. Along they way , lots of code gets called that
says .. do you care about this ? .. no .. go up. I understand
why strings need to be around for the resource property, but
some pretty good performance speed-ups could be gained if XmN.....
was a int or short hash index rather than a string .. and unless
you've got a pretty smart loader, the image is filled with
duplicated (long I might add) strings.
2). Similarly, it would be nice if you could specify a
prototypical widget that embodies the majority of the
resources you wish to use in the future .. and refer to it
when creating a new widget. Then you override only the
resources you were different. I bet you could play alot
of tricks with backpointers that would cut down memory useage
quite a bit. Its sort of multiple inheritance I guess.
3). AT&T did a really neat thing in the OpenLook widgets called
"Flat Widgets" .. I haven't seen the code for this .. but I
bet its a "superWidget" that has lots of subareas that it knows
how to render and dispatch internally to mimick many children.
Seems like this would be a generally good thing to have in
the Xaw stuff ... Sun/AT&T are Consortium members .. maybe they
would be interested in helping here.
4). Translation Tables need to be re-examined .. boy are they
big.
5). An exclusive late binding would be nice. It would be great
to say
"<Btn1Down>: Action()\n\
<Btn1Down>(2): Action2()"
and not have both of them get dispatched on a double click .
I know they put a time-out value in R4 .. but it still
seems to dispatch both of them.
Thanks,
Jeff Markham
markham@cadence.comUuunet@vicorp.com (UUNET) (08/16/90)
I like what Richard has suggested alot ...
re: 1. ( graphical lists )
I've done one of these (its commercial so I can't post it) ..
and boy are they handy. The only thing I can add here is that
I did it using a parasite approach .. so you can attach these
display lists onto any existing widget or gadget. If you do
the graphics layer right, you can get some really good
performance.
re: 2. ( resource change callbacks )
Again .. a good idea , but could lead to severe performance
degradation. I would think it would be OK if one could be
called back as a preSetValues->postSetValues pair so that
you don't branch out in the middle of a propagation.
re: (graphical constraints)
Maybe what's needed here is an active constraint system. The
current offering of Constraint class widgets are quite passive,
and the constraints they understand are too atomic. It would
be really neat if we could have some Constraint widgets that
could incorporate some of the features found in a Constraint
Programming Language .. where more than trivial constraints
could be described and satisfied via a constraint satisfaction
system. Then .. things like graphical contraints would be quite
easy to do ... "Put this over here and line this group up
N apart and with their top edges aligned". Most of the time,
you wind up creating a complex widget tree just so the
contraints won't screw up. MIT has alot of experience here,
so the right people are around to make it happen.
I'd like to also add a few things to the Xt wish list ...
1). The way resources are passed and cached really needs to be
re-examined. A significant part of the widget creation time
comes from creating and merging arg lists .. and then searching
through the class hierarchy to find the class that cares about
this resource. Along they way , lots of code gets called that
says .. do you care about this ? .. no .. go up. I understand
why strings need to be around for the resource property, but
some pretty good performance speed-ups could be gained if XmN.....
was a int or short hash index rather than a string .. and unless
you've got a pretty smart loader, the image is filled with
duplicated (long I might add) strings.
2). Similarly, it would be nice if you could specify a
prototypical widget that embodies the majority of the
resources you wish to use in the future .. and refer to it
when creating a new widget. Then you override only the
resources you were different. I bet you could play alot
of tricks with backpointers that would cut down memory useage
quite a bit. Its sort of multiple inheritance I guess.
3). AT&T did a really neat thing in the OpenLook widgets called
"Flat Widgets" .. I haven't seen the code for this .. but I
bet its a "superWidget" that has lots of subareas that it knows
how to render and dispatch internally to mimick many children.
Seems like this would be a generally good thing to have in
the Xaw stuff ... Sun/AT&T are Consortium members .. maybe they
would be interested in helping here.
4). Translation Tables need to be re-examined .. boy are they
big.
5). An exclusive late binding would be nice. It would be great
to say
"<Btn1Down>: Action()\n\
<Btn1Down>(2): Action2()"
and not have both of them get dispatched on a double click .
I know they put a time-out value in R4 .. but it still
seems to dispatch both of them.
Thanks,
Jeff Markham
markham@cadence.com