Re: [Pharo-project] Issue 3965 in pharo: Turn off Smart Characters in Full Image by default

[pharo]

Updates:
Status: Closed

Comment #1 on issue 3965 by marcus.d...@gmail.com: Turn off Smart  
Characters in Full Image by default

http://code.google.com/p/pharo/issues/detail?id=3965

maybe not... lets see how many people will complain

Re: [Pharo-project] Issue 3842 in pharo: 1.2 Config needs to load latest code from OB Repository

[pharo]

Updates:
Status: FixProposed

Comment #5 on issue 3842 by marcus.d...@gmail.com: 1.2 Config needs to load  
latest code from OB Repository

http://code.google.com/p/pharo/issues/detail?id=3842

TODO: update Configuration based on the latest packages



(It should be noted that this is only possible after 1.2 was released.  
Before, the latest packages

where compatible to 1.1...)

Re: [Pharo-project] Making layouts using anchors

[Fernando Olivero]

The idea is simple yet powerful, i'm favor.
Can they be somehow integrated into the current layout mechanism?
LayoutPolicy subclass: #AnchorPolicy
Then they are just another option, and the merge could be transparent.
I could add them in the context of SMx.
Fernando

On Thu, Apr 7, 2011 at 8:45 PM, Igor Stasenko  wrote:
> Hi,
>
> i hacked morphs a bit to use anchors for laying out the morphs.
>
> The idea that you can force morph to make one of its edges (left, top,
> bottom, right)
> be dependent from other morph's edge.
>
> Here an example:
>
> | window morph morph2 |
>
> window := StandardWindow labelled: 'foo'.
> window color: Color red.
> morph := Morph new.
>
> morph anchorLeft: window leftAnchor + (window widthAnchor * 0.5) - 20.
> morph anchorRight: window leftAnchor + (window widthAnchor * 0.5) + 20.
> morph anchorTop: window topAnchor + 20.
> morph anchorBottom: window bottomAnchor - 20.
>
> morph2 := Morph new.
> morph2 color: Color green.
>
> morph2 anchorLeft: morph rightAnchor + 10.
> morph2 anchorRight: morph rightAnchor + 50.
> morph2 anchorTop: window topAnchor + 20.
> morph2 anchorBottom: window bottomAnchor - 20.
>
> window addMorph: morph2.
> window addMorph: morph.
>
> window openInWorld.
>
> window extent: 200@200.
>
>
> You can of course implement same layout using proportional layouts
> i.e. you can do
>
> window addMorph: fullFrame: ...
>
> but note that while its okay for first morph you add , a morph2 left
> edge is actually depending on first morph right edge.
> So, if it will be resized by other means (like stretched by inner
> morph), you won't be able to align sibling accordingly,
> and then you are forced to use table layout or something else.
>
> What i like about anchors that it reflects the natural way of thinking
> of UI designer i.e. : "I want this morph to align to window right
> edge"
> or "I want this morph to align to previous morph right edge with 10
> pixels offset"
>
> For example, if i have two morphs, left and right, and i want to put
> my morph in the middle of them to fill the space between them,
> i can simply do:
>
> middle := Morph new.
>
> middle anchorLeft: leftMorph rightAnchor + 10.
> middle anchorRight: rightMorph leftAnchor - 10.
>
> so, you will get a following layout:
>
> [leftMorph] [ 10 pixels ] [ ... middle morph . ] [ 10 pixels ]
> [right morph ]
>
> with just two lines of code!
>
> P.S. Of course , anchors are in conflict with layouts, because you
> cannot have both. But some combination of them could still be used.
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar

[pharo]

Updates:
Status: Duplicate
Mergedinto: 3842

Comment #16 on issue 3754 by marcus.d...@gmail.com: Omnibrowser's an extra  
horizontal scrollbar

http://code.google.com/p/pharo/issues/detail?id=3754

(No comment was entered for this change.)

Re: [Pharo-project] [COTDC] 43 - TextStyleFontSelectorDialogWindow

[Marcus Denker]

On Apr 7, 2011, at 10:23 PM, laurent laffont wrote:

> TextStyleFontSelectorDialogWindow new => error.
> 
> Is it used ??

If it is broken, it is not used.

> Should we remove it ?
> 
things that nobody cares about should be removed. Who will maintain them? 
Nobody.


> 
> For FreeTypeFontSelectorDialogWindow:
> 
> I'm a dialog to select a font. Usage example:
> 
> |fontSelector|
> fontSelector := FreeTypeFontSelectorDialogWindow new.
> UITheme builder openModal: fontSelector.
> fontSelector selectedFont inspect.
> 
> 
> Laurent.
> 
> 
> 
> On Wed, Apr 6, 2011 at 9:52 PM, laurent laffont  
> wrote:
> Today:  TextStyleFontSelectorDialogWindow
> 
> 
> Comment Of The Day Contest - One Day One Comment
> Rules: 
> #1: Each day a not commented class is elected. Each day the best comment will 
> be integrated with name of the author(s).
> #2: If you cannot comment it, deprecate it.
> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest
> 
> Laurent
> 

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Re: [Pharo-project] Issue 3842 in pharo: 1.2 Config needs to load latest code from OB Repository

[pharo]

Updates:
Cc: renggli

Comment #4 on issue 3842 by marcus.d...@gmail.com: 1.2 Config needs to load  
latest code from OB Repository

http://code.google.com/p/pharo/issues/detail?id=3842

Issue 3754 has been merged into this issue.

Re: [Pharo-project] Initial PetitC parser

[Tudor Girba]

Hi Javier,

On 8 Apr 2011, at 05:37, Javier Pimás wrote:

> Hi,
>  I took some time to start developing a C parser with PetitParser. I used 
> the slides of the smalltalk school, they were pretty useful, and after some 
> hours I have a very basic tokens scanner. The idea of this work is to be able 
> to feed the parser with C headers and automagically get the C bindings done 
> in smalltalk.


Nice. I took a quick look. If you want to scale, please write tests (one small 
example per test). Grammars become complex and if you do not have close to 100% 
coverage, you will get stuck.

Cheers,
Doru



