visualpython-users

Re: [Visualpython-users] Visual 2001-10-15

[David A. <dm...@an...>]

I should have mentioned, this version also includes idlefork, an enhanced 
version of the IDLE integrated development environment.

[Visualpython-users] Visual 2001-10-15

[David A. <dm...@an...>]

I've built visual for Redhat Linux 7.1, Python 2.1.1 and updated our Web 
page accordingly.

Included are all the pieces required to install Python 2.1.1, Numeric, 
libgtkglarea and visual.

Also included is the source RPM for visual, plus the python and 
libgtkglarea pieces required to build visual.

Re: [Visualpython-users] arrow shaftwidth question

[Arthur S. <aj...@ix...>]

My particular problem is a different situation - the long arrow
(versus the short arrow).  In this case, if the length is more than
50 times the shaftwidth, there is automatic rescaling - the shaft thickens.
You can also see this phenom in the crossproduct demo.

It is not clear exactly how the rescaling works.  It is clear that in some
of my constructions, its not quite what I want.  My issue is the lack
of control of the specifics. The issue, since my app is dynamic, is
that the rescaling kicks in suddenly and is somewhat jarring
visually.  Why 50 times - when 25 or 100 might work much
better in a particular situation.  Or none, if that happens to work
in a particular instance. The default behavior is probably reasonable.
The inability to override the defaults in a meaningful way, is
frustrating.

Wondering out loud if Python2.2 will allow me to sub-class the arrow
and get closer to what I want.

Also wishing I had a better handle on Python extension stuff in C.
Wondering out loud if giving the configure the ability to set the
min/max settings from Python is a big or little thing.

Art





----- Original Message -----
From: "Bruce Sherwood" <ba...@an...>
To: <vis...@li...>
Sent: Sunday, October 14, 2001 6:09 PM
Subject: Re: [Visualpython-users] arrow shaftwidth question


> I realize that it is difficult to express graphics in words, but can you
> say more about your needs, and how additional attributes of the arrow
> object might meet them?
>
> I'll try to express graphics in words about the current situation. If the
> arrow is so short that the head length is a large fraction of the arrow
> length (equal to or greater than half, currently), the whole arrow, shaft
> width and head, are shrunk to retain the shape of an arrow (rather than
> turning into a cone).
>
> Bruce Sherwood
>
> --On Sunday, October 14, 2001 14:36 -0400 Arthur Siegel
<aj...@ix...>
> wrote:
>
> > My solution at this point has been to alter the "min" settings in
> > the arrow C code to something that works better for me, and
> > recompile.
> >
> > My wish is either to be able to set the min/max settings from
> > Python, or to allow some override of the min/max behavior.
> > As it stands writing to shaftwidth does not seem to take, once
> > the min/max conditions have set in.
> >
> > Art
>
>
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] arrow shaftwidth question

[Bruce S. <ba...@an...>]

I realize that it is difficult to express graphics in words, but can you 
say more about your needs, and how additional attributes of the arrow 
object might meet them?

I'll try to express graphics in words about the current situation. If the 
arrow is so short that the head length is a large fraction of the arrow 
length (equal to or greater than half, currently), the whole arrow, shaft 
width and head, are shrunk to retain the shape of an arrow (rather than 
turning into a cone).

Bruce Sherwood

--On Sunday, October 14, 2001 14:36 -0400 Arthur Siegel <aj...@ix...> 
wrote:

> My solution at this point has been to alter the "min" settings in
> the arrow C code to something that works better for me, and
> recompile.
>
> My wish is either to be able to set the min/max settings from
> Python, or to allow some override of the min/max behavior.
> As it stands writing to shaftwidth does not seem to take, once
> the min/max conditions have set in.
>
> Art

Re: [Visualpython-users] arrow shaftwidth question

[Arthur S. <aj...@ix...>]

My solution at this point has been to alter the "min" settings in
the arrow C code to something that works better for me, and
recompile.

My wish is either to be able to set the min/max settings from
Python, or to allow some override of the min/max behavior.
As it stands writing to shaftwidth does not seem to take, once
the min/max conditions have set in.

Art

----- Original Message -----
From: "Bruce Sherwood" <ba...@an...>
To: <vis...@li...>
Sent: Sunday, October 14, 2001 12:07 PM
Subject: Re: [Visualpython-users] arrow shaftwidth question


