date:20141005


Ok now I got it.

Stef

On 5/10/14 19:53, Tudor Girba wrote:

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  and then we use it consistently throughout the 
system. Is that Ok?


Cheers,
Doru

Inline image 1

On Sun, Oct 5, 2014 at 5:58 PM, stepharo > wrote:



On 5/10/14 15:10, Tudor Girba wrote:

Hi Stef,

Great. GT is already prepared for this :). If you define a
 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 , or
. 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 mailto:steph...@free.fr>> wrote:

Hi guys

I started to systematically defined widget example using the
pragram 


rowPrototype
"Answer a prototypical row"
"self rowPrototype openInHand"


| 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] [ANN] flow: a living full-stack #‎framework for the web



On 6/10/14 06:40, Tudor Girba wrote:

Hi Sebastian,

Interesting. Is there a relation between flow and Tide?


Indeed I asked myself the same because I would like to see more traction 
around tide because this is a great framework.




Cheers,
Doru



On Sun, Oct 5, 2014 at 11:04 PM, Sebastian Sastre 
mailto: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








--
www.tudorgirba.com 

"Every thing has its own flow"

Re: [Pharo-dev] [ANN] flow: a living full-stack #‎framework for the web

2014-10-05 Thread S Krish

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  wrote:

> Great !
>
> Wasn't there a step by step tutorial somewhere ?
>
> On 05 Oct 2014, at 23:04, Sebastian Sastre 
> 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
> >
> >
> >
> >
> >
>
>
>

Re: [Pharo-dev] [ANN] flow: a living full-stack #‎framework for the web

2014-10-05 Thread Sven Van Caekenberghe

Great !

Wasn't there a step by step tutorial somewhere ?

On 05 Oct 2014, at 23:04, Sebastian Sastre  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
> 
> 
> 
> 
>

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

2014-10-05 Thread S Krish

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 :
>
> 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
>
>
>
>
>
>

[Pharo-dev] WhatsUp from: 2014-10-06 until: 2014-10-19

2014-10-05 Thread seaside

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

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 :
>
> 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
>
>
>
>
>
>


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

2014-10-05 Thread David T. Lewis

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  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] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

2014-10-05 Thread Paul DeBruicker

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 <

> stepharo@

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

Re: [Pharo-dev] [Moose-dev] [ANN] Test Coverage with Hapao

2014-10-05 Thread Alexandre Bergel

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  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:
> 
> 
> 
> 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 :
> 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  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 :
> > Excellent!
> >
> > Alexandre
> >
> > Le 16-09-2014 à 16:15, Tudor Girba  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 
> >>  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:
> >> 
> >>
> >> 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:
> >>
> >> 
> >>
> >> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

[Pharo-dev] [ANN] flow: a living full-stack #‎framework for the web

2014-10-05 Thread Sebastian Sastre

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] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

2014-10-05 Thread Jan Vrany

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  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] 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  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  wrote:

>
> On 5/10/14 15:10, Tudor Girba wrote:
>
> Hi Stef,
>
>  Great. GT is already prepared for this :). If you define a 
> 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 , or . 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  wrote:
>
>> Hi guys
>>
>> I started to systematically defined widget example using the pragram
>> 
>>
>>
>> rowPrototype
>> "Answer a prototypical row"
>> "self rowPrototype openInHand"
>> 
>>
>> | 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] gt issues

2014-10-05 Thread kmo

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

Tudor Girba wrote:

Hi,

On Sun, Oct 5, 2014 at 5:38 PM, Ben Coman > 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
mailto:esteba...@gmail.com>
>> wrote:

On 04 Oct 2014, at 22:43, Tudor Girba
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
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

[Pharo-dev] [pharo-project/pharo-core]

2014-10-05 Thread GitHub

  Branch: refs/tags/40284
  Home:   https://github.com/pharo-project/pharo-core

[Pharo-dev] [pharo-project/pharo-core] 32845c: 40284

2014-10-05 Thread GitHub

  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 
  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 entry
