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

Re: [Pharo-dev] method return-typing (was Re: Date&Time api)

by Richard Sargent

Ben Coman wrote >> On Tue, Aug 18, 2015 at 1:21 AM, Yuriy Tymchuk < > yuriy.tymchuk@ > > wrote: >>> >>> Hi, >>> >>> there are some weird things around the data & time API. So time-related >>> classes are using methods like #asNanoSeconds. And numbers do not >>> implements >>> it. But they do implement methods as #nanoSeconds, #milliSeconds, >>> #seconds >>> and #asSeconds. Of course "5 nanoSecondsâ are nicer than â5 >>> asNanoSecondsâ. >>> Maybe we can do something to maintain polymorphism? >>> >>> Uko > > On Wed, Aug 19, 2015 at 3:21 AM, Chris Cunningham > < > cunningham.cb@ > > wrote: >> To, #asNanoSeconds converts the time into the umber of nanosecond that >> the >> time represents. >> #nanoSeconds (and the others) create a duration that is to be added to >> the >> time or DateAndTime. The two do not end with the same things 0 and >> shouldin't. >> >> The first tells you how many they represent; the second builds duration. >> >> Probably not ideal names - but the intents are definitely different. >> >> -cbc > > That is a fine distinction, and relatively hidden from someone reading > application code. So the follow up question is how to make such > distinction visible to an application developer. It would be nice to > hover over a message send to get a popup showing the "type" returned > and messages available. From time to time I consider what Smalltalk > might be like where the return-type of a method is specified (i.e. > only the method return type, still not typing variables). Anyone know > of a programming language like that? > > Return-typing might facilitate: > * Static analysis making a return-type hover popup simple. > * Static analysis of cascade message sends. > * Definition of global conventions that a particular message always > returns a particular type, with automatic checking. Runtime violations > might be logged full-time, or only when running unit tests. The > message return-type effectively becomes an interface definition and > the methods the implementation. > > A return type might be: > * a class > * a trait > * a more narrowly defined "protocol" subset of messages, which might > help with static analysis for modularisation and minimising the > bootstrap. > > cheers -ben > > btw, I notice... > * Number>>nanoSeconds returns a Duration, > * Duration>>nanoSeconds returns an Integer. If you want to rename anything, rename the instance variable. Keep Smalltalk readable. As long as it is an English-based language, spell out words in English. (Similar rules apply regardless of the language one uses to write Smalltalk applications!) > Should the latter be renamed #asNanoSeconds, or perhaps #nanos in line > with its instance variable? Indeed, perhaps all #asNanoSeconds should > be renamed #nanos, since its not converting to a NanoSeconds class. > If its being converted to a raw integer, presumably the context of its > usage will remain apparent plus the developer will have to > subsequently mange that. -- View this message in context: http://forum.world.st/method-return-typing-was-Re-Date-Time-api-tp4843929p4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 19, 2015

Re: [Pharo-dev] Nautilus questions

by Thierry Goubier

2015-08-19 16:46 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > kilon.alios wrote > > I failed to see why its useful... > >>> is particularly useful for: a) applying > >>> refactors, b) search senders/implementors inside my project and not in > >>> all > >>> image. > > 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. > A good example of scoping is finding all the senders of new in a package ;) > > > kilon.alios wrote > > I have to confess I was never and probably will never be a fan of the > > system browser > > I agree. It was probably well-suited to the context in which it was > invented, but I think we could do much better today. However: > - IMHO there is value in having a really-great-old-thing that empowers us > to > create an entirely new thing > - as mentioned, it's good to have a simple and robust fallback behind a > revolutionary new tool > Yes! You like it when you just managed to make your main browser unusable, or when your browser shows you something strange and you need to qualify it as a bug or as something which was already there, but invisible ;) You also need the old browser to understand how to do things; it's the only documentation you have access to. Thierry > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Nautilus-questions-tp4843893p4844082.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Aug. 19, 2015

