World: r3wp

yes, prototype color scheme. nothing serious.

http://rebol.hmkdesign.dk/files/r3/gui/

Reactors - page moved
This page is being moved to the new R3 document wiki.

Where is the new wiki?

graham: http://www.rebol.com/r3/docs/, i guess

I guess we need some more public tasks, to keep moving. We're contemplating 
messaging between faces and I've written something up in the specs 
document, although I think it's a bit too complex. How does one face 
communicate with another in a simple way? The trick is to both keep 
it simple inside the style design and layout specification. Ideas?

http://rebol.net/wiki/R3_GUI_Specs#Face_attachment

Henrik, a question: currently I see a trend to adopt animated background, 
animated gui elements, animated transitions and sometime 3D ebjects/effects 
in the interfaces. Do you think they could be possible in the next 
R3 GUI ?

they are partially possible as you can see in the built in demo in 
R3, but I haven't studied them closely. I don't think we can do this 
in the beginning, but I think it should be possible to do something 
similar to Core Animation in MacOSX, where shapes, colors and transparency 
can automatically transition between two states. I wrote up some 
quite detailed specs on this a few years ago.

Henrik - have you received any docs on GUI from Carl yet?

nope

Hmm, my question was related to your "face communication" question. 
IIRC, there was nothing like that in prior R3 GUIs .... I wonder 
what do we need it for? I went thru your docs, and they look kind 
of complicated, but maybe those are just detailed and the stuff is 
really needed, so I don't want to judge it preliminarly ...

there was actually something in Gabriele's GUI, but it was very complicated 
to work with.

it's needed to provide automatic messaging between faces, so you 
can for example co-relate the data output of a face (scroller) with 
the y-offset of a panel. This is not very well formalized right now.

I stand corrected, the 'attach keyword is there. Actors/reactors 
are a good idea.

on-attach, on-detach seems the way to go. But maybe I just don't 
understand, what do you miss with the current design?

there's not much missing. I'm just asking if anyone knows a way to 
simplifiy it.

Thanks henrik, it is obvius those are not meant to be included in 
the first instance. However I keep in mind the multi-year target: 
have a modern GUI suitable for all computing platforms.

In demo I can currently see, that you can attach e.g. slider to progress 
bar. It is done in a VID dialect level (reactor?). Then setting the 
slider value will cause on-attach event to be executed?

The way it's done now, it's treated as a bit of a special case: when 
a scroller occurs, it will try to attach itself onto a face that 
has a specific actor, on-scroll (I think it is). I don't like this 
method as it only reveals itself through the style code as a special 
case. There can be hundreds of other ways to attach styles to eachother, 
so there needs to be a generic way to do it.

... understood ...

is Maxim's Liquid stuff not a good source of inspiration for this 
kind of thing?

it might be

I think that liquid might be complete engine, which does not make 
sense to use only some ideas from, but dunno. Max would have to comment 
...

Thanks for bringing this up Henrik.  I was going to say the same 
thing about Max's work. His is a general data flow engine. As usual, 
I think the first step is to clearly define the goal. If REBOL is 
about messaging, attaching faces is a very special case. Even limiting 
the recipient of a message to being a face, you might want more than 
a direct facet mapping.

As I see it, you would want to map any facet in face 1 to any facet 
in face 2. Afterwards, you can judge whether that makes sense or 
not. This could be by checking for accepted datatypes in the target 
face at attach-time, but maybe that's too simple?


Also facet attachment should happen on as many faces as you need. 
If you want a slider to control 20 other faces with different facets 
as input and output, that should be possible. It's starting to look 
like a flow engine, so maybe we should take a look at what Maxim 
has done.

Another issue is that while this should be simple to do in the dialect, 
it should also be possible to create and destroy connections during 
runtime and make it abstracted enough to be possible to do with a 
GUI editor.

Yes, we are on the same page. I see this as built upon a messaging 
infrastructure. It doesn't need to be elaborate today, in what it 
supports, but the design should allow us to extend and build on it. 
i.e. we need a message bus that we can tap into, inside an app, interprocess, 
and distributed.

What I've noticed about Carl's styles is that he tries to do as much 
of that intra-face communication inside the styles.


That is simple to do at first, but doesn't scale very well, because 
we will have a lot of different styles.


