DESIGN toolbox : 5-July-96
xvroutines
kroutines
libraries
cantata
- Short Description:
- Once an encapsulated workspace is created, its GUI cannot
be changed.
Work-Around :
Severity : 3a - Major inconvenience
Priority : 3 - Medium
Reported By : ingle@erim.org
Date : 24-Aug-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
When an encapsulated workspace is created, can the GUI be
changed through craftsman/composer? When I try this the pane
file is changed, but even though a "generate code" and "make
install" were done, the GUI still shows the original form when
using cantata.
- Notes :
-
It's a design flaw. Currently the workspace gui is recreated
from the workspace, rather than restored from the saved gui.
It's on our list to fix, but need to redesign how a workspace
and gui are associated via the workspace. Once this is done
we should be able to restore the gui from the object's pane,
rather than recreate it when restoring.
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Problems with attempts to resize detached procedures:
1 - detached procedure not resized properly
2 - hitting reattach button on the detached procedure's
titlebar will result in what appears to be a corrupted
main workspace display, but is in fact the
re-attached, resized procedure with the contents of
the main cantata workspace "peeking out" from
underneath.
Work-Around : Workaround for 1:
Don't resize detached procedures,
or don't resize them horizontally,
or resize them back again, or don't let it bother you
Workaround for 2:
Hit the "detach" button on the titlebar to once again
detach the procedure. The detached procedure's
"iconify" button can now be used to close the procedure
and all will appear normal again.
Severity : 3a - Major inconvenience
Priority : 4 - Low
Reported By : Danielle Argiro
Date : 3-Jul-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- For the first problem:
a - % cantata -wksp workspaces:procedures:Procedure2
b - Open and detach a procedure
c - Resize it to be smaller than the default size.
Scrollbars disappear; the titlebar at the top does
not resize.
Now for the second problem:
d - resize the detached procedure such that you can
once again see the entire titlebar, but the body
of the procedure is still alot shorter than it
was originally
e - if you hit the "iconify" button on the far left
side of the detached procedure's titlebar, all
will be fine. However, if you hit the "re-attach"
button on the far right side of the detached
procedure's titlebar, the now-much-shorter
procedure will be remapped onto the cantata
workspace ON TOP of the previous contents (the
main workspace). This results in an extremely
confusing display which is not affected by a
"Redraw". To rectify this situation, hit the
"detach" button on the titlebar to once again
detach the procedure. the detached procedure's
"iconify" button can now be used to close the
procedure and all will appear normal again.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Procedure input file specification bug
Work-Around : Use a "User defined" input glyph, specify the desired
input file, and connect that to the procedure input
rather than trying to specify the input file directly
using the procedure pane.
Severity : 4b - Minor inconvenience
Priority : 3 - Medium
Reported By : Shannon Wells
Date : 3-Jul-96
HW : all
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- A procedure will not run if you specify the input file
using the Inputfile selection of the Procedure form
rather than by connecting another glyph to it. To
reproduce:
1 - % cantata -wksp workspaces:procedure:Procedure1
(or create any other workspace with a procedure
having at least one input)
2 - delete input connection to procedure
3 - open procedure pane and type input file directly into
the Inputfile selection
4 - try to run the procedure: it won't schedule, because
cantata doesn't know that an input file has been
specified
To get around this, simply use a "User defined" input
glyph, specify the desired input file, and connect that
to the procedure input.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- (Very minor) rubberband selection bug in empty workspace.
Work-Around : If you get stuck in rubberband mode, simply click the
first mouse button in the workspace.
Severity : 4b - Minor inconvenience
Priority : 4 - Low
Reported By : Mark Young
Date : 3-Jul-96
HW : all
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- In an empty workspace, depress first mouse button and drag
the mouse as if you were selecting (non-existent) glyphs.
The pointer will remain "in rubberband selection mode",
with the cursor appearing as the hand. You have to click
in the workspace to get things back to normal.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- If KHOROS_NOTIFY is set to KDEBUG, cantata will hang
on startup.
Work-Around : set KHOROS_NOTIFY to something other than KDEBUG;
KSTANDARD is recommended.
Severity : 4b - Minor inconvenience
Priority : 4 - Low
Reported By : Danielle Argiro
Date : 3-Jul-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- If KHOROS_NOTIFY is set to KDEBUG, cantata will hang
on startup. This is because there is a problem with
sending messages to an as-of-yet nonexistent console.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Sometimes glyph name does not appear when you create a
glyph.
Work-Around : Select glyph and move it slightly up. The name will
appear.
Severity : 4b - Minor inconvenience
Priority : 4 - Low
Reported By : Danielle Argiro
Date : 3-Jul-96
HW : all
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- This is not reliably reproducible, but there is a minor
refresh bug involved in glyph creation. Occasionally when
a glyph is created, its name will not appear underneath
it. If this happens, select it and move it up slightly
to get the glyph name to appear.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Label that displays name of workspace (eg, "Main
Workspace") can get over-written by the contents of
the status window and be unreadable
Work-Around : Anything that causes a refresh of the cantata workspace
will do.
Severity : 5a - Aestetics (types, minor UI inconsistencies, etc)
Priority : 4 - Low
Reported By : Danielle Argiro
Date : 3-Jul-96
HW : all
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- There is a minor refresh bug where the contents of the
status window can over-write the label that displays the
name of the workspace. Occasionally when a workspace is
restored, and the path to the workspace is pretty long,
the place under the cantata workspace (to the left)
that is allotted for kannounce messages will not be large
enough to accommodate the message that is displayed.
This will cause the label to the right (which displays
the workspace name) to get over-written. name not being
erased; the result is unreadable. If this happens,
resizing the workspace slightly should cause it to
refresh.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Procedure glyph indicates "open" even after it's closed
Work-Around :
Severity : 5a - Aestetics (types, minor UI inconsistencies, etc)
Priority : 4 - Low
Reported By : Danielle Argiro
Date : 3-Jul-96
HW : all
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- The little white triangle stays down after Procedure/Loop
is closed. To reproduce:
% cantata -wksp workspaces:control:Count
Open loop/procedure (do not detach). Little white
triangle points down. Close loop/procedure. Little
white triangle still points down.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- cannot capture the command log contents in a file -
reference in doc (KHOROS_LOG) says you can
Work-Around :
Severity : 3a- Major inconvenience
Priority : 3 - Medium
Reported By : Timothy Williams
Date : ??
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
> Hi there. We recently installed Khoros 2.02, and have not
> yet figured out how to capture the command log contents in
> a file. How do we go about saving these commands to execute
> from UNIX? (I cannot cut and paste from the "console"
> window...)
> Kerrie
In the manual set, Getting Started Manual, Chapter 2 - Setting
Up Your Environment, there is a reference to the environment
variable KHOROS_LOG. I tried it, but it doesn't seem to be
working (yet?). I think manual text is actually a leftover
from Khoros 1.0.5, because I know it worked then.
Cut/paste from the console window and error popups is a
definite "can we have this please" item for me too.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Color names often appear in hex, as in #ff0000 instead
of "Red" or #00ff00 instead of "Green"
Work-Around :
Severity : 4b - Minor inconvenience
Priority : 4 - Low
Reported By : Paula Plomp
Date : 4-Jul-96
HW : 486 PC (glacier & mohawk)
OS : Linux 1.2.13, Plug-and-play Linux Fall 1995, Yggdrasil
Widget : Athena
C : gcc 2.6.3
Fortran : f2c 19940329
Perl : perl 4.036
X : X11R6, Xfree86 3.1.2
Win Mgr :
Display :
- Original Rpt:
-
When you bring up the Glyph pane of the Preferences
subform, you may see the default color as #eeeeee
(instead of "light grey").
Notes :
Keywords :
TB::oname : ENVISION::xprism
- Short Description:
- Cantata Crashes when a glyph is deleted
Work-Around : Get X11R5 for the Sun
Severity : 1a- Seg fault, core dump, memory overwrite
Priority : 5 - None
Reported By : Matthew G. Fleming" wrote:
Date : 09-Jun-95
HW :
OS : SunOS 4.1.3_U1
Widget :
C : gcc 2.6.3
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
I am using SunOS 4.1.3_U1 with gcc 2.6.3. As I indicated
in my recent post to the newsgroup, cantata crashes when a
glyph is deleted if that glyph's pane has ever been opened.
This happens with both OLIT and Athena widget sets. Responses
to my post, and posts from others, indicate that I am not the
only one with this problem. However, some responders who had
built cantata with Athena on the same architecture did not
encounter this problem. The difference, if any, between the
configurations of the people who had and did not have the
problem are unclear.
So, TRUST ME, there is a REAL problem with this architecture.
I installed a vanilla X11R6 distribution on my workstation
and recompiled design, envision and geometry with that. This
apparently eliminated the cantata problem, but made one other
problem worse.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Encapsulated workspace saved/restored as procedures.
Work-Around :
Severity : 10a- enhancement request
Priority : 3 - Medium
Reported By : Mark Young young@khoral.com
Date : 24-Mar-96
HW : zen
OS : solaris
Widget : athena
C :
Fortran :
Perl :
X : X11R6 (accelerated X on glacier)
Win Mgr : twm
Display : glacier:0
- Original Rpt:
- Currently cantata saves encapsulated workspaces as
procedures rather than encapsulated workspaces. This
means that if the encapsulated workspace changes all
workspaces must be updated.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Need distributed IPC in order to execute remote processes
Work-Around :
Severity : 10a- enhancement request
Priority : 3 - Medium
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
A distributed IPC is needed in order to execute distributed
processes. It may not be enough to execute processes as if
they were not khoros processes since continuous run and other
glyphs are starting to rely on the IPC.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Request that Finder List also look at the keywords for
the objects. It currently looks only at the name, icon
name, and short description.
Work-Around :
Severity : 10a- enhancement request
Priority : 3 - Medium
Reported By :
Date : 5-Mar-96
HW : zen
OS : solaris
Widget : motif
C :
Fortran :
Perl :
X : X11R6 (Accelerated X)
Win Mgr : twm
Display : glacier:0T
- Original Rpt:
- Try to do a Finder Expresion lookup for the keyword
"variable". You might expect it to find kprval for
you, since the word "variable" is in the keywords list
for kprval.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Put the name of the saved workspace file being viewed
somewhere conveniently readable.
Work-Around :
Severity : 10a- enhancement request
Priority : 4 - Low
Reported By :
Date : 3-June-96
HW : zen
OS : solaris
Widget : motif
C :
Fortran :
Perl :
X : X11R6 (Accelerated X)
Win Mgr : twm
Display :
- Original Rpt:
- put the name of the file being viewed somewhere on the
Cantata title bar or in the window or something. the only way
that i can tell what file i'm viewing is by selecting File/Open.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Would like to save & restore current workspace attribute
settings as part of the cantata workspace.
Work-Around :
Severity : 10a - Enhancement request
Priority : 3 - Medium
Reported By : Scott Wilson
Date : 27-Feb-95
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- It would be nice if workspace attribute settings were
saved/restored along with the cantata workspace.
Notes :
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Would like separate file browsers for workspaces
and glyphs.
Work-Around :
Severity : 10a - Enhancement request
Priority : 4 - Low
Reported By : Shannon Wells
Date : 3-Jul-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- It might be good to have separate file browsers for input
of workspaces and input of files to glyphs. it is
somewhat of a pain to have to switch directories every
time you change workspace and then alter input to a
glyph via the file browser.
Notes :
Keywords :
composer
- Short Description:
- Composer interface is unusable during a compile
Work-Around :
Severity : 10a - Enhancement request
Priority : 4 - Low
Reported By : Jeff Blank
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
If the 'Commands' menu is used to make an object,
the window manager is locked out during the compile.
The pull-down menu for 'Make' stays active during the entire
compile. The button turns red and the pull-down stays pulled
down.
Reproduce Bug By:
1) Use composer's 'Command' menu to build an object.
2) Pick a 'Make' option that takes a long time.
3) Go get a drink or use the restroom because your
window manager will be busy for awhile.
[this is not really a bug, but feature of The Way Things Are]
- Notes :
- Enabling this would require us to fully support an IPC
and object locking mechanisms. This is not trivial.
Most of this IPC and locking would require kcms
infrastructure changes.
Keywords :
TB::oname : DESIGN::composer
- Short Description:
- problems with horizontal scrollbar in the Commands
window when compiling
Work-Around :
Severity : 4a- Non-standard behavior
Priority : 3 - Medium
Reported By : Tom Konerth
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
When compiling with the Commands window up, as the compile
outputs, both the horizontal and vertical scroll bars slide.
The horizontal bar should not move at all.
- Notes :
- This should be logged in the approprate widget library
in design
Keywords :
TB::oname : DESIGN::composer
- Short Description:
- The scroll bar in the Commands window does not reflect
actual position
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 3 - Medium
Reported By : George Ruban
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Does not reflect actual position of text window in text stream,
vertically or horizontally. Again, this makes it hard to see
progress of tools such as compiler.
- Notes :
- This should be logged in the approprate widget library
in design
Keywords :
TB::oname : DESIGN::composer
- Short Description:
- When you select "Shell", it seems like it should invoke an xterm and put you in the directory specified by "List Files"
Work-Around :
Severity : 10a - Enhancement request
Priority : 4 - Low
Reported By : Becky Bishop
Date : 14-Feb-96
HW : Sun SPARC
OS : Solaris 2.3 or 2.4, shared libraries
Widget : Athena
C : gcc 2.7.2
Fortran : f2c 19951025
Perl : perl 4.036
X : X11R5 - OpenWindows
Win Mgr : twm
Display : 24-bit
- Original Rpt:
-
When you select "Shell", it seems like it should invoke an
xterm and put you in the directory specified by "List Files".
For example, if "UIS" is selected, and then "Shell" is
clicked, I would expect for the current directory in the xterm
to be the UIS directory.
- Notes :
- There's disagreement on how this should work. The shell
button was initiall created so users could dbx and
test compiled software from composer, so put it in
the src directory made the most sense. However, the
requested feature is reasonable and brings up a good
point.
Keywords :
TB::oname : DESIGN::composer
- Short Description:
- when compiling from composer, it would be nice to have some
visual feedback that the compile is done via the console
widget or some other means.
Work-Around :
Severity : 10a- Enhancement request
Priority : 2 - High
Reported By : Becky Bishop
Date : 22-Mar-96
HW : Sun Sparc 5
OS : Solaris
Widget : Athena
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- In composer when you compile or make from the "Commands"
subform, it would be nice if there were some interactive
feedback which informed the user when the compile was
finished. One suggestion would be to echo:
COMPILE FINISHED
inside the console object.
Notes :
Keywords : composer, compiling
TB::oname : DESIGN:composer
craftsman
- Short Description:
- spawning off multiple composer processes allowed, but
they are not sychronized
Work-Around : Don't spawn off more than one session on the same object
Severity : 10a - Enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Craftsman will let you spawn off multiple copies of composer
on the same object. This has to wait until something like
tool-talk is available, or at least a simple application-level
IPC.
- Notes :
- This depends on infrastructure enhancements to support
tool and software object locking and IPC.
Keywords :
TB::oname : DESIGN::craftsman
- Short Description:
- strange popup message behaviour when copying software
objects in craftsman
Work-Around :
Severity : 4d- Error message, warning, or prompting, is unclear
Priority : 2 - High
Reported By : Scott Wilson
Date :
HW :
OS : solaris2.4
Widget : OLIT
C : gcc
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Try this on cabernet (solaris2.4-gcc, OLIT):
1. Start craftsman
2. Select the datamanip toolbox
3. Select the kflip object
4. Select Object Operations/Copy Object
5. Using the chooser, Select SCOTTSTB as the destination object
(don't worry about clobbering something in there)
6. Hit the Copy Object button
7. Get an info popup that says "Please Wait". Cool.
8. Watch the info popup go *blank* and remaing that way until
it suddenly disappears. This might be a "flash" of some
kind of text for a fraction of a second just as the thing
goes blank, but I'm not sure.
The object does appear to copy correctly - I think.
- Notes :
- Probably not a composer bug, but should be verified. If
it is a bug it actually uis/widget libraries.
Keywords :
TB::oname : DESIGN::craftsman
- Short Description:
- Add option to regenerate all Imakefile and/or Makefiles
in a toolbox
Work-Around :
Severity : 10a - Enhancement request
Priority : 3 - Medium
Reported By : Donna Koechner
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
In craftsman, it would be a useful toolbox option to
update all Imakefiles and Makefiles in that toolbox.
Notes :
Keywords :
TB::oname : DESIGN::craftsman
- Short Description:
- Under Olit, craftsman software object list scrollbar
disappears making it is impossible to scroll through
the list
Work-Around : "make athena"
Severity : 1d- User cannot proceed with work
Priority : 4 - Low
Reported By : Daniel Talso
Date : 09-Aug-95
HW : SPARCStation 20
OS : Solaris 2.4
Widget : Olit
C :
Fortran :
Perl :
X :
Win Mgr : openwin
Display :
- Original Rpt:
-
Craftsman will not properly display the names of routines in a
toolbox that I created. When six routines are in the list the
scroll bar pushes out slightly to the right. When routine
number ten is added the scroll bar vanishes and it is
impossible to move the list. I have K2.0.2+p2 plus the
8Jun1995 pack and the problem persists.
Reproduce by creating a toolbox, then create new xvroutines for
the toolbox.
- Notes :
- This is a olit list widget problem, and should be listed
in the olit library object.
Keywords :
TB::oname : DESIGN::craftsman
- Short Description:
- Licence access is in non-standard place
Work-Around :
Severity : 5a - Aestetics (types, minor UI inconsistencies, etc)
Priority : 3 - Medium
Reported By : Becky Bishop
Date : 14-Feb-96
HW : Sun SPARC
OS : Solaris 2.3 or 2.4, shared libraries
Widget : Athena
C : gcc 2.7.2
Fortran : f2c 19951025
Perl : perl 4.036
X : X11R5 - OpenWindows
Win Mgr : twm
Display : 24-bit
- Original Rpt:
-
The License is accessable from the "Options" pulldown menu
whereas on many other applications, the license has its own
button that appears in yellow (envision apps). We need to
have consistency one way or the other.
Notes :
Keywords :
TB::oname : DESIGN::craftsman
- Short Description:
- It would be nice if the console window could map itself
when new input arrives
Work-Around : leave console up
Severity : 10a - Enhancement request
Priority : 3 - Medium
Reported By : Becky Bishop
Date : 14-Feb-96
HW : Sun SPARC
OS : Solaris 2.3 or 2.4, shared libraries
Widget : Athena
C : gcc 2.7.2
Fortran : f2c 19951025
Perl : perl 4.036
X : X11R5 - OpenWindows
Win Mgr : twm
Display : 24-bit
- Original Rpt:
-
This is not really a bug but probably a request. The Console
Window is not visible unless you explicitly invoke it from
the "Options" pulldown menu. If an error is encountered,
the user doesn't necessarily know about it unless the cosole
is up. It would be nice if the console could map itself when
new input arrives.
Notes :
Keywords :
TB::oname : DESIGN::craftsman
- Short Description:
- When you copy a library object to another toolbox, the
Imake Configuration file and toolbox include files are
not updated
Work-Around : Remember to do it by hand.
Severity : 10a - Enhancement request
Priority : 2 - High
Reported By : Becky Bishop
Date : 14-Feb-96
HW : Sun SPARC
OS : Solaris 2.3 or 2.4, shared libraries
Widget : Athena
C : gcc 2.7.2
Fortran : f2c 19951025
Perl : perl 4.036
X : X11R5 - OpenWindows
Win Mgr : twm
Display : 24-bit
- Original Rpt:
-
When you copy a library object to another toolbox, the Imake
Configuration file and toolbox include files are not updated.
It would be nice if craftsman could at least issue a warning
message that indicates to manually add these references.
- Notes :
- This really should be solved by updating toolbox.def
file automatically, but for 2.1 it would be sufficient
to do a kinfo with a warning about not forgetting to
do it..
Keywords :
TB::oname : DESIGN::craftsman
- Short Description:
- Icon should default to object name if one is not
specified at creation time.
Work-Around : Use composer to give icon name.
Severity : 10a - Enhancement request
Priority : 2 - High
Reported By : Becky Bishop
Date : 14-Feb-96
HW : Sun SPARC
OS : Solaris 2.3 or 2.4, shared libraries
Widget : Athena
C : gcc 2.7.2
Fortran : f2c 19951025
Perl : perl 4.036
X : X11R5 - OpenWindows
Win Mgr : twm
Display : 24-bit
- Original Rpt:
-
If I try and create a new kroutine and specify "Install in
Cantata?" to 'Yes', it seems that I would have to specify a
Category, Subcategory, and Icon Name. Craftsman won't let me
get away without specifying a Category & Subcategory but it
WILL let me create an object without an icon name. When I
then bring up cantata and traverse the category, subcategory
walking menus, the icon name is blank. If I select the blank
area, it pops up a glyph but there is no icon name label on
it. It seems that craftsman should not let you create a
cantata installed object without an icon name.
Notes :
Keywords :
TB::oname : DESIGN::craftsman
- Short Description:
- If a toolbox or object name is really long, it is
cutoff horizontally by the list widget
Work-Around : Don't make long names
Severity : 4a- Non-standard behavior
Priority : 2 - High
Reported By : Becky Bishop
Date : 14-Feb-96
HW : Sun SPARC
OS : Solaris 2.3 or 2.4, shared libraries
Widget : Athena
C : gcc 2.7.2
Fortran : f2c 19951025
Perl : perl 4.036
X : X11R5 - OpenWindows
Win Mgr : twm
Display : 24-bit
- Original Rpt:
-
If a toolbox or object name is really long, it is cutoff
horizontally by the list widget. It seems like the list
widget should either grow when its children have a certain
size or place a horizontal scroll bar on the list.
- Notes :
- We don't want to limit name sizes, so it needs to
be dealt with in the list widget stuff
Keywords :
TB::oname : DESIGN::craftsman
- Short Description:
- Windows are not tacked - resizing not handled elegantly
Work-Around :
Severity : 5a- aesthetics
Priority : 3 - Medium
Reported By : Danielle Argiro
Date : 18-Mar-96
HW : piglet
OS : OSF 3.0
Widget : Athena
C : gcc
Fortran : f2c
Perl :
X :
Win Mgr : twm
Display : piglet
- Original Rpt:
- The console window of craftsman is not tacked correctly,
so that when you resize the pane with the scrollbar, the
console window doesn't go with it.
To reproduce,
- do something to sent output to the tty, such as
a klint or a make
- select 'Console' from the Options pulldown menu
- use the window manager to resize the Console window.
the pane resizes but the console window doesn't go
with it.
The Master, subforms and panes also need to be
tacked so resizing works as you'd expect.
- Notes:
- I noticed that in initialize.c, around line 132, the
console object is created and tacked to its parent,
the manager object produced by having a [-w] line in
the console.subform file. However, this isn't enough,
because the "gui_info->console->conspane->workspace"
manager object isn't tacked to the pane, and the pane
isn't tacked to the subform. You'll need to tack
gui_info->console->conspane->workspace to the pane
(KMANAGER_TACK_HORIZ | KMANAGER_TACK_BOTTOM),
and the pane to the subform (KMANAGER_TACK_ALL) if you
want this to work. Note that using xvw_parent() is
the easiest way to get to the pane and to the subform
in this case. (do i get half credit for this bug fix?)
Keywords :
TB::oname : DESIGN::craftsman
guise
- Short Description:
- Inconsistency with operation of string toggles
Work-Around :
Severity : 4a- nonstandard behavior
Priority : 4 - Low
Reported By : George Ruban
Date : 9-Feb-96
HW : Sun 4
OS :
Widget : Motif
C :
Fortran :
Perl :
X :
Win Mgr : mwm
Display :
- Original Rpt:
- Creating a string toggle, while the string names that
show up on the form are correct, the ones pased to the
program are 'String1', 'String2', etc.
Basically, We created the 4-member string toggle: FE ALGORITHMS, and named
them. However there seems to be no way to get rei of the 'StringX' labels in
guise, and those are what are being passed to the code as
char *refine_info->FEAlgorithm_val.
Question - why are there 3 strings per member at all? Why isn't one sufficient,
being passed to the code and seen by the user? Essentially that is what happens
on the clui - the command line argument (-i filename) is the same as the
variable seen by the code (char *clui_info->i_file) - and that seems to work.
-F 4.3 1 0 52x1+0+0 +0+0 'Cantata' form
-M 1 1 30x5+0+0 +0+0 'SEA Search Hypothesis Refinement' refine_subform
-P 1 0 50x15+0+0 +0+0 'SEA MSTAR Build Refinement Command Sequence' refine> -H 1 5x1+45+0 'Help' 'Help for Refine' $SEA/objects/xvroutine/SEA_Search_Main/help/refine.doc help
-Q 1 0 6x1+53+0 'Close'
-x 1 0 0 1 0 20.125x1+1+1.5 2 1 1 'For Hypo:' 'list' hypoMode 'Selected' 'All Leaves'
-z 1 0 0 1 0 19x6.5+42+1.5 0 0 -1 0 'Command Sequence' 'display list' stepseq
-T 1 0 0 1 0 16x2+1+4.5 +0+0 1 'REFINEMENT ALGORITHM' 'Integer toggle selection' refineAlgorithm
-i 1 0 1 1 0 10x1+1+1 2 2 1 0 0 'Jacobian-Based ' 'Jacobian-Based ' dummy
-E
-T 1 0 0 1 1 15x5+24+4.5 +0+0 1 'FE ALGORITHMS' 'String toggle selection' FEAlgorithm
-s 1 0 1 1 0 10x1+1+1 'String1' 'FES_PromPeaks1' 'FES_PromPeaks1' dummy
-s 1 0 1 0 0 10x1+1+2 'String2' 'FEE_CoarsePeaks' 'FEE_CoarsePeaks' dummy
-s 1 0 1 0 0 10x1+1+3 'String3' 'FEE_FinePeaks1' 'FEE_FinePeaks1' dummy
-s 1 0 1 0 0 10x1+1+4 'String4' 'FEE_FinePeaks2' 'FEE_FinePeaks2' dummy
-E
-T 1 0 0 1 0 11x2.5+1+7 +0+0 1 'FEATURE TYPE' 'Integer toggle selection' featureType
-i 1 0 1 1 0 10x1+1+1 2 2 1 0 0 'FT_PEAK' 'FT_PEAK' dummy
-E
-a 1 0 9x1+47+8.5 'ADD STEP' 'action button' addStep
-a 0 0 9x1+47+10 'EDIT STEP' 'action button' editStep
-l 1 0 0 1 0 15x1+1+11 0 'Pose x' 'False' 'True' 'logical' poselogic1
-l 1 0 0 1 0 15x1+19+11 0 'Pose oz' 'False' 'True' 'logical' poselogic4
-a 1 0 9x1+47+11.5 'CLEAR' 'action button' clearCommand
-l 1 0 0 1 0 15x1+1+12.5 0 'Pose y' 'False' 'True' 'logical' poselogic2
-l 1 0 0 1 0 15x1+19+12.5 0 'Pose oy' 'False' 'True' 'logical' poselogic5
-a 1 0 11x1.5+46+13.5 'EXECUTE' 'action button' executeCommandSequence
-l 1 0 0 1 0 15x1+1+14 0 'Pose z' 'False' 'True' 'logical' poselogic3
-l 1 0 0 1 0 15x1+19+14 0 'Pose ox' 'False' 'True' 'logical' poselogic6
-b +1+10 'REFINE POSE VARIABLES' blank1
-b +1+3 '----------------BUILD STEP COMMAND ---------------' blank2
-b +42+14 'DONE' blank3
-E
-E
-E
Notes :
Keywords :
TB::oname : DESIGN::guise
- Short Description:
- Would like to revamp GUI for GUISE
Work-Around :
Severity : 10a- enhancment request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Would like to revamp GUI for GUISE. Unsure how at this
point.
Notes :
Keywords : guise, GUI
TB::oname : DESIGN:guise
- Short Description:
- When using "Edit Manually", subforms that are subordinate
to a master form will unmap and maps, but won't place
themselves automatically
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- When using "Edit Manually", the subform unmaps and maps,
but doesn't place itself automatically. To reproduce:
1. run guise with no command-line arguments
2. hit "CREATE MASTER"
3. hit "EDIT MANUALLY"
4. change something in the UIS from the text editor, and
write the file out, without quitting.
5. The master unmaps and maps, placing itself
automatically; the subform unmaps and maps, but
doesn't place itself automatically
- Notes :
- Severe nastyness wrt implementation;
xvf_subform_geometry to be called on all subforms in
master subform list, x & y vals saved in an array,
kvf_create_form called instead of xvf_create_form, so
that you can see if you need to call xvf_create_subform
separately specifying the old X & Y values (major pain).
Keywords :
TB::oname : DESIGN::guise
- Short Description:
- Directory to which output files go when called from
within craftsman is not intuitive
Work-Around : Check [-k] references generated in UIS files for
correctness; edit manually if appropriate.
Severity : 4b- Minor inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- I was running guise from the uis/ directory of craftsman.
After adding a subform, I brought up the internal form,
and specified a filename "console.subform".
An info window appeared, telling me that the subform was
written to:
/usr/tmp/console.subform
On checking, craftsman.form had a line:
-k /usr/tmp/console.subform
Maybe in this case, guise should default to the current
directory. It could also check to see whether the current
directory is in a toolbox, and use a tb-relative path.
Notes :
Keywords :
TB::oname : DESIGN::guise
- Short Description:
- Options menu left empty when creating master
Work-Around : Move [-H] UIS line defining license button into
[-D to -E] submenu definition of options button
using a visual editor
Severity : 4a- nonstandard behavior
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Options menu is left empty when creating master.
To reproduce:
1. create an xvroutine
2. edit the xvroutine's form with guise
3. create master
4. the License file selection is moved to the new master,
but the Options menu which contained it is left on the
subform, and is now empty.
Notes :
Keywords :
TB::oname : DESIGN::guise
khelp
preview
runwksp
- Short Description:
- When running an encapsulated workspace having 1 input
file selection on its workspace GUI, you cannot change
the input file value from its original default
Work-Around :
Severity : 1d- User cannot proceed with work
Priority : 2 - High
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Encapsulated Workspace Command Line Bug:
Write out an encapsulated workspace having 1 input file
selection on its workspace GUI. When running the workspace
from the command line, you cannot change the input file value
from its original default.
Notes :
Keywords :
TB::oname : DESIGN::runwksp
xvregister
- Short Description:
- License screen pops up larger than the screen area.
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 2 - High
Reported By : Tom Konerth
Date : 1-Apr-96
HW : Alpha
OS : OSF 1.3
Widget : Athena
C : gcc
Fortran :
Perl :
X :
Win Mgr : twm
Display : piglet
- Original Rpt:
- After filling out the register program, the license
window pops up and is off the screen at the top and the
bottom. I can't even get to the resize icon with twm to
change it. I would prefer a normal sized window that I
scroll to view all of it.
Notes :
Keywords :
TB::oname :
- Short Description:
- Too many popups
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 4 - Low
Reported By : Tom Konerth
Date : 11-Apr-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- When running xvregister, there are 4 pop-ups that
are displayed. These should be combined somehow.
Notes :
Keywords : registration
TB::oname : DESIGN::xvregister
xvrun
kcat
Athena
- Short Description:
- Caplock keys disables GUI
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Becky Bishop
Date : 22-Mar-96
HW : Sun Sparc 5
OS : Solaris
Widget : Athena
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- If you turn on caps-lock and then try to select an item
from pulldown menus, the user interface does not respond.
Notes :
Keywords :
TB::oname : DESIGN:Athena
- Short Description:
- Athena text selections do not scroll when the text exceeds
the size of the widget. Text appears to be cut off even
though it is not.
Work-Around : Make text entry selections larger or ignore the fact that
you can't type as your text is really being saved.
Severity : 3a- Major inconvenience
Priority : 3 - Medium
Reported By : Becky Bishop
Date : 22-Mar-96
HW : Sun Sparc 5
OS : Solaris
Widget : Athena
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- The Athena widget set appears like it cuts off text if
the text is longer than the size of the widget. It
does not scroll like the Motif text widget does. This
brings up a usuability issue.
Notes :
Keywords : Athena, text widget
TB::oname : DESIGN:Athena
- Short Description:
- Can't easily delete the last character in the Athena
text parameter box (widget set bug)
Work-Around : Use the arrow buttons to the right of your keyboard to
move to the end of the string, then use the "delete"
button to delete characters as desired. You can also
highlight all the text, and then hit ^W, which will delete
all the text in the window.
Severity : 3a- Major inconvenience
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- It is difficult, sometimes impossible to delete the last
character, or a single character in a text parameter box;
you cannot use the mouse to place the cursor at the end of
the string it order to delete the character.
To get around this, use the arrow buttons to the right of
your keyboard to move to the end of the string, then use
the "delete" button to delete characters as desired.
You can also highlight all the text, and then hit ^W,
which will delete all the text in the window.
- Notes :
- This is a bug in the Athena widget set itself; it is
not something that we can fix in Khoros code.
Keywords : Athena
TB::oname : DESIGN::Athena
Motif
- Short Description:
- Motif list not relaying out correctly.
Work-Around :
Severity : 5a- Aesthetics (typos, minor UI inconsistencies, etc)
Priority : 4 - Low
Reported By : Donna Koechner
Date : 02-Apr-96
HW : spud
OS : solaris 2.5
Widget : motif
C : cc
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- The version of Motif on spud (which assume is
some 1.2.X version) the list for the browser
does not update correctly. When the contents
of the list is smaller than the list, then the
vertical scrollbar disappears, but the list is
not resized. So you get this weird 20 pixel
wide column where the vertical scrollbar use to be.
Notes :
Keywords : Motif spud dud
TB::oname : design::Motif
- Short Description:
- Sometimes text boxes don't have insertion cursors in the
various entries. This makes it hard to figure out where the
text you type in is going to end up.
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 2 - High
Reported By : Scott Wilson swilson@khoral.com
Date : 8-Mar-96
HW : fresca
OS : irix
Widget : motif
C :
Fortran :
Perl :
X : X11R6 (accelerated X on glacier)
Win Mgr : twm
Display : glacier:0
- Original Rpt:
- kodiak (and mirage too) do not have an insertion cursor
displayed in out various text entry areas in the forms when
running on fresca, either locally (on the console) or
displayed to glacier. Running from zen shows no problem.
To repeat:
1. Start cantata
2. Get a kresample glyph.
3. Open the pane for the glyph and see of there are insertion
cursors present.
Notes :
Keywords :
TB::oname : DESIGN::Motif
- Short Description:
- When using Motif and changing the text object from
multiline to single line (or vice versa) the cursor
position and the text that is displayed becomes corrupted
(widget set bug)
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- When you change a text object from multiline to single
line, or single line to multi-line, the cursor position
and the text that is displayed becomes corrupted,
although if queried, the widget will report the full
(original) contents of the text.
- Notes :
- This seems to be a bug in the widget set itself;
it is in spite of setting XmNcursorPosition to 0,
XmNtopCharacter to 0, and XmNautoShowCursorPosition to
TRUE. It still might, however, be worth trying to find
a workaround. It's just that there might not be one.
Keywords : Motif
TB::oname : DESIGN::Motif
- Short Description:
- On SGI running Irix 5.2 and 5.3, with Motif 1.2.4,
many programs will seg fault, xprism will crash, etc.
Work-Around :
Severity : 1a- Seg fault, core dump
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
Original Rpt:
- Notes :
- On SGI running Irix 5.2 and 5.3, with Motif 1.2.4,
a variety of programs will crash with a seg fault,
including most of the plotting example programs, xprism,
and others.
To the best of our knowledge, this is not something we
can fix. The 1.2.4 version of SGI Motif installs it's
own "optimized" SetValues method, which calls a routine
called _SG_XtSetValuesCleanup(). This function apparently
makes a call to a nonexistent function, causing the
calling application to seg fault or bus error on startup.
We have not been able to find a bug fix at SGI which
fixes this. At this point, our best suggestion is to
use the Athena widget set instead of the Motif widget
set, since Athena does not suffer from this problem.
Alternatively, if you really want to use Motif, you may
try upgrading upgrade to Irix 6.2, which we believe
includes Motif 2.0 rather than Motif 1.2.4. Although we
have not yet verified it, we believe that the bug may be
fixed in the new version of Motif.
Another option if you have an OSF source contract is to
compile Motif 1.2.4 yourself and fix the bugs.
In addition to the problem with _SG_XtSetValuesCleanup(),
there are some uninitialized variable reads and other such
mistakes which can lead to obscure crashes.
Keywords : Motif
TB::oname : DESIGN::Motif
Olit
- Short Description:
- You cannot remote display to a non-SUN architecture
when using the OLIT widget set; applications will
segmentation fault.
Work-Around : Display only on Sun workstations running OpenWindows
when using the Olit widget set
Severity : 4b- Minor inconvenience
Priority : 5 - None
Reported By : Danielle Argiro
Date : 14-May-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display : Dec Alpha
- Original Rpt:
- When using Olit, you must display locally or to
a SUN workstation running OpenWindows.
Notes :
Keywords : OLIT, olit
TB::oname : DESIGN::Olit
- Short Description:
- With the OLIT widget set, clicking the mouse button
in a string widget causes Olit to grab the mouse focus,
and keep it until the window goes away, or until you do
an unfocus from your window manager
Work-Around :
Severity : 3a- Major inconvenience
Priority : 5 - None
Reported By :
Date :
HW : Dudley, piglet
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Clicking the mouse button in a string widget causes Olit
to grab the mouse focus, and keep it until the window
goes away, or until you do a unfocus from your window
manager.
- Notes :
- This is a bug in the widget set itself
Keywords : OLIT, olit
TB::oname : DESIGN::Olit
- Short Description:
- With the OLIT widget set, certain pulldown menus will go
away before you can select something
Work-Around : Move the mouse REALLY fast from the pulldown button to
the pulldown menu
Severity : 3a- Major inconvenience
Priority : 5 - None
Reported By :
Date :
HW : SGI, DEC alpha
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Certain pulldown menus (like the ones in craftsman of
categories and subcategories) will go away before you can
select something unless you move the mouse REALLY fast
from the pulldown button to the pulldown menu.
- Notes :
- This is a bug in the widget set itself
Keywords : OLIT, olit
TB::oname : DESIGN::Olit
- Short Description:
- With the Olit widget set, when an xvroutine is
displayed to a DEC there are occasional problems with
resize refresh (bug in widget set)
Work-Around : This condition can be fixed by resizing or moving the
window
Severity : 4b- minor inconvenience
Priority : 5 - None
Reported By :
Date :
HW : SGI, DEC Alpha
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- When a Khoros xvroutine using the OLIT widget set is
displayed to a DEC Alpha, there are occasional problems
with resize refresh. For example, when using guise to
create a new selection on a pane in such a way that the
pane is forced to grow in order to accommodate the new
selection, the new selection may be partially or totally
"blanked out"; this condition can be fixed by resizing
or moving the window.
- Notes :
- This is a bug in the widget set itself
Keywords : OLIT, olit
TB::oname : DESIGN::Olit
kwidgets
xvforms
- Short Description:
- Selection of nested groups is controlled by the outside
group; would be nice if it could be controlled by the
inside group, too.
Work-Around : When selecting a member of a group, use the inside
group members.
Severity : 10a- enhancement request
Priority : 5 - None
Reported By : Eric Ellis
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Selection of nested groups is controlled by the outside
group; would be nice if it could be controlled by the
inside group, too (not for 2.1).
- Notes :
- This is going to be a difficult enhancement.
Keywords : groups
TB::oname : DESIGN::xvforms
- Short Description:
- Applications should not have to update GUI Info struct
in addition to making calls to xvf_set_attribute(s)().
Work-Around :
Severity : 10a- enhancement request
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- In an xvroutine, when you call xvf_set_attribute(s)()
to set XVF_FILE_NAME, XVF_STRING_VAL, or anything else
that changes a value in the GUI Info struct, it would
be nice if you didn't also have to remember to change the
value of the GUI info struct field directly. Forgetting
to set the values is often a source of bugs in xvroutines.
- Notes :
- PROBLEM: How should xvforms (a library) modify the values
of a structure that is defined by the calling application?
Setting selection->modified to TRUE won't work... there
simply doesn't seem to be any easy solutions. So far
we have made 3 attempts to fix this problem, and ended
up backing out of it because it introduced an unacceptable
level of instability.
Keywords : GUI info structure
TB::oname : DESIGN::xvforms
- Short Description:
- Would like the forms to support interactive creation
of integer, float, and double toggles with non-standard
values. Ie, values that don't necessarily start at 1,
are not necessarily incremental or positive.
Work-Around : Edit UIS file using visual editor.
Severity : 10a- enhancement request
Priority : 5 - None
Reported By : Dave Modl
Date : 04-Mar-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- I am trying to create a set of integer toggles that
range from negative values to positive values, but when
I set the value of the integer widget inside the toggle
to a number less than or equal to '0' I get error mesgs:
Toolbox: DESIGN
Program: guise
Library: kforms
Routine: kvf_check_double
Invalid double -30 provided for GUI selection
'-30'; double value must be > 0.0
- Notes :
- Make xvf_set_toggle_members() more complicated, robust
Keywords : Toggle
TB::oname : DESIGN::xvforms
- Short Description:
- Add appdefaults config info to internal menuforms
Work-Around :
Severity : 10a- Enhancement request
Priority : 4 - Low
Reported By : Becky Bishop
Date : 22-Mar-96
HW : Sun Sparc 5
OS : Solaris
Widget : Athena
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- It would be nice if the internal menu form for each GUI
object creatable through guise would also allow you to
specify app-default type information. For example when
you create a button, you might like to specify if the
button should appear in a specified color. Once the
internal menu form is close, it would be cool if all
the app-defaults info specified on the form could be
authomatically written out to an app-defaults file for
the application.
Notes :
Keywords : app-defaults, guise, internal menuforms
TB::oname : DESIGN:xvforms
xvgraphics
- Short Description:
- (K1.0.5) strange xprism labels (fix provided in report)
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 5 - None
Reported By : mnickel@inbit.ibt.unit.no (Michael)
Date : 11-Sep-92
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Yesterday, I began to dig into the depth of the khoros routines
and found the 'corrupted' routine: X2D_draw_text().
It is not surprising that You hardly will be able to reproduce
this problem because there is no bug in this routine. What
happened was that the values from the
Coord wc_min
variable were overwritten from one step to the next without
any reason. This occurred in the switch construction
switch (graphics->justify)
{
case LeftJustify:
wc_min.x = coord.x - width/2.0;
break;
case CenterJustify:
wc_min.x = coord.x - (width * size/2.0) -
(width * spacing * size/2.0);
.
.
.
The expression coord.x - (width * size/2.0) -
(width * spacing * size/2.0)
was calculated correctly as f.e. -0.359333 .
But as soon wc_min.x was assigned, it changed to
4097816909420440751628556407741303545063814273603191864493085394659021137630986240.00000.
I fixed my problem in introducing four new variables
Real wcminx, wcminy, wcmaxx, wcmaxy;
These replaced wc_min.x , ... , wc_max.y .
Just before
if(!(X2D_convert_point_wc_to_dc(id, wcmin, &xmin, &ymin)))
return;
if(!(X2D_convert_point_wc_to_dc(id, wcmax, &xmax, &ymax)))
return;
I resubstituted
wc_min.x=wcminx;
wc_min.y=wcminy;
wc_max.x=wcmaxx;
wc_max.y=wcmaxy;
and this worked.
I have no idea why this side effect occurs but if You might
have an idea, please, let me know.
Notes :
Keywords :
TB::oname : DESIGN::xvgraphics
- Short Description:
- Bug in X3D_bezier_surface (K1.0.5) (fix provided in report)
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 5 - None
Reported By : steve@borris.eece.unm.edu
Date : 11-May-92
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
This routine draws a bezier surface patch. The problem is
in the declaration of an array of control points. The
declaration is:
Coord control[4];
And the routine uses control[0] thru control[15]. So,
the fix is:
Coord control[16];
Notes :
Keywords :
TB::oname : DESIGN::xvgraphics
- Short Description:
- XPRISM3 (K1.0.5) on SGI - malloc for the XSegment structures is failing
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 5 - None
Reported By : Danielle Argiro
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
XPRISM3 on SGI: input plot3D:example3.0 as a contour plot.
its fine. then go to the Contours pane of the Options
subform. Click on SET CONTOUR INFO followed by GENERATE
Contours Automatically, and finally PLOT Contour 3D. You get
the error message: "X3D_display_contour: not enough memory"
even though the contour plot seems fine. apparently the
malloc for the XSegment structures is failing. (danielle, 5/9)
Notes :
Keywords :
TB::oname : DESIGN::xvgraphics
- Short Description:
- in xprism2 (K1.0.5) the polymarker plots are incorrect
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 5 - None
Reported By : mathew@elroy.jpl.nasa.gov
Date : 29-Jul-91
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
problem with polymarker
in xprism2 the polymarker plots are incorrect. Duplicate by
plotting the same data repeatedly. Plots 2(triangle) 5 and 7
and maybe others are not in the same position as the other
plots.
Notes :
Keywords :
TB::oname : DESIGN::xvgraphics
- Short Description:
- XPRISM3 (K1.0.5) mesh plot not drawn correctly
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 5 - None
Reported By : Dr. Don Hush
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Dr. Don Hush reported a bug about xprism3 not correctly
drawing mesh plots when rotating about a 3d plot. The
graphics library incorrectly draws front to back, instead
of back to front for certain rotations. (2/26)
Notes :
Keywords :
TB::oname : DESIGN::xvgraphics
- Short Description:
- xprism3 (K1.0.5) perspective bug (annoying)
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 5 - None
Reported By : @m2xenix.psg.com,@quagga.ru.ac.za:VDPOEL@dsp.sun.ac.za
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
The prespective transformation is incorrect (i.e the lines
that are supposed to be further away are longer than the
lines which are supposed to be closer to the view point).
The hidden-surface (or -line) removal works incorrectly
(probably because of the perspective bug). It seems that the
hidden-surface removal is done by determining which corner
of the cube is furthest from the viewer and then starting to
draw the polygons from there. The problem is that from certain
viewing angles it starts drawing the polygons from the front
or side (relative to the viewer); this causes it to draw
polygons that are further away on top of polygons that are
closer!
The perspective tool does not allow keyboard entry of angles.
Reproduce By:
Run xprism3, draw a mesh surface and view from all sides.
Notes :
Keywords :
TB::oname : DESIGN::xvgraphics
xvisual
- Short Description:
- Pseudocolor object causes X protocol error on SGI/Irix5.2
for $ENVISION/examples/color/pseudo/* example programs
Work-Around :
Severity : 1a- X protocol error
Priority : 1 - Mandatory
Reported By : danielle
Date : 2/28/96
HW : SGI
OS : Irix 5.2
Widget : Motif
C :
Fortran :
Perl :
X :
Win Mgr :
Display : fresca
- Original Rpt:
-
X Error of failed request:
BadMatch (invalid parameter attributes)
Major opcode of failed request:
2 (X_ChangeWindowAttributes)
- Notes :
- This bug is an instance of the bug with the description,
"Setting XVW_COLOR_COLORFILE or XVW_COLOR_COLOROBJ directly
on a pseudo or threshold display will cause incorrect
display of the colormap on a 24-bit display."
Keywords : pseudocolor
TB::oname : DESIGN::xvisual
- Short Description:
- Palette object created with NULL parent is displayed
with incorrect default sizing
Work-Around :
Severity : 2a - Incorrect behavior
Priority : 3 - Medium
Reported By : Danielle Argiro
Date : 16-Apr-96
HW : all
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Palette is coming up initially with bogus size when
created with NULL parent. To reproduce:
% cd $ENVISION/examples/color/palette/1.palette_display
% example
The palette that is displayed is about 1 pixel wide and
10 pixels high.
Notes :
Keywords : palette
TB::oname : DESIGN::xvisual
- Short Description:
- Problems with running out of colorcells even when
specifying private colormap
Work-Around :
Severity : 2a - Incorrect behavior
Priority : 3 - Medium
Reported By : Danielle Argiro
Date : 3-Jul-96
HW : Dec Alpha (piglet & water)
OS : OSF/1 3.2
Widget : Motif
C : native C
Fortran : f77
Perl : perl 4.036
X : X11R5
Win Mgr :
Display :
- Original Rpt:
- have some color intensive something up, like editimage
with image:ball or mandril.
% editcmap -pseudo -priv true -alloc 2 -i image:ball
-o hello.out
for instance. i got all black colorcells. once i
loaded something not as color intensive (image:colortest)
the colors could be changed.
Notes :
Keywords : private colormap
TB::oname : DESIGN::xvisual
- Short Description:
- 3D plots often redraw themselves 2 or 3 times on
exposure events.
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 3 - Medium
Reported By : Danielle Argiro
Date : 16-Apr-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- 3D plots tend to redraw themselves 2 or 3
times on exposure events.
We already tried to fix this once (April 16) by
putting this line in the Plot3D Refresh() routine:
if (!xvw_check_visible(xvw_object(widget))) return;
However, it was later discovered that this causes
putplot3 and several of the example programs not to
display their plots initially at all; plots were
refreshed only when the plot type or other attribute
was changed via the menuform.
Notes :
Keywords : plotting, 3D plot
TB::oname : DESIGN::xvisual
- Short Description:
- Would like quality Postscript output for 2D Plots,
2D Axes, 3D Plots
Work-Around :
Severity : 10a- Enhancement request
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Would like to have quality Postscript output for:
- 2D Plots
- 2D Axes
- 3D Plots
Notes :
Keywords : 2D plot, 3D plot, 2D axis, postscript
TB::oname : DESIGN::xvisual
- Short Description:
- When Axis label goes away because area is too small, it
does not come back when window is resized
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Becky Bishop
Date : 14-Feb-96
HW : Sun SPARC
OS : Solaris 2.3 or 2.4, shared libraries
Widget : Athena
C : gcc 2.7.2
Fortran : f2c 19951025
Perl : perl 4.036
X : X11R5 - OpenWindows
Win Mgr : twm
Display : 24-bit
- Original Rpt:
-
When Plotting multiple areas, eventually, you get so many
plot areas in the display that the "X Axis" label goes away
because there is not enough space to display it. But, when
you resize xprism using the window manager, the label is
still not displayed even though there is adequate space to
display it.
Notes :
Keywords : 2D axis
TB::oname : ENVISION::xprism, DESIGN::xvisual
- Short Description:
- Displaying date can overwrite the "X Axis" label if the
plot area is too small
Work-Around : Resize plot area to be larger
Severity : 4b- minor inconvenience
Priority : 4 - Low
Reported By : Becky Bishop
Date : 14-Feb-96
HW : Sun SPARC
OS : Solaris 2.3 or 2.4, shared libraries
Widget : Athena
C : gcc 2.7.2
Fortran : f2c 19951025
Perl : perl 4.036
X : X11R5 - OpenWindows
Win Mgr : twm
Display : 24-bit
- Original Rpt:
-
On the "Defaults" pane when changing "Date For New Areas" to
displayed, it can overwrite the "X Axis" label if the plot area
is too small (i.e. when adding multiple areas, the size of the
xprism work area remains the same so plot areas have to get
smaller to fit).
Notes :
Keywords : 2D axis
TB::oname : DESIGN::xvisual, ENVISION::xprism
- Short Description:
- Xaxis label is somewhat garbled and difficult to read for
plots with large range along x axis
Work-Around :
Severity : 3a- Major inconvenience
Priority : 3 - Medium
Reported By : Becky Bishop
Date : 14-Feb-96
HW : Sun SPARC
OS : Solaris 2.3 or 2.4, shared libraries
Widget : Athena
C : gcc 2.7.2
Fortran : f2c 19951025
Perl : perl 4.036
X : X11R5 - OpenWindows
Win Mgr : twm
Display : 24-bit
- Original Rpt:
- For some plots that have a large range along the x axis
(Actual Displayed Range Max = 1023), the xaxis label is
somewhat garbeled and difficult to read. However for
floating point ranges with just as many digits (i.e.
4.06094), things are fine.
Notes :
Keywords : 2D axis
TB::oname : DESIGN::xvisual, ENVISION::xprism
- Short Description:
- Would like quality Postscript output for Annotations
Work-Around :
Severity : 10a- Enhancement request
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Would like to have quality Postscript output for current
annotations: Circle, Date, Ellipse, Marker, Line,
Rectangle, Polyline, String, StringValue, Timer
Notes :
Keywords : annotations, postscript
TB::oname : DESIGN::xvisual
- Short Description:
- Want "Nice Labels" for 2D axis object
Work-Around :
Severity : 10a- Enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Want "Nice Labels" for 2D axis object.
"Nice Labels" would be the capability of the 2D axis
object to label itself with pretty, or "nice" numbers;
for example, a minimum label might appear as 5 rather
than the exact value of 4.81798223.
This capability was originally planned for the 2D axis
object, but the first implementation never got past the
prototype stage and was taken out since it didn't work
correctly.
We'd like to eventually put this capability back into
the 2D axis object.
Notes :
Keywords : 2D axis
TB::oname : DESIGN::xvisual
- Short Description:
- Want "Proportional Plotting" for 2D axis object
Work-Around :
Severity : 10a- Enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Want "Proportional Plotting" for 2D axis object, in
addition to the current method of nonproportional
plotting.
"Proportional Plotting" means that the scale on both
axes is identical, making the plot appear proportional.
This is as opposed to the current, non-proportional
display of axes where each axis goes from the min to the
max on that coordinate, so that you can get for example
0 - 100 on one axis, and 0 - 1 on another axis, but they
are the same size.
There is also the question of "windowed" vs. "nonwindowed"
proportionality (see John Salas).
This capability was originally planned for the 2D axis
object, but the first implementation never got past the
prototype stage and was taken out since it didn't work
correctly.
We'd like to eventually put this capability back into
the 2D axis object.
Notes :
Keywords : 2D axis
TB::oname : DESIGN::xvisual
- Short Description:
- App-defaults confusion with regard to
XVW_AXIS_AXIS_COLOR vs. XVW_AXIS_AXIS_PIXEL
(need to follow existing convention w/ converter).
Work-Around :
Severity : 4b- Minor inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- App-defaults confusion with regard to
XVW_AXIS_AXIS_COLOR vs. XVW_AXIS_AXIS_PIXEL
(need to follow existing convention w/ converter).
Notes :
Keywords : 2D axis
TB::oname : DESIGN::xvisual
- Short Description:
- Would like to have convenience attributes
XVW_AXIS2D_XAXIS_LABEL and XVW_AXIS2D_YAXIS_LABEL
Work-Around :
Severity : 10a- enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Would like convenience attributes
XVW_AXIS2D_XAXIS_LABEL and XVW_AXIS2D_YAXIS_LABEL;
this would allow you to set labels on the X axis and
Y axis without first extracting the xvobjects from
the 2D axis object.
Notes :
Keywords : 2D axis
TB::oname : DESIGN::xvisual
- Short Description:
- Would like 2D Axis Minor Tic Marks to Work
Work-Around :
Severity : 10a- enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- The 2D Axis minor tic marks somehow got broken,
so we disabled support for them in the menuforms.
Would like to get them working again and put them
back into the system.
Notes :
Keywords : 2D axis
TB::oname : DESIGN::xvisual
- Short Description:
- With the palette object, when you set "Show Palette"
to FALSE using the menuform, you get a space where the
palette used to be
Work-Around :
Severity : 5a- Aesthetics
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- With the palette object, when you set "Show Palette"
to FALSE using the menuform, you get a space where the
palette used to be. The object should shrink to not
show this space, and grow back accordingly when you set
"Show Palette" back to TRUE.
Solution 1: Kludge Initialize code to get it to work
Solution 2: General fix to manager object w/ initial
sizing of children (can't do this for 2.1)
Solution 3: don't worry about it, it's pretty minor.
Notes :
Keywords : palette
TB::oname : DESIGN::xvisual
- Short Description:
- The colorcell palette by default comes up with the
cells too small to be useful
Work-Around : Use the window manager to resize the window, then it
will resize itself properly
Severity : 2a - Incorrect behavior
Priority : 4 - Low
Reported By : Becky Bishop
Date : Dec 19, 1995
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- The internal menu form for the "pallete" object allow
you to toggle between color bar, color cell, and color
wheel. There seems to be a size problem with the
"color cell". Try the following:
% putpalette -i image:mandril
% Select the "Options" button
% toggle "Palette Type" to "Color Cell"
The cells are so small that you can't see the colors
displayed. If you re-size the entire window with the
window manager, the size of the cells grow and then you
can see the colors.
Notes :
Keywords : palette
TB::oname : DESIGN::xvisual, ENVISION::editcmap
- Short Description:
- Palette of threshold is black & image goes black
for image:tank_big
Work-Around : Click on "Invert Region" to set it to True rather
than False; the image will appear correctly as long
as "Invert Region" is set to True.
Severity : 2a - Incorrect behavior
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Run % editimage -i image:tank_big. Open Thresholding
subform. Palette of threshold is black, and then
the entire image goes black. Set "Invert Region" to
True; image appears normally; set "Invert Region" to
False; image goes black again.
Notes :
Keywords : threshold, image
TB::oname : DESIGN::xvisual
- Short Description:
- When you specify the position of the zoom object,
you are specifying the position of the upper right hand
corner of the zoom window. It would be much more
intuitive to specify the zoom focus (ie, the middle of
the zoom window where the location marker appears).
Work-Around :
Severity : 10a- enhancement request
Priority : 4 - Low
Reported By : Danielle Argiro
Date : 05-Apr-96
HW : zen
OS : solaris
Widget : motif
C : cc
Fortran :
Perl :
X :
Win Mgr : twm
Display : piglet
- Original Rpt:
- When you specify the position of the zoom object,
you are specifying the position of the upper right hand
corner of the zoom window. It would be much more
intuitive to specify the zoom focus (ie, the middle of
the zoom window where the location marker appears).
- Notes :
- This was actually fixed in the Zoom object, in xvisual.
Keywords : zoom position
TB::oname : ENVISION::putzoom
- Short Description:
- Pseudocolor colorcell palette sometimes has one white
cell at the very end that isn't actually tied to any
of the pixels in the image.
Work-Around : Don't let it bother you. Just ignore it.
Severity : 4b- minor inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Pseudocolor colorcell palette sometimes has one white cell
at the very end that is "false", ie, it doesn't seem to be
tied to any of the pixels in the image.
% editimage -i image:tank_big
Solution 1:
- Create a button gadget (mark has prototype)
- Rewrite palette object to use the button gadget, this
will simplify the code significantly, and get rid of
this bug & potential others.
Solution 2:
- Fix calculation of indx returned by the GetInfo()
function. Note hairy code.
- Notes :
- document this (preferably FAQ)
Keywords : pseudo, palette, document
TB::oname : DESIGN::xvisual
- Short Description:
- Printpixel object does not yet know to recognize clip mask
Work-Around :
Severity : 10a- Enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Printpixel object does not know to recognize clip mask.
Would like printpixel display to work with a clip mask
on the image (need a XVW_PRINTPIXEL_CLIPFILE attribute).
Possibility:
Get rid of support for separate clip mask in image object.
You can always get the same effect w/ mask segment.
Not only can you get the same effect by pre-processing
with datamanip, but this will alleviate a great deal of
work.
Notes :
Keywords : printpixel, clip mask
TB::oname : ENVISION::editimage, DESIGN::xvisual
- Short Description:
- Printmapval object doesn't yet know to recognize clip mask
Work-Around :
Severity : 10a- Enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Printmapval object does not know to recognize clip mask.
Would like printmapval display to work with a clip mask
on the image (need a XVW_PRINTPIXEL_CLIPFILE attribute).
Possibility:
Get rid of support for separate clip mask in image object.
You can always get the same effect w/ mask segment.
Not only can you get the same effect by pre-processing
with datamanip, but this will alleviate a great deal of
work.
Notes :
Keywords : printmapval, clip mask
TB::oname : DESIGN::xvisual
- Short Description:
- With a complex, RGB image, printmapval does not have
correct background colors
Work-Around :
Severity : 2a- incorrect behavior
Priority : 4 - Low
Reported By : Danielle Argiro
Date : March 5, 1996
HW : Sun SPARC
OS : zen
Widget : Motif
C :
Fortran :
Perl :
X :
Win Mgr : twm
Display :
- Original Rpt:
- With a complex, RGB image, printmapval does not have
correct background colors. Use example program
$DESIGN/examples/printmapval with ./ankle_RGB.viff
Notes :
Keywords : printmapval, RGB image
TB::oname : DESIGN::xvisual
- Short Description:
- Position Object doesn't yet support different
complex conversion types.
Work-Around :
Severity : 10a- Enhancement request
Priority : 3 - Medium
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Position Object yet doesn't support different complex
conversion types. Want to add an attribute to the
position object, XVW_POSITION_COMPLEX_CONVERT, that will
allow specification of the complex conversion type,
instead of hardwiring the complex conversion type.
Default should be KLOGMAGP1.
Test: take the FFT of moon.xv and display it using
putimage. You get a readout at the bottom with the
complex pixel value. Go into the options and change the
conversion to say Phase. The pixel readout *remains* a
complex number, instead of becoming the phase, as
specified.
Notes :
Keywords : position
TB::oname : DESIGN::xvisual
- Short Description:
- Color is not always set correctly with a ReadWrite Visual
when the display is out of colors
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Color is not always set properly with a ReadWrite Visual
when the display is out of colors (POST 2.1).
Need to rewrite the colorcell object completely:
Modification of colorcell to be completely controlled by
the RGB values with optional index specification rather
than the current implementation, which has the opposite
case: required index specification and optional RGB value
specification
Notes :
Keywords : colorcell, color cell, readwrite visual
TB::oname : DESIGN::xvisual
- Short Description:
- Colormap not correct
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Roberto A Lotufo
Date : Jan 31, 1996
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- I created a pseudo color table for the spine image.
The color table size is H=1202 W=3; the spine image is
float, ranging from 1024 to 1862. (so there are some
indexes that will not be find in the map table)
So, the color table is smaller than the range of the
data, and also the data pixels are in float.
1. applying the colortable to the image in the putimage:
the display is black.
2. same as 1, but converting the image to unsigned short:
the display is ok, but the colors are corrupt at higher
values
3. inserting the map segment into the spine data:
if the data is float: black display
if the data is unsigned short: the display is ok,
THIS IS THE CORRECT.
4. mapping the map through the data:
if the data is float or unsigned short:
the display shows a colored noisy image.
You can check this in the workspace:
~lotufo/WORKSPACE-BUGS/putimage-spine-palette.wk
Notes :
Keywords : color class
TB::oname : DESIGN::xvisual
- Short Description:
- The algorithm used to obtaining the closest color when
display is out of colors could be improved.
Work-Around :
Severity : 10a- enhancement request
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- When finding the closest color when display is out of
colors, we only search on previously allocated colors
in the XColor array of the image object.
We already do find the closest color when display is out
of colors, by doing a minimal distance algorithm, but we
only search on previously allocated colors in the XColor
array of the image object. It would be better, on
failure to allocate a color, to search the entire (screen)
Colormap for the closest color.
Algorithm for ReadWrite Color Allocation Policy:
- leave it exactly the way it is now
Algorithm for ReadOnly Color Allocation Policy:
- Use XQueryColors to see what colors are currently in use on
the screen
- Alter the RGB request to be the color that's closest to the
one you want
- If that color has been previously allocated by the Image
object (ie, it appears in the image object's XColor array)
simply point to that color; if that color hasn't been
allocated, then use XAllocColor to allocate.
- If XAllocColor fails, try again with the next closest color.
Issues:
- Any additional calls to XAllocColor will *slow down* the
system, meaning that any time you run out of colors, image
display will really slow down; have to find ways to speed
up algorithm.
- May cause severe ripple in the image object; expect a large
increase in XProtocol errors until the code settles down
Notes :
Keywords : color class
TB::oname : DESIGN::xvisual
- Short Description:
- UMR when switching between Read/Write and Read Only
Color allocation policy
Work-Around :
Severity : 2a - Incorrect behavior
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- load an image and open the Options/Display pane, click
on the Color Allocation Policy button a few times.
Notes :
Keywords : color allocation policy
TB::oname : DESIGN::xvisual
- Short Description:
- Setting XVW_COLOR_COLORFILE or XVW_COLOR_COLOROBJ directly
on a pseudo or threshold display will cause incorrect
display of the colormap on a 24-bit display.
Work-Around : Get the palette sub-part of the threshold or pseudo
object, and set XVW_COLOR_COLORFILE on *it* before setting
it on the threshold or pseudo itself. Eg:
xvw_set_attribute(pseudo, XVW_PSEUDO_PALETTE_OBJECT, &palette);
xvw_set_attribute(palette, XVW_COLOR_COLORFILE, infile);
xvw_set_attribute(pseudo, XVW_COLOR_COLORFILE, infile);
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Setting XVW_COLOR_COLORFILE or XVW_COLOR_COLOROBJ directly
on a pseudo or threshold object will cause incorrect
display of the colormap on a 24-bit display. It will
also cause a BadMatch / X_ChangeWindowAttributes X
Protocol error on displays such as Fresca, where the
default visual is not the same as the one that the Color
Class will allocate. For example, a 24-bit display that
has a default visual of Pseudocolor (8-bit).
Basically, the pseudo and threshold objects are using
the default visual, rather than using the visual that
matches the data (which might be 24 bit). Since all the
color objects share a common color->info structure, we
now have the problem that some visuals may be 8-bit and
some 24-bit. X does not support mixed visuals; all
colormaps, pixmaps, windows, and pixels used must all
come from the *same* visual; if they don't, you get
an X Protocol Error sooner or later.
We should fix this so the XVW_COLOR_COLORFILE can be set
directly on the threshold or pseudo object.
- Notes :
- The bug described in the entry with the description,
"Pseudocolor object causes X protocol error on SGI/Irix5.2"
is a particular instance of this bug.
Keywords : color class
TB::oname : DESIGN::xvisual
- Short Description:
- Setting clip file on zoom object causes zoom to
always be blank
Work-Around : Use datamanip routines to integrate clip mask
into image file. For example:
% kcpfromval -i masks:ball -o tmp.kdf -mask
% kinsertseg -i1 tmp.kdf -i2 image:mandril -o lulu.kdf -mask
% editimage -i lulu.kdf
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Setting clip file on zoom object causes zoom to
always be blank. To reproduce:
% editimage -i image:mandril -clip masks:ball
Open the zoom window and focus on the part of the
mandril that *is* displayed. Nothing appears in the
zoom window.
Possibility:
Get rid of support for separate clip mask in image object.
You can always get the same effect w/ mask segment.
Not only can you get the same effect by pre-processing
with datamanip, but this will alleviate a great deal of
work.
- Notes :
- Clip mask inside data object being displayed as image
works just fine.
Keywords : zoom, clip mask
TB::oname : DESIGN::xvisual
- Short Description:
- On Display subform of animate, editimage, and spectrum:
Change map cols, current map col not reflected in
map functions
Work-Around : Just pretend that the current map columns appear.
Severity : 4b- minor inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- On Display subform of animate, editimage, and spectrum:
Change map cols, current map col not reflected in map
functions
Notes :
Keywords : color class
TB::oname : DESIGN::xvisual
- Short Description:
- Display of integer image with range > 65536 produces
undefined colors and can produce a segmentation violation
Work-Around : Use image toolbox routine igamut to compress colormap
so that it has a range < 65536.
Severity : 1a- Seg fault, core dump, memory overwrite
Priority : 4 - Low
Reported By : Klamer Schutte
Date : Feb 22, 1996
HW : Linux 1.2.13, ELF system, slackware 3.0
OS :
Widget : Athena
C :
Fortran :
Perl :
X : Xfree 3.1.2, 8 bit pseudocolor
Win Mgr : fvwm
Display :
- Original Rpt:
- From kscp1@pc512.fel.tno.nl Thu Feb 22 00:59:23 1996
If we try to visualize an integer image (long, for example) with
a range bigger 65536 we get undefined colors. This can result in
a segmentation violation.
The problem is that in .../library/xvisual/src/ImageUtil.c
function ImageInit care is taken for integer images that
its values are scaled up from the minimum, but that no check
is performed to the maximum.
The problem is how to get this maximum. It clearly is not useful to
have 2^32 (for 32 bit machines -- 2^64 for 64 bit machines) entries
in the lookup table. But the X lookup table (per color) is limited
to 2^16 entries, so a greyscale of 2^16 should do. Next problem: how
to map all those entries to this limited range? (Actually, we often
have as little as 6 or 8 bits used by the hardware. And
distinquishable by the human eye)
The method used for real images is to map the whole dynamic range of
the image to the dynamic range of the hardware (in 256 bins.) Should
this also be used for integer images? So this means that we also have
to change the behaviour of 16 bit (short) images!
Or should we pick a certain dynamic range and clip / wrap around the
other values?
If you have an opinion about which strategy to follow
I might find time to make a patch.
- Notes :
- See email message Feb 24 "Forwarded mail" guiviz
for workspace reproducing bug
Keywords : color class, image
TB::oname : DESIGN::xvisual
- Short Description:
- Refresh problems with attempting to move a marker
over a plot
Work-Around : In spectrum, simply take hand off mouse until marker
catches up with plot.
Severity : 4b- minor inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- There are severe refresh problems when you create a
marker over a plot, and then attempt to move the
marker rapidly. Spectrum in particular suffers from
this limitation, with the marker on its scatterplot.
We need to implement some variation of backing store for
the area object, or come up with another workaround in
order to prevent refresh problems with marker moving over
plot.
Notes :
Keywords : marker, 2D plot, area
TB::oname : DESIGN::xvisual
- Short Description:
- Would like to provide converters for all strings
that might appear in app-defaults files
Work-Around :
Severity : 10a- Enhancement request
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Would like to provide converters for all strings that
might appear in app-defaults files, so user can specify
"Spline", for example, instead of 2 for the connection
type.
Notes :
Keywords : converters
TB::oname : DESIGN::xvisual, DESIGN::xvlang, DESIGN::xvobjects
- Short Description:
- Can't interactively move annotation off the top or
the left of an image
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- If you attempt to interactively move an annotation off
the top or the left of the image, it "bumps" into the
side of the window and won't go any further. You can
move the marker off the bottom or the right, though...
Notes :
Keywords : interactive movement, annotations
TB::oname : DESIGN::xvisual
- Short Description:
- Medium & Large Border Widths cause Mouse Droppings
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- When the border width of any annotation is set to Medium
or larger, interactive movement of the annotation will
cause severe mouse droppings.
Notes :
Keywords : interactive movement, interactive resize, annotations,
TB::oname : DESIGN::xvisual
- Short Description:
- Out-of-bounds annotations do not always refresh properly
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- If an annotation (tested w/ circle) is moved to the edge
of the image parent, it may not be refreshed. It should
be refreshed and clipped to the edge of the parent.
Test/fix with circle, test with other annotations after
bugfix.
Notes :
Keywords : annotations
TB::oname : DESIGN::xvisual
- Short Description:
- Interactively resizing an annotation such that it
gets out-of-bounds WC's produces bizarre results
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Interactively resizing an annotation such that it
gets out-of-bounds WC's produces bizarre results
- On resizeable manager parent, move annotation until WC's
are outside 0.0 to 1.0; after that, attempts to resize
produce very bizarre/unpredictable results.
- On resizeable manager parent, attempt to resize
annotation outside 0.0 to 1.0; again, very bizarre and
unpredictable results
Notes :
Keywords : interactive resize, annotations
TB::oname : DESIGN::xvisual
- Short Description:
- Intermittent problems with interactive movement of
the circle annotation
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Intermittent problems with interactive movement of
the circle annotation
Sometimes when you grab and try to move a circle, it
"wanders off on its own".
Notes :
Keywords : interactive movement, annotations, circle
TB::oname : DESIGN::xvisual
- Short Description:
- Intermittent problems with interactive movement of
the ellipse annotation
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Intermittent problems with interactive movement of
the ellipse annotation
Sometimes when you grab and try to move a ellipse, it
"wanders off on its own".
Notes :
Keywords : annotations, interactive movement, ellipse
TB::oname : DESIGN::xvisual
- Short Description:
- Indicator lines are not exactly horizontal or vertical
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Indicator lines are not exactly horizontal or vertical
When the indicator is set to use horizontal and vertical
lines, the lines are not exactly horizontal or vertical.
- Notes :
- Something having to do with setting attributes on
sub-parts is playing a role here
Keywords : annotations, indicator
TB::oname : DESIGN::xvisual, ENVISION::xprism
- Short Description:
- If you have a linear plot with an indicator, and you
change it to be log plot, the indicator still displays
points as if it was in linear space.
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Indicator in Conjunction w/ Log Axes
If you have a linear plot with an indicator, and you
change it to be log plot, the indicator still displays
points as if it was in linear space.
Notes :
Keywords : annotations, indicator
TB::oname : ENVISION::xprism, DESIGN::xvisual
- Short Description:
- You can move the indicator, but it is so slow as to be
unusable
Work-Around :
Severity : 3a- Major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- You can move the indicator by grabbing it and holding the
mouse pointer down while moving the pointer, but it is so
slow as to be unusable. (You have to go *very* slowly or
the indicator will get "dropped", and you have to go pick
it up again.)
Notes :
Keywords : annotations, indicator, interactive movement
TB::oname : DESIGN::xvisual, ENVISION::xprism
- Short Description:
- Would like device coordinate specification for line
annotation.
Work-Around :
Severity : 10a- enhancement request
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Would like device coordinate specification for line
annotation. Other annotations can use XVW_XPOSITION,
XVW_YPOSITION, XVW_WIDTH, and XVW_HEIGHT to set bounding
box of annotation, but this is not sufficient for
the line object (no way to specify orientation of line).
It would be nice to have special device coordinate
resources with which to size and position a line.
Notes :
Keywords : annotations, line object
TB::oname : DESIGN::xvisual
- Short Description:
- Would like device coordinate specification for polyline
annotation.
Work-Around :
Severity : 10a- enhancement request
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Would like device coordinate specification for polyline
annotation. Other annotations can use XVW_XPOSITION,
XVW_YPOSITION, XVW_WIDTH, and XVW_HEIGHT to set bounding
box of annotation, but this is not sufficient for
the polyline object (no way to specify number or location
of vertices). It would be nice to have special device
coordinate resources with which to size and position a
polyline annotation.
Notes :
Keywords : annotations, polyline
TB::oname : DESIGN::xvisual
- Short Description:
- Severe problems with interactive movement of line object
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Severe problems with interactive movement of line object,
include the following:
- difficult to move a horizontal line up & down
(it doesn't stay horizontal)
- can't move a horizontal line left & right
(it won't move at all)
- difficult to move a vertical line left & right
(it doesn't stay vertical)
- can't move a vertical line up & down
(it won't move at all)
- attempts to move often result in a resize
- can't move second endpoint more than 90 degrees
Notes :
Keywords : annotations, line, interactive movement
TB::oname : DESIGN::xvisual
- Short Description:
- If an event handler is installed on the marker object
to move it on PointerMotion, the marker is never directly
under the cursor
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- If an event handler is installed on the marker object to
move it on PointerMotion, the marker is never directly
under the cursor. Cursor sits on upper left corner of
bounding box, not center of bounding box.
Notes :
Keywords : annotations, marker
TB::oname : DESIGN::xvisual
- Short Description:
- The polyline object is just about impossible to select.
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- The polyline object is just about impossible to select.
This means it can't be interactively moved, and you
can't display its menuform.
Notes :
Keywords : annotations, polyline
TB::oname : DESIGN::xvisual
- Short Description:
- Cannot interactively move polyline object.
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- First, there is already a bug where the polyline object
is just about impossible to select. No chance of moving
it unless you can't select it first! Furthermore, the
ChangeGeometry() method will need rewriting before it
will be able to be moved interactively (i think).
Notes :
Keywords : annotations, polyline
TB::oname : DESIGN::xvisual
- Short Description:
- World coordinate size of annotations seems to change
when parent changes, even if it shouldn't.
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By : Becky
Date : 2/12/96
HW : cabernet
OS : solaris 2.4-gcc
Widget : athena
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- To reproduce:
run envision/examples/annotations/14.image_annotate/
Display the ball or moon image first; input locations1
followed by locations2; input image:lizard; and then
input image:kitten. Notice that the rectangles are
shrinking. Then go back and display image:moon again
and re-input locations1 and locations2 but do NOT clear
first. Notice that you get doubles but slightly offset
from each other; this emphasizes the problem.
Notes :
Keywords : annotations, rectangle
TB::oname : DESIGN::xvisual
- Short Description:
- Interactive movement of the rectangle object will
produce mouse droppings to the top and left
Work-Around :
Severity : 3a- major inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Interactive movement of a rectangle will produce mouse
droppings to the top and left, even if it has small line
width (as opposed to other annotations, which only leave
mouse droppings when they have a large line width).
Notes :
Keywords : annotations, rectangle
TB::oname : DESIGN::xvisual
- Short Description:
- Stringvalue object loses value precision after %.5f
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Stringvalue object looses value precision
If you have format of %.5f or greater, you don't get all 5
places of precision as expected (it rounds the number).
Notes :
Keywords : annotations, stringvalue
TB::oname : DESIGN::xvisual
- Short Description:
- Bumping up zoom factor on small image zoom won't
resize window.
Work-Around : Resize with window manager.
Severity : 4b- Minor inconvenience
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Bumping up zoom factor on small image zoom won't resize window.
In editimage:
1 - % editimage -i ~/design/repos/bitmaps/cursors/stopwatch
2 - bring up zoom window; zoom window is sized correctly for
zoomfactor.
3 - increase zoom factor
4 - ideally, you want the zoom window to automatically
increase in size until it gets to 256x256, but it stays
(locked) at the original size, even if you change the
image that is being displayed.
Notes :
Keywords : zoom
TB::oname : DESIGN::xvisual
- Short Description:
- Zoom object focus changes when zoomfactor changes
Work-Around : Simply re-focus zoom object by clicking in image
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Zoom object focus changes when zoomfactor changes
When you change the zoom factor, the zoom object focus
changes; it should stay at the same location regardless
of whether the zoom factor is changed.
Notes :
Keywords : zoom
TB::oname : DESIGN::xvisual
- Short Description:
- If image object is resized with window manager,
it would be nice to resize the image with pixel
replication or some such algorithm, like xv does.
Work-Around :
Severity : 10a- enhancement request
Priority : 4 - Low
Reported By : becky
Date : 2/29/96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- If image object is resized with window manager,
it would be nice to resize the image with pixel
replication or some such algorithm, like xv does.
Notes :
Keywords : image
TB::oname : DESIGN::xvisual
- Short Description:
- Refresh problem with Area objects
Work-Around : xvw_set_attributes(area,
XVW_GRAPHICS_VIEWPORT_MIN_X, 0.2,
XVW_GRAPHICS_VIEWPORT_MIN_Y, 0.2,
XVW_GRAPHICS_VIEWPORT_MAX_X, 0.8,
XVW_GRAPHICS_VIEWPORT_MAX_Y, 0.8,
NULL);
Severity : 4b- minor inconvenience
Priority : 4 - Low
Reported By : Danielle Argiro
Date : 23-Apr-96
HW : zen
OS : solaris
Widget :
C :
Fortran :
Perl :
X :
Win Mgr : twm
Display : piglet
- Original Rpt:
- When you have an area object displaying a 3D plot,
and the viewport is not set fairly small, this is what
happens: the plot is displayed, then the window grows
slightly, then the plot is refreshed again.
This can be avoided by setting the viewport to a fairly
small setting: <(0.2, 0.8), ((0.2, 0.8)>
This can be seen in the following example programs:
$ENVISION/examples/plot_color/06.3Dfile_data/
$ENVISION/examples/plot_color/07.3Dfile_map/
$ENVISION/examples/plot_color/08.3Dcoords_fg/
$ENVISION/examples/plot_color/09.3Dcoords_map/
Set Viewport to <(0.1, 0.9), ((0.1, 0.9)>, recompile and
the problem should occur.
Notes :
Keywords :
TB::oname : DESIGN::xvisual
- Short Description:
- Refresh problems when changing eye distance & perspective
Severity : 2a - Incorrect behavior
Priority : 4 - Low
Reported By : Danielle Argiro
Date : 23-Apr-96
HW : all
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- 1) xprism &
2) plot->files->open plot3d:flow
3) options->open menuform plot3d(1)
4) change Eye distance, alpha; droppings left behind
Notes :
Keywords : plot object
TB::oname : DESIGN::xvisual
- Short Description:
- Pan icon bounces back
Work-Around :
Severity : 4b- minor inconvenience
Priority : 4 - Low
Reported By : Danielle Argiro
Date : 3-Jul-96
HW : zen
OS : solaris
Widget :
C :
Fortran :
Perl :
X :
Win Mgr : twm
Display :
- Original Rpt:
- $ENVISION/examples/panicon/*/example, editimage; position
pan box and it bounces back a couple pixels
Notes :
Keywords : panicon
TB::oname : DESIGN::xvisual
- Short Description:
- Corruption/restoration of RGB colormap on ROI extraction
Work-Around :
Severity : 4b- minor inconvenience
Priority : 4 - Low
Reported By : Danielle Argiro
Date : 3-Jul-96
HW : zen
OS : solaris
Widget :
C :
Fortran :
Perl :
X :
Win Mgr : twm
Display :
- Original Rpt:
- % extractor -i image:mandril-rgb
Extract ROI; watch main image's colormap corrupt,
then restore
Notes :
Keywords : ROI extraction
TB::oname : DESIGN::xvisual
- Short Description:
- Problem with private colormap on RGB complex image
Work-Around :
Severity : 2a - Incorrect behavior
Priority : 5 - None
Reported By : Shannon Wells
Date : 3-Jul-96
HW : Dec Alpha (piglet & water)
OS : OSF/1 3.2
Widget : Motif
C : native C
Fortran : f77
Perl : perl 4.036
X : X11R5
Win Mgr : twm
Display :
- Original Rpt:
- changing to Use Private Colormap when viewing
test:RGB:complex changes the colormap permanently
load test:RGB:complex
Notes :
Keywords : ROI extraction
TB::oname : DESIGN::xvisual
- Short Description:
- Should you be able to change map columns on RGB image?
Work-Around :
Severity : 2a - Incorrect behavior
Priority : 3 - Medium
Reported By : Shannon Wells
Date : 3-Jul-96
HW : Dec Alpha (piglet & water)
OS : OSF/1 3.2
Widget : Motif
C : native C
Fortran : f77
Perl : perl 4.036
X : X11R5
Win Mgr : twm
Display :
- Original Rpt:
- open test:RGB:ubyte_reg_range and select options, then
select the Display pane. edit fcns dicatating colormap
Seems to always do the same
thing no matter what fcn you put in - acts like you put a
sequence of r, g and blue filters on it until it turns
black
Notes :
Keywords : change map columns
TB::oname : DESIGN::xvisual
- Short Description:
- Sometime zoom window gets blurry on update
Work-Around :
Severity : 4b - Minor inconvenience
Priority : 4 - Low
Reported By : Shannon Wells
Date : 3-Jul-96
HW : Dec Alpha (piglet & water)
OS : OSF/1 3.2
Widget : Motif
C : native C
Fortran : f77
Perl : perl 4.036
X : X11R5
Win Mgr : twm
Display :
- Original Rpt:
- sometimes when updating the zoom window (either by button
press or continuous) the pixels are offset causing the
zoom image to be blurry. click again or move the mouse
and this goes away, then returns randomly
- load test:RGB:complex and open Zoom window.
Notes :
Keywords : change map columns
TB::oname : DESIGN::xvisual
xvlang
- Short Description:
- Request for the FinderList object to use keywords.
Work-Around :
Severity : 10a- enhancement request
Priority : 3 - Medium
Reported By :
Date : 5-Mar-96
HW : zen
OS : solaris
Widget : motif
C :
Fortran :
Perl :
X : X11R6 (Accelerated X)
Win Mgr : twm
Display : glacier:0T
- Original Rpt:
- The Finder Expression thingy in the Cantata Finder is not
looking at the keywords for the objects. It appears to be
looking only at the name, icon name, and short description.
Try to do a Finder Expresion lookup for the keyword
"variable". You might expect it to drag out kprval for
you, since that what is used to set variables at run time,
and the word "variable" is in the keywords list for kprval.
However, you get no matches - i.e.nothing is identified
that contains the word "variable".
- Notes :
- The finder list never *has* supported keyword scanning;
but this would be a really good enhancement.
Keywords :
TB::oname : DESIGN::cantata
- Short Description:
- Provide converters for all strings that might appear in app-defaults files
Work-Around :
Severity : 10a- enhancement request
Priority : 3 - Medium
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
-
Would like to have converters for all strings that might
appear in app-defaults files, so user can specify "Spline",
for example, instead of 2 for the connection type.
Notes :
Keywords : converters
TB::oname : DESIGN::xvlang, DESIGN::xvobjects, DESIGN::xvisual
xvobjects
- Short Description:
- No error message is given by browser when selecting an
alias for a file that doesn't exist
Work-Around :
Severity : 2c- Error message, warning, or prompting, is incorrect
Priority : 2 - High
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- If you select an alias for a file that doesn't exist,
the browser returns NULL, but does not give an error
message. To reproduce: add bogus entry to Aliases file.
Select bogus alias from browser. No error message given.
Notes :
Keywords : browser
TB::oname : DESIGN::xvobjects
- Short Description:
- TextDisplay multiline text display bug; if you don't set
XVW_TEXT_MULTILINE to TRUE before setting the initial
contents of the string with XVW_TEXT_STRING, the text
displayed will not all be visible at first.
Work-Around : Set XVW_TEXT_MULTILINE to TRUE before setting the initial
contents of the string with XVW_TEXT_STRING.
Severity : 2a- Incorrect behavior
Priority : 4 - Low
Reported By : Danielle Argiro
Date : 8-Apr-96
HW : fresca
OS : IRIX 4.2
Widget : Motif
C :
Fortran :
Perl :
X :
Win Mgr : twm
Display : piglet:0
- Original Rpt:
- TextDisplay multiline text display bug; if you don't set
XVW_TEXT_MULTILINE to TRUE before setting the initial
contents of the string with XVW_TEXT_STRING, the text
displayed will not all be visible at first (text seems to
start to the left of the left hand side of the textdisplay
object.
Notes :
Keywords : TextDisplay
TB::oname : DESIGN::xvobjects
- Short Description:
- Can't view any more than 2184 lines with TextDisplay
object (and therefore, with Help object)
Work-Around : Divide files up into smaller files.
Severity : 3a- major inconvenience
Priority : 3 - Medium
Reported By : George Ruban, "nobody@www.."
Date :30-Jan-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- ---- version 1, from Scott ------------------------
I have some big .c files. Around 0.5MB. If I try to use
the View option from composer to look at them, everything
works for a while as I start moving the scrollbar down,
but at some point, the text in the window reverts back
to that which is present at the start of the file.
Moving the slider further down simply repeats that same
text. There's no way to see the rest of the file unless
I use Edit and start a vi session.
---- version 2, from "nobody", WWW Bug Report ----
I can't display a text file of more than 2184 lines.
When I do, the display wraps back to the beginning of
the file and the scrollbar doesn't scroll the text
anymore. Scrolling back to before 2184 is ok.
---- version 3, from "nobody", WWW Bug Report ----
Specifically, I can't scroll down to the bottom of a
~200 K text file. Another user reported a segmentation
fault trying to display this file, even bringing down
cantata.
- Notes :
- (from Mark)
I was hoping when i did the first proto-type of the
TextDisplay object that we wouldn't have to deal with
this, but i guess i was wrong. The problem is going to
be a bitch to solve.
The major problem is that in Xt they use shorts instead of
ints. This means that it you wish to have the
TextDisplay as a scrollable text window (rather than
some kind of fake virtual window) then you are limited
by a scroll range of 2^15 (Position) and 2^16 size
(Dimension). Anyway, this really bites! If we decide
to go with a virtual window, then we will have to deal
with the eventual problem of how to provide a virtual
manager that deals with mapping and unmapping objects
that have been "scrolled" off the page.
Keywords : help, textdisplay
TB::oname : DESIGN::xvobjects
- Short Description:
- Would like to provide converters for all strings
that might appear in app-defaults files
Work-Around :
Severity : 10a- Enhancement request
Priority : 4 - Low
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Would like to provide converters for all strings that
might appear in app-defaults files, so user can specify
"Spline", for example, instead of 2 for the connection
type.
Notes :
Keywords : converters
TB::oname : DESIGN::xvisual, DESIGN::xvlang, DESIGN::xvobjects
- Short Description:
- Would like to write a translator from csh filter strings
to regex filter strings, and then re-enable browser
object filter.
Work-Around :
Severity : 10a- enhancement request
Priority : 5 - None
Reported By : danielle
Date : 3/13/96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Originally, the browser object had a filter, but the
input to the filter had to be in regex form. Users cannot
be expected to understand regex, and tended to report the
operation of the filter as a bug, when they used it at
all. Therefore, we took the textinput object that
supported the filter off the browser for the 2.1 release.
However, internal support for the browser filter is still
there (commented out), and is waiting for when someone
(Steve J) writes a translator so that the user can enter
specifications such as "*.c", etc, and the translator
will translate them into regex for processing.
Notes :
Keywords : browser
TB::oname : DESIGN::xvobjects
- Short Description:
- On Linux display, long text lines may be truncated by
the TextDisplay object after use of horizontal scrollbar.
Work-Around :
Severity : 2a- Incorrect behavior
Priority : 3 - Medium
Reported By : Scott Wilson
Date : 5-Mar-96
HW : zen
OS :
Widget :
C :
Fortran :
Perl :
X : X11R6 (accelerated X) on glacier
Win Mgr : twm
Display : glacier:0
- Original Rpt:
- There is a refresh problem with the text display widget that
makes it look like it is truncating long text lines. If
you move the scrollbars very slowly, it will usually do it
right. If you move them fast, it will probably not put the
text up, but it *will* leave space for it. If you then
resize the window the text may or may not appear.
To reproduce:
% kstats -i image:moon -o blah
% kprdata -val -attr -i blah junk
% khelp -i junk
Then go to the very bottom line, and try to get over to see
the last few numbers. They should be 512 512 1 1 1, but you
will often only see the first 512 with the remaining 4
numbers cut off.
- Notes :
- Bug does not appear on piglet's display, only glacier.
Keywords :
TB::oname : DESIGN::xvobjects
- Short Description:
- Request for search capability in TextDisplay object
Work-Around :
Severity : 10a- Enhancement request
Priority : 5 - None
Reported By : Becky Bishop
Date : 22-Mar-96
HW : Sun Sparc 5
OS : Solaris
Widget : Athena
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- It would be nice if the Text Display object had a search
capability similar to the "less" command so that when
files are being viewed, you can search for certain
sections of text.
Notes :
Keywords : textdisplay
TB::oname : DESIGN::xvobjects
- Short Description:
- Request for TextDisplay object to support scrolling
with arrow keys.
Work-Around :
Severity : 10a- Enhancement request
Priority : 5 - None
Reported By : Becky Bishop
Date : 22-Mar-96
HW : Sun Sparc 5
OS : Solaris
Widget : Athena
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- It would be nice if the file viewer would support
scrolling using the arrow keys in addition to the
scrollbar.
Notes :
Keywords : textdisplay
TB::oname : DESIGN::xvobjects
- Short Description:
- Integer object will accept floating point values,
but will interpret them as bogus integer values
Work-Around :
Severity : 2a- incorrect behavior
Priority : 3 - Medium
Reported By : Tom Konerth
Date : 13-Feb-96
HW : Sun Sparc 5
OS : Solaris
Widget : Motif
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- When a value starting with "." is entered as the integer
value (eg .0967), the value diplayed is 303832 and not
0. Integer object should check ascii value of input,
and make sure it's really an integer value.
Notes :
Keywords : integer
TB::oname : DESIGN::xvobjects
- Short Description:
- Multiline text objects should automatically provide
scroll bar; each update whould result in scrolling to
the latest line
Work-Around :
Severity : 10a- Enhancement request
Priority : 5 - None
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Multiline text widgets should automatically provide
scrollbar; each update whould result in scrolling to
the latest line
Notes :
Keywords : text
TB::oname : DESIGN::xvobjects
xvutils
xvwidgets
- Short Description:
- Request to specify other displays
Work-Around :
Severity : 10a- enhancement request
Priority : 5 - None
Reported By : Wes Bethel
Date : 06-Feb-96
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- i'd like to be able to create/display/etc stuff
(specifically via the image widget) on some display
other than $DISPLAY. currently, none of xvwidgets
routines take a string as a parameter that says where
the display is...at least, that i can find in the doc.
Notes :
Keywords : display
TB::oname : DESIGN::xvwidgets
- Short Description:
- Requested feature to be able to tab between text entry
fields. If the entry field has text in it already, then
highlight the text.
Work-Around :
Severity : 10a- Enhancement request
Priority : 5 - None
Reported By : Becky Bishop
Date : 22-Mar-96
HW : Sun Sparc 5
OS : Solaris
Widget : Athena, Motif
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- If the widget set supports it, people would like for
Khoros to support tabbing between text entry fields.
Currently, the mouse has to be placed inside the field
and focus is required. This makes for difficult
usability. Also, if we were to support tabbing, then
it would be nice to highlight any text that already
appears in a selection such that it can easily be
deleted or modified without having to use the mouse
to first select the text.
Notes :
Keywords : widgets, tab
TB::oname : DESIGN:xvwidgets
- Short Description:
- Text Object - Should be able to use mouse to yank and put
Work-Around : text = xvw_create_text(WORKSPACE WIDGET,"display");
xvw_set_attributes(text,
XVW_TEXT_STRING, multi-line string,
XVW_TEXT_MULTILINE, TRUE,
XVW_TACK_EDGE, KMANAGER_TACK_ALL,
NULL);
Severity : 3a- Major inconvenience
Priority : 3 - Medium
Reported By :
Date :
HW :
OS :
Widget :
C :
Fortran :
Perl :
X :
Win Mgr :
Display :
- Original Rpt:
- Text Object - Should be able to use mouse to yank and put
Notes :
Keywords :
TB::oname : DESIGN::xvwidgets