Re: [Pharo-dev] [Ann] Calypso system browser

2017-01-09 Thread Bernhard Pieber
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 :
> 
> 
> 2017-01-09 13:02 GMT+01:00 Bernhard Pieber :
> 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?




Re: [Pharo-dev] [Ann] Calypso system browser

2017-01-09 Thread Denis Kudriashov
2017-01-09 13:02 GMT+01:00 Bernhard Pieber :

> 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?


Re: [Pharo-dev] [Ann] Calypso system browser

2017-01-09 Thread Denis Kudriashov
Hi Bernhard

2017-01-09 13:02 GMT+01:00 Bernhard Pieber :

> 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.


Re: [Pharo-dev] [Ann] Calypso system browser

2017-01-09 Thread Bernhard Pieber
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 :
> 
> 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: [Pharo-dev] [Ann] Calypso system browser

2017-01-04 Thread Denis Kudriashov
2017-01-04 8:32 GMT+01:00 Ben Coman :

> 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


Re: [Pharo-dev] [Ann] Calypso system browser

2017-01-03 Thread Ben Coman
On Tue, Jan 3, 2017 at 8:40 PM, Denis Kudriashov  wrote:
>
> 2016-12-31 16:57 GMT+01:00 Ben Coman :
>>
>> 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: [Pharo-dev] [Ann] Calypso system browser

2017-01-03 Thread Denis Kudriashov
2016-12-31 16:57 GMT+01:00 Ben Coman :

> 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


Re: [Pharo-dev] [Ann] Calypso system browser

2017-01-02 Thread Yuriy Tymchuk

> On 30 Dec 2016, at 19:18, Denis Kudriashov  wrote:
> 
> Hi Yuriy
> 
> 2016-12-30 8:29 GMT+01:00 Yuriy Tymchuk  >:
> 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. 
> 
I can help you with this :)

> 
> Anyway all these features require documentation from me on how extend things. 
> It is first in my todo.



Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-31 Thread Denis Kudriashov
2016-12-30 17:21 GMT+01:00 Dimitris Chloupis :

> 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?


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-31 Thread Denis Kudriashov
2016-12-31 16:57 GMT+01:00 Ben Coman :

> > 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?


I call this pane method groups view (because it shows method groups)


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-31 Thread Ben Coman
On Sat, Dec 31, 2016 at 6:55 AM, Denis Kudriashov  wrote:
>
> 2016-12-30 17:04 GMT+01:00 Ben Coman :
>>
>> > 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  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: [Pharo-dev] [Ann] Calypso system browser

2016-12-31 Thread Ben Coman
On Sat, Dec 31, 2016 at 6:05 AM, Denis Kudriashov  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



Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-30 Thread Denis Kudriashov
2016-12-30 17:04 GMT+01:00 Ben Coman :

> > 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  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
.
User will be able to mark method or class with set of tags. Each tag is
just symbol)


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-30 Thread Denis Kudriashov
> 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.


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-30 Thread Denis Kudriashov
Hi Yuriy

2016-12-30 8:29 GMT+01:00 Yuriy Tymchuk :

> 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.


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-30 Thread Ben Coman
On Thu, Dec 29, 2016 at 1:40 AM, Denis Kudriashov  wrote:
>
> 2016-12-28 18:12 GMT+01:00 Ben Coman :
>>
>> * 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  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



Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-29 Thread Yuriy Tymchuk
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  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



Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-29 Thread Stephane Ducasse
Mariano all RB and other will be present.

On Wed, Dec 28, 2016 at 1:55 PM, Mariano Martinez Peck <
marianop...@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 
> wrote:
>
>>
>> 2016-12-28 0:17 GMT+01:00 Cyril Ferlicot D. :
>>
>>>
>>> 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
>


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-28 Thread Denis Kudriashov
2016-12-28 18:12 GMT+01:00 Ben Coman :

>
> 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


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-28 Thread Denis Kudriashov
2016-12-28 18:12 GMT+01:00 Ben Coman :

> * 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.


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-28 Thread Ben Coman
On Wed, Dec 28, 2016 at 12:12 AM, Denis Kudriashov  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



Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-28 Thread Denis Kudriashov
2016-12-28 15:21 GMT+01:00 Tudor Girba :

> 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


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-28 Thread Tudor Girba
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  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."




Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-28 Thread Denis Kudriashov
2016-12-28 13:55 GMT+01:00 Mariano Martinez Peck :

> 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


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-28 Thread Denis Kudriashov
2016-12-28 13:55 GMT+01:00 Mariano Martinez Peck :

> 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
>


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-28 Thread Mariano Martinez Peck
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 
wrote:

>
> 2016-12-28 0:17 GMT+01:00 Cyril Ferlicot D. :
>
>>
>> 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


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-28 Thread Denis Kudriashov
2016-12-28 0:17 GMT+01:00 Cyril Ferlicot D. :

>
> 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)


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-27 Thread Cyril Ferlicot D.
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



signature.asc
Description: OpenPGP digital signature


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-27 Thread Denis Kudriashov
2016-12-27 23:11 GMT+01:00 Denis Kudriashov :

> 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 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


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-27 Thread stepharong
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

Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-27 Thread Denis Kudriashov
2016-12-27 22:01 GMT+01:00 Cyril Ferlicot D. :

> 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.


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-27 Thread stepharong

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/

Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-27 Thread Denis Kudriashov
2016-12-27 22:01 GMT+01:00 Cyril Ferlicot D. :

>
> 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 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 :).


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-27 Thread Cyril Ferlicot D.
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
> .
> 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



signature.asc
Description: OpenPGP digital signature


Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-27 Thread Sven Van Caekenberghe
Yes, very cool, great work!

> On 27 Dec 2016, at 19:06, p...@highoctane.be wrote:
> 
> Ah, this XMas present!
> 
> Thx Denis.
> 
> Phil
> 
> On Tue, Dec 27, 2016 at 5:12 PM, Denis Kudriashov  
> 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
> 




Re: [Pharo-dev] [Ann] Calypso system browser

2016-12-27 Thread p...@highoctane.be
Ah, this XMas present!

Thx Denis.

Phil

On Tue, Dec 27, 2016 at 5:12 PM, Denis Kudriashov 
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
>