[ann] brick on top of bloc - preview

Getting an error on loading bloc:

Using base Pharo 4.0 with Pharo 5 image / changes.

On Fri, Aug 28, 2015 at 1:41 PM, Richard Wettel <[hidden email]> wrote:

Great job! Works well. Thank you!

cheers

Ricky

On Fri, Aug 28, 2015 at 4:16 AM, Ben Coman <[hidden email]> wrote:

On Fri, Aug 28, 2015 at 8:34 AM, J.F. Rick <[hidden email]> wrote:
> On Wed, Aug 26, 2015 at 11:45 PM Ben Coman <[hidden email]> 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 <[hidden email]> wrote:

Getting an error on loading bloc:

Using base Pharo 4.0 with Pharo 5 image / changes.

On Fri, Aug 28, 2015 at 1:41 PM, Richard Wettel <[hidden email]> wrote:

Great job! Works well. Thank you!

cheers

Ricky

On Fri, Aug 28, 2015 at 4:16 AM, Ben Coman <[hidden email]> wrote:

On Fri, Aug 28, 2015 at 8:34 AM, J.F. Rick <[hidden email]> wrote:
> On Wed, Aug 26, 2015 at 11:45 PM Ben Coman <[hidden email]> 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  --  [hidden email]
http://www.marcusdenker.de