- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] History of the .image

by Hilaire

Le 04/10/2014 16:16, David T. Lewis a Ã©crit : > On Sat, Oct 04, 2014 at 04:00:15PM +0200, Hilaire wrote: >> Hello, >> >> I am curious. What is the history of the Pharo image? I know it is >> forked from Squeak, but then from where does come the Squeak image? >> How and when was it build from its source code definition? >> When did it became an "evolving organism" as it is today? >> >> Thanks >> >> Hilaire > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-September/17995… > > > > Thanks for the pointer. But my curiosity targets technical considerations. How and when was done the first image bootstrap, then at this moment was the image became the base of development, or was a kind of boostrap-image-build from source still done for some time. Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu

Oct. 5, 2014

Re: [Pharo-dev] Inspector steals my Window !

by Tudor Girba

Thanks! Doru On Sun, Oct 5, 2014 at 12:12 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > I made the preview tab only show a static picture of the morph and renamed > the title to Morph. Now it's like for Morph and Glamour. Still it seems > that clicking on a morph only works when inspecting Morph objects, and not > Spec or Glamour ones. > > On Sun, Oct 5, 2014 at 8:16 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> This is why the Preview should be static. For the Morph preview we simply >> render the form. >> >> Doru >> >> On Sun, Oct 5, 2014 at 12:32 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> Inspect in playground ("inspect it" from menu or with the play-icon): >>> >>> |t| >>> t:=TextModel new. >>> t title:'Test'. >>> t openWithSpec >>> >>> It opens a window with the textfield and an inspector. >>> In the inspector, choose the "preview" tab, your textfield window >>> will dissapear from the world and only show up in the preview tab. >>> >>> Funny! >>> But is there any way to get the window back to the world? >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-dev] Inspector steals my Window !

by Andrei Chis

I made the preview tab only show a static picture of the morph and renamed the title to Morph. Now it's like for Morph and Glamour. Still it seems that clicking on a morph only works when inspecting Morph objects, and not Spec or Glamour ones. On Sun, Oct 5, 2014 at 8:16 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > This is why the Preview should be static. For the Morph preview we simply > render the form. > > Doru > > On Sun, Oct 5, 2014 at 12:32 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Inspect in playground ("inspect it" from menu or with the play-icon): >> >> |t| >> t:=TextModel new. >> t title:'Test'. >> t openWithSpec >> >> It opens a window with the textfield and an inspector. >> In the inspector, choose the "preview" tab, your textfield window >> will dissapear from the world and only show up in the preview tab. >> >> Funny! >> But is there any way to get the window back to the world? >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 5, 2014

Re: [Pharo-dev] "Browser" on a single class

by Sven Van Caekenberghe