> That indeed is probably it. As you said in another note, this behavior can
> be seen in the cross-product demo: when an arrow gets very short, we
shrink
> the whole thing. The reason for doing this is to provide some visual cue
as
> long as possible for there being an arrow present. If we were to keep the
> shaft width fixed for very short arrows, we wouldn't be able to show an
> arrow-like object.
>
> It is of course possible that there is some other solution to this;
perhaps
> someone can suggest a better solution to the problem of very short arrows.
>
> Bruce Sherwood
>
> --On Sunday, October 14, 2001 11:49 -0400 Arthur Siegel
<aj...@ix...>
> wrote:
>
> > "If headlength becomes larger than half the length of the arrow,
> > or the shaft becomes thinner than 1/50 the length, the entire
> > arrow is scaled accordingly."
>
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] arrow shaftwidth question

[Bruce S. <ba...@an...>]

That indeed is probably it. As you said in another note, this behavior can 
be seen in the cross-product demo: when an arrow gets very short, we shrink 
the whole thing. The reason for doing this is to provide some visual cue as 
long as possible for there being an arrow present. If we were to keep the 
shaft width fixed for very short arrows, we wouldn't be able to show an 
arrow-like object.

It is of course possible that there is some other solution to this; perhaps 
someone can suggest a better solution to the problem of very short arrows.

Bruce Sherwood

--On Sunday, October 14, 2001 11:49 -0400 Arthur Siegel <aj...@ix...> 
wrote:

> "If headlength becomes larger than half the length of the arrow,
> or the shaft becomes thinner than 1/50 the length, the entire
> arrow is scaled accordingly."

Re: [Visualpython-users] arrow shaftwidth question

[Arthur S. <aj...@ix...>]

From the docs for arrow:

"If headlength becomes larger than half the length of the arrow,
or the shaft becomes thinner than 1/50 the length, the entire
arrow is scaled accordingly."

I suspect my issue is in there somewhere.  I will play with setting
headlength to a constant and see how that behaves.

Art


----- Original Message -----
From: "Bruce Sherwood" <ba...@an...>
To: <vis...@li...>
Sent: Sunday, October 14, 2001 10:59 AM
Subject: Re: [Visualpython-users] arrow shaftwidth question


> As the documentation says, the shaft width is proportional to arrow length
> only as a default (which can also be invoked by setting shaft width to
> zero). If you specify the shaft width explicitly, that's the shaft width
> you get. Do you have a suggestion of how to reword the documentation to
> make this more clear?
>
> Bruce Sherwood
>
> --On Sunday, October 14, 2001 10:34 -0400 Arthur Siegel
<aj...@ix...>
> wrote:
>
> > The implementation - for reasons I don't understand - has the arrow
shaft
> > dependent upon the arrow length.  Length times .1 as the default.
> >
> > I am looking to override this behavior - to achieve a constant shaft in
an
> > interactive environment where the arrow length might change dynamically.
> > Would think that a "normalization" routine would work - dynamically
divide
> > by arrow.length.
> > But haven't had success.
>
>
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] arrow shaftwidth question

[Arthur S. <aj...@ix...>]

The docs are fine.

But I am not getting the behavior I expect.

If I set a specific fixed shaftwidth, that is my *initial*
width.  But the width varies  as the length varies interactively.

I believe the behavior I am referring to can be seen in the
cross_product demo where the shaftwidth is initially
set to a constant, but varies in the interactive scene.

Am I missing something?

Art

----- Original Message -----
From: "Bruce Sherwood" <ba...@an...>
To: <vis...@li...>
Sent: Sunday, October 14, 2001 10:59 AM
Subject: Re: [Visualpython-users] arrow shaftwidth question


> As the documentation says, the shaft width is proportional to arrow length
> only as a default (which can also be invoked by setting shaft width to
> zero). If you specify the shaft width explicitly, that's the shaft width
> you get. Do you have a suggestion of how to reword the documentation to
> make this more clear?
>
> Bruce Sherwood
>
> --On Sunday, October 14, 2001 10:34 -0400 Arthur Siegel
<aj...@ix...>
> wrote:
>
> > The implementation - for reasons I don't understand - has the arrow
shaft
> > dependent upon the arrow length.  Length times .1 as the default.
> >
> > I am looking to override this behavior - to achieve a constant shaft in
an
> > interactive environment where the arrow length might change dynamically.
> > Would think that a "normalization" routine would work - dynamically
divide
> > by arrow.length.
> > But haven't had success.
>
>
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] arrow shaftwidth question

