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

Re: [Pharo-dev] WhatsUp from: 2015-08-17 until: 2015-08-31

by Dimitris Chloupis

I was thinking something similar. Its not a crazy idea at all. Auto completion already has a detailed view for class comments if its enabled in settings. However a more minimal gui will be needed not to make the life of the user difficult . On Thu, Aug 20, 2015 at 12:36 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi > > 2015-08-20 6:54 GMT+03:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > >> >>> Auto-completion in Pharo is really bad. It would be fantastic to improve >>> it. >>> >>> >> Yes indeed, my effort for now is focused in documenting it. I cannot >> improve what I dont understand. Then will see if I can improve it, by >> making it more customizable or making it a bit smarter. >> > > I have crazy idea to integrate GTSpotter to autocompletion pane to allow > immediate search on existed texts. What you think about this? >

Aug. 20, 2015

Re: [Pharo-dev] WhatsUp from: 2015-08-17 until: 2015-08-31

by Tudor Girba

Hi, On Thu, Aug 20, 2015 at 5:54 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > > On Thu, Aug 20, 2015 at 4:42 AM Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >> > 2) Gave a deep reading on Pharo auto completion. >> >> Auto-completion in Pharo is really bad. It would be fantastic to improve >> it. >> >> > Yes indeed, my effort for now is focused in documenting it. I cannot > improve what I dont understand. Then will see if I can improve it, by > making it more customizable or making it a bit smarter. > > >> > 3) Study how Playgrounds draws its GUI to improve it by making far more >> flexible. >> >> Can you say more about this? >> > > > I have talked about this long time ago. I was imagining a new tool I > called "Cyclops". The idea of Cyclops was born when I was reading the > GTPlayground comment that says > > "Playground is the correspondent of a classic Smalltalk Workspace. *The > problem with the name Workspace is that it implies that work should be > carried out in this space, while this is not a best practice*. Playground > describes better the intention of providing a place in which we can quickly > play with some code." > > My first reply to this comment was "Why not ?". So the idea is to have a > new Workspace that allows the user to create code , add it to a class, > inspect, debug , print and do all code tasks without ever leaving the > boundaries of the tool. GTPlayground already does this in some way by > implementing the inspector inside workspace that also has some browsing > capabilities. I would also like to integrate the GTSpotter gui inside > GTPlayground. The idea here is to bring all these tools inside a single > window. > > It will be a slow process , for now documenting GTPlayground is the goal, > next will be to provide a cleaner design for printing values, creating > blocks of code that the GTPlayground is aware of and allows the user to be > added to a new or existing class as methods and some code browsing > abilities. I am also interested into browsing documentation inside > workspace and I have many other ideas. > > For now the goal is just to read the code of GTPlayground GUI and try to > document it > > One step at a time ;) > Thanks for describing your intention. Indeed, this is the direction of the new Playground as well. For example, at ESUG Andrei and Alex Syrel demonstrated Snippets, which basically allow you to have multiple types of code/text/pillar/methods ... in the same playground and build a live document out of it. We are currently mainly focused on the widgets part on top of bloc, but we will soon get back to the tools. In any case, we are interested in ideas that people have. Cheers, Doru > Cheers, >> Alexandre >> >> >> > 4) Study a new programming language Nim , for making dynamic libraries >> for pharo , replacing C/C++. Possible scenario of porting SqueakNim to >> Pharo. >> > >> > To Do >> > >> > 1) Improve my blue theme (Nireas) >> > 2) Create an API for Blender for Pharo >> > 3) Create my own custom Playground which will be more powerful >> > 4) Integrate Nim with Pharo >> > >> > On Tue, Aug 18, 2015 at 6:23 PM Sean P. DeNigris <sean(a)clipperadams.com> >> wrote: >> > ### Here's what I've been up to since the last WhatsUp: >> > - Ported Moose issue tracker to GitHub >> > - GT extension for presentations semi-auto-generated from Magritte >> > descriptions >> > - data, label, etc pre-filled by default >> > - Magritte actions appear as e.g. presentation list selection context >> menu >> > - Magritte >> > - extension for above >> > - many little fixes and enhancements >> > - [WIP]: Created Glamour browsers from presentations >> > - Glamour/GT patches >> > - GSoC Mentoring for sQuick Smalltalk project >> > >> > ### What's next, until 2015-08-31 (*): >> > - Camp Smalltalk Portland! >> > >> > >> > >> > >> > ----- >> > Cheers, >> > Sean >> > -- >> > View this message in context: >> http://forum.world.st/WhatsUp-from-2015-08-17-until-2015-08-31-tp4843391p48… >> > Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> -- www.tudorgirba.com "Every thing has its own flow"

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by stepharo

