[Pharo-project] [ANN] 10252
Added BoundedGradientFillStyle. Standard Squeak uses original menu pin form. Tweaked appearance of drop lists for Watery 2 as an interim measure. Fixed positioning of drop list pop-up-list to deal with transforms (no rotation though ;-) ) (thanks Alain) Removed "revert" option in patch browser for MC 1.0 compatability. Handle missing remote definition when selecting next conflict. Stef
2009/3/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Added BoundedGradientFillStyle.
can to elaborate , what is it? :) We duscussed the fill styles with Gary a while ago, and the result of a discussion is to make fill styles to know what they need to do to fill the given shape i.e. fill style could be seen as a function: f(shape, canvas) and, to use a fill style, in general form, you simply should use: myfillStyle fill: someShape on: canvas. This concept were introduced into Polymorph, and as first proof of it, Gary implemented a composite fill styles. But it's far from complete. In ideal, i'd like to get rid of many 'isXXXFill', like #isGradientFill and others and remove any code which relying on fill style properties - instead it should always delegate the responsibility from filling a shape to a fill style object. This approach , also opens a new questions: - how do we treat a morph. Should morph define own shape? Or shape is something that should be determined procedurally, and morph could contain/use as many shapes as it wants to for representing itself on canvas? I am far from thinking that morph's shape is rectangular (but there are many aspects in morphic, assuming it is rectangular - such as #fullBounds or #bounds), as well as i don't think that making morph === shape is a good choice.
Standard Squeak uses original menu pin form. Tweaked appearance of drop lists for Watery 2 as an interim measure. Fixed positioning of drop list pop-up-list to deal with transforms (no rotation though ;-) ) (thanks Alain)
Removed "revert" option in patch browser for MC 1.0 compatability. Handle missing remote definition when selecting next conflict.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I will let gary reply and rollback if necessary. or even better integrate next fixes :) I thought it was ready for integration. stef On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote:
2009/3/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Added BoundedGradientFillStyle.
can to elaborate , what is it? :)
We duscussed the fill styles with Gary a while ago, and the result of a discussion is to make fill styles to know what they need to do to fill the given shape i.e. fill style could be seen as a function: f(shape, canvas)
and, to use a fill style, in general form, you simply should use: myfillStyle fill: someShape on: canvas.
This concept were introduced into Polymorph, and as first proof of it, Gary implemented a composite fill styles. But it's far from complete. In ideal, i'd like to get rid of many 'isXXXFill', like #isGradientFill and others and remove any code which relying on fill style properties - instead it should always delegate the responsibility from filling a shape to a fill style object.
This approach , also opens a new questions: - how do we treat a morph. Should morph define own shape? Or shape is something that should be determined procedurally, and morph could contain/use as many shapes as it wants to for representing itself on canvas? I am far from thinking that morph's shape is rectangular (but there are many aspects in morphic, assuming it is rectangular - such as #fullBounds or #bounds), as well as i don't think that making morph === shape is a good choice.
Standard Squeak uses original menu pin form. Tweaked appearance of drop lists for Watery 2 as an interim measure. Fixed positioning of drop list pop-up-list to deal with transforms (no rotation though ;-) ) (thanks Alain)
Removed "revert" option in patch browser for MC 1.0 compatability. Handle missing remote definition when selecting next conflict.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/3/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I will let gary reply and rollback if necessary. or even better integrate next fixes :) I thought it was ready for integration.
I didn't said its not ready.. I just wanted to point out, that it is half-done, in the way how i see it should be done. It works, of course, but not so elegant as it should be :)
stef On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote:
2009/3/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Added BoundedGradientFillStyle.
can to elaborate , what is it? :)
We duscussed the fill styles with Gary a while ago, and the result of a discussion is to make fill styles to know what they need to do to fill the given shape i.e. fill style could be seen as a function: f(shape, canvas)
and, to use a fill style, in general form, you simply should use: myfillStyle fill: someShape on: canvas.
This concept were introduced into Polymorph, and as first proof of it, Gary implemented a composite fill styles. But it's far from complete. In ideal, i'd like to get rid of many 'isXXXFill', like #isGradientFill and others and remove any code which relying on fill style properties - instead it should always delegate the responsibility from filling a shape to a fill style object.
This approach , also opens a new questions: - how do we treat a morph. Should morph define own shape? Or shape is something that should be determined procedurally, and morph could contain/use as many shapes as it wants to for representing itself on canvas? I am far from thinking that morph's shape is rectangular (but there are many aspects in morphic, assuming it is rectangular - such as #fullBounds or #bounds), as well as i don't think that making morph === shape is a good choice.
Standard Squeak uses original menu pin form. Tweaked appearance of drop lists for Watery 2 as an interim measure. Fixed positioning of drop list pop-up-list to deal with transforms (no rotation though ;-) ) (thanks Alain)
Removed "revert" option in patch browser for MC 1.0 compatability. Handle missing remote definition when selecting next conflict.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2009/3/14 Igor Stasenko <siguctua@gmail.com>:
2009/3/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I will let gary reply and rollback if necessary. or even better integrate next fixes :) I thought it was ready for integration.
I didn't said its not ready.. I just wanted to point out, that it is half-done, in the way how i see it should be done. It works, of course, but not so elegant as it should be :)
stef On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote:
2009/3/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Added BoundedGradientFillStyle.
can to elaborate , what is it? :)
We duscussed the fill styles with Gary a while ago, and the result of a discussion is to make fill styles to know what they need to do to fill the given shape i.e. fill style could be seen as a function: f(shape, canvas)
going further with that, all drawings (not only fills) on canvas could be represented by such function f(shape, canvas) but it would require a deep refactorings in bitblt/morphic engine to do such unification. With such approach, it would be easy to introduce a new fill styles, such as bevel/emboss, blur , etc. While old fillstyles implementation is quite limited, because fillstyle used as a dumb state holder and drawing engine performs different tests (isXXXX) to do the right thing.
and, to use a fill style, in general form, you simply should use: myfillStyle fill: someShape on: canvas.
This concept were introduced into Polymorph, and as first proof of it, Gary implemented a composite fill styles. But it's far from complete. In ideal, i'd like to get rid of many 'isXXXFill', like #isGradientFill and others and remove any code which relying on fill style properties - instead it should always delegate the responsibility from filling a shape to a fill style object.
This approach , also opens a new questions: - how do we treat a morph. Should morph define own shape? Or shape is something that should be determined procedurally, and morph could contain/use as many shapes as it wants to for representing itself on canvas? I am far from thinking that morph's shape is rectangular (but there are many aspects in morphic, assuming it is rectangular - such as #fullBounds or #bounds), as well as i don't think that making morph === shape is a good choice.
Standard Squeak uses original menu pin form. Tweaked appearance of drop lists for Watery 2 as an interim measure. Fixed positioning of drop list pop-up-list to deal with transforms (no rotation though ;-) ) (thanks Alain)
Removed "revert" option in patch browser for MC 1.0 compatability. Handle missing remote definition when selecting next conflict.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Sadly BitBlt and/or Balloon don't support much so we're stuck with GradientFills and rectangles for shapes (where the double-dispatched "puting the behaviour in the fill style" is concerned, unless the low-level shape drawing types are all dispatched)... As for the original question, BoundedGradientFillStyle simply allows for an extent so that, as part of a composite, it can be limited to only part of the drawing area. This makes it possible to make composites that have different corner images (for example) along with gradients for the "stretchy bits" in between... In respect of the isXXX methods, these could be refactored properly such that the morph informs its fillStyle of bounds changes. For simple colours this would be effecitvely a no-op, gardients would adjust their origin etc. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, March 14, 2009 9:13 AM Subject: Re: [Pharo-project] [ANN] 10252
2009/3/14 Igor Stasenko <siguctua@gmail.com>:
2009/3/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I will let gary reply and rollback if necessary. or even better integrate next fixes :) I thought it was ready for integration.
I didn't said its not ready.. I just wanted to point out, that it is half-done, in the way how i see it should be done. It works, of course, but not so elegant as it should be :)
stef On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote:
2009/3/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Added BoundedGradientFillStyle.
can to elaborate , what is it? :)
We duscussed the fill styles with Gary a while ago, and the result of a discussion is to make fill styles to know what they need to do to fill the given shape i.e. fill style could be seen as a function: f(shape, canvas)
going further with that, all drawings (not only fills) on canvas could be represented by such function f(shape, canvas) but it would require a deep refactorings in bitblt/morphic engine to do such unification.
With such approach, it would be easy to introduce a new fill styles, such as bevel/emboss, blur , etc. While old fillstyles implementation is quite limited, because fillstyle used as a dumb state holder and drawing engine performs different tests (isXXXX) to do the right thing.
and, to use a fill style, in general form, you simply should use: myfillStyle fill: someShape on: canvas.
This concept were introduced into Polymorph, and as first proof of it, Gary implemented a composite fill styles. But it's far from complete. In ideal, i'd like to get rid of many 'isXXXFill', like #isGradientFill and others and remove any code which relying on fill style properties - instead it should always delegate the responsibility from filling a shape to a fill style object.
This approach , also opens a new questions: - how do we treat a morph. Should morph define own shape? Or shape is something that should be determined procedurally, and morph could contain/use as many shapes as it wants to for representing itself on canvas? I am far from thinking that morph's shape is rectangular (but there are many aspects in morphic, assuming it is rectangular - such as #fullBounds or #bounds), as well as i don't think that making morph === shape is a good choice.
Standard Squeak uses original menu pin form. Tweaked appearance of drop lists for Watery 2 as an interim measure. Fixed positioning of drop list pop-up-list to deal with transforms (no rotation though ;-) ) (thanks Alain)
Removed "revert" option in patch browser for MC 1.0 compatability. Handle missing remote definition when selecting next conflict.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
a question: would it help to have rome canvas? because I would really like to curve it out of sophie for 1.1 stef On Mar 14, 2009, at 2:59 PM, Gary Chambers wrote:
Sadly BitBlt and/or Balloon don't support much so we're stuck with GradientFills and rectangles for shapes (where the double-dispatched "puting the behaviour in the fill style" is concerned, unless the low-level shape drawing types are all dispatched)...
As for the original question, BoundedGradientFillStyle simply allows for an extent so that, as part of a composite, it can be limited to only part of the drawing area. This makes it possible to make composites that have different corner images (for example) along with gradients for the "stretchy bits" in between...
In respect of the isXXX methods, these could be refactored properly such that the morph informs its fillStyle of bounds changes. For simple colours this would be effecitvely a no-op, gardients would adjust their origin etc.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, March 14, 2009 9:13 AM Subject: Re: [Pharo-project] [ANN] 10252
2009/3/14 Igor Stasenko <siguctua@gmail.com>:
2009/3/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I will let gary reply and rollback if necessary. or even better integrate next fixes :) I thought it was ready for integration.
I didn't said its not ready.. I just wanted to point out, that it is half-done, in the way how i see it should be done. It works, of course, but not so elegant as it should be :)
stef On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote:
2009/3/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Added BoundedGradientFillStyle.
can to elaborate , what is it? :)
We duscussed the fill styles with Gary a while ago, and the result of a discussion is to make fill styles to know what they need to do to fill the given shape i.e. fill style could be seen as a function: f(shape, canvas)
going further with that, all drawings (not only fills) on canvas could be represented by such function f(shape, canvas) but it would require a deep refactorings in bitblt/morphic engine to do such unification.
With such approach, it would be easy to introduce a new fill styles, such as bevel/emboss, blur , etc. While old fillstyles implementation is quite limited, because fillstyle used as a dumb state holder and drawing engine performs different tests (isXXXX) to do the right thing.
and, to use a fill style, in general form, you simply should use: myfillStyle fill: someShape on: canvas.
This concept were introduced into Polymorph, and as first proof of it, Gary implemented a composite fill styles. But it's far from complete. In ideal, i'd like to get rid of many 'isXXXFill', like #isGradientFill and others and remove any code which relying on fill style properties - instead it should always delegate the responsibility from filling a shape to a fill style object.
This approach , also opens a new questions: - how do we treat a morph. Should morph define own shape? Or shape is something that should be determined procedurally, and morph could contain/use as many shapes as it wants to for representing itself on canvas? I am far from thinking that morph's shape is rectangular (but there are many aspects in morphic, assuming it is rectangular - such as #fullBounds or #bounds), as well as i don't think that making morph === shape is a good choice.
Standard Squeak uses original menu pin form. Tweaked appearance of drop lists for Watery 2 as an interim measure. Fixed positioning of drop list pop-up-list to deal with transforms (no rotation though ;-) ) (thanks Alain)
Removed "revert" option in patch browser for MC 1.0 compatability. Handle missing remote definition when selecting next conflict.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
A lot more could be done with Rome, though only then availbale for platforms with Cario... Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, March 14, 2009 3:22 PM Subject: Re: [Pharo-project] [ANN] 10252 a question: would it help to have rome canvas? because I would really like to curve it out of sophie for 1.1 stef On Mar 14, 2009, at 2:59 PM, Gary Chambers wrote:
Sadly BitBlt and/or Balloon don't support much so we're stuck with GradientFills and rectangles for shapes (where the double-dispatched "puting the behaviour in the fill style" is concerned, unless the low-level shape drawing types are all dispatched)...
As for the original question, BoundedGradientFillStyle simply allows for an extent so that, as part of a composite, it can be limited to only part of the drawing area. This makes it possible to make composites that have different corner images (for example) along with gradients for the "stretchy bits" in between...
In respect of the isXXX methods, these could be refactored properly such that the morph informs its fillStyle of bounds changes. For simple colours this would be effecitvely a no-op, gardients would adjust their origin etc.
Regards, Gary
----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, March 14, 2009 9:13 AM Subject: Re: [Pharo-project] [ANN] 10252
2009/3/14 Igor Stasenko <siguctua@gmail.com>:
2009/3/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
I will let gary reply and rollback if necessary. or even better integrate next fixes :) I thought it was ready for integration.
I didn't said its not ready.. I just wanted to point out, that it is half-done, in the way how i see it should be done. It works, of course, but not so elegant as it should be :)
stef On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote:
2009/3/13 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Added BoundedGradientFillStyle.
can to elaborate , what is it? :)
We duscussed the fill styles with Gary a while ago, and the result of a discussion is to make fill styles to know what they need to do to fill the given shape i.e. fill style could be seen as a function: f(shape, canvas)
going further with that, all drawings (not only fills) on canvas could be represented by such function f(shape, canvas) but it would require a deep refactorings in bitblt/morphic engine to do such unification.
With such approach, it would be easy to introduce a new fill styles, such as bevel/emboss, blur , etc. While old fillstyles implementation is quite limited, because fillstyle used as a dumb state holder and drawing engine performs different tests (isXXXX) to do the right thing.
and, to use a fill style, in general form, you simply should use: myfillStyle fill: someShape on: canvas.
This concept were introduced into Polymorph, and as first proof of it, Gary implemented a composite fill styles. But it's far from complete. In ideal, i'd like to get rid of many 'isXXXFill', like #isGradientFill and others and remove any code which relying on fill style properties - instead it should always delegate the responsibility from filling a shape to a fill style object.
This approach , also opens a new questions: - how do we treat a morph. Should morph define own shape? Or shape is something that should be determined procedurally, and morph could contain/use as many shapes as it wants to for representing itself on canvas? I am far from thinking that morph's shape is rectangular (but there are many aspects in morphic, assuming it is rectangular - such as #fullBounds or #bounds), as well as i don't think that making morph === shape is a good choice.
Standard Squeak uses original menu pin form. Tweaked appearance of drop lists for Watery 2 as an interim measure. Fixed positioning of drop list pop-up-list to deal with transforms (no rotation though ;-) ) (thanks Alain)
Removed "revert" option in patch browser for MC 1.0 compatability. Handle missing remote definition when selecting next conflict.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Gary Chambers wrote:
A lot more could be done with Rome, though only then availbale for platforms with Cario...
That is not entirely true. Rome has also a Balloon backend, though ti hasn't been updated in a while. It should also be possible to build a BitBlt back end with fallbacks for unsupported features like certain gradients. Michael
Michael Rueger wrote:
Gary Chambers wrote:
A lot more could be done with Rome, though only then availbale for platforms with Cario...
That is not entirely true. Rome has also a Balloon backend, though ti hasn't been updated in a while. It should also be possible to build a BitBlt back end with fallbacks for unsupported features like certain gradients.
Hmm, thinking about it a second more ;-) BitBlt would only make sense for relatively simple graphics as otherwise you would need Balloon's features for drawing curves etc. Michael
noob question: downloadable from? or is just updating a 243? sebastian
-----Mensaje original----- De: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] En nombre de Stephane Ducasse Enviado el: Friday, March 13, 2009 18:27 Para: Pharo Development Asunto: [Pharo-project] [ANN] 10252
Added BoundedGradientFillStyle. Standard Squeak uses original menu pin form. Tweaked appearance of drop lists for Watery 2 as an interim measure. Fixed positioning of drop list pop-up-list to deal with transforms (no rotation though ;-) ) (thanks Alain)
Removed "revert" option in patch browser for MC 1.0 compatability. Handle missing remote definition when selecting next conflict.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Mar 17, 2009 at 4:35 AM, Sebastian Sastre <ssastre@seaswork.com> wrote:
noob question: downloadable from? or is just updating a 243?
All downloadable versions are in: https://gforge.inria.fr/frs/?group_id=1299 If you can't find in you have to update. -- Damien Cassou http://damiencassou.seasidehosting.st
participants (6)
-
Damien Cassou -
Gary Chambers -
Igor Stasenko -
Michael Rueger -
Sebastian Sastre -
Stéphane Ducasse