[Bruce S. <ba...@an...>]

As the documentation says, the shaft width is proportional to arrow length 
only as a default (which can also be invoked by setting shaft width to 
zero). If you specify the shaft width explicitly, that's the shaft width 
you get. Do you have a suggestion of how to reword the documentation to 
make this more clear?

Bruce Sherwood

--On Sunday, October 14, 2001 10:34 -0400 Arthur Siegel <aj...@ix...> 
wrote:

> The implementation - for reasons I don't understand - has the arrow shaft
> dependent upon the arrow length.  Length times .1 as the default.
>
> I am looking to override this behavior - to achieve a constant shaft in an
> interactive environment where the arrow length might change dynamically.
> Would think that a "normalization" routine would work - dynamically divide
> by arrow.length.
> But haven't had success.

[Visualpython-users] arrow shaftwidth question

[Arthur S. <aj...@ix...>]

The implementation - for reasons I don't understand - has the arrow shaft
dependent upon the arrow length.  Length times .1 as the default.

I am looking to override this behavior - to achieve a constant shaft in an
interactive environment where the arrow length might change dynamically.
Would think that a "normalization" routine would work - dynamically divide
by arrow.length.
But haven't had success.

Anyone have ideas on this?

Art

[Visualpython-users] Linux documentation

[Bruce S. <ba...@an...>]

For those of you using VPython on Linux or Unix, I'd be interested to know 
where you install Python and Visual documentation (if you do). Do you put 
these in /usr/share/doc? Is there a convention for this?

This ties into issues of where IDLE on Unix/Linux should point for giving 
easy access to appropriate documentation.

Bruce Sherwood

[Visualpython-users] subscribe

[Brian C. <bc...@ge...>]

=============================
Brian Colfer
Sr. Release Engineer
bc...@ge...
Mobile: 415 290 6855
=============================

RE: [Visualpython-users] bug/typo in latest download

[Kevin C. <kj...@gr...>]

I GUESS for now I'll grab the .zip, and monkey with that.
More than one string replacement needed... Here's what I see:

  $ grep "\*\*" *.py

  __init__.py:    def __call__(self, *args, **kw):
  __init__.py:    def __call__(self, *args, **kw):
  graph.py:    number = 10.**mantissa
  graph.py:    return (sign*(array(marks)*10.**exponent)).tolist(), format
  graph.py:    def __init__(self, **args):
  graph.py:    def plot(self, **args):
  graph.py:    def __init__(self, **args):
  graph.py:    def plot(self, **args):
  graph.py:    def __init__(self, **args):
  graph.py:    def plot(self, **args):
  graph.py:    def __init__(self, **args):
  graph.py:    def plot(self, **args):
  graph.py:    def __init__(self, **args):
  graph.py:        gvbars.__init__(self, **args)
  graph.py:    def __init__(self, **args):
  graph.py:        ghbars.__init__(self, **args)
  graph.py:    def __init__(self, **args):
  graph.py:        gdots.__init__(self, **args)

RE: [Visualpython-users] bug/typo in latest download (artifact of C)? (fwd)

[Bruce S. <ba...@an...>]

The current version of graph.py in CVS does indeed have the form

	apply( gvbars.__init__, (self,), args)

So the problem seems to be how the Linux 1.5.2 distribution is put together.

Bruce Sherwood

---------- Forwarded Message ----------
Date: Monday, October 08, 2001 3:11 PM -0400
From: David Scherer <dsc...@vy...>
To: vis...@li...
Subject: RE: [Visualpython-users] bug/typo in latest download (artifact of 
C)?

> [Bruce writes]
>> Maybe there's a bad copy of graph.py in our Linux distribution files?
>
> No.  The SyntaxError below is caused by the use of the **args syntax,
> which is not supported by Python 1.5.2.  I don't know whether the Linux
> distribution is supposed to run on 1.5.2 or not.  If it is, this line
> needs to be replaced, e.g.
>
>   apply( gvbars.__init__, (self,), args)
>
> If not, the solution is to upgrade to a more recent version of Python.
>
> Dave
>
>> >         gvbars.__init__(self, **args)
>> >                            ^
>> >     SyntaxError: invalid syntax
>
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

