Hi Lukas, I will need to present this information to a company. I'm OK with using short words but instvar isn't a word as defined in the dictionary. Also, it's not clear as to the intentions to someone that hasn't experienced a Smalltalk environment. These are the people that I will need to explain why things are the way they are and the information that you have provided willl allow me to navigate through my presentation a little easier. Furthermore, I like the idea of having to have refactorings grouped into sub-menus. In short, I'm trying to present this information to peoples that are stuck in the stone age.
<div><br class="webkit-block-placeholder"></div><div>-Conrad<br><br><div><span class="gmail_quote">On 8/12/07, <b class="gmail_sendername">Lukas Renggli</b> <<a href="mailto:renggli@gmail.com">renggli@gmail.com</a>> wrote:
</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">> It appears to faster than the OmniBrowser. I see a noticeable lag from<br>> initiating an action to seeing the results of that action. Next, it has
<br>> better clarity in regards to the menu selections. For example,<br>><br>> RB: "Create accessors for instance varibales"<br>><br>> OB: "accessors for instvar"<br>><br>> The RB provides an easier to understand menu in this regard. On the other
<br>> hand, it's not clear what it does until you play with it. For example, when<br>> I see "accessors for instvar", I'm thinking that it would simply return a<br>> list of the accessors for the selected instance variable. Should creating
<br>> and accessing mean the same thing in this context? In short, please spell<br>> out the menu item entries instead of using these abbreviations and be clear<br>> as to what it does with its name.<br><br>This is me that created this package. I like to have the menus as
<br>short as possible, preferably just one word. And since listing the<br>accessors for a selected instance variable is no refactoring, I argue<br>that it is quite clear what it is supposed to do.<br><br>Now what I agree is that this huge flat list of menu items in OB is
<br>not really user-friendly. It would be better to have refactorings<br>grouped into sub-menus so that it becomes more clear what they do. For<br>example:<br><br> instance variable refactorings -> create accessors
<br><br>Unfortunately OB doen't support sub-menus without hacks yet.<br><br>> > > Why are they're so many browsers? It<br>> ><br>> ><br>> > This is because the base image already includes different browsers.
<br><br>No, this is because everybody prefers a different browser. I think OB<br>would be the best match for everybody (and to go into the base-image),<br>because it can be easily tweaked to your exact needs. Except for the
<br>StarBrowser, I don't know of any other browsers that is that adaptive.<br><br>> Damien, I'll work with the OB but I'll be refactoring the names of the menu<br>> items especially the one:<br>><br>> "undo a
<br>> CreateAccessorsForVariableRefacoring"<br><br>That's the refactoring engine, that does not provide a label for menu<br>items. The old RB browser does not even provide the possibility to<br>undo/redo a refactoring, something I consider to be very important.
<br><br>Lukas<br><br>--<br>Lukas Renggli<br><a href="http://www.lukas-renggli.ch">http://www.lukas-renggli.ch</a><br>_______________________________________________<br>Seaside mailing list<br><a href="mailto:Seaside@lists.squeakfoundation">
Seaside@lists.squeakfoundation</a>.org<br><a href="http://lists.squeakfoundation">http://lists.squeakfoundation</a>.org/cgi-bin/mailman/listinfo/seaside<br></blockquote></div><br></div>