1 Nov 2007 16:21
1 Nov 2007 16:22
Re: Traits timeout
It sounds to me like the auto_set/enter_set settings are inverted for the input widget you are describing... Dave Morrill jelle wrote: > Hi, > > When using TVTK with heavy files, than sometimes it can be slightly problematic > to set a parameter of a traited object. To give an example: when i adjust the > scaling of the TensorGlyph module, and let's say I want to set it from 0.1 to > 0.01, and update will be invoked when I'm still typing 0. perhaps when typing > 0.0 before I get to the value of 0.01 > Therefore I'm curious if its perhaps an idea to include a .2 seconds time-out, > such that one is able to finish setting the new value before an update occurs. > An idea perhaps? > > Cheers, > > -jelle > > _______________________________________________ > Enthought-dev mailing list > Enthought-dev@... > https://mail.enthought.com/mailman/listinfo/enthought-dev > > >
1 Nov 2007 16:21
Re: Screen updating issue in a TreeEditor
What version of Traits? In 3.0 the tree demo works fine...if I update an employee name, all identical nodes update simultaneously. It would be a mistake to assume that 3.0 only contains new features. It also contains many bug fixes as well... Dave Morrill Danny Shevitz wrote: > In a TreeEditor I'm trying to do something that may be a little funky, but it > makes in my application. I'm trying to display the same node (actually subtree) > at multiple locations in the same tree editor. > > In my app, it's analagous to having a view of the > file system with symbolic links to a directory. The same tree structure is > evident multiple times even though it really only exists once. The same issue > appears in the TreeDemo code, where the same employee appears multiple > times in the tree. > > The issue is that while the underlying trait is consistent between different > instances in the tree, the visual display of the tree nodes is not. In the tree > demo, change the name of an employee and you will see it only changes in the > tree in one spot. Underneath the hood, my suspicion is the underlying trait > is changing, but the wx.TreeItem is not. It feels like a proper implementation > would employ delegation somewhere so that the tree items really do always point > to the same underlying item. > > Am I doing something stupid as usual, and is this remediable, or is this just > not supported? > > I'm attaching sample code. On the "a.xml" tab, the wow node is in fact the(Continue reading)
1 Nov 2007 16:37
Re: Screen updating issue in a TreeEditor
David C. Morrill <dmorrill <at> ...> writes: > > What version of Traits? In 3.0 the tree demo works fine...if I update an > employee name, all identical nodes update simultaneously. It would be a > mistake to assume that 3.0 only contains new features. It also contains > many bug fixes as well... > > Dave Morrill Sorry for that, I didn't know. I'm using Traits 2.x. I still have no way of getting Traits 3.0, making me all the more desperate. D
1 Nov 2007 16:46
Re: enthought.naming dependency in Pyface
Peter Wang wrote: > Hi folks, > > From what I can tell, there are only two places where > enthought.naming is actually used in the enthought.pyface_3.0 package: > > 1. in dock/dock_window.py:wx_dropped_on() > > I talked this over with Dave P. and have made this an optional feature/dependency in DockWindows, opening the way to make enthought.naming an 'extra' from an egg installation point of view. I have not modified any setup files though... Dave Morrill
1 Nov 2007 13:00
Re: enthought.naming dependency in Pyface
>>>>> "Peter" == Peter Wang <pwang@...> writes: Peter> Hi folks, From what I can tell, there are only two places Peter> where enthought.naming is actually used in the Peter> enthought.pyface_3.0 package: [...] Peter> Can we remove/refactor these, and thus eliminate a useless Peter> dependency? +1 cheers, prabhu
1 Nov 2007 17:06
Re: enthought.naming dependency in Pyface
On Nov 1, 2007, at 10:46 AM, David C. Morrill wrote: > I talked this over with Dave P. and have made this an optional > feature/dependency in DockWindows, opening the way to make > enthought.naming an 'extra' from an egg installation point of view. I > have not modified any setup files though... Excellent, thank you guys!
1 Nov 2007 17:05
Re: Traits timeout
David C. Morrill wrote: > It sounds to me like the auto_set/enter_set settings are inverted for > the input widget you are describing... Right, IIRC, Fred wanted a feature to optionally turn on and off enter_set and auto_set. I think he had some problems with the TupleEditor and I'm not sure what happened after that. Fred? cheers, prabhu
1 Nov 2007 10:13
Re: enthought.naming dependency in Pyface
G'day, > From what I can tell, there are only two places where > enthought.naming is actually used in the enthought.pyface_3.0 package: > > 1. in dock/dock_window.py:wx_dropped_on() > 2. in new_dialog.py > > The former is a wx-specific file (which explicitly imports wx) and > only uses enthought.naming to import Binding, which is used in an > isinstance() check. The latter does not seem to be used anywhere in > other enthought packages or in the internal repositories that I've > checked. The 'new_dialog' was used in one of the old converge versions when creating new objects in the explorer I think, but IMHO it shouldn't have been in PyFace in the first place, so I'm all for getting it out... Martin
1 Nov 2007 17:22
Re: Traits timeout
Prabhu Ramachandran a écrit : > David C. Morrill wrote: > >> It sounds to me like the auto_set/enter_set settings are inverted for >> the input widget you are describing... >> > > Right, IIRC, Fred wanted a feature to optionally turn on and off > enter_set and auto_set. I think he had some problems with the > TupleEditor and I'm not sure what happened after that. > > Fred? > Only need to take some time to hack thisDave M. has given a few advices on that, so thanks Dave. I hope I'll come back soon on that issue, but for now, I'm struggling against chaco2 with traits 3.0, building eggs for etch, and so on... Cheers, -- -- http://scipy.org/FredericPetit
RSS Feed