Re: [Pharo-project] modal windows and unit tests
On Oct 13, 2010, at 3:04 PM, Alexander LazareviÄ wrote:
There are also some basic things that would need some adjustment as I see it. I think core or basic classes and models shouldn't make any assumptions about the UI or even if there is an UI at all.
YESSSssssssss.... and a minicore will help /force us to do that (imagine an hudson script blocked because of a nice popup)
So things like Object inform: aString would be something I'd rather see to disappear.
Yes Alexander, this is years that I want that. In fact we started pharo exactly for these kinds of reasons. Getting a clean and cool system. Any code going in that direction is welcome and will be warmly considered.
Or Class rename: aString, which kindly pops up a Dialog to inform the "user" when there are still references in Undeclared. I think that check should better move to the sending method in Browser renameClass, where chances are very high that a real user initiated the rename of a class and not some filein.
Alex
2010/10/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I think that we will have to reconsider a lot of the infrastructure decision and the hudson server will kick us
Stef
On Oct 12, 2010, at 10:45 PM, Alexander LazareviÄ wrote:
I was just looking at something similar. I guess for modal windows that are a kind of DialogWindow something like this should work
[UIManager default confirm: 'Got milk?'] on: ProvideAnswerNotification do: [:ex | ex resume: (ex messageText = 'Got milk?')]
But which modal windows do pop up in your scenario, that do not send a notification?
Regards, Alex
2010/10/12 Alexandre Bergel <alexandre@bergel.eu>:
Hi!
A modal window is pop up by one of my tests. Is there a way to capture this situation and simply remove the modal window? Apparently, no notification is raised...
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
There are also some basic things that would need some adjustment as I see it. I think core or basic classes and models shouldn't make any assumptions about the UI or even if there is an UI at all.
YESSSssssssss.... and a minicore will help /force us to do that  (imagine an hudson script blocked because of a nice popup)
Consider that this is not the UI framework that should decide to open a dialog or not. If somebody tells morphic to open a window it should open it otherwise you break all kinds of assumptions. If a user wants to support multiple UI frameworks (or the possibility to disable certain UI actions), then he needs to take appropriate action himself. OB for example uses notifications for all UI interactions that are captured either by a morphic handler (by default), a web handler (if you use the web interface), or by a test handler (that builds a fake UI that doesn't display anything but gives you a nice model to exercise the UI). Lukas -- Lukas Renggli www.lukas-renggli.ch
participants (2)
-
Lukas Renggli -
Stéphane Ducasse