Le 20/8/15 11:08, Esteban Lorenzano a Ã©crit : > >> On 20 Aug 2015, at 09:14, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> For example why protocol get the same space than method. We could >> split the protocol by half and use the space for >> soemthing useful. >> >> I would like the coding area to expand a bit when a method is too long. >> I do it all the time by hand. > > not just a bit: I would like a button (and a key combination) to > expand the full area to occupy all browser space when needed. > and not just the code area: the different panels too: no matter how > much you reduce the size of protocols and/or packages, there will > always be methods and classes with bigger namesâ¦ I think an âexpandâ > function is better solution than arbitrary change panel sizes. I want an accordeon like..... > > Esteban > >> >> Stef >> >> >> Le 19/8/15 13:13, Thierry Goubier a Ã©crit : >>> Hitting send too early :( >>> >>> 2015-08-19 11:59 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com >>> <mailto:estebanlm@gmail.com>>: >>> >>> >>>> On 19 Aug 2015, at 11:50, Esteban Lorenzano >>>> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>> >>>>> >>>>> On 19 Aug 2015, at 11:44, Thierry Goubier >>>>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> >>>>> wrote: >>>>> >>>>> <Screen Shot 2015-08-19 at 11.10.41.png> >>>>> >>>>> â¦ but arriving to it is not so easy. >>>>> >>>>> In conclusion: We are doing some right steps. It is not >>>>> finished, but we are not going to go back to older way :) >>>>> >>>>> >>>>> Hi Esteban, >>>>> >>>>> My opinion is that you're still tied a lot to the Smalltalk >>>>> 80's way... Which is good: someone coming from 1980 would be >>>>> able to use Nautilus ;) >>>>> >>>>> My critics on that design: the tabs are nice and certainly >>>>> help see that a class has a class side. Overall look is more >>>>> up to date. Tabs headers, scroll bars, etc... take far too >>>>> much space: work area (the code area) is 39% of overall window >>>>> size, and 68% counting in the context (package, class, >>>>> protocol and method) (Numbers are worse on a small window, of >>>>> course, but I guess some do work on small screens). >>>>> >>>>> It will be nice to see simpler / cleaner Nautilus code coming >>>>> along :) >>>> >>>> yes, of course you are right :) >>>> the GTools guys are working in a complete replacement, and Iâm >>>> sure it will be a lot betterâ¦ but we will always need a >>>> backdoorâ¦ and I would like to have a good browser even as a >>>> backdoor. >>> >>> I'm certainly looking forward for the GT-based system browser >>> results, while probably I won't be using it; some of the design / >>> implementation choices of the GT tools just don't fit the way I >>> work, and I feel down by just looking at how clumsy and slow I >>> become when using them. >>> >>>> (also, our philosophy is incremental: we improve what we have >>>> while we wait for the break-thru improvements) >>> >>> Agreed. I still miss a bit the OmniBrowser I started Pharo with... >>> Especially the code regularity and architecture. >>> >>>> >>>> Esteban >>>> >>>> ps: for me the âcode areaâ is not equivalent to the âwork >>>> areaâ: I spend much more time understanding a problem than >>>> coding it, and for that a view of the method *in the context* >>>> is better) >>> >>> That's why I added the 68% result: I do agree that the context >>> matter; I still think that the overhead is too high. >>> >>> >>> for example: I try your alt browser time to time, because I find >>> it has some good ideas. >>> But since my workflow is usually: I dig a package, then I see >>> the classes inside and try to figure out how they work together, >>> then I read the comments, try to find examples, testsâ¦ then I >>> finally go to the method level, and even that often with an eye >>> into the class it belongs and even the packageâ¦ so the >>> AltBrowser is useless for meâ¦ it is really not confortable for >>> me to useâ¦ and yes, it has a bigger code area, but that is not >>> really relevant (for me). >>> â¦ and the traditional browser adapts a lot better to that way of >>> doing. >>> >>> >>> I think I more or less do the same, but with a slightly different >>> approach, with for example a lot of scoping (to a class, to a >>> package, implementors, senders, finder). I especially rely on the >>> fact that I stay in the browser task model (but with multiple >>> windows) all the time while doing that; I don't have to deal with >>> disparate tools (Spotter, Finder, MessageList). >>> >>> I also like the fact I can see both class and instance side methods >>> at the same time... >>> >>> Nowâ¦ real question is: I work that way because fits better my >>> mind-model or my mind-model fits what the browser provides me? >>> well, who knowsâ¦ but back in my java days I also was using the >>> âjava browsing perspectiveâ of Eclipse, who resembles a >>> Smalltalk browser. >>> >>> >>> The good question we have here is that our >>> search/exploration/understanding strategies are different, but based >>> on the same building blocks... So there is some Moldable issue there >>> as per the GT group, but not inside the tool as they are currently >>> doing, instead the tool itself has to be moldable (or what is the tool). >>> >>> Now, I'm so attuned to the Alt Browser tree view that I prefer it in >>> any case... even to the point that I can do short and fast smalltalk >>> edits directly on github through the web interface. >>> >>> Thierry >>> >>> >>> Esteban >>> >>>> >>>>> >>>>> Thierry >>> >>> >> >

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by stepharo

