Hi,

Good points.

We are definitely interested in the searching model. Could you send us some pointers? @Alex, could you take a look?

About the composition, I also think it is important. Like you point out, we also observed that when we have layers (like in Spec or Glamour), you lose part of the abilities of the underlying engine. For example, imagine adding animations to a Spec interface. At Morphic/Bloc level, this is not difficult, but at the higher level it is much more expensive. That is why, I think a more promising approach is to merge higher level concepts directly in the widgets.

For example, in the case of Glamour, the key ingredient is the connection of the widgets to model flows of data. This can be made possible directly in morphs and we have the best of both world. It's not exactly Glamour, but the end result will actually be even more flexible. I think a similar approach can work for a Spec-like thing, too.

From my point of view, the most important part is to keep in mind that we keep the ability of creating live and new interfaces. That is why I think it is important to rely on only one basic model: the morphs. For example, if you look at the D3 visualization engine, you will see that it manipulates directly on the HTML DOM, and this can be incredibly powerful. We should do the same.

Cheers,
Doru



On Wed, Aug 26, 2015 at 11:06 AM, stepharo <stepharo@free.fr> wrote:
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:

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

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

We would be happy to hear your feedback.

Cheers,
Doru

--

"Every thing has its own flow"




--
www.tudorgirba.com

"Every thing has its own flow"