Dear all, I have some questions about the following topics: Morphic, the Zinc-HTTP-Client-Server, and NautilusRefactoring. I am wondering if someone can help ;) I am visiting RMoD @ INRIA these days (I am now sitting at the âvisiting tablesâ @ 3rd floor of INRIA). If someone is willingness to help, please come forward! To get an idea (and hopefully to collect some answers from people outside of Lille) here are my doubts ### Morphic - How can I assess the âz indexâ of windows? For each window Iâd like to know the % that is visible on screen, i.e., not covered from other windows. - Is there a âgeneral patternâ on how to extract which entity is âdisplayedâ on a window? In System Browsers is easy, what about other types of windows? ### Zinc-HTTP-Client-Server - How can I do a real upload (HTTP post) in background? ### NautilusRefactoring - How does it work? Why there are different methods to remove a class, for example? e.g., NautilusRefactoring>>#removeClasses: vs. AbstractTool>>#removeClasses: - Why #removeClasses: is triggered before the actual removal (i.e., confirmation dialogue)? Cheers and thanks in advance, Roberto
On 27 Jan 2015, at 13:21, Roberto Minelli <roberto.minelli@usi.ch> wrote:
Dear all,
I have some questions about the following topics: Morphic, the Zinc-HTTP-Client-Server, and NautilusRefactoring. I am wondering if someone can help ;)
I am visiting RMoD @ INRIA these days (I am now sitting at the âvisiting tablesâ @ 3rd floor of INRIA). If someone is willingness to help, please come forward! To get an idea (and hopefully to collect some answers from people outside of Lille) here are my doubts
Are you at the Pharo Days ?
### Morphic - How can I assess the âz indexâ of windows? For each window Iâd like to know the % that is visible on screen, i.e., not covered from other windows. - Is there a âgeneral patternâ on how to extract which entity is âdisplayedâ on a window? In System Browsers is easy, what about other types of windows?
### Zinc-HTTP-Client-Server - How can I do a real upload (HTTP post) in background?
You can talk to me about that.
### NautilusRefactoring - How does it work? Why there are different methods to remove a class, for example? e.g., NautilusRefactoring>>#removeClasses: vs. AbstractTool>>#removeClasses: - Why #removeClasses: is triggered before the actual removal (i.e., confirmation dialogue)?
Cheers and thanks in advance, Roberto
Hi Sven, Yes, Iâll be there at the Pharo Days! Super cool that I can discuss with you about the Zinc-HTTP-Client-Server! See you at the Pharo Days then! Cheers, Roberto
On 27 Jan 2015, at 13:24, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 27 Jan 2015, at 13:21, Roberto Minelli <roberto.minelli@usi.ch> wrote:
Dear all,
I have some questions about the following topics: Morphic, the Zinc-HTTP-Client-Server, and NautilusRefactoring. I am wondering if someone can help ;)
I am visiting RMoD @ INRIA these days (I am now sitting at the âvisiting tablesâ @ 3rd floor of INRIA). If someone is willingness to help, please come forward! To get an idea (and hopefully to collect some answers from people outside of Lille) here are my doubts
Are you at the Pharo Days ?
### Morphic - How can I assess the âz indexâ of windows? For each window Iâd like to know the % that is visible on screen, i.e., not covered from other windows. - Is there a âgeneral patternâ on how to extract which entity is âdisplayedâ on a window? In System Browsers is easy, what about other types of windows?
### Zinc-HTTP-Client-Server - How can I do a real upload (HTTP post) in background?
You can talk to me about that.
### NautilusRefactoring - How does it work? Why there are different methods to remove a class, for example? e.g., NautilusRefactoring>>#removeClasses: vs. AbstractTool>>#removeClasses: - Why #removeClasses: is triggered before the actual removal (i.e., confirmation dialogue)?
Cheers and thanks in advance, Roberto
On 27 Jan 2015, at 1:21 , Roberto Minelli <roberto.minelli@usi.ch> wrote:
Dear all,
I have some questions about the following topics: Morphic, the Zinc-HTTP-Client-Server, and NautilusRefactoring. I am wondering if someone can help ;)
I am visiting RMoD @ INRIA these days (I am now sitting at the âvisiting tablesâ @ 3rd floor of INRIA). If someone is willingness to help, please come forward! To get an idea (and hopefully to collect some answers from people outside of Lille) here are my doubts
### Morphic - How can I assess the âz indexâ of windows? That would be their index in the PasteupMorphs submorphs collection, where larger index -> higher in z-order. In general, the z-ordering of morphs would be a tree, where
Morph >> visibilityIndex ^self owner ifNil:[0] ifNotNil: [: own | own submorphs indexOf: self ] Morph >> visibility ^self owner ifNotNil: [ owner visibility addLast: self visibilityIndex; yourself ] ifNil:[OrderedCollection new]. would give you a list of numbers, all morphs with higher numbers at any level would have a higher z-order.
For each window Iâd like to know the % that is visible on screen, i.e., not covered from other windows.
That's not possible to calculate accurately in the general case, due to morphs possibly containing fully transparent portions within their bounds. An approximation using bounds would work the same way as the procedure in WorldState >> drawWorld: aWorld submorphs: submorphs invalidAreasOn: aCanvas , where: - The bounds of the morph to check is the damage rect to fill (rectList) - The bounds of higher ordered morphs that might obscure it corresponds to the submorphs parameter. - There's no merging of remnants - No actually drawing/all the other fluff :P Area of remnants / area of original morph bounds would then be an ok-ish approximation of the % that is visible.
- Is there a âgeneral patternâ on how to extract which entity is âdisplayedâ on a window? In System Browsers is easy, what about other types of windows?
Dunno what you mean by that...
### Zinc-HTTP-Client-Server - How can I do a real upload (HTTP post) in background?
### NautilusRefactoring - How does it work? Why there are different methods to remove a class, for example? e.g., NautilusRefactoring>>#removeClasses: vs. AbstractTool>>#removeClasses: - Why #removeClasses: is triggered before the actual removal (i.e., confirmation dialogue)?
Leaving these for others ;) Cheers, Henry
Henry, thanks a lot for all the useful information! Concerning the last part my question is: given a window, say a Workspace (or Playground) is there a way to tell which program entity (i.e., method or class) is involved? So, for a SystemBrowser the entity is the #selectedClass or #selectedMethod. For a Playground I should probably extract the source code displayed and parse it? I have no idea on how to do that.. Cheers, Roberto
On 27 Jan 2015, at 13:51, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 27 Jan 2015, at 1:21 , Roberto Minelli <roberto.minelli@usi.ch> wrote:
Dear all,
I have some questions about the following topics: Morphic, the Zinc-HTTP-Client-Server, and NautilusRefactoring. I am wondering if someone can help ;)
I am visiting RMoD @ INRIA these days (I am now sitting at the âvisiting tablesâ @ 3rd floor of INRIA). If someone is willingness to help, please come forward! To get an idea (and hopefully to collect some answers from people outside of Lille) here are my doubts
### Morphic - How can I assess the âz indexâ of windows?
That would be their index in the PasteupMorphs submorphs collection, where larger index -> higher in z-order. In general, the z-ordering of morphs would be a tree, where
Morph >> visibilityIndex ^self owner ifNil:[0] ifNotNil: [: own | own submorphs indexOf: self ]
Morph >> visibility ^self owner ifNotNil: [ owner visibility addLast: self visibilityIndex; yourself ] ifNil:[OrderedCollection new].
would give you a list of numbers, all morphs with higher numbers at any level would have a higher z-order.
For each window Iâd like to know the % that is visible on screen, i.e., not covered from other windows.
That's not possible to calculate accurately in the general case, due to morphs possibly containing fully transparent portions within their bounds. An approximation using bounds would work the same way as the procedure in WorldState >> drawWorld: aWorld submorphs: submorphs invalidAreasOn: aCanvas , where: - The bounds of the morph to check is the damage rect to fill (rectList) - The bounds of higher ordered morphs that might obscure it corresponds to the submorphs parameter. - There's no merging of remnants - No actually drawing/all the other fluff :P
Area of remnants / area of original morph bounds would then be an ok-ish approximation of the % that is visible.
- Is there a âgeneral patternâ on how to extract which entity is âdisplayedâ on a window? In System Browsers is easy, what about other types of windows?
Dunno what you mean by that...
### Zinc-HTTP-Client-Server - How can I do a real upload (HTTP post) in background?
### NautilusRefactoring - How does it work? Why there are different methods to remove a class, for example? e.g., NautilusRefactoring>>#removeClasses: vs. AbstractTool>>#removeClasses: - Why #removeClasses: is triggered before the actual removal (i.e., confirmation dialogue)?
Leaving these for others ;)
Cheers, Henry
On 27 Jan 2015, at 1:51 , Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 27 Jan 2015, at 1:21 , Roberto Minelli <roberto.minelli@usi.ch> wrote:
Dear all,
I have some questions about the following topics: Morphic, the Zinc-HTTP-Client-Server, and NautilusRefactoring. I am wondering if someone can help ;)
I am visiting RMoD @ INRIA these days (I am now sitting at the âvisiting tablesâ @ 3rd floor of INRIA). If someone is willingness to help, please come forward! To get an idea (and hopefully to collect some answers from people outside of Lille) here are my doubts
### Morphic - How can I assess the âz indexâ of windows? That would be their index in the PasteupMorphs submorphs collection, where larger index -> higher in z-order. In general, the z-ordering of morphs would be a tree, where
Morph >> visibilityIndex ^self owner ifNil:[0] ifNotNil: [: own | own submorphs indexOf: self ]
Morph >> visibility ^self owner ifNotNil: [ owner visibility addLast: self visibilityIndex; yourself ] ifNil:[OrderedCollection new].
would give you a list of numbers, all morphs with higher numbers at any level would have a higher z-order.
Hupps, upon further reading, I got the ordering wrong, submorphs at higher indexes are drawn first. It's amazing what you forget over time... (a modification to this method was the first thing I contributed to Pharo :) * ) Morph visibilityIndex ^self owner ifNil: [0] ifNotNil: [: | own | own submorphs size - (own submorphs indexOf: self) ] is probably better than switching the definition in the original post, since then you'd need to special case the root morph. Cheers, Henry * Related to the Pharo-users thread about when Pharo was publicly announced, timestamp in 1.0 shows that change committed 25/2/2009. I remember first hearing about Pharo from Steph announcing a new dialect at an ESUG, which means even though it's not an official post of the program of ESUG Amsterdam 2008, at least by the end of that, it was public.
;) you remember better than me. Stef * Related to the Pharo-users thread about when Pharo was publicly announced, timestamp in 1.0 shows that change committed 25/2/2009. I remember first hearing about Pharo from Steph announcing a new dialect at an ESUG, which means even though it's not an official post of the program of ESUG Amsterdam 2008, at least by the end of that, it was public.
We started to move Moose from VW to Pharo on April 24, 2008 (right after a decisive meeting with Cincom). This was a very early Pharo (pre 1.0) that was hardly distinguishable from Squeak :) Cheers, Doru On Sat, Jan 31, 2015 at 3:08 PM, stepharo <stepharo@free.fr> wrote:
;) you remember better than me.
Stef
* Related to the Pharo-users thread about when Pharo was publicly announced, timestamp in 1.0 shows that change committed 25/2/2009. I remember first hearing about Pharo from Steph announcing a new dialect at an ESUG, which means even though it's not an official post of the program of ESUG Amsterdam 2008, at least by the end of that, it was public.
-- www.tudorgirba.com "Every thing has its own flow"
On 31 Jan 2015, at 17:36, Tudor Girba <tudor@tudorgirba.com> wrote:
We started to move Moose from VW to Pharo on April 24, 2008 (right after a decisive meeting with Cincom). This was a very early Pharo (pre 1.0) that was hardly distinguishable from Squeak :)
Yes, I defended my thesis end of May, finished writing 1st April⦠The first project of what became 2Denker we did in June (holidays well spend ;-), after postdoc in Bern with a stay in Brussels in the fall. The 2Denker company was founded Jan 2009, Pharo1.0 was released shortly after, I left Switzerland, stayed in Germany a month, then I was in Chile until something like November, official start at Inria mid December. Marcus
On 31 Jan 2015, at 18:11, Marcus Denker <marcus.denker@inria.fr> wrote:
On 31 Jan 2015, at 17:36, Tudor Girba <tudor@tudorgirba.com> wrote:
We started to move Moose from VW to Pharo on April 24, 2008 (right after a decisive meeting with Cincom). This was a very early Pharo (pre 1.0) that was hardly distinguishable from Squeak :)
This date makes a good birthday. Because without Moose there would have not been the same pressure and commitment⦠it changed the game to another level. If Moose would be today on VW, a lot of things would be different⦠Marcus
It would be really good to pick a date, that way we can make this into a little celebration each year !
On 31 Jan 2015, at 18:15, Marcus Denker <marcus.denker@inria.fr> wrote:
On 31 Jan 2015, at 18:11, Marcus Denker <marcus.denker@inria.fr> wrote:
On 31 Jan 2015, at 17:36, Tudor Girba <tudor@tudorgirba.com> wrote:
We started to move Moose from VW to Pharo on April 24, 2008 (right after a decisive meeting with Cincom). This was a very early Pharo (pre 1.0) that was hardly distinguishable from Squeak :)
This date makes a good birthday. Because without Moose there would have not been the same pressure and commitment⦠it changed the game to another level.
If Moose would be today on VW, a lot of things would be differentâ¦
Marcus
Le 27/1/15 13:21, Roberto Minelli a écrit :
### NautilusRefactoring - How does it work? Why there are different methods to remove a class, for example? e.g., NautilusRefactoring>>#removeClasses: vs. AbstractTool>>#removeClasses: I looked at it and clean it a bit. Now AbstractTool is common to all the tools. NautilusRefactoring introduces refactoring at the level of nautilus hence redefines the methods.
- Why #removeClasses: is triggered before the actual removal (i.e., confirmation dialogue)?
where? because this is not what I see. I renamed private... by classRemoval..... removeClasses: aCollection "Execute the refactoring of the receiver." | refactoring | refactoring := self classRemovalRefactoringObjectFor: aCollection. refactoring model environment: self model browsedEnvironment. self performRefactoring: refactoring. ^ true
Sorry for the late reply, Stef. Cool that you cleaned AbstractTool and about the second part of my email.. I was indeed wrong! Cheers, R
On 31 Jan 2015, at 20:39, stepharo <stepharo@free.fr> wrote:
Le 27/1/15 13:21, Roberto Minelli a écrit :
### NautilusRefactoring - How does it work? Why there are different methods to remove a class, for example? e.g., NautilusRefactoring>>#removeClasses: vs. AbstractTool>>#removeClasses: I looked at it and clean it a bit. Now AbstractTool is common to all the tools. NautilusRefactoring introduces refactoring at the level of nautilus hence redefines the methods.
- Why #removeClasses: is triggered before the actual removal (i.e., confirmation dialogue)?
where? because this is not what I see. I renamed private... by classRemoval.....
removeClasses: aCollection "Execute the refactoring of the receiver."
| refactoring | refactoring := self classRemovalRefactoringObjectFor: aCollection. refactoring model environment: self model browsedEnvironment. self performRefactoring: refactoring. ^ true
participants (6)
-
Henrik Johansen -
Marcus Denker -
Roberto Minelli -
stepharo -
Sven Van Caekenberghe -
Tudor Girba