On Sat, Dec 31, 2016 at 6:55 AM, Denis Kudriashov <[email protected]> wrote: > > 2016-12-30 17:04 GMT+01:00 Ben Coman <[email protected]>: >> >> > So you think existence of "Class variables" is also confusing because it >> > looks like parent group for instance variables? >> >> Yes its confusing. I didn't even notice that "Class variables" could >> be expanded to show >> DependentsFields. I just assumed "Class variables" was the expanded >> parent of >> MultiByteBinaryOrTextStream, isBinary, converter. Hence my comment >> that "class variables" item should be renamed "instance variables". >> Now I see my comment was off target. I think the best fix is to have >> a parent "instance variables" as well as "class variables", and on the >> class side the parent should be "class instance variables." Such >> labels educate newbies. >> >> > >> >> >> >> >> >> Now I wonder if we can do without the Methods/Vars buttons by having >> >> the following top level tree items. Also as a newbie before developing >> >> the instinct to *know* which instance/class-side I was on, I got burnt >> >> a few times following tutorials accidentally putting methods on the >> >> wrong side. It would be interesting to try deprecating the >> >> Inst-Side/Class-Side buttons, and have something like the following >> >> items... >> >> + instance-side methods >> >> - accessing >> >> - initialization >> >> - extensions >> >> - GT-InspectorExtensions >> >> + class-side methods >> >> - instance creation >> >> - extensions >> >> + variables >> >> - instance variables >> >> - class variables >> >> - class instance variables >> >> >> > >> > It could be good or not. >> > Problem with this approach is same as why we use 4-column panes instead >> > of >> > single tree menu for everything like other IDE does. >> > We don't want to scroll to achieve some group element. >> > Imaging that you browse some morph subclass which have a lot of >> > protocols. >> > You are in some middle protocol and not see parent expanded group in >> > list. >> > And now you want to look at class side or variables. Tree view will >> > force >> > you to scroll instead of simple press on switch button like it is now. >> >> okay. It would still be useful to at least have "Instance methods" parent >> at the same level as "inherited methods" and "extensions" >> * its disconcerting to have the protocols floating without a parent >> * currently nowhere to select "All methods" - it seems you need to >> deselect to see all methods. So with >> * it could give another visual indication of which side you are on, by >> changing to "class methods" when the <Class side> button is pushed. > > > Personally I do not like it. > I not understand why "accessing" under "inherited methods" is looks like > child inside parent
If I look more closely I notice that "accessing" is not indented from "inherited methods", so you are right that I should not be considering "accessing" as a child of "inherited methods". But just this is my first impression. And the same glitch happened regarding my perception of "Class variables" item. I'm not clear on the cause. Perception is a strange thing highly influenced by what you already know. Like those magic eye stereographic images [1] that at first you can't see, but then after the image appears, its hard to *not* see it. [1] http://www.vision3d.com/sghidden/saturn.html Maybe it is the checkbox doubling the size of the whitespace (??) such that it would be better placed to the right (??), or maybe I just need to adapt. > but "instance methods" under it will not confuse you too. By having "instance methods" at the top level with "accessing" will be indented from it, I think it would be more obvious rather than cause additional confusion. An alternative might be putting "inherited methods" next to "extensions" beneath the standard protocols > > Also in Calypso protocol is not exists anymore. Okay. So btw will you have a new name for the third pane of the browser to use in discussions? cheers -ben. > There is just specific kind > of method group which shows methods marked with given tag. > Group "extensions" is another kind of method group which shows class > extensions. > In future we will have much more groups from old nice project "dynamic > protocols" (there are github issues for them). > > So in general my idea that tagged method groups is not something special > comparing to any other method groups. Not need for special parent for them. > > (In Pharo7 we will try to move to tags idea and remove protocols and > class/method categories. New API for tags is already in Pharo 6 19341. > User will be able to mark method or class with set of tags. Each tag is just > symbol) >