https://p

Re: [Pharo-dev] GT first impressions


> On 05 Oct 2014, at 18:24, Tudor Girba  wrote:
> 
> Hi,
> 
> On Sun, Oct 5, 2014 at 5:38 PM, Ben Coman  > 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    >> wrote:
> 
> 
> On 04 Oct 2014, at 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
> 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,

Re: [Pharo-dev] GT first impressions

Hi,

On Sun, Oct 5, 2014 at 5:38 PM, Ben Coman  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 > > wrote:
>>
>>
>>  On 04 Oct 2014, at 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
>>> 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 
>>>
>>> "Every thing has its own flow"
>>>
>>
>>
>>
>>
>> --
>> www.tudorgirba.com 
>>
>> "Every thing has its own flow"
>>
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has

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  
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 , or . 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 > wrote:


Hi guys

I started to systematically defined widget example using the
pragram 


rowPrototype
"Answer a prototypical row"
"self rowPrototype openInHand"


| 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] About ways to participate in community and general negativity

2014-10-05 Thread Hernán Morales Durand

2014-10-03 17:03 GMT-03:00 stepharo :

>
> 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=dFZKeXUwaG80OWhSOGpZVERrX2ZlVGc6MQ&fromEmail=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] 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 > wrote:

On 04 Oct 2014, at 22:43, Tudor Girba 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
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

"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


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  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...

--

CrossPlatform>>platform
^ CurrentPlatform ifNil: [ "<--class variable"
CurrentPlatform := self class subClasses detect:
[   :candidatePlatformClass |
candidatePlatformClass isCurrentPlatform

CrossPlatform subclass: SomeCoolDialect.

SomeCoolDialect>>isCurrentPlatform
^ (Smalltalk version includesSubstring: 'SomeCoolDialect')

--

CrossPlatform>>writeStreamOn: aString
self platform writeSteamOn: aString

SomeCoolDialect>>writeStreamOn: 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] [Pharo-fuel] Updates for Pharo4

2014-10-05 Thread Max Leske


> On 04.10.2014, at 07:26, Stéphane Ducasse  wrote:
> 
> 
> On 03 Oct 2014, at 22:21, Max Leske  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] structuring widget examples


Tudor Girba wrote:

Hi Stef,

Great. GT is already prepared for this :). If you define a  
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 , or . What do you 
think?


NOT !  I've no opinion on  versus  - 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 > wrote:


Hi guys

I started to systematically defined widget example using the pragram



rowPrototype
"Answer a prototypical row"
"self rowPrototype openInHand"


| 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

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  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] 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] structuring widget examples

Hi Stef,

Great. GT is already prepared for this :). If you define a  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 , or . What do you
think?

Cheers,
Doru


On Sun, Oct 5, 2014 at 2:25 PM, stepharo  wrote:

> Hi guys
>
> I started to systematically defined widget example using the pragram
> 
>
>
> rowPrototype
> "Answer a prototypical row"
> "self rowPrototype openInHand"
> 
>
> | 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] 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  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] GT first impressions

Ok :)

Doru

On Sun, Oct 5, 2014 at 2:45 PM, kmo  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 first impressions

2014-10-05 Thread kmo

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.