Re: [Pharo-dev] Nautilus questions

by Sean P. DeNigris

kilon.alios wrote > I failed to see why its useful... >>> is particularly useful for: a) applying >>> refactors, b) search senders/implementors inside my project and not in >>> all >>> image. 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. kilon.alios wrote > I have to confess I was never and probably will never be a fan of the > system browser I agree. It was probably well-suited to the context in which it was invented, but I think we could do much better today. However: - IMHO there is value in having a really-great-old-thing that empowers us to create an entirely new thing - as mentioned, it's good to have a simple and robust fallback behind a revolutionary new tool ----- Cheers, Sean -- View this message in context: http://forum.world.st/Nautilus-questions-tp4843893p4844082.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 19, 2015

Re: [Pharo-dev] Nautilus questions

by Dimitris Chloupis

Yeah I did not phrase it the way I wanted it. I have used scoped several times to understands its purpose but each time I failed to see why its useful. I fail to see why opening a browser that displays a single package is important. But I guess if that's what people like , I can always ignore that button :) I have to confess I was never and probably will never be a fan of the system browser. I think the overall Smalltalk design wastes a lot of GUI space and provides me with info I mostly not need. Like a continuous display of a list of packages, classes and protocols / methods when the only thing I need to see all the time is the method source. On Wed, Aug 19, 2015 at 3:58 PM Ben Coman <btc(a)openinworld.com> wrote: > On Wed, Aug 19, 2015 at 5:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Hi, >> >> Some remarks: >> >> Yes: >> - yes, we are still working on Nautilus, and some of the things we are >> trying now will change (for example, I do not think we need the history >> dropdown there having the back/forward iconsâ¦ and in any case since they >> are talking about the same, they should be close) >> - yes, we can add other functionality, as Franck posted, thatâs why we >> ask for those functionality. Now if nobody answers, do not expect we can >> know what you want :) >> - yes, using abbreviated names there is bad. (Hier., Com.) we need to >> find a better place. >> - yes, âvariablesâ is not so relevant and I would like to move it to a >> place where does not look as is. I use it all the time, but in regular >> programming people should not need to use it all the time. Weâll see. >> >> Nos: >> - no, we are not going to put back buttons in the middle of the browser: >> what is a toolbar, should be where toolsbars go. I know many if you are >> used to the older way, but that older way was bad: the original idea was to >> put functionality close to the coding areaâ¦ no reason to do that this days. >> - actually, I do not have more ânosâ for now, but I want to keep this >> open, for the future ;) >> >> Some others: >> - the fact that you never used âScopedâ is actually the reason why we put >> it in such a relevant place: is one of the most powerful functionalities of >> Nautilus and we want you to have access to it in a direct and visible >> place. So you can start to use it. Using âI never used itâ as an argument >> does not work because in exchange I can say âthis is the function I use the >> most of nautilusâ. Give it a try, is particularly useful for: a) applying >> refactors, b) search senders/implementors inside my project and not in all >> image. >> - actually, I would like to remove also the buttons that acts on classes >> (most of them needs to be tabs in the right places). In my ideal browser, >> functionality is distributed like this: >> >> >> >> â¦ but arriving to it is not so easy. >> > > I *very* much like this concept of tabs rather buttons. Some ideas... > > You could have a [Scoped] tab next to [Packages]. Actually, beyond > providing a label (which I do like), the [Classes] tab doesn't seem to > serve much purpose. So maybe spread one tabbing area across the top of > both panes 1 & 2. Then you have more room for multiple tabs... > [Packages/Classes] [ Scope1] [Scope]. > This area might scroll tabs horizontally. You should be able to rename a > tab by direct action - just double-clicking or similar. > > Above panes 3 & 4, there seems there might be room to name the tabs... > [Instance protocols/methods] [Class protocols/methods] [Variables] > and eliminate one level of tabs. > > I like how panes 3 & 4 seems joined together. The same would look nice > between panes 1 & 2. This conveys in a subtle way the panes are paired > together. > > A nice shortcut to ]add packages to a scoped tab would be... > Ctrl-C in [Packages/Classes] tab to copy selected packages > Ctrl-V in [ScopeXX] tab to. > > Can [Definition] tab be named [Instances Definition] - and to be clear, I > do think plural is correct. > Or... maybe that gets confusing since we often talk about a "Class > Definition" while looking at the instance-side definition. > Perhaps they should be [Definition] [Meta Definition][Comment] > > Or alternatively, I rarely see definitions taking up much of the code > space. Now since previously the <Class-side> checkbox was tied to mode of > both definition and methods, but here tabs would seem to allow these to be > selected independently... perhaps there might be a single [Definition] tab > split vertically into two panes showing instance-side and class-side > definitions at the same time. Or maybe just one pane but the text of > class-sdie definition appended to instance-side definition. > > Perhaps selecting a method #myMethod adds a code pane tab [myMethod]. The > name of the tab would change each time a different method is selected, but > also you could pin a tab, thus making use of the empty space to the right > of the [Comment] tab. > > One thing that sometimes annoys me with current Nautilus, is that to view > a class definition, I need to deselect the method and loose my context > there. Tabs seem a great way to be able to flick back and forth without > loosing context. > > cheers -ben > > >> >> In conclusion: We are doing some right steps. It is not finished, but we >> are not going to go back to older way :) >> >> cheers, >> Esteban >> >> On 19 Aug 2015, at 10:04, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> >> wrote: >> >> There is free space for another functionnality. I asked for ideas of >> buttons before doing Scoped one (and it appeared that scoped is used by >> people). Variables is often used too, and there is no shortcut to browse >> all the access to the variables of a class so I think it is needed. >> They seem more needed than a button with an action which can be triggered >> by cmd + n or m in the same context than when you are about to clic on it >> (selector selected). >> >> The toolbar may take time to be loved, but I think new users are more >> used to a bar with functionnalities on top of a window than a middle bar. I >> would put all the buttons on top but I understand the strong link of >> hierarchy, class and comments with the classes panel so it is ok. >> >> And yes, the layout handling in this case is very painful. >> >> Franck >> >> ------------------------------ >> From: kilon.alios(a)gmail.com >> Date: Tue, 18 Aug 2015 20:49:34 +0000 >> To: pharo-dev(a)lists.pharo.org; pharo-users(a)lists.pharo.org >> Subject: Re: [Pharo-dev] Nautilus questions >> >> I agree with your post about the buttons. Personally I have never used >> scoped or really need it as feature , I dont think I would be needing >> variables either. Actually two buttons I miss from Squeak is implementers >> and senders which I found super useful. >> >> On Tue, Aug 18, 2015 at 11:00 PM Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> Hi, >> >> maybe I'm too picky, but I have couple of questions/remarks regarding >> current Nautilus UI. >> Now, I'm happy that new features were added/reorganized, but it does feel >> it is a little bit chaotic right now. >> >> <2015-08-18_191053.png> >> I would expect the left/right history buttons being right next to the >> History Navigator selector. That way history-related controls are together >> and the purpose of the buttons is obvious >> >> "Hier.", "Com."... abbreviating button labels? Really? >> >> âAnd finally, why was part of the buttons moved up? And part stayed down? >> I know that you wanted to distinguish "Scoped", because it opens a new >> browser, and Variables, because they have intermediate menu (and later open >> another menu). >> But I think the fact that Variables are tied to a particular selected >> class would make much more sense to place the button beside hierachy/class >> button. >> >> And opening Scoped can be denoted with an appropriate icon ( >> https://www.google.com/search?site=&tbm=isch&source=hp&biw=&bih=&q=new+wind… >> ) >> >> Placing them all on a single line would also save up vertical space, >> which considering we've added QualityAssistant and Rubric adds another line >> is quite valuable. >> >> (And finally the width of the buttons should perhaps match more closely >> the actual needs of the label, because now it's bit cramped.) >> >> <2015-08-18_214348.png> >> â >> And finally, code-wise I've never really interacted with Morphic and >> stayed in Spec, so when I was digging through code it seems that the way >> Morphs are composed are through these "addMorph:fullFrame: (LayoutFrame >> identity rightFraction: 0.10; yourself);" constructs sprinkled haphazardly >> throughout the code. Is there nothing like SpecLayout? Maybe it wasn't so >> hard once you get used to Morphic, because I spent probably more time doing >> elementary changes to layout than learning half of Spec... (Also since Spec >> can interoperate with Morphic, maybe the layout could also be adapted? Or >> slowly migrate Nautilus to Spec (if there are even plans like that)?) >> >> Now as I've mentioned I'm not an UI/UX expert, but you don't need to be a >> chef to tell when food isn't great (which is of course amplified by >> personal tastes). >> >> So unless I am the only person bothered by this, I would like to raise a >> discussion (or send a slice, but the way I've done the layout weirds me >> out, so I still want to look into that regardless). >> >> Cheers, >> Peter >> >> >>

