selection in OB browser
Locked
 
|
Hi lukas
I refactored a lot of code with gary yesterday and when we used refactor like push up method for example, we got bitten by two problems after the method is moved, the method with the same name but self halt is selected. I think that it would be better to select another one, like that we can directly refactor the next one. Else you read again the code during 2 s and think ok this is the old one but this is really taking cycle of attention. The selection is strange, often I got an item kind of selected because it was in light blue but the list itself was not selected so I could select the refactoring to happy but the system barked telling me that the selection was not good and I have to click again on the item so select it for real (in the case I could see the selection because the list was surrounded by a blue line). If you have time this would be great to fix these two problems. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> after the method is moved, the method with the same name but self halt is selected.
> I think that it would be better to select another one, like that we can directly refactor the next one. > Else you read again the code during 2 s and think ok this is the old one but this is really taking cycle of attention. The refactoring is performed in a different thread than the one that updates the GUI and refreshes the display. So it takes a few hundred milliseconds to propagate the changes to all other browser windows. You can see the same when you edit a method. I've committed a little change that forces the browser that opened the refactoring change browser to immediately refresh the original browser. For all the other windows it still takes a short time to refresh. Name: OB-Refactory-lr.221 Author: lr Time: 18 July 2010, 11:09:39 am UUID: ea66aaba-9f9e-4f48-9cfd-9710601065b8 Ancestors: OB-Refactory-lr.220 - force the browser that performs a refactoring to refresh immediately (all other browsers still take a few 100 milliseconds to get the system change notification and to refresh the display) > The selection is strange, often I got an item kind of selected because it was in light blue but the list itself was > not selected so I could select the refactoring to happy but the system barked telling me that the selection was not > good and I have to click again on the item so select it for real (in the case I could see the selection because the list > was surrounded by a blue line). Can you describe step by step how to reproduce that? I am not aware of such a problem. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Jul 18, 2010, at 11:10 AM, Lukas Renggli wrote: >> after the method is moved, the method with the same name but self halt is selected. >> I think that it would be better to select another one, like that we can directly refactor the next one. >> Else you read again the code during 2 s and think ok this is the old one but this is really taking cycle of attention. > > The refactoring is performed in a different thread than the one that > updates the GUI and refreshes the display. So it takes a few hundred > milliseconds to propagate the changes to all other browser windows. > You can see the same when you edit a method. > > I've committed a little change that forces the browser that opened the > refactoring change browser to immediately refresh the original > browser. For all the other windows it still takes a short time to > refresh. Thanks lukas > > Name: OB-Refactory-lr.221 > Author: lr > Time: 18 July 2010, 11:09:39 am > UUID: ea66aaba-9f9e-4f48-9cfd-9710601065b8 > Ancestors: OB-Refactory-lr.220 > > - force the browser that performs a refactoring to refresh > immediately (all other browsers still take a few 100 milliseconds to > get the system change notification and to refresh the display) > >> The selection is strange, often I got an item kind of selected because it was in light blue but the list itself was >> not selected so I could select the refactoring to happy but the system barked telling me that the selection was not >> good and I have to click again on the item so select it for real (in the case I could see the selection because the list >> was surrounded by a blue line). > > Can you describe step by step how to reproduce that? I am not aware of > such a problem. It happened to us a lot when we pushed up a method. So you select the method, bring push up and then you go to the next one but the list is not selected just the item. I got that a lot during our refactoring session. BTW lukas could you have rename class >>>rename class refactoring close to rename class? Because this is something that we do often. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> It happened to us a lot when we pushed up a method. So you select the method, bring push up and then you go to the next one
> but the list is not selected just the item. > I got that a lot during our refactoring session. Name: OmniBrowser-lr.483 Author: lr Time: 18 July 2010, 3:20:03 pm UUID: f8c1b3df-4fda-4cf2-a533-e721c0cd5088 Ancestors: OmniBrowser-lr.482 - more agressively refresh display when a node disappears > BTW lukas could you have > rename class >>>>rename class refactoring close to rename class? Consistency is more important in my option. Otherwise we have to move all other refactorings too and we end up with a mess. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Jul 18, 2010, at 3:23 PM, Lukas Renggli wrote: >> It happened to us a lot when we pushed up a method. So you select the method, bring push up and then you go to the next one >> but the list is not selected just the item. >> I got that a lot during our refactoring session. > > Name: OmniBrowser-lr.483 > Author: lr > Time: 18 July 2010, 3:20:03 pm > UUID: f8c1b3df-4fda-4cf2-a533-e721c0cd5088 > Ancestors: OmniBrowser-lr.482 > > - more agressively refresh display when a node disappears > >> BTW lukas could you have >> rename class >>>>> rename class refactoring close to rename class? > > Consistency is more important in my option. Otherwise we have to move > all other refactorings too and we end up with a mess. no no no this is not a question of consistency. this is question of use. Rename class and rename class refactoring should be together. Believe the user. Stef > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |