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