Aug. 19, 2015

Re: [Pharo-dev] Nautilus questions

by Ben Coman

On Wed, Aug 19, 2015 at 5:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Some remarks: > > Yes: > - yes, we are still working on Nautilus, and some of the things we are > trying now will change (for example, I do not think we need the history > dropdown there having the back/forward iconsâ¦ and in any case since they > are talking about the same, they should be close) > - yes, we can add other functionality, as Franck posted, thatâs why we ask > for those functionality. Now if nobody answers, do not expect we can know > what you want :) > - yes, using abbreviated names there is bad. (Hier., Com.) we need to find > a better place. > - yes, âvariablesâ is not so relevant and I would like to move it to a > place where does not look as is. I use it all the time, but in regular > programming people should not need to use it all the time. Weâll see. > > Nos: > - no, we are not going to put back buttons in the middle of the browser: > what is a toolbar, should be where toolsbars go. I know many if you are > used to the older way, but that older way was bad: the original idea was to > put functionality close to the coding areaâ¦ no reason to do that this days. > - actually, I do not have more ânosâ for now, but I want to keep this > open, for the future ;) > > Some others: > - the fact that you never used âScopedâ is actually the reason why we put > it in such a relevant place: is one of the most powerful functionalities of > Nautilus and we want you to have access to it in a direct and visible > place. So you can start to use it. Using âI never used itâ as an argument > does not work because in exchange I can say âthis is the function I use the > most of nautilusâ. Give it a try, is particularly useful for: a) applying > refactors, b) search senders/implementors inside my project and not in all > image. > - actually, I would like to remove also the buttons that acts on classes > (most of them needs to be tabs in the right places). In my ideal browser, > functionality is distributed like this: > > > > â¦ but arriving to it is not so easy. > I *very* much like this concept of tabs rather buttons. Some ideas... You could have a [Scoped] tab next to [Packages]. Actually, beyond providing a label (which I do like), the [Classes] tab doesn't seem to serve much purpose. So maybe spread one tabbing area across the top of both panes 1 & 2. Then you have more room for multiple tabs... [Packages/Classes] [ Scope1] [Scope]. This area might scroll tabs horizontally. You should be able to rename a tab by direct action - just double-clicking or similar. Above panes 3 & 4, there seems there might be room to name the tabs... [Instance protocols/methods] [Class protocols/methods] [Variables] and eliminate one level of tabs. I like how panes 3 & 4 seems joined together. The same would look nice between panes 1 & 2. This conveys in a subtle way the panes are paired together. A nice shortcut to ]add packages to a scoped tab would be... Ctrl-C in [Packages/Classes] tab to copy selected packages Ctrl-V in [ScopeXX] tab to. Can [Definition] tab be named [Instances Definition] - and to be clear, I do think plural is correct. Or... maybe that gets confusing since we often talk about a "Class Definition" while looking at the instance-side definition. Perhaps they should be [Definition] [Meta Definition][Comment] Or alternatively, I rarely see definitions taking up much of the code space. Now since previously the <Class-side> checkbox was tied to mode of both definition and methods, but here tabs would seem to allow these to be selected independently... perhaps there might be a single [Definition] tab split vertically into two panes showing instance-side and class-side definitions at the same time. Or maybe just one pane but the text of class-sdie definition appended to instance-side definition. Perhaps selecting a method #myMethod adds a code pane tab [myMethod]. The name of the tab would change each time a different method is selected, but also you could pin a tab, thus making use of the empty space to the right of the [Comment] tab. One thing that sometimes annoys me with current Nautilus, is that to view a class definition, I need to deselect the method and loose my context there. Tabs seem a great way to be able to flick back and forth without loosing context. cheers -ben > > In conclusion: We are doing some right steps. It is not finished, but we > are not going to go back to older way :) > > cheers, > Esteban > > On 19 Aug 2015, at 10:04, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> > wrote: > > There is free space for another functionnality. I asked for ideas of > buttons before doing Scoped one (and it appeared that scoped is used by > people). Variables is often used too, and there is no shortcut to browse > all the access to the variables of a class so I think it is needed. > They seem more needed than a button with an action which can be triggered > by cmd + n or m in the same context than when you are about to clic on it > (selector selected). > > The toolbar may take time to be loved, but I think new users are more used > to a bar with functionnalities on top of a window than a middle bar. I > would put all the buttons on top but I understand the strong link of > hierarchy, class and comments with the classes panel so it is ok. > > And yes, the layout handling in this case is very painful. > > Franck > > ------------------------------ > From: kilon.alios(a)gmail.com > Date: Tue, 18 Aug 2015 20:49:34 +0000 > To: pharo-dev(a)lists.pharo.org; pharo-users(a)lists.pharo.org > Subject: Re: [Pharo-dev] Nautilus questions > > I agree with your post about the buttons. Personally I have never used > scoped or really need it as feature , I dont think I would be needing > variables either. Actually two buttons I miss from Squeak is implementers > and senders which I found super useful. > > On Tue, Aug 18, 2015 at 11:00 PM Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > maybe I'm too picky, but I have couple of questions/remarks regarding > current Nautilus UI. > Now, I'm happy that new features were added/reorganized, but it does feel > it is a little bit chaotic right now. > > <2015-08-18_191053.png> > I would expect the left/right history buttons being right next to the > History Navigator selector. That way history-related controls are together > and the purpose of the buttons is obvious > > "Hier.", "Com."... abbreviating button labels? Really? > > âAnd finally, why was part of the buttons moved up? And part stayed down? > I know that you wanted to distinguish "Scoped", because it opens a new > browser, and Variables, because they have intermediate menu (and later open > another menu). > But I think the fact that Variables are tied to a particular selected > class would make much more sense to place the button beside hierachy/class > button. > > And opening Scoped can be denoted with an appropriate icon ( > https://www.google.com/search?site=&tbm=isch&source=hp&biw=&bih=&q=new+wind… > ) > > Placing them all on a single line would also save up vertical space, which > considering we've added QualityAssistant and Rubric adds another line is > quite valuable. > > (And finally the width of the buttons should perhaps match more closely > the actual needs of the label, because now it's bit cramped.) > > <2015-08-18_214348.png> > â > And finally, code-wise I've never really interacted with Morphic and > stayed in Spec, so when I was digging through code it seems that the way > Morphs are composed are through these "addMorph:fullFrame: (LayoutFrame > identity rightFraction: 0.10; yourself);" constructs sprinkled haphazardly > throughout the code. Is there nothing like SpecLayout? Maybe it wasn't so > hard once you get used to Morphic, because I spent probably more time doing > elementary changes to layout than learning half of Spec... (Also since Spec > can interoperate with Morphic, maybe the layout could also be adapted? Or > slowly migrate Nautilus to Spec (if there are even plans like that)?) > > Now as I've mentioned I'm not an UI/UX expert, but you don't need to be a > chef to tell when food isn't great (which is of course amplified by > personal tastes). > > So unless I am the only person bothered by this, I would like to raise a > discussion (or send a slice, but the way I've done the layout weirds me > out, so I still want to look into that regardless). > > Cheers, > Peter > > >