Nice ;-) On 05 Oct 2014, at 11:56, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > lazy Yury > > > browser := GLMTabulator new > row: [ :row | > row > column: #protocols; > column: #methods ]; > row: #code; > yourself. > > browser transmit > to: #protocols; > andShow: [ :a| > a list > allowDropOnItem: [:draggedObject :targetItem :list | true ]; > dropOnItem: [:draggedObject :targetItem :list | > browser entity organization > classify: draggedObject > under: targetItem name. > list update. > true ]; > display: [ :class | class organization protocols ]; format: #name ]. > browser transmit > from: #protocols; > to: #methods; > andShow: [ :a| > a list > allowItemDrag: [:item :list | true ]; > display: [ :protocol | protocol methods ] ]. > browser transmit > from: #methods; > to: #code; > andShow: [ :a | > a smalltalkCode > smalltalkClass: [ browser entity ]; > display: [ :method | (browser entity>>method) sourceCode ] ]. > > browser openOn: Morph > >> On 05 Oct 2014, at 10:08, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Yes, but as Iâve mentioned earlier, Iâm interested in drag-n-drop recategorization. I donât know if itâs doable with glamour. >> >> Uko >> >>> On 04 Oct 2014, at 15:58, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> and this is same with glamour: >>> >>> browser := GLMTabulator new >>> row: [ :row | >>> row >>> column: #protocols; >>> column: #methods ]; >>> row: #code; >>> yourself. >>> >>> browser transmit >>> to: #protocols; >>> andShow: [ :a| a list display: [ :class | class organization protocols ]; format: #name ]. >>> browser transmit >>> from: #protocols; >>> to: #methods; >>> andShow: [ :a| a list display: [ :protocol | protocol methods ] ]. >>> browser transmit >>> from: #methods; >>> to: #code; >>> andShow: [ :a | >>> a smalltalkCode >>> smalltalkClass: [ browser entity ]; >>> display: [ :method | (browser entity>>method) sourceCode ] ]. >>> >>> browser openOn: Morph. >>> >>> Of course spec is capable of doing that. >>> But glamour is designed with transitions and scripting in mind (thinking specially on browsers), while spec is designed for components and composition. >>> >>> Esteban >>> >>>> On 04 Oct 2014, at 15:35, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>> >>>> >>>> 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>> >>>>> On 03 Oct 2014, at 13:14, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>>> >>>>> >>>>> Am 03.10.2014 12:34 schrieb "Yuriy Tymchuk" <yuriy.tymchuk(a)me.com>: >>>>> > >>>>> > Hi. >>>>> > >>>>> > I want to make something like a browser on a single class. I.e. just use 2 last lists out if 4 in standard browser. >>>>> > >>>>> > Is there already something like that? If not, should I use existing widgets, or implement my own using spec? >>>>> > >>>>> > Cheers! >>>>> > Uko >>>>> > >>>>> > Sent from my iPhone >>>>> >>>>> I think that is pretty easy with some spec models. >>>>> Maybe there is already an example >>>>> >>>> yes, but a few models means a few classes :) >>>> in a single class, it will e a lot easier glamour (which btw, is specially designed for that: to make browsers). >>>> >>>> You can work with ready made models like ListModel/TextModel and just need one class for sticking them >>>> together. Here some code, evaluateable from workspace, that shows how we >>>> can build a "simple browser" with spec models: >>>> This is just the simple skeleton, for more details it would be a bit confusing doing all this >>>> in one workspace "script" :) >>>> >>>> class:=Morph. >>>> method:=class>>#openInWorld. >>>> >>>> composed:= DynamicComposableModel new. >>>> composed instantiateModels: #(code TextModel protocols ListModel methods ListModel). >>>> composed code text:method sourceCode. >>>> composed protocols items: class protocols. >>>> composed methods items: class selectors. >>>> composed code aboutToStyle:true. >>>> composed code behavior:class. >>>> composed title: class asString. >>>> composed code acceptBlock:[:text | >>>> class compile:text notifying:nil. >>>> ]. >>>> composed protocols whenSelectedItemChanged:[:item | >>>> composed methods items:( class selectorsInProtocol: item) >>>> ]. >>>> composed methods whenSelectedItemChanged:[:item | >>>> item ifNotNil:[ >>>> method:=class methodDict at:item. >>>> composed code text:method sourceCode] >>>> ]. >>>> composed openWithSpecLayout:( >>>> SpecLayout composed >>>> newColumn:[:c | c >>>> newRow:[:r | r >>>> add: #protocols; >>>> add: #methods >>>> ]; >>>> add: #code]; >>>> yourself). >>>> >>>> >>>> Esteban >>>>> Hilaire asked for a simple Method editor and >>>>> i wrote a simple example build with DynamicComposableModel, search the Mailingliste. >>>>> >>> >> >

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by kilon alios

If I was coding God that was able to code at coding speed 120WPM (Words Per Minute) then yes I would not even consider using anything but shortcuts but my speed is more like 120 WPH (Words Per Hour) which is more like 20 lines of code and that is a very optimistic scenario. So I find myself in many cases just right clicking , why ? a) Because using menus does not bother me too much even if it is a bit slow to using a shortcut and b) In many cases I tend to forget shortcuts I dont use 24/7. Of course not copy and paste. I tried to make my brain fit into the emacs/vim mentality of only using shortcuts but I keep forgetting stuff or being lazy to go back to documentation to remember when I can just right click and find what I want. Plus right clicking has another advantage it shows you the right shortcut next to the menu option. So for me right click menus and other menus are beginner and lazy friendly. On Sun, Oct 5, 2014 at 10:53 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Esteban, > > I know it's a usability principle, but usability should also take into > account culture. Programmers are not every-day users, and the assumptions > we take should adapt to their needs. This is why it is worth exploring what > might or might not be needed. > > I cannot believe that programmers do not know the shortcuts, but I did not > consider the case in which people go through multiple virtual boxes to get > to the image. This is a legitimate issue, so these actions are back. > > Cheers, > Doru > > > On Sun, Oct 5, 2014 at 9:36 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> On 04 Oct 2014, at 22:43, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi HernÃ¡n, >> >> Thanks for the feedback. Just a question: Was there anything you do like? >> :) >> >> The rest of the reply is inline. >> >> >> On Sat, Oct 4, 2014 at 10:10 PM, HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com> wrote: >> >>> Sorry if following issues were reported. I have seen so many mails about >>> GT that I wanted to try it. These are my first notes and personal tastes, >>> don't take them as negative just want to provide some feedback: >>> >>> - First weird thing: The Workspace doesn't open a Workspace anymore, it >>> opens a Playground window. >>> >> >> That is because it is still a work in progress. >> >> >>> - When I select code, right click gives no "Copy, Cut, Delete" commands. >>> >> >> This was reported. The menu is missing on purpose. I still have a hard >> time understanding why a developer needs those menu entries, but we will >> add them back. Btw, the shortcuts do work. >> >> >> Is an usability principle: A system should provide visual feedback about >> what happens and about what it can do. >> How can we know what can or cannot do the playground? >> But of course, using menus as documentation is not always a good idea, >> soâ¦ we need to find a balance here :) >> I always use OSX design guidelines as a base on what I want to do (not >> that we should take it literally, but is always good to see what others >> with time to invest have to say). >> And this is all what they say about menus: >> https://developer.apple.com/library/mac/documentation/userexperience/concep… >> >> Esteban >> >> >> >>> - Selecting an instance variable from the "State" tab, completely shift >>> the code view and scrolls to a new Inspector. Is not that I would love to >>> scroll back everytime to get a view on my code. >>> >> >> The usage depends on the scenario in which you are. In most cases, when >> you do want to drill through many objects, you are likely to only use the >> playground as an entry point. When you build a more elaborate piece of code >> in the playground, you typically do not need to drill too much. In any >> case, if you want to scroll back, there are also keybindings that allow you >> to navigate: Cmd+Alt+Left/Right. >> >> >>> - I cannot find how to close new Inspector tabs. >>> >> >> This is a feature that is already planned. >> >> >>> - "Print it" seems broken. It seems to print evaluation result but >>> suddenly dissapears. >>> >> >> What do you mean? Can you elaborate on that? Print it should behave like >> here: >> >> >>> - Debugger buttons Into, Through, etc. >>> >> -- They are too small and close themselves for the importance they have. >>> -- They have no caption, so you have to mouse over to know what they do >>> (until you get used to) >>> -- They are like "too distant" from the code view. >>> >> >> The debugger is not in the Pharo image, so I think you are trying the >> Moose image. Is that so? >> In any case, the positioning of the icons will be the same everywhere in >> GT (to the right of the scope they relate to). We are still fiddling with >> the right balance in the debugger. >> >> Cheers, >> Doru >> >> >> >>> Cheers, >>> >>> HernÃ¡n >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Oct. 5, 2014

