[Ann] Calypso system browser
Locked
12
12
 
|
Wow, Denis, this is super cool! I really like that you have these “New method” tabs because I find it super confusing that you have to either select no methods or change the existing method to create a new one. I would be really happy on any feedback about the Renraku (critiques model) integration as I want to make it easily usably by any tool, and feedback from tool developers is very valuable. Cheers. Uko
|
|
|
In reply to this post by Denis Kudriashov
On Thu, Dec 29, 2016 at 1:40 AM, Denis Kudriashov <[hidden email]> wrote:
> > 2016-12-28 18:12 GMT+01:00 Ben Coman <[hidden email]>: >> >> * multiple code pane tabs - cool >> * multi-selection is cool (but I need to trial how it works out in >> practice) >> * automatic selection of items similar to last selection - I've been >> meaning to ask this for Nautilus for a while. >> * pinning modified pane code panes is a nice approach. It would be >> nice to pin any pane. >> * packages pane - it would be nice for the test-result-icon to appear >> on left like the other panes. The folder icon would seem reasonable >> place to substitute. >> >> Nice feature to show variables in the protocol pane and references in >> the method list pane. But it says "Class variables" while these are >> "Instance Variables" > > > Because Class variables are also accessible from instance side and you want > to see what methods are used it. > But I agree it should not be here by default. Actually it will be not here > if Object will not define any class variable. But Object has > DependantFields. Browser probably should ignore it. > Now structure of variables view is the same as when you click on Variables > button in Nautilus. > > 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. > >> >> The "inherited methods" tree-item might be better as a pull down menu >> at the bottom of the pane, level with "Filter..." since visually it is >> confusing seeming that protocols like "accessing" are a sub-item of >> "inherited methods". > > > But it is not expanded and indentation of both items are same. > Also you can select "inherited methods" as any other group I didn't notice that. Fair enough. > and see all inherited methods together without using visibility checkbox. okay. I can see how that works. But I can't work out the display logic. Selecting... Collections-Streams > ReadWriteStream > inherited methods asBinaryOrTextStream(PositionableStream) is shown normal asZLibReadStream(PositionableStream) is shown grey Can you explain? cheers -ben |
|
On a clean pharo 6 image file (alpha+vmLatest) Calypso installs fine but on my own built image it seems to conflict with Pillar triggering a syntax error
 |