Aug. 19, 2015

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

by Martin Dias

El lun., 17 ago. 2015 a las 7:00, <seaside(a)rmod.lille.inria.fr> escribiÃ³: > Hi! We're sending this automatic email twice a month, to give the > community an opportunity to easily know what's happening and to coordinate > efforts. Just answer informally, and feel free to spawn discussions > thereafter! > > ### Here's what I've been up to since the last WhatsUp: > Small steps towards a clearer API and implementation in change/source subsystem (applying refactorings and repackaging code related to .changes, .sources, RemoteStrings and "file out") > > ### What's next, until 2015-08-31 (*): > > Continue, slowly. MartÃn

Aug. 19, 2015

Re: [Pharo-dev] Nautilus questions

by Thierry Goubier

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. 19, 2015

Re: [Pharo-dev] Nautilus questions

by Christophe Demarey

Le 19 aoÃ»t 2015 Ã 11:34, Peter UhnÃ¡k a Ã©crit : > Nos: > - no, we are not going to put back buttons in the middle of the browser: what is a toolbar, should be where toolsbars go. I know many if you are used to the older way, but that older way was bad: the original idea was to put functionality close to the coding areaâ¦ no reason to do that this days. > > Could you elaborate on this please? Because I don't understand why having it close to the coding area is no longer meaningful. It could be a toolbar of the code pane ;) This way, it will be a toolbar at the top of the code pane but will be in the middle of the window as before.

