Fwd: [Pharo-users] [ann] brick on top of bloc - preview
On Wed, Aug 26, 2015 at 4:13 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
We are happy to announce the first preview version of Brick, a new widget set created from scratch on top of Bloc.
Brick is being developed primarily by Alex Syrel (together with Alain Plantec, Andrei Chis and myself), and the work is sponsored by ESUG. Brick is part of the Glamorous Toolkit effort and will provide the basis for the new versions of the development tools.
Brick's goal is to provide a beautiful looking widget set, and the default look is based on material design. The widgets are theme-able.
(whoops, slip of the <enter> key) Interesting to read about Z-depth [1] use in Material Design ... "In addition to the X and Y properties, views in Android now have a Z property. This new property represents the elevation of a view, which determines: The size of the shadow: views with higher Z values cast bigger shadows. The drawing order: views with higher Z values appear on top of other views." So morphic has a Z-order but I think not a Z-depth. Is that be something we should be aiming for? [1] https://developer.android.com/design/material/index.html cheers -ben
On Wed, Aug 26, 2015 at 11:45 PM Ben Coman <btc@openinworld.com> wrote:
So morphic has a Z-order but I think not a Z-depth. Is that be something we should be aiming for?
In HTML5, Z-depth is pretty exclusively used as a mechanism to determine Z-order in the HTML / CSS separation. Normally, the order of HTML determines the Z-order. But, Z-order is really a style thing, rather than a composition thing. So, specifying the Z-depth allows you to override standard behavior in the style sheet. This is not necessary in a true object-based GUI where graphical objects are more self contained and can easily determine their own Z-order. I doubt we will see general purpose adoption of any 2D interface that will rely on Z-depth for anything besides determining Z-order. For instance, the example of shadow size seems interesting but runs into usability problems quickly. Let's say that you have element A with a larger shadow to indicate that it is above element B with a smaller shadow. That seems great. What happens if element B is selected and brought to the forefront? Does A's shadow go down in size? If so, that breaks the normal shadow analogy. If not, it would seem that the shadows would just keep growing bigger each time a new element is brought to the front. For limited general-purpose applications (e.g., a larger shadow for an object currently being dragged), you don't need Z-depth info. For specialized applications where a Z-depth might make sense (I can't even think of one), there's little problem adding such functionality to custom widgets. So, my recommendations is to stay away from trying to implement Z-depth as a fundamental component of a 2D interface. The benefit is minimal and largely theoretical. Cheers, Jeff
On Fri, Aug 28, 2015 at 8:34 AM, J.F. Rick <self@je77.com> wrote:
On Wed, Aug 26, 2015 at 11:45 PM Ben Coman <btc@openinworld.com> wrote:
So morphic has a Z-order but I think not a Z-depth. Is that be something we should be aiming for?
In HTML5, Z-depth is pretty exclusively used as a mechanism to determine Z-order in the HTML / CSS separation. Normally, the order of HTML determines the Z-order. But, Z-order is really a style thing, rather than a composition thing. So, specifying the Z-depth allows you to override standard behavior in the style sheet. This is not necessary in a true object-based GUI where graphical objects are more self contained and can easily determine their own Z-order.
I doubt we will see general purpose adoption of any 2D interface that will rely on Z-depth for anything besides determining Z-order. For instance, the example of shadow size seems interesting but runs into usability problems quickly. Let's say that you have element A with a larger shadow to indicate that it is above element B with a smaller shadow. That seems great. What happens if element B is selected and brought to the forefront? Does A's shadow go down in size? If so, that breaks the normal shadow analogy. If not, it would seem that the shadows would just keep growing bigger each time a new element is brought to the front. For limited general-purpose applications (e.g., a larger shadow for an object currently being dragged), you don't need Z-depth info. For specialized applications where a Z-depth might make sense (I can't even think of one), there's little problem adding such functionality to custom widgets. So, my recommendations is to stay away from trying to implement Z-depth as a fundamental component of a 2D interface. The benefit is minimal and largely theoretical.
Cheers,
Jeff
Thats a fair argument, thanks Jeff. I guess if someone wanted different size shadows for different z-order, a fixed distance between levels could be simulated with all windows shuffling down when a window is brought to the top. cheers -ben
Great job! Works well. Thank you! cheers Ricky On Fri, Aug 28, 2015 at 4:16 AM, Ben Coman <btc@openinworld.com> wrote:
On Fri, Aug 28, 2015 at 8:34 AM, J.F. Rick <self@je77.com> wrote:
On Wed, Aug 26, 2015 at 11:45 PM Ben Coman <btc@openinworld.com> wrote:
So morphic has a Z-order but I think not a Z-depth. Is that be something we should be aiming for?
In HTML5, Z-depth is pretty exclusively used as a mechanism to determine Z-order in the HTML / CSS separation. Normally, the order of HTML determines the Z-order. But, Z-order is really a style thing, rather than a composition thing. So, specifying the Z-depth allows you to override standard behavior in the style sheet. This is not necessary in a true object-based GUI where graphical objects are more self contained and can easily determine their own Z-order.
I doubt we will see general purpose adoption of any 2D interface that will rely on Z-depth for anything besides determining Z-order. For instance, the example of shadow size seems interesting but runs into usability problems quickly. Let's say that you have element A with a larger shadow to indicate that it is above element B with a smaller shadow. That seems great. What happens if element B is selected and brought to the forefront? Does A's shadow go down in size? If so, that breaks the normal shadow analogy. If not, it would seem that the shadows would just keep growing bigger each time a new element is brought to the front. For limited general-purpose applications (e.g., a larger shadow for an object currently being dragged), you don't need Z-depth info. For specialized applications where a Z-depth might make sense (I can't even think of one), there's little problem adding such functionality to custom widgets. So, my recommendations is to stay away from trying to implement Z-depth as a fundamental component of a 2D interface. The benefit is minimal and largely theoretical.
Cheers,
Jeff
Thats a fair argument, thanks Jeff. I guess if someone wanted different size shadows for different z-order, a fixed distance between levels could be simulated with all windows shuffling down when a window is brought to the top. cheers -ben
Getting an error on loading bloc: Using base Pharo 4.0 with Pharo 5 image / changes. [image: Inline image 1] On Fri, Aug 28, 2015 at 1:41 PM, Richard Wettel <wettel@gmail.com> wrote:
Great job! Works well. Thank you!
cheers Ricky
On Fri, Aug 28, 2015 at 4:16 AM, Ben Coman <btc@openinworld.com> wrote:
On Fri, Aug 28, 2015 at 8:34 AM, J.F. Rick <self@je77.com> wrote:
On Wed, Aug 26, 2015 at 11:45 PM Ben Coman <btc@openinworld.com> wrote:
So morphic has a Z-order but I think not a Z-depth. Is that be something we should be aiming for?
In HTML5, Z-depth is pretty exclusively used as a mechanism to determine Z-order in the HTML / CSS separation. Normally, the order of HTML determines the Z-order. But, Z-order is really a style thing, rather than a composition thing. So, specifying the Z-depth allows you to override standard behavior in the style sheet. This is not necessary in a true object-based GUI where graphical objects are more self contained and can easily determine their own Z-order.
I doubt we will see general purpose adoption of any 2D interface that will rely on Z-depth for anything besides determining Z-order. For instance, the example of shadow size seems interesting but runs into usability problems quickly. Let's say that you have element A with a larger shadow to indicate that it is above element B with a smaller shadow. That seems great. What happens if element B is selected and brought to the forefront? Does A's shadow go down in size? If so, that breaks the normal shadow analogy. If not, it would seem that the shadows would just keep growing bigger each time a new element is brought to the front. For limited general-purpose applications (e.g., a larger shadow for an object currently being dragged), you don't need Z-depth info. For specialized applications where a Z-depth might make sense (I can't even think of one), there's little problem adding such functionality to custom widgets. So, my recommendations is to stay away from trying to implement Z-depth as a fundamental component of a 2D interface. The benefit is minimal and largely theoretical.
Cheers,
Jeff
Thats a fair argument, thanks Jeff. I guess if someone wanted different size shadows for different z-order, a fixed distance between levels could be simulated with all windows shuffling down when a window is brought to the top. cheers -ben
This should be fixed in the last version (50286) On Fri, Aug 28, 2015 at 10:34 AM, S Krish <krishnamachari.sudhakar@gmail.com
wrote:
Getting an error on loading bloc:
Using base Pharo 4.0 with Pharo 5 image / changes.
[image: Inline image 1]
On Fri, Aug 28, 2015 at 1:41 PM, Richard Wettel <wettel@gmail.com> wrote:
Great job! Works well. Thank you!
cheers Ricky
On Fri, Aug 28, 2015 at 4:16 AM, Ben Coman <btc@openinworld.com> wrote:
On Fri, Aug 28, 2015 at 8:34 AM, J.F. Rick <self@je77.com> wrote:
On Wed, Aug 26, 2015 at 11:45 PM Ben Coman <btc@openinworld.com> wrote:
So morphic has a Z-order but I think not a Z-depth. Is that be something we should be aiming for?
In HTML5, Z-depth is pretty exclusively used as a mechanism to determine Z-order in the HTML / CSS separation. Normally, the order of HTML determines the Z-order. But, Z-order is really a style thing, rather than a composition thing. So, specifying the Z-depth allows you to override standard behavior in the style sheet. This is not necessary in a true object-based GUI where graphical objects are more self contained and can easily determine their own Z-order.
I doubt we will see general purpose adoption of any 2D interface that will rely on Z-depth for anything besides determining Z-order. For instance, the example of shadow size seems interesting but runs into usability problems quickly. Let's say that you have element A with a larger shadow to indicate that it is above element B with a smaller shadow. That seems great. What happens if element B is selected and brought to the forefront? Does A's shadow go down in size? If so, that breaks the normal shadow analogy. If not, it would seem that the shadows would just keep growing bigger each time a new element is brought to the front. For limited general-purpose applications (e.g., a larger shadow for an object currently being dragged), you don't need Z-depth info. For specialized applications where a Z-depth might make sense (I can't even think of one), there's little problem adding such functionality to custom widgets. So, my recommendations is to stay away from trying to implement Z-depth as a fundamental component of a 2D interface. The benefit is minimal and largely theoretical.
Cheers,
Jeff
Thats a fair argument, thanks Jeff. I guess if someone wanted different size shadows for different z-order, a fixed distance between levels could be simulated with all windows shuffling down when a window is brought to the top. cheers -ben
-- -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
I am getting a strange FastTable error... I downloaded latest gtoolkit5 build (#166; uses Pharo #50248), but when I open System Browser no classes are visible, if I click on the empty space I get an error in the zip provided by Aliaksei it works fine (Pharo #50222, build unknown). Peter On Fri, Aug 28, 2015 at 3:33 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
This should be fixed in the last version (50286)
On Fri, Aug 28, 2015 at 10:34 AM, S Krish < krishnamachari.sudhakar@gmail.com> wrote:
Getting an error on loading bloc:
Using base Pharo 4.0 with Pharo 5 image / changes.
[image: Inline image 1]
On Fri, Aug 28, 2015 at 1:41 PM, Richard Wettel <wettel@gmail.com> wrote:
Great job! Works well. Thank you!
cheers Ricky
On Fri, Aug 28, 2015 at 4:16 AM, Ben Coman <btc@openinworld.com> wrote:
On Fri, Aug 28, 2015 at 8:34 AM, J.F. Rick <self@je77.com> wrote:
On Wed, Aug 26, 2015 at 11:45 PM Ben Coman <btc@openinworld.com> wrote:
So morphic has a Z-order but I think not a Z-depth. Is that be something we should be aiming for?
In HTML5, Z-depth is pretty exclusively used as a mechanism to determine Z-order in the HTML / CSS separation. Normally, the order of HTML determines the Z-order. But, Z-order is really a style thing, rather than a composition thing. So, specifying the Z-depth allows you to override standard behavior in the style sheet. This is not necessary in a true object-based GUI where graphical objects are more self contained and can easily determine their own Z-order.
I doubt we will see general purpose adoption of any 2D interface that will rely on Z-depth for anything besides determining Z-order. For instance, the example of shadow size seems interesting but runs into usability problems quickly. Let's say that you have element A with a larger shadow to indicate that it is above element B with a smaller shadow. That seems great. What happens if element B is selected and brought to the forefront? Does A's shadow go down in size? If so, that breaks the normal shadow analogy. If not, it would seem that the shadows would just keep growing bigger each time a new element is brought to the front. For limited general-purpose applications (e.g., a larger shadow for an object currently being dragged), you don't need Z-depth info. For specialized applications where a Z-depth might make sense (I can't even think of one), there's little problem adding such functionality to custom widgets. So, my recommendations is to stay away from trying to implement Z-depth as a fundamental component of a 2D interface. The benefit is minimal and largely theoretical.
Cheers,
Jeff
Thats a fair argument, thanks Jeff. I guess if someone wanted different size shadows for different z-order, a fixed distance between levels could be simulated with all windows shuffling down when a window is brought to the top. cheers -ben
-- -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
Le 28/08/2015 17:56, Peter Uhnák a écrit :
I am getting a strange FastTable error...
I downloaded latest gtoolkit5 build (#166; uses Pharo #50248), but when I open System Browser no classes are visible, if I click on the empty space I get an error
in the zip provided by Aliaksei it works fine (Pharo #50222, build unknown).
Peter
Seems to be related to https://pharo.fogbugz.com/f/cases/16267/Fasttable-isn-t-visible-in-athens-in... -- Cheers Cyril Ferlicot-Delbecque
In HTML5, Z-depth is pretty exclusively used as a mechanism to determine Z-order in the HTML / CSS separation. Normally, the order of HTML determines the Z-order. But, Z-order is really a style thing, rather than a composition thing. So, specifying the Z-depth allows you to override standard behavior in the style sheet. This is not necessary in a true object-based GUI where graphical objects are more self contained and can easily determine their own Z-order.
I doubt we will see general purpose adoption of any 2D interface that will rely on Z-depth for anything besides determining Z-order. For instance, the example of shadow size seems interesting but runs into usability problems quickly. Let's say that you have element A with a larger shadow to indicate that it is above element B with a smaller shadow. That seems great. What happens if element B is selected and brought to the forefront? Does A's shadow go down in size? If so, that breaks the normal shadow analogy. If not, it would seem that the shadows would just keep growing bigger each time a new element is brought to the front. For limited general-purpose applications (e.g., a larger shadow for an object currently being dragged), you don't need Z-depth info. For specialized applications where a Z-depth might make sense (I can't even think of one), there's little problem adding such functionality to custom widgets. So, my recommendations is to stay away from trying to implement Z-depth as a fundamental component of a 2D interface. The benefit is minimal and largely theoretical.
+ 1 Stef
participants (8)
-
Ben Coman -
Ferlicot D. Cyril -
J.F. Rick -
Marcus Denker -
Peter Uhnák -
Richard Wettel -
S Krish -
stepharo