I will wait a bit more and collect a list of essential action to the bug entry I created.
Stef On Aug 9, 2011, at 7:28 PM, Nicolas Cellier wrote: > 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 >