---------- End Forwarded Message ----------

RE: [Visualpython-users] bug/typo in latest download (artifact of C)?

[Ari H. <ahe...@an...>]

On Mon, 8 Oct 2001, David Scherer wrote:

> [Bruce writes]
> > Maybe there's a bad copy of graph.py in our Linux distribution files?
>
> No.  The SyntaxError below is caused by the use of the **args syntax,
> which is not supported by Python 1.5.2.  I don't know whether the Linux
> distribution is supposed to run on 1.5.2 or not.  If it is, this line
> needs to be replaced, e.g.
>
>   apply( gvbars.__init__, (self,), args)
>
> If not, the solution is to upgrade to a more recent version of Python.
>
> Dave
>
> > >         gvbars.__init__(self, **args)
> > >                            ^
> > >     SyntaxError: invalid syntax

Man. I seem to keep fixing this in CVS (possibly in multiple places) and it
seems to keep creeping back in.

We could move to python2 on Linux; it would mean a few modifications to the
current packaging tools, but it could be done.


Ari

RE: [Visualpython-users] Doc files

[Bruce S. <ba...@an...>]

Sharp eyes! You're right, although the Python documentation would still be 
usable, in the sense that F1 in IDLE would take you to the VPython 
documentation index, where you would click the Python documentation and get 
it, while clicking on any of the VPython documentation would give you a 
broken link.

I haven't quite understood the uninstall options in Inno Setup, but I'll 
try to put things back the way they were if I can.

I've released this stuff onto the VPython site, including not showing an 
error message if there is no index.html (in which case the installer 
silently installs appropriate Doc files).

Bruce Sherwood

--On Monday, October 08, 2001 3:08 PM -0400 David Scherer 
<dsc...@vy...> wrote:

> The only thing I can see that could be improved in the below procedure
> is that on uninstall, the original state of affairs should be restored
> by copying Python.html over index.html (and removing the former).
>
> Otherwise uninstalling VPython will leave a Python installation with bad
> links in the documentation.

RE: [Visualpython-users] bug/typo in latest download (artifact of C)?

[David S. <dsc...@vy...>]

[Bruce writes]
> Maybe there's a bad copy of graph.py in our Linux distribution files?

No.  The SyntaxError below is caused by the use of the **args syntax,
which is not supported by Python 1.5.2.  I don't know whether the Linux
distribution is supposed to run on 1.5.2 or not.  If it is, this line
needs to be replaced, e.g.

  apply( gvbars.__init__, (self,), args)

If not, the solution is to upgrade to a more recent version of Python.

Dave

> >         gvbars.__init__(self, **args)
> >                            ^
> >     SyntaxError: invalid syntax

RE: [Visualpython-users] Doc files

[David S. <dsc...@vy...>]

The only thing I can see that could be improved in the below procedure
is that on uninstall, the original state of affairs should be restored
by copying Python.html over index.html (and removing the former).

Otherwise uninstalling VPython will leave a Python installation with bad
links in the documentation.

Dave