> > my âproposalâ is just a fast sketch made to illustrate how I would > like to show certain functionality, it does not take into account any > other functionalityâ¦ If I finish my browser proposal ever, it will > have a lot more buttons in the toolbar :) > about hierarchy I think it should spawn a new browser, as beforeâ¦ but > it is still something we need to play with it. NOoooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > >> The same way we use all the time variables. > > *we* use them all the time, but most people does not use them never :) > anyway: an option in a tab is one click, same as with a button: not > hardâ¦ and we can play with the information we show in auxiliary panels > better :) We could have a set up for normal dev and one for indiana jones. > > Esteban > >> >> Stef >> >> Le 19/8/15 11:50, Esteban Lorenzano a Ã©crit : >>> >>>> On 19 Aug 2015, at 11:44, Thierry Goubier >>>> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >>>> >>>> <Screen Shot 2015-08-19 at 11.10.41.png> >>>> >>>> â¦ but arriving to it is not so easy. >>>> >>>> In conclusion: We are doing some right steps. It is not >>>> finished, but we are not going to go back to older way :) >>>> >>>> >>>> Hi Esteban, >>>> >>>> My opinion is that you're still tied a lot to the Smalltalk 80's >>>> way... Which is good: someone coming from 1980 would be able to use >>>> Nautilus ;) >>>> >>>> My critics on that design: the tabs are nice and certainly help see >>>> that a class has a class side. Overall look is more up to date. >>>> Tabs headers, scroll bars, etc... take far too much space: work >>>> area (the code area) is 39% of overall window size, and 68% >>>> counting in the context (package, class, protocol and method) >>>> (Numbers are worse on a small window, of course, but I guess some >>>> do work on small screens). >>>> >>>> It will be nice to see simpler / cleaner Nautilus code coming along :) >>> >>> yes, of course you are right :) >>> the GTools guys are working in a complete replacement, and Iâm sure >>> it will be a lot betterâ¦ but we will always need a backdoorâ¦ and I >>> would like to have a good browser even as a backdoor. >>> (also, our philosophy is incremental: we improve what we have while >>> we wait for the break-thru improvements) >>> >>> Esteban >>> >>> ps: for me the âcode areaâ is not equivalent to the âwork areaâ: I >>> spend much more time understanding a problem than coding it, and for >>> that a view of the method *in the context* is better) >>> >>>> >>>> Thierry >>> >> >

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by Dimitris Chloupis