Re: [Pharo-dev] "Browser" on a single class

by Esteban Lorenzano

lazy Yury browser := GLMTabulator new row: [ :row | row column: #protocols; column: #methods ]; row: #code; yourself. browser transmit to: #protocols; andShow: [ :a| a list allowDropOnItem: [:draggedObject :targetItem :list | true ]; dropOnItem: [:draggedObject :targetItem :list | browser entity organization classify: draggedObject under: targetItem name. list update. true ]; display: [ :class | class organization protocols ]; format: #name ]. browser transmit from: #protocols; to: #methods; andShow: [ :a| a list allowItemDrag: [:item :list | true ]; display: [ :protocol | protocol methods ] ]. browser transmit from: #methods; to: #code; andShow: [ :a | a smalltalkCode smalltalkClass: [ browser entity ]; display: [ :method | (browser entity>>method) sourceCode ] ]. browser openOn: Morph > On 05 Oct 2014, at 10:08, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Yes, but as Iâve mentioned earlier, Iâm interested in drag-n-drop recategorization. I donât know if itâs doable with glamour. > > Uko > >> On 04 Oct 2014, at 15:58, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> and this is same with glamour: >> >> browser := GLMTabulator new >> row: [ :row | >> row >> column: #protocols; >> column: #methods ]; >> row: #code; >> yourself. >> >> browser transmit >> to: #protocols; >> andShow: [ :a| a list display: [ :class | class organization protocols ]; format: #name ]. >> browser transmit >> from: #protocols; >> to: #methods; >> andShow: [ :a| a list display: [ :protocol | protocol methods ] ]. >> browser transmit >> from: #methods; >> to: #code; >> andShow: [ :a | >> a smalltalkCode >> smalltalkClass: [ browser entity ]; >> display: [ :method | (browser entity>>method) sourceCode ] ]. >> >> browser openOn: Morph. >> >> Of course spec is capable of doing that. >> But glamour is designed with transitions and scripting in mind (thinking specially on browsers), while spec is designed for components and composition. >> >> Esteban >> >>> On 04 Oct 2014, at 15:35, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >>> >>> >>> 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >>> >>>> On 03 Oct 2014, at 13:14, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >>>> >>>> >>>> Am 03.10.2014 12:34 schrieb "Yuriy Tymchuk" <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >>>> > >>>> > Hi. >>>> > >>>> > I want to make something like a browser on a single class. I.e. just use 2 last lists out if 4 in standard browser. >>>> > >>>> > Is there already something like that? If not, should I use existing widgets, or implement my own using spec? >>>> > >>>> > Cheers! >>>> > Uko >>>> > >>>> > Sent from my iPhone >>>> >>>> I think that is pretty easy with some spec models. >>>> Maybe there is already an example >>>> >>> yes, but a few models means a few classes :) >>> in a single class, it will e a lot easier glamour (which btw, is specially designed for that: to make browsers). >>> >>> You can work with ready made models like ListModel/TextModel and just need one class for sticking them >>> together. Here some code, evaluateable from workspace, that shows how we >>> can build a "simple browser" with spec models: >>> This is just the simple skeleton, for more details it would be a bit confusing doing all this >>> in one workspace "script" :) >>> >>> class:=Morph. >>> method:=class>>#openInWorld. >>> >>> composed:= DynamicComposableModel new. >>> composed instantiateModels: #(code TextModel protocols ListModel methods ListModel). >>> composed code text:method sourceCode. >>> composed protocols items: class protocols. >>> composed methods items: class selectors. >>> composed code aboutToStyle:true. >>> composed code behavior:class. >>> composed title: class asString. >>> composed code acceptBlock:[:text | >>> class compile:text notifying:nil. >>> ]. >>> composed protocols whenSelectedItemChanged:[:item | >>> composed methods items:( class selectorsInProtocol: item) >>> ]. >>> composed methods whenSelectedItemChanged:[:item | >>> item ifNotNil:[ >>> method:=class methodDict at:item. >>> composed code text:method sourceCode] >>> ]. >>> composed openWithSpecLayout:( >>> SpecLayout composed >>> newColumn:[:c | c >>> newRow:[:r | r >>> add: #protocols; >>> add: #methods >>> ]; >>> add: #code]; >>> yourself). >>> >>> >>> Esteban >>>> Hilaire asked for a simple Method editor and >>>> i wrote a simple example build with DynamicComposableModel, search the Mailingliste. >>>> >> >

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by Esteban Lorenzano

> On 05 Oct 2014, at 10:39, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > On Sun, Oct 5, 2014 at 10:04 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > >> On 05 Oct 2014, at 09:55, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi, >> >> On Sun, Oct 5, 2014 at 9:40 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >>> On 05 Oct 2014, at 08:43, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> >>> >>> On 4/10/14 22:43, Tudor Girba wrote: >>>> Hi HernÃ¡n, >>>> >>>> Thanks for the feedback. Just a question: Was there anything you do like? :) >>>> >>>> The rest of the reply is inline. >>>> >>>> >>>> On Sat, Oct 4, 2014 at 10:10 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: >>>> Sorry if following issues were reported. I have seen so many mails about GT that I wanted to try it. These are my first notes and personal tastes, don't take them as negative just want to provide some feedback: >>>> >>>> - First weird thing: The Workspace doesn't open a Workspace anymore, it opens a Playground window. >>>> >>>> That is because it is still a work in progress. >>>> >>>> - When I select code, right click gives no "Copy, Cut, Delete" commands. >>>> >>>> This was reported. The menu is missing on purpose. I still have a hard time understanding why a developer needs those menu entries, but we will add them back. Btw, the shortcuts do work. >>> >>> Doru can you add sender and implementors >>> because I saw that newbies are really lost when the cannot know what they can do. >> >> and âbrowseâ. >> In factâ¦ I want almost all the âextended searchâ backâ¦ please, please, please. >> >> It's back. But, this time as a real submenu, not like the hack we had before in the Workspace (a menu was spawning another menu). Funny enough, nobody complained about that one. It's good to shake the tree :). >> >>>> - Selecting an instance variable from the "State" tab, completely shift the code view and scrolls to a new Inspector. Is not that I would love to scroll back everytime to get a view on my code. >>>> >>>> The usage depends on the scenario in which you are. In most cases, when you do want to drill through many objects, you are likely to only use the playground as an entry point. When you build a more elaborate piece of code in the playground, you typically do not need to drill too much. In any case, if you want to scroll back, there are also keybindings that allow you to navigate: Cmd+Alt+Left/Right. >>>> >>>> - I cannot find how to close new Inspector tabs. >>>> >>>> This is a feature that is already planned. >>>> >>>> - "Print it" seems broken. It seems to print evaluation result but suddenly dissapears. >>>> >>>> What do you mean? Can you elaborate on that? Print it should behave like here: >>>> >>>> - Debugger buttons Into, Through, etc. >>>> -- They are too small and close themselves for the importance they have. >>>> -- They have no caption, so you have to mouse over to know what they do (until you get used to) >>>> -- They are like "too distant" from the code view. >>>> >>>> The debugger is not in the Pharo image, so I think you are trying the Moose image. Is that so? >>>> In any case, the positioning of the icons will be the same everywhere in GT (to the right of the scope they relate to). We are still fiddling with the right balance in the debugger. >>> putting a caption would be a great point. >>> why forcing people to learn icons. Icons should be there to help not to force learning. >> >> Iâm planning to make Doru hate me by replacing all those icons by âthemableâ icons and of course, using eclipse icons for all that actions ;) >> >> All the visual aspects from GT and Glamour should get themeable (not all of them are at this point). I will certainly not complain if you help there :). >> >> As for the icons, I think Pharo deserves a Pharo look, not an Eclipse one. So, you can certainly use the Eclipse icons, but I will try to propose a complete set of Pharo icons. > > of course, is better if we have our own. > problem is that a complete set is hard to do, with the appropriate quality, etc. > If you do it, I will be super happy (with Nico we started a set of icons both for Pharo and Amberâ¦ and my contribution there was just to ask Nico âis there something new todayâ, because I frankly suck at design :P) > > When I asked for help, I was more thinking of getting the icons be themeable at the code level - delegate to a themer object :) yeah, I started. Real problem is that I became very ambitious with that (or at least: more ambitious than: lets make this work and think later), so I will take a bit more of time :P Esteban > > Cheers, > Doru > > > > Esteban > >> >> Cheers, >> Doru >> >> >> >> Esteban >> >> >>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> Cheers, >>>> >>>> HernÃ¡n >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com <http://www.tudorgirba.com/> >>>> >>>> "Every thing has its own flow" >>> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by Tudor Girba