> -----Original Message-----
> From: vis...@li... 
> [mailto:vis...@li...] On 
> Behalf Of Bruce Sherwood
> Sent: Monday, October 08, 2001 2:15 PM
> To: vis...@li...
> Cc: idle
> Subject: [Visualpython-users] Doc files
> 
> 
> The idlefork project at sourceforge.net began with the IDLE 
> version created 
> by Dave Scherer in the VPython context. It is now being 
> extended, and bugs 
> being fixed, with the goal of becoming the version of IDLE to be 
> distributed with future versions of Python. The idlefork version has 
> reached a level of maturity that makes it feasible to use it 
> rather than 
> the original VPython version, with the long-term advantage of 
> there being 
> only one version of Scherer-based IDLE to maintain and extend.
> 
> In the past, the VPython installer installed Doc\VPython.html 
> with a link 
> to Doc\index.html, the standard documentation home page for 
> Python. The 
> original VPython version of IDLE linked to Doc\VPython.html when you 
> pressed F1 for help. The idlefork version links to 
> index.html, and it would 
> be desirable not to change IDLE to accomodate the wider 
> documentation needs 
> of Python+Visual.
> 
> In the idlefork discussion I proposed overwriting index.html with the 
> VPython index, and installing a copy of the Python index. But 
> a reader 
> pointed out that he makes changes to the Python index (to add more 
> documentation links), and the VPython installer would overwrite the 
> changes. I think I've sorted out how to build the VPython 
> installer so as 
> to preserve user changes to the standard Python 
> Doc\index.html. If you see 
> a hole in my logic, please criticize! I'm using Inno Setup 
> with Extensions 
> to create the installer.
> 
> 1) In the Doc directory, if Python.html doesn't exist, copy 
> index.html to 
> Python.html.
> 
> 2) If Python.html still doesn't exist, install a copy from 
> the installation 
> procedure.
> 
> 3) Install index.html (the base of the VPython documentation, 
> with link to 
> Python.html), overwriting index.html if necessary.
> 
> 4) Specify in the installer that Doc\index.html and 
> Doc\Python.html are not 
> to be removed by the VPython uninstaller.
> 
> I've tested this scheme to some extent, but I'm worried that 
> I might have a 
> logical flaw somewhere. It does seem robust to multiple installs and 
> uninstalls of VPython. The only problem I've found with it is 
> that if there 
> is no Doc\index.html, you get an error message, but if you 
> choose "skip" 
> (rather than aborting the installation) both index.html and 
> Python.html are 
> installed correctly. However, if there is no index.html, 
> there are other 
> things wrong anyway, so maybe this isn't terrible (or maybe I 
> can find a 
> way to have the installer not issue a warning in this case).
> 
> Bruce Sherwood
> 
> 
> _______________________________________________
> Visualpython-users mailing list 
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
> 

Re: [Visualpython-users] bug/typo in latest download (artifact of C)?

[Bruce S. <ba...@an...>]

This looks like your copy of visual/graph.py has somehow been damaged; it 
shouldn't have any syntax errors. On the VPython site, on the download page 
for any platform, go the the documentation etc. page and get just the 
visual zip file, from which you can extract a fresh copy of graph.py.

Maybe there's a bad copy of graph.py in our Linux distribution files?

Bruce Sherwood

--On Monday, October 08, 2001 2:34 PM -0400 Kevin Cole 
<kj...@gr...> wrote:

>     $ python graphtest.py
>     Visual-2001-09-24
>     Traceback (innermost last):
>       File "graphtest.py", line 1, in ?
>         from visual.graph import *
>       File "/usr/lib/python1.5/site-packages/visual/graph.py", line 544
>         gvbars.__init__(self, **args)
>                            ^
>     SyntaxError: invalid syntax
>     $

[Visualpython-users] bug/typo in latest download (artifact of C)?

[Kevin C. <kj...@gr...>]

Hi,

I'm quite new to VPython, and started by running each of the demos to
see what they did.  (I'm running RedHat 7.1, Python 1.5.2, and the
Numerical-13.tar.gz and visual-2001.09.24-3.i386.rpm downloaded from
cil.andrew.cmu.edu last week.)

Most of the demos work (though a few don't seem to want to let me exit).
However a couple give results like this:

    $ python graphtest.py
    Visual-2001-09-24
    Traceback (innermost last):
      File "graphtest.py", line 1, in ?
        from visual.graph import *
      File "/usr/lib/python1.5/site-packages/visual/graph.py", line 544
        gvbars.__init__(self, **args)
                           ^
    SyntaxError: invalid syntax
    $

Known problem?  (I searched the mailing-list archive but didn't turn up
anything.)

[Visualpython-users] Doc files

[Bruce S. <ba...@an...>]

The idlefork project at sourceforge.net began with the IDLE version created 
by Dave Scherer in the VPython context. It is now being extended, and bugs 
being fixed, with the goal of becoming the version of IDLE to be 
distributed with future versions of Python. The idlefork version has 
reached a level of maturity that makes it feasible to use it rather than 
the original VPython version, with the long-term advantage of there being 
only one version of Scherer-based IDLE to maintain and extend.

In the past, the VPython installer installed Doc\VPython.html with a link 
to Doc\index.html, the standard documentation home page for Python. The 
original VPython version of IDLE linked to Doc\VPython.html when you 
pressed F1 for help. The idlefork version links to index.html, and it would 
be desirable not to change IDLE to accomodate the wider documentation needs 
of Python+Visual.

In the idlefork discussion I proposed overwriting index.html with the 
VPython index, and installing a copy of the Python index. But a reader 
pointed out that he makes changes to the Python index (to add more 
documentation links), and the VPython installer would overwrite the 
changes. I think I've sorted out how to build the VPython installer so as 
to preserve user changes to the standard Python Doc\index.html. If you see 
a hole in my logic, please criticize! I'm using Inno Setup with Extensions 
to create the installer.

1) In the Doc directory, if Python.html doesn't exist, copy index.html to 
Python.html.

