[ann] brick on top of bloc - preview

Now that the Moose 6.0 job is working, the last build of Pharo is used and the problem appears in the CI...

Vincent

-----Message d'origine-----
De : Pharo-users [mailto:[hidden email]] De la part de Alexandre Bergel
Envoyé : mercredi 26 août 2015 01:02

À : Any question about pharo is welcome
Objet : Re: [Pharo-users] [ann] brick on top of bloc - preview

Wow…

Alexandre


> On Aug 25, 2015, at 6:41 PM, Vincent BLONDEAU <[hidden email]> wrote:
>
> That is because GToolkit is based on last successful Moose 6.0 build where everything works fine (it is Pharo50248).
> But less than a week ago, a featured bug was integrated in Pharo and it is not possible to load Moose anymore… That is due to some encoding problems during Monticello loading between 50256 and 50257 Pharo versions (integration of Slice 16283).
>
> As I can’t load brick on the 50256 pharo image, I think that the bug you encounter has been introduced before, i.e. between 50248 and 50256. So it is not related to the Moose one.
> Bernardo’s bug is related to traits loading, I have the same bug for one of my project but I didn’t investigate it yet.
>
> Cheers,
> Vincent
>
> De : Pharo-users [mailto:[hidden email]] De la
> part de Tudor Girba Envoyé : mardi 25 août 2015 23:08 À : Any question
> about pharo is welcome Objet : Re: [Pharo-users] [ann] brick on top of
> bloc - preview
>
> Hmm. Thanks for the report. Indeed, I get the same, but the CI job works well. We will have to investigate this.
>
> In the meantime, you can use the image from:
> https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/g
> toolkit5.zip
>
> Cheers,
> Doru
>
>
>
> On Tue, Aug 25, 2015 at 10:51 PM, Bernardo Ezequiel Contreras <[hidden email]> wrote:
>>  i forgot to mention that it was while
>>
>> Loading Bloc-Core-AliakseiSyrel.636
>>
>> thanks
>>
>>
>>
>> On Tue, Aug 25, 2015 at 5:43 PM, Bernardo Ezequiel Contreras <[hidden email]> wrote:
>>> Sorry, but after evaluating
>>>
>>> Gofer new
>>> smalltalkhubUser: 'Pharo' project: 'Brick'; configuration;
>>> loadDevelopment
>>>
>>> in Pharo5.0#50270, i got an Error: Unrecognized class definition
>>>
>>> The screenshots look really cool.
>>>
>>> thanks
>>>
>>>
>>> On Tue, Aug 25, 2015 at 5:13 PM, Tudor Girba <[hidden email]> 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.
>>>>
>>>> Right now, there exists:
>>>> - Label
>>>> - Simple button
>>>> - Toggle button
>>>> - Checkbox
>>>> - Radio button
>>>> - Window with or without an active title bar that can include
>>>> various visual actions and info
>>>> - Menu
>>>> - Beautiful scrollbars that are thin by default and enlarge when
>>>> the mouse hovers over it
>>>> - Scalable list for huge amounts of items with various heights (The
>>>> list also allows one for embedding text widgets with in place
>>>> editing)
>>>>
>>>> The next immediate target is the creation of a new Pager widget (the widget that is behind the current GTInspector).
>>>>
>>>> You can see some screenshots on the official site:
>>>> http://gt.moosetechnology.org/brick
>>>>
>>>> To play with it, you can download a ready-made image:
>>>> https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifac
>>>> t/gtoolkit5.zip
>>>>
>>>> and, in a Bloc space, you can browse the examples:
>>>> BrExampleBrowser exampleOpen
>>>>
>>>> We would be happy to hear your feedback.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Every thing has its own flow"
>>>
>>>
>>>
>>> --
>>> Bernardo E.C.
>>>
>>> Sent from a cheap desktop computer in South America.
>>
>>
>>
>> --
>> Bernardo E.C.
>>
>> Sent from a cheap desktop computer in South America.
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

We did a change last week on MCDataStream. We did it with the intention of making it backward compatible.