Hi, On Sun, Oct 5, 2014 at 10:04 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 05 Oct 2014, at 09:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > On Sun, Oct 5, 2014 at 9:40 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> On 05 Oct 2014, at 08:43, stepharo <stepharo(a)free.fr> wrote: >> >> >> On 4/10/14 22:43, Tudor Girba wrote: >> >> Hi HernÃ¡n, >> >> Thanks for the feedback. Just a question: Was there anything you do like? >> :) >> >> The rest of the reply is inline. >> >> >> On Sat, Oct 4, 2014 at 10:10 PM, HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com> wrote: >> >>> Sorry if following issues were reported. I have seen so many mails about >>> GT that I wanted to try it. These are my first notes and personal tastes, >>> don't take them as negative just want to provide some feedback: >>> >>> - First weird thing: The Workspace doesn't open a Workspace anymore, it >>> opens a Playground window. >>> >> >> That is because it is still a work in progress. >> >> >>> - When I select code, right click gives no "Copy, Cut, Delete" commands. >>> >> >> This was reported. The menu is missing on purpose. I still have a hard >> time understanding why a developer needs those menu entries, but we will >> add them back. Btw, the shortcuts do work. >> >> >> Doru can you add sender and implementors >> because I saw that newbies are really lost when the cannot know what they >> can do. >> >> >> and âbrowseâ. >> In factâ¦ I want almost all the âextended searchâ backâ¦ please, please, >> please. >> > > It's back. But, this time as a real submenu, not like the hack we had > before in the Workspace (a menu was spawning another menu). Funny enough, > nobody complained about that one. It's good to shake the tree :). > > >> - Selecting an instance variable from the "State" tab, completely shift >>> the code view and scrolls to a new Inspector. Is not that I would love to >>> scroll back everytime to get a view on my code. >>> >> >> The usage depends on the scenario in which you are. In most cases, when >> you do want to drill through many objects, you are likely to only use the >> playground as an entry point. When you build a more elaborate piece of code >> in the playground, you typically do not need to drill too much. In any >> case, if you want to scroll back, there are also keybindings that allow you >> to navigate: Cmd+Alt+Left/Right. >> >> >>> - I cannot find how to close new Inspector tabs. >>> >> >> This is a feature that is already planned. >> >> >>> - "Print it" seems broken. It seems to print evaluation result but >>> suddenly dissapears. >>> >> >> What do you mean? Can you elaborate on that? Print it should behave like >> here: >> >> >>> - Debugger buttons Into, Through, etc. >>> >> -- They are too small and close themselves for the importance they have. >>> -- They have no caption, so you have to mouse over to know what they do >>> (until you get used to) >>> -- They are like "too distant" from the code view. >>> >> >> The debugger is not in the Pharo image, so I think you are trying the >> Moose image. Is that so? >> In any case, the positioning of the icons will be the same everywhere in >> GT (to the right of the scope they relate to). We are still fiddling with >> the right balance in the debugger. >> >> putting a caption would be a great point. >> why forcing people to learn icons. Icons should be there to help not to >> force learning. >> >> >> Iâm planning to make Doru hate me by replacing all those icons by >> âthemableâ icons and of course, using eclipse icons for all that actions ;) >> > > All the visual aspects from GT and Glamour should get themeable (not all > of them are at this point). I will certainly not complain if you help there > :). > > As for the icons, I think Pharo deserves a Pharo look, not an Eclipse one. > So, you can certainly use the Eclipse icons, but I will try to propose a > complete set of Pharo icons. > > > of course, is better if we have our own. > problem is that a complete set is hard to do, with the appropriate > quality, etc. > If you do it, I will be super happy (with Nico we started a set of icons > both for Pharo and Amberâ¦ and my contribution there was just to ask Nico > âis there something new todayâ, because I frankly suck at design :P) > When I asked for help, I was more thinking of getting the icons be themeable at the code level - delegate to a themer object :) Cheers, Doru > Esteban > > > Cheers, > Doru > > > > >> Esteban >> >> >> >> >> Cheers, >> Doru >> >> >> >>> Cheers, >>> >>> HernÃ¡n >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 5, 2014

Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