Re: [Ann] Calypso system browser
|
|
In reply to this post by Uko2
Hi Yuriy 2016-12-30 8:29 GMT+01:00 Yuriy Tymchuk <[hidden email]>:
To support Nautilus style (footer pane) we first need to decide who is responsible for it. Because In Calypso there are two ways how to achieve it: it could be part of method/class editor tool or it could be global browser footer pane independent from tabs. So it needs some analysis. For example first way will hide critiques when user switch to comment tab or other tab which is not method/class editor. Is it desired or not? And what is desired? Another thing from you which I want support is matcher/rewriter tool. I opened issue for this https://github.com/dionisiydk/Calypso/issues/10. Anyway all these features require documentation from me on how extend things. It is first in my todo. |
Re: [Ann] Calypso system browser
|
|
In reply to this post by Ben Coman
okay. I can see how that works. But I can't work out the display logic. It's easy. Class extension is shown with grey and #asZLibReadStream is from Compression package. Actually this logic is a bit different. If method not belongs to selected package (from package view) then it will be shown with grey. It is current logic of Nautilus. |
Re: [Ann] Calypso system browser
|
|
In reply to this post by Ben Coman
2016-12-30 17:04 GMT+01:00 Ben Coman <[hidden email]>: > So you think existence of "Class variables" is also confusing because it I not understand why "accessing" under "inherited methods" is looks like child inside parent but "instance methods" under it will not confuse you too. Also in Calypso protocol is not exists anymore. 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) |
|
|
In reply to this post by Denis Kudriashov
On Sat, Dec 31, 2016 at 6:05 AM, Denis Kudriashov <[hidden email]> wrote:
> >> okay. I can see how that works. But I can't work out the display logic. >> Selecting... Collections-Streams > ReadWriteStream > inherited methods >> asBinaryOrTextStream(PositionableStream) is shown normal >> asZLibReadStream(PositionableStream) is shown grey >> Can you explain? > > > It's easy. Class extension is shown with grey and #asZLibReadStream is from > Compression package. > Actually this logic is a bit different. If method not belongs to selected > package (from package view) then it will be shown with grey. > It is current logic of Nautilus. Okay. That should have been obvious. So in trying to work out why my mind faltered, I think it may be because Nautlius provides visual feedback by light-highlighting the extension package (i.e. Compression) where Calypso does not - it only highlights real protocols. https://github.com/dionisiydk/Calypso/issues/38 cheers -ben |
|
|
In reply to this post by Denis Kudriashov
On Sat, Dec 31, 2016 at 6:55 AM, Denis Kudriashov <[hidden email]> wrote:
> > 2016-12-30 17:04 GMT+01:00 Ben Coman <[hidden email]>: >> >> > 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) > |
Re: [Ann] Calypso system browser
|
|
2016-12-31 16:57 GMT+01:00 Ben Coman <[hidden email]>: > Also in Calypso protocol is not exists anymore. I call this pane method groups view (because it shows method groups) |
Re: [Ann] Calypso system browser
|
|
In reply to this post by kilon.alios
2016-12-30 17:21 GMT+01:00 Dimitris Chloupis <[hidden email]>: On a clean pharo 6 image file (alpha+vmLatest) Calypso installs fine but on my own built image it seems to conflict with Pillar triggering a syntax error Does it mean that you first load Calypso then open it first time and then load some your package? |
|
|
In reply to this post by Denis Kudriashov
By the way, for classes it works in the same way. In fact the method the annotates a text model is defined in object, so theoretically every object that can produce critiques (renraku properties in general) can add then to a text area.
I don’t think that we have to have a list at the bottom, but what we can do is to make some plugins that will show all the critiques for a class or package, etc…
I can help you with this :)
|
Re: [Ann] Calypso system browser
|
|
In reply to this post by Ben Coman
2016-12-31 16:57 GMT+01:00 Ben Coman <[hidden email]>:
In last version (dev) I push it to the right. Also I moved extensions group to the top at second place. And all groups now support highlighting as owner of selected methods |
|
|
On Tue, Jan 3, 2017 at 8:40 PM, Denis Kudriashov <[hidden email]> wrote:
> > 2016-12-31 16:57 GMT+01:00 Ben Coman <[hidden email]>: >> >> 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. > > > In last version (dev) I push it to the right. That for giving this a go. It looks good when "inherited methods" is unexpanded. When expanded, at first I wasn't sure about the other checkboxes remaining left-aligned, but I think its fine and actually an advantage since "inherited methods" checkbox is a slightly different function to the per-superclass checkbox. btw I think pushing the per-superclass checkbox to the right wouldn't work. > Also I moved extensions group to the top at second place. I think this works well. > And all groups now support highlighting as owner of selected methods Cool. I tried this... 1. Select AST-Core > ASTCache 2. Tick "inherited methods" then expand it and "extensions" 3. Select #addIfNotPresent:ifPresentDo: ==> highlights "inherited methods", "Collection", "extensions" and "Fuel" Not sure if all four should be highlighted but its okay. and something tricky... 4. Select Fuel 5. Select #fuelAccept: 6. Click Fuel to unselect it ==> Fuel keeps a highlight, which is very nice. however... 7. Select Fuel again and unclick it ==> Fuel has lost its highlight. Also... 8. Select ASTCacheReset 9. Tick "inherited methods" 10. Select #addIfNotPresent:ifPresentDo: without expanding any method groups ==> "inherited methods" and "extensions" are highlighted, which is okay but now... 11. Expanding "extensions" ==> Collections not highlighted, and extensions lost it highlight 12. Expanding "inherited methods" ==> WeakIdentityKeyDictionary highlighted rather than expected Collection highlight "inherited methods" remains highlighted, which is different behaviour to "extensions" at step 11. cheers -ben |
Re: [Ann] Calypso system browser
|
|
2017-01-04 8:32 GMT+01:00 Ben Coman <[hidden email]>:
Yes, it is known issue which I think explain others from your feedback too. Problem that now highlighting is not restored as selection. For example if you select accessing group and then expand inherited methods (which is first) selection will stay correct although accessing is now shifted. I not put same logic for highlighting just to save time. It is feature kind of "nice to have" but not really critical IMO. So it is for future |
|
|
In reply to this post by Denis Kudriashov
Hi Denis,
I just played a bit with Calypso. I love the possibility to easily show the inherited methods. I would love to stay in a Calypso browser when I use Cmd-b to browse classes referenced in method source. Thanks for your contribution! Cheers, Bernhard > Am 27.12.2016 um 17:12 schrieb Denis Kudriashov <[hidden email]>: > > Hi > > I am glad announce first initial version of new system browser called Calypso. > It is implemented from scratch with idea to build model suitable for remote scenario. > But as result it leads to more important goal: provide clean implementation of browser which people could understand and evolve. > > Calypso supports most features from Nautilus but also miss many of them. And there are many not nicely looking parts of UI which require more work. > But in same time Calypso provides many new cool features with clean implementation underhood. I put many things from other smalltalks and old browsers which I always miss. > > I release Calypso in the state where I finish most design decisions which I think important for project evolution. > Of course there are a lot of things to do and improve. But browser is fully working. And now it is important to community to participate in project and make browser great again :). We need escape from Nautilus pasta world. > Please report any ideas/bugs on github page https://github.com/dionisiydk/Calypso/issues. I already fill it with my wishes. > > Next step I will work on documentation/class comments and I will publish couple of posts about Calypso internals. > > Read more details on my blog. It includes pictures, videos and loading script. > > Best regards, > Denis |
Re: [Ann] Calypso system browser
|
|
Hi Bernhard 2017-01-09 13:02 GMT+01:00 Bernhard Pieber <[hidden email]>:
I not hook yet into text editor commands. So they are global ones. And now only way to achieve what you want is to make Calypso default browser.
But I guess it is too early to make it default for general usage. Anyway I will reimplement text editor commands in Calypso way. So it will be possible to open Calypso and stay inside it without global tool replacement. |
Re: [Ann] Calypso system browser
|
|
In reply to this post by bpi
2017-01-09 13:02 GMT+01:00 Bernhard Pieber <[hidden email]>: I just played a bit with Calypso. I love the possibility to easily show the inherited methods. I would love to stay in a Calypso browser when I use Cmd-b to browse classes referenced in method source. Maybe I misunderstood you. Do you want cmd-b open selected class in same browser window? |
|
|
No, this is not what I meant. Although it might be a useful variant once there is go back and go forward like in web browsers.
For now ClySystemBrowser beDefaultBrowser does what I want. Thanks! Cheers, Bernhard > Am 09.01.2017 um 15:10 schrieb Denis Kudriashov <[hidden email]>: > > > 2017-01-09 13:02 GMT+01:00 Bernhard Pieber <[hidden email]>: > I just played a bit with Calypso. I love the possibility to easily show the inherited methods. I would love to stay in a Calypso browser when I use Cmd-b to browse classes referenced in method source. > > Maybe I misunderstood you. Do you want cmd-b open selected class in same browser window? |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |