Can BLT be replaced by Tcl packages ?
relaxmike
I have a Tcl software which uses several commands of the BLT package.
The problem is that binary versions of BLT are not
available on all platforms which are currently supported by Tcl, in
particular
the Active State distribution. Example : HP, Sun, etc...
I would like to replace the BLT commands that I use with
standard Tcl scripts so that I can have a more portable software.
Here is the full list of BLT commands that I use :
blt::graph
blt::vector
blt::barchart
blt::busy
blt::bgexec
blt::winop
I searched around the found alternative way of doing the same thing.
Here is what I found :
bgexec : Tcl/[exec ...&], Tcl / [open | ...]
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/95a6eb742abfe9ae/3a06432b88784f64?lnk=gst&q=bgexec#3a06432b88784f64
http://wiki.tcl.tk/12704
busy
http://wiki.tcl.tk/3049
http://aspn.activestate.com/ASPN/Cookbook/Tcl/Recipe/68377
http://phaseit.net/claird/comp.lang.tcl/tcl-examples.html#busy
bltdebug : TclX / cmdtrace , TclX / profile
barchart, graph :
Tklib / Plotchart
http://www.flightlab.com/~joe/gutter/doc/tklib-0.4.1/plotchart.html
http://wiki.tcl.tk/18167
winop snap window photoName
http://wiki.tcl.tk/9127
In fact, I feel that BLT, which has been really useful in the past,
can be replaced
by other pure Tcl packages today. Am I wrong ?
Best regards,
Michaël
Bryan Oakley
> In fact, I feel that BLT, which has been really useful in the past,
> can be replaced
> by other pure Tcl packages today. Am I wrong ?
I don't think you'll find any tcl-based packages that come close to the
functionality of BLT's graph and vector commands. If all you need are
very simple charts and graphs you can get by with the tcl solutions.
I also think BLT's bgexec is better than any other alternative.
--
Bryan Oakley
http://www.tclscripting.com
Alexandre Ferrieux
>
> I also think BLT's bgexec is better than any other alternative.
>
This may be debated.
One tiny bit is currently missing in the core to allow for complete
emulation of [bgexec] (and much more) with smaller primitives like
[open] and [exec]: standalone pipes. See TIP 304:
http://www.tcl.tk/cgi-bin/tct/tip/304.html.
-Alex
Keith Nash
> relaxmike wrote:
>
>> In fact, I feel that BLT, which has been really useful in the past,
>> can be replaced
>> by other pure Tcl packages today. Am I wrong ?
>
> I don't think you'll find any tcl-based packages that come close to the
> functionality of BLT's graph and vector commands. If all you need are
> very simple charts and graphs you can get by with the tcl solutions.
I agree that BLT is the best solution for graphs and vectors.
Michaël, you don't say whether you've tried to build BLT on the platforms
that you need. Building from source will likely be easier than porting
your BLT code to a different package.
Keith.
relaxmike
> that you need. Building from source will likely be easier than porting
> your BLT code to a different package.
In fact, I got the Windows .dll from the official web page, and it
was easy for me to compile a Linux version. Two years ago, I had
the opportunity to use a Solaris - Sparc machine so that I could
generate a .so for that system.
The problem is that I am far from being able to get BLT on
HP, AIX, Solaris - ix86, etc... all platforms which are currently
supported
by the Active State distribution.
This is a real issue, since the current software would be very more
portable if I did not use BLT.
The official http://blt.sourceforge.net/ web page only distributes
Windows binaries.
The Active Tcl distribution does not contain BLT, and will not do
before long (because it is not "stub enabled", but I don't know what
it means
exactly) :
http://community.activestate.com/product/activetcl
"We do not provide BLT at this time largely because it is an
unmaintained extension with outstanding issues, and cannot be
considered "stable"."
My problem is the following :
- BLT is very useful,
- BLT is difficult to deploy.
Larry W. Virden
> "We do not provide BLT at this time largely because it is an
> unmaintained extension with outstanding issues, and cannot be
> considered "stable"."
>
> My problem is the following :
> - BLT is very useful,
> - BLT is difficult to deploy.
Your options include:
1. Build and use BLT yourself - as you have already mentioned, this
means that you have to figure out how to build the code on the various
platforms.
2. Fork the BLT code and work on it to get it into a condition that
ActiveState might support.
3. Convert your programs to use as many non-BLT packages that _are_
supported by ActiveState as possible. This would mean
a. identifying alternative packages - which you have begun to do
b. making appropriate application changes, testing, etc.
c. determining what to do in any cases where functionality you use is
not available in other packages.
For your particular situation, option 3 seems to be the best approach
for you.
Gerald W. Lester
>...
> The Active Tcl distribution does not contain BLT, and will not do
> before long (because it is not "stub enabled", but I don't know what
> it means
> exactly) :
> http://community.activestate.com/product/activetcl
> "We do not provide BLT at this time largely because it is an
> unmaintained extension with outstanding issues, and cannot be
> considered "stable"."
You can always contact ActiveState and see how much it will cost to change
the status of BLT to one that is "stable" and maintained -- I suspect *very*
strongly that for the correct amount of money ActiveState will support BLT.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Keith Nash
> means that you have to figure out how to build the code on the various
> platforms.
Your platform must have development tools installed, i.e. a C compiler, and
include files for its libraries. If anything is missing it will be
reported as an error message in step (4) below. Your ActiveTcl
installation must be version 8.4.x - BLT is not yet adapted to Tcl/Tk 8.5.
(0) copy the BLT tarball and the latest cumulative patch from sourceforge to
a convenient directory
(1) unpack the BLT source
(2) apply the patch, e.g.
patch -p0 < blt2.4z-patch-2
(3) cd blt2.4z
(4) replace /usr/local/ActiveTcl with the location of your ActiveTcl
installation in this command:
./configure --prefix=/usr/local/ActiveTcl \
--with-tcl=/usr/local/ActiveTcl/lib --with-tk=/usr/local/ActiveTcl/lib \
--with-tclincls=/usr/local/ActiveTcl/include \
--with-tkincls=/usr/local/ActiveTcl/include \
--with-tcllibs=/usr/local/ActiveTcl/lib --with-tklibs=/usr/local/ActiveTcl/lib
(5) make
(6) follow the instructions in the file INSTALL to test the binary by
running some of the demos:
cd demos
./graph1.tcl
after you have finished, go back to the parent directory
cd ..
(7) (as root) make install
Keith.
relaxmike
This is really useful.
But for me, it is not possible to compile BLT on all systems
where Tcl is currently available, and it is a pity that my software
can't be used everywhere, just because of that particular package.
My particular situation is that the software target is the
scientific community, which traditionnaly use exotic systems like HP-
UX,
Solaris, AIX, etc...
Since BLT
- is not strictly necessary for me and
- since other packages do the job, even with less features,
- I have not hope that the situation is going to change radically
in the current year,
- I have no time to imply myself in the BLT project,
I think that I will replace BLT code with other packages.
It will simplify my task.
Michaël
Arjen Markus
Can you be more specific about what parts of BLT are
of interest to you? (Maybe I can enhance Plotchart,
if it lacks certain features)
Regards,
Arjen, who should be very careful with such promises ... ;)
relaxmike
> of interest to you? (Maybe I can enhance Plotchart,
> if it lacks certain features)
> Regards,
> Arjen, who should be very careful with such promises ... ;)
The part of BLT which are of interest for me and which are
part of Plotchart are :
blt::graph
blt::barchart
I have allready experienced a little with Plotchart to conlude that
it can satisfy my current needs. I especially tested :
Plotchart::createXYPlot
Plotchart::createHorizontalBarchart
At first read, I was afraid that there was no support for legends,
but it appeared that the legends are available, but with no
documentation (in ActiveTcl8.4.14).
They are written in the category "ROOM FOR IMPROVEMENT" in the html
page.
In the package, one can find that the subcommand "legend" works well
for XYPlot.
In fact, the documentation problem does not matter since the Plotchart
script is clear
enough to be directly understood.
What is in BLT and that I did not see in Plotchart is the possibility
for zooming, which is useful to analyse a complex curve. Useful, yes,
but not mandatory for me.
Best regards,
Michaël
Arjen Markus
Thanks for bringing the lack of documentation of the legend
to my attention. I should fix that :).
Hm, zooming would indeed be a nice feature. I will have to think
about that (given the canvas's support for zooming it should
not be too difficult, but the axes should be redrawn in
accordance - that might prove tricky, or at least, require
an additional bit of programming).
Regards,
Arjen
Torsten Reincke
> Hm, zooming would indeed be a nice feature. I will have to think
> about that (given the canvas's support for zooming it should
> not be too difficult, but the axes should be redrawn in
> accordance - that might prove tricky, or at least, require
> an additional bit of programming).
Right. I would love that feature for plotchart! What BLT does, it that
you only see the part of the axes that belong to the zoomed area, and
they are always displayed at the specified edges of the plot area
(top, bottom, left, or right). Neither the tick marks nor the numbers
at the axes get scaled, of course, just stretched or squeezed to the
desired zoom level. I think, that is what you are thinking, when you
say, the axes should be redrawn in accordance. It would be nice, when
the graph is replotted when the canvas size changes (the default in
BLT), but again, this requires some housekeeping of the plot data (and
programming, of course).
Actually, I have been looking for a BLT substitute for a long time,
especially, because BLT seems stuck at 2.4z and without stub and Aqua
support. (The mythical version 3.0 in cvs is crippled, no chance to
compile that beast because of missing files and routines). I feel,
that plotchart has the potential to make it there, perhaps apart from
the speed when plotting hundreds or thousands of points. Since it is
written in pure Tcl, I could even enhance it myself. But as you
already said, I also should be really really careful with any
promises ... but who knows, if I'm desperate enough ...
And then, dreaming of callbacks to the data points, logarithmic axes
(which I use a lot), inverse axes, all without changing the input
data, abnd, and, and ...
Torsten
Arjen Markus
I feel,
> that plotchart has the potential to make it there, perhaps apart from
> the speed when plotting hundreds or thousands of points. Since it is
> written in pure Tcl, I could even enhance it myself. But as you
> already said, I also should be really really careful with any
> promises ... but who knows, if I'm desperate enough ...
>
> And then, dreaming of callbacks to the data points, logarithmic axes
> (which I use a lot), inverse axes, all without changing the input
> data, abnd, and, and ...
>
Hundreds of thousands of points ... well, I can add a subcommand
to plot a bunch of points at the same time - that should get
rid of some overhead.
In the CVS repository you will find a very preliminary implementation
of logarithmic axes (that was an easy extension; no docs yet :)):
#source plotchart.tcl
canvas .c -width 600 -height 400 -bg white
pack .c -fill both
.c delete all
set s [::Plotchart::createXLogYPlot .c {0 100 10} {1 100}]
for { set i 0 } {$i < 20 } { incr i } {
set x [expr {$i*5.0}]
set y [expr {$x+1.0}] ;# Should not be zero!
$s plot data $x $y
}
Note: no need to pass the logarithm of the y-value - that is done by
the plot function itself.
Regards,
Arjen
Arjen Markus
> On 20 nov, 10:59, Torsten Reincke <b...@typoscriptics.de> wrote:
>
> Hundreds of thousands of points ... well, I can add a subcommand
> to plot a bunch of points at the same time - that should get
> rid of some overhead.
>
What a difference one single letter makes: replace the "f" in
"of" by an "r", please :).
Looking over your suggestions again, I think there are a
number of things that I can fairly easily implement (like
the inverse axis bit).
Zooming in is a bit tougher (it would be nice to let the
user zoom in via selecting a rectangle via the mouse and then zoom out
again, so add some interactive functionality).
As for callbacks, yes, that ought to be relatively easy, as
the canvas has adequate support for such things, but we
need to discuss how to.
Oh well, some early-morning musings ...
Regards,
Arjen
Torsten Reincke
> What a difference one single letter makes: replace the "f" in
> "of" by an "r", please :).
Sure :-) Let's just say 5000 points for a relatively normal plot in my
application.
> Looking over your suggestions again, I think there are a
> number of things that I can fairly easily implement (like
> the inverse axis bit).
That would be cool.
> Zooming in is a bit tougher (it would be nice to let the
> user zoom in via selecting a rectangle via the mouse and then zoom out
> again, so add some interactive functionality).
BLT does it this way using a zoom stack and a marching ants rectangle
for the interactive zoom selection.
> As for callbacks, yes, that ought to be relatively easy, as
> the canvas has adequate support for such things, but we
> need to discuss how to.
What would be nice is a callback to format the tick labels. If I
specify an axis as {0 10 1} I get numbers formatted as 1.0, 2.0, and
so on, but I would have preferred 1, 2, 3, ... Imagine having an
option like '-formatcommand' that would register a proc to be called
just before the label is displayed on the canvas. I could then do
things like
proc myFormat {label} {return expr {int($label)}}
or convert the number into a weekday or ... whatever (this idea is of
course "stolen" from BLT).
And then a callback on the points themselves, so I can define a
binding for "mouse over" that can diplay some info on the poit under
the cursor.
Apart from that, I'm now going to try the log plot you mentioned :-)
Torsten
Arjen Markus
Quick update:
- I repaired a small glitch in the drawing of the logarithmic
axis
- I have implemented reversed axes (Use: {100 0 -10} for
instance), with additional support in [determineScale].
(The above changes are available from CVS)
- I have implemented a rescale subcommand that redraws the
axes and rescales the data (no need to manage the data
explicitly :). Interactive zooming and keeping track of
zoom windows is a next step.
Regards,
Arjen
relaxmike
Arjen Markus
> You are fast !
Well, it is an intriguiging aspect, I had some time this weekend and
it turned out to be much easier than I feared.
Regards,
Arjen
Torsten Reincke
> Quick update:
> - I repaired a small glitch in the drawing of the logarithmic
> axis
> - I have implemented reversed axes (Use: {100 0 -10} for
> instance), with additional support in [determineScale].
I have tried this, and it works great!
> - I have implemented a rescale subcommand that redraws the
> axes and rescales the data (no need to manage the data
> explicitly :). Interactive zooming and keeping track of
> zoom windows is a next step.
This isn't in CVS yet, right? At least I couldn't find it grepping the
source.
I treid the logarithmic plots also. Fine! They only fails when there
are large numbers in the input:
Error in startup script: floating-point value too large to represent
while executing
"expr {log10($ycrd)}"
(procedure "DrawLogData" line 3)
but this is a limitation in Tcl 8.4 and not in plotchart.
I also tried to plot something with 5000 points. Perhaps it was the
numbers I chose and the size of the canvas, but my computer nearly got
a nervous breakdown. 5000 points for a xyplot was too much, while BLT
displayed them nicely within only a split second. Well, BLT is C
code ...
... but this brouhgt me to another enhancement proposal for plotchart.
Is it possible to only plot the data points (as points) without
connecting them with lines? I didn't find a way to do this in the
documentation. This should be a simple modification of the code and
speed things up a bit, no?
Thanks for you effort, Arjen!
Torsten
Arjen Markus
Ah, it is fun! And useful to me too.
>
> Torsten
Hm, I will have a look at the 5000-points problem - mind you:
most displays do not have the resolution to show them all separately -
at least if they represent a univalued function.
Single points are not going to solve it: the canvas will still
create them as separate objects and there is no "point" object.
One thing I was thinking about is to create a single line with
5000 points, rather than 4999 lines with 2 points each.
Regards,
Arjen
Arjen Markus
Hm, I tried this interactively:
package require Plotchart
canvas .c
pack .c
set p [::Plotchart::createXYPlot .c {0 100 10} {0 100 10}]
for {set i 0} {$i < 5000} {incr i} {
set x [expr {100*rand()}]
set y [expr {100*rand()}]
$p plot data $x $y
}
and got a plot filled in with a black blob in a single second.
Can you tell what you are doing differently?
Regards,
Arjen
relaxmike
I finally used the graphic commands of Plotchart instead of the BLT
commands that I used before. It was made really easy, thanks to the
excellent html documentation of the commands and the clarity of the
script. Good job.
But there was a little problem with the Bar chart, in a
particular situation where the y labels are longer than usual.
What I want to draw is a x-y bar chart where x is the number of lines
and y the tail of the name of the file. It may happen
that the file names are very long. Once drawn, it appears the
beginning of long filenames are not displayed.
This problem can be seen in the following sample script :
package require Tcl
package require Tk
package require Plotchart
for {set i 0} {$i<20} {incr i} {
set x $i
set y "very_very_very_very_long_file_name$i.txt"
lappend xydata $x $y
}
canvas .canvas1 -background white -width 600 -height 400
pack .canvas1 -fill both -side top -expand true
set xaxis {0.0 25.0 5.0}
set ylabels {}
foreach { x y } $xydata {
lappend ylabels $y
}
set barchart [Plotchart::createHorizontalBarchart .canvas1 $xaxis
$ylabels 1]
The problem is located at the beginning of the
"::Plotchart::createHorizontalBarchart" proc,
after that the call to MarginsRectangle computes the view pxmin pymin
pxmax pymax and
pass these values to viewPort. In the MarginsRectangle proc, one can
see that
the text_width argument authorizes to configure the number of
characters to display,
with a default of 8 characters.
It is expected that the y label will be displayed with a fixed font of
size 10.
There is two problems for me :
- it appears that the canvas uses a non fixed font so that all letters
do not have
the same size in pixels,
- I have a maximum y label string length greater than 8 (in the
sample : 40 characters).
This is not a bug, in fact.
I can easily make a loop to compute the maximum y label string length.
The remaining problem is that I don't know how the compute the real
size
in pixels taken by a given string with a given font.
How can I do that ?
Another question that I was wondering is why such a package uses
an internal object system based on "interp alias" instead of
using one of the available objects systems in Tcl
only (xotcl, stooop, etc...) ?
Is that for timing reasons, ie the xotcl (for example) OO system
appeared
after that the Plotchart package appeared itself ?
Best regards,
Michaël
Alexandre Ferrieux
>
> The remaining problem is that I don't know how the compute the real
> size in pixels taken by a given string with a given font.
> How can I do that ?
Create an off-screen canvas (i.e one you neither place nor pack nor
grid), then create your text item with the proper font, then ask [.c
bbox $item].
-Alex
Jonathan Bromley
Alexandre Ferrieux wrote:
>On Nov 28, 12:04 pm, relaxmike wrote:
>>
>> The remaining problem is that I don't know how the compute the real
>> size in pixels taken by a given string with a given font.
>> How can I do that ?
>
>Create an off-screen canvas (i.e one you neither place nor pack nor
>grid), then create your text item with the proper font, then ask [.c
>bbox $item].
Isn't it easier and cheaper to use [font measure]
and [font metrics] ?
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan...@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Alexandre Ferrieux
wrote:
> On Wed, 28 Nov 2007 12:04:35 -0800 (PST),
>
> Alexandre Ferrieux wrote:
> >On Nov 28, 12:04 pm, relaxmike wrote:
>
> >> The remaining problem is that I don't know how the compute the real
> >> size in pixels taken by a given string with a given font.
> >> How can I do that ?
>
> >Create an off-screen canvas (i.e one you neither place nor pack nor
> >grid), then create your text item with the proper font, then ask [.c
> >bbox $item].
>
> Isn't it easier and cheaper to use [font measure]
> and [font metrics] ?
If all you need is width, yes. But bbox gives you the height too, and
has been in Tcl for longer (if somebody remembers the version [font
measure] was introduce, I'll be grateful).
-Alex
Jonathan Bromley
<alexandre...@gmail.com> wrote:
>On Nov 28, 9:14 pm, Jonathan Bromley wrote:
>> Isn't it easier and cheaper to use [font measure]
>> and [font metrics] ?
>
>If all you need is width, yes. But bbox gives you the height too
In most cases I would have thought that the "body" height
given by [font metrics] is likely to be more useful. There
are several different measurements you can use there...
Alexandre Ferrieux
wrote:
> On Wed, 28 Nov 2007 12:23:17 -0800 (PST), Alexandre Ferrieux
>
> >On Nov 28, 9:14 pm, Jonathan Bromley wrote:
> >> Isn't it easier and cheaper to use [font measure]
> >> and [font metrics] ?
>
> >If all you need is width, yes. But bbox gives you the height too
>
> In most cases I would have thought that the "body" height
> given by [font metrics] is likely to be more useful. There
> are several different measurements you can use there...
In fact I thought bbox was more tailored to the particular string,
just like for a line item...
But trying with "____" vs. "AAAA" shows the very same height, which is
exactly the -linespace value from [font metrics]. You win :-)
-Alex
PS: Anybody remembering when [font xxx] were introduced ?
Arjen Markus
> Hi,
>
> I finally used the graphic commands of Plotchart instead of the BLT
> commands that I used before. It was made really easy, thanks to the
> excellent html documentation of the commands and the clarity of the
> script. Good job.
>
Thanks :) (It was made easy by the documentation utilities of
Tcllib by the way)
Well, one of the enhancements I have been thinking about
is a way to make the layout more flexible, so that you
can customise the amount of space for axis labels or titles.
Not quite sure how to do that:
- Setting a global option _before_ actually creating a plot
would be the easiest way implementation-wise,
but it seems unnatural
- Setting an option afterwards, means redrawing the plot.
I have demonstrating to myself that that can actually
be easier than I thought, but still requires some work.
>
> Another question that I was wondering is why such a package uses
> an internal object system based on "interp alias" instead of
> using one of the available objects systems in Tcl
> only (xotcl, stooop, etc...) ?
> Is that for timing reasons, ie the xotcl (for example) OO system
> appeared
> after that the Plotchart package appeared itself ?
>
I designed Plotchart to work with the Tcl core. I could have
used stooop, as that is Tcl-only, or snit, but when I started
working on Plotchart, there was little clarity as to what OO
extension/methodology was preferred. Besides, the amount of
OO needed for Plotchart is minimal, like you saw in the
source code: [interp alias] is all that is required.
Maybe in retrospect I could have done it differently, especially
with Tcl 8.5's OO facilities.
Regards,
Arjen
Torsten Reincke
> Can you tell what you are doing differently?
Well here is my script to compare BLT and plotchart:
for {set x 0} {$x < 5000} {incr x} {
lappend xdata $x
lappend ydata [expr {$x*$x}]
}
puts "numbers generated"
package require BLT
set b [blt::graph .b -plotrelief flat -background white -borderwidth
10]
pack $b -expand yes -fill both
$b element create bla -xdata $xdata -ydata $ydata -fill black \
-outline black -symbol {} -linewidth 3
$b legend configure -hide 1
$b xaxis configure -title "Anzahl Stationen" -stepsize 2 \
-min 0 -max [lindex $xdata end]
$b yaxis configure -title "Anzahl Taxa (kumulativ)" \
-min 0 -max [lindex $ydata end]
update
puts "blt finished"
package require Plotchart
canvas .cc -background white -width 400 -height 300
pack .cc -expand yes -fill both
set bb [::Plotchart::createXYPlot .cc "0 [lindex $xdata end] 2" "0
[lindex $ydata end] 10"]
$bb xtext "Anzahl Stationen"
$bb ytext "Anzahl Taxa (kumulativ)"
foreach x $xdata y $ydata {$bb plot bla $x $y}
# bind .cc <Configure> [list $bb rescale]
puts "plotchart finished"
The problem is not the plot itself, but the annotation of the axes.
Runing the above script, I have chosen ridiculously many subdivisions
of the axes. Changing that to reasonable values like "0 [lindex $xdata
end] 1000" and "0 [lindex $ydata end] 5000000" will speed up things
pretty much. I don't know if it is the numbers or the tick marks, that
take most time.
Perhaps another idea (I am never short of ideas :-) is to make
plotchart automatically choose reasonable values for the axes. There
is code in BLT to do so, which could be adopted.
> One thing I was thinking about is to create a single line with
> 5000 points, rather than 4999 lines with 2 points each.
Perhaps, I was not clear enough. What I would need is a so-called
scatterplot, where the data points do not depict a function. A typical
example from one of my projects: http://tcl.typoscriptics.de/misc/scatter.png
This graph has nearly 10,000 points, where many of them lie upon each
other (these are "statistical doubles").
Torsten
Larry W. Virden
wrote:
> PS: Anybody remembering when [font xxx] were introduced ?
While I didn't remember, I have several Tk distributions locally. The
font command appeared in tk 8.0.
Arjen Markus
Ah! wrt the plotting time
Ah! wrt the dots
Well, you asked for an axis from 0 to 5000*5000 with a spacing between
the labels of 2 - so you get a large number of them :)
I am not sure how BLT interprets the stepsize - apparently
differently from Plotchart.
And the dots: you can specify a symbol (plus, cross, dot ...)
without a line - I have to look up the exact command in the
documents. I am not sure if small dots are available.
Regards,
Arjen
relaxmike
which is
what I need.
It was easy for me to compte the maximal x size of the ylabels,
with the following loop :
label .invisibleLabel
set fontname [.invisibleLabel cget -font]
destroy .invisibleLabel
set xspacemax 0
foreach ylab $ylabels {
set xspace [font measure $fontname $ylab]
if {$xspace> $xspacemax} then {
set xspacemax $xspace
}
}
set text_width [expr {int ( ($xspacemax + 10.) / 10.)}]
Unfortunately, there is not current support in Plotchart for
fonts, so I had to compute the default font with an invisible label
widget. In the future, there could be the possibility to set the
font of each Plotchart widget, with a default font. It should be
that font which should be measured instead of my ugly hack...
Best regards,
Michaël