AltME groups: search

graham yeah but in fact most of the time when you write a software 
you make it first to feel your need or the need of your client ... 
then you don't think out of the box if that guy will be able to run 
your script on his I-phone with the same posibilities that you initially 
planned

and once again i'm not saying that's not to be done ... i'm saying 
if we take in charge unic specs according to a given documentaton 
then you have to provide a clear information mecanism explaining 
to the user why the technologies involved in the script he wants 
to use is not supported on the plateform he is under if that's the 
case

next issue is storing the tab face in the window face... this is 
necessary to store a tab navigation frame per window. I wonder how 
this is going to be done...

The challenge is to provide a GUI that you don't need to hack to 
make it do what you want. We can go much further with that in R3 
than we ever would be able to with R2.

The challenge is to make a GUI that ordinary users can hack :)

No, the challenge is to make a GUI that ordinary users won't have 
to hack. Ordinary users are terrible at making GUIs, and their attemps 
to hack them look terrible.

worse is that when GUIs scale up, you really don't want to do hacks. 
you want faces to be churned out smoothly, like a  modern car factory.

I have a Dell XT2 tablet with multitouch ... so yes, I would want 
that as well

hmm... it seems that the on-key actor requires keyboard focus for 
the specific face before it works. I figure that the tab navigation 
stuff would fit nicely in the window's on-key actor, but the focus 
requirement is a problem. Ideas?

Yeah, maybe I should repost it here? I put it here, because it was 
a reply to something written here.

And as for Max, he is a bit fanboying here :-) I see absolutly no 
reason to not coordinate with Carl, and it was already taken care 
for :-)

sometimes we don't have a focal face

yes... need to figure out a way to capture which window is active.

Hello everyone.... Robert has invited me to be involved in the GUI 
project.


I thought about it for a few weeks, and decided that I would like 
to do so (become involved)... because Robert is not the only one 
asking for this.  There seems to be other interested persons, no? 


(And, just a note, I am not ignoring the other comments posted above, 
but my desire is to stay on topic here.)

That's a requirement, otherwise you can't do a lot of important key 
functions.

For example, the primary multitouch I miss in VID on OS X is 2-finger 
scroll, but it can be packaged as a scroll event, so should map. 
 (The issues we face will also be faced by all web browsers, so we're 
in good company.)

Many recent operating systems support multitouch, including Mac OS 
X, Windows 7, Windows Vista, Windows XP Tablet PC Edition and Ubuntu 
(since version 7.10), Google's Android, Palm's webOS and Xandros. 
Application frameworks such as MT4j (Multi-touch for Java) and PyMT, 
a Python module that supports multitouch, have also been developed.

Anyway, I'm going to take a crack at cleaning that up.  I need good 
docs thesedays, just to keep my head straight.... I rely on docs 
more then ever these days.

One question I have that I did not see in reading all the docs .. 
how does one generate a GUI event ( to be used inside network code 
) ... since one can't use a wait to allow the gui to update?

Ok, so from here, I'm going to take a "timeout" and sort out the 
docs.  I'm also going to move them to where we have tighter control 
over who and how they get edited.

I have to tell you... I feel like the way-open-wiki was a bit of 
a failure.

What some of us wonder about is since it is a wiki .. why were all 
these changes not just rolled bacak

Carl, the wiki should be downgraded to simply a repository of documents 
to be collected later for permanent storage in the WIP wiki.

G: so, a rollback could lose actual contributions from valid authors.

I thought wikipedia supports page roll back ... but if that wasn't 
the case .. it's a lesson

H: I agree. I'm going to allow only a few uses like Henrik, etc. 
to edit at full control level.  Other uses can submit notes as comments.

G: The problem is that the content was cut and pasted all over the 
place.  It's quite a nightmare as I look it over.

It's different when there is a large body of knowledgeable users 
..., we don't have that yet.

Guys, can we concentrate on the GUI? I think we really need to get 
something done. By that I mean finished to a 1.0 release.

Carl, you posted a specs document to me some time ago regarding guides, 
layers and better layout capabilities. I lost it. :-) Can you post 
it again?

G: Before I can do anything, I need to be sure that we've got the 
basic design well stated in a document.  We can always add from there.

H: I'll take a look around. Probably in R3-GUI world, no?

I posted Carl a list of main topics. IMO the goal is to sort our 
what Carl really can do only by himself. All the rest can be done 
by a group of people. The main effort will be to get the design right. 
If this is done, the rest is "only"  implementation

Carl, I can take a look again.

Yes, I think we have a good critical mass of skillful developers.

We need a good enough solution, that is open enough that we can drive 
it forward. At the end of the day, the GUI must fit the developer 
needs. I'm not seeking for perfection (Ok, I do) but for time-to-market 
(because I learned/know that it's more critical these days).

Is that a GUI or a core issue?

A: Bug.

Carl, looked twice now and only found a small document regarding 
tags (which are implemented now).

I don't recall this being a limitation in R2/vid ... when using keys 
to activate faces

navigating using the tab key, or navigating a tab panel?

something we'll look at later. there's a logical sequence of things 
that we need to get working before we get to resizing.

Nice to see the events evolving...
The community needs a GUI system and creates a team

Reichart wars Carl that something is moving on on this front and 
needs his attention

Carl pop up in the group and catches the wave hoping the GUI sysytem 
does not take the wrong direction (I suppose).
Everyone is happy about this ! :-)