> Now I have to actually start doing something with the scanned code. How 
> should I do that, all in the same class? What if I want to generate bindings 
> for different kinds of FFIs? Other question, how should I handle 
> preprocessing? (now there isn't any kind of preprocessing)
> 
> You can see the code, download it and commit improvements to the repo at 
> www.squeaksource.com/Bindings
> 
> Anybody who is interested is welcomed to help in the development!
> 
> Regards,
>   Javier.
> 
> -- 
> Javier Pimás
> Ciudad de Buenos Aires

--
www.tudorgirba.com

"Sometimes the best solution is not the best solution."

Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar

[pharo]

Comment #15 on issue 3754 by renggli: Omnibrowser's an extra horizontal  
scrollbar

http://code.google.com/p/pharo/issues/detail?id=3754

I looked at ConfigurationOfOmniBrowser this morning and it is definitely  
very outdated and mixes incompatible versions. Look at the images I linked  
to see what versions to load. Alternatively you can use the script  
 to  
load a working configuration into a PharoCore image.

Re: [Pharo-project] Issue 3969 in pharo: MorphTreeMorph performance

[pharo]

Comment #4 on issue 3969 by marcus.d...@gmail.com: MorphTreeMorph  
performance

http://code.google.com/p/pharo/issues/detail?id=3969

Issue 3970 has been merged into this issue.

Re: [Pharo-project] Issue 3970 in pharo: Finder broken with last updates related to MorphTreeMorph

[pharo]

Updates:
Status: Duplicate
Mergedinto: 3969

Comment #1 on issue 3970 by marcus.d...@gmail.com: Finder broken with last  
updates related to MorphTreeMorph

http://code.google.com/p/pharo/issues/detail?id=3970

fixed by Issue  3969

Re: [Pharo-project] Issue 3602 in pharo: Code evaluation possible in About box ...

[pharo]

Comment #2 on issue 3602 by fernando...@gmail.com: Code evaluation possible  
in About box ...

http://code.google.com/p/pharo/issues/detail?id=3602

What about reusing the ideas in the TranscriptMorph, to display a Read-Only  
paragraph morph by filling in the contents of a paragraph to a form, then  
displaying the form in the morph?

Take a look at Transcript and TranscriptMorph.
If this idea seems good enough i can implement it.

Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar

[pharo]

Comment #14 on issue 3754 by patchi...@gmail.com: Omnibrowser's an extra  
horizontal scrollbar

http://code.google.com/p/pharo/issues/detail?id=3754

i'm using latest from PharoOB repository the repository the  
configurationOfOB is poiting to. I've loaded  
OmniBrowser-GuillermoPolito.506 and tried  OmniBrowser-lr.505 too.


If this is related to issue 3842 can you point me to OB latest code  
repository?


Thanks

Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar

[pharo]

Comment #13 on issue 3754 by renggli: Omnibrowser's an extra horizontal  
scrollbar

http://code.google.com/p/pharo/issues/detail?id=3754

Maybe this is related to Issue 3842?

Re: [Pharo-project] Issue 3754 in pharo: Omnibrowser's an extra horizontal scrollbar

[pharo]

Comment #12 on issue 3754 by renggli: Omnibrowser's an extra horizontal  
scrollbar

http://code.google.com/p/pharo/issues/detail?id=3754

Looks like you use an outdated OB version. I cannot reproduce. Give it a  
try with any of these images:  
http://jenkins.lukas-renggli.ch/job/Development/

Re: [Pharo-project] Issue 3971 in pharo: OBSystemBrowserAdaptor does not correctly find classes

[pharo]

Updates:
Status: Invalid

Comment #1 on issue 3971 by renggli: OBSystemBrowserAdaptor does not  
correctly find classes

http://code.google.com/p/pharo/issues/detail?id=3971

Sure, it contains it as a sub-string:

A*b*stractA*u*to*t*est*T*estL*o*ngRu*n*

This is a feature.

Re: [Pharo-project] Initial PetitC parser

[Ricardo Moran]

On Fri, Apr 8, 2011 at 12:37 AM, Javier Pimás wrote:

> Hi,
>  I took some time to start developing a C parser with PetitParser. I
> used the slides of the smalltalk school, they were pretty useful, and after
> some hours I have a very basic tokens scanner. The idea of this work is to
> be able to feed the parser with C headers and automagically get the C
> bindings done in smalltalk.
>
>
Hi Javier,

That's a great project and I'm highly interested in it. I'm not experienced
in PetitParser so I won't be a lot of help, but I'll give it a try.


> Now I have to actually start doing something with the scanned code. How
> should I do that, all in the same class? What if I want to generate bindings
> for different kinds of FFIs? Other question, how should I handle
> preprocessing? (now there isn't any kind of preprocessing)
>

Maybe you already thought of this but what if you make your parser build
some simple C AST and then you make specific visitors for each kind of FFI?

Cheers
Richo


>
> You can see the code, download it and commit improvements to the repo at
> www.squeaksource.com/Bindings
>
> Anybody who is interested is welcomed to help in the development!
>
> Regards,
>   Javier.
>
> --
> Javier Pimás
> Ciudad de Buenos Aires
>

Re: [Pharo-project] Initial PetitC parser

[Javier Pimás]

by the way, the grammar is based on

http://www.quut.com/c/ANSI-C-grammar-l-1998.html

and

http://www.quut.com/c/ANSI-C-grammar-y.html

I'd be very grateful if you contribute to cover the full extent of it!


On Fri, Apr 8, 2011 at 12:37 AM, Javier Pimás wrote:

> Hi,
>  I took some time to start developing a C parser with PetitParser. I
> used the slides of the smalltalk school, they were pretty useful, and after
> some hours I have a very basic tokens scanner. The idea of this work is to
> be able to feed the parser with C headers and automagically get the C
> bindings done in smalltalk.
>
> Now I have to actually start doing something with the scanned code. How
> should I do that, all in the same class? What if I want to generate bindings
> for different kinds of FFIs? Other question, how should I handle
> preprocessing? (now there isn't any kind of preprocessing)
>
> You can see the code, download it and commit improvements to the repo at
> www.squeaksource.com/Bindings
>
> Anybody who is interested is welcomed to help in the development!
>
> Regards,
>   Javier.
>
> --
> Javier Pimás
> Ciudad de Buenos Aires
>



-- 
Javier Pimás
Ciudad de Buenos Aires

[Pharo-project] Initial PetitC parser

[Javier Pimás]

Hi,
 I took some time to start developing a C parser with PetitParser. I
used the slides of the smalltalk school, they were pretty useful, and after
some hours I have a very basic tokens scanner. The idea of this work is to
be able to feed the parser with C headers and automagically get the C
bindings done in smalltalk.

Now I have to actually start doing something with the scanned code. How
should I do that, all in the same class? What if I want to generate bindings
for different kinds of FFIs? Other question, how should I handle
preprocessing? (now there isn't any kind of preprocessing)

You can see the code, download it and commit improvements to the repo at
www.squeaksource.com/Bindings

Anybody who is interested is welcomed to help in the development!

Regards,
  Javier.

-- 
Javier Pimás
Ciudad de Buenos Aires

Re: [Pharo-project] [COTDC] 43 - TextStyleFontSelectorDialogWindow

[HwaJong Oh]

Example code your provided in comment reminds me of Google Sketchup Ruby API.

http://code.google.com/apis/sketchup/docs/ourdoc/face.html



UITheme >> newFontSelector used by ComposableMorph, ExampleBuilderMorph,
MorphicUIManager, StandardWindow,TEasilyThemed classes. I'm not sure it can
be removed.




--
View this message in context: 
http://forum.world.st/COTDC-43-TextStyleFontSelectorDialogWindow-tp3431614p3434934.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Re: [Pharo-project] A step toward reducing complexity

[Tudor Girba]

Hi,

I refactored the GLMUITheme to inherit from UITheme. I followed your steps and 
fixed a number of other issues. There are still a couple of places to fix (like 
a remaining orange highlight of the text area), but it is pretty much working.

Cheers,
Doru



On 25 Mar 2011, at 09:08, Tudor Girba wrote:

> Thanks, Doug. This was on my to do list for a long time.
> 
> Just a note: GLMUITheme is part of Glamour. Please do not fork it in Pharo 
> and integrate fixes there because then it will just get messy. I will 
> integrate it in Glamour.
> 
> If you want to evolve it in the context of Pharo, you should rename it an put 
> it in a different package (this would probably make sense anyway).
> 
> Cheers,
> Doru
> 
> 
> On 25 Mar 2011, at 08:44, Stéphane Ducasse wrote:
> 
>> Thanks.
>> May be the windowActiveDropShadowStyle could be just added to the UITheme 
>> class?
>> 
>> Open a bug entry and attach code or slice there so that 
>>  - have a look
>>  - not forget to integrate the fix.
>> 
>> Stef
>> 
>>> Reduce the complexity of user interface themes
>>> 
>>> In general, user interface themes should inherit directly from UITheme, not
>>> from a chain of themes.  When you have a chain of themes, you are stuck with
>>> the intermediate themes, whether you need/use them or not.  Consider
>>> GLMUITheme.  Currently it is under UIThemeWatery2, which is under
>>> UIThemeWatery, which is under UITheme.
>>> 
>>> Some characteristics inherited from the chain are missing, but in principal,
>>> GLMUITheme can be moved directly under UITheme with just 3 changes.
>>> 
>>> 1. Add an instanceVariable 'windowActiveDropShadowStyle'
>>> 
>>> UITheme subclass: #GLMUITheme
>>> instanceVariableNames: 'windowActiveDropShadowStyle'
>>> classVariableNames: ''
>>> poolDictionaries: ''
>>> category: 'Glamour-Morphic-Theme'
>>> 
>>> 2. Add a class method
>>> 
>>> isAbstract
>>> "Answer whether the receiver is considered to be abstract."
>>> ^false
>>> 
>>> 3. Add an instance method
>>> 
>>> windowActiveDropShadowStyle: anObject
>>> "Set the value of windowActiveDropShadowStyle"
>>> windowActiveDropShadowStyle := anObject
>>> 
>>> 
>>> Because GLMOrangeUITheme inherits these changes, it does not need
>>> modification.  
>>> 
>>> 
>>> --
>>> View this message in context: 
>>> http://forum.world.st/A-step-toward-reducing-complexity-tp3404504p3404504.html
>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>>> 
>> 
>> 
> 
> --
> www.tudorgirba.com
> 
> "We are all great at making mistakes."
> 
> 
> 
> 
> 
> 
> 

--
www.tudorgirba.com

"Reasonable is what we are accustomed with."

Re: [Pharo-project] Issue 3969 in pharo: MorphTreeMorph performance

[pharo]

Updates:
Status: FixProposed

Comment #3 on issue 3969 by marcus.d...@gmail.com: MorphTreeMorph  
performance

http://code.google.com/p/pharo/issues/detail?id=3969

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3430 in pharo: SystemProgressMorph possible enh

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #1 on issue 3430 by marcus.d...@gmail.com: SystemProgressMorph  
possible enh

http://code.google.com/p/pharo/issues/detail?id=3430

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3346 in pharo: Socket bug fixes

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #1 on issue 3346 by marcus.d...@gmail.com: Socket bug fixes
http://code.google.com/p/pharo/issues/detail?id=3346

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3135 in pharo: Monticello Browser does not answer to key position

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #2 on issue 3135 by marcus.d...@gmail.com: Monticello Browser does  
not answer to key position

http://code.google.com/p/pharo/issues/detail?id=3135

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3348 in pharo: use #shouldBePrintedAsLiteral instead of #isLiteral when printing or storing characters and arrays

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #2 on issue 3348 by marcus.d...@gmail.com: use  
#shouldBePrintedAsLiteral instead of #isLiteral when printing or storing  
characters and arrays

http://code.google.com/p/pharo/issues/detail?id=3348

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #20 on issue 3436 by marcus.d...@gmail.com: #copyFrom: is broken
http://code.google.com/p/pharo/issues/detail?id=3436

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3782 in pharo: Pangrams

[pharo]

Updates:
Status: FixProposed
Labels: -Milestone-1.3

Comment #2 on issue 3782 by marcus.d...@gmail.com: Pangrams
http://code.google.com/p/pharo/issues/detail?id=3782

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3692 in pharo: Default line-end convention fix

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #6 on issue 3692 by marcus.d...@gmail.com: Default line-end  
convention fix

http://code.google.com/p/pharo/issues/detail?id=3692

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3349 in pharo: Some network fixes

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #2 on issue 3349 by marcus.d...@gmail.com: Some network fixes
http://code.google.com/p/pharo/issues/detail?id=3349

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3073 in pharo: A version of Compiler with support for methods with many arguments including external FFI calls - For inclusion in Pharo 1.2

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #5 on issue 3073 by marcus.d...@gmail.com: A version of Compiler  
with support for methods with many arguments including external FFI calls -  
For inclusion in Pharo 1.2

http://code.google.com/p/pharo/issues/detail?id=3073

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3788 in pharo: Should fix all the menu category of ToolRegistry and deprecate the methods.

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #1 on issue 3788 by marcus.d...@gmail.com: Should fix all the menu  
category of ToolRegistry and deprecate the methods.

http://code.google.com/p/pharo/issues/detail?id=3788

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3649 in pharo: Should check PharoSound and PharoNonCorePackages

[pharo]

Updates:
Status: Closed

Comment #1 on issue 3649 by marcus.d...@gmail.com: Should check PharoSound  
and PharoNonCorePackages

http://code.google.com/p/pharo/issues/detail?id=3649

I think this was done

Re: [Pharo-project] Issue 3698 in pharo: removing caseOf:

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #2 on issue 3698 by marcus.d...@gmail.com: removing caseOf:
http://code.google.com/p/pharo/issues/detail?id=3698

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3670 in pharo: Fixes for Latin1Environment from EToys

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #1 on issue 3670 by marcus.d...@gmail.com: Fixes for  
Latin1Environment from EToys

http://code.google.com/p/pharo/issues/detail?id=3670

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3382 in pharo: BUG: Class variable creation behavior Inconsistent/incorrect

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #4 on issue 3382 by marcus.d...@gmail.com: BUG: Class variable  
creation behavior Inconsistent/incorrect

http://code.google.com/p/pharo/issues/detail?id=3382

(No comment was entered for this change.)

Re: [Pharo-project] Debugging Cog crash

[Igor Stasenko]

On 7 April 2011 23:10, Schwab,Wilhelm K  wrote:
> Hello all,
>
> I have an account on an Ubuntu terminal server (at least I think that's what 
> it would be called) running 10.10.  The Cog one-click image crashes with 
> "Segmentation fault" (if run from a terminal); the legacy VM seems to run the 
> image nicely on the box.  Any ideas?  I will happily collect any facts that 
> will be of help, but I need some
> direction.
>

Post to vm-dev list
And don't forget to specify vm version you using.
:)

> Bill
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.

Re: [Pharo-project] Issue 3549 in pharo: ChooseClassOrTrait

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #3 on issue 3549 by marcus.d...@gmail.com: ChooseClassOrTrait
http://code.google.com/p/pharo/issues/detail?id=3549

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3466 in pharo: Display the leading zero while printing the hexadecimal version of a Character

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #5 on issue 3466 by marcus.d...@gmail.com: Display the leading zero  
while printing the hexadecimal version of a Character

http://code.google.com/p/pharo/issues/detail?id=3466

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3665 in pharo: asStringOrText should invoke asString

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #1 on issue 3665 by marcus.d...@gmail.com: asStringOrText should  
invoke asString

http://code.google.com/p/pharo/issues/detail?id=3665

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3602 in pharo: Code evaluation possible in About box ...

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #1 on issue 3602 by marcus.d...@gmail.com: Code evaluation possible  
in About box ...

http://code.google.com/p/pharo/issues/detail?id=3602

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3548 in pharo: Network changes from Etoy

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #1 on issue 3548 by marcus.d...@gmail.com: Network changes from Etoy
http://code.google.com/p/pharo/issues/detail?id=3548

(No comment was entered for this change.)

[Pharo-project] [TODO 1.3] open issues tagged 1.3

[Marcus Denker]

Hello,

So I went through the bug tracker and removed 1.3 tags from non-essential items.

What is left are 45 issues:

http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D1.3

among them all 25 failing tests of core:


https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompletedBuild/testReport/

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Re: [Pharo-project] Issue 3663 in pharo: XMLWriter and MultiByteFileStream

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #4 on issue 3663 by marcus.d...@gmail.com: XMLWriter and  
MultiByteFileStream

http://code.google.com/p/pharo/issues/detail?id=3663

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3466 in pharo: Display the leading zero while printing the hexadecimal version of a Character

[pharo]

Updates:
Status: Comment

Comment #4 on issue 3466 by marcus.d...@gmail.com: Display the leading zero  
while printing the hexadecimal version of a Character

http://code.google.com/p/pharo/issues/detail?id=3466

(No comment was entered for this change.)

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

[Tudor Girba]

Hi,

On 6 Apr 2011, at 23:03, Igor Stasenko wrote:

> On 6 April 2011 22:54, Tudor Girba  wrote:
>> And if we are at it, how would it be possible to get vertical resizers 
>> between rows?
>> 
> between rows..
> 
> 
>> For example, in the case of GTCoder, I would like to be able to resize the 
>> pane with code inside.
>> 
> 
> i think you'd better do a little different thing.
> You can put a resizer 'grip' into a corner of code pane, and then
> resize code using that grip,
> and parent morph(s) will(or should) adjust themselves accordingly.
> 
> For example you can take a look how gmail web interface works:
> for text areas where i currently typing a message there is a resizer
> grip, using which i can resize the text pane.
> 
> But there is no sizers every row which representing a separate mail in
> this thread. I guess you got an idea.

I got the idea. I mentioned splitters, because I do not know how to get grips 
to work. I tried to poke around a bit but I cannot seem to get the grips work 
on any morph other than window. Do you happen to have an example that makes it 
work?

Cheers,
Doru 

>> Cheers,
>> Doru
>> 
>> 
>> On 6 Apr 2011, at 18:01, Igor Stasenko wrote:
>> 
>>> okay.. i found one bug
>>> 
>>> forgot to add  cellPositioning: #leftCenter;  for colum wrapper morph
>>> 
>>> 
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>> 
>> 
>> --
>> www.tudorgirba.com
>> 
>> "There are no old things, there are only old ways of looking at them."
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.
> 

--
www.tudorgirba.com

"Every successful trip needs a suitable vehicle."

[Pharo-project] Debugging Cog crash

[Schwab,Wilhelm K]

Hello all,

I have an account on an Ubuntu terminal server (at least I think that's what it 
would be called) running 10.10.  The Cog one-click image crashes with 
"Segmentation fault" (if run from a terminal); the legacy VM seems to run the 
image nicely on the box.  Any ideas?  I will happily collect any facts that 
will be of help, but I need some
direction.

Bill

[Pharo-project] 13135 open setting DNU

[stephane ducasse]

props layoutInset asPoint

asPoint DNU on a rectangle.

Stef

Re: [Pharo-project] Making layouts using anchors

[Alexandre Bergel]

thanks

alexandre


On 7 Apr 2011, at 15:37, Igor Stasenko wrote:

> On 7 April 2011 22:11, Alexandre Bergel  wrote:
>> A screenshot ?
>> 
> here
>> Alexandre
>> 
>> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.
> 

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

[Pharo-project] [COTDC] 44 - ColorChanged

[laurent laffont]

 Today:  ColorChanged


Comment Of The Day Contest - One Day One Comment
Rules:
#1: Each day a not commented class is elected. Each day the best comment
will be integrated with name of the author(s).
#2: If you cannot comment it, deprecate it.
Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest

Laurent

Re: [Pharo-project] [COTDC] 43 - TextStyleFontSelectorDialogWindow

[laurent laffont]

TextStyleFontSelectorDialogWindow new => error.

Is it used ?? Should we remove it ?


For FreeTypeFontSelectorDialogWindow:

I'm a dialog to select a font. Usage example:

|fontSelector|
fontSelector := FreeTypeFontSelectorDialogWindow new.
UITheme builder openModal: fontSelector.
fontSelector selectedFont inspect.


Laurent.



On Wed, Apr 6, 2011 at 9:52 PM, laurent laffont
wrote:

>  Today:  TextStyleFontSelectorDialogWindow
>
>
> Comment Of The Day Contest - One Day One Comment
> Rules:
> #1: Each day a not commented class is elected. Each day the best comment
> will be integrated with name of the author(s).
> #2: If you cannot comment it, deprecate it.
> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest
>
> Laurent
>

[Pharo-project] Issue 3971 in pharo: OBSystemBrowserAdaptor does not correctly find classes

[pharo]

Status: New
Owner: 

New issue 3971 by dougedmu...@gmail.com: OBSystemBrowserAdaptor does not  
correctly find classes

http://code.google.com/p/pharo/issues/detail?id=3971

Using:
Pharo1.2.2a
Latest update: #12346
on XP

ObSystemBrowserAdaptor (the "System Browser" window) does not correctly  
find classes:


1. Open system browser, right click, select "Find Classes".
2. Type in 'button'
3. Results include classes that do not contain 'button'. (such as
the first entry, "AbstractAutotestTestLongRun")

Re: [Pharo-project] Issue 2441 in pharo: Strange behavior of Rectangle

[pharo]

Comment #10 on issue 2441 by nicolas@gmail.com: Strange behavior of  
Rectangle

http://code.google.com/p/pharo/issues/detail?id=2441

Hmm, In squeak I enforced the rules saying that rectangle with a negative  
width or height shall be considered empty.


To me vertex:vertex: is the right solution.

Re: [Pharo-project] Metacello chapter

[Stéphane Ducasse]

> Those are separate scenarios:

yes I know.
I just do not know the git commands :)


> 
>>  notify a project I have changes for it?
> 
> Here you are contributor and are informing the original
> author/developer/owner that you have some changes for it to review and
> possibly integrate (that is the pull request: you request the author
> that pull your changes in its repository).
> 
>>  how do I merge changes submitted?
> 
> Here you are the author/developer/owner of the repo and you have a queue
> of pull request to review and possible to integrate changes made from
> some other people.

Re: [Pharo-project] Making layouts using anchors

[Igor Stasenko]

On 7 April 2011 22:11, Alexandre Bergel  wrote:
> A screenshot ?
>
here
> Alexandre
>
>



-- 
Best regards,
Igor Stasenko AKA sig.
<>

Re: [Pharo-project] An idea about Pluggable widgets

[Nicolas Cellier]

2011/4/7 Alain Plantec :
> Le 07/04/2011 19:23, Igor Stasenko a écrit :
>>
>> button1 model: (self for: #performAction adapt: #turnRed)
>> button2 model: (self for: #performAction adapt: #turnGreen)
>
> yes, cool!
> It seems to be a good way to clean morphic
> cheers
> Alain
>
>

Yes, it's delegating the job to specialized objects.
Specialized objects shall know how to.
That should prevent Morphs to be omniscient.

My favourite name for the opposite pattern is "god programming": we
all encountered the thousand lines functions with tons of imbricated
if/switch logic in C or C// world, didn't we ?

Somehow, Igor proposal reminds me the VW UI architecture were they
pushed the wrapper pattern very far.
Personnally, I found myself comfortable with it, but it had its detractors too.
It would be interesting to analyze their arguments.

cheers.

Nicolas

Re: [Pharo-project] Metacello chapter

[Miguel Cobá]

El jue, 07-04-2011 a las 20:44 +0200, Stéphane Ducasse escribió:
> On Apr 7, 2011, at 5:02 PM, Miguel Cobá wrote:
> 
> > El jue, 07-04-2011 a las 09:18 +0200, Stéphane Ducasse escribió:
> >> and so what? I still do not understand it.
> >> may be noury should be added to the project.
> > 
> > A pull is a notice to the original author (whose code the contributor is
> > forking and modifying) to indicate that some changes are made parting
> > from some point in time (the time of forking). Github permits the
> > original author to review the changes and apply them to its own
> > "official" codebase, therefore integrating contributions from others.
> 
> how do I do both

Those are separate scenarios:

>   notify a project I have changes for it?

Here you are contributor and are informing the original
author/developer/owner that you have some changes for it to review and
possibly integrate (that is the pull request: you request the author
that pull your changes in its repository).

>   how do I merge changes submitted?

Here you are the author/developer/owner of the repo and you have a queue
of pull request to review and possible to integrate changes made from
some other people.

Cheers

> > 
> > The nice thing is that everyone can modify what he wants but the
> > original author is the one that takes what it appears good to him for
> > integrating in the official codebase. There is no need to add more
> > people to a "project" because everyone can have its own copy of the
> > project and only share the changes as needed.
> 
> Yes I know the idea.
> 
> > 
> > Cheers
> >> 
> >> 
> >> On Apr 7, 2011, at 3:28 AM, Serge Stinckwich wrote:
> >> 
> >>> https://github.com/SquareBracketAssociates/PharoByExample-english/pull/3
> >>> 
> >>> On Thu, Apr 7, 2011 at 3:10 AM, Stéphane Ducasse
> >>>  wrote:
> > Cool. BTW, I have a pending pull request on the Socket chapter.
>  
>  what is it?
>  what do you mean?
>  what do you need?
>  
>  Stef
>  
>  
> >>> 
> >>> 
> >>> 
> >>> -- 
> >>> Serge Stinckwich
> >>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
> >>> Every DSL ends up being Smalltalk
> >>> http://doesnotunderstand.org/
> >> 
> >> 
> > 
> > -- 
> > Miguel Cobá
> > http://twitter.com/MiguelCobaMtz
> > http://miguel.leugim.com.mx
> > 
> > 
> > 
> > 
> 
> 

-- 
Miguel Cobá
http://twitter.com/MiguelCobaMtz
http://miguel.leugim.com.mx

Re: [Pharo-project] Making layouts using anchors

[Alexandre Bergel]

A screenshot ?

Alexandre


On 7 Apr 2011, at 14:45, Igor Stasenko wrote:

> Hi,
> 
> i hacked morphs a bit to use anchors for laying out the morphs.
> 
> The idea that you can force morph to make one of its edges (left, top,
> bottom, right)
> be dependent from other morph's edge.
> 
> Here an example:
> 
> | window morph morph2 |
> 
> window := StandardWindow labelled: 'foo'.
> window color: Color red.
> morph := Morph new.
> 
> morph anchorLeft: window leftAnchor + (window widthAnchor * 0.5) - 20.
> morph anchorRight: window leftAnchor + (window widthAnchor * 0.5) + 20.
> morph anchorTop: window topAnchor + 20.
> morph anchorBottom: window bottomAnchor - 20.
> 
> morph2 := Morph new.
> morph2 color: Color green.
> 
> morph2 anchorLeft: morph rightAnchor + 10.
> morph2 anchorRight: morph rightAnchor + 50.
> morph2 anchorTop: window topAnchor + 20.
> morph2 anchorBottom: window bottomAnchor - 20.
> 
> window addMorph: morph2.
> window addMorph: morph.
> 
> window openInWorld.
> 
> window extent: 200@200.
> 
> 
> You can of course implement same layout using proportional layouts
> i.e. you can do
> 
> window addMorph: fullFrame: ...
> 
> but note that while its okay for first morph you add , a morph2 left
> edge is actually depending on first morph right edge.
> So, if it will be resized by other means (like stretched by inner
> morph), you won't be able to align sibling accordingly,
> and then you are forced to use table layout or something else.
> 
> What i like about anchors that it reflects the natural way of thinking
> of UI designer i.e. : "I want this morph to align to window right
> edge"
> or "I want this morph to align to previous morph right edge with 10
> pixels offset"
> 
> For example, if i have two morphs, left and right, and i want to put
> my morph in the middle of them to fill the space between them,
> i can simply do:
> 
> middle := Morph new.
> 
> middle anchorLeft: leftMorph rightAnchor + 10.
> middle anchorRight: rightMorph leftAnchor - 10.
> 
> so, you will get a following layout:
> 
> [leftMorph] [ 10 pixels ] [ ... middle morph . ] [ 10 pixels ]
> [right morph ]
> 
> with just two lines of code!
> 
> P.S. Of course , anchors are in conflict with layouts, because you
> cannot have both. But some combination of them could still be used.
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.
> 

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

[Pharo-project] Making layouts using anchors

[Igor Stasenko]

Hi,

i hacked morphs a bit to use anchors for laying out the morphs.

The idea that you can force morph to make one of its edges (left, top,
bottom, right)
be dependent from other morph's edge.

Here an example:

| window morph morph2 |

window := StandardWindow labelled: 'foo'.
window color: Color red.
morph := Morph new.

morph anchorLeft: window leftAnchor + (window widthAnchor * 0.5) - 20.
morph anchorRight: window leftAnchor + (window widthAnchor * 0.5) + 20.
morph anchorTop: window topAnchor + 20.
morph anchorBottom: window bottomAnchor - 20.

morph2 := Morph new.
morph2 color: Color green.

morph2 anchorLeft: morph rightAnchor + 10.
morph2 anchorRight: morph rightAnchor + 50.
morph2 anchorTop: window topAnchor + 20.
morph2 anchorBottom: window bottomAnchor - 20.

window addMorph: morph2.
window addMorph: morph.

window openInWorld.

window extent: 200@200.


You can of course implement same layout using proportional layouts
i.e. you can do

window addMorph: fullFrame: ...

but note that while its okay for first morph you add , a morph2 left
edge is actually depending on first morph right edge.
So, if it will be resized by other means (like stretched by inner
morph), you won't be able to align sibling accordingly,
and then you are forced to use table layout or something else.

What i like about anchors that it reflects the natural way of thinking
of UI designer i.e. : "I want this morph to align to window right
edge"
or "I want this morph to align to previous morph right edge with 10
pixels offset"

For example, if i have two morphs, left and right, and i want to put
my morph in the middle of them to fill the space between them,
i can simply do:

middle := Morph new.

middle anchorLeft: leftMorph rightAnchor + 10.
middle anchorRight: rightMorph leftAnchor - 10.

so, you will get a following layout:

[leftMorph] [ 10 pixels ] [ ... middle morph . ] [ 10 pixels ]
[right morph ]

with just two lines of code!

P.S. Of course , anchors are in conflict with layouts, because you
cannot have both. But some combination of them could still be used.

-- 
Best regards,
Igor Stasenko AKA sig.


anchors.1.cs
Description: Binary data

Re: [Pharo-project] Issue 3424 in pharo: Improved class Tests

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #1 on issue 3424 by marcus.d...@gmail.com: Improved class Tests
http://code.google.com/p/pharo/issues/detail?id=3424

(No comment was entered for this change.)

Re: [Pharo-project] Metacello chapter

[Stéphane Ducasse]

On Apr 7, 2011, at 5:02 PM, Miguel Cobá wrote:

> El jue, 07-04-2011 a las 09:18 +0200, Stéphane Ducasse escribió:
>> and so what? I still do not understand it.
>> may be noury should be added to the project.
> 
> A pull is a notice to the original author (whose code the contributor is
> forking and modifying) to indicate that some changes are made parting
> from some point in time (the time of forking). Github permits the
> original author to review the changes and apply them to its own
> "official" codebase, therefore integrating contributions from others.

how do I do both
notify a project I have changes for it?
how do I merge changes submitted?
> 
> The nice thing is that everyone can modify what he wants but the
> original author is the one that takes what it appears good to him for
> integrating in the official codebase. There is no need to add more
> people to a "project" because everyone can have its own copy of the
> project and only share the changes as needed.

Yes I know the idea.

> 
> Cheers
>> 
>> 
>> On Apr 7, 2011, at 3:28 AM, Serge Stinckwich wrote:
>> 
>>> https://github.com/SquareBracketAssociates/PharoByExample-english/pull/3
>>> 
>>> On Thu, Apr 7, 2011 at 3:10 AM, Stéphane Ducasse
>>>  wrote:
> Cool. BTW, I have a pending pull request on the Socket chapter.
 
 what is it?
 what do you mean?
 what do you need?
 
 Stef
 
 
>>> 
>>> 
>>> 
>>> -- 
>>> Serge Stinckwich
>>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
>>> Every DSL ends up being Smalltalk
>>> http://doesnotunderstand.org/
>> 
>> 
> 
> -- 
> Miguel Cobá
> http://twitter.com/MiguelCobaMtz
> http://miguel.leugim.com.mx
> 
> 
> 
> 

Re: [Pharo-project] Metacello chapter

[Stéphane Ducasse]

noury can you log on git hub so that we can add you to the project?

Stef

On Apr 7, 2011, at 2:59 PM, Noury Bouraqadi wrote:

> I don't know how other authors work.
> Not having write access to the repo, I have to fork, make my changes and then 
> ask the admin of the repo (you + who else) to pull (=> merge) changes I made.
> 
> Noury
> On 7 avr. 2011, at 09:18, Stéphane Ducasse wrote:
> 
>> and so what? I still do not understand it.
>> may be noury should be added to the project.
>> 
>> 
>> On Apr 7, 2011, at 3:28 AM, Serge Stinckwich wrote:
>> 
>>> https://github.com/SquareBracketAssociates/PharoByExample-english/pull/3
>>> 
>>> On Thu, Apr 7, 2011 at 3:10 AM, Stéphane Ducasse
>>>  wrote:
> Cool. BTW, I have a pending pull request on the Socket chapter.
 
 what is it?
 what do you mean?
 what do you need?
 
 Stef
 
 
>>> 
>>> 
>>> 
>>> -- 
>>> Serge Stinckwich
>>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
>>> Every DSL ends up being Smalltalk
>>> http://doesnotunderstand.org/
>> 
>> 
> 
> Noury Bouraqadi
> http://car.mines-douai.fr/noury
> --
> -6th National Conference on
> “Control Architecture of Robots”
> 24-25 may 2011, Grenoble area, France
> http://car2011.inrialpes.fr/
> 
> -19th ESUG International Smalltalk Conference
> 22-26 August 2011, Edinburgh, UK
> http://www.esug.org/Conferences/2011
> 
> -19èmes Journées Francophones sur les Systèmes Multi-Agents (JFSMA’11)
> http://www.univ-valenciennes.fr/congres/jfsma2011/
> 17-19 Octobre 2011, Valenciennes, France
> 
> 
> 
> 
> 
> 

Re: [Pharo-project] Issue 3789 in pharo: convert MenuMorph reference to invoke UIManager

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #4 on issue 3789 by marcus.d...@gmail.com: convert MenuMorph  
reference to invoke UIManager

http://code.google.com/p/pharo/issues/detail?id=3789

(No comment was entered for this change.)

Re: [Pharo-project] filesystem changes

[Stéphane Ducasse]

On Apr 7, 2011, at 7:26 PM, Tudor Girba wrote:

> Hi,
> 
> I noticed that Filesystem changed significantly recently both internally and 
> in package structure (I guess it was Colin - the user says cwp).

yes
we should add a configurationOfFS

> This led to some red tests in Moose that I now fixed. I am writing here to 
> document these changes in case other people are using this nice library.

thanks. 

> From a package point of view Filesystem has now a cool structure with 
> basically each category being in a separate package. Furthermore, the 
> original Filesystem is now empty which might create problems if people are 
> loading it like we do in Moose.
> 
> To get it loading, I created a new baseline (2.0.1-baseline) in the 
> ConfigurationOfFilesystem.

tx!

> There were also some refactorings at the level of the model. Now, 
> FSFilesystem does not have subclasses anymore (e.g., FSDiskFilesystem does 
> not exist anymore). Instead there is a composition with a Store, so you will 
> have FSDiskStore.
> 
> Thus, if before you used something like "FSDiskFilesystem current", now you 
> will have to use "FSDiskStore currentFilesystem"
> 
> That was it.
> 
> Everything is green now in Moose land.
> 
> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com
> 
> "Next time you see your life passing by, say 'hi' and get to know her."
> 
> 
> 
> 

Re: [Pharo-project] Issue 3370 in pharo: NewParagraph and MultiNewParagraph should be merged

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #5 on issue 3370 by marcus.d...@gmail.com: NewParagraph and  
MultiNewParagraph should be merged

http://code.google.com/p/pharo/issues/detail?id=3370

(No comment was entered for this change.)

Re: [Pharo-project] abouth nautilus and the removal of CodeHolder hierarchy

[Stéphane Ducasse]

:) yes this is good to join forces.

Stef

> pd: I've been tackling it from another perspective: less tool based
> and more object based, but for now i'm also into developing the next
> Gaucho. This would be the main driver for me, to port SMx.
> Hopefully we have the same requirements for SystemAnnouncements and
> RPackageOrganizer, and refactorings, and undos, and .

Re: [Pharo-project] Issue 3347 in pharo: simplified and unified String's line-ending changing methods

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #2 on issue 3347 by marcus.d...@gmail.com: simplified and unified  
String's line-ending changing methods

http://code.google.com/p/pharo/issues/detail?id=3347

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3773 in pharo: should get a better completionDialog

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #2 on issue 3773 by marcus.d...@gmail.com: should get a better  
completionDialog

http://code.google.com/p/pharo/issues/detail?id=3773

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3340 in pharo: ThreadSafe DebuggerMethodMap

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #1 on issue 3340 by marcus.d...@gmail.com: ThreadSafe  
DebuggerMethodMap

http://code.google.com/p/pharo/issues/detail?id=3340

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3329 in pharo: Object>>closeTo:

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #3 on issue 3329 by marcus.d...@gmail.com: Object>>closeTo:
http://code.google.com/p/pharo/issues/detail?id=3329

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3497 in pharo: Monticello Browser, +slice doesn't validate for not selecting any package

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #2 on issue 3497 by marcus.d...@gmail.com: Monticello Browser,  
+slice  doesn't validate for not selecting any package

http://code.google.com/p/pharo/issues/detail?id=3497

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3615 in pharo: Debug log should use platform line endings

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #1 on issue 3615 by marcus.d...@gmail.com: Debug log should use  
platform line endings

http://code.google.com/p/pharo/issues/detail?id=3615

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3435 in pharo: Don't draw transparent fillStules

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #1 on issue 3435 by marcus.d...@gmail.com: Don't draw transparent  
fillStules

http://code.google.com/p/pharo/issues/detail?id=3435

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3392 in pharo: Class finder should probably use a different editor

[pharo]

Updates:
Status: Closed
Labels: -Milestone-1.3

Comment #1 on issue 3392 by marcus.d...@gmail.com: Class finder should  
probably use a different editor

http://code.google.com/p/pharo/issues/detail?id=3392

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3766 in pharo: Lets fix this one (which is not broken)

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #2 on issue 3766 by marcus.d...@gmail.com: Lets fix this one (which  
is not broken)

http://code.google.com/p/pharo/issues/detail?id=3766

(No comment was entered for this change.)

Re: [Pharo-project] Issue 3236 in pharo: Cuis DateAndTime Enhancement

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #3 on issue 3236 by marcus.d...@gmail.com: Cuis DateAndTime  
Enhancement

http://code.google.com/p/pharo/issues/detail?id=3236

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2816 in pharo: Improve GeneralScrollPane

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #1 on issue 2816 by marcus.d...@gmail.com: Improve GeneralScrollPane
http://code.google.com/p/pharo/issues/detail?id=2816

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2755 in pharo: Image Save loses Form's color [black becomes transparent]

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #13 on issue 2755 by marcus.d...@gmail.com: Image Save loses Form's  
color [black becomes transparent]

http://code.google.com/p/pharo/issues/detail?id=2755

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2063 in pharo: NumberTest

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #6 on issue 2063 by marcus.d...@gmail.com: NumberTest
http://code.google.com/p/pharo/issues/detail?id=2063

(No comment was entered for this change.)

Re: [Pharo-project] An idea about Pluggable widgets

[Alain Plantec]

Le 07/04/2011 19:23, Igor Stasenko a écrit :

button1 model: (self for: #performAction adapt: #turnRed)
button2 model: (self for: #performAction adapt: #turnGreen)

yes, cool!
It seems to be a good way to clean morphic
cheers
Alain

Re: [Pharo-project] Issue 2498 in pharo: measuring tests speed

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #2 on issue 2498 by marcus.d...@gmail.com: measuring tests speed
http://code.google.com/p/pharo/issues/detail?id=2498

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2454 in pharo: decompiler fix

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #7 on issue 2454 by marcus.d...@gmail.com: decompiler fix
http://code.google.com/p/pharo/issues/detail?id=2454

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2441 in pharo: Strange behavior of Rectangle

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #9 on issue 2441 by marcus.d...@gmail.com: Strange behavior of  
Rectangle

http://code.google.com/p/pharo/issues/detail?id=2441

(No comment was entered for this change.)

Re: [Pharo-project] An idea about Pluggable widgets

[Igor Stasenko]

On 7 April 2011 19:23, Igor Stasenko  wrote:
> On 7 April 2011 18:59, Alain Plantec  wrote:
>> Hi Igor,
>> I'm not sure to understand.
>> As an example:
>> TrafficLight is my model with an action for the red light.
>> If I build a view for it, I can use a Button with #performAction:
>>
>> Button>> performAction
>>    ^ model performAction
>>
>> So, my TrafficLight must implement a #performAction method.
>> Now, if I want also an action for the green light performed when another
>> button is pressed.
>> It means that I've to implement a specific model class for the red and
>> another for the green ?
>
> For that case you use model adapters.
> So, then you do something like:
>
> button1 model: (self for: #performAction adapt: #turnRed)
> button2 model: (self for: #performAction adapt: #turnGreen)
>
> and so, a receiver (which is a model), will receive #turnRed, or
> #turnGreen messages,
> while button will still use same message for model - #performAction
>

or alternatively, we could ask a widget to create and install an
instance of model adaptor
(so it will construct a properly initialized model adaptor, when you
only need to fill the data in it):

(button1 installModelAdaptorFor: self)
   actionSelector: #turnRed.

(button2 installModelAdaptorFor: self)
   actionSelector: #turnGreen.


>> cheers
>> Alain
>>
>>
>> for example, I have a simple UI with two buttons
>>
>> Le 07/04/2011 15:26, Igor Stasenko a écrit :
>>>
>>> I have an idea how to refactor the pluggable morphs mess.
>>>
>>> The main principle behind all pluggables, that you have a model (which
>>> is held in instance variable),
>>> and then morph having additional ivars to speak with this model, which
>>> the selector names you should use
>>> to access certain state from model.
>>>
>>> For example:
>>>
>>> AlignmentMorph subclass: #PluggableButtonMorph
>>>        instanceVariableNames: 'model label getStateSelector actionSelector
>>> getLabelSelector getMenuSelector shortcutCharacter askBeforeChanging
>>> triggerOnMouseDown offColor onColor feedbackColor
>>> showSelectionFeedback allButtons arguments argumentsProvider
>>> argumentsSelector gradientLook enabled actionBlock getColorSelector
>>> getEnabledSelector'
>>>        classVariableNames: 'UseGradientLook'
>>>        poolDictionaries: ''
>>>        category: 'Morphic-Pluggable Widgets'
>>>
>>>
>>> as you can see it is crowded with all those ivars, where part of them
>>> used to speak with model,
>>> and part of them used for keeping flags and additional parameters
>>> which you can customize when creating a button.
>>> getStateSelector actionSelector getLabelSelector getMenuSelector
>>>  arguments argumentsProvider argumentsSelector gradientLook
>>> actionBlock getColorSelector getEnabledSelector
>>>
>>> and this is really messy..
>>> Take a look at code:
>>>
>>> performAction
>>>        "Inform the model that this button has been pressed. Sent by the
>>> controller when this button is pressed. If the button's actionSelector
>>> takes any arguments, they are obtained dynamically by sending the
>>> argumentSelector to the argumentsProvider"
>>>
>>>        enabled ifFalse: [^self].
>>>        askBeforeChanging ifTrue: [model okToChange ifFalse: [^ self]].
>>>        self actionBlock ifNotNil: [ ^ self actionBlock value].
>>>        actionSelector ifNotNil:
>>>                [actionSelector numArgs == 0
>>>                        ifTrue: [model perform: actionSelector]
>>>                        ifFalse:
>>>                                [argumentsProvider ifNotNil:
>>>                                        [arguments := argumentsProvider
>>> perform: argumentsSelector].
>>>                                        model perform: actionSelector
>>> withArguments: arguments]]
>>>
>>>
>>> Now think if we could replace this with simple:
>>>
>>>
>>> performAction
>>>        "Inform the model that this button has been pressed. Sent by the
>>> controller when this button is pressed. If the button's actionSelector
>>> takes any arguments, they are obtained dynamically by sending the
>>> argumentSelector to the argumentsProvider"
>>>
>>>        enabled ifFalse: [^self].
>>>         model performAction.
>>>
>>>
>>> so, in this case, we just put an obligation onto model to perform any
>>> action in response to button clicked,
>>> and button no longer cares about crappy logic how it should send a
>>> message to model
>>> (via action block, via actionSelector ... and whether it should pass
>>> any additional arguments or not..)
>>>
>>> So, in all places which using things in a way like:
>>>
>>> getListItems
>>>   ^ model perform: getListItemsSelector
>>>
>>> now will be replaced with clean:
>>>
>>> getListItems
>>>   ^ model getListItems
>>>
>>> So, a pluggable morph no longer cares about keeping all those
>>> selectors and maintain an obscure logic whether selector is nil or not
>>> nil etc etc..
>>> Let model handle it!
>>>
>>> Then you may ask, what if i have a model, which doesn't implements
>>> such 

Re: [Pharo-project] Issue 2402 in pharo: TCollectionTest and others should provide the collectionClass of the collection under tests

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #2 on issue 2402 by marcus.d...@gmail.com: TCollectionTest and  
others should provide the collectionClass of the collection under tests

http://code.google.com/p/pharo/issues/detail?id=2402

(No comment was entered for this change.)

[Pharo-project] filesystem changes

[Tudor Girba]

Hi,

I noticed that Filesystem changed significantly recently both internally and in 
package structure (I guess it was Colin - the user says cwp). This led to some 
red tests in Moose that I now fixed. I am writing here to document these 
changes in case other people are using this nice library.

From a package point of view Filesystem has now a cool structure with basically 
each category being in a separate package. Furthermore, the original Filesystem 
is now empty which might create problems if people are loading it like we do in 
Moose.

To get it loading, I created a new baseline (2.0.1-baseline) in the 
ConfigurationOfFilesystem.

There were also some refactorings at the level of the model. Now, FSFilesystem 
does not have subclasses anymore (e.g., FSDiskFilesystem does not exist 
anymore). Instead there is a composition with a Store, so you will have 
FSDiskStore.

Thus, if before you used something like "FSDiskFilesystem current", now you 
will have to use "FSDiskStore currentFilesystem"

That was it.

Everything is green now in Moose land.

Cheers,
Doru


--
www.tudorgirba.com

"Next time you see your life passing by, say 'hi' and get to know her."

Re: [Pharo-project] Issue 2438 in pharo: Umlaute äöÜ etc in in file/directory names: UTF8 unicode problem?

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #3 on issue 2438 by marcus.d...@gmail.com: Umlaute äöÜ etc in in  
file/directory names: UTF8 unicode problem?

http://code.google.com/p/pharo/issues/detail?id=2438

(No comment was entered for this change.)

Re: [Pharo-project] An idea about Pluggable widgets

[Igor Stasenko]

On 7 April 2011 18:59, Alain Plantec  wrote:
> Hi Igor,
> I'm not sure to understand.
> As an example:
> TrafficLight is my model with an action for the red light.
> If I build a view for it, I can use a Button with #performAction:
>
> Button>> performAction
>    ^ model performAction
>
> So, my TrafficLight must implement a #performAction method.
> Now, if I want also an action for the green light performed when another
> button is pressed.
> It means that I've to implement a specific model class for the red and
> another for the green ?

For that case you use model adapters.
So, then you do something like:

button1 model: (self for: #performAction adapt: #turnRed)
button2 model: (self for: #performAction adapt: #turnGreen)

and so, a receiver (which is a model), will receive #turnRed, or
#turnGreen messages,
while button will still use same message for model - #performAction

> cheers
> Alain
>
>
> for example, I have a simple UI with two buttons
>
> Le 07/04/2011 15:26, Igor Stasenko a écrit :
>>
>> I have an idea how to refactor the pluggable morphs mess.
>>
>> The main principle behind all pluggables, that you have a model (which
>> is held in instance variable),
>> and then morph having additional ivars to speak with this model, which
>> the selector names you should use
>> to access certain state from model.
>>
>> For example:
>>
>> AlignmentMorph subclass: #PluggableButtonMorph
>>        instanceVariableNames: 'model label getStateSelector actionSelector
>> getLabelSelector getMenuSelector shortcutCharacter askBeforeChanging
>> triggerOnMouseDown offColor onColor feedbackColor
>> showSelectionFeedback allButtons arguments argumentsProvider
>> argumentsSelector gradientLook enabled actionBlock getColorSelector
>> getEnabledSelector'
>>        classVariableNames: 'UseGradientLook'
>>        poolDictionaries: ''
>>        category: 'Morphic-Pluggable Widgets'
>>
>>
>> as you can see it is crowded with all those ivars, where part of them
>> used to speak with model,
>> and part of them used for keeping flags and additional parameters
>> which you can customize when creating a button.
>> getStateSelector actionSelector getLabelSelector getMenuSelector
>>  arguments argumentsProvider argumentsSelector gradientLook
>> actionBlock getColorSelector getEnabledSelector
>>
>> and this is really messy..
>> Take a look at code:
>>
>> performAction
>>        "Inform the model that this button has been pressed. Sent by the
>> controller when this button is pressed. If the button's actionSelector
>> takes any arguments, they are obtained dynamically by sending the
>> argumentSelector to the argumentsProvider"
>>
>>        enabled ifFalse: [^self].
>>        askBeforeChanging ifTrue: [model okToChange ifFalse: [^ self]].
>>        self actionBlock ifNotNil: [ ^ self actionBlock value].
>>        actionSelector ifNotNil:
>>                [actionSelector numArgs == 0
>>                        ifTrue: [model perform: actionSelector]
>>                        ifFalse:
>>                                [argumentsProvider ifNotNil:
>>                                        [arguments := argumentsProvider
>> perform: argumentsSelector].
>>                                        model perform: actionSelector
>> withArguments: arguments]]
>>
>>
>> Now think if we could replace this with simple:
>>
>>
>> performAction
>>        "Inform the model that this button has been pressed. Sent by the
>> controller when this button is pressed. If the button's actionSelector
>> takes any arguments, they are obtained dynamically by sending the
>> argumentSelector to the argumentsProvider"
>>
>>        enabled ifFalse: [^self].
>>         model performAction.
>>
>>
>> so, in this case, we just put an obligation onto model to perform any
>> action in response to button clicked,
>> and button no longer cares about crappy logic how it should send a
>> message to model
>> (via action block, via actionSelector ... and whether it should pass
>> any additional arguments or not..)
>>
>> So, in all places which using things in a way like:
>>
>> getListItems
>>   ^ model perform: getListItemsSelector
>>
>> now will be replaced with clean:
>>
>> getListItems
>>   ^ model getListItems
>>
>> So, a pluggable morph no longer cares about keeping all those
>> selectors and maintain an obscure logic whether selector is nil or not
>> nil etc etc..
>> Let model handle it!
>>
>> Then you may ask, what if i have a model, which doesn't implements
>> such protocol (required for specific pluggable widget).
>> The answer is simple:
>>  - create a pluggable model class for given widget, which wraps around
>> your object and can keeps all those messy 'getLabelSelector'
>> 'getMenuSelector' ,
>> inside and mediates between your model and widget.
>>
>> The benefit of it that widgets code will be much more cleaner.
>> And another benefit is that you know what exact protocol is needed if
>> you want to use your object as a model to given widget (list, button
>> etc).
>

Re: [Pharo-project] Issue 2394 in pharo: Halt

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #6 on issue 2394 by marcus.d...@gmail.com: Halt
http://code.google.com/p/pharo/issues/detail?id=2394

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2398 in pharo: Scoped System Reflection (reconciling BrowserEnvironment)

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #2 on issue 2398 by marcus.d...@gmail.com: Scoped System Reflection  
(reconciling BrowserEnvironment)

http://code.google.com/p/pharo/issues/detail?id=2398

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2388 in pharo: Display graphics in FileList

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #6 on issue 2388 by marcus.d...@gmail.com: Display graphics in  
FileList

http://code.google.com/p/pharo/issues/detail?id=2388

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2374 in pharo: Dragging a .image in a Windows VM raises an error

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #6 on issue 2374 by marcus.d...@gmail.com: Dragging a .image in a  
Windows VM raises an error

http://code.google.com/p/pharo/issues/detail?id=2374

(No comment was entered for this change.)

Re: [Pharo-project] Decode url form with Zinc-HTTP

[Sven Van Caekenberghe]

On 07 Apr 2011, at 17:37, Hernán Morales Durand wrote:

> One more thing, I've tried to install in the new released Pharo with CogVM:
> 
> Gofer new
>   squeaksource: 'ZincHTTPComponents';
>   package: 'ConfigurationOfZincHTTPComponents';
>   load.
> (Smalltalk at: #ConfigurationOfZincHTTPComponents) perform: #load
> 
> and loading manually the latest Zinc-HTTP from the Monticello Browser.
> 
> either way I get errors (attached debugger output from the
> ConfigurationOf script). What is the proper way to install or update
> to the latest version,

As described here: http://homepage.mac.com/svc/Zinc-HTTP-Components/

Gofer it
  squeaksource: 'ZincHTTPComponents';
  package: 'Zinc-HTTP';
  package: 'Zinc-Tests';
  load

should always work and load the latest version.

The class comment of ConfigurationOfZincHTTPComponents says

ConfigurationOfZincHTTPComponents project latestVersion load.

I am no expert, so I'll try to rember to ask this at the next Pharo sprint.

Sven

Re: [Pharo-project] Issue 2349 in pharo: Canonical form for duration

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #3 on issue 2349 by marcus.d...@gmail.com: Canonical form for  
duration

http://code.google.com/p/pharo/issues/detail?id=2349

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2325 in pharo: Sensor shiftPressed always returns false

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #3 on issue 2325 by marcus.d...@gmail.com: Sensor shiftPressed  
always returns false

http://code.google.com/p/pharo/issues/detail?id=2325

(No comment was entered for this change.)

Re: [Pharo-project] An idea about Pluggable widgets

[Alain Plantec]

Hi Igor,
I'm not sure to understand.
As an example:
TrafficLight is my model with an action for the red light.
If I build a view for it, I can use a Button with #performAction:

Button>> performAction
^ model performAction

So, my TrafficLight must implement a #performAction method.
Now, if I want also an action for the green light performed when another 
button is pressed.
It means that I've to implement a specific model class for the red and 
another for the green ?

cheers
Alain





for example, I have a simple UI with two buttons

Le 07/04/2011 15:26, Igor Stasenko a écrit :

I have an idea how to refactor the pluggable morphs mess.

The main principle behind all pluggables, that you have a model (which
is held in instance variable),
and then morph having additional ivars to speak with this model, which
the selector names you should use
to access certain state from model.

For example:

AlignmentMorph subclass: #PluggableButtonMorph
instanceVariableNames: 'model label getStateSelector actionSelector
getLabelSelector getMenuSelector shortcutCharacter askBeforeChanging
triggerOnMouseDown offColor onColor feedbackColor
showSelectionFeedback allButtons arguments argumentsProvider
argumentsSelector gradientLook enabled actionBlock getColorSelector
getEnabledSelector'
classVariableNames: 'UseGradientLook'
poolDictionaries: ''
category: 'Morphic-Pluggable Widgets'


as you can see it is crowded with all those ivars, where part of them
used to speak with model,
and part of them used for keeping flags and additional parameters
which you can customize when creating a button.
getStateSelector actionSelector getLabelSelector getMenuSelector
  arguments argumentsProvider argumentsSelector gradientLook
actionBlock getColorSelector getEnabledSelector

and this is really messy..
Take a look at code:

performAction
"Inform the model that this button has been pressed. Sent by the
controller when this button is pressed. If the button's actionSelector
takes any arguments, they are obtained dynamically by sending the
argumentSelector to the argumentsProvider"

enabled ifFalse: [^self].
askBeforeChanging ifTrue: [model okToChange ifFalse: [^ self]].
self actionBlock ifNotNil: [ ^ self actionBlock value].
actionSelector ifNotNil:
[actionSelector numArgs == 0
ifTrue: [model perform: actionSelector]
ifFalse:
[argumentsProvider ifNotNil:
[arguments := argumentsProvider 
perform: argumentsSelector].
model perform: actionSelector 
withArguments: arguments]]


Now think if we could replace this with simple:


performAction
"Inform the model that this button has been pressed. Sent by the
controller when this button is pressed. If the button's actionSelector
takes any arguments, they are obtained dynamically by sending the
argumentSelector to the argumentsProvider"

enabled ifFalse: [^self].
 model performAction.


so, in this case, we just put an obligation onto model to perform any
action in response to button clicked,
and button no longer cares about crappy logic how it should send a
message to model
(via action block, via actionSelector ... and whether it should pass
any additional arguments or not..)

So, in all places which using things in a way like:

getListItems
   ^ model perform: getListItemsSelector

now will be replaced with clean:

getListItems
   ^ model getListItems

So, a pluggable morph no longer cares about keeping all those
selectors and maintain an obscure logic whether selector is nil or not
nil etc etc..
Let model handle it!

Then you may ask, what if i have a model, which doesn't implements
such protocol (required for specific pluggable widget).
The answer is simple:
  - create a pluggable model class for given widget, which wraps around
your object and can keeps all those messy 'getLabelSelector'
'getMenuSelector' ,
inside and mediates between your model and widget.

The benefit of it that widgets code will be much more cleaner.
And another benefit is that you know what exact protocol is needed if
you want to use your object as a model to given widget (list, button
etc).
And in most of the cases, you don't need to use this messy
'getXYZSelector', because you can simply answer to messages sent by
widget and provide
necessary data.
But if you wanna go messy, you just use wrapper model, which contains
all those 'getXYZSelectors'  which you can set to whatever you like.

Re: [Pharo-project] Issue 2269 in pharo: Smalltalk appendChangesTo: 'myfile.sources'

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #4 on issue 2269 by marcus.d...@gmail.com:  Smalltalk  
appendChangesTo: 'myfile.sources'

http://code.google.com/p/pharo/issues/detail?id=2269

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2265 in pharo: to check MCWorkingCopyBrowser from Squeak

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #4 on issue 2265 by marcus.d...@gmail.com: to check  
MCWorkingCopyBrowser from Squeak

http://code.google.com/p/pharo/issues/detail?id=2265

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2262 in pharo: Pragma Package

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #5 on issue 2262 by marcus.d...@gmail.com: Pragma Package
http://code.google.com/p/pharo/issues/detail?id=2262

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2254 in pharo: sorted and sorted: should be moved to TSortable

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #4 on issue 2254 by marcus.d...@gmail.com: sorted and sorted:  
should be moved to TSortable

http://code.google.com/p/pharo/issues/detail?id=2254

(No comment was entered for this change.)

Re: [Pharo-project] Issue 2235 in pharo: Character č is represented as new line

[pharo]

Updates:
Labels: -Milestone-1.3

Comment #9 on issue 2235 by marcus.d...@gmail.com: Character č is  
represented as new line

http://code.google.com/p/pharo/issues/detail?id=2235

(No comment was entered for this change.)