Folks -
Along with the updates for 3.3a, I've also forwarded a whole bunch for 3.2gamma heh heh. This is a point where all the class builder work and all the VMMaker work is supposedly in good shape, so it's definitely a propitious time to tie a ribbon around it.
PLEASE: Get these updates and test the result, *especially* if you're a VM hacker. Does anyone know fixes to the simulator or tracer that should go in?
Scott and I will be doing some final housekeeping for 3.2 in the next couple of days, so this is the time to find (and fix) any little problems.
Thanks in advance for any testing or other suggestions regarding the final 3.2.
- Dan
My patch for MpegPlayer plugin (to handle id3v2 tags) has been submitted and should work with 3.2. I'll plan on submitting a test mp3 file and an sUnit in the next day or so.
Dan Ingalls wrote:
Folks -
Along with the updates for 3.3a, I've also forwarded a whole bunch for 3.2gamma heh heh. This is a point where all the class builder work and all the VMMaker work is supposedly in good shape, so it's definitely a propitious time to tie a ribbon around it.
PLEASE: Get these updates and test the result, *especially* if you're a VM hacker. Does anyone know fixes to the simulator or tracer that should go in?
Scott and I will be doing some final housekeeping for 3.2 in the next couple of days, so this is the time to find (and fix) any little problems.
Thanks in advance for any testing or other suggestions regarding the final 3.2.
- Dan
Hi,
When the #preserveTrash is true (3.2gamma2 does so), selected morphs can't delete. The attached cs will fix the problem.
I also found another problem that was related to trashing selected morphs. But it seems too difficult to fix for me.
1. select morphs 2. pick up them by clicking black halo 3. drop into the TrashCan 4. selection was canceled and the cover of the TrashCan is not closed even if the mouse cursor moved out of bounds of the TrashCan.
Regards,
On Wednesday 26 June 2002 06:19 am, Masato Sumi wrote:
Hi,
When the #preserveTrash is true (3.2gamma2 does so), selected morphs can't delete. The attached cs will fix the problem.
I also found another problem that was related to trashing selected morphs. But it seems too difficult to fix for me.
How should this work? It's possible that some objects in the selection resist deletion.
Right now, the SelectionMorph does addMorphFront: for every selected Morph; is this desired behavior?
I suspect what should be done is to simulate a drop event for each of the selected items, and remove those that got dropped successfully from the selection. If all were dropped successfully, it would delete itself. This would leave those objects that resisted being dropped on the receiver (in this case the TrashCan) in the selection.
on 06/26/02 23:12, ned@bike-nomad.com wrote:
How should this work? It's possible that some objects in the selection resist deletion.
I think this should work just trashing them all. Because we can drop an object into the TrashCan even if its resist deletion option is on.
In consideration of the current specification, it seems that the "resist being deleted" option is not working properly as we suppose.
For example, when resist deletion objects were preserved in the trash, we could delete them easily without any confirmation. If a morph has resist deletion submorphs, we can delete the owner not only dropping into a TrashCan but also clicking pink halo without any confirmation, too.
So, I think it is not the time to care the inadequate resist deletion option for fixing the problem before official 3.2 release.
I suspect what should be done is to simulate a drop event for each of the selected items, and remove those that got dropped successfully from the selection. If all were dropped successfully, it would delete itself.
It's nice idea if the "resist being deleted" option was available even if a drop-into-TrashCan event.
This would leave those objects that resisted being dropped on the receiver (in this case the TrashCan) in the selection.
I prefer they will return their original place before they are moved.
On Wednesday 26 June 2002 09:03 am, Masato Sumi wrote:
on 06/26/02 23:12, ned@bike-nomad.com wrote:
How should this work? It's possible that some objects in the selection resist deletion.
I think this should work just trashing them all. Because we can drop an object into the TrashCan even if its resist deletion option is on.
Try my separate change set and see if you think it works OK.
In consideration of the current specification, it seems that the "resist being deleted" option is not working properly as we suppose.
Yes.
It's nice idea if the "resist being deleted" option was available even if a drop-into-TrashCan event.
This would leave those objects that resisted being dropped on the receiver (in this case the TrashCan) in the selection.
I prefer they will return their original place before they are moved.
I didn't do that yet.
on 06/27/02 01:12, ned@bike-nomad.com wrote:
I think this should work just trashing them all. Because we can drop an object into the TrashCan even if its resist deletion option is on.
Try my separate change set and see if you think it works OK.
I tried and that's the thing I wanted to do. Thanks a lot.
squeak-dev@lists.squeakfoundation.org