Good. Kr Bacon really messed things up, and this is a source of much 
of the confusion about R3's GUI.

Cyphre is down with the flu right now and a sporadic internet connection 
due to snow, so I have no immediate status of what he's doing, other 
than waiting for the host kit, but what he's shown me, based on a 
separate AGG build, shows that there are a lot of ideas for what 
to do.

The separate AGG build is just there until he can get a hold of the 
host kit and to test ideas.

on a low level yes. on VID level, there's more than enough to do.

So you started styling from scratch? Looks a bit different to your 
initial work, no?

that was a prototype color scheme wasn't it?

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?

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.

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.

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.

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

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.

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.

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.   :-)

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 ...

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

The idea is simply to make it very simple to interconnect faces. 
We have to remember that it's about the idea, not that a really fancy 
flow engine is the solution.

Also I'm being slowed down because of a project that I'm doing for 
Robert that takes time to finish. But please, continue the discussion.

where is actual/latest VID 3.4 code stored? I would like to see, 
how 'attach works, and what it allows, then look into your docs, 
and try to think about it for a while ... well, I will most probably 
not come with anything anyway, but I would at least like to understand 
what we area talking about here ...

I have spoken with Carl in the past about liquid, he REALLY likes 
the concept, he was mezmerized when I did a quick demo of it at Paris 
devcon.


But at that time, I wasn't trying to convince him because I didn't 
have enough real-world experience using it, and still had a few reserves 
about it myself.

A lot more world experience is needed before something unknown is 
added to the GUI

The nice thing about liquid is that its an API more than anything 
and you can model it to do alot of different things, by just changing 
a few properties and implementing one or two functions.


All the nitty gritty is already taken care of and you don't have 
to play around in that unless you really want to create special and 
ultra-optimized nodes whih I very rarely need to do myself.

Although easy to use as a design aim contradicts his new stance that 
Rebol is not for everyone!

the trick with adding Liquid to R3 VID is to integrate liquid INTO 
VID and not the other way around.  in the VID dialect, or as a few 
function calls which just basically create a predefined node type, 
and links it up.

an example of a very complex system which was made 100% robust is 
this:

-an image is used as a background, cropped , transformed and displayed 
within AGG

-we need to overlay an text area over the canvas, but its all AGG 
and its contained within a graphic element.

-we create a face which is a text-area, LINK it to the coordinates 
of the graphic element.

-the face is then converted to an image on the fly everytime the 
coordinates change (even rebuilding the text wrapping interactively)

-this image is added at the proper position with the AGG draw block 
as an image with coordinates.

Currenlty, i try a new way.

No VID engine, just an event handler and Gobs as agents talking with 
their environment.

had I tried to build this system without Liquid... 
  -I'd probably have a very brittle textbox.
  -one that is VERY hard to improve.
  -it would lack a lot of the interactive aspects about it.

each gob having a lot of methods and properties

each gob having a lot of methods and properties

If it's slow .. just get a faster cpu

the opposite principle has been tested with area-tc. Cul de sac.
(i mean, having a fast engine (but huge and hard to maintain)

@ jocko on rebol.org there is a working version of liquid and a small 
demo of how it can be merged right into VID called blood.r

and i don't like the need of  a phase to construct graphical objects 
from read-only specs.
All the GUI we had so far, act such.
It's an bad...

its why I'm pushing for graphic element as a lower-level api for 
AGG right into view.

to my mind there should not be difference of design between a style 
and a face.

A face is an instantiated style (copied and just showed) , tha't 
enough.

Maxim, I have hacked together(in fact it was lurking on my hdd for 
couple of weeks but I got to publish it here today) a test of one 
concept which IMO could solve part of your requests regarding 'access 
to DRAW elements' etc in R3. It can be also handy when you need to 
manipulate content of complex DRAW blocks...or even be a base for 
scalable vector graphics editor...or....I think there is relative 
big potential of usage :-)
Just try to run:
do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes.r
in your R3 console.

BTW The demo also features pixel precise object masking and optimized 
redrawing of DRAW objects just to prove we can do lot of things even 
at the higher level.

The file contains couple of predefined objects but the main code 
is very small like 4kB so it should be easy to see my point. Hope 
this could help a bit to someone.

(found a way to have time events)

http://www.rebol.net/r3blogs/0088.html

A more accurate post on what's going on.

I seem to recall that .002 was a lower limit that could cause issues 
in R2 if you went below that.

Right. I thought maybe R3 had an artifact of that, but it doesn't 
seem so. CPU use goes up as you decrease the wait time, there doesn't 
seem to be a magic threshold.

Is a simple LOOP with a WAIT in it enough for the bug report?

did you do a do-events ?

i don't think so, actually it's a trick i discovered accidentaly. 
I don't thing Carl thought about it

yes, but try: source init-view-system
this is a shortcut for creating the event-port

hum ok, it should not be a burden

Steeve, how is your approach different from a busy loop?