Aug. 19, 2015

Re: [Pharo-dev] Nautilus questions

by Thierry Goubier

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. > > Agreed for the need for a simple, safe browser just in case (developping a browser in a. I'm certainly looking forward for the ideas > (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) > > > 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. > 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. > > Esteban > > > > Thierry > > >

Aug. 19, 2015

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

by Merwan Ouddane

Ok nice I'll take a look someday. Good job :) On mer., 2015-08-19 at 08:57 +0000, Dimitris Chloupis wrote: > The project is called Ephestos , goal is to use Pharo to script > Blender > > > You can watch a demo here > > https://www.youtube.com/watch?v=XPGDQc5LUvE > > > Documentation can be found here > > http://kilon.gitbooks.io/ephestos/content/introduction/introduction.pier.ht… > > > You no longer need to install Ephestos in Pharo via Gofer, latest > version can be installed through Configuration Browser/ Catalog > Browser with a single click. > > > If you want more info you can find me online at the official irc pharo > channel #pharo at freenode.net I have the nick name "kilon" or > "thekilon" > > > > On Wed, Aug 19, 2015 at 10:33 AM Merwan Ouddane > <merwanouddane(a)gmail.com> wrote: > > That's awesome :) > > On the top of which project will you write this api ? > > Le 19 aoÃ»t 2015 08:05, "Dimitris Chloupis" > <kilon.alios(a)gmail.com> a Ã©crit : > Yeap that one. > > > On Wed, Aug 19, 2015 at 12:30 AM Merwan Ouddane > <merwanouddane(a)gmail.com> wrote: > > > > On 18/08/2015 23:00, Dimitris Chloupis wrote: > > > 1) bringing more Python support for Pharo, > > now I have added support for python and > > blender types to be automagically converted > > to pharo objects . Used and learn SmaCC. > > > > 2) Gave a deep reading on Pharo auto > > completion. > > > > 3) Study how Playgrounds draws its GUI to > > improve it by making far more flexible. > > > > 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 > > > > > Blender ? > > This one: https://www.blender.org/features/ ? > > > > 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. > > > >

Aug. 19, 2015