I took a look at the class you recommended and now I see what you mean.I am glad this is not deeply tied to the system browser and is something other tools can use as well with ease. Very flexible too. Looks like the tools only expose a fraction of the power of the environment . Makes me wonder whether environment would be a good idea to be used as some sort of namespaces. On Thu, Aug 20, 2015 at 9:08 AM Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 19/08/2015 20:26, Dimitris Chloupis a Ã©crit : > > > > > > On Wed, Aug 19, 2015 at 5:51 PM Sean P. DeNigris <sean(a)clipperadams.com > > <mailto:sean@clipperadams.com>> wrote: > > > > kilon.alios wrote > > > > > > For example, let's say your project has a class that implements a > > generically-named method, like #asMorph. If you try to rename that > > method > > via Refactoring, Pharo will try to rename all #asMorph methods, and > > update > > all senders, in the entire system, not just yours. But if you scope > the > > browser first to your package or class, you can restrict the > > environment to > > which the refactoring is applied > > > > > > This sounds useful indeed. Is just the browser aware of the scope or is > > also the pharo environment aware of the scope too ? It would be nice if > > the scope could expand to include multiple packages , or is this > > something left to groups ? > > What is happening is that many commands linked to the IDE (refactorings, > searches) have an environment entity. By default, this environment is > Smalltalk, but it can be a subset of it, and any subset of it. > > Have a look into the RBBrowserEnvironment class and subclasses and you > will see all the variants. For example, a RBPackageEnvironment will > scope to one or multiple packages. > > Thierry > > > >

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by phil＠highoctane.be

On Thu, Aug 20, 2015 at 11:08 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 20 Aug 2015, at 09:14, stepharo <stepharo(a)free.fr> wrote: > > For example why protocol get the same space than method. We could split > the protocol by half and use the space for > soemthing useful. > > I would like the coding area to expand a bit when a method is too long. > I do it all the time by hand. > > > not just a bit: I would like a button (and a key combination) to expand > the full area to occupy all browser space when needed. > and not just the code area: the different panels too: no matter how much > you reduce the size of protocols and/or packages, there will always be > methods and classes with bigger namesâ¦ I think an âexpandâ function is > better solution than arbitrary change panel sizes. > Right thing to do if you ask me. Or like TWM, have a bunch of icons to put the part where you want it. Or like on Windows applications: drag and drop the panes around and save the layout with a given name (now, this one would be harder) Phil > > Esteban > > > Stef > > > Le 19/8/15 13:13, Thierry Goubier a Ã©crit : > > Hitting send too early :( > > 2015-08-19 11:59 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> >> On 19 Aug 2015, at 11:50, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> On 19 Aug 2015, at 11:44, Thierry Goubier <thierry.goubier(a)gmail.com> >> wrote: >> >> <Screen Shot 2015-08-19 at 11.10.41.png> >>> >>> â¦ but arriving to it is not so easy. >>> >>> In conclusion: We are doing some right steps. It is not finished, but we >>> are not going to go back to older way :) >>> >> >> Hi Esteban, >> >> My opinion is that you're still tied a lot to the Smalltalk 80's way... >> Which is good: someone coming from 1980 would be able to use Nautilus ;) >> >> My critics on that design: the tabs are nice and certainly help see that >> a class has a class side. Overall look is more up to date. Tabs headers, >> scroll bars, etc... take far too much space: work area (the code area) is >> 39% of overall window size, and 68% counting in the context (package, >> class, protocol and method) (Numbers are worse on a small window, of >> course, but I guess some do work on small screens). >> >> It will be nice to see simpler / cleaner Nautilus code coming along :) >> >> >> yes, of course you are right :) >> the GTools guys are working in a complete replacement, and Iâm sure it >> will be a lot betterâ¦ but we will always need a backdoorâ¦ and I would like >> to have a good browser even as a backdoor. >> >> I'm certainly looking forward for the GT-based system browser results, > while probably I won't be using it; some of the design / implementation > choices of the GT tools just don't fit the way I work, and I feel down by > just looking at how clumsy and slow I become when using them. > >> (also, our philosophy is incremental: we improve what we have while we >> wait for the break-thru improvements) >> >> Agreed. I still miss a bit the OmniBrowser I started Pharo with... > Especially the code regularity and architecture. > >> >> Esteban >> >> ps: for me the âcode areaâ is not equivalent to the âwork areaâ: I spend >> much more time understanding a problem than coding it, and for that a view >> of the method *in the context* is better) >> >> That's why I added the 68% result: I do agree that the context matter; I > still think that the overhead is too high. > > >> >> for example: I try your alt browser time to time, because I find it has >> some good ideas. >> But since my workflow is usually: I dig a package, then I see the classes >> inside and try to figure out how they work together, then I read the >> comments, try to find examples, testsâ¦ then I finally go to the method >> level, and even that often with an eye into the class it belongs and even >> the packageâ¦ so the AltBrowser is useless for meâ¦ it is really not >> confortable for me to useâ¦ and yes, it has a bigger code area, but that is >> not really relevant (for me). >> â¦ and the traditional browser adapts a lot better to that way of doing. >> > > I think I more or less do the same, but with a slightly different > approach, with for example a lot of scoping (to a class, to a package, > implementors, senders, finder). I especially rely on the fact that I stay > in the browser task model (but with multiple windows) all the time while > doing that; I don't have to deal with disparate tools (Spotter, Finder, > MessageList). > > I also like the fact I can see both class and instance side methods at the > same time... > > >> Nowâ¦ real question is: I work that way because fits better my mind-model >> or my mind-model fits what the browser provides me? well, who knowsâ¦ but >> back in my java days I also was using the âjava browsing perspectiveâ of >> Eclipse, who resembles a Smalltalk browser. >> > > The good question we have here is that our > search/exploration/understanding strategies are different, but based on the > same building blocks... So there is some Moldable issue there as per the GT > group, but not inside the tool as they are currently doing, instead the > tool itself has to be moldable (or what is the tool). > > Now, I'm so attuned to the Alt Browser tree view that I prefer it in any > case... even to the point that I can do short and fast smalltalk edits > directly on github through the web interface. > > Thierry > > >> Esteban >> >> >> >> Thierry >> >> >> > > >

