Re: [Pharo-project] Load OB
On Jan 25, 2011, at 8:04 AM, Fernando Olivero wrote: How can i load OB into a clean Pharo image? it used to be Refactoring Gofer new squeaksource: 'rb'; package: 'AST-Core'; package: 'Refactoring-Core'; package: 'Refactoring-Changes'; package: 'Refactoring-Critics'; package: 'Refactoring-Environment'; load. OmniBrowser Gofer new renggli: 'omnibrowser'; package: 'OmniBrowser'; package: 'OB-Standard'; package: 'OB-Morphic'; package: 'OB-Refactory'; load. but now in 1.2 this gives an error message when opening the browser... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Issue 3513 in pharo: Failing Test:ClosureTests.testWhileWithTempIsNil
Updates: Status: Fixed Comment #3 on issue 3513 by marcus.d...@gmail.com: Failing Test:ClosureTests.testWhileWithTempIsNil http://code.google.com/p/pharo/issues/detail?id=3513 as this bug is in 1.0 and 1.1 (and nobody ever had a problem...) Let's move it to 1.3 TODO 1.2: delete test
Re: [Pharo-project] Issue 3589 in pharo: ClassComment in OB
Updates: Labels: -Milestone-1.2 Milestone-1.2-DevImage Comment #2 on issue 3589 by marcus.d...@gmail.com: ClassComment in OB http://code.google.com/p/pharo/issues/detail?id=3589 (No comment was entered for this change.)
Re: [Pharo-project] Issue 3583 in pharo: Shout should only be active in code panes
Updates: Labels: Milestone-1.3 Comment #6 on issue 3583 by marcus.d...@gmail.com: Shout should only be active in code panes http://code.google.com/p/pharo/issues/detail?id=3583 (No comment was entered for this change.)
Re: [Pharo-project] Issue 3051 in pharo: ContextPartobjectSize
Updates: Status: Fixed Labels: Milestone-1.3 Comment #2 on issue 3051 by marcus.d...@gmail.com: ContextPartobjectSize http://code.google.com/p/pharo/issues/detail?id=3051 (No comment was entered for this change.)
Re: [Pharo-project] Issue 3513 in pharo: Failing Test:ClosureTests.testWhileWithTempIsNil
Updates: Labels: -Milestone-1.2 Comment #4 on issue 3513 by marcus.d...@gmail.com: Failing Test:ClosureTests.testWhileWithTempIsNil http://code.google.com/p/pharo/issues/detail?id=3513 (No comment was entered for this change.)
Re: [Pharo-project] Issue 2360 in pharo: nil out locals in a block if readBeforeWritten
Comment #11 on issue 2360 by marcus.d...@gmail.com: nil out locals in a block if readBeforeWritten http://code.google.com/p/pharo/issues/detail?id=2360 Issue 3513 has been merged into this issue.
Re: [Pharo-project] [Pharo-users] Infinite loop is not stopped by Cmd+.
On 24.01.2011 23:34, Mariano Martinez Peck wrote: I could reproduce it. Myabe I am saying something stupid, but didn't Cmd+. depends on the process priority? I mean, if the loop was caused by a Process with higher priority than Cmd+. then it cannot be interrupted. can someone help? cheers mariano InputFetcher runs at 60, UI at 40. Only if infinite loop was in process with pri = 60 should this possibly happen. It works on windows in 1.1.1 and 1.2core, which platform did you test on? Cheers, Henry
[Pharo-project] [update 1.2] #12321
12321 - Issue 3513:Failing Test:ClosureTests.testWhileWithTempIsNil (workaround, moved to 1.3) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Issue 3513 in pharo: Failing Test:ClosureTests.testWhileWithTempIsNil
Updates: Status: Duplicate Mergedinto: 2360 Comment #5 on issue 3513 by marcus.d...@gmail.com: Failing Test:ClosureTests.testWhileWithTempIsNil http://code.google.com/p/pharo/issues/detail?id=3513 (No comment was entered for this change.)
Re: [Pharo-project] Issue 2360 in pharo: [Failing Test] nil out locals in a block if readBeforeWritten
Updates: Summary: [Failing Test] nil out locals in a block if readBeforeWritten Comment #12 on issue 2360 by marcus.d...@gmail.com: [Failing Test] nil out locals in a block if readBeforeWritten http://code.google.com/p/pharo/issues/detail?id=2360 (No comment was entered for this change.)
Re: [Pharo-project] Hapao for Test coverage!
Thank you very much for your help :) On Mon, Jan 24, 2011 at 10:26 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: This is cool to have news! Excellent idea. I will try to help you to post regularly. On Jan 24, 2011, at 11:01 AM, Marcus Denker wrote: On Thu, Jan 20, 2011 at 6:41 PM, Vanessa Peña vane.c.p...@gmail.com wrote: Hello all, We are happy to introduce you Hapao, an innovative test coverage tool which gives you an intuitive graphical representation to visually assess the quality of the coverage. For more information and download you can visit us at: http://hapao.dcc.uchile.cl/ Of course, all feedback is always welcome :) Very nice! One small thing: the dialog selecting the packages at the beginning should label the button continue, not terminate (which sounds like cancel to me). I added a blog post: http://pharo-project.org/news -- Marcus Denker -- den...@acm.org http://www.marcusdenker.de
Re: [Pharo-project] What about a little rename in MouseEvent?
Lukas Renggli wrote: ... AFAIK, most operating systems number the mouse buttons. - The primary button is what you use to perform actions (typically left mouse button). - The secondary buttons is what you use to open context menu (typically right mouse button). - The third button is the middle button, the fourth button, ... Now I see that numbers are not that far from colors, but at least they have a logical order. I don't like #select, #menu, #extra because I does not make sense in any other context (for example games, or touch applications) than a traditional GUI. Agree, on one side there are the physical buttons (button 1, 2, 3 etc) and on the other hand there are the events they trigger. e.g. for right-handed people button 1 would be the primary button where for left-handed this could very well be button 3. Then again, maybe it is time to look a bit further as it looks like the near future is heading towards a world without any physical buttons where there is no need to number or name buttons at all :) http://www.geek.com/articles/gadgets/new-apple-patent-puts-a-display-on-the-magic-mouse-20110124/ Additional gesture events: http://www.youtube.com/watch?v=JKlkte1aOOw -- View this message in context: http://forum.world.st/What-about-a-little-rename-in-MouseEvent-tp3233363p3235798.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] collapsing panes
Hi Doru,
The weight should be applied to the expanders themselves...
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 3;
expanded: true.
Regards, Gary
- Original Message -
From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 9:14 PM
Subject: Re: [Pharo-project] collapsing panes
Hi Gary,
On 24 Jan 2011, at 16:16, Gary Chambers wrote:
Hi,
I don't think the layouts can be merged, as such, as they have very
different
approaches.
With the TableLayout, it is possible to assign weights to each spaceFill
section to get what you want, I think. (see #spaceFillWeight:)
I tried to use it, but I get no effect when I use it in your example.
Below is one of my trouts (added spaceFillWeight: 10 to morph2). What am I
doing wrong?
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill;
spaceFillWeight: 10.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1) expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2) expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) expanded: true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex2.
container := UITheme builder newColumn: { ex1. sp1. ex2. sp2. ex3}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Cheers,
Doru
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 2:32 PM
Subject: Re: [Pharo-project] collapsing panes
Thanks a lot, Gary! I gave it a try and it does go in the wanted
direction.
Now, the next question. I see that you are using a TableLayout. Is there a
way to specify a proportion (like in the proportional layout?) for the
initial extent of the inner panes?
If yes, then I suppose we could merge the two layouts into one.
Cheers,
Doru
On 24 Jan 2011, at 14:51, Benjamin wrote:
I love that :)
It could be very useful ^^
Ben
On Jan 24, 2011, at 2:36 PM, Gary Chambers wrote:
Tricky...
Just an experiment, but try the following after filing in attached
change set.
Can make the re-proportioning explicit and maybe fix things to constrain
to
the owner morph if interested...
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color
yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
expanded: true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex2.
container := UITheme builder newColumn: {
ex1.
sp1.
ex2.
sp2.
ex3}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Have a play/fun.
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr Development
pharo-project@lists.gforge.inria.fr
Sent: Friday, January 21, 2011 11:18 PM
Subject: [Pharo-project] collapsing panes
Hi,
I have a question about how to obtain an effect similar to minimizing a
pane in Eclipse. Let's consider the example from below. I have a
ProportionalLayout because I want to fill the entire space and be able
to resize the inside panes. Now, I would also like to have some way of
collapsing one of the panes and have the rest resize to fill the rest of
the space. It's a bit like I would need some part of a behavior from the
TableLayout.
Can anyone provide me
Re: [Pharo-project] Issue 2864 in pharo: Windows frozen after restart
Updates: Status: Closed Comment #3 on issue 2864 by marcus.d...@gmail.com: Windows frozen after restart http://code.google.com/p/pharo/issues/detail?id=2864 I can not reproduce in 1.2
Re: [Pharo-project] Issue 1042 in pharo: documentation/help menu
Updates: Status: Fixed Comment #16 on issue 1042 by marcus.d...@gmail.com: documentation/help menu http://code.google.com/p/pharo/issues/detail?id=1042 (No comment was entered for this change.)
[Pharo-project] Issue 3593 in pharo: NoneInteractive UIManager
Status: Fixed Owner: marcus.d...@gmail.com Labels: Milestone-1.3 New issue 3593 by marcus.d...@gmail.com: NoneInteractive UIManager http://code.google.com/p/pharo/issues/detail?id=3593 attached Attachments: NonInteractiveTools.4.cs 24.0 KB
Re: [Pharo-project] Issue 3593 in pharo: NoneInteractive UIManager
Comment #1 on issue 3593 by marcus.d...@gmail.com: NoneInteractive UIManager http://code.google.com/p/pharo/issues/detail?id=3593 updated (and tested) version Attachments: NonInteractiveTools.2.cs 16.3 KB
Re: [Pharo-project] Issue 3593 in pharo: NoneInteractive UIManager
Comment #2 on issue 3593 by marcus.d...@gmail.com: NoneInteractive UIManager http://code.google.com/p/pharo/issues/detail?id=3593 ups Attachments: NonInteractiveTools.5.cs 16.3 KB
Re: [Pharo-project] Issue 3593 in pharo: NoneInteractive UIManager
Updates: Status: Closed Comment #3 on issue 3593 by marcus.d...@gmail.com: NoneInteractive UIManager http://code.google.com/p/pharo/issues/detail?id=3593 13018
Re: [Pharo-project] Issue 3051 in pharo: ContextPartobjectSize
Updates: Status: Closed Comment #3 on issue 3051 by marcus.d...@gmail.com: ContextPartobjectSize http://code.google.com/p/pharo/issues/detail?id=3051 13018
Re: [Pharo-project] Issue 3335 in pharo: [Kernel Dependencies] Number@
Updates: Status: Closed Labels: Milestone-1.3 Comment #3 on issue 3335 by marcus.d...@gmail.com: [Kernel Dependencies] Number@ http://code.google.com/p/pharo/issues/detail?id=3335 13018
Re: [Pharo-project] Load OB
Take a look at the last ConfigurationOfOmnibrowser in MetacelloRepository. Guille On Tue, Jan 25, 2011 at 5:08 AM, Marcus Denker marcus.den...@inria.frwrote: On Jan 25, 2011, at 8:04 AM, Fernando Olivero wrote: How can i load OB into a clean Pharo image? it used to be Refactoring Gofer new squeaksource: 'rb'; package: 'AST-Core'; package: 'Refactoring-Core'; package: 'Refactoring-Changes'; package: 'Refactoring-Critics'; package: 'Refactoring-Environment'; load. OmniBrowser Gofer new renggli: 'omnibrowser'; package: 'OmniBrowser'; package: 'OB-Standard'; package: 'OB-Morphic'; package: 'OB-Refactory'; load. but now in 1.2 this gives an error message when opening the browser... -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] debugger problems?
Hi Doru, Yes, I experienced that too. But I never track this bug. #Luc 2011/1/25 Tudor Girba tudor.gi...@gmail.com Hi, From time to time, I seem to get confused in the Debugger because somehow the current selection does not seem to reflect the execution point. Is it just me, or are there others that encountered this problem as well? Cheers, Doru -- www.tudorgirba.com Every thing should have the right to be different.
[Pharo-project] problem starting up with a script on windows
Hi, There seems to be a problem with starting a Pharo 1.2-based image with an initial .st script on Windows. The problem seems to be in CodeLoaderinstallSourceFiles and it is related to the contentStream retrieved from the HTTPDownloadRequest being nil. I attached the debug.log. I checked the paths and they are all correct. In fact, if I run the same script with a Pharo 1.1.1 image, everything works as expected. I also tried to drag and drop the .st script and again, everything works as expected. So, it seems that there is some initialization problem. I cannot debug well because I do not have a Windows machine (the situation happens on a server that I cannot access easily). Can someone take a look to see if the problem can be reproduced? Cheers, Doru -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal. PharoDebug.log Description: Binary data
Re: [Pharo-project] debugger problems?
I am not alone! :) Anyone else noticed this? I forgot to mention that I am using a Pharo image, not a Core one. Cheers, Doru On 25 Jan 2011, at 14:02, Luc Fabresse wrote: Hi Doru, Yes, I experienced that too. But I never track this bug. #Luc 2011/1/25 Tudor Girba tudor.gi...@gmail.com Hi, From time to time, I seem to get confused in the Debugger because somehow the current selection does not seem to reflect the execution point. Is it just me, or are there others that encountered this problem as well? Cheers, Doru -- www.tudorgirba.com Every thing should have the right to be different. -- www.tudorgirba.com Every thing should have the right to be different.
Re: [Pharo-project] Hapao for Test coverage!
Very nice tool. I encountered the same bug mentioned by Lukas in Profiler#runningUnitTests:atEachTestEvaluate: I think you just have to reject abstract classes from the sunitClasses collection. On Tue, Jan 25, 2011 at 10:57 AM, Vanessa Peña vane.c.p...@gmail.comwrote: Thank you very much for your help :) On Mon, Jan 24, 2011 at 10:26 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: This is cool to have news! Excellent idea. I will try to help you to post regularly. On Jan 24, 2011, at 11:01 AM, Marcus Denker wrote: On Thu, Jan 20, 2011 at 6:41 PM, Vanessa Peña vane.c.p...@gmail.com wrote: Hello all, We are happy to introduce you Hapao, an innovative test coverage tool which gives you an intuitive graphical representation to visually assess the quality of the coverage. For more information and download you can visit us at: http://hapao.dcc.uchile.cl/ Of course, all feedback is always welcome :) Very nice! One small thing: the dialog selecting the packages at the beginning should label the button continue, not terminate (which sounds like cancel to me). I added a blog post: http://pharo-project.org/news -- Marcus Denker -- den...@acm.org http://www.marcusdenker.de -- Gaëtan Le Brun www.linkedin.com/in/gaetanlebrun The best way to predict the future is to invent it., A.Kay, 1971
Re: [Pharo-project] debugger problems?
I also experience a lot of problem with instances variable and guessting its type. Time to time, I cannot type or accept Alexandre On 25 Jan 2011, at 10:05, Tudor Girba wrote: I am not alone! :) Anyone else noticed this? I forgot to mention that I am using a Pharo image, not a Core one. Cheers, Doru On 25 Jan 2011, at 14:02, Luc Fabresse wrote: Hi Doru, Yes, I experienced that too. But I never track this bug. #Luc 2011/1/25 Tudor Girba tudor.gi...@gmail.com Hi, From time to time, I seem to get confused in the Debugger because somehow the current selection does not seem to reflect the execution point. Is it just me, or are there others that encountered this problem as well? Cheers, Doru -- www.tudorgirba.com Every thing should have the right to be different. -- www.tudorgirba.com Every thing should have the right to be different. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
[Pharo-project] Cairo graphics and pango
Hi, a question to the maintainers of the Cairographics / pango repo in squeaksource. 1) in what OS are you using it? 2) Does it have a Morphic binding or are you using it to create/output pdf and svg files? Thanks, Fernando
[Pharo-project] why does monticello updates accessing web when i save on dir?
Saving packages in my local directory repository and then copying them to the squeaksource is my pattern of work since Squeak. But, when I apply that pattern, Pharo accesses web everytime i save a version taking long time. Is this behavior have some meaning or is it some sort of side effect? Best Regards -- View this message in context: http://forum.world.st/why-does-monticello-updates-accessing-web-when-i-save-on-dir-tp3236185p3236185.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Hapao for Test coverage!
I encountered the same bug mentioned by Lukas in Profiler#runningUnitTests:atEachTestEvaluate: The problem should now have disappeared. I think you just have to reject abstract classes from the sunitClasses collection. True. We will fix this. http://code.google.com/p/moose-technology/issues/detail?id=503 Cheers, Alexandre On Tue, Jan 25, 2011 at 10:57 AM, Vanessa Peña vane.c.p...@gmail.com wrote: Thank you very much for your help :) On Mon, Jan 24, 2011 at 10:26 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: This is cool to have news! Excellent idea. I will try to help you to post regularly. On Jan 24, 2011, at 11:01 AM, Marcus Denker wrote: On Thu, Jan 20, 2011 at 6:41 PM, Vanessa Peña vane.c.p...@gmail.com wrote: Hello all, We are happy to introduce you Hapao, an innovative test coverage tool which gives you an intuitive graphical representation to visually assess the quality of the coverage. For more information and download you can visit us at: http://hapao.dcc.uchile.cl/ Of course, all feedback is always welcome :) Very nice! One small thing: the dialog selecting the packages at the beginning should label the button continue, not terminate (which sounds like cancel to me). I added a blog post: http://pharo-project.org/news -- Marcus Denker -- den...@acm.org http://www.marcusdenker.de -- Gaëtan Le Brun www.linkedin.com/in/gaetanlebrun The best way to predict the future is to invent it., A.Kay, 1971 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] problem starting up with a script on windows
I managed to debug some more and the problem seems to be introduced by System-Download after the version System-Download-StephaneDucasse.51. If you try any of the newer version, you should get the error. Ah, one more detail: I worked on a Windows Server 2008 R2 using a Cog VM (both r2316 and r2348). It would be great if someone else could confirm. Cheers, Doru On 25 Jan 2011, at 14:04, Tudor Girba wrote: Hi, There seems to be a problem with starting a Pharo 1.2-based image with an initial .st script on Windows. The problem seems to be in CodeLoaderinstallSourceFiles and it is related to the contentStream retrieved from the HTTPDownloadRequest being nil. I attached the debug.log. I checked the paths and they are all correct. In fact, if I run the same script with a Pharo 1.1.1 image, everything works as expected. I also tried to drag and drop the .st script and again, everything works as expected. So, it seems that there is some initialization problem. I cannot debug well because I do not have a Windows machine (the situation happens on a server that I cannot access easily). Can someone take a look to see if the problem can be reproduced? Cheers, Doru -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal. PharoDebug.log -- www.tudorgirba.com Relationships are of two kinds: those we choose and those that happen. They both matter.
Re: [Pharo-project] Issue 3573 in pharo: Failing Test: CompiledMethodTest.testPerformInSuperclassCanExecutelongMethodWithTemps
Comment #1 on issue 3573 by marcus.d...@gmail.com: Failing Test: CompiledMethodTest.testPerformInSuperclassCanExecutelongMethodWithTemps http://code.google.com/p/pharo/issues/detail?id=3573 See Issue 3468
[Pharo-project] Issue 3594 in pharo: Expander needs tweaking to enable resize in a TableLayout
Status: Accepted
Owner: tudor.gi...@gmail.com
Labels: Milestone-1.2 Type-RequestForEnhancement
New issue 3594 by tudor.gi...@gmail.com: Expander needs tweaking to enable
resize in a TableLayout
http://code.google.com/p/pharo/issues/detail?id=3594
The attached change set from Gary makes the following code to work:
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 2;
expanded: true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex2.
container := UITheme builder newColumn: { ex1. sp1. ex2. sp2. ex3}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Re: [Pharo-project] collapsing panes
Ahh, indeed! My bad. Thanks Gary.
The main issue that seems to be left is the resizing. Currently, resizing
propagates the changes to all the following morphs. This is great when the
table layout is inside a GeneralScrollPane, but it leads to a bit of an odd
behavior when stretching inside a bounded morph. Is there an easy option to
change the behavior of the resizer?
Cheers,
Doru
On 25 Jan 2011, at 12:07, Gary Chambers wrote:
Hi Doru,
The weight should be applied to the expanders themselves...
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 3;
expanded: true.
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 9:14 PM
Subject: Re: [Pharo-project] collapsing panes
Hi Gary,
On 24 Jan 2011, at 16:16, Gary Chambers wrote:
Hi,
I don't think the layouts can be merged, as such, as they have very different
approaches.
With the TableLayout, it is possible to assign weights to each spaceFill
section to get what you want, I think. (see #spaceFillWeight:)
I tried to use it, but I get no effect when I use it in your example.
Below is one of my trouts (added spaceFillWeight: 10 to morph2). What am I
doing wrong?
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill;
spaceFillWeight: 10.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1) expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2) expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) expanded: true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex2.
container := UITheme builder newColumn: { ex1. sp1. ex2. sp2. ex3}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Cheers,
Doru
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 2:32 PM
Subject: Re: [Pharo-project] collapsing panes
Thanks a lot, Gary! I gave it a try and it does go in the wanted direction.
Now, the next question. I see that you are using a TableLayout. Is there a
way to specify a proportion (like in the proportional layout?) for the
initial extent of the inner panes?
If yes, then I suppose we could merge the two layouts into one.
Cheers,
Doru
On 24 Jan 2011, at 14:51, Benjamin wrote:
I love that :)
It could be very useful ^^
Ben
On Jan 24, 2011, at 2:36 PM, Gary Chambers wrote:
Tricky...
Just an experiment, but try the following after filing in attached change
set.
Can make the re-proportioning explicit and maybe fix things to constrain to
the owner morph if interested...
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
expanded: true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex2.
container := UITheme builder newColumn: {
ex1.
sp1.
ex2.
sp2.
ex3}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Have a play/fun.
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr Development
Re: [Pharo-project] why does monticello updates accessing web when i save on dir?
Does it access the web when you store to your local repo or when you copy to SqueakSource? Was that different with Squeak? If there's some unnecessary activity I would be interested to know about ;) Cheers, Adrian On Jan 25, 2011, at 14:44 , HwaJong Oh wrote: Saving packages in my local directory repository and then copying them to the squeaksource is my pattern of work since Squeak. But, when I apply that pattern, Pharo accesses web everytime i save a version taking long time. Is this behavior have some meaning or is it some sort of side effect? Best Regards -- View this message in context: http://forum.world.st/why-does-monticello-updates-accessing-web-when-i-save-on-dir-tp3236185p3236185.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Issue 3594 in pharo: Expander needs tweaking to enable resize in a TableLayout
Comment #1 on issue 3594 by tudor.gi...@gmail.com: Expander needs tweaking to enable resize in a TableLayout http://code.google.com/p/pharo/issues/detail?id=3594 And now with the attachment Attachments: ExpanderTweak.1.cs 757 bytes
Re: [Pharo-project] debugger problems?
On Jan 25, 2011, at 14:05 , Tudor Girba wrote: I am not alone! :) Anyone else noticed this? yes Is it http://code.google.com/p/pharo/issues/detail?id=709 ? Adrian
Re: [Pharo-project] Issue 3594 in pharo: Expander needs tweaking to enable resize in a TableLayout
Updates: Labels: Milestone-1.3 Comment #2 on issue 3594 by tudor.gi...@gmail.com: Expander needs tweaking to enable resize in a TableLayout http://code.google.com/p/pharo/issues/detail?id=3594 (No comment was entered for this change.)
Re: [Pharo-project] why does monticello updates accessing web when i save on dir?
It accesses the web when i store to my local repo. Since my last post here, I am coming up with a suspicion that it may have some package dependency toward the web. I better check. Your interest tell me, it is not a usual case. It is interesting to me, too. :-) -- View this message in context: http://forum.world.st/why-does-monticello-updates-accessing-web-when-i-save-on-dir-tp3236185p3236255.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] why does monticello updates accessing web when i save on dir?
At some point it tries to refresh all know repositories.. probably to show you the warning Oh, but there is more recent version of the package you saving.. maybe you need to merge with it before saving I think this message could be made optional and turned off for professionals :) On 25 January 2011 15:25, HwaJong Oh daliot...@gmail.com wrote: It accesses the web when i store to my local repo. Since my last post here, I am coming up with a suspicion that it may have some package dependency toward the web. I better check. Your interest tell me, it is not a usual case. It is interesting to me, too. :-) -- View this message in context: http://forum.world.st/why-does-monticello-updates-accessing-web-when-i-save-on-dir-tp3236185p3236255.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] collapsing panes
I'm working on it... changeset soon...
Regards, Gary
- Original Message -
From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 2:15 PM
Subject: Re: [Pharo-project] collapsing panes
Ahh, indeed! My bad. Thanks Gary.
The main issue that seems to be left is the resizing. Currently, resizing
propagates the changes to all the following morphs. This is great when the
table layout is inside a GeneralScrollPane, but it leads to a bit of an odd
behavior when stretching inside a bounded morph. Is there an easy option to
change the behavior of the resizer?
Cheers,
Doru
On 25 Jan 2011, at 12:07, Gary Chambers wrote:
Hi Doru,
The weight should be applied to the expanders themselves...
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 3;
expanded: true.
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 9:14 PM
Subject: Re: [Pharo-project] collapsing panes
Hi Gary,
On 24 Jan 2011, at 16:16, Gary Chambers wrote:
Hi,
I don't think the layouts can be merged, as such, as they have very
different
approaches.
With the TableLayout, it is possible to assign weights to each
spaceFill
section to get what you want, I think. (see #spaceFillWeight:)
I tried to use it, but I get no effect when I use it in your example.
Below is one of my trouts (added spaceFillWeight: 10 to morph2). What am I
doing wrong?
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill;
spaceFillWeight: 10.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1) expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2) expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) expanded:
true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex2.
container := UITheme builder newColumn: { ex1. sp1. ex2. sp2. ex3}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Cheers,
Doru
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 2:32 PM
Subject: Re: [Pharo-project] collapsing panes
Thanks a lot, Gary! I gave it a try and it does go in the wanted
direction.
Now, the next question. I see that you are using a TableLayout. Is there
a way to specify a proportion (like in the proportional layout?) for the
initial extent of the inner panes?
If yes, then I suppose we could merge the two layouts into one.
Cheers,
Doru
On 24 Jan 2011, at 14:51, Benjamin wrote:
I love that :)
It could be very useful ^^
Ben
On Jan 24, 2011, at 2:36 PM, Gary Chambers wrote:
Tricky...
Just an experiment, but try the following after filing in attached
change set.
Can make the re-proportioning explicit and maybe fix things to
constrain to
the owner morph if interested...
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color
blue))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color
yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
expanded: true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex2.
container := UITheme builder newColumn: {
ex1.
sp1.
ex2.
sp2.
ex3}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Have a play/fun.
Regards, Gary
- Original
Re: [Pharo-project] collapsing panes
OK, try the following, after filing in attached change set,
I've had a dabble with announcements too ;-) ...
| container morph1 morph2 morph3 morph4 ex1 ex2 ex3 ex4 sp1 sp2 sp3|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill; vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill; vResizing: #spaceFill.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow))
hResizing: #spaceFill; vResizing: #spaceFill.
morph4 := (PanelMorph new fillStyle: (SolidFillStyle color: Color green))
hResizing: #spaceFill; vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1) spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2) spaceFillWeight:
2; expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) spaceFillWeight:
3; expanded: true.
ex4 := (UITheme builder newExpander: 'Green' for: morph4) spaceFillWeight:
4; expanded: true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
fitTargetOwner: true;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
fitTargetOwner: true;
on: #mouseDown send: #expandedSizingRigid to: ex2.
sp3 := EdgeGripMorph new
target: ex3;
edgeName: #bottom;
fitTargetOwner: true;
on: #mouseDown send: #expandedSizingRigid to: ex3.
ex1 announcer on: ExpanderMorphAnnouncement do: [:ann |
sp1
visible: ann expanderMorph expanded;
disableTableLayout: ann expanderMorph expanded not].
ex2 announcer on: ExpanderMorphAnnouncement do: [:ann |
sp2
visible: ann expanderMorph expanded;
disableTableLayout: ann expanderMorph expanded not].
ex3 announcer on: ExpanderMorphAnnouncement do: [:ann |
sp3
visible: ann expanderMorph expanded;
disableTableLayout: ann expanderMorph expanded not].
container := UITheme builder newColumn: {
ex1.
sp1.
ex2.
sp2.
ex3.
sp3.
ex4}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Once people are happy with it I'll wrap thing up into a new morph that
takes the burdensome details away (ExpanderGroupMorph or something like
that).
Later, like tabs, ability to add/remove sections dynamically etc.
Regards, Gary
- Original Message -
From: Gary Chambers gazzagu...@btinternet.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 3:07 PM
Subject: Re: [Pharo-project] collapsing panes
I'm working on it... changeset soon...
Regards, Gary
- Original Message -
From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 2:15 PM
Subject: Re: [Pharo-project] collapsing panes
Ahh, indeed! My bad. Thanks Gary.
The main issue that seems to be left is the resizing. Currently, resizing
propagates the changes to all the following morphs. This is great when the
table layout is inside a GeneralScrollPane, but it leads to a bit of an
odd behavior when stretching inside a bounded morph. Is there an easy
option to change the behavior of the resizer?
Cheers,
Doru
On 25 Jan 2011, at 12:07, Gary Chambers wrote:
Hi Doru,
The weight should be applied to the expanders themselves...
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 3;
expanded: true.
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 9:14 PM
Subject: Re: [Pharo-project] collapsing panes
Hi Gary,
On 24 Jan 2011, at 16:16, Gary Chambers wrote:
Hi,
I don't think the layouts can be merged, as such, as they have very
different
approaches.
With the TableLayout, it is possible to assign weights to each
spaceFill
section to get what you want, I think. (see #spaceFillWeight:)
I tried to use it, but I get no effect when I use it in your example.
Below is one of my trouts (added spaceFillWeight: 10 to morph2). What am
I doing wrong?
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill;
spaceFillWeight: 10.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color
yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1) expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2) expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) expanded:
true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
Re: [Pharo-project] collapsing panes
It's really great working with you :)
Cheers,
Doru
On 25 Jan 2011, at 16:07, Gary Chambers wrote:
I'm working on it... changeset soon...
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 2:15 PM
Subject: Re: [Pharo-project] collapsing panes
Ahh, indeed! My bad. Thanks Gary.
The main issue that seems to be left is the resizing. Currently, resizing
propagates the changes to all the following morphs. This is great when the
table layout is inside a GeneralScrollPane, but it leads to a bit of an odd
behavior when stretching inside a bounded morph. Is there an easy option to
change the behavior of the resizer?
Cheers,
Doru
On 25 Jan 2011, at 12:07, Gary Chambers wrote:
Hi Doru,
The weight should be applied to the expanders themselves...
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 3;
expanded: true.
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 9:14 PM
Subject: Re: [Pharo-project] collapsing panes
Hi Gary,
On 24 Jan 2011, at 16:16, Gary Chambers wrote:
Hi,
I don't think the layouts can be merged, as such, as they have very
different
approaches.
With the TableLayout, it is possible to assign weights to each spaceFill
section to get what you want, I think. (see #spaceFillWeight:)
I tried to use it, but I get no effect when I use it in your example.
Below is one of my trouts (added spaceFillWeight: 10 to morph2). What am I
doing wrong?
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill;
spaceFillWeight: 10.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1) expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2) expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) expanded: true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex2.
container := UITheme builder newColumn: { ex1. sp1. ex2. sp2. ex3}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Cheers,
Doru
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 2:32 PM
Subject: Re: [Pharo-project] collapsing panes
Thanks a lot, Gary! I gave it a try and it does go in the wanted direction.
Now, the next question. I see that you are using a TableLayout. Is there a
way to specify a proportion (like in the proportional layout?) for the
initial extent of the inner panes?
If yes, then I suppose we could merge the two layouts into one.
Cheers,
Doru
On 24 Jan 2011, at 14:51, Benjamin wrote:
I love that :)
It could be very useful ^^
Ben
On Jan 24, 2011, at 2:36 PM, Gary Chambers wrote:
Tricky...
Just an experiment, but try the following after filing in attached change
set.
Can make the re-proportioning explicit and maybe fix things to constrain
to
the owner morph if interested...
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
expanded: true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
Re: [Pharo-project] collapsing panes
Ta, no problem!
Not quite perfect though... expanding after manual resize of an upper one
won't fill properly.
Unfortunately that's the limit with Morphic as it stands.
There's no concept of desired extent (which would normally be like extent
when rigid but slightly flexible)...
It would be nice to have layout etc. totally redone, perhaps based on the
Xwindows model... a big job
though that would probably benefit from a new (lowish level) UI
framework... along with
Cairo/Rome etc.
Regards, Gary
- Original Message -
From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 3:33 PM
Subject: Re: [Pharo-project] collapsing panes
It's really great working with you :)
Cheers,
Doru
On 25 Jan 2011, at 16:07, Gary Chambers wrote:
I'm working on it... changeset soon...
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 2:15 PM
Subject: Re: [Pharo-project] collapsing panes
Ahh, indeed! My bad. Thanks Gary.
The main issue that seems to be left is the resizing. Currently, resizing
propagates the changes to all the following morphs. This is great when the
table layout is inside a GeneralScrollPane, but it leads to a bit of an
odd behavior when stretching inside a bounded morph. Is there an easy
option to change the behavior of the resizer?
Cheers,
Doru
On 25 Jan 2011, at 12:07, Gary Chambers wrote:
Hi Doru,
The weight should be applied to the expanders themselves...
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 3;
expanded: true.
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 9:14 PM
Subject: Re: [Pharo-project] collapsing panes
Hi Gary,
On 24 Jan 2011, at 16:16, Gary Chambers wrote:
Hi,
I don't think the layouts can be merged, as such, as they have very
different
approaches.
With the TableLayout, it is possible to assign weights to each
spaceFill
section to get what you want, I think. (see #spaceFillWeight:)
I tried to use it, but I get no effect when I use it in your example.
Below is one of my trouts (added spaceFillWeight: 10 to morph2). What am
I doing wrong?
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill;
spaceFillWeight: 10.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color
yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1) expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2) expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) expanded:
true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex2.
container := UITheme builder newColumn: { ex1. sp1. ex2. sp2. ex3}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Cheers,
Doru
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 2:32 PM
Subject: Re: [Pharo-project] collapsing panes
Thanks a lot, Gary! I gave it a try and it does go in the wanted
direction.
Now, the next question. I see that you are using a TableLayout. Is there
a way to specify a proportion (like in the proportional layout?) for the
initial extent of the inner panes?
If yes, then I suppose we could merge the two layouts into one.
Cheers,
Doru
On 24 Jan 2011, at 14:51, Benjamin wrote:
I love that :)
It could be very useful ^^
Ben
On Jan 24, 2011, at 2:36 PM, Gary Chambers wrote:
Tricky...
Just an experiment, but try the following after filing in attached
change set.
Can make the re-proportioning explicit and maybe fix things to
constrain to
the owner morph if interested...
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color
red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color
blue))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color
yellow))
Re: [Pharo-project] collapsing panes
Hi Gary,
I tried it but there does not seem to be any difference. Resizing the red morph
leads to resizing all other panes. Resizing the yellow pane, affects only
yellow and green.
Am I looking at the wrong thing?
In any case, going towards Announcements in Morphic is really cool.
Cheers,
Doru
On 25 Jan 2011, at 16:31, Gary Chambers wrote:
OK, try the following, after filing in attached change set,
I've had a dabble with announcements too ;-) ...
| container morph1 morph2 morph3 morph4 ex1 ex2 ex3 ex4 sp1 sp2 sp3|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill; vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill; vResizing: #spaceFill.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow))
hResizing: #spaceFill; vResizing: #spaceFill.
morph4 := (PanelMorph new fillStyle: (SolidFillStyle color: Color green))
hResizing: #spaceFill; vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1) spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2) spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) spaceFillWeight:
3; expanded: true.
ex4 := (UITheme builder newExpander: 'Green' for: morph4) spaceFillWeight:
4; expanded: true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
fitTargetOwner: true;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
fitTargetOwner: true;
on: #mouseDown send: #expandedSizingRigid to: ex2.
sp3 := EdgeGripMorph new
target: ex3;
edgeName: #bottom;
fitTargetOwner: true;
on: #mouseDown send: #expandedSizingRigid to: ex3.
ex1 announcer on: ExpanderMorphAnnouncement do: [:ann |
sp1
visible: ann expanderMorph expanded;
disableTableLayout: ann expanderMorph expanded not].
ex2 announcer on: ExpanderMorphAnnouncement do: [:ann |
sp2
visible: ann expanderMorph expanded;
disableTableLayout: ann expanderMorph expanded not].
ex3 announcer on: ExpanderMorphAnnouncement do: [:ann |
sp3
visible: ann expanderMorph expanded;
disableTableLayout: ann expanderMorph expanded not].
container := UITheme builder newColumn: {
ex1.
sp1.
ex2.
sp2.
ex3.
sp3.
ex4}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Once people are happy with it I'll wrap thing up into a new morph that
takes the burdensome details away (ExpanderGroupMorph or something like that).
Later, like tabs, ability to add/remove sections dynamically etc.
Regards, Gary
- Original Message - From: Gary Chambers gazzagu...@btinternet.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 3:07 PM
Subject: Re: [Pharo-project] collapsing panes
I'm working on it... changeset soon...
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 2:15 PM
Subject: Re: [Pharo-project] collapsing panes
Ahh, indeed! My bad. Thanks Gary.
The main issue that seems to be left is the resizing. Currently, resizing
propagates the changes to all the following morphs. This is great when the
table layout is inside a GeneralScrollPane, but it leads to a bit of an odd
behavior when stretching inside a bounded morph. Is there an easy option to
change the behavior of the resizer?
Cheers,
Doru
On 25 Jan 2011, at 12:07, Gary Chambers wrote:
Hi Doru,
The weight should be applied to the expanders themselves...
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 3;
expanded: true.
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 9:14 PM
Subject: Re: [Pharo-project] collapsing panes
Hi Gary,
On 24 Jan 2011, at 16:16, Gary Chambers wrote:
Hi,
I don't think the layouts can be merged, as such, as they have very
different
approaches.
With the TableLayout, it is possible to assign weights to each spaceFill
section to get what you want, I think. (see #spaceFillWeight:)
I tried to use it, but I get no effect when I use it in your example.
Below is one of my trouts (added spaceFillWeight: 10 to morph2). What am I
doing wrong?
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill;
spaceFillWeight: 10.
Re: [Pharo-project] collapsing panes
Once wrapped in a more specific class, a workaround will be possible to
maintain
the integrity of the layout.
Regards, Gary
- Original Message -
From: Gary Chambers gazzagu...@btinternet.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 3:40 PM
Subject: Re: [Pharo-project] collapsing panes
Ta, no problem!
Not quite perfect though... expanding after manual resize of an upper one
won't fill properly.
Unfortunately that's the limit with Morphic as it stands.
There's no concept of desired extent (which would normally be like
extent when rigid but slightly flexible)...
It would be nice to have layout etc. totally redone, perhaps based on the
Xwindows model... a big job
though that would probably benefit from a new (lowish level) UI
framework... along with
Cairo/Rome etc.
Regards, Gary
- Original Message -
From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 3:33 PM
Subject: Re: [Pharo-project] collapsing panes
It's really great working with you :)
Cheers,
Doru
On 25 Jan 2011, at 16:07, Gary Chambers wrote:
I'm working on it... changeset soon...
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 2:15 PM
Subject: Re: [Pharo-project] collapsing panes
Ahh, indeed! My bad. Thanks Gary.
The main issue that seems to be left is the resizing. Currently, resizing
propagates the changes to all the following morphs. This is great when
the table layout is inside a GeneralScrollPane, but it leads to a bit of
an odd behavior when stretching inside a bounded morph. Is there an easy
option to change the behavior of the resizer?
Cheers,
Doru
On 25 Jan 2011, at 12:07, Gary Chambers wrote:
Hi Doru,
The weight should be applied to the expanders themselves...
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 3;
expanded: true.
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 9:14 PM
Subject: Re: [Pharo-project] collapsing panes
Hi Gary,
On 24 Jan 2011, at 16:16, Gary Chambers wrote:
Hi,
I don't think the layouts can be merged, as such, as they have very
different
approaches.
With the TableLayout, it is possible to assign weights to each
spaceFill
section to get what you want, I think. (see #spaceFillWeight:)
I tried to use it, but I get no effect when I use it in your example.
Below is one of my trouts (added spaceFillWeight: 10 to morph2). What am
I doing wrong?
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill;
spaceFillWeight: 10.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color
yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1) expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2) expanded:
true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) expanded:
true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex2.
container := UITheme builder newColumn: { ex1. sp1. ex2. sp2. ex3}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Cheers,
Doru
Regards, Gary
- Original Message - From: Tudor Girba
tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 2:32 PM
Subject: Re: [Pharo-project] collapsing panes
Thanks a lot, Gary! I gave it a try and it does go in the wanted
direction.
Now, the next question. I see that you are using a TableLayout. Is
there a way to specify a proportion (like in the proportional layout?)
for the initial extent of the inner panes?
If yes, then I suppose we could merge the two layouts into one.
Cheers,
Doru
On 24 Jan 2011, at 14:51, Benjamin wrote:
I love that :)
It could be very useful ^^
Ben
On Jan 24, 2011, at 2:36 PM, Gary Chambers wrote:
Tricky...
Just an experiment, but try the following after filing in attached
change set.
Can make the re-proportioning explicit and maybe fix things to
constrain to
the owner morph if interested...
| container morph1 morph2 morph3 ex1 ex2
Re: [Pharo-project] collapsing panes
Indeed, the point being that when resizing, the lower panes running outside
the container is
prevented.
Initially, all panes are in spaceFill mode, weight accounted for.
Upon manual resizing the affected pane becomes rigid.
Contracting an expander will reset the the associated pane to spaceFill
such that, when re-expanded it scales again..
Regards, Gary
- Original Message -
From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 3:40 PM
Subject: Re: [Pharo-project] collapsing panes
Hi Gary,
I tried it but there does not seem to be any difference. Resizing the red
morph leads to resizing all other panes. Resizing the yellow pane, affects
only yellow and green.
Am I looking at the wrong thing?
In any case, going towards Announcements in Morphic is really cool.
Cheers,
Doru
On 25 Jan 2011, at 16:31, Gary Chambers wrote:
OK, try the following, after filing in attached change set,
I've had a dabble with announcements too ;-) ...
| container morph1 morph2 morph3 morph4 ex1 ex2 ex3 ex4 sp1 sp2 sp3|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill; vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill; vResizing: #spaceFill.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow))
hResizing: #spaceFill; vResizing: #spaceFill.
morph4 := (PanelMorph new fillStyle: (SolidFillStyle color: Color green))
hResizing: #spaceFill; vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1) spaceFillWeight:
1; expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2) spaceFillWeight:
2; expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 3; expanded: true.
ex4 := (UITheme builder newExpander: 'Green' for: morph4)
spaceFillWeight: 4; expanded: true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
fitTargetOwner: true;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
fitTargetOwner: true;
on: #mouseDown send: #expandedSizingRigid to: ex2.
sp3 := EdgeGripMorph new
target: ex3;
edgeName: #bottom;
fitTargetOwner: true;
on: #mouseDown send: #expandedSizingRigid to: ex3.
ex1 announcer on: ExpanderMorphAnnouncement do: [:ann |
sp1
visible: ann expanderMorph expanded;
disableTableLayout: ann expanderMorph expanded not].
ex2 announcer on: ExpanderMorphAnnouncement do: [:ann |
sp2
visible: ann expanderMorph expanded;
disableTableLayout: ann expanderMorph expanded not].
ex3 announcer on: ExpanderMorphAnnouncement do: [:ann |
sp3
visible: ann expanderMorph expanded;
disableTableLayout: ann expanderMorph expanded not].
container := UITheme builder newColumn: {
ex1.
sp1.
ex2.
sp2.
ex3.
sp3.
ex4}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Once people are happy with it I'll wrap thing up into a new morph that
takes the burdensome details away (ExpanderGroupMorph or something like
that).
Later, like tabs, ability to add/remove sections dynamically etc.
Regards, Gary
- Original Message - From: Gary Chambers
gazzagu...@btinternet.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 3:07 PM
Subject: Re: [Pharo-project] collapsing panes
I'm working on it... changeset soon...
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 2:15 PM
Subject: Re: [Pharo-project] collapsing panes
Ahh, indeed! My bad. Thanks Gary.
The main issue that seems to be left is the resizing. Currently, resizing
propagates the changes to all the following morphs. This is great when
the table layout is inside a GeneralScrollPane, but it leads to a bit of
an odd behavior when stretching inside a bounded morph. Is there an easy
option to change the behavior of the resizer?
Cheers,
Doru
On 25 Jan 2011, at 12:07, Gary Chambers wrote:
Hi Doru,
The weight should be applied to the expanders themselves...
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 3;
expanded: true.
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 9:14 PM
Subject: Re: [Pharo-project] collapsing panes
Hi Gary,
On 24 Jan 2011, at 16:16, Gary Chambers wrote:
Hi,
I don't think the layouts can be merged, as such, as they have very
different
approaches.
With the TableLayout, it is possible to assign weights to each
spaceFill
section to get what you want, I think. (see #spaceFillWeight:)
I tried to use it, but I get no effect when I
Re: [Pharo-project] collapsing panes
Once wrapped, we could have the panes that are not being resized reverted to
their spaceFill mode...
Regards, Gary
- Original Message -
From: Gary Chambers gazzagu...@btinternet.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 3:52 PM
Subject: Re: [Pharo-project] collapsing panes
Once wrapped in a more specific class, a workaround will be possible to
maintain
the integrity of the layout.
Regards, Gary
- Original Message -
From: Gary Chambers gazzagu...@btinternet.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 3:40 PM
Subject: Re: [Pharo-project] collapsing panes
Ta, no problem!
Not quite perfect though... expanding after manual resize of an upper one
won't fill properly.
Unfortunately that's the limit with Morphic as it stands.
There's no concept of desired extent (which would normally be like
extent when rigid but slightly flexible)...
It would be nice to have layout etc. totally redone, perhaps based on the
Xwindows model... a big job
though that would probably benefit from a new (lowish level) UI
framework... along with
Cairo/Rome etc.
Regards, Gary
- Original Message -
From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 3:33 PM
Subject: Re: [Pharo-project] collapsing panes
It's really great working with you :)
Cheers,
Doru
On 25 Jan 2011, at 16:07, Gary Chambers wrote:
I'm working on it... changeset soon...
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 2:15 PM
Subject: Re: [Pharo-project] collapsing panes
Ahh, indeed! My bad. Thanks Gary.
The main issue that seems to be left is the resizing. Currently,
resizing propagates the changes to all the following morphs. This is
great when the table layout is inside a GeneralScrollPane, but it leads
to a bit of an odd behavior when stretching inside a bounded morph. Is
there an easy option to change the behavior of the resizer?
Cheers,
Doru
On 25 Jan 2011, at 12:07, Gary Chambers wrote:
Hi Doru,
The weight should be applied to the expanders themselves...
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 3;
expanded: true.
Regards, Gary
- Original Message - From: Tudor Girba
tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 9:14 PM
Subject: Re: [Pharo-project] collapsing panes
Hi Gary,
On 24 Jan 2011, at 16:16, Gary Chambers wrote:
Hi,
I don't think the layouts can be merged, as such, as they have very
different
approaches.
With the TableLayout, it is possible to assign weights to each
spaceFill
section to get what you want, I think. (see #spaceFillWeight:)
I tried to use it, but I get no effect when I use it in your example.
Below is one of my trouts (added spaceFillWeight: 10 to morph2). What
am I doing wrong?
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color
blue))
hResizing: #spaceFill;
vResizing: #spaceFill;
spaceFillWeight: 10.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color
yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1) expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2) expanded:
true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) expanded:
true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
vResizing: #rigid;
extent: 24 @ ProportionalSplitterMorph splitterWidth;
on: #mouseDown send: #expandedSizingRigid to: ex2.
container := UITheme builder newColumn: { ex1. sp1. ex2. sp2. ex3}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Cheers,
Doru
Regards, Gary
- Original Message - From: Tudor Girba
tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 2:32 PM
Subject: Re: [Pharo-project] collapsing panes
Thanks a lot, Gary! I gave it a try and it does go in the wanted
direction.
Now, the next question. I see that you are using a TableLayout. Is
there a way to specify a proportion (like in the proportional layout?)
for the initial extent of the inner panes?
If yes, then I suppose we could merge the two layouts into one.
Cheers,
Doru
On 24 Jan 2011, at 14:51, Benjamin wrote:
I love that :)
It
Re: [Pharo-project] why does monticello updates accessing web when i save on dir?
Do you mean #checkForNewerVersions with the message 'CAUTION! These versions in the repository may be newer:'? At least in PharoCore 1.1.1 this method doesn't have a sender. Adrian On Jan 25, 2011, at 15:49 , Igor Stasenko wrote: At some point it tries to refresh all know repositories.. probably to show you the warning Oh, but there is more recent version of the package you saving.. maybe you need to merge with it before saving I think this message could be made optional and turned off for professionals :) On 25 January 2011 15:25, HwaJong Oh daliot...@gmail.com wrote: It accesses the web when i store to my local repo. Since my last post here, I am coming up with a suspicion that it may have some package dependency toward the web. I better check. Your interest tell me, it is not a usual case. It is interesting to me, too. :-) -- View this message in context: http://forum.world.st/why-does-monticello-updates-accessing-web-when-i-save-on-dir-tp3236185p3236255.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Issue 3470 in pharo: [Failing Tests] OBKeyBindingsTest
Comment #3 on issue 3470 by panu.j.m...@gmail.com: [Failing Tests] OBKeyBindingsTest http://code.google.com/p/pharo/issues/detail?id=3470 If one changes OBTextMorph#editorClass to return OBTextMorphEditor instead of SmalltalkEditor the OBKeyBindingsTest will pass. But I am don't know what are the consequences of this change.
Re: [Pharo-project] Issue 3579 in pharo: declare temp adds the variable twice
Comment #3 on issue 3579 by marianopeck: declare temp adds the variable twice http://code.google.com/p/pharo/issues/detail?id=3579 Laurent, I cannot reproduce it anymore in PharoCore 12319, can you?
Re: [Pharo-project] Issue 3579 in pharo: declare temp adds the variable twice
Comment #4 on issue 3579 by marcus.d...@gmail.com: declare temp adds the variable twice http://code.google.com/p/pharo/issues/detail?id=3579 this is not Core, but Full (OB)
Re: [Pharo-project] problem starting up with a script on windows
Thanks doru. Can you open a ticket? Stef I managed to debug some more and the problem seems to be introduced by System-Download after the version System-Download-StephaneDucasse.51. If you try any of the newer version, you should get the error. Ah, one more detail: I worked on a Windows Server 2008 R2 using a Cog VM (both r2316 and r2348). It would be great if someone else could confirm. Cheers, Doru On 25 Jan 2011, at 14:04, Tudor Girba wrote: Hi, There seems to be a problem with starting a Pharo 1.2-based image with an initial .st script on Windows. The problem seems to be in CodeLoaderinstallSourceFiles and it is related to the contentStream retrieved from the HTTPDownloadRequest being nil. I attached the debug.log. I checked the paths and they are all correct. In fact, if I run the same script with a Pharo 1.1.1 image, everything works as expected. I also tried to drag and drop the .st script and again, everything works as expected. So, it seems that there is some initialization problem. I cannot debug well because I do not have a Windows machine (the situation happens on a server that I cannot access easily). Can someone take a look to see if the problem can be reproduced? Cheers, Doru -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal. PharoDebug.log -- www.tudorgirba.com Relationships are of two kinds: those we choose and those that happen. They both matter.
Re: [Pharo-project] collapsing panes
I love to hear that kind of news.
In addition, I think that we should really get rid of toolBuilder because it
will not support new ui elements.
Stef
On Jan 25, 2011, at 4:31 PM, Gary Chambers wrote:
OK, try the following, after filing in attached change set,
I've had a dabble with announcements too ;-) ...
| container morph1 morph2 morph3 morph4 ex1 ex2 ex3 ex4 sp1 sp2 sp3|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill; vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill; vResizing: #spaceFill.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow))
hResizing: #spaceFill; vResizing: #spaceFill.
morph4 := (PanelMorph new fillStyle: (SolidFillStyle color: Color green))
hResizing: #spaceFill; vResizing: #spaceFill.
ex1 := (UITheme builder newExpander: 'Red' for: morph1) spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2) spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3) spaceFillWeight:
3; expanded: true.
ex4 := (UITheme builder newExpander: 'Green' for: morph4) spaceFillWeight:
4; expanded: true.
sp1 := EdgeGripMorph new
target: ex1;
edgeName: #bottom;
fitTargetOwner: true;
on: #mouseDown send: #expandedSizingRigid to: ex1.
sp2 := EdgeGripMorph new
target: ex2;
edgeName: #bottom;
fitTargetOwner: true;
on: #mouseDown send: #expandedSizingRigid to: ex2.
sp3 := EdgeGripMorph new
target: ex3;
edgeName: #bottom;
fitTargetOwner: true;
on: #mouseDown send: #expandedSizingRigid to: ex3.
ex1 announcer on: ExpanderMorphAnnouncement do: [:ann |
sp1
visible: ann expanderMorph expanded;
disableTableLayout: ann expanderMorph expanded not].
ex2 announcer on: ExpanderMorphAnnouncement do: [:ann |
sp2
visible: ann expanderMorph expanded;
disableTableLayout: ann expanderMorph expanded not].
ex3 announcer on: ExpanderMorphAnnouncement do: [:ann |
sp3
visible: ann expanderMorph expanded;
disableTableLayout: ann expanderMorph expanded not].
container := UITheme builder newColumn: {
ex1.
sp1.
ex2.
sp2.
ex3.
sp3.
ex4}.
container cellInset: 0.
container extent: 400@400.
container openInWindow.
Once people are happy with it I'll wrap thing up into a new morph that
takes the burdensome details away (ExpanderGroupMorph or something like that).
Later, like tabs, ability to add/remove sections dynamically etc.
Regards, Gary
- Original Message - From: Gary Chambers gazzagu...@btinternet.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 3:07 PM
Subject: Re: [Pharo-project] collapsing panes
I'm working on it... changeset soon...
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Tuesday, January 25, 2011 2:15 PM
Subject: Re: [Pharo-project] collapsing panes
Ahh, indeed! My bad. Thanks Gary.
The main issue that seems to be left is the resizing. Currently, resizing
propagates the changes to all the following morphs. This is great when the
table layout is inside a GeneralScrollPane, but it leads to a bit of an odd
behavior when stretching inside a bounded morph. Is there an easy option to
change the behavior of the resizer?
Cheers,
Doru
On 25 Jan 2011, at 12:07, Gary Chambers wrote:
Hi Doru,
The weight should be applied to the expanders themselves...
ex1 := (UITheme builder newExpander: 'Red' for: morph1)
spaceFillWeight: 1;
expanded: true.
ex2 := (UITheme builder newExpander: 'Blue' for: morph2)
spaceFillWeight: 2;
expanded: true.
ex3 := (UITheme builder newExpander: 'Yellow' for: morph3)
spaceFillWeight: 3;
expanded: true.
Regards, Gary
- Original Message - From: Tudor Girba tudor.gi...@gmail.com
To: Pharo-project@lists.gforge.inria.fr
Sent: Monday, January 24, 2011 9:14 PM
Subject: Re: [Pharo-project] collapsing panes
Hi Gary,
On 24 Jan 2011, at 16:16, Gary Chambers wrote:
Hi,
I don't think the layouts can be merged, as such, as they have very
different
approaches.
With the TableLayout, it is possible to assign weights to each spaceFill
section to get what you want, I think. (see #spaceFillWeight:)
I tried to use it, but I get no effect when I use it in your example.
Below is one of my trouts (added spaceFillWeight: 10 to morph2). What am I
doing wrong?
| container morph1 morph2 morph3 ex1 ex2 ex3 sp1 sp2|
morph1 := (PanelMorph new fillStyle: (SolidFillStyle color: Color red))
hResizing: #spaceFill;
vResizing: #spaceFill.
morph2 := (PanelMorph new fillStyle: (SolidFillStyle color: Color blue))
hResizing: #spaceFill;
vResizing: #spaceFill;
spaceFillWeight: 10.
morph3 := (PanelMorph new fillStyle: (SolidFillStyle color: Color yellow))
hResizing: #spaceFill;
vResizing: #spaceFill.
ex1 := (UITheme builder
Re: [Pharo-project] why does monticello updates accessing web when i save on dir?
if you save locally did you try to psuh the changes with gofer Gofer new ... ; push On Jan 25, 2011, at 2:44 PM, HwaJong Oh wrote: Saving packages in my local directory repository and then copying them to the squeaksource is my pattern of work since Squeak. But, when I apply that pattern, Pharo accesses web everytime i save a version taking long time. Is this behavior have some meaning or is it some sort of side effect? Best Regards -- View this message in context: http://forum.world.st/why-does-monticello-updates-accessing-web-when-i-save-on-dir-tp3236185p3236185.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] just to tell you that I love all these activities and energy around pharo :)
This is really giving me a lot of energy to build the next generation. I busy writing project proposals to get money for the future, but all these activities and cool changes push me to hack and improve the system, its process and the doc. Stef
Re: [Pharo-project] Pharo on the iPhone
Le 24/01/2011 19:22, Alexandre Bergel a écrit : Unfortunately, my resources are scarce. iPhone are not really spread in Chile. I haven't seen a student having one. Is it possible to make DrGeo available on iTune? Not yet. Hilaire
[Pharo-project] Fwd: Google Summer of Code 2011 Announced
Hi: Is anyone organizing something for GSOC this year? We definitely would like to propose one or two RoarVM+Pharo projects. Best regards Stefan -- Forwarded message -- From: Carol Smith car...@google.com Date: Mon, Jan 24, 2011 at 23:21 Subject: Google Summer of Code 2011 Announced To: Google Summer of Code Announce google-summer-of-code-annou...@googlegroups.com Hi all, We're pleased to announce that Google Summer of Code will be happening for its seventh year this year. Please check out the blog post [1] about the program and read the FAQs [2] and Timeline [3] on Melange for more information. [1] - http://google-opensource.blogspot.com/2011/01/google-summer-of-code-announced-at-lca.html [2] - http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs [3] - http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline Cheers, Carol -- You received this message because you are subscribed to the Google Groups Google Summer of Code Announce group. To post to this group, send email to google-summer-of-code-annou...@googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-announce+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-announce?hl=en. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
[Pharo-project] Weird behavior in a package loaded with Monticello?
Recently I took a look at the Global Keys project of Tony Fleig and noticed something strange. The package GlobalKeys makes some class extensions to the HandMorph class, extensions which are accessors to an instance variable. Since instance variable can't be included in class extensions, the variable appears as undeclared instead. HandMorphglobalKeystrokeHandler class extension ^globalKeystrokeHandler is an undeclared variable HandMorphglobalKeystrokeHandler: aOneArgBlock globalKeystrokeHandler := aOneArgBlock However, when loading the package, class side initialization uses the mutator #globalKeystrokeHandler: to set a default behavior for 'World activeHand' (an instance of HandMorph) and... it works! No error, it just works as if the instance variable is well defined and can be accessed without problem. GlobalKeys classsetHandMorphHook called by class initialization World activeHand globalKeystrokeHandler: [ :ev | | retval | retval := false. ... ] How can it be that the first invocation of #globalKeystrokeHandler: in #setHandMorphHook does not crash? Try the following: Gofer new squeaksource: 'GlobalKeys'; version: 'GlobalKeys-TonyFleig.9'; load Print it: World activeHand globalKeystrokeHandler --- print the source of a code block Now debug the above snippet and proceed *into* globalKeystrokeHandler Print it again print nil as if the code was recompiled once processed by the debugger You can also add the instance var globalKeystrokeHandler, recompile, it will be set to nil. -- View this message in context: http://forum.world.st/Weird-behavior-in-a-package-loaded-with-Monticello-tp3237145p3237145.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] why does monticello updates accessing web when i save on dir?
Why on earth does Pharo thinks me as professional? I am not at that level yet. :-) So the waiting is needed for saver save. I should endure this, but I makes harder for my micro commit habbit. I try to commit as small as refactoring operation defined in the book Refactoring-M. Fowler so the reader of my code will clearly see the change. The commit cycle 1. refactor 2. run test 3. read package change 4. commit with comment with refactoring name followed by extra info: ExtractMethod: #refreshLayoutsFor: The waiting distracts my focus applying this. Best Regards -- View this message in context: http://forum.world.st/why-does-monticello-updates-accessing-web-when-i-save-on-dir-tp3236185p3237169.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] why does monticello updates accessing web when i save on dir?
Why on earth does Pharo thinks me as professional? I am not at that level yet. :-) So the waiting is needed for saver save. I should endure this, but I makes harder for my micro commit habbit. I try to commit as small as refactoring operation defined in the book Refactoring-M. Fowler so the reader of my code will clearly see the change. The commit cycle 1. refactor 2. run test 3. read package change 4. commit with comment with refactoring name followed by extra info: ExtractMethod: #refreshLayoutsFor: The waiting distracts my focus applying this. Best Regards -- View this message in context: http://forum.world.st/why-does-monticello-updates-accessing-web-when-i-save-on-dir-tp3236185p3237168.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] debugger problems?
On Tue, Jan 25, 2011 at 2:58 PM, Michael Roberts m...@mjr104.co.uk wrote: yes as Adrian pointed out debugger highlighting is broken in Pharo. Has been since the very beginning. what we need ideally is a set of test cases describing the desired behaviour. i struggled to simulate this, i am not sure what a good test harness is for the debugger. ideally the highlighting can be tested without the debugger (i.e without the necessary processes and activations), just triggering the necessary execution machinery that calculates highlight offsets (intervals). With a good set of tests we could then better compare Squeak and Pharo implementations because a lot of fixes go into squeak and we need to harvest them over here. any help of course welcome in this area. I poke at it now and then Take a look at the ClosureCompilerTesttestSourceRangeAccessForClosureBytecodeInjectInto which tests the source ranges (that the debugger uses to highlight) for all pcs in the inject:into: method. cheers, Mike On Tue, Jan 25, 2011 at 2:20 PM, Adrian Lienhard a...@netstyle.ch wrote: On Jan 25, 2011, at 14:05 , Tudor Girba wrote: I am not alone! :) Anyone else noticed this? yes Is it http://code.google.com/p/pharo/issues/detail?id=709 ? Adrian
Re: [Pharo-project] problem starting up with a script on windows
Done: http://code.google.com/p/pharo/issues/detail?id=3595 Doru On 25 Jan 2011, at 21:43, Stéphane Ducasse wrote: Thanks doru. Can you open a ticket? Stef I managed to debug some more and the problem seems to be introduced by System-Download after the version System-Download-StephaneDucasse.51. If you try any of the newer version, you should get the error. Ah, one more detail: I worked on a Windows Server 2008 R2 using a Cog VM (both r2316 and r2348). It would be great if someone else could confirm. Cheers, Doru On 25 Jan 2011, at 14:04, Tudor Girba wrote: Hi, There seems to be a problem with starting a Pharo 1.2-based image with an initial .st script on Windows. The problem seems to be in CodeLoaderinstallSourceFiles and it is related to the contentStream retrieved from the HTTPDownloadRequest being nil. I attached the debug.log. I checked the paths and they are all correct. In fact, if I run the same script with a Pharo 1.1.1 image, everything works as expected. I also tried to drag and drop the .st script and again, everything works as expected. So, it seems that there is some initialization problem. I cannot debug well because I do not have a Windows machine (the situation happens on a server that I cannot access easily). Can someone take a look to see if the problem can be reproduced? Cheers, Doru -- www.tudorgirba.com The coherence of a trip is given by the clearness of the goal. PharoDebug.log -- www.tudorgirba.com Relationships are of two kinds: those we choose and those that happen. They both matter. -- www.tudorgirba.com It's not what we do that matters most, it's how we do it.
[Pharo-project] Issue 3595 in pharo: problem starting up with a script on windows
Status: Accepted Owner: tudor.gi...@gmail.com Labels: Milestone-1.2 Milestone-1.3 Type-ReportDefect New issue 3595 by tudor.gi...@gmail.com: problem starting up with a script on windows http://code.google.com/p/pharo/issues/detail?id=3595 Pharo image: Dev Pharo core version: copy from World/System/About Virtual machine used: Cog 2316, 2348 There seems to be a problem with starting a Pharo 1.2-based image with an initial .st script on Windows. The problem seems to be in CodeLoaderinstallSourceFiles and it is related to the contentStream retrieved from the HTTPDownloadRequest being nil. The debug log is listed below. I checked the paths and they are all correct. In fact, if I run the same script with a Pharo 1.1.1 image, everything works as expected. I also tried to drag and drop the .st script and again, everything works as expected. So, it seems that there is some initialization problem. I managed to debug some more and the problem seems to be introduced by System-Download after the version System-Download-StephaneDucasse.51. If you try any of the newer version, you should get the error. I worked on a Windows Server 2008 R2 using a Cog VM (both r2316 and r2348). Attachments: PharoDebug.log 7.8 KB
[Pharo-project] First commit to Pharoinbox. Need advice.
My last package is Balloon-hjo.72.mcz. It is small testing refactoring on Ballloon supporting collections. I wonder this type of work is acceptable? Best Regards -- View this message in context: http://forum.world.st/First-commit-to-Pharoinbox-Need-advice-tp3237535p3237535.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] Smalltalk and the Canvas
Being the Canvas so popular these days, (HTML5, CairoGraphics, etc..),i wonder if its correct to state that it was introduced together with Smalltalk? Does someone know if this claim is correct? Fernando
Re: [Pharo-project] First commit to Pharoinbox. Need advice.
On 26 January 2011 08:13, HwaJong Oh daliot...@gmail.com wrote: My last package is Balloon-hjo.72.mcz. It is small testing refactoring on Ballloon supporting collections. I wonder this type of work is acceptable? Are you joking? Any contribution is acceptable. Of course if its pass the quality test :) And anything which improves functionality cleans the code is acceptable. Can i ask you to make life easier for review? Please create entry in issue tracker , put a link to file there and a little description of your changes. This is to make life easier for people who will review your code and integrate it. :) Also, this will make integration process visible to all people. Best Regards -- View this message in context: http://forum.world.st/First-commit-to-Pharoinbox-Need-advice-tp3237535p3237535.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] What about a little rename in MouseEvent?
Regarding the looking into the future i was thinking that we will go the Smalltalk way, by reifying such new events. Instead of reusing plain old three button mouse events. And leave the MouseEvent for what they were originally conceived (the proposed renaming ) In this scenario a touch pad would generate a TouchPadEvent, and a multibutton mouse would generate MultiButtonMouseEvent Fernando On Tue, Jan 25, 2011 at 10:58 AM, Geert Claes geert.wl.cl...@gmail.com wrote: Lukas Renggli wrote: ... AFAIK, most operating systems number the mouse buttons. - The primary button is what you use to perform actions (typically left mouse button). - The secondary buttons is what you use to open context menu (typically right mouse button). - The third button is the middle button, the fourth button, ... Now I see that numbers are not that far from colors, but at least they have a logical order. I don't like #select, #menu, #extra because I does not make sense in any other context (for example games, or touch applications) than a traditional GUI. Agree, on one side there are the physical buttons (button 1, 2, 3 etc) and on the other hand there are the events they trigger. e.g. for right-handed people button 1 would be the primary button where for left-handed this could very well be button 3. Then again, maybe it is time to look a bit further as it looks like the near future is heading towards a world without any physical buttons where there is no need to number or name buttons at all :) http://www.geek.com/articles/gadgets/new-apple-patent-puts-a-display-on-the-magic-mouse-20110124/ Additional gesture events: http://www.youtube.com/watch?v=JKlkte1aOOw -- View this message in context: http://forum.world.st/What-about-a-little-rename-in-MouseEvent-tp3233363p3235798.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