by Johan Brichau

Itâs true that when you do a lot of cross-dialect development, such a method is often what you desire. However, I think itâs better to do feature detection instead of dialect detection. So, something like: ((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[ stream := CharacterWriteStream on: (String new: 10) ] ifFalse:[ stream := WriteStream on: (String new: 10) ] And yes: use Grease where applicable. We try to maintain Grease across Pharo, Squeak and Gemstone. I also think itâs actively ported to VA. cheers Johan On 05 Oct 2014, at 09:00, stepharo <stepharo(a)free.fr> wrote: > Hi jan > > Thanks for the proposal. > I thought about it and I'm against because it goes again the idea of dispatch. > I prefer to have a class and some dispatch. Seaside with Grease is the way to go from my perspective. > Finally I do not want such methods in the systems because I spent my time removing isXXXX because of bad design. > Let us see what other people think. > > Stef > > On 4/10/14 22:14, Jan Vrany wrote: >> Hi guys, >> >> I've just opened: >> >> https://pharo.fogbugz.com/f/cases/14160/Introduce-isXXX-dialect-testing-met… >> >> Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to >> SmalltalkImage to ease multi-dialect development. >> >> RATIONALE: >> >> Commonly used approach to solve differences among dialect is to use a >> sort of platform object and dispatch there for troublesome operations >> that has to be specialized. This platform object is usually in platform >> specific package. >> Other option is to load some library like Grease or Sport. >> >> The problem of the first approach is that brings to much (unnecessary) >> burden when used for two, three things. The amount of of the code and >> management is way to bigger then the amount of the code that has to be >> specialized. Loading Grease/Sport on the other hand introduces a >> dependency on an external package - not worth of for two or three >> things. >> >> The proposed dialect testing messages would allow for simple, >> #ifdef-like idiom like: >> >> | stream | >> ... >> ((Smalltalk respondsTo: #isSomeCoolDialect) and:[Smalltalk >> isSomeCoolDialect]) ifTrue:[ >> stream := CharacterWriteStream on: (String new: 10) >> ] ifFalse:[ >> stream := WriteStream on: (String new: 10) >> ] >> >> The #respondsTo: check, while not nice, is required as at the moment not >> all dialects could be trusted to have these testing messages. >> >> Putting these methods may not stick with Pharo standard (whatever it >> is), but Smalltalk global is probably one of the >> very few that are present in pretty much every Smalltalk implementation. >> Other option would be to place them to the class side of an Object >> (which is amost certainly present everywhere), however >> >> Smalltalk isPharo >> >> reads better than >> >> Object isPharo. >> >> Best, Jan >> >> >> > >

Oct. 5, 2014

Re: [Pharo-dev] "Browser" on a single class

by Yuriy Tymchuk

Yes, but as Iâve mentioned earlier, Iâm interested in drag-n-drop recategorization. I donât know if itâs doable with glamour. Uko > On 04 Oct 2014, at 15:58, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > and this is same with glamour: > > browser := GLMTabulator new > row: [ :row | > row > column: #protocols; > column: #methods ]; > row: #code; > yourself. > > browser transmit > to: #protocols; > andShow: [ :a| a list display: [ :class | class organization protocols ]; format: #name ]. > browser transmit > from: #protocols; > to: #methods; > andShow: [ :a| a list display: [ :protocol | protocol methods ] ]. > browser transmit > from: #methods; > to: #code; > andShow: [ :a | > a smalltalkCode > smalltalkClass: [ browser entity ]; > display: [ :method | (browser entity>>method) sourceCode ] ]. > > browser openOn: Morph. > > Of course spec is capable of doing that. > But glamour is designed with transitions and scripting in mind (thinking specially on browsers), while spec is designed for components and composition. > > Esteban > >> On 04 Oct 2014, at 15:35, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> >> 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> >>> On 03 Oct 2014, at 13:14, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >>> >>> >>> Am 03.10.2014 12:34 schrieb "Yuriy Tymchuk" <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>>: >>> > >>> > Hi. >>> > >>> > I want to make something like a browser on a single class. I.e. just use 2 last lists out if 4 in standard browser. >>> > >>> > Is there already something like that? If not, should I use existing widgets, or implement my own using spec? >>> > >>> > Cheers! >>> > Uko >>> > >>> > Sent from my iPhone >>> >>> I think that is pretty easy with some spec models. >>> Maybe there is already an example >>> >> yes, but a few models means a few classes :) >> in a single class, it will e a lot easier glamour (which btw, is specially designed for that: to make browsers). >> >> You can work with ready made models like ListModel/TextModel and just need one class for sticking them >> together. Here some code, evaluateable from workspace, that shows how we >> can build a "simple browser" with spec models: >> This is just the simple skeleton, for more details it would be a bit confusing doing all this >> in one workspace "script" :) >> >> class:=Morph. >> method:=class>>#openInWorld. >> >> composed:= DynamicComposableModel new. >> composed instantiateModels: #(code TextModel protocols ListModel methods ListModel). >> composed code text:method sourceCode. >> composed protocols items: class protocols. >> composed methods items: class selectors. >> composed code aboutToStyle:true. >> composed code behavior:class. >> composed title: class asString. >> composed code acceptBlock:[:text | >> class compile:text notifying:nil. >> ]. >> composed protocols whenSelectedItemChanged:[:item | >> composed methods items:( class selectorsInProtocol: item) >> ]. >> composed methods whenSelectedItemChanged:[:item | >> item ifNotNil:[ >> method:=class methodDict at:item. >> composed code text:method sourceCode] >> ]. >> composed openWithSpecLayout:( >> SpecLayout composed >> newColumn:[:c | c >> newRow:[:r | r >> add: #protocols; >> add: #methods >> ]; >> add: #code]; >> yourself). >> >> >> Esteban >>> Hilaire asked for a simple Method editor and >>> i wrote a simple example build with DynamicComposableModel, search the Mailingliste. >>> >

Oct. 5, 2014