October 2014 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] GT first impressions

by Esteban Lorenzano

> 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 <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) 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"

Oct. 5, 2014

Re: [Pharo-dev] Athens and TxText Re: About ways to participate in community and general negativity

by Tudor Girba

Thank you! Doru On Sun, Oct 5, 2014 at 8:44 AM, stepharo <stepharo(a)free.fr> wrote: > Thanks this is a great initiative. > > > > On 4/10/14 22:21, Nicolai Hess wrote: > > > 2014-10-04 12:11 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> >> What are the plans to integrate TxText? >>> >> >> - Igor is taking clients one by one and improving txText. We got a >> new syntax hilighter. >> - Then I want to replace the workspace by a TxWorkspace. >> - After for athens we should rewrite all the drawOn: methods. >> - We were waiting to get integration based on configurations to >> include it and now this is ready. >> so soon we will have >> - TxText inside Pharo >> - >> > > > I made a fogbugz issue about changes to be done for > athens based morphic drawing > > 13790 <https://pharo.fogbugz.com/default.asp?13790> > Port what is needed for Athens (drawing morphs) > > One is about TextMorphs, I wrote about what I had to change to make > the basic drawing working. Maybe some of it is useless with TxText > but maybe it helps. > > 13449 <https://pharo.fogbugz.com/default.asp?13449> > AthensWrapMorph can not draw TextMorphs > > If we don't port/rewrite all text based morphs, we will have an > issue with this: > > 13448 <https://pharo.fogbugz.com/default.asp?13448> > No Font emphasis (bold/oblique...) on text drawn with Athens > > > AFAIK for the font handling in text morphs, they use the "normal" font > and holds the emphasis property on their own. But Athens (FreeType > renderer) > relies on the font allone, that means if you want a bold font you don't > take > the normal font *name* + bold emphasis, but you'll have to take the > "bold font" FreeType font entry, or something like that. > > About changing all the drawOn: methods for athens, there is > an alternative I proposed in > 13866 <https://pharo.fogbugz.com/default.asp?13866> > AthensFormCanvasWrapper > > Font rendering bug: > The font-bug for FreeType fonts (wrong sized characters) in Athens is not > solved. > (see screenshot) > The current solution is: "Don't use the same font (+font size) for > Athens and > Morphic". ( > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-June/097128… > ) > But of course, how can we enforce this? > > > > >> >>> >>> Now I know that GTools have been used in Moose for a long time, but its >>> integration to Pharo REPLACING Workspace has been a cultural shock to those >>> that haven't used it before (myself included, though I'm lookign forward to >>> adapting). I think there'll be similar culture shock when Pharo 4 is >>> released, from those that don't follow the bleeding edge. I'd strongly >>> suggest that GTools operate for ONE release alongside existing tools, as an >>> additional item in the first level World menu next to 'Workspace'. >>> >> I said the same to doru :). >> >> >> Indeed, even if Playground is quite stable through long use in Moose, it >>> is new to Pharo, and marking its menu entry as 'Experimental' for now might >>> provide some benefits. >>> >>> * This may provide a to stress test new evolving frameworks like TxText >>> & Rubric - without affecting existing tools. >>> >>> * Now Playground has a wider community exposure, feedback from new users >>> is likely to be less pressure and less negative if they still have access >>> to old tools. >>> >>> * Feedback may result in changes. >>> >>> * Reduced culture shock. Builds confidence in a stable system not going >>> "too fast" but just "fast enough" (very subjective I know). >>> >>> >> >> > > -- 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 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. 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"

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by Tudor Girba

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] GT first impressions

by Tudor Girba

Hi, On Sun, Oct 5, 2014 at 8:43 AM, 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. > It's done :). It took a while because we had to find a suitable code design, but now Andrei came up with an elegant solution that does not force us to duplicate code between the presentation, renderer and the text editor. - 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. > The problem is that they would take too much space. This is especially problematic when you have multiple extra actions (remember that this is extensible). We have to come up with a different solution somehow, but we need a bit more time. Cheers, Doru > > > 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] GT first impressions

by Esteban Lorenzano

> 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 <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. > >> >> - 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 ;) Esteban > >> >> Cheers, >> Doru >> >> >> Cheers, >> >> HernÃ¡n >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" >

Oct. 5, 2014

Re: [Pharo-dev] GT first impressions

by Esteban Lorenzano

> 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 <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. 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… <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 <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Oct. 5, 2014