June 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Roassal Camp Smalltalk

by stepharo

Alex what are your criteria for knowing if this is stable? Because Roassal 2 got completely different from roassal 1. So people used mondrian, then roassal (the changes was important and good there). then we got roassal 2 which did not follow the same API and worse is changing. So from a user perspective rewriting is boring. So how do you assess that doing x that way is better expressed? How can we help stabilizing the API? Do not get me wrong I really want Roassal getting massively successful but it will not without: - data importers - stable API - a slice of statistics Stef Le 16/6/15 23:53, Alexandre Bergel a Ã©crit : > Yes, but the problem is that stabilizing an API that does not work is not productive. > In any case, July will be decisive for Roassal as I intent to push the book. > > Alexandre > > >> On Jun 15, 2015, at 4:00 AM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi Peter >> >> Definitively. Having stable API is key for us and for everybody. >> For us (synectique), we stop to change versions around 6 months ago. >> This is sad that we have to shield us from Roassal but this is what we are doing. >> We cannot fight to get clients and change all the time our code. >> As you see, I'm the only one to say it because usman already reported this problem one year >> ago and we discussed with alex but we faced the same problem and now he stopped even to report >> problems. >> So we will rediscuss in july when alex is visiting us and else we will stay with an old version. >> The problem is that the community around roassal will not benefit from this but >> we cannot do much. >> >> Stef >> >>> Since I've already run into second thing in agile visualization book that is outdated (RTArrow, which was some time ago renamed to RTArrowedLine (https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… section 2.2) it made me wonder how many things like these are there (considering in neither case I was looking for errors). >>> >>> So, maybe this could be also addressed at the camp if there will be time? >>> >>> Writing is hard and reviewing own work is exercise in futility (I see things that I want to see, not what is there). Some of it (like the examples) could be even executed to verify their validity. >>> >>> And lastly what I saw in another thread (by stef) - graceful deprecation, and stabilization of API. >>> >>> Peter >>> >>> On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>>> On 08 Jun 2015, at 18:22, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>> >>>>> Well at least for me it is certainly not clear what release policy is Roassal following; i.e. if I see a minor version change what to expect, if any BC breaks were introduced, etc. Of course this is extra effort for the person doing it, so it should be taken with care. But there are certainly things to be discussed about this. >>>> Hi Peter, >>>> >>>> Indeed, we have not been good at producing a descent version numbering schema. >>>> My position was always this one: the last version should always fit your need. However, some product favored stability when Roassal is used in a commercial setting. >>>> We will be more careful when updating the configuration with a proper version number. >>> Versioning is in fact a complex thing. Thatâs why I suggest to have a brainstorming session during the camp. >>> >>> Uko >>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>>> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>>> Oh, then itâs my bad. Last time Iâve checked it seemed that it wasnât updated for a long time. Maybe I was wrong. >>>>> >>>>> Uko >>>>> >>>>> >>>>> >>>>>> On 05 Jun 2015, at 18:08, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>>>> >>>>>> There sure are, look at ConfigurationOfRoassal2>>version*: >>>>>> >>>>>> and in my baseline I have something like >>>>>> >>>>>> ~~~~~~~~~~~ >>>>>> spec >>>>>> project: 'Roassal2' with: [ >>>>>> spec >>>>>> className: #ConfigurationOfRoassal2; >>>>>> versionString: '1.52'; >>>>>> repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ]; >>>>>> ~~~~~~~~~~~ >>>>>> >>>>>> Peter >>>>>> >>>>>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>>>> But are there numbered version to refer to? >>>>>> >>>>>> Uko >>>>>> >>>>>>> On 05 Jun 2015, at 16:34, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>>>>>> Iâm interested in participating. Personally Iâd like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve somethingâ¦ >>>>>>> >>>>>>> Yes I am also interested in this, right now I am actually using quite old version (month+) because I didn't have time to keep up. :) (Arguably 90% of my problems were from infamous composite shapes. :)) >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> Uko >>>>>>> >>>>>>>> On 04 Jun 2015, at 19:55, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>>>>>>> >>>>>>>> Dear Colleagues and Friends, >>>>>>>> >>>>>>>> We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. >>>>>>>> >>>>>>>> As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: >>>>>>>> - Port of Roassal on VisualWorks >>>>>>>> - Using Roassal on Gemstone >>>>>>>> - HTML/JavaScript export >>>>>>>> - Improving Grapher, our charting library >>>>>>>> >>>>>>>> If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Alexandre >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>> >>>

June 17, 2015

Re: [Pharo-dev] We want to remove historyNavigation from Nautilus...

by stepharo

We can keep it if people really use it. I never use it and usually this is for one of two methods deep because after I do not find my babies. Do you use it to spot the method? How deep long are going? Stef Le 16/6/15 22:09, Nicolai Hess a Ã©crit : > > > 2015-06-16 18:00 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi guys > > we really need to cleanup nautilus and we are thinking to remove > the history navigation. > So we hope that not that many people will cry but we should move on. > > > I use it often and I find it helpful. Will it be replaced with another > history navigation? > > We are also cleaning the group management. > > Stef > >

June 17, 2015

Re: [Pharo-dev] We want to remove historyNavigation from Nautilus...

by Franck Warlouzet

> From: damien.cassou(a)inria.fr > To: pharo-dev(a)lists.pharo.org > Date: Wed, 17 Jun 2015 06:27:56 +0200 > Subject: Re: [Pharo-dev] We want to remove historyNavigation from Nautilus... > > > stepharo <stepharo(a)free.fr> writes: > > > we really need to cleanup nautilus and we are thinking to remove the > > history navigation. > > So we hope that not that many people will cry but we should move on. > > We are also cleaning the group management. > > what about removing the Nautilus history UI (drop-down list) but let > Nautilus continue saving the information somewhere? That way, Spotter > can find it. If you want to keep the classes you watched in a kind of history, you can also use the group Most Viewed Classes. Franck > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill >

June 17, 2015

Re: [Pharo-dev] Who changed the meaning of command-click on class names ?

by stepharo

Le 16/6/15 12:43, Torsten Bergmann a Ã©crit : > Not unimportant side note: > > >From what I see from Nicolai's high activity in bug tracker and here on the list > he is someone who closely watches the included changes and fixes/reviews issues. > This quickly helps making progress. > > @Nicolai: big thanks from my side! Big thanks from my side too!!!! Really cool to have somebody watching at your errors. Because we are in the junggle with Nautilus and related in this moment... so we are cutting the firt path and it has some raw edges. stef > > Bye > T. > > Gesendet: Dienstag, 16. Juni 2015 um 10:44 Uhr > Von: "Nicolai Hess" <nicolaihess(a)web.de> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Who changed the meaning of command-click on class names ? > > > > 2015-06-16 10:15 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>:Hi, > > In Pharo 5, the meaning of command-click (apple-click) on class names changed from 'Browse class' to 'References to class'. On selectors it still is 'Implementors'. > > Why was this done ? Was this done intentionally or by accident, as a side effect of some other change ? > > By accident, please open an issue. (caused by 15575 AST syntax highlight: clean up variable resolving a bit ) > > I rely on it a lot and I think the old behaviour should be restored. > > Sven > > > >

June 17, 2015

Re: [Pharo-dev] We want to remove historyNavigation from Nautilus...

by Damien Cassou

stepharo <stepharo(a)free.fr> writes: > we really need to cleanup nautilus and we are thinking to remove the > history navigation. > So we hope that not that many people will cry but we should move on. > We are also cleaning the group management. what about removing the Nautilus history UI (drop-down list) but let Nautilus continue saving the information somewhere? That way, Spotter can find it. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

June 17, 2015

Re: [Pharo-dev] Roassal Camp Smalltalk

by Alexandre Bergel

Yes, but the problem is that stabilizing an API that does not work is not productive. In any case, July will be decisive for Roassal as I intent to push the book. Alexandre > On Jun 15, 2015, at 4:00 AM, stepharo <stepharo(a)free.fr> wrote: > > Hi Peter > > Definitively. Having stable API is key for us and for everybody. > For us (synectique), we stop to change versions around 6 months ago. > This is sad that we have to shield us from Roassal but this is what we are doing. > We cannot fight to get clients and change all the time our code. > As you see, I'm the only one to say it because usman already reported this problem one year > ago and we discussed with alex but we faced the same problem and now he stopped even to report > problems. > So we will rediscuss in july when alex is visiting us and else we will stay with an old version. > The problem is that the community around roassal will not benefit from this but > we cannot do much. > > Stef > >> Since I've already run into second thing in agile visualization book that is outdated (RTArrow, which was some time ago renamed to RTArrowedLine (https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… section 2.2) it made me wonder how many things like these are there (considering in neither case I was looking for errors). >> >> So, maybe this could be also addressed at the camp if there will be time? >> >> Writing is hard and reviewing own work is exercise in futility (I see things that I want to see, not what is there). Some of it (like the examples) could be even executed to verify their validity. >> >> And lastly what I saw in another thread (by stef) - graceful deprecation, and stabilization of API. >> >> Peter >> >> On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> > On 08 Jun 2015, at 18:22, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> > >> >> Well at least for me it is certainly not clear what release policy is Roassal following; i.e. if I see a minor version change what to expect, if any BC breaks were introduced, etc. Of course this is extra effort for the person doing it, so it should be taken with care. But there are certainly things to be discussed about this. >> > >> > Hi Peter, >> > >> > Indeed, we have not been good at producing a descent version numbering schema. >> > My position was always this one: the last version should always fit your need. However, some product favored stability when Roassal is used in a commercial setting. >> > We will be more careful when updating the configuration with a proper version number. >> >> Versioning is in fact a complex thing. Thatâs why I suggest to have a brainstorming session during the camp. >> >> Uko >> >> > >> > Cheers, >> > Alexandre >> > >> > >> >> >> >> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Oh, then itâs my bad. Last time Iâve checked it seemed that it wasnât updated for a long time. Maybe I was wrong. >> >> >> >> Uko >> >> >> >> >> >> >> >>> On 05 Jun 2015, at 18:08, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> >> >>> There sure are, look at ConfigurationOfRoassal2>>version*: >> >>> >> >>> and in my baseline I have something like >> >>> >> >>> ~~~~~~~~~~~ >> >>> spec >> >>> project: 'Roassal2' with: [ >> >>> spec >> >>> className: #ConfigurationOfRoassal2; >> >>> versionString: '1.52'; >> >>> repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ]; >> >>> ~~~~~~~~~~~ >> >>> >> >>> Peter >> >>> >> >>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >>> But are there numbered version to refer to? >> >>> >> >>> Uko >> >>> >> >>>> On 05 Jun 2015, at 16:34, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>>> >> >>>> >> >>>> >> >>>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >>>> Iâm interested in participating. Personally Iâd like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve somethingâ¦ >> >>>> >> >>>> Yes I am also interested in this, right now I am actually using quite old version (month+) because I didn't have time to keep up. :) (Arguably 90% of my problems were from infamous composite shapes. :)) >> >>>> >> >>>> Peter >> >>>> >> >>>> Uko >> >>>> >> >>>>> On 04 Jun 2015, at 19:55, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >>>>> >> >>>>> Dear Colleagues and Friends, >> >>>>> >> >>>>> We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. >> >>>>> >> >>>>> As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: >> >>>>> - Port of Roassal on VisualWorks >> >>>>> - Using Roassal on Gemstone >> >>>>> - HTML/JavaScript export >> >>>>> - Improving Grapher, our charting library >> >>>>> >> >>>>> If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) >> >>>>> >> >>>>> Cheers, >> >>>>> Alexandre >> >>>>> -- >> >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>>>> Alexandre Bergel http://www.bergel.eu >> >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >> >> >> >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 16, 2015

Re: [Pharo-dev] Roassal Camp Smalltalk

by Alexandre Bergel

Hi Peter, I am really sorry about the instability. The book chapter has been updated. Cheers, Alexandre > On Jun 14, 2015, at 7:10 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Since I've already run into second thing in agile visualization book that is outdated (RTArrow, which was some time ago renamed to RTArrowedLine (https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… section 2.2) it made me wonder how many things like these are there (considering in neither case I was looking for errors). > > So, maybe this could be also addressed at the camp if there will be time? > > Writing is hard and reviewing own work is exercise in futility (I see things that I want to see, not what is there). Some of it (like the examples) could be even executed to verify their validity. > > And lastly what I saw in another thread (by stef) - graceful deprecation, and stabilization of API. > > Peter > > On Tue, Jun 9, 2015 at 9:57 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > On 08 Jun 2015, at 18:22, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > >> Well at least for me it is certainly not clear what release policy is Roassal following; i.e. if I see a minor version change what to expect, if any BC breaks were introduced, etc. Of course this is extra effort for the person doing it, so it should be taken with care. But there are certainly things to be discussed about this. > > > > Hi Peter, > > > > Indeed, we have not been good at producing a descent version numbering schema. > > My position was always this one: the last version should always fit your need. However, some product favored stability when Roassal is used in a commercial setting. > > We will be more careful when updating the configuration with a proper version number. > > Versioning is in fact a complex thing. Thatâs why I suggest to have a brainstorming session during the camp. > > Uko > > > > > Cheers, > > Alexandre > > > > > >> > >> On Fri, Jun 5, 2015 at 7:31 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> Oh, then itâs my bad. Last time Iâve checked it seemed that it wasnât updated for a long time. Maybe I was wrong. > >> > >> Uko > >> > >> > >> > >>> On 05 Jun 2015, at 18:08, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >>> > >>> There sure are, look at ConfigurationOfRoassal2>>version*: > >>> > >>> and in my baseline I have something like > >>> > >>> ~~~~~~~~~~~ > >>> spec > >>> project: 'Roassal2' with: [ > >>> spec > >>> className: #ConfigurationOfRoassal2; > >>> versionString: '1.52'; > >>> repository: 'http://smalltalkhub.com/mc/ObjectProfile/Roassal2/main/' ]; > >>> ~~~~~~~~~~~ > >>> > >>> Peter > >>> > >>> On Fri, Jun 5, 2015 at 4:37 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >>> But are there numbered version to refer to? > >>> > >>> Uko > >>> > >>>> On 05 Jun 2015, at 16:34, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >>>> > >>>> > >>>> > >>>> On Fri, Jun 5, 2015 at 3:29 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >>>> Iâm interested in participating. Personally Iâd like to talk more about design decisions behind roassal ecosystem, release strategy and so on. Usually when I work with Roassal I have this issue that things are breaking because of rapid changes, or because of the differences between different parts of roassal. Maybe someone is also concerned about this, so we can discuss and maybe improve somethingâ¦ > >>>> > >>>> Yes I am also interested in this, right now I am actually using quite old version (month+) because I didn't have time to keep up. :) (Arguably 90% of my problems were from infamous composite shapes. :)) > >>>> > >>>> Peter > >>>> > >>>> Uko > >>>> > >>>>> On 04 Jun 2015, at 19:55, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >>>>> > >>>>> Dear Colleagues and Friends, > >>>>> > >>>>> We are happy to announce we will organize a CampSmalltalk about the Roassal visualization engine, on _Sunday 12 July_. > >>>>> > >>>>> As far as we have seen, the interests are multiple. Here is a list of topics we will happy to work on: > >>>>> - Port of Roassal on VisualWorks > >>>>> - Using Roassal on Gemstone > >>>>> - HTML/JavaScript export > >>>>> - Improving Grapher, our charting library > >>>>> > >>>>> If you wish to participate, get in touch with us. Since we will probably have a sponsoring of the event, it would be nice to know how many will attend to ease the logistic and the pizza ordering :-) > >>>>> > >>>>> Cheers, > >>>>> Alexandre > >>>>> -- > >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>>> Alexandre Bergel http://www.bergel.eu > >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 16, 2015

Re: [Pharo-dev] We want to remove historyNavigation from Nautilus...

by Dimitris Chloupis

me too, quite a lot On Tue, Jun 16, 2015 at 11:19 PM phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I use it too. > Le 16 juin 2015 22:10, "Nicolai Hess" <nicolaihess(a)web.de> a Ã©crit : > >> >> >> 2015-06-16 18:00 GMT+02:00 stepharo <stepharo(a)free.fr>: >> >>> Hi guys >>> >>> we really need to cleanup nautilus and we are thinking to remove the >>> history navigation. >>> So we hope that not that many people will cry but we should move on. >>> >> >> I use it often and I find it helpful. Will it be replaced with another >> history navigation? >> >> >>> We are also cleaning the group management. >>> >>> Stef >>> >>> >>

June 16, 2015

Re: [Pharo-dev] We want to remove historyNavigation from Nautilus...

by phil＠highoctane.be

I use it too. Le 16 juin 2015 22:10, "Nicolai Hess" <nicolaihess(a)web.de> a Ã©crit : > > > 2015-06-16 18:00 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> Hi guys >> >> we really need to cleanup nautilus and we are thinking to remove the >> history navigation. >> So we hope that not that many people will cry but we should move on. >> > > I use it often and I find it helpful. Will it be replaced with another > history navigation? > > >> We are also cleaning the group management. >> >> Stef >> >> >

June 16, 2015

Re: [Pharo-dev] We want to remove historyNavigation from Nautilus...

by Nicolai Hess

2015-06-16 18:00 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi guys > > we really need to cleanup nautilus and we are thinking to remove the > history navigation. > So we hope that not that many people will cry but we should move on. > I use it often and I find it helpful. Will it be replaced with another history navigation? > We are also cleaning the group management. > > Stef > >

June 16, 2015