2011/8/9 Stéphane Ducasse <[email protected]>: > > On Aug 9, 2011, at 6:29 PM, Nicolas Cellier wrote: > >> 2011/8/9 Stéphane Ducasse <[email protected]>: >>> Hi >>> >>> I would like that we do an analysis of what should stay in implementors >>> >>> Here are the menus in 1.2 and 1.4 >>> >> >> Note that the menu titles are misleading. >> In previous implementation, 'Implementors of...(m)' did mean >> implementor of this message or any message called by this method. > > I did not pay attention to that because I always type the code but I see now. > >> In current implementation, 'Implementors of...(m)' does mean >> implementor of this message and only this message. >> Same for 'senders of ...(n)'. >> >> That's the main grief I got because this break the browsing chain. >> If I want to see implementors/senders of a sub message, then I have to: >> - select the message in text field, then click cmd+m or cmd+n > > this is what I do :) >
Then also remove implementors/senders from the method list menu... >> - if the message is multiple keyword, then this won't work... > > We should fix that for any place in the system foo: #yyy to: does not find > foo:to: :( > This requires a minimal parsing of surrounding text, maybe shout like style is enough. >> I have to open a finder, copy some text, paste in the finder then >> click one of the matching methods... >> That's many more clicks than previous implementation. > > Ok we will fix that. > > >> >> To define a "good" UI you must not only think in term of available >> feature, other views matter: >> - homogeneity of presentation / action >> - number of clicks for accessing a feature >> - auto-discovery of features rather than implicit knowledge > > Yes. > >>> Please comment so that we can add what is really used. >>> As a general comment I would avoid to do everything with a single tool. >>> >> >> Err. I think the contrary. >> Every such view is a browser with a specific filter on displayed code. >> The first function of a browser is browsing. >> Removing browsing capabilities from these views make em become dead >> ends (look and close). >> To restore the navigation chain, user must pass thru textual copy/paste. >> Ubiquitous browsing is a strength of Smalltalk IDE, no? > > Yes but do we need spawn subprotocol? and friends. All instances... > So let us focus on the most 40% most important features and add them to the > browsers. > So there should be a reasonable amount of used functionality. > > So let us know what you use most of the time or less and this will be good. > > Stef > This reflects my very personnal use for the browsing category : 5) vital alt+b / alt+N (otherwise I have to type self/print it/select it/alt+b in Text) 4) often used: alt+m alt+n (including sub messages) alt+v (my own right to make mistake) inst var refs/defs (though I also browse it from text with alt+shift+n for refs) 3) casually used: alt+h - local implementors/senders - alt+i inheritance - class var ref/defs 2) rarely used; none 1) never used: all the rest For actions: 4) remove method (x) 3) toggle break on entry (it's not recommended for some kernel UI messages) 2) fileOut (but in some rare cases this is valuable, it must be able to filOut the whole list if there is no selection) - change category 1) all the rest But there is a bias, everything accessible thru more... will be less often used by construction. Of course, my flow is a bit different when using OB/RB. I'm not biggest OB fan, but I wonder like Marcus if maintaining two browsers is sustainable. 1) You have complaints from Lukas because of OB regressions at each upgrade 2) You get complaints for removed features from end users. A recipe for maximizing the complaints ;) While you could integrate OB in dev, core developers would fix OB on the fly and commit to local Pharo/PharoInbox. Then Lukas would select/correct/merge available fixes and officialize them on a new ConfigurationOfOB. Nicolas