[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

[Pharo-dev] structuring widget examples


Hi guys

I started to systematically defined widget example using the pragram 




rowPrototype
"Answer a prototypical row"
"self rowPrototype openInHand"


| 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

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

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

2014-10-05 Thread Yuriy Tymchuk


> On 05 Oct 2014, at 11:56, Esteban Lorenzano  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 entity>>method) 
> sourceCode ] ].
> 
> browser openOn: Morph
> 
>> On 05 Oct 2014, at 10:08, Yuriy Tymchuk > > 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 >> > wrote:
>>> 
>>> and this is same with glamour:
>>> 
>>> browser := GLMTabulator new 
>>> row: [ :row | 
>>> row 
>>> column: #protocols;
>>> column: #methods ];
>>> row: #code;
>>> yourself.
>>> 
>>> browser transmit 
>>> to: #protocols; 
>>> andShow: [ :a| a list display: [ :class | class organization protocols 
>>> ]; format: #name ].
>>> browser transmit 
>>> from: #protocols; 
>>> to: #methods; 
>>> andShow: [ :a| a list display: [ :protocol | protocol methods ] ].
>>> browser transmit 
>>> from: #methods; 
>>> to: #code; 
>>> andShow: [ :a | 
>>> a smalltalkCode 
>>> smalltalkClass: [ browser entity ];
>>> display: [ :method | (browser entity>>method) 
>>> sourceCode ] ].
>>> 
>>> browser openOn: Morph.
>>> 
>>> Of course spec is capable of doing that. 
>>> But glamour is designed with transitions and scripting in mind (thinking 
>>> specially on browsers), while spec is designed for components and 
>>> composition.
>>> 
>>> Esteban
>>> 
 On 04 Oct 2014, at 15:35, Nicolai Hess >>> > wrote:
 
 
 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano >>> >:
 
> On 03 Oct 2014, at 13:14, Nicolai Hess  > wrote:
> 
> 
> Am 03.10.2014 12:34 schrieb "Yuriy Tymchuk"  >:
> >
> > 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 whenSelecte

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


> On 05 Oct 2014, at 13:21, Nicolai Hess  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  >:
> lazy Yury
> 
> 
> browser := GLMTabulator new 
>   row: [ :row | 
>   row 
>   column: #protocols;
>   column: #methods ];
>   row: #code;
>   yourself.
>   
> browser transmit 
>   to: #protocols; 
>   andShow: [ :a| 
>   a list 
>   allowDropOnItem: [:draggedObject :targetItem :list | 
> true ];
>   dropOnItem: [:draggedObject :targetItem :list | 
>   browser entity organization
>   classify: draggedObject
>   under: targetItem name.
>   list update.
>   true ];
>   display: [ :class | class organization protocols ]; 
> format: #name ].
> browser transmit 
>   from: #protocols; 
>   to: #methods; 
>   andShow: [ :a| 
>   a list 
>   allowItemDrag: [:item :list | true ];   
>   display: [ :protocol | protocol methods ] ].
> browser transmit 
>   from: #methods; 
>   to: #code; 
>   andShow: [ :a | 
>   a smalltalkCode 
>   smalltalkClass: [ browser entity ];
>   display: [ :method | (browser entity>>method) 
> sourceCode ] ].
> 
> browser openOn: Morph
> 
>> On 05 Oct 2014, at 10:08, Yuriy Tymchuk > > 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 >> > wrote:
>>> 
>>> and this is same with glamour:
>>> 
>>> browser := GLMTabulator new 
>>> row: [ :row | 
>>> row 
>>> column: #protocols;
>>> column: #methods ];
>>> row: #code;
>>> yourself.
>>> 
>>> browser transmit 
>>> to: #protocols; 
>>> andShow: [ :a| a list display: [ :class | class organization protocols 
>>> ]; format: #name ].
>>> browser transmit 
>>> from: #protocols; 
>>> to: #methods; 
>>> andShow: [ :a| a list display: [ :protocol | protocol methods ] ].
>>> browser transmit 
>>> from: #methods; 
>>> to: #code; 
>>> andShow: [ :a | 
>>> a smalltalkCode 
>>> smalltalkClass: [ browser entity ];
>>> display: [ :method | (browser entity>>method) 
>>> sourceCode ] ].
>>> 
>>> browser openOn: Morph.
>>> 
>>> Of course spec is capable of doing that. 
>>> But glamour is designed with transitions and scripting in mind (thinking 
>>> specially on browsers), while spec is designed for components and 
>>> composition.
>>> 
>>> Esteban
>>> 
 On 04 Oct 2014, at 15:35, Nicolai Hess >>> > wrote:
 
 
 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano >>> >:
 
> On 03 Oct 2014, at 13:14, Nicolai Hess  > wrote:
> 
> 
> Am 03.10.2014 12:34 schrieb "Yuriy Tymchuk"  >:
> >
> > 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).
 compose

Re: [Pharo-dev] GT first impressions

2014-10-05 Thread kmo

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

2014-10-05 Thread Nicolai Hess

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 :

> lazy Yury
>
>
> browser := GLMTabulator new
> row: [ :row |
> row
> column: #protocols;
> column: #methods ];
> row: #code;
> yourself.
> browser transmit
> to: #protocols;
> andShow: [ :a|
> a list
> allowDropOnItem: [:draggedObject :targetItem :list | true ];
> dropOnItem: [:draggedObject :targetItem :list |
> browser entity organization
> classify: draggedObject
> under: targetItem name.
> list update.
> true ];
> display: [ :class | class organization protocols ]; format: #name ].
> browser transmit
> from: #protocols;
> to: #methods;
> andShow: [ :a|
> a list
> allowItemDrag: [:item :list | true ];
> display: [ :protocol | protocol methods ] ].
> browser transmit
> from: #methods;
> to: #code;
> andShow: [ :a |
> a smalltalkCode
> smalltalkClass: [ browser entity ];
> display: [ :method | (browser entity>>method) sourceCode ] ].
>
> browser openOn: Morph
>
> On 05 Oct 2014, at 10:08, Yuriy Tymchuk  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  wrote:
>
> and this is same with glamour:
>
> browser := GLMTabulator new
> row: [ :row |
> row
> column: #protocols;
> column: #methods ];
> row: #code;
> yourself.
> browser transmit
> to: #protocols;
> andShow: [ :a| a list display: [ :class | class organization protocols ];
> format: #name ].
> browser transmit
> from: #protocols;
> to: #methods;
> andShow: [ :a| a list display: [ :protocol | protocol methods ] ].
> browser transmit
> from: #methods;
> to: #code;
> andShow: [ :a |
> a smalltalkCode
> smalltalkClass: [ browser entity ];
> display: [ :method | (browser entity>>method) sourceCode ] ].
>
> browser openOn: Morph.
>
> Of course spec is capable of doing that.
> But glamour is designed with transitions and scripting in mind (thinking
> specially on browsers), while spec is designed for components and
> composition.
>
> Esteban
>
> On 04 Oct 2014, at 15:35, Nicolai Hess  wrote:
>
>
> 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano :
>
>>
>> On 03 Oct 2014, at 13:14, Nicolai Hess  wrote:
>>
>>
>> Am 03.10.2014 12:34 schrieb "Yuriy Tymchuk" :
>> >
>> > 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] History of the .image

2014-10-05 Thread Hilaire

Le 04/10/2014 16:16, David T. Lewis a écrit :
> On Sat, Oct 04, 2014 at 04:00:15PM +0200, Hilaire wrote:
>> Hello,
>>
>> I am curious. What is the history of the Pharo image? I know it is
>> forked from Squeak, but then from where does come the Squeak image?
>> How and when was it build from its source code definition?
>> When did it became an "evolving organism" as it is today?
>>
>> Thanks
>>
>> Hilaire
> 
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-September/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] Inspector steals my Window !

Thanks!

Doru

On Sun, Oct 5, 2014 at 12:12 PM, Andrei Chis 
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  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  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] Inspector steals my Window !

2014-10-05 Thread Andrei Chis

I made the preview tab only show a static picture of the morph and renamed
the title to Morph. Now it's like for Morph and Glamour. Still it seems
that clicking on a morph only works when inspecting Morph objects, and not
Spec or Glamour ones.

On Sun, Oct 5, 2014 at 8:16 AM, Tudor Girba  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  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] "Browser" on a single class

2014-10-05 Thread Sven Van Caekenberghe

Nice ;-)

On 05 Oct 2014, at 11:56, Esteban Lorenzano  wrote:

> lazy Yury
> 
> 
> browser := GLMTabulator new 
>   row: [ :row | 
>   row 
>   column: #protocols;
>   column: #methods ];
>   row: #code;
>   yourself.
>   
> browser transmit 
>   to: #protocols; 
>   andShow: [ :a| 
>   a list 
>   allowDropOnItem: [:draggedObject :targetItem :list | 
> true ];
>   dropOnItem: [:draggedObject :targetItem :list | 
>   browser entity organization
>   classify: draggedObject
>   under: targetItem name.
>   list update.
>   true ];
>   display: [ :class | class organization protocols ]; 
> format: #name ].
> browser transmit 
>   from: #protocols; 
>   to: #methods; 
>   andShow: [ :a| 
>   a list 
>   allowItemDrag: [:item :list | true ];   
>   display: [ :protocol | protocol methods ] ].
> browser transmit 
>   from: #methods; 
>   to: #code; 
>   andShow: [ :a | 
>   a smalltalkCode 
>   smalltalkClass: [ browser entity ];
>   display: [ :method | (browser entity>>method) 
> sourceCode ] ].
> 
> browser openOn: Morph
> 
>> On 05 Oct 2014, at 10:08, Yuriy Tymchuk  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  wrote:
>>> 
>>> and this is same with glamour:
>>> 
>>> browser := GLMTabulator new 
>>> row: [ :row | 
>>> row 
>>> column: #protocols;
>>> column: #methods ];
>>> row: #code;
>>> yourself.
>>> 
>>> browser transmit 
>>> to: #protocols; 
>>> andShow: [ :a| a list display: [ :class | class organization protocols 
>>> ]; format: #name ].
>>> browser transmit 
>>> from: #protocols; 
>>> to: #methods; 
>>> andShow: [ :a| a list display: [ :protocol | protocol methods ] ].
>>> browser transmit 
>>> from: #methods; 
>>> to: #code; 
>>> andShow: [ :a | 
>>> a smalltalkCode 
>>> smalltalkClass: [ browser entity ];
>>> display: [ :method | (browser entity>>method) 
>>> sourceCode ] ].
>>> 
>>> browser openOn: Morph.
>>> 
>>> Of course spec is capable of doing that. 
>>> But glamour is designed with transitions and scripting in mind (thinking 
>>> specially on browsers), while spec is designed for components and 
>>> composition.
>>> 
>>> Esteban
>>> 
 On 04 Oct 2014, at 15:35, Nicolai Hess  wrote:
 
 
 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano :
 
> On 03 Oct 2014, at 13:14, Nicolai Hess  wrote:
> 
> 
> Am 03.10.2014 12:34 schrieb "Yuriy Tymchuk" :
> >
> > 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

Re: [Pharo-dev] GT first impressions

2014-10-05 Thread kilon alios

If I was coding God that was able to code at coding speed 120WPM (Words Per
Minute) then yes I would not even consider using anything but shortcuts but
my speed is more like 120 WPH (Words Per Hour) which is more like 20 lines
of code and that is a very optimistic scenario. So I find myself in many
cases just right clicking , why ?

a) Because using menus does not bother me too much even if it is a bit slow
to using a shortcut and
b) In many cases I tend to forget shortcuts I dont use 24/7. Of course not
copy and paste.

I tried to make my brain fit into the emacs/vim mentality of only using
shortcuts but I keep forgetting stuff or being lazy to go back to
documentation to remember when I can just right click and find what I want.
Plus right clicking has another advantage it shows you the right shortcut
next to the menu option. So for me right click menus and other menus are
beginner and lazy friendly.

On Sun, Oct 5, 2014 at 10:53 AM, Tudor Girba  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 
> wrote:
>
>>
>> On 04 Oct 2014, at 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.
>>
>>
>> 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

lazy Yury


browser := GLMTabulator new 
row: [ :row | 
row 
column: #protocols;
column: #methods ];
row: #code;
yourself.

browser transmit 
to: #protocols; 
andShow: [ :a| 
a list 
allowDropOnItem: [:draggedObject :targetItem :list | 
true ];
dropOnItem: [:draggedObject :targetItem :list | 
browser entity organization
classify: draggedObject
under: targetItem name.
list update.
true ];
display: [ :class | class organization protocols ]; 
format: #name ].
browser transmit 
from: #protocols; 
to: #methods; 
andShow: [ :a| 
a list 
allowItemDrag: [:item :list | true ];   
display: [ :protocol | protocol methods ] ].
browser transmit 
from: #methods; 
to: #code; 
andShow: [ :a | 
a smalltalkCode 
smalltalkClass: [ browser entity ];
display: [ :method | (browser entity>>method) 
sourceCode ] ].

browser openOn: Morph

> On 05 Oct 2014, at 10:08, Yuriy Tymchuk  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 > > wrote:
>> 
>> and this is same with glamour:
>> 
>> browser := GLMTabulator new 
>>  row: [ :row | 
>>  row 
>>  column: #protocols;
>>  column: #methods ];
>>  row: #code;
>>  yourself.
>>  
>> browser transmit 
>>  to: #protocols; 
>>  andShow: [ :a| a list display: [ :class | class organization protocols 
>> ]; format: #name ].
>> browser transmit 
>>  from: #protocols; 
>>  to: #methods; 
>>  andShow: [ :a| a list display: [ :protocol | protocol methods ] ].
>> browser transmit 
>>  from: #methods; 
>>  to: #code; 
>>  andShow: [ :a | 
>>  a smalltalkCode 
>>  smalltalkClass: [ browser entity ];
>>  display: [ :method | (browser entity>>method) 
>> sourceCode ] ].
>> 
>> browser openOn: Morph.
>> 
>> Of course spec is capable of doing that. 
>> But glamour is designed with transitions and scripting in mind (thinking 
>> specially on browsers), while spec is designed for components and 
>> composition.
>> 
>> Esteban
>> 
>>> On 04 Oct 2014, at 15:35, Nicolai Hess >> > wrote:
>>> 
>>> 
>>> 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano >> >:
>>> 
 On 03 Oct 2014, at 13:14, Nicolai Hess >>> > wrote:
 
 
 Am 03.10.2014 12:34 schrieb "Yuriy Tymchuk" >>> >:
 >
 > 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

Re: [Pharo-dev] GT first impressions


> On 05 Oct 2014, at 10:39, Tudor Girba  wrote:
> 
> Hi,
> 
> On Sun, Oct 5, 2014 at 10:04 AM, Esteban Lorenzano  > wrote:
> 
>> On 05 Oct 2014, at 09:55, Tudor Girba > > wrote:
>> 
>> Hi,
>> 
>> On Sun, Oct 5, 2014 at 9:40 AM, Esteban Lorenzano > > wrote:
>> 
>>> On 05 Oct 2014, at 08:43, stepharo >> > 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 
 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)
> 
> When I asked for help, I was more thinking of getting the icons be themeable 
> at the code level - delegate to a themer object :)

yeah, I started. 
Real problem is that I became very ambitious with that (or at least: more 
ambitious than: lets make this work and think later), so I will take a bit more 
of time :P

Esteban

> 
> Cheers,
> Doru
> 
> 
>  
> Esteban
> 
>> 
>> Cheers,
>> Doru
>> 
>> 
>>  
>> Esteban
>> 
>> 
>>> 
 
 Cheers,
 Doru
 
  
 Cheers,

Re: [Pharo-dev] GT first impressions

Hi,

On Sun, Oct 5, 2014 at 10:04 AM, Esteban Lorenzano 
wrote:

>
> On 05 Oct 2014, at 09:55, Tudor Girba  wrote:
>
> Hi,
>
> On Sun, Oct 5, 2014 at 9:40 AM, Esteban Lorenzano 
> wrote:
>
>>
>> On 05 Oct 2014, at 08:43, stepharo  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] Issue 14160: Introduce isXXX dialect testing methods to SmalltalkImage to ease cross-dialect development

2014-10-05 Thread Johan Brichau

It’s true that when you do a lot of cross-dialect development, such a method is 
often what you desire.
However, I think it’s better to do feature detection instead of dialect 
detection. So, something like:

((Smalltalk includesKey: #CharacterWriteStream) ifTrue:[
  stream := CharacterWriteStream on: (String new: 10)
] ifFalse:[
  stream := WriteStream on: (String new: 10)
]

And yes: use Grease where applicable. We try to maintain Grease across Pharo, 
Squeak and Gemstone. I also think it’s actively ported to VA.

cheers
Johan

On 05 Oct 2014, at 09:00, stepharo  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] "Browser" on a single class

2014-10-05 Thread Yuriy Tymchuk

Yes, but as I’ve mentioned earlier, I’m interested in drag-n-drop 
recategorization. I don’t know if it’s doable with glamour.

Uko

> On 04 Oct 2014, at 15:58, Esteban Lorenzano  wrote:
> 
> and this is same with glamour:
> 
> browser := GLMTabulator new 
>   row: [ :row | 
>   row 
>   column: #protocols;
>   column: #methods ];
>   row: #code;
>   yourself.
>   
> browser transmit 
>   to: #protocols; 
>   andShow: [ :a| a list display: [ :class | class organization protocols 
> ]; format: #name ].
> browser transmit 
>   from: #protocols; 
>   to: #methods; 
>   andShow: [ :a| a list display: [ :protocol | protocol methods ] ].
> browser transmit 
>   from: #methods; 
>   to: #code; 
>   andShow: [ :a | 
>   a smalltalkCode 
>   smalltalkClass: [ browser entity ];
>   display: [ :method | (browser entity>>method) 
> sourceCode ] ].
> 
> browser openOn: Morph.
> 
> Of course spec is capable of doing that. 
> But glamour is designed with transitions and scripting in mind (thinking 
> specially on browsers), while spec is designed for components and composition.
> 
> Esteban
> 
>> On 04 Oct 2014, at 15:35, Nicolai Hess > > wrote:
>> 
>> 
>> 2014-10-03 13:26 GMT+02:00 Esteban Lorenzano > >:
>> 
>>> On 03 Oct 2014, at 13:14, Nicolai Hess >> > wrote:
>>> 
>>> 
>>> Am 03.10.2014 12:34 schrieb "Yuriy Tymchuk" >> >:
>>> >
>>> > 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


> On 05 Oct 2014, at 09:55, Tudor Girba  wrote:
> 
> Hi,
> 
> On Sun, Oct 5, 2014 at 9:40 AM, Esteban Lorenzano  > wrote:
> 
>> On 05 Oct 2014, at 08:43, stepharo > > 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 
>>> 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 
>>> 
>>> "Every thing has its own flow"
>> 
> 
> 
> 
> 
> -- 
> 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

Thank you!

Doru

On Sun, Oct 5, 2014 at 8:44 AM, stepharo  wrote:

>  Thanks this is a great initiative.
>
>
>
> On 4/10/14 22:21, Nicolai Hess wrote:
>
>
> 2014-10-04 12:11 GMT+02:00 stepharo :
>
>>
>>  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 
>  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 
>  AthensWrapMorph can not draw TextMorphs
>
>  If we don't port/rewrite all text based morphs, we will have an
> issue with this:
>
>  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 
>  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).
>>>
>>>
>>
>>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] GT first impressions

Hi,

On Sun, Oct 5, 2014 at 9:40 AM, Esteban Lorenzano 
wrote:

>
> On 05 Oct 2014, at 08:43, stepharo  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.

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"

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 
wrote:

>
> On 04 Oct 2014, at 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.
>
>
> 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

Hi,

On Sun, Oct 5, 2014 at 8:43 AM, stepharo  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.
>

It's done :). It took a while because we had to find a suitable code
design, but now Andrei came up with an elegant solution that does not force
us to duplicate code between the presentation, renderer and the text editor.


   - Selecting an instance variable from the "State" tab, completely shift
>> the code view and scrolls to a new Inspector. Is not that I would love to
>> scroll back everytime to get a view on my code.
>>
>
>  The usage depends on the scenario in which you are. In most cases, when
> you do want to drill through many objects, you are likely to only use the
> playground as an entry point. When you build a more elaborate piece of code
> in the playground, you typically do not need to drill too much. In any
> case, if you want to scroll back, there are also keybindings that allow you
> to navigate: Cmd+Alt+Left/Right.
>
>
>>  - I cannot find how to close new Inspector tabs.
>>
>
>  This is a feature that is already planned.
>
>
>>  - "Print it" seems broken. It seems to print evaluation result but
>> suddenly dissapears.
>>
>
>  What do you mean? Can you elaborate on that? Print it should behave like
> here:
>
>
>>  - Debugger buttons Into, Through, etc.
>>
>  -- They are too small and close themselves for the importance they have.
>> -- They have no caption, so you have to mouse over to know what they do
>> (until you get used to)
>> -- They are like "too distant" from the code view.
>>
>
>  The debugger is not in the Pharo image, so I think you are trying the
> Moose image. Is that so?
> In any case, the positioning of the icons will be the same everywhere in
> GT (to the right of the scope they relate to). We are still fiddling with
> the right balance in the debugger.
>
> putting a caption would be a great point.
> why forcing people to learn icons. Icons should be there to help not to
> force learning.
>

The problem is that they would take too much space. This is especially
problematic when you have multiple extra actions (remember that this is
extensible). We have to come up with a different solution somehow, but we
need a bit more time.

Cheers,
Doru




>
>
>  Cheers,
> Doru
>
>
>
>> Cheers,
>>
>> Hernán
>>
>>
>>
>
>
>  --
> www.tudorgirba.com
>
>  "Every thing has its own flow"
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] GT first impressions


> On 05 Oct 2014, at 08:43, stepharo  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 
>> 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.

> 
>>  
>> - Selecting an instance variable from the "State" tab, completely shift the 
>> code view and scrolls to a new Inspector. Is not that I would love to scroll 
>> back everytime to get a view on my code.
>> 
>> The usage depends on the scenario in which you are. In most cases, when you 
>> do want to drill through many objects, you are likely to only use the 
>> playground as an entry point. When you build a more elaborate piece of code 
>> in the playground, you typically do not need to drill too much. In any case, 
>> if you want to scroll back, there are also keybindings that allow you to 
>> navigate: Cmd+Alt+Left/Right.
>>  
>> - I cannot find how to close new Inspector tabs.
>> 
>> This is a feature that is already planned.
>>  
>> - "Print it" seems broken. It seems to print evaluation result but suddenly 
>> dissapears.
>> 
>> What do you mean? Can you elaborate on that? Print it should behave like 
>> here:
>>  
>> - Debugger buttons Into, Through, etc. 
>> -- They are too small and close themselves for the importance they have.
>> -- They have no caption, so you have to mouse over to know what they do 
>> (until you get used to)
>> -- They are like "too distant" from the code view.
>> 
>> The debugger is not in the Pharo image, so I think you are trying the Moose 
>> image. Is that so?
>> In any case, the positioning of the icons will be the same everywhere in GT 
>> (to the right of the scope they relate to). We are still fiddling with the 
>> right balance in the debugger.
> putting a caption would be a great point.
> why forcing people to learn icons. Icons should be there to help not to force 
> learning.

I’m planning to make Doru hate me by replacing all those icons by “themable” 
icons and of course, using eclipse icons for all that actions ;)

Esteban


> 
>> 
>> Cheers,
>> Doru
>> 
>>  
>> Cheers,
>> 
>> Hernán
>> 
>> 
>> 
>> 
>> 
>> -- 
>> www.tudorgirba.com 
>> 
>> "Every thing has its own flow"
>

Re: [Pharo-dev] GT first impressions


> On 04 Oct 2014, at 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 
> 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 
> 
> "Every thing has its own flow"

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