2) If Python.html still doesn't exist, install a copy from the installation 
procedure.

3) Install index.html (the base of the VPython documentation, with link to 
Python.html), overwriting index.html if necessary.

4) Specify in the installer that Doc\index.html and Doc\Python.html are not 
to be removed by the VPython uninstaller.

I've tested this scheme to some extent, but I'm worried that I might have a 
logical flaw somewhere. It does seem robust to multiple installs and 
uninstalls of VPython. The only problem I've found with it is that if there 
is no Doc\index.html, you get an error message, but if you choose "skip" 
(rather than aborting the installation) both index.html and Python.html are 
installed correctly. However, if there is no index.html, there are other 
things wrong anyway, so maybe this isn't terrible (or maybe I can find a 
way to have the installer not issue a warning in this case).

Bruce Sherwood

Re: [Visualpython-users] Re: Some ideas (Konrad Piwowarczyk)

[Konrad P. <kon...@po...>]

Surely, after I develop tkWidget for VPython I will announce it here!
I suppose it takes some time ;-)
Thanks for encouraging me, Ryan!

Konrad

----- Original Message -----
From: "Ryan Martens" <RMA...@md...>
To: <vis...@li...>
Sent: Monday, October 01, 2001 2:37 PM
Subject: [Visualpython-users] Re: Some ideas (Konrad Piwowarczyk)


> That would be very useful.  If you run into any success or problems,
please let us listeners out here know.  I've been interested in such a
feature for a while now, but haven't had the time to sit down and do it.
>
> Thanks a lot,
>
> Ryan




-- 

Zagraj z finalistkami
Miss Polonia [ http://miss.onet.pl/start.html ]

[Visualpython-users] VPython site back

[Bruce S. <ba...@an...>]

During the last 24 hours or more there were campus file server problems 
that prevented the VPython server from accessing files. It all seems okay 
now.

Bruce

--On Monday, October 01, 2001 12:10 AM -0400 Ari Heitner 
<ahe...@an...> wrote:

> virtualphoton.pc.cc.cmu.edu has been very slow for me for the last couple
> of days, and other people (outside CMU, I think) have complained about it
> as well.
>
> is it having problems?

[Visualpython-users] Re: Some ideas (Konrad Piwowarczyk)

[Ryan M. <RMA...@md...>]

That would be very useful.  If you run into any success or problems, =
please let us listeners out here know.  I've been interested in such a =
feature for a while now, but haven't had the time to sit down and do it.

Thanks a lot,

Ryan

----- Original Message -----
From:	"Konrad Piwowarczyk" <kon...@po...>
To:	"Ari Heitner" <ahe...@an...>
Cc:	<vis...@li...>
Subject: Re: [Visualpython-users] Some ideas
Date:	Fri, 28 Sep 2001 21:53:17 +0200

I will try to write new context for interacting with tkinter thanks for
advice!
I need it because placing many charts and control panels in many
different windows is really not convenient
I have played with colorsliders demo, hmm... Tk sliders are easier to
use ( I had to learn how to select balls without zooming the whole
scene ) and I am not convinced to mix animation and controls.
Is it possible to highlight sliders while mouse is over? - such
interaction causes that one knows exactly what is happening with the
mouse.

And what about Glut?

Konrad Piwowarczyk

Re: [Visualpython-users] Some ideas

[Bruce S. <ba...@an...>]

Yes, but you have to do it yourself. In an endless loop, watch for the 
mouse location in the plane of the control to be on the control, and change 
the color.

--On Friday, September 28, 2001 21:53 +0200 Konrad Piwowarczyk 
<kon...@po...> wrote:

> Is it possible to highlight sliders while mouse is over?