Oh, I see! Vectors get created even without create! This might be good enough. I'm not 100% clear as to why syntactical compatibility between 2.x and 3.x is needed. Nor why the vectors need to created in a single command. Is this because the TCL code making the call can't be changed? The reason for my initiating this compatibility discussion is this: if I want to write a code that I can distribute (to students, for example) I need to anticipate the environment in which they will be using it. The...
Sorry, @ghowlett, I may have been unclear. It's the loss of ability to declare multiple vectors on one line that represents a discontinuity in syntax: $ bltsh30 % blt::vector create x(5) t w unknown switch "t" The following switches are available: -variable varName -command command -watchunset bool -flush bool -length length although I just noticed that there is in v.2.5.3 from blt-dev an option: vector configure -oldcreate bool which may be doing what I had in mind: The configure operation sets...
postscript BB is off
Very simple but useful things that are missing in v.2.x : [x min] and [x max]. This is difficult to overcome (my shortest version is x dup xx; xx sort; puts "$xx(0)" for min), and the best workaround I found is to use critcl: package require BLT namespace import ::blt::* package require critcl critcl::clibraries -lBLT critcl::ccode { #include <tcl.h> #include <blt.h> } critcl::cproc minValue { Tcl_Interp* ip Tcl_Obj* v } double { Blt_Vector *vp; Blt_GetVector(ip, Tcl_GetString(v), &vp); return vp->min;...
BLT v.3 significantly changed the syntax of the vector command. Since a lot of places are still running v.2.47z, trying to write universal code requires accommodations like these: proc newVector { name len } { # BLT 2.x allowed to re-create existing vectors, # this is necessary in BLT 3 but will also work in BLT 2.x global BLT3 $name if { [info exists ${name}] } { vector destroy ${name} } if {$len != "" && $len > 0} { if {$BLT3} { vector create ${name} -length $len # BLT 3 initializes to NaN, restore...
Just updated the code from this site, compiled and verified that the same behaviour is seen in the current version (3.0? 4.0?) of BLT: $ blt-src/src/bltsh30 fpbug.tcl tclsh underflow with y = exp(-x**2) 25.00 --> 3.681e-272 26.00 --> 2.612e-294 27.00 --> 2.508e-317 28.00 --> 0.000e+00 29.00 --> 0.000e+00 30.00 --> 0.000e+00 blt underflow with y = exp(-x^2) 25.0 26.0 27.0 --> 3.6808558548018004e-272 2.6117417612840555e-294 2.507972e-317 25.0 26.0 27.0 28.0 --> floating-point value too small to represent...
unnecessary and harmful underflow error in vector
By the way, the plotting symbol and other decorations on the plot must also be scaled by the [tk scaling] factor when generating PostScript. Some of it could be done in tcl, so the truly critical part about PostScript is the fonts because one cannot correct it within tcl. Perhaps the best way to specify sizes of things on the graph could be not in absolute terms (pixels or points) but, say, % of the graph width. This approach would scale predictably across modes of viewing the same graph (low-res...
By the way, the plotting symbol and other decorations on the plot must also be scaled by the [tk scaling factor] when generating PostScript. Some of it could be done in tcl, so the truly critical part about PostScript is the fonts because one cannot correct it within tcl. Perhaps the best way to specify sizes of things on the graph could be not in absolute terms (pixels or points) but, say, % of the graph width. This approach would scale predictably across modes of viewing the same graph (low-res...
I guess to answer your question explicitly, my goal is to have the relative sizes of the objects be the same, whether they are on the screen or in a PostScript file, at a much higher resolution.
I would find it incomprehensible, if the adjustments made on the screen (change the font or its size, or the plotting symbol and its size) did not correspond to the changes made in the postscript output. In general, PNG snapshots in BLT 2.4 and 3.0 work in exactly that way. The problem with PostScript generation showed up only when I started using high-DPI screens. While I can insist on points (1/72in on screen) being used to define the size of the on-screen buttons and menus in Tk, inside BLT it...
I would find it incomprehensible, if the adjustments made on the screen (increase the the font or its size, or the plotting symbol and its size) did not correspond to the changes made in the postscript output. In general, PNG snapshots in BLT 2.4 and 3.0 work in exactly that way. The problem with PostScript generation showed up only when I started using high-DPI screens. While I can insist on points (1/72in on screen) being used to define the size of the on-screen buttons and menus in Tk, inside...
I would find it incomprehensible, if the adjustments made on the screen (increase the the font or its size, or the plotting symbol and its size) did not correspond to the changes made in the postscript output. In general, PNG snapshots in BLT 2.4 and 3.0 work in exactly that way. The problem with PostScrip generation showed up only when I started using high-DPI screens. While I can insist on points (1/72in on screen) being used to define the size of the on-screen buttons and menus in Tk, inside BLT...
I would find it incomprehensible, if the adjustments made on the screen (increase the the font or its size, or the plotting symbol and its size) did not correspond to the changes made in the postscript output. In general, PNG snapshots in BLT 2.4 and 3.0 work in exactly that way. The problem with PostScrip generation showed up only when I started using high-DPI screens. While I can insist on points (1/72in on screen) being used to define the size of the on-screen buttons and menus in Tk, inside BLT...
I would find it incomprehensible, if the adjustments made on the screen (increase the the font or its, or the plotting symbol and its size) did not correspond to the changes made in the postscript output. In general, PNG snapshots in BLT 2.4 and 3.0 work in exactly that way. The problem with PostScrip generation showed up only when I started using high-DPI screens. While I can insist on points (1/72in on screen) being used to define the size of the on-screen buttons and menus in Tk, inside BLT it...
} missing above
}
postscript generation sets font sizes without considering tk scaling (workaround)
"no current grab" error on second time a menu is accessed
Actually, I did find a workaround: delete and re-create the marker every time. Is this the best I can do? set i 0 bind .g.c <ButtonRelease-1> { if {[info exists gt]} {.g.c marker delete gt} .g.c marker create text -name gt .g.c marker configure gt -coords {0.5 0.2} -text "Click to refresh..." }
A memory leak (?) in marker in BLT 2.4z, not in 3.0
Since I am lucky enough to be the first Wiki contributor, I must begin by expressing a universal, I am sure, love and admiration for this amazing, outstanding bit of code craftsmanship. Thanks, George A. Howlett! You have created an indispensable tool. BLT 2.4z has been the mainstay of most Linux distributions for a while and, unfortunately, the recent changes to the code here have not yet made it through to the distribution channels. I wanted to make my code run under either the 2.x series or under...
Since I am lucky enough to be the first Wiki contributor, I must begin by expressing a universal, I am sure, love and admiration for this amazing, outstanding bit of code craftsmanship. Thanks, George A. Howlett! You have created an indispensable tool. BLT 2.4z has been the mainstay of most Linux distributions for a while and, unfortunately, the recent changes to the code here have not yet made it through to the distribution channels. I wanted to make my code run under either the 2.x series or under...
BLT 2.4z has been the mainstay of most Linux distributions for a while and, unfortunately, the recent changes to the code here have not yet made through to the distribution channels. I wanted to make my code run under either the 2.x series or under the current 3.0 (4.0? in Readme) versions if you downloaded/compiled/installed that. These are some of the tricks I had to use: if { [catch {set BLTversion [package require BLT]}] } { puts stderr "BLT package is missing, maybe `sudo apt-get install blt`\n";...
BLT 2.4z has been the mainstay of most Linux distributions for a while and, unfortunately, the recent changes to the code here have not yet made through to the distribution channels. I wanted to make my code run under either the 2.x series or under the current 3.0 (4.0? in Readme) versions if you downloaded/compiled/installed that. These are some of the tricks I had to use: if { [catch {set BLTversion [package require BLT]}] } { puts stderr "BLT and RBC packages are missing, maybe `sudo apt-get install...
BLT 2.4z has been the mainstay of most Linux distributions for a while and, unfortunately, the recent changes to the code here have not yet made through to the distribution channels. I wanted to make my code run under either the 2.x series or under the current 3.0 (4.0? in Readme) versions if you downloaded/compiled/installed that. These are some of the tricks I had to use: if { [catch {set BLTversion [package require BLT]}] } { puts stderr "BLT and RBC packages are missing, maybe `sudo apt-get install...
BLT 2.4z has been the mainstay of most Linux distributions for a while and, unfortunately, the recent changes to the code here have not yet made through to the distribution channels. I wanted to make my code run under either the 2.x series or under the current 3.0 (4.0? in Readme) versions if you downloaded/compiled/installed that. These are some of the tricks I had to use: if { [catch {set BLTversion [package require BLT]}] } { puts stderr "BLT and RBC packages are missing, maybe `sudo apt-get install...
BLT 2.4z has been the mainstay of most Linux distributions for a while and, unfortunately, the recent changes to the code here have not yet made through to the distribution channels. I wanted to make my code run under either the 2.x series or under the current 3.0 (4.0? in Readme) versions if you downloaded/compiled/installed that. These are some of the tricks I had to use: if { [catch {set BLTversion [package require BLT]}] } { puts stderr "BLT and RBC packages are missing, maybe `sudo apt-get install...
BLT 2.4z has been the mainstay of most Linux distributions for a while and, unfortunately, the recent changes to the code here have not yet made through to the distribution channels. I wanted to make my code run under either the 2.x series or under the current 3.0 (4.0? in Readme) versions if you downloaded/compiled/installed that. These are some of the tricks I had to use: if { [catch {set BLTversion [package require BLT]}] } { puts stderr "BLT and RBC packages are missing, maybe `sudo apt-get install...
There has been some naming convention changes in several of the libraries. autoconf should have picked them all up, but I found that under Ubuntu (buster) or Debian (10.2), tcl/tk 8.6.9, I still needed to make this change: configure.in 490c490 < ft2_inc_spec=`freetype-config --cflags` --- > ft2_inc_spec=`pkg-config freetype2 --cflags` 492c492 < ft2_inc_spec="-I${blt_with_ft2_include_dir}/freetype2 -I${blt_with_ft2_include_dir}" --- > ft2_inc_spec="-I${blt_with_ft2_include_dir}/freetype -I${blt_with_ft2_include_dir}"...
Minor typos in math and in y-error bars - fix provided
There has been some naming convention changes in several of the libraries. autoconf should have picked them all up, but I found that under Ubuntu (buster) or Debian (10.2) I still needed to make this change: configure.in 490c490 < ft2_inc_spec=`freetype-config --cflags` --- > ft2_inc_spec=`pkg-config freetype2 --cflags` 492c492 < ft2_inc_spec="-I${blt_with_ft2_include_dir}/freetype2 -I${blt_with_ft2_include_dir}" --- > ft2_inc_spec="-I${blt_with_ft2_include_dir}/freetype -I${blt_with_ft2_include_dir}"...
That's not a bug, but a re-design. You may need to modify your code, but the functionality is there. According to GAH: Grid lines were moved from being global to the axis when multiple axes were added. You can have different gridlines per axis. -grid boolean Turns on/off grid lines on the axis. -gridcolor colorName Specifies the color of major grid lines. -griddashes dashList Specifies the dashes for major grid lines -gridlinewidth numPixels Specifies the line width of major grid lines. -gridminor...