Re: [Pharo-dev] GT first impressions
Oh, I see now. Where was the fix committed? Doru On Sun, Oct 5, 2014 at 12:02 AM, Nicolai Hess nicolaih...@web.de wrote: 2014-10-04 23:13 GMT+02:00 Tudor Girba tu...@tudorgirba.com: Hi, On Sat, Oct 4, 2014 at 11:02 PM, Hernán Morales Durand hernan.mora...@gmail.com wrote: Hi Doru 2014-10-04 17:43 GMT-03:00 Tudor Girba tu...@tudorgirba.com: Hi Hernán, Thanks for the feedback. Just a question: Was there anything you do like? :) One day I will write about what I like, I promise! Good :) [...] - 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. In my case, because sometimes I do remote desktop over remote desktop over Windows and Linux, and protocols use to lost dead keys like Ctrl, Shift, etc. Ok. That makes sense. Andrei added these actions in the latest development version. Loading again like you said below should provide you those actions. [...] - 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: I just typed DateAndTime now asTime. and Print it displays current date and time but get quickly refreshed. This happens only the first time, print it again didn't show any results at all. Let me know if you cannot reproduce, below is how I installed GT. I cannot reproduce it. Print it should popup the result and the popup should remain until you either press Esc or you change focus to something else. This happens on choosing PrintIt from the menu. There is an issue on fogbugz 14128 https://pharo.fogbugz.com/default.asp?14128 Print it from Playground menu does not work already fixed an integrated in 40276 It should look like this: http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo/ - 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? I am trying in a fresh Pharo 3.0 image on Windows 8.1, and followed instructions in http://www.humane-assessment.com/blog/installing-gtoolkit .BTW when the installation finish the image seems to automatically closes, but this is reported in other recent post. Indeed, the script should have mention activateWithoutSaving instead of activate. Cheers, Doru -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Inspector steals my Window !
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 nicolaih...@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
Re: [Pharo-dev] GT first impressions
On 4/10/14 22:10, Hernán Morales Durand 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. - When I select code, right click gives no Copy, Cut, Delete commands. - 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. - I cannot find how to close new Inspector tabs. - Print it seems broken. It seems to print evaluation result but suddenly dissapears. - 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. I already reported most of them on the moose mailing-list :) Tx! Cheers, Hernán
Re: [Pharo-dev] GT first impressions
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.mora...@gmail.com mailto:hernan.mora...@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. - 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. Cheers, Doru Cheers, Hernán -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Athens and TxText Re: About ways to participate in community and general negativity
Thanks this is a great initiative. On 4/10/14 22:21, Nicolai Hess wrote: 2014-10-04 12:11 GMT+02:00 stepharo steph...@free.fr mailto:steph...@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.html) 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).
Re: [Pharo-dev] GT first impressions
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 esteba...@gmail.com wrote: On 04 Oct 2014, at 22:43, Tudor Girba tu...@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.mora...@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/conceptual/applehiguidelines/Menus/Menus.html 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
Re: [Pharo-dev] GT first impressions
On 05 Oct 2014, at 09:55, Tudor Girba tu...@tudorgirba.com wrote: Hi, On Sun, Oct 5, 2014 at 9:40 AM, Esteban Lorenzano esteba...@gmail.com mailto:esteba...@gmail.com wrote: On 05 Oct 2014, at 08:43, stepharo steph...@free.fr mailto:steph...@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.mora...@gmail.com mailto:hernan.mora...@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
Re: [Pharo-dev] Browser on a single class
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 esteba...@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 entitymethod) 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 nicolaih...@web.de mailto:nicolaih...@web.de wrote: 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano esteba...@gmail.com mailto:esteba...@gmail.com: On 03 Oct 2014, at 13:14, Nicolai Hess nicolaih...@web.de mailto:nicolaih...@web.de wrote: Am 03.10.2014 12:34 schrieb Yuriy Tymchuk yuriy.tymc...@me.com mailto:yuriy.tymc...@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.
Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development
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 steph...@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 is 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-methods-to-SmalltalkImage-to-ease-cross-dialect-development 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
Re: [Pharo-dev] GT first impressions
Hi, On Sun, Oct 5, 2014 at 10:04 AM, Esteban Lorenzano esteba...@gmail.com wrote: On 05 Oct 2014, at 09:55, Tudor Girba tu...@tudorgirba.com wrote: Hi, On Sun, Oct 5, 2014 at 9:40 AM, Esteban Lorenzano esteba...@gmail.com wrote: On 05 Oct 2014, at 08:43, stepharo steph...@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.mora...@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
Re: [Pharo-dev] Browser on a single class
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 entitymethod) sourceCode ] ]. browser openOn: Morph On 05 Oct 2014, at 10:08, Yuriy Tymchuk yuriy.tymc...@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 esteba...@gmail.com mailto:esteba...@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 entitymethod) 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 nicolaih...@web.de mailto:nicolaih...@web.de wrote: 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano esteba...@gmail.com mailto:esteba...@gmail.com: On 03 Oct 2014, at 13:14, Nicolai Hess nicolaih...@web.de mailto:nicolaih...@web.de wrote: Am 03.10.2014 12:34 schrieb Yuriy Tymchuk yuriy.tymc...@me.com mailto:yuriy.tymc...@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).
Re: [Pharo-dev] GT first impressions
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 tu...@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 esteba...@gmail.com wrote: On 04 Oct 2014, at 22:43, Tudor Girba tu...@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.mora...@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/conceptual/applehiguidelines/Menus/Menus.html 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
Re: [Pharo-dev] Browser on a single class
Nice ;-) On 05 Oct 2014, at 11:56, Esteban Lorenzano esteba...@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 entitymethod) sourceCode ] ]. browser openOn: Morph On 05 Oct 2014, at 10:08, Yuriy Tymchuk yuriy.tymc...@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 esteba...@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 entitymethod) 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 nicolaih...@web.de wrote: 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano esteba...@gmail.com: On 03 Oct 2014, at 13:14, Nicolai Hess nicolaih...@web.de wrote: Am 03.10.2014 12:34 schrieb Yuriy Tymchuk yuriy.tymc...@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
Re: [Pharo-dev] Inspector steals my Window !
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 tu...@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 nicolaih...@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
Re: [Pharo-dev] Inspector steals my Window !
Thanks! Doru On Sun, Oct 5, 2014 at 12:12 PM, Andrei Chis chisvasileand...@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 tu...@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 nicolaih...@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
Re: [Pharo-dev] History of the .image
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/179950.html 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
Re: [Pharo-dev] Browser on a single class
Yes, Glamour is cool. But two issues (can you solve them? :) ) 1. the source list is not updated, the dragged method is still visible in the old protocol until you change the selected protocol item 2. (critical) the image hangs if you drop the methods list item in the methods list. 2014-10-05 11:56 GMT+02:00 Esteban Lorenzano esteba...@gmail.com: 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 entitymethod) sourceCode ] ]. browser openOn: Morph On 05 Oct 2014, at 10:08, Yuriy Tymchuk yuriy.tymc...@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 esteba...@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 entitymethod) 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 nicolaih...@web.de wrote: 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano esteba...@gmail.com: On 03 Oct 2014, at 13:14, Nicolai Hess nicolaih...@web.de wrote: Am 03.10.2014 12:34 schrieb Yuriy Tymchuk yuriy.tymc...@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.
Re: [Pharo-dev] GT first impressions
I don't even use shortcuts for copy and paste. I can't be much of a programmer. -- View this message in context: http://forum.world.st/GT-first-impressions-tp4782636p4782710.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Browser on a single class
On 05 Oct 2014, at 13:21, Nicolai Hess nicolaih...@web.de wrote: Yes, Glamour is cool. But two issues (can you solve them? :) ) 1. the source list is not updated, the dragged method is still visible in the old protocol until you change the selected protocol item 2. (critical) the image hangs if you drop the methods list item in the methods list. that’s an issue for Doru ;) 2014-10-05 11:56 GMT+02:00 Esteban Lorenzano esteba...@gmail.com mailto:esteba...@gmail.com: 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 entitymethod) sourceCode ] ]. browser openOn: Morph On 05 Oct 2014, at 10:08, Yuriy Tymchuk yuriy.tymc...@me.com mailto:yuriy.tymc...@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 esteba...@gmail.com mailto:esteba...@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 entitymethod) 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 nicolaih...@web.de mailto:nicolaih...@web.de wrote: 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano esteba...@gmail.com mailto:esteba...@gmail.com: On 03 Oct 2014, at 13:14, Nicolai Hess nicolaih...@web.de mailto:nicolaih...@web.de wrote: Am 03.10.2014 12:34 schrieb Yuriy Tymchuk yuriy.tymc...@me.com mailto:yuriy.tymc...@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
Re: [Pharo-dev] Browser on a single class
On 05 Oct 2014, at 11:56, Esteban Lorenzano esteba...@gmail.com wrote: lazy Yury I’m just not so UI hacker as you are :). Thanks! 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 entitymethod) sourceCode ] ]. browser openOn: Morph On 05 Oct 2014, at 10:08, Yuriy Tymchuk yuriy.tymc...@me.com mailto:yuriy.tymc...@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 esteba...@gmail.com mailto:esteba...@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 entitymethod) 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 nicolaih...@web.de mailto:nicolaih...@web.de wrote: 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano esteba...@gmail.com mailto:esteba...@gmail.com: On 03 Oct 2014, at 13:14, Nicolai Hess nicolaih...@web.de mailto:nicolaih...@web.de wrote: Am 03.10.2014 12:34 schrieb Yuriy Tymchuk yuriy.tymc...@me.com mailto:yuriy.tymc...@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 |
Re: [Pharo-dev] GT first impressions
Hi, My remark was not meant to be derogative. If it came out like this, I apologize. I simply stated what my assumption was. You prove to refute my assumption (at least for your specific case). Cheers, Doru On Sun, Oct 5, 2014 at 1:35 PM, kmo vox...@gmail.com wrote: I don't even use shortcuts for copy and paste. I can't be much of a programmer. -- View this message in context: http://forum.world.st/GT-first-impressions-tp4782636p4782710.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] structuring widget examples
Hi guys
I started to systematically defined widget example using the pragram
exampleWidget
rowPrototype
Answer a prototypical row
self rowPrototype openInHand
exampleWidget
| sampleMorphs aRow |
sampleMorphs := (1 to: (2 + 3 atRandom)) collect:
[:integer | EllipseMorph new extent: ((60 + (20 atRandom)) @
(80 + ((20 atRandom; color: Color random; setNameTo: ('egg', integer
asString); yourself].
aRow := self inARow: sampleMorphs.
aRow setNameTo: 'Row'.
aRow enableDragNDrop.
aRow cellInset: 6.
aRow layoutInset: 8.
aRow setBalloonText: 'Things dropped into here will automatically
be organized into a row. Once you have added your own items here, you
will want to remove the sample colored eggs that this started with, and
you will want to change this balloon help message to one of your own!'.
aRow color: Color veryVeryLightGray.
^ aRow
This means that GTool will get instances for free to play with and the
finder get really handy to browse widgets.
If you want to join the effort you are welcome.
Stef
Screen Shot 2014-10-05 at 14.23.10.pdf
Description: Adobe PDF document
[Pharo-dev] [GT] seeing morph **And** textpane
Hi andrei/doru When I inspect a morph I only see it, while when I look at state I see the variables and the textpane to evaluate expression. I think that the expression is really important in the inspector and we should see it all the time. Stef
Re: [Pharo-dev] GT first impressions
Doru - Don't take me too seriously. There was no offence. -- View this message in context: http://forum.world.st/GT-first-impressions-tp4782636p4782721.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] GT first impressions
Ok :) Doru On Sun, Oct 5, 2014 at 2:45 PM, kmo vox...@gmail.com wrote: Doru - Don't take me too seriously. There was no offence. -- View this message in context: http://forum.world.st/GT-first-impressions-tp4782636p4782721.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [GT] seeing morph **And** textpane
Indeed, this is something I would like since quite a while. Of course, we could add the evaluator at the bottom of everything (I tried that), but this will take away from the interaction and make up for an ugly UI. What I would want is a kind of a pane that appears/disappears on demand. We still need to create that support. Cheers, Doru On Sun, Oct 5, 2014 at 2:40 PM, stepharo steph...@free.fr wrote: Hi andrei/doru When I inspect a morph I only see it, while when I look at state I see the variables and the textpane to evaluate expression. I think that the expression is really important in the inspector and we should see it all the time. Stef -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] structuring widget examples
Hi Stef,
Great. GT is already prepared for this :). If you define a gtExample on
the class side, you will get an E.g. tab with those examples.
It's called gtExample because we did not want to interfere with other
pragmas, but perhaps we can change it to eg, or example. What do you
think?
Cheers,
Doru
On Sun, Oct 5, 2014 at 2:25 PM, stepharo steph...@free.fr wrote:
Hi guys
I started to systematically defined widget example using the pragram
exampleWidget
rowPrototype
Answer a prototypical row
self rowPrototype openInHand
exampleWidget
| sampleMorphs aRow |
sampleMorphs := (1 to: (2 + 3 atRandom)) collect:
[:integer | EllipseMorph new extent: ((60 + (20 atRandom)) @ (80 +
((20 atRandom; color: Color random; setNameTo: ('egg', integer
asString); yourself].
aRow := self inARow: sampleMorphs.
aRow setNameTo: 'Row'.
aRow enableDragNDrop.
aRow cellInset: 6.
aRow layoutInset: 8.
aRow setBalloonText: 'Things dropped into here will automatically be
organized into a row. Once you have added your own items here, you will
want to remove the sample colored eggs that this started with, and you will
want to change this balloon help message to one of your own!'.
aRow color: Color veryVeryLightGray.
^ aRow
This means that GTool will get instances for free to play with and the
finder get really handy to browse widgets.
If you want to join the effort you are welcome.
Stef
--
www.tudorgirba.com
Every thing has its own flow
Re: [Pharo-dev] gt issues
kmo wrote: I've raised two issues on the GT playground: https://pharo.fogbugz.com/f/cases/14158/Navigation-buttons-icons-at-bottom-of-GT-playground-are-meaningless-unintuitive https://pharo.fogbugz.com/f/cases/14157/Navigation-buttons-at-bottom-of-GT-playground-are-almost-invisible-in-default-theme When I first tried the playground I never even noticed the dots at the bottom of the window - they do not show up well in the default theme. - (they seem OK in the dark theme screenshots I've seen). Also, I think little dots are not intuitive. It would be better if you had video controller buttons or perhaps little outlined squares with page numbers in them. Dots on their own mean nothing. Perhaps when a new pane is added, its dot can flash a couple of times, to form a cognitive cause--effect link between dots and panes. Maybe this should only occur when going from 1 pane (which shows no dots) to 2 panes (which adds the bottom bar with dots). -ben
Re: [Pharo-dev] gt issues
Indeed. But just having a good contrast solves the problem quite well, I believe, because it is gets more easily noticeable. Cheers, Doru On Sun, Oct 5, 2014 at 3:37 PM, Ben Coman b...@openinworld.com wrote: kmo wrote: I've raised two issues on the GT playground: https://pharo.fogbugz.com/f/cases/14158/Navigation- buttons-icons-at-bottom-of-GT-playground-are-meaningless-unintuitive https://pharo.fogbugz.com/f/cases/14157/Navigation- buttons-at-bottom-of-GT-playground-are-almost-invisible-in-default-theme When I first tried the playground I never even noticed the dots at the bottom of the window - they do not show up well in the default theme. - (they seem OK in the dark theme screenshots I've seen). Also, I think little dots are not intuitive. It would be better if you had video controller buttons or perhaps little outlined squares with page numbers in them. Dots on their own mean nothing. Perhaps when a new pane is added, its dot can flash a couple of times, to form a cognitive cause--effect link between dots and panes. Maybe this should only occur when going from 1 pane (which shows no dots) to 2 panes (which adds the bottom bar with dots). -ben -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] structuring widget examples
Tudor Girba wrote:
Hi Stef,
Great. GT is already prepared for this :). If you define a gtExample
on the class side, you will get an E.g. tab with those examples.
It's called gtExample because we did not want to interfere with other
pragmas, but perhaps we can change it to eg, or example. What do you
think?
NOT eg! I've no opinion on example versus gtExample - except that
we shouldn't have too many varying forms of example.
-ben
Cheers,
Doru
On Sun, Oct 5, 2014 at 2:25 PM, stepharo steph...@free.fr
mailto:steph...@free.fr wrote:
Hi guys
I started to systematically defined widget example using the pragram
exampleWidget
rowPrototype
Answer a prototypical row
self rowPrototype openInHand
exampleWidget
| sampleMorphs aRow |
sampleMorphs := (1 to: (2 + 3 atRandom)) collect:
[:integer | EllipseMorph new extent: ((60 + (20 atRandom)) @
(80 + ((20 atRandom; color: Color random; setNameTo: ('egg',
integer asString); yourself].
aRow := self inARow: sampleMorphs.
aRow setNameTo: 'Row'.
aRow enableDragNDrop.
aRow cellInset: 6.
aRow layoutInset: 8.
aRow setBalloonText: 'Things dropped into here will
automatically be organized into a row. Once you have added your own
items here, you will want to remove the sample colored eggs that
this started with, and you will want to change this balloon help
message to one of your own!'.
aRow color: Color veryVeryLightGray.
^ aRow
This means that GTool will get instances for free to play with and
the finder get really handy to browse widgets.
If you want to join the effort you are welcome.
Stef
--
www.tudorgirba.com http://www.tudorgirba.com
Every thing has its own flow
Re: [Pharo-dev] [Pharo-fuel] Updates for Pharo4
On 04.10.2014, at 07:26, Stéphane Ducasse stef...@free.fr wrote: On 03 Oct 2014, at 22:21, Max Leske maxle...@gmail.com wrote: I fixed a couple of issues and failing tests for Pharo4. There’s also a couple of new things (e.g. test cases for Context instead of MethodContext) that should be integrated into Pharo4. Let us know and we will do it ;) Yep, saw that you included the change, thanks. Tx for your energy and constant push. My pleasure :) Cheers, Max ___ Pharo-fuel mailing list pharo-f...@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel ___ Pharo-fuel mailing list pharo-f...@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel
Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development
Johan Brichau wrote: 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. +1 and others agree... (though on the net its possible to find material to support any view) test for features, not for platforms http://programmers.stackexchange.com/questions/50876/are-there-any-best-practices-on-cross-device-development The best bet is always to test for features, not versions, because it's difficult to screw that up and it allows for the possibility that things might be back-ported in future. http://mac-os-x.10953.n7.nabble.com/CocoaApp-isThisTiger-td29619i20.html The Autoconf approach to portability is to test for features, not for versions. http://en.wikipedia.org/wiki/Autoconf btw Johan, how would you handle a method-existence-based requirement rather than class-existence-based? ... 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 steph...@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 is because of bad design. Let us see what other people think. Stef With the disclaimer that I haven't done cross platform Smalltalk yet, in general philosophy I agree with Stef. A Mentoring Course On Smalltalk regarding elimination of conditional logic says, drawing design time distinctions at run time is intention obscuring by nature. ... 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-methods-to-SmalltalkImage-to-ease-cross-dialect-development Introduce isXXX (isPharo, isVisualWorks, ...) dialect testing methods to SmalltalkImage to ease multi-dialect development. You would need to get ALL dialects to implement the convention? 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. However if you do want to go the testing-for-versions, and your concern is management of separate packages, then perhaps it can all be done on one package. The following does not seem too onerous from a code perspective... -- CrossPlatformplatform ^ CurrentPlatform ifNil: [ --class variable CurrentPlatform := self class subClasses detect: [ :candidatePlatformClass | candidatePlatformClass isCurrentPlatform CrossPlatform subclass: SomeCoolDialect. SomeCoolDialectisCurrentPlatform ^ (Smalltalk version includesSubstring: 'SomeCoolDialect') -- CrossPlatformwriteStreamOn: aString self platform writeSteamOn: aString SomeCoolDialectwriteStreamOn: aString ^ CharacterWriteStream on: aString -- 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: New #ifdef's which test for specific compilers or manufacturers or operating systems are unacceptable. All #ifdef's should test for features. https://www.cs.utah.edu/dept/old/texinfo/gdb/gdbint.html cheers -ben | 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
Re: [Pharo-dev] GT first impressions
Tudor Girba 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 programmers new to Pharo don't know the shortcuts. Menus enhance the explorability of the system, and lower the cognitive load of remembering everything all at once, and helps with video tutorials. cheers -ben 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 esteba...@gmail.com mailto:esteba...@gmail.com wrote: On 04 Oct 2014, at 22:43, Tudor Girba tu...@tudorgirba.com mailto:tu...@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.mora...@gmail.com mailto:hernan.mora...@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/conceptual/applehiguidelines/Menus/Menus.html 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 -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] About ways to participate in community and general negativity
2014-10-03 17:03 GMT-03:00 stepharo steph...@free.fr: On 3/10/14 18:56, Hernán Morales Durand wrote: I have the same feeling. Pharo is yours, but I take the main decisions. Actually it feels a little bit insulting, I am using Pharo since several years in a domain which nobody works with Smalltalk, and never got a survey request (except for some software engineering research). And I bet there are people not in the Pharo/Moose/Seaside team that didn't received any attention and they are doing significant experiences. You are paranoid. :) We know well people in Moose and Seaside and they know that they can talk to us. Just ask and we listen. I do not think that people understand what is our life. We are not a team working on Pharo. We are a research team fighting to get some time to push Pharo and Inria gives us some money to pay engineers like igor, and esteban. I know that. What I am saying is: Why there is no voting process for libraries, tools, roadmaps, etc? Not for asking things to you but for getting an idea what's most wanted, where is the community. Some of you are scientists, you know the value of collecting data. I remembered there was a Pharo usage poll in 2012 : https://docs.google.com/forms/d/1sa01_h8_SFoPIrrXaAzpmmCBvnXgEpGzIyslnkcgTpk/viewform?formkey=dFZKeXUwaG80OWhSOGpZVERrX2ZlVGc6MQfromEmail=true I like that route. Even if people with the money don't care, let us believe we have the data, opinions, ideas, etc. You know like a modern democracy :) Definitely I would help building a poll, it doesn't *have* to include a Consortium member but that would be really nice. We could try smart questions. Anyone? Why they don't write here? I suspect one of the reasons is Pharo is being too motivated by software enineering research and not enough interest for other giant domains like 3D, finance, expert systems, HPC, etc. People perceive this. We are NOT DOING RESEARCH IN SOFTWARE ENGINEERING IN PHARO. Repeat after me. We are NOT DOING RESEARCH IN SOFTWARE ENGINEERING IN PHARO. We are just maintaining it and making sure that we can have a decent compiler and infrastructure to build other systems. Ok for now I disagree a little bit, but I don't want to go there, I don't think that would be a productive discussion. How could we build finance, HPC, 3d without been experts. Do not dream there are full team of researchers at Inria building real 3d engines. Why would we go there? Seriously. Because there is big money in 3D? I see years passing but money never comes. You cannot expect big funding if you keep doing things the same as always. Exactly and do not dream about investors. Now we work hard to set the consortium. If at the end of the journey, people do not sponsor or participate then we will close it. and we will look back and say that we did our best. We create an autonomous entity that can manage Pharo but if we cannot pay an engineer with it then this is ok too. But people should not complain that open-source Pharo does not work. We do not have mozilla or google behind us and if individuals do not understand that they can get an impact = Pharo is yours then what can we do. Just continue slower with less engineers. But there are entrepreneur networks like FounderDating and https://angel.co/ Of course they are not Google but they are a popular choice for initial investment. Someone using Pharo has passed the seed funding round? Or tried to present a business plan? Cheers, Hernán
Re: [Pharo-dev] structuring widget examples
On 5/10/14 15:10, Tudor Girba wrote:
Hi Stef,
Great. GT is already prepared for this :). If you define a gtExample
on the class side, you will get an E.g. tab with those examples.
It's called gtExample because we did not want to interfere with other
pragmas, but perhaps we can change it to eg, or example. What do
you think?
for a given class I would like to have potentially multiple examples. I
already have that in certain classes.
Then since these examples are for core classes I do not really like the
idea to get gt*
Now first we should have many more and renaming a pragma is just the
easy part of the game.
Because I'm turning WidgetExamples into class methods examples and
trying to understand the API of UITheme
and reducing the mess.
I want
- UITheme to call widgets class methods
- but I have to understand the theme impact on the API.
a kind of gigantic task. but we will see.
Stef
Cheers,
Doru
On Sun, Oct 5, 2014 at 2:25 PM, stepharo steph...@free.fr
mailto:steph...@free.fr wrote:
Hi guys
I started to systematically defined widget example using the
pragram exampleWidget
rowPrototype
Answer a prototypical row
self rowPrototype openInHand
exampleWidget
| sampleMorphs aRow |
sampleMorphs := (1 to: (2 + 3 atRandom)) collect:
[:integer | EllipseMorph new extent: ((60 + (20 atRandom))
@ (80 + ((20 atRandom; color: Color random; setNameTo: ('egg',
integer asString); yourself].
aRow := self inARow: sampleMorphs.
aRow setNameTo: 'Row'.
aRow enableDragNDrop.
aRow cellInset: 6.
aRow layoutInset: 8.
aRow setBalloonText: 'Things dropped into here will
automatically be organized into a row. Once you have added your
own items here, you will want to remove the sample colored eggs
that this started with, and you will want to change this balloon
help message to one of your own!'.
aRow color: Color veryVeryLightGray.
^ aRow
This means that GTool will get instances for free to play with and
the finder get really handy to browse widgets.
If you want to join the effort you are welcome.
Stef
--
www.tudorgirba.com http://www.tudorgirba.com
Every thing has its own flow
Re: [Pharo-dev] GT first impressions
Hi, On Sun, Oct 5, 2014 at 5:38 PM, Ben Coman b...@openinworld.com wrote: Tudor Girba 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 programmers new to Pharo don't know the shortcuts. Menus enhance the explorability of the system, and lower the cognitive load of remembering everything all at once, and helps with video tutorials. cheers -ben Perhaps it was not clear, but the current discussion is about copy/cut/paste :). Cheers, Doru 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 esteba...@gmail.com mailto:esteba...@gmail.com wrote: On 04 Oct 2014, at 22:43, Tudor Girba tu...@tudorgirba.com mailto:tu...@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.mora...@gmail.com mailto:hernan.mora...@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/conceptual/applehiguidelines/Menus/Menus.html 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 -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] GT first impressions
On 05 Oct 2014, at 18:24, Tudor Girba tu...@tudorgirba.com wrote: Hi, On Sun, Oct 5, 2014 at 5:38 PM, Ben Coman b...@openinworld.com mailto:b...@openinworld.com wrote: Tudor Girba 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 programmers new to Pharo don't know the shortcuts. Menus enhance the explorability of the system, and lower the cognitive load of remembering everything all at once, and helps with video tutorials. cheers -ben Perhaps it was not clear, but the current discussion is about copy/cut/paste :). Well, I don’t know if it helps, but I cannot think on a single app in my life that does not have those ubiquitous copy/cut/paste options as part of their contextual menus. Not that because everybody does it we *have to* do it too… but I do not see a reason to not follow the universal conventions in this case. Esteban Cheers, Doru 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 esteba...@gmail.com mailto:esteba...@gmail.com mailto:esteba...@gmail.com mailto:esteba...@gmail.com wrote: On 04 Oct 2014, at 22:43, Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com mailto:tu...@tudorgirba.com mailto:tu...@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.mora...@gmail.com mailto:hernan.mora...@gmail.com mailto:hernan.mora...@gmail.com mailto:hernan.mora...@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/conceptual/applehiguidelines/Menus/Menus.html https://developer.apple.com/library/mac/documentation/userexperience/conceptual/applehiguidelines/Menus/Menus.html 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.
[Pharo-dev] [pharo-project/pharo-core] 32845c: 40284
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 32845c46176f43f87157c4ccc34157cf9392aa05 https://github.com/pharo-project/pharo-core/commit/32845c46176f43f87157c4ccc34157cf9392aa05 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-10-05 (Sun, 05 Oct 2014) Changed paths: M KernelTests.package/IVsAndClassVarNamesConflictTest.class/definition.st A KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/running/setUp.st A KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/running/tearDown.st R KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/setup/setUp.st R KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/setup/tearDown.st M KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/tests/testOneCanProceedWhenIntroducingCapitalizedInstanceVariables.st M KernelTests.package/IVsAndClassVarNamesConflictTest.class/instance/tests/testOneCanProceedWhenIntroducingClasseVariablesBeginingWithLowerCaseCharacters.st M KernelTests.package/ObsoleteTest.class/definition.st A KernelTests.package/ObsoleteTest.class/instance/running/setUp.st A KernelTests.package/ObsoleteTest.class/instance/running/tearDown.st R KernelTests.package/ObsoleteTest.class/instance/testing/testClassObsolete.st R KernelTests.package/ObsoleteTest.class/instance/testing/testTraitObsolete.st A KernelTests.package/ObsoleteTest.class/instance/tests/testClassObsolete.st A KernelTests.package/ObsoleteTest.class/instance/tests/testFixObsoleteSharedPools.st A KernelTests.package/ObsoleteTest.class/instance/tests/testTraitObsolete.st M MonticelloGUI.package/MCSliceMaker.class/instance/actions/downloadIssueSummary.st A MonticelloGUI.package/MCSliceMaker.class/instance/actions/informFailedWith_.st A Morphic-Base.package/StringMorph.class/class/examples/exampleManyStringMorphs.st R Morphic-Base.package/StringMorph.class/class/testing/test.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/examples/example.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/examples/exampleDisable.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/instance creation/labelFont.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/instance creation/newLabelFor_label_getEnabled_.st A Morphic-Widgets-Basic.package/LabelMorph.class/class/instance creation/newLabel_.st A Morphic-Widgets-Basic.package/PluggableButtonMorph.class/class/examples/exampleButtonNoAction.st A Morphic-Widgets-Basic.package/PluggableButtonMorph.class/class/instance creation/newButtonFor_action_label_help_.st A Morphic-Widgets-Basic.package/PluggableButtonMorph.class/class/instance creation/newButtonFor_getState_action_arguments_getEnabled_label_help_.st M Morphic-Widgets-Extra.package/DockingBarMorph.class/class/example/example.st M Morphic-Widgets-Extra.package/DockingBarMorph.class/class/example/exampleWithMenu.st R Polymorph-Tools-Diff.package/DiffChangeMorph.class/class/as yet unclassified/from_label_to_label_contextClass_.st A Polymorph-Tools-Diff.package/DiffChangeMorph.class/class/instance creation/from_label_to_label_contextClass_.st M SUnit-Core.package/ClassFactoryForTestCase.class/definition.st A SUnit-Core.package/ClassFactoryForTestCase.class/instance/accessing/nextCount.st A SUnit-Core.package/ClassFactoryForTestCase.class/instance/cleaning/deleteClass_.st M SUnit-Core.package/ClassFactoryForTestCase.class/instance/creating/newClassName.st M SUnit-Core.package/ClassFactoryForTestCase.class/instance/creating/newSubclassOf_uses_instanceVariableNames_classVariableNames_category_.st A SUnit-Core.package/ClassFactoryForTestCase.class/instance/creating/newSubclassOf_uses_instanceVariableNames_classVariableNames_poolDictionaries_category_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script284.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40284.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Support.package/SmalltalkImage.class/instance/housekeeping/fixObsoleteBindings.st M System-Support.package/SmalltalkImage.class/instance/housekeeping/fixObsoleteReferences.st A System-Support.package/SmalltalkImage.class/instance/housekeeping/fixObsoleteSharedPools.st M Traits.package/TBehavior.class/instance/accessing/sharedPoolNames.st M Traits.package/TClassDescription.class/instance/printing/sharedPoolsString.st Log Message: --- 40284 13905 entering non existing issue numbers in slice maker https://pharo.fogbugz.com/f/cases/13905 14164 using exampleWidget and not widgetExample https://pharo.fogbugz.com/f/cases/14164 13088 Deleting class that is used in pool dictionaries leaves a private class pool
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40284 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] GT first impressions
Tudor Girba wrote: Hi, On Sun, Oct 5, 2014 at 5:38 PM, Ben Coman b...@openinworld.com mailto:b...@openinworld.com wrote: Tudor Girba 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 programmers new to Pharo don't know the shortcuts. Menus enhance the explorability of the system, and lower the cognitive load of remembering everything all at once, and helps with video tutorials. cheers -ben Perhaps it was not clear, but the current discussion is about copy/cut/paste :). Cheers, Doru Yes, it was not clear. I was thinking more of the Extended search... and suchlike, but I see you've mentioned addressing that already. cheers -ben 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 esteba...@gmail.com mailto:esteba...@gmail.com mailto:esteba...@gmail.com mailto:esteba...@gmail.com wrote: On 04 Oct 2014, at 22:43, Tudor Girba tu...@tudorgirba.com mailto:tu...@tudorgirba.com mailto:tu...@tudorgirba.com mailto:tu...@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.mora...@gmail.com mailto:hernan.mora...@gmail.com mailto:hernan.morales@gmail.__com mailto:hernan.mora...@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/conceptual/__applehiguidelines/Menus/Menus.__html https://developer.apple.com/library/mac/documentation/userexperience/conceptual/applehiguidelines/Menus/Menus.html 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.
Re: [Pharo-dev] gt issues
By video controls I meant /first, previous, next, last /buttons - but that's not a good idea now I think about it. I still think page numbers might be better than dots. But, as you say, I managed to use the dots so they can't be that bad, Still, I think the dots would look more obviously like navigation controls if they were embedded in a small sunken or raised panel. But perhaps as you suggest with more contrast in colour even that might not be necessary. I'm a bit more concerned about how easy it is to end up with lots of panes that are identical. For example, in the screenshots of smallInteger(42) in this thread. Every pane reads the same. Isn't that confusing? No doubt I'll get used to it, though. I don't like the idea of flashing the controls by the way - that seems very artificial to me. -- View this message in context: http://forum.world.st/gt-issues-tp4782476p4782808.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] structuring widget examples
Hi Stef,
I was not clear. The E.g. presentation for a class lists all examples. So,
it is expected that we get more examples for a class. Take a look at the
attached screenshot showing the examples of FileReference.
Let's call it example and then we use it consistently throughout the
system. Is that Ok?
Cheers,
Doru
[image: Inline image 1]
On Sun, Oct 5, 2014 at 5:58 PM, stepharo steph...@free.fr wrote:
On 5/10/14 15:10, Tudor Girba wrote:
Hi Stef,
Great. GT is already prepared for this :). If you define a gtExample
on the class side, you will get an E.g. tab with those examples.
It's called gtExample because we did not want to interfere with other
pragmas, but perhaps we can change it to eg, or example. What do you
think?
for a given class I would like to have potentially multiple examples. I
already have that in certain classes.
Then since these examples are for core classes I do not really like the
idea to get gt*
Now first we should have many more and renaming a pragma is just the easy
part of the game.
Because I'm turning WidgetExamples into class methods examples and trying
to understand the API of UITheme
and reducing the mess.
I want
- UITheme to call widgets class methods
- but I have to understand the theme impact on the API.
a kind of gigantic task. but we will see.
Stef
Cheers,
Doru
On Sun, Oct 5, 2014 at 2:25 PM, stepharo steph...@free.fr wrote:
Hi guys
I started to systematically defined widget example using the pragram
exampleWidget
rowPrototype
Answer a prototypical row
self rowPrototype openInHand
exampleWidget
| sampleMorphs aRow |
sampleMorphs := (1 to: (2 + 3 atRandom)) collect:
[:integer | EllipseMorph new extent: ((60 + (20 atRandom)) @ (80
+ ((20 atRandom; color: Color random; setNameTo: ('egg', integer
asString); yourself].
aRow := self inARow: sampleMorphs.
aRow setNameTo: 'Row'.
aRow enableDragNDrop.
aRow cellInset: 6.
aRow layoutInset: 8.
aRow setBalloonText: 'Things dropped into here will automatically be
organized into a row. Once you have added your own items here, you will
want to remove the sample colored eggs that this started with, and you will
want to change this balloon help message to one of your own!'.
aRow color: Color veryVeryLightGray.
^ aRow
This means that GTool will get instances for free to play with and the
finder get really handy to browse widgets.
If you want to join the effort you are welcome.
Stef
--
www.tudorgirba.com
Every thing has its own flow
--
www.tudorgirba.com
Every thing has its own flow
Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development
On Sun, 2014-10-05 at 10:29 +0200, Johan Brichau wrote: 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) ] Right, in this example it could eventually work. Another concrete example I bumped just yesterday. The feature testing code would look like ((Character respondsTo: #to:) and:[($a to: $z) isKindOf: Interval]) ifTrue:[ ... ] ifFalse:[ ... ]. (true, in this very case you may be able to get around using different method, but you get the point, no?) Some time ago Hilaire posted a very nice, 15 lines long code that does reliable feature detection whether the system is Pharo 2.0 or 3.0 (or similar, I don't remember exactly). Is the interval testing code above more robust? Perhaps. Is it more readable, more intention revelaling? I doubt it. While I can agree that feature testing is is better, however, in my experience it is very tricky if the code does not provide support for such tests. 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. That's great. But having such dependency is exactly what I, and not only me, don't want if it would be for only one or two methods. The aim is to provide a simple solution for simple cases, not a silver bullet. Jan cheers Johan On 05 Oct 2014, at 09:00, stepharo steph...@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 is 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-methods-to-SmalltalkImage-to-ease-cross-dialect-development 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
[Pharo-dev] [ANN] flow: a living full-stack #framework for the web
Hi guys, I’m sharing slides of my presentation at CampSmalltalkVI2014 http://www.slideshare.net/sebastianconcept/flow-39897704 From flow’s readme at github: Flow's mission is to provide consultants, startups and software houses with a competitive Smalltalk full-stack framework that allows them to quickly deliver a demo with all the modern html5 features the market expects today (2014). The idea is that they can tactically use this framework to keep momentum up among their prospects and clients and scale things to full successful projects delivered by kickass productive teams or individuals. sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept
Re: [Pharo-dev] [Moose-dev] [ANN] Test Coverage with Hapao
Hi Maximiliano! The legend problem is now fixed. Can you double check please? What would be the best way to exclude some methods? This question slightly rephrased: how do you run Hapao? Programmatically or using the World menu? Cheers, Alexandre On Oct 2, 2014, at 11:34 PM, Maximiliano Taborda mtabo...@gmail.com wrote: Hi Alexandre. Yes, now it works. Thank you. But, the box with the legends don't show very well. Like in the attached image: RelativeDate.png And, a question. Is there a way to exclude some methods from the analysis? I have some class methods, used for initialize some singletons for example, that I do not want to be considered for coverage. Regards. Maxi 2014-10-02 18:39 GMT-03:00 Alexandre Bergel alexandre.ber...@me.com: Hi! Sorry, we somehow slightly messed up with the configurations. I just took the last Pharo 4.0, and loaded Roassal2: -=-=-=-=-=-=-=-=-=-=-=-= Gofer new smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; package: 'ConfigurationOfRoassal2'; load. (Smalltalk at: #ConfigurationOfRoassal2) loadDevelopment -=-=-=-=-=-=-=-=-=-=-=-= Then I loaded S2py: -=-=-=-=-=-=-=-=-=-=-=-= Gofer new smalltalkhubUser: 'ObjectProfile' project: 'S2py'; package: 'S2py'; load. -=-=-=-=-=-=-=-=-=-=-=-= It works here. Can you confirm? Sorry for having taken long to answer... Cheers, Alexandre On Sep 24, 2014, at 8:24 PM, Maximiliano Taborda mtabo...@gmail.com wrote: Hi Alexandre, I want to try Hapao2 to check the coverage level of Chalten, but it's not working (at least for me). I load Roassal2 and S2py in a fresh 3.0 image like you say and the new entries appear in the world menu, but the only option that partially works is the one for a particular class (Hapao @ Class ...) and after run all the tests (I see the progress showing that) a MNU is raised in the method #addMethodEdges:scope:view: of Hapa2 class because RTEdgeBuilder is not loaded. So, could you tell me what I missed please? I need to load another thing, which?, at least the package which defines RTEdgeBuilder. Thanks for your help. Regards. Maxi 2014-09-16 20:10 GMT-03:00 Alexandre Bergel alexandre.ber...@me.com: Excellent! Alexandre Le 16-09-2014 à 16:15, Tudor Girba tu...@tudorgirba.com a écrit : Great! I will go over it more thoroughly in the following weeks and get back to you with feedback. Cheers, Doru On Tue, Sep 16, 2014 at 6:03 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Dear all, We are happy to release Hapao2 for Pharo. Ricard Jacas and Alejandro Infante put quite some work on Spy2 (an über cool profiling framework for Pharo) and Hapao2. Hapao2 is about assessing the test coverage of your code and is a major revamp of Hapao1, which was presented a couple of years ago by Vanessa. Hapao2 does not only list covered and uncovered methods, as most test coverage tool on Earth will do. Hapao gives a great visualization to easily navigate in your code, assess its complexity, and give you a great visual output telling its coverage. You need Roassal in your image: Gofer new smalltalkhubUser: 'ObjectProfile' project: 'Roassal2'; package: 'ConfigurationOfRoassal2'; load. (Smalltalk at: #ConfigurationOfRoassal2) load and you need S2py: MCHttpRepository location: 'http://smalltalkhub.com/mc/ObjectProfile/S2py/main' user: '' password: '' New entries will appear in the world menu: Screen Shot 2014-09-16 at 11.49.06 AM.png You can run the test coverage on : - the class classes you have modified, - on a particular - on a particular class category - on the last class categories you have modified - on the last packages you have modified Here is a portion of a large coverage: Screen Shot 2014-09-16 at 12.00.11 PM.png A technical description of Hapao may be found on http://bergel.eu/download/papers/Berg12c-HapaoSCP.pdf We are daily using Hapao to help us understand our tests. Cheers, Ricardo, Alejandro Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com Every thing has its own flow -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development
Would using Metacello's knowledge of the platform work for you? e.g. (MetacelloPlatform current defaultPlatformAttributes includes: '#squeak') ifTrue:[ ... ] (MetacelloPlatform current defaultPlatformAttributes includes: '#pharo1.2') . (MetacelloPlatform current defaultPlatformAttributes includes: '#gemstone2.4') . Or are you trying to get very very cross platform (e.g. GST, VAST, etc...) ? Jan Vrany wrote On Sun, 2014-10-05 at 10:29 +0200, Johan Brichau wrote: 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) ] Right, in this example it could eventually work. Another concrete example I bumped just yesterday. The feature testing code would look like ((Character respondsTo: #to:) and:[($a to: $z) isKindOf: Interval]) ifTrue:[ ... ] ifFalse:[ ... ]. (true, in this very case you may be able to get around using different method, but you get the point, no?) Some time ago Hilaire posted a very nice, 15 lines long code that does reliable feature detection whether the system is Pharo 2.0 or 3.0 (or similar, I don't remember exactly). Is the interval testing code above more robust? Perhaps. Is it more readable, more intention revelaling? I doubt it. While I can agree that feature testing is is better, however, in my experience it is very tricky if the code does not provide support for such tests. 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. That's great. But having such dependency is exactly what I, and not only me, don't want if it would be for only one or two methods. The aim is to provide a simple solution for simple cases, not a silver bullet. Jan cheers Johan On 05 Oct 2014, at 09:00, stepharo lt; stepharo@ gt; 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 is 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-methods-to-SmalltalkImage-to-ease-cross-dialect-development 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 -- View this message in context: http://forum.world.st/Issue-14160-Introduce-isXXX-dialect-testing-methods-to-SmalltalkImage-to-ease-cross-dialect-developmt-tp4782638p4782844.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development
Speaking as the maintainer of an external package (OSProcess/CommandShell) I agree with both Stef and Johan. Feature detection is better, because pharo (or squeak, or gemstone) is meaningless over time as the dialect changes. If you need to test for some feature, it is better to test for it explicitly than to assume that it exists in all versions of a specified dialect. As Stef says, Seaside with Grease is the way to go. The test for any given feature belongs in an external package (Grease), not in the core images. For a significant external package such as Seaside, use the abstraction layer of Grease. For simpler cases (e.g. OSProcess) put the required tests directly into that external package. But either way the isFoo tests belong in the external packages, and not in pharo/squeak/gemstone proper. Dave On Sun, Oct 05, 2014 at 10:29:26AM +0200, Johan Brichau wrote: 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 steph...@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 is 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-methods-to-SmalltalkImage-to-ease-cross-dialect-development 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
Re: [Pharo-dev] [ANN] flow: a living full-stack #framework for the web
Hi Sebastian, Interesting. Is there a relation between flow and Tide? Cheers, Doru On Sun, Oct 5, 2014 at 11:04 PM, Sebastian Sastre sebast...@flowingconcept.com wrote: Hi guys, I’m sharing slides of my presentation at CampSmalltalkVI2014 http://www.slideshare.net/sebastianconcept/flow-39897704 From flow’s readme at github https://github.com/flow-stack/flow: Flow's mission is to provide *consultants*, *startups* and *software houses* with *a competitive Smalltalk full-stack framework* that allows them to quickly deliver a demo with all the modern html5 features the market expects today (2014). The idea is that they can tactically use this framework to keep momentum up among their prospects and clients and scale things to full successful projects delivered by kickass productive teams or individuals. sebastian https://about.me/sebastianconcept o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] WhatsUp from: 2014-10-06 until: 2014-10-19
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: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-10-19 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)
Re: [Pharo-dev] [ANN] flow: a living full-stack #framework for the web
Abs great .. !.. https://github.com/flow-stack/flow have yet to install and check if it has any issues in my system. Will check it out, infact have a hackathon to see if this can be tried out on it. Nice framework to demo Smalltalk to the crowd in a banking world.. On Mon, Oct 6, 2014 at 2:34 AM, Sebastian Sastre sebast...@flowingconcept.com wrote: Hi guys, I’m sharing slides of my presentation at CampSmalltalkVI2014 http://www.slideshare.net/sebastianconcept/flow-39897704 From flow’s readme at github https://github.com/flow-stack/flow: Flow's mission is to provide *consultants*, *startups* and *software houses* with *a competitive Smalltalk full-stack framework* that allows them to quickly deliver a demo with all the modern html5 features the market expects today (2014). The idea is that they can tactically use this framework to keep momentum up among their prospects and clients and scale things to full successful projects delivered by kickass productive teams or individuals. sebastian https://about.me/sebastianconcept o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept
Re: [Pharo-dev] gt issues
Hi Phil, Sorry for the late reply. I cannot reproduce the stepping problem. Do you have a specific case? Run to here exists. It is a contextual action that depends on the cursor position. Hence, it is mapped in the context menu. Cheers, Doru On Sat, Oct 4, 2014 at 11:07 PM, p...@highoctane.be p...@highoctane.be wrote: I'd say that it is not intuitive at first but the abilities of the GT inspector are really making up for any inconvenience. As for the GT debugger, I've been running in a couple of problems, namely that stepping when restarting hasn't been working properly after a couple times. Also, I miss the run to here option that was in the debuggers before. It looks like gone. Why? It is a common option in all languages. Phil On Sat, Oct 4, 2014 at 10:56 PM, Tudor Girba tu...@tudorgirba.com wrote: Hi, Thanks for the feedback. Of course, they are not used anywhere else at this point just because the inspector is the first tool that was integrated into Pharo :). You say they are meaningless, but in fact you seem to have no problem with what they are and how they work. And you found it out by yourself. I agree that it is a different interface than anything else out there, but that is not a negative thing. Actually, we also tried other variations, but this was the one we stuck with, and most people seem to not have a problem with it. What do you mean by video controller buttons? And, you are right in that the contrast is not proper in the Pharo theme. This will change. In the meantime, here is how they look like in the WhitespaceTheme [image: Inline image 1] Is this better? Cheers, Doru On Sat, Oct 4, 2014 at 1:15 PM, kmo vox...@gmail.com wrote: Well, one man's intuitive is another man's completely obscure. In the pharo context, the dots are a completely new navigation widget - used nowhere else - and their function is unclear. I think part of the problem is that the dots do not appear on any kind of obvious toolbar - they are more or less just dots on the bottom of the window. There is no visual cue that they have any function at all. They could be mere decoration. Just my two cents. -- View this message in context: http://forum.world.st/gt-issues-tp4782476p4782557.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- www.tudorgirba.com Every thing has its own flow -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [ANN] flow: a living full-stack #framework for the web
The links has the step by step. I am running it as I type.. * For newbies on linux a mention of dependencies viz installing git / curl/ npm , node.js and bower and any others reqd would be great.. Anyways will post my attempt note in a few min.. On Mon, Oct 6, 2014 at 11:06 AM, Sven Van Caekenberghe s...@stfx.eu wrote: Great ! Wasn't there a step by step tutorial somewhere ? On 05 Oct 2014, at 23:04, Sebastian Sastre sebast...@flowingconcept.com wrote: Hi guys, I’m sharing slides of my presentation at CampSmalltalkVI2014 http://www.slideshare.net/sebastianconcept/flow-39897704 From flow’s readme at github: Flow's mission is to provide consultants, startups and software houses with a competitive Smalltalk full-stack framework that allows them to quickly deliver a demo with all the modern html5 features the market expects today (2014). The idea is that they can tactically use this framework to keep momentum up among their prospects and clients and scale things to full successful projects delivered by kickass productive teams or individuals. sebastian o/ blog: http://sebastianconcept.com LinkedIn: http://www.linkedin.com/in/sebastiansastre github: https://github.com/sebastianconcept