Aug. 20, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50251 Home: https://github.com/pharo-project/pharo-core

Aug. 20, 2015

[pharo-project/pharo-core] a918b7: 50251

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a918b7ae66b91e62ab0583ff991d86550d6fea7c https://github.com/pharo-project/pharo-core/commit/a918b7ae66b91e62ab0583ff… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-20 (Thu, 20 Aug 2015) Changed paths: R Komitter.package/DataRetriever.class/README.md R Komitter.package/DataRetriever.class/class/instance creation/for_.st R Komitter.package/DataRetriever.class/definition.st R Komitter.package/DataRetriever.class/instance/accessing/block_.st R Komitter.package/DataRetriever.class/instance/accessing/data.st R Komitter.package/DataRetriever.class/instance/accessing/nullObject_.st R Komitter.package/DataRetriever.class/instance/initialize/initialize.st R Komitter.package/DataRetriever.class/instance/private/retrieveData.st R Komitter.package/DataRetriever.class/instance/private/signalDataIsReady.st R Komitter.package/DataRetriever.class/instance/protocol/release.st M Komitter.package/KomitClassNode.class/instance/initialization/initialize.st M Komitter.package/KomitLeaf.class/instance/initialization/initialize.st M Komitter.package/KomitNode.class/instance/initialization/initialize.st M Komitter.package/KomitPackage.class/definition.st M Komitter.package/KomitPackage.class/instance/accessing/package_.st M Komitter.package/KomitPackage.class/instance/accessing/patch.st R Komitter.package/KomitPackage.class/instance/private/retrievePatch.st M Komitter.package/KomitPackage.class/instance/protocol/flush.st M Nautilus-GroupManager.package/PackageGroup.class/instance/accessing/elements.st M Nautilus.package/AbstractNautilusUI.class/class/shortcuts/buildBrowseShortcutsOn_.st M Nautilus.package/AbstractNautilusUI.class/class/shortcuts/buildExtraShortcutsOn_.st M Nautilus.package/AbstractNautilusUI.class/class/shortcuts/buildFindShortcutsOn_.st M Nautilus.package/AbstractNautilusUI.class/class/shortcuts/buildGotoNavigationShortcutsOn_.st M Nautilus.package/AbstractNautilusUI.class/class/shortcuts/buildRunTestKeymappingsOn_.st R Nautilus.package/AbstractNautilusUI.class/instance/group announcements/aGroupHasBeenRegistered_.st R Nautilus.package/AbstractNautilusUI.class/instance/group announcements/aGroupHasBeenUnregistered_.st R Nautilus.package/AbstractNautilusUI.class/instance/private/browseClassVars.st R Nautilus.package/AbstractNautilusUI.class/instance/private/browseInstVars.st M Nautilus.package/AbstractNautilusUI.class/instance/system announcements/packageRegistered_.st M Nautilus.package/Nautilus.class/class/accessing/maxSize_.st R Nautilus.package/Nautilus.class/class/accessing/recentClasses.st M Nautilus.package/Nautilus.class/class/cleanup/cleanUp.st M Nautilus.package/Nautilus.class/class/groups/buildGroupManager.st A Nautilus.package/Nautilus.class/class/groups/configurationPackages.st A Nautilus.package/Nautilus.class/class/groups/configurationsGroupName.st R Nautilus.package/Nautilus.class/class/groups/lastModifiedClasses.st R Nautilus.package/Nautilus.class/class/private/recentClassesElements.st M Nautilus.package/Nautilus.class/definition.st R Nautilus.package/Nautilus.class/instance/accessing/recentClasses.st M Nautilus.package/Nautilus.class/instance/accessing/selectedClass_.st M Nautilus.package/PackageTreeModel.class/instance/private/packagesAsNodes.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50250.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50251.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50250.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50251.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50251 16292 Make TreeNode of Komitter user friendly https://pharo.fogbugz.com/f/cases/16292 16296 Default group with configurations in Nautilus https://pharo.fogbugz.com/f/cases/16296 16297 Add shortcut to open variables menu https://pharo.fogbugz.com/f/cases/16297 16288 Remove parallel diff calculation https://pharo.fogbugz.com/f/cases/16288 http://files.pharo.org/image/50/50251.zip