Still, some parts could be inherent to the face or style, in that 
the face or style holds a list of actions to perform and then some 
type of evaluator (I've never built these things, so I don't know 
what to call it). There is DO-STYLE, but a formalization of how to 
store the actions inside the face is needed, both when specifying 
face attachments in the layout and when accessing the face attachments 
using a general access function like DO-STYLE or DO-FACE.


The formalization is needed to allow a scalable number of actions 
or attachments stored in each face. This could simply be a block 
of blocks or functions that are bound to both source and target face. 
In order to trigger the action, just DO the block or function and 
the magic unfolds.

Whatever we come up with, it should not be too much complex. Elements 
should be able to register/unregister to particular messages and 
receive events. The engine should be well isolated. Of course the 
question is, where does it lead us :-) We will have to wait for Max, 
to explain us liquid. But - Carl is always right in one aspect - 
if you can't understand the code in few hours, then it is wrong and 
noone will be able to understand it.

could you have gui for other os (linux and osx) now ?

Probably not until it moves to be an Extension and part of the hostkit?

That would be a start, but I wouldn't expect it to be supported for 
those platforms on day one of the new host kit.

However, it will allow the rest of us to help get it working on those 
platforms.

Hmm, I would've expected Maxim to jump in and give his 2 cents when 
he stopped by...

Liquid is the perfect engine to add to R3 GUI.


After years of use in many different situations, I am now very confidents 
in its capabilities.


Liquid is a generic engine, allowing you to tell DATA to message 
DATA.  


This means you can use the same system that you'd use for the GUI, 
for the data itself, and then just plug it together.


Because Liquid was designed to allow very advanced procedural computation 
at a fraction of the complexity of other systems I've used I'd say 
its the best system we'll ever be able to build for R3.


Wrapping liquids within faces and the view dialect is rarely more 
than 5-10 lines of extra code, but then, you don't need to write 
"action" code afterwards.

I've JUST finished work on the first public version of a graphic 
editing software which will go public shortly.  It is built using 
Liquid extensively, using my glob technology (a.k.a. liquid paint).


In this project, I'm even using liquid to do automatic declinations 
of web originated information, some of it directly connected to buttons 
and fields.

Changing some parameters will automatically update other fields and 
button states when the web query is done.  


The software cleans itself up when some other part of the software 
changes internal data.

this is the true value of liquid. :-)

liquid even has data filtering mechanism built-in... so you can patch 
type conversion right in you data, for example, and connect any other 
compatible datatype without needing to build ANY extra code.


Did you notice the detail... I didn't say type conversion in your 
GUI... 


so If your age is supposed to be an integer... pluging it into a 
field can actually make the field an integer field, without the field 
knowing anything about integers.   :-)

It ain't perfect if you don't do it !

anyone can learn liquid.   its dead easy.


its the concept of messaging and dataflow itself which is challenging.

the proof is in the drinking ...

I like to use fields where the prompt is an image in the background 
which disappears on focus, and reappears on loss of focus unless 
some text is present

so if Liquid is perfect, what's the next step? Henrik needs to evaluate 
it? Does that mean that Maxim needs to spend time going over things 
with Henrik? Does Carl have to approve it himself - i.e. does he 
need to spend some time looking it over?

History tells us that nothing will happen ... there is no next step.

Petr, could you push Carl to do something wrt Liquid? At least  to 
spend an hour or two on this or to just rule it out if he's already 
formed some opinion about it. Hope he doesn't though - I thought 
the idea with R3 was to not be so conservative with incorporating 
community contributions.

Maxim, if we want to learn liquid, which version do you recommend 
to use: the one already published, or another, that you could publish 
in the coming days/months ?

We should be shown some liquid usage example, the simple one, to 
understand the concept. Then we should be shown more complex working 
app. If liquid is general flow engine (usefull also to non GUI parts), 
it could be added to rebol as a concept, and maybe even made native, 
but I am not sure if it fits the language or not. Maybe it should 
be available in the form of module/extension, dunno ...

AdrianS: I asked Carl to resurface and provide development team with 
promissed GUI related docs. I hope Carl will be back soon, he worked 
on moving Altme services to new servers (as can be seen in his latest 
blog post)

and working on altme server improvements

I'm having a stupid day where nothing works, so I can't do any work 
right now. I'm not sure it's a good idea to just wrap any flow engine 
on top of the GUI. The idea is simply to . We have to remember that 
it's about the idea

ok, AltME doesn't work either...