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

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

by Merwan Ouddane

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 <mailto:sean@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. 18, 2015

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

by Dimitris Chloupis

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

Re: [Pharo-dev] Nautilus questions

by Dimitris Chloupis

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. > > > 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.) > > > â > 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. 18, 2015

Re: [Pharo-dev] World Menu associated mouse click

by Dimitris Chloupis

and what about the existing right click menu for selecting morphs ? On Tue, Aug 18, 2015 at 8:09 PM Ben Coman <btc(a)openinworld.com> wrote: > Opened issue with fix - https://pharo.fogbugz.com/default.asp?16265 > > On Wed, Aug 19, 2015 at 12:13 AM, Ben Coman <btc(a)openinworld.com> wrote: > >>>>> -----Message d'origine----- > >>>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la > part de > >>>>> Ben Coman > >>>>> A while back on reddit someone complained about the World Menu being > >>>>> associated with left-mouse-click. I have come to agree. The World > Menu > >>>>> provides the actions available in the context of the World, i.e. > >>>>> the World's context-menu - but its not invoked by the usual > convention > >>>>> for context menus, which is the right-mouse-click. > >>>>> > >>>>> By way of example, in a fresh image and open one Playground. > >>>>> > >>>>> * First right-click the Playground. Up comes the Playground's > >>>>> context-menu as expected per industry wide conventions. > >>>>> > >>>>> * Then right-click the background. Doh! Its not consistent, thats not > >>>>> the World's context-menu. "WTH is that?" says a newbie in surprise. > >>>>> (Btw, who uses that list of open windows ? I *never* do and might > >>>>> suggest that function be moved to a meta-mouse-click.) > >>>>> > >>>>> So can we discuss changing the World Menu to be invoked by the > >>>>> context-click (i.e. right-click) ? > >>>>> > >>>>> cheers -ben > >

Aug. 18, 2015

Nautilus questions

by Peter UhnÃ¡k

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. 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.) â 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. 18, 2015

Re: [Pharo-dev] Date&Time api

by Chris Cunningham

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 On Tue, Aug 18, 2015 at 1:21 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> 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 >

Aug. 18, 2015

Re: [Pharo-dev] World Menu associated mouse click

by Ben Coman

Opened issue with fix - https://pharo.fogbugz.com/default.asp?16265 On Wed, Aug 19, 2015 at 12:13 AM, Ben Coman <btc(a)openinworld.com> wrote: >>>>> -----Message d'origine----- >>>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >>>>> Ben Coman >>>>> A while back on reddit someone complained about the World Menu being >>>>> associated with left-mouse-click. I have come to agree. The World Menu >>>>> provides the actions available in the context of the World, i.e. >>>>> the World's context-menu - but its not invoked by the usual convention >>>>> for context menus, which is the right-mouse-click. >>>>> >>>>> By way of example, in a fresh image and open one Playground. >>>>> >>>>> * First right-click the Playground. Up comes the Playground's >>>>> context-menu as expected per industry wide conventions. >>>>> >>>>> * Then right-click the background. Doh! Its not consistent, thats not >>>>> the World's context-menu. "WTH is that?" says a newbie in surprise. >>>>> (Btw, who uses that list of open windows ? I *never* do and might >>>>> suggest that function be moved to a meta-mouse-click.) >>>>> >>>>> So can we discuss changing the World Menu to be invoked by the >>>>> context-click (i.e. right-click) ? >>>>> >>>>> cheers -ben

Aug. 18, 2015

Re: [Pharo-dev] SqueakNim - an FFI glue code tool

by Ben Coman