Can somebody tell me a repo/package/version that I should try to load to reproduce it?

Guille

El mié., 26 de ago. de 2015 a la(s) 12:00 p. m., Nicolai Hess <[hidden email]> escribió:

2015-08-26 11:00 GMT+02:00 Marcus Denker <[hidden email]>:

> On 26 Aug 2015, at 10:58, Blondeau Vincent <[hidden email]> wrote:
>
> Loading traits only is working, there are traits in Moose and it is well working...
> E.g.:
> Trait named: #TOODependencyQueries
>        uses: TDependencyQueries
>        category: 'Famix-Core’
>

Yes, but there it might not fall back on loading the .st file but instead de-seriaize the MC model.

Yes, I think this is again

MCMczReader>>loadDefinitions
    definitions := OrderedCollection new.
    (self zip memberNamed: 'snapshot.bin') ifNotNil:
        [:m | [^ definitions := (MCDataStream on: m contentStream) next definitions]
            on: Error do: [:fallThrough]].
    "otherwise"
    (self zip membersMatching: 'snapshot/*')
        do: [:m | self extractDefinitionsFrom: m].

if the first run wit hMCDataStream on: ... fails, it uses the "otherwise" path.

But that one does not handle Trait definitions correctly.

I don't know why the first one (MCDataStream ...) fails on some packages, may have something to do with

non-ascii characters but I don't know if it failed always at that place and only the implementation in the

second path changed?

nicolai

 

> Vincent
>
> -----Message d'origine-----
> De : Pharo-users [mailto:[hidden email]] De la part de Marcus Denker
> Envoyé : mercredi 26 août 2015 10:52
> À : Any question about pharo is welcome
> Cc : Pharo Development List
> Objet : Re: [Pharo-users] [ann] brick on top of bloc - preview
>
>
>> On 26 Aug 2015, at 10:42, Tudor Girba <[hidden email]> wrote:
>>
>> Aha. Thanks for the help, Vincent.
>>
>> Now, the next problem: Does anyone know why the "Unrecognized class definition" problem occurs? :)
>>
>
> It seems that
>
> 1) MC model loading of the serialised package fails
> 2) it falls back on using MCStReader
> 3) which fails to load the .st file for the definition of TBlLayoutPropertiesOwner
>
> Maybe loading trait definitions does not work in general with MCStReader?
>
>        Marcus
>
>
> Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.
>
> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
>

Excellent

Two questions:

    Doru recently we (franck on a keyboard) played with the data source model of (mac) of FastTable. We are building a list with a search that displays only the
    matching element. This is interesting to see that we just have to provide a different (more elaborate datasource).
    We can show you a bit what we did.

    I was again rethinking how to compose/reuse logic (basically rethinking Spec ideas). The tension is that when we use composable models
    we by construction limit the functionality that can be composed. For example, it is difficult to expose all the behavior of rubric
    without explosing the API of Text. Now if we use directly widgets then how can we reuse the logic of the composition
    Alain started to brainstorm about it in calypso and I would like to discuss deeper this point.

Stef

I did not see email in the bloc mailing-list. Are you using it?
I would be interested to see some discussions because I have a lot of little details that I came accross building "simple" UI
and I would love to see how Brick handle them.

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.

Right now, there exists:

- Label

- Simple button

- Toggle button

- Checkbox

- Radio button

- Window with or without an active title bar that can include various visual actions and info

- Menu

- Beautiful scrollbars that are thin by default and enlarge when the mouse hovers over it

- Scalable list for huge amounts of items with various heights

(The list also allows one for embedding text widgets with in place editing)

The next immediate target is the creation of a new Pager widget (the widget that is behind the current GTInspector).

You can see some screenshots on the official site:

http://gt.moosetechnology.org/brick

To play with it, you can download a ready-made image:

https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolkit5.zip

and, in a Bloc space, you can browse the examples:

BrExampleBrowser exampleOpen

We would be happy to hear your feedback.

Cheers,

Doru

--

www.tudorgirba.com

"Every thing has its own flow"

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

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