Aug. 20, 2015

Re: [Pharo-dev] Nautilus questions

by phil＠highoctane.be

On Thu, Aug 20, 2015 at 10:19 AM, stepharo <stepharo(a)free.fr> wrote: > > > Le 20 aoÃ»t 2015 09:15, "stepharo" <stepharo(a)free.fr> a Ã©crit : > > > > For example why protocol get the same space than method. We could split > the protocol by half and use the space for > > soemthing useful. > > Protocol names can be long... > > > yes but 99% of the time you do not care. > And methods are way more important. > In fact protocol could just the tag (as in the catalog browser) after the > method names. > FWIW, protocols allow to have nice segregation of methods without inflating the number of classes (hey, Java, I am looking at you). I have a number of cases where I do have *myproject-someaspect1", *myproject-someaspect2", "*myproject-someaspect3" ... in the classes. Protocols also help in making sense of the methods. It is also something different about the way we do code. Protocol really work well with the "messaging" concept. "We can talk because we understand that protocol". Not because we have a full dictionary of sentences. Phil > > Stef > > > > > I would like the coding area to expand a bit when a method is too long. > > I do it all the time by hand. > > Yes, especially with Seaside renderOn: > > Phil > > > > > Stef > > > > > > Le 19/8/15 13:13, Thierry Goubier a Ã©crit : > >> > >> Hitting send too early :( > >> > >> 2015-08-19 11:59 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >>> > >>> > >>>> On 19 Aug 2015, at 11:50, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >>>> > >>>>> > >>>>> On 19 Aug 2015, at 11:44, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > >>>>> > >>>>>> <Screen Shot 2015-08-19 at 11.10.41.png> > >>>>>> > >>>>>> â¦ but arriving to it is not so easy. > >>>>>> > >>>>>> In conclusion: We are doing some right steps. It is not finished, > but we are not going to go back to older way :) > >>>>> > >>>>> > >>>>> Hi Esteban, > >>>>> > >>>>> My opinion is that you're still tied a lot to the Smalltalk 80's > way... Which is good: someone coming from 1980 would be able to use > Nautilus ;) > >>>>> > >>>>> My critics on that design: the tabs are nice and certainly help see > that a class has a class side. Overall look is more up to date. Tabs > headers, scroll bars, etc... take far too much space: work area (the code > area) is 39% of overall window size, and 68% counting in the context > (package, class, protocol and method) (Numbers are worse on a small window, > of course, but I guess some do work on small screens). > >>>>> > >>>>> It will be nice to see simpler / cleaner Nautilus code coming along > :) > >>>> > >>>> > >>>> yes, of course you are right :) > >>>> the GTools guys are working in a complete replacement, and Iâm sure > it will be a lot betterâ¦ but we will always need a backdoorâ¦ and I would > like to have a good browser even as a backdoor. > >> > >> I'm certainly looking forward for the GT-based system browser results, > while probably I won't be using it; some of the design / implementation > choices of the GT tools just don't fit the way I work, and I feel down by > just looking at how clumsy and slow I become when using them. > >>>> > >>>> (also, our philosophy is incremental: we improve what we have while > we wait for the break-thru improvements) > >> > >> Agreed. I still miss a bit the OmniBrowser I started Pharo with... > Especially the code regularity and architecture. > >>>> > >>>> > >>>> Esteban > >>>> > >>>> ps: for me the âcode areaâ is not equivalent to the âwork areaâ: I > spend much more time understanding a problem than coding it, and for that a > view of the method *in the context* is better) > >> > >> That's why I added the 68% result: I do agree that the context matter; > I still think that the overhead is too high. > >> > >>> > >>> > >>> for example: I try your alt browser time to time, because I find it > has some good ideas. > >>> But since my workflow is usually: I dig a package, then I see the > classes inside and try to figure out how they work together, then I read > the comments, try to find examples, testsâ¦ then I finally go to the method > level, and even that often with an eye into the class it belongs and even > the packageâ¦ so the AltBrowser is useless for meâ¦ it is really not > confortable for me to useâ¦ and yes, it has a bigger code area, but that is > not really relevant (for me). > >>> â¦ and the traditional browser adapts a lot better to that way of doing. > >> > >> > >> I think I more or less do the same, but with a slightly different > approach, with for example a lot of scoping (to a class, to a package, > implementors, senders, finder). I especially rely on the fact that I stay > in the browser task model (but with multiple windows) all the time while > doing that; I don't have to deal with disparate tools (Spotter, Finder, > MessageList). > >> > >> I also like the fact I can see both class and instance side methods at > the same time... > >> > >>> > >>> Nowâ¦ real question is: I work that way because fits better my > mind-model or my mind-model fits what the browser provides me? well, who > knowsâ¦ but back in my java days I also was using the âjava browsing > perspectiveâ of Eclipse, who resembles a Smalltalk browser. > >> > >> > >> The good question we have here is that our > search/exploration/understanding strategies are different, but based on the > same building blocks... So there is some Moldable issue there as per the GT > group, but not inside the tool as they are currently doing, instead the > tool itself has to be moldable (or what is the tool). > >> > >> Now, I'm so attuned to the Alt Browser tree view that I prefer it in > any case... even to the point that I can do short and fast smalltalk edits > directly on github through the web interface. > >> > >> Thierry > >> > >>> > >>> Esteban > >>> > >>>> > >>>>> > >>>>> Thierry > >>> > >>> > >> > > > > >

Aug. 20, 2015

Re: [Pharo-dev] WhatsUp from: 2015-08-17 until: 2015-08-31

by Denis Kudriashov

2015-08-20 11:45 GMT+03:00 Max Leske <maxleske(a)gmail.com>: > > Just wondering, you need to have libssh2 working in order to get libgit2? > > How far are we from getting this working? > > Not exactly, but we need libssh2 for ssh support which, in my opinion, is > very important in this context (I use ssh with Git about 98% of the time). > Do you plan to implement FileSystem backend with libssh2?

Aug. 20, 2015