[Ann] Calypso system browser
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 <http://dionisiydk.blogspot.fr/2016/12/calypso-new-system-browser-for-pharo.h...>. It includes pictures, videos and loading script. Best regards, Denis
Ah, this XMas present! Thx Denis. Phil On Tue, Dec 27, 2016 at 5:12 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
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 <http://dionisiydk.blogspot.fr/2016/12/calypso-new-system-browser-for-pharo.h...>. It includes pictures, videos and loading script.
Best regards, Denis
Yes, very cool, great work!
On 27 Dec 2016, at 19:06, phil@highoctane.be wrote:
Ah, this XMas present!
Thx Denis.
Phil
On Tue, Dec 27, 2016 at 5:12 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote: 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
Le 27/12/2016 à 17:12, Denis Kudriashov a écrit :
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 <http://dionisiydk.blogspot.fr/2016/12/calypso-new-system-browser-for-pharo.h...>. It includes pictures, videos and loading script.
Best regards, Denis
This is really cool :) On the pure design side, two things that hits my eyes are the toggle buttons and the test icon on the package list. The toggle buttons looks really⦠"Old". The tests icons should be align on the right of the list I think. But this should be improve directly on the widget. Right icons aligned and if the text is too long, cut it, add 'â¦' and show it on the hoover. Or if you don't want to cut the text and add a scrollbar, the icons should be align to the left. I did not had the time to try it now but I look forward to it :) Thanks Denis! -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
2016-12-27 22:01 GMT+01:00 Cyril Ferlicot D. <cyril.ferlicot@gmail.com>:
This is really cool :)
On the pure design side, two things that hits my eyes are the toggle buttons and the test icon on the package list.
The toggle buttons looks really⦠"Old".
I agree Cyril. Thank's for feedback. Definitely current UI design is not the end. It is just the start, the simple way how to arrange current browser features. Now toolbar looks bad but it provides desired features which allow to be more effective than with Nautilus. That's idea: implement functions and then start to think about design. But not alone. I am not good in design and I hope together we could provide good look&feel for desired features. Now what you see in Calypso is my wishes which I want to be covered by design. So as I said: let's make browser great again :).
2016-12-27 23:11 GMT+01:00 Denis Kudriashov <dionisiydk@gmail.com>:
On the pure design side, two things that hits my eyes are the toggle
buttons and the test icon on the package list.
The toggle buttons looks really⦠"Old".
I agree Cyril. Thank's for feedback.
Definitely current UI design is not the end. It is just the start, the simple way how to arrange current browser features.
Now toolbar looks bad but it provides desired features which allow to be more effective than with Nautilus. That's idea: implement functions and then start to think about design. But not alone. I am not good in design and I hope together we could provide good look&feel for desired features. Now what you see in Calypso is my wishes which I want to be covered by design.
So as I said: let's make browser great again :).
It would be super cool if some of clever guys could just design look of browser in pictures. And the rest will be just technical job
Le 27/12/2016 à 23:45, Denis Kudriashov a écrit :
It would be super cool if some of clever guys could just design look of browser in pictures. And the rest will be just technical job
I'm not a "pro" of ux but at Synectique I make the css of our web tools. So I can try to make some mockup of widgets when I will have some time but I will not have the time to implements them in Pharo/Morph. Tomorrow I will send a screen of the nested list we made at Synectique. It's a responsive tree with icons at the right and/or left. And also I know the priority is the features. I just make some notes of the main UI problems because it's something that should not be forgotten after the features implementation :) And I am well aware that it's hard to find time to fix design. (Tests, doc, design, promo, bug correction, speed up⦠Too much things to do after making a feature :D) -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France
2016-12-28 0:17 GMT+01:00 Cyril Ferlicot D. <cyril.ferlicot@gmail.com>:
I'm not a "pro" of ux but at Synectique I make the css of our web tools. So I can try to make some mockup of widgets when I will have some time
It will be really really nice.
but I will not have the time to implements them in Pharo/Morph.
No problem here. I think implementing all "candies" is task for many people.
Tomorrow I will send a screen of the nested list we made at Synectique. It's a responsive tree with icons at the right and/or left.
And also I know the priority is the features. I just make some notes of the main UI problems because it's something that should not be forgotten after the features implementation :) And I am well aware that it's hard to find time to fix design. (Tests, doc, design, promo, bug correction, speed up⦠Too much things to do after making a feature :D)
Wow, it already have features I have wished since long time (like the view or inherited / filtered methods and multi selection everywhere). About RB, how much do you plan to integrate? From the screenshots I can see only a few basic ones. Is the idea to have at least the ones of Nautilus? Can we add a feature to compare /diff to random methods? Right now nautilus allows you that but it must be from the same class.... Thanks and congratulations! I am eager to test it out. On Wed, Dec 28, 2016 at 7:03 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-12-28 0:17 GMT+01:00 Cyril Ferlicot D. <cyril.ferlicot@gmail.com>:
I'm not a "pro" of ux but at Synectique I make the css of our web tools. So I can try to make some mockup of widgets when I will have some time
It will be really really nice.
but I will not have the time to implements them in Pharo/Morph.
No problem here. I think implementing all "candies" is task for many people.
Tomorrow I will send a screen of the nested list we made at Synectique. It's a responsive tree with icons at the right and/or left.
And also I know the priority is the features. I just make some notes of the main UI problems because it's something that should not be forgotten after the features implementation :) And I am well aware that it's hard to find time to fix design. (Tests, doc, design, promo, bug correction, speed up⦠Too much things to do after making a feature :D)
-- Mariano http://marianopeck.wordpress.com
2016-12-28 13:55 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:
Wow, it already have features I have wished since long time (like the view or inherited / filtered methods and multi selection everywhere).
About RB, how much do you plan to integrate? From the screenshots I can see only a few basic ones. Is the idea to have at least the ones of Nautilus?
Yes of course. Now I added what I personally used often. I will document how extend Calypso in many aspects. So others could participate easily. Now just report what you really miss on github. And of course you could just discover code and add missing refactorings in same way as existing
Can we add a feature to compare /diff to random methods? Right now nautilus allows you that but it must be from the same class....
2016-12-28 13:55 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:
Can we add a feature to compare /diff to random methods? Right now nautilus allows you that but it must be from the same class....
Yes. There is already issue for this: https://github.com/dionisiydk/Calypso/issues/11. My idea to open diff tool in tab instead of method editor. And to compare multiple methods you will need to select multiple packages/classes first and then choose methods from single list to compare
Mariano all RB and other will be present. On Wed, Dec 28, 2016 at 1:55 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Wow, it already have features I have wished since long time (like the view or inherited / filtered methods and multi selection everywhere).
About RB, how much do you plan to integrate? From the screenshots I can see only a few basic ones. Is the idea to have at least the ones of Nautilus?
Can we add a feature to compare /diff to random methods? Right now nautilus allows you that but it must be from the same class....
Thanks and congratulations! I am eager to test it out.
On Wed, Dec 28, 2016 at 7:03 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-12-28 0:17 GMT+01:00 Cyril Ferlicot D. <cyril.ferlicot@gmail.com>:
I'm not a "pro" of ux but at Synectique I make the css of our web tools. So I can try to make some mockup of widgets when I will have some time
It will be really really nice.
but I will not have the time to implements them in Pharo/Morph.
No problem here. I think implementing all "candies" is task for many people.
Tomorrow I will send a screen of the nested list we made at Synectique. It's a responsive tree with icons at the right and/or left.
And also I know the priority is the features. I just make some notes of the main UI problems because it's something that should not be forgotten after the features implementation :) And I am well aware that it's hard to find time to fix design. (Tests, doc, design, promo, bug correction, speed up⦠Too much things to do after making a feature :D)
-- Mariano http://marianopeck.wordpress.com
2016-12-27 22:01 GMT+01:00 Cyril Ferlicot D. <cyril.ferlicot@gmail.com>:
The tests icons should be align on the right of the list I think. But this should be improve directly on the widget. Right icons aligned and if the text is too long, cut it, add 'â¦' and show it on the hoover. Or if you don't want to cut the text and add a scrollbar, the icons should be align to the left.
Nice idea. Now every cell in table has definitionMorph before name and extra morphs after it. Plugins decide how to fill and decorate them. And currently table is single column. I think it would be nice to put all this morphs in separate columns which will provide good alignment.
Thanks denis. :) Now let us make sure that we can deprecated our old friend nautilus :) Stef
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
-- Using Opera's mail client: http://www.opera.com/mail/
I love the name. :) and I want to thank Alain for not complaining that we stole the name of one of his projects :) It deserves a little explanation..... Nautilus was a submarine of Jules Verne. Calypso is the boat of commandant Cousteau. Now calypso is more than a browser: it is a model and really nice because without case and tests everywhere. Stef
Hi Denix, Nice work! I particularly like the focus on low traffic between the model and the UI. I think there is a good deal of things to learn from the experience of building remote tools. Cheers, Doru
On Dec 27, 2016, at 5:12 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
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
-- www.tudorgirba.com www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened."
2016-12-28 15:21 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Nice work!
I particularly like the focus on low traffic between the model and the UI. I think there is a good deal of things to learn from the experience of building remote tools.
Calypso supposed to work good in remote scenario. It was always main design goal. So soon we will have remote browser based on Calypso
On Wed, Dec 28, 2016 at 12:12 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
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.
I like this initiative, especially for the local browser and the remote browser using the same code base. * overall minimizing code * using/testing the same mechanisms * facilitate seamless experience between local and remote usage
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.
* 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" 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 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". cheers -ben
2016-12-28 18:12 GMT+01:00 Ben Coman <btc@openinworld.com>:
* 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?
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.
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 and see all inherited methods together without using visibility checkbox.
On Thu, Dec 29, 2016 at 1:40 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-12-28 18:12 GMT+01:00 Ben Coman <btc@openinworld.com>:
* 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 [image: Screenshot 2016-12-30 18.08.38.png]
2016-12-30 17:21 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:
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?
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.
On Sat, Dec 31, 2016 at 6:05 AM, Denis Kudriashov <dionisiydk@gmail.com> 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
2016-12-30 17:04 GMT+01:00 Ben Coman <btc@openinworld.com>:
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 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 <https://pharo.fogbugz.com/f/cases/19341/New-class-and-method-tags-API>. User will be able to mark method or class with set of tags. Each tag is just symbol)
On Sat, Dec 31, 2016 at 6:55 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2016-12-30 17:04 GMT+01:00 Ben Coman <btc@openinworld.com>:
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)
2016-12-31 16:57 GMT+01:00 Ben Coman <btc@openinworld.com>:
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. 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 <dionisiydk@gmail.com> wrote:
2016-12-31 16:57 GMT+01:00 Ben Coman <btc@openinworld.com>:
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
2017-01-04 8:32 GMT+01:00 Ben Coman <btc@openinworld.com>:
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
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
2016-12-28 18:12 GMT+01:00 Ben Coman <btc@openinworld.com>:
I like this initiative, especially for the local browser and the remote browser using the same code base. * overall minimizing code * using/testing the same mechanisms * facilitate seamless experience between local and remote usage
And thank's for feedback. I saw you created issues. It is good
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
On 27 Dec 2016, at 17:12, Denis Kudriashov <dionisiydk@gmail.com> wrote:
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 <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 <http://dionisiydk.blogspot.fr/2016/12/calypso-new-system-browser-for-pharo.h...>. It includes pictures, videos and loading script.
Best regards, Denis
Hi Yuriy 2016-12-30 8:29 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:
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.
Now critiques are only supported as in MessageBrowser because it was just one line of code. 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.
On 30 Dec 2016, at 19:18, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi Yuriy
2016-12-30 8:29 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>>: 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.
Now critiques are only supported as in MessageBrowser because it was just one line of code.
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.
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?
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â¦
Another thing from you which I want support is matcher/rewriter tool. I opened issue for this https://github.com/dionisiydk/Calypso/issues/10. <https://github.com/dionisiydk/Calypso/issues/10.>
I can help you with this :)
Anyway all these features require documentation from me on how extend things. It is first in my todo.
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 <dionisiydk@gmail.com>:
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
Hi Bernhard 2017-01-09 13:02 GMT+01:00 Bernhard Pieber <bernhard@pieber.com>:
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.
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. ClySystemBrowser beDefaultBrowser. 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.
2017-01-09 13:02 GMT+01:00 Bernhard Pieber <bernhard@pieber.com>:
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 <dionisiydk@gmail.com>:
2017-01-09 13:02 GMT+01:00 Bernhard Pieber <bernhard@pieber.com>: 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?
participants (12)
-
Ben Coman -
Bernhard Pieber -
Cyril Ferlicot D. -
Denis Kudriashov -
Dimitris Chloupis -
Mariano Martinez Peck -
phil＠highoctane.be -
Stephane Ducasse -
stepharong -
Sven Van Caekenberghe -
Tudor Girba -
Yuriy Tymchuk