Sounds interesting. Thanks for the notice. cheers -ben On Tue, Aug 18, 2015 at 7:55 PM, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > (resend) > Hi fellow Smalltalkers! > > At 3DICC we are using Nim (http://nim-lang.org) to write our performance > critical code that typically otherwise would have been written in C/C++. But > now we have Nim :) > > Nim can generate dlls/so libraries following C conventions so they can > easily be called via FFI. > > Andreas Rumpf (author of Nim who works with us) wrote a small utility called > SqueakNim - its a set of Nim macros that generates the .st primitive calls > based on the Nim code, so it takes out some grunt work and matches up types > as far as it can. Simple, but very nice. > > The docs etc are a bit unpolished, but the trivial example in "tests" has > comments in it and it works in Squeak 5, Pharo 3, Pharo 4 and I guess in > most versions of Squeak/Pharo. > > Why would you be interested? > > - Nim is great fun! C/C++ is torture. Same performance, nuff said. > - Nim has a tool called c2nim that wraps C *and* C++ libraries. > > That last part is a killer. We use c2nim to wrap Urho3D - a huge C++ game > engine, works great, and that wrapper is also open source btw, Urhonimo. > > How do I use it? See README at: > > https://gitlab.3dicc.com/3dicc/squeaknim > > For some more information my article (predating this tool) might have some > details: > > http://goran.krampe.se/2014/11/03/squeak-to-nim > > ...and if you want to ask questions, hop onto freenode on either #squeak, > #pharo or #nim. Me and Andreas are around. > > regards, GÃ¶ran > >

Aug. 18, 2015

Re: [Pharo-dev] World Menu associated mouse click

by Ben Coman

>>>> -----Message d'origine----- >>>> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >>>> Ben Coman >>>> EnvoyÃ© : lundi 17 aoÃ»t 2015 15:52 >>>> Ã : Pharo Development List >>>> Objet : [Pharo-dev] World Menu associated mouse click >>>> >>>> A while back on reddit someone complained about the World Menu being >>>> associated with left-mouse-click. I have come to agree. The World Menu >>>> provides the actions available in the context of the World, i.e. >>>> the World's context-menu - but its not invoked by the usual convention >>>> for context menus, which is the right-mouse-click. >>>> >>>> By way of example, in a fresh image and open one Playground. >>>> >>>> * First right-click the Playground. Up comes the Playground's >>>> context-menu as expected per industry wide conventions. >>>> >>>> * Then right-click the background. Doh! Its not consistent, thats not >>>> the World's context-menu. "WTH is that?" says a newbie in surprise. >>>> (Btw, who uses that list of open windows ? I *never* do and might >>>> suggest that function be moved to a meta-mouse-click.) >>>> >>>> So can we discuss changing the World Menu to be invoked by the >>>> context-click (i.e. right-click) ? >>>> >>>> cheers -ben >>> 2015-08-17 16:07 GMT+02:00 Blondeau Vincent >>> <vincent.blondeau(a)worldline.com>: >>>> There is a setting to have this consistence (deactivated by default): >>>> Appearance>Desktop>Invert right click on world menu in Linux and Windows >>>> >>>> By the way, the buttons are not inverted under Mac (conventional). >>>> >>>> I agree that the context click should open the world menu by default.. >> On Mon, Aug 17, 2015 at 4:14 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> +1 > On Mon, Aug 17, 2015 at 7:19 PM Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> Btw in Bloc this has already been changed. > On Mon, Aug 17, 2015 at 9:15 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: >> If you are not ready to get out of your comfort zone , you wont be using >> Smalltalk. Sure change it to left click, but in the end it wont make much of >> a difference. Smalltalk is for a specific kind of people that are looking >> for a fresh approach to coding. For everyone else there is like a ton of >> languages that recycle old recipes and keep things familiar. On Tue, Aug 18, 2015 at 5:39 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > importantly there's difference between "keeping things familiar with the > universe (other OS/langs/...)" and "being internally consistent" (every > menu except for the world menu is opened with right/yellow button). On Tue, Aug 18, 2015 at 3:15 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > If you are not ready to get out of your comfort zone , you wont be using > Smalltalk. Sure change it to left click, but in the end it wont make much of > a difference. Smalltalk is for a specific kind of people that are looking > for a fresh approach to coding. For everyone else there is like a ton of > languages that recycle old recipes and keep things familiar. Of course I subscribe to the view of our uniqueness :) - but its not sufficient as the only argument. We should not be complacent to use that as a crutch to keep things the way they have always been because that is "our" comfort zone. cheers -ben

Aug. 18, 2015

Re: [Pharo-dev] Ctrl key on Windows

by Ben Coman

On Tue, Aug 18, 2015 at 5:28 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-08-17 21:16 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >> First, Thanks Nicolai :) >> >> I was testing the latest windows VM In my gf's machine to see the fix of >> Nicolai to the Ctrl+friends. >> >> For those who do not know, before, the windows (and unix, and mac too) VMs >> mapped some Ctrl+key combinations to another one simulating emacs/terminal >> shortcuts. For example: >> >> Ctrl+a => Ctrl home >> Ctrl+d => Ctrl end >> >> The problem of this, is that the image never received a Ctrl+a event, and >> thus, Ctrl+a and Ctrl+home were not distinguishable. >> >> Nicolai did a fix in the Windows VM for this and I'm glad to see that most >> of the keys that did not work before now work. I tested it by disabling the >> global shortcuts and using the following script: >> >> w := SystemWindow new. >> >> ($a to: $z) do: [ :k| >> w bindKeyCombination: k ctrl toAction: [ :a :b :c | UIManager default >> inform: c asString ]]. >> >> w addMorphBack: TextMorph new. >> w openInWorld. >> >> Using that I saw however that the Ctrl+m combination does not reach my >> handler and there are no global handlers for it. The event does however >> arrive to the image (checked using the InputEventFetcher). >> >> Then I have two questions for the world: >> >> - Does anyone have an idea of who may be catching the Ctrl+m? >> - What do we have to do to bless the latest Windows VM as stable? >> >> Guille > > > > Hi Guille, > > the problem with my fix for ctrl+a vs. ctrl+home is, that we do not get > ctrl+space keystrokes anymore :( > But I know how to fix this. > > The problem with ctrl+m is that it does not generate a keychar-Event, only > keyup and keydown (similar ctrl+<somenumber> or ctrl+tab), it is recognized > as a keyevent but only keychar-events are used as keystrokes. > > > Some info I searched up, somewhat enlightening... What's broken in the WM_KEYDOWN-WM_CHAR input model? http://www.ngedit.com/a_wm_keydown_wm_char.html MSDN > Accelerator Tables https://msdn.microsoft.com/en-us/library/windows/desktop/ms646335(v=vs.85).… https://msdn.microsoft.com/en-us/library/windows/desktop/ms646337(v=vs.85).… cheers -ben

Aug. 18, 2015