Why not offer "not yet categorized" as the first option as a category to choose from?
Niko 2010/6/7 Gabriel Brunstein <[email protected]>: > maybe the right name would be something like "don´t categorize" ;) > > On Mon, Jun 7, 2010 at 11:54 AM, Niko Schwarz <[email protected]> > wrote: >> >> Right, only that I'm unhappy with the naming. I'd never have guessed >> that "cancel" does what I want. So far, I've always chosen a random >> junk category and fixed it up later. A button "Cancel" I'd expect to >> cancel the creation altogether. >> >> Niko >> >> 2010/6/7 Hernan Wilkinson <[email protected]>: >> > it is true, I almost all the time cancel that dialog to put the method >> > as >> > not yet categorized... but sometimes I select the category... I think >> > that >> > pressing ESC or cancel is not that bad in this case and I would keep >> > this >> > dialog. >> > >> > On Mon, Jun 7, 2010 at 5:45 AM, Niko Schwarz >> > <[email protected]> >> > wrote: >> >> >> >> I think the rationale must be: during TDD it's ok to ask the developer >> >> questions that he can answer right away. Thus, it's ok that the create >> >> button asks for the class: you know instantly what to answer. But >> >> asking for the method category is a major pain. I don't know about >> >> y'all, but I never quite know upfront how I'll structure my >> >> categories. That emerges much later in the process. >> >> >> >> In short: remove the asking for the method category. Just put it in >> >> 'not yet categorized', and have me figure it out later. >> >> >> >> Cheers, >> >> >> >> Niko >> >> >> >> 2010/6/2 Germán Leiva <[email protected]>: >> >> > I'm thinking out load here ... >> >> > In the debugger when a DNU is raised, for speeding up the programming >> >> > in >> >> > "TDD mode": >> >> > >> >> > The create button must add the method in the class of the receiver, >> >> > the >> >> > possibility to choose a superclass of the receiver must be optional >> >> > (I >> >> > don't >> >> > like the recurrent asking...) in other button for example or having >> >> > different shortcuts from the keyboard >> >> > If I send a message that I already know that will be a getter, some >> >> > option >> >> > like "Create getter" could automagically create the method and the >> >> > instance >> >> > variable. >> >> > When we a accept a method for the first time the pop-ups saying >> >> > "Unkown >> >> > selector please confirm, select or cancel" are really annoying and >> >> > decrease >> >> > coding speed >> >> > Same for the category pop-ups >> >> > In the creation of a new class through "define new class" it will be >> >> > helpful >> >> > to remember the last class category used >> >> > >> >> > Some ToDo list supported from the environment and some facility for >> >> > the >> >> > creation of test. >> >> > All of the above maybe just make sense in TDD mode or not =P >> >> > Cheers >> >> > 2010/6/2 Alexandre Bergel <[email protected]> >> >> >> >> >> >> The problems that I would like to see Pharo address are: >> >> >> - redundancies in unit tests >> >> >> - coverage of tests >> >> >> - classification of low and high levels of tests (implementation >> >> >> tests >> >> >> vs >> >> >> user stories) >> >> >> >> >> >> What are the tools to identify and solve this issues ? Research is >> >> >> needed >> >> >> :-) >> >> >> >> >> >> Alexandre >> >> >> >> >> >> >> >> >> >> >> >> On 2 Jun 2010, at 15:30, Stéphane Ducasse wrote: >> >> >> >> >> >> > Hi all >> >> >> > >> >> >> > Imagine that we would like to sell pharo (+ seaside) as THE agile >> >> >> > platform for doing TDD. >> >> >> > What would be the changes that we could do support it. >> >> >> > I know that hernan did a package for that but not I would like to >> >> >> > have a >> >> >> > new list of items >> >> >> > to support it. >> >> >> > >> >> >> > Stef >> >> >> > _______________________________________________ >> >> >> > Pharo-project mailing list >> >> >> > [email protected] >> >> >> > >> >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> Pharo-project mailing list >> >> >> [email protected] >> >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> > >> >> > >> >> > -- >> >> > Germán Leiva >> >> > [email protected] >> >> > >> >> > _______________________________________________ >> >> > Pharo-project mailing list >> >> > [email protected] >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> >> >> >> >> >> >> -- >> >> http://scg.unibe.ch/staff/Schwarz >> >> twitter.com/nes1983 >> >> Tel: +41 076 235 8683 >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> [email protected] >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [email protected] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
