AltME groups: search

why do this when there are thousands of other words to choose from??

One shouldn't need to access faces directly. In time, I think GET-FACE 
and SET-FACE will do this, but you might need to pass the window 
face first:

get-face window my-form


Carl already has used a /field refinement, but I'm not sure what 
it does.

Posted some of that. Still a lot left to do. Feel free to comment 
in here.

The window face needs to know which face is the one tabbed to. This 
means it has to be extended with TAB-FACE. I wonder where it's best 
to do that...

Got basic face traversal working: LOCATE-FACE, NEXT-FACE, BACK-FACE, 
TRAVERSE-FACE, INSIDE-FACE?, FIND-RELATIVE-FACE, GET-TIP-FACE are 
now ported from the VID Extension Kit.

Requires no modification to VID3.4.

It can be tested here:

do http://rebol.hmkdesign.dk/files/r3/gui/traversal.r

@Shadwolf: If Carl doesn't agree with what we do or wants to position 
VID34 different than it will be a fork. Overall I still think we 
should avoid creating to much GUI forks and fragment our little community 
forces but instead pool forces to faster move forward.

Robert i think 2 years ago the reply from carl was christal clear 
VID3.4 is not what he wanted  drop it he would do VID alone when 
he get the time and in the mean time 2 years 24  month  we lost  
an opportunity to motivate ourselves to get VID 3.4  tuned up

how do you want people contribute with quality when they don't have 
a sand bow to shape their abilities ?

Carl seems to have some specific stuff in mind for vid direction 
but he is just not going to get to it anytime soon...I do not see 
a prob with you guys coming up with an alternate vid (rebgui for 
r3) in the mean time...each gui may be addressing different needs 
anyway. Carl's VID, when ready, can become the defacto and distributed 
with R3 but in the mean time we can use the alternate to push R use 
forward.

Henrik - what is the plan to get Carl's opinion on some of his known 
plans, e.g. layers. Shouldn't you know, how were those supposed to 
work, etc., before you do any other design decisions?

The fact that brian has completely taken over parts of the development 
of R3, should be a clue, that there are other areas where this is 
possible.


This is all just my two cents, but in the last year that I have been 
chatting with Carl and some of the people which have "taken responsibility" 
for some stuff in R3, the more Its obvious to me that Carl just wants 
the community to do more... to take up more responsibility.

Say you want to write a multiplatform gui app, well, then you make 
sure that what you do is supported.

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.

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.

Graham, keyboard strokes are lost, when the focal face is not set. 
The culprit is this function in event handling:

key: key-up: context [
	do-event: func [event /local win face] [
		if face: guie/focal-face [
			; bubble up if necessary
			until [
				event: do-style face 'on-key event
				not all [face: parent-face? face event? event]
			]
		]
	]
]


Ideas on how best to solve this? We want keyboard events always to 
be captured and responded to in the correct window regardless of 
focal-face.

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

Graham, active window being known: If Carl says yes, then I just 
need to know that. BUT: I'm presently needing to be sure the method 
would be correct for capturing key events everywhere. Currently it 
just looks like you can only do that for focal-face, which is not 
enough.

There are tons of questions and things to do around R3 but let's 
not fragment our time. Let us concentrate on it and get it done, 
than move on. All necessary side-effects that need to be fixed are 
in scope. All other things IMO not.

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.

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

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

should be simple to do. we worked out how yesterday.

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.

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

no, just 5 minutes of work to get rid of Carl's fancy colors, while 
we do various GUI testing.

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.

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

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

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.

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.

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.

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

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 ?

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

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.

cool to see, what even non-HW accelerated View can do.

do I need to set the event properties in some specific way?

Gabriele, that was my question too.  Currently If you have 'busy 
loop', no matter what technique you are using, you need to 'idle' 
at some point to give CPU some free time. Currently I don't know 
of a way how to do it in R3 as the CPU is getting high even on very 
long(in terms of CPU time) idle delays.

Cyphre - do you understand, what Max wants? And for us dumb - would 
it be a benefit, to have "draw elements"? :-)

AGG does a lot of computation, basically having access to this data 
in a consistent way.  also not having to use composed/reduced blocks 
all the time.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  

getting intersections between complex shapes like splines and polygons, 
xformed.
bounding boxes of things, calculated points of displayed letters.


if there where a unified method which just keeps the persistent data 
and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.

Once View sources are released (part of the next release hopefully), 
do you think you could make some example, to show what you mean?

...also not having to use composed/reduced blocks all the time.


If you had look at the concept demo I posted above there is no sigle 
forced compose or reduce(ofcourse except the possible internal native 
parser processing) applied on the DRAW block using this method.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  
getting intersections between complex shapes 
like splines and polygons, xformed.
bounding boxes of things, calculated 
points of displayed letters.


Agreed, being able te get calculated coordinates of bsplines was 
planned addition, though not yet implemented.

Not sure about the intersections. I think you would need to use external/third-party 
code for that.
Bounding boxes, yes that is/was also planned.

But these ale more like helper functions which doesn't need to have 
any 'draw elements' access. It's enough to provide whole/partial 
draw block to get proper results.


if there where a unified method which just keeps the persistent data...


The DRAW dialect block is the persistent data IMO. And you can build 
any other dialect/system over it.

Don't be fooled by the result you are seeing. The internal structure 
of the data is almost identical as described in the DRAW block but 
in different format.

All the calculations are done on-the-fly using diferent parts of 
the pipeline setup. For example:


coordinates(almost same as in DRAW definition)->curve_converter->trasformer->rasterizer->renderer


there is not any persistent storage between 'coordinates' and 'rasterize' 
phases (that would be memory overkill to store all the approximated 
curves etc.)..the result is directly rasterized on the fly.

So in fact there is no static 'list of vertices or whateve' of the 
resulted image, everything is dynamic from the time you pass your 
DRAW definition to the engine.


...and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.
 

See the concept demo. I'm using one single DRAW block for all the 
objects and I can access/manipulate them without any complex code. 
There are no limits.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.


ok, so show me example of the form you would like to use for drawing. 
Is there any existing system which uses your expected behaviour?

Max - try to define simple usage case, and possible syntax, so that 
Cyphre can see, how your aproach differs, because it seems to me, 
that with few enhancements Cyphre outlined above, Cyphre thinks current 
implementation can already do what you are asking for ...

yep  I agree, I just don't have the time to go in-depth.  too much 
stuff to do right now.

Steeve, but were you succesfull to use this technique in real world 
case? I tried to use it for the DRAW demo but it doesn't work well.

Try: do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes-2.r


-try to move mouse over the window..you should see quick 'MOVE'  
events  eing logged in the console

-if you select any object using the mouse the loop is starting to 
do something usefull and from that time I could get only about 3 
MOVE events per second which is very slow. To me it looks like the 
event port blocks during execution of the code inside the WAKE handler.

But if I use the same code inside FOREVER+WAIT cycle the events are 
comming much more frequently.

ofcourse if you want to do 100 smaller places on the screen then 
it is usually better to refresh whole screen ;)

Pekr, you can't use Rebol to "do " the script at this remote location 
 , you must download it at first.
(no redirection supported by http in R3)

It is still a very silly way to do what Cyphre is doing, more consistently, 
by just using a FOREVER loop with WAIT.

Henrik: Do you also tie validation and multiple data sources to each 
binding?  I kind of like the independence of a data model co-existing 
with a layout structure, you can poke and prod data from outside 
while the view internals just get on with what they do...

this doesn't have anything to do with those functions. :-) if you 
didn't have an actor to handle things like EMIT, you would have to 
write special db handling code up against GET-FACE and do a lot of 
silly wiring, like is necessary with VID.

next will be to return to ATTACH and see how we can do this as simply 
as possible without getting a "no" from Carl.

Do we count for so called "accelerator" keys? I mean - in Windows, 
you can see underscorred letters, which you can use as a keyboard 
accelerator keys. But I can also imagine other aproach, e.g. that 
pressing Alt will display small boxes displaying accelerator keys. 
E.g. Lotus Notes does so. If there will be layers introduced, it 
could be rather easy to have such visual markers (ditto for mouse-over 
help)

I noticed this under Experimental in face-reactors.r3:


signal: ["Send a signal to another face." id [word! integer!] who 
[word! none!]] [
	unless who [face: parent-face? face]
	do-style face 'on-signal id
]

Pekr, that might be possible to do. An interesting issue is how to 
write up accelerator keys in a simple way. I'm considering a small 
dialect: [alt ctrl d] or something.

If I need to communicate with the container, I usually just: do-style 
parent-face? face actor-name

Currently the form is bound to one record. Good question, btw. on 
new item. It's simple to do in principle, but I think it requires 
a clearly defined set of functions (reactors) for simple db operations:

I guess one wants these reactors (names not finalized):

emit - get data out of form to table. Done.
obtain - get data from table into form. Done.
next - next record
previous - previous record
first - first record
last - last record
new - new record
delete - delete record

I do remember how I disliked one simple draw block (one gob) to represent 
a style. IIRC BrianH said, that multiple gob styles are possible. 
Would that be a hack? Or is method already supported?

Ok Henrik, please do not forget a "record modified" trigger for the 
UI. In multiuser enviromnent it is really useful to know if the record 
has been modified by someone else.

Henrik - what was last status of resizing? Carl admitted, that resizing 
is broken. But I do remember some discussions about using different 
model to Carl's choosen one. And btw - is 'max-size requirement still 
there?

my VID ?, i do my own research on VID. I don't intend to use the 
standard one in my own apps, sorry for that.

I've been working on docs (a dialect for image annotation in docs, 
actually) for a program, so not much here. Some things are actually 
very difficult to do in DRAW. I could use a pure alpha overwrite 
mode. I've posted a report in the AGG group about a bug in TRANSLATE.


I might add something to specs, which I've been working with as part 
of writing docs: A way to use a layer to provide editing tools, i.e. 
box handles, rotate handles, swipe selections, moving and resizing, 
like you have in many graphics editors. I think this can be done 
in a generic way and would make it easy to build any kind of graphics 
or GUI editor.


This is not something that we want to add now, but it's nice to think 
into the design, so that it's simple to do later (and to remove, 
when Carl announces that he doesn't like it).

Pekr, do you find it understandable? Does it help you to understand 
how it could be extended?

accelerator key visibility is missing from spec. do you want to write 
something up, just to collect notes? I can clean it up later.

it's a pain every time you need an advanced widget to have to do 
it from scratch  you then spend alot of time  designing widgets instead 
of inputing fonctionalities to your software

maybe  this set of "advanced widgets" can be updated automatically 
through internet like rebgui was. IT depends in fact on how often 
do we plan to update the widget library  if its once or twice a year 
then it can be done through regular R3 release if it's more ofthen 
then we need a way to update the advanced library more often

yes, in 2 steps (not specific to Rebol).

Make a mask with your shape, then apply the mask on the second graphics 
(you can use 2 overlapping gobs to do so).

Don't know if it's possible to do the 2 steps in only one gob though.

in photoshop, its like using the eraser to remove parts of a layer 
and reveal the bg. 


 what you say, looks more like adding a layer with a hole in it.  
 Do I understand your idea properly?

is that more obvious?

Screenshots will be available when there is something to show. Worked 
out a few bugs regarding tab navigation yesterday and there is work 
being done on the basis for a grid system that will be used for tables, 
dropdowns, menus, etc. Someone has been added to the list of developers, 
as I don't have much time right now to do GUI work. He may speak 
up if he wants to. :-)

Is it by any chance planned to add HTML rendering to R3, maybe as 
an extension? (probably not but I'm going to ask anyhow because I'm 
horribly rude) There are some cool apps that mix native GUI widgets 
with HTML content, gitx for example. Would be neat to do this with 
Rebol too. And I'm sure, often enough an app you write is going to 
offer export as HTML, being able to show a preview of the output 
while you are editing the data adds a nice touch to an app.

dunno about HTML5 Canvas, but browsers contain SVG, and there were 
some attempts to do REBOL-2-SVG converters. There was some incompatibility 
in how gradients are specified, but that could be added to our kernel. 
I am sure Cyphre has more to say here ...

all those years i sharpen my own way  to code in rebol in a more 
professional way ... and that was done basing my self  on the few 
spare tools the rebolers bring  but it would be nice to have this 
effort through years continuated to show that the rought aspect of 
rebol evolved alot ans that now all you really need to do rebol is 
rebol and i think we all shown that in rebol light weight wasn't 
synonimous of  poor ideas oe small capabilities*

It would be really good to get Carl cooperating
 - yes it would be. And you probably know how to do it? ;)

I agree with the headache brought on by the pieces you mentioned, 
but how to get people to transition unless you make it easy for them 
to do so?

AdrianS: I don't think you can convert the Web people to Rebol easily 
just by replacing the JS in a browser. Better to build some 'cool' 
product based on Rebol with modular interface so people can play 
with it and build own 'gadgets' using dialects etc. I believe there 
are still some 'oportunities' to do it on misc embedded systems but 
first you need HostKit source and fully abstracted Rebol dll versions 
compiled for such systems.

when we'll have a webkit REBOL plugin, then I (and hopefull others) 
will be able to do a real-time web dev software using the remark 
framework.

Cyphre has a good idea on how to do this, and it probably involves 
an extra gob. As a side effect, it might be possible to define a 
bitmap mask to get pixel precision accuracy for click events.

You render all visible faces to a bitmap. Each face has different 
color. The you just read mouse coordinates and do a PICK on the bitmap. 
That way you know exactly where the event should end. That's the 
bitmap mask.

render - well, there are different ways to do it, you must ask Cyphre 
how exactly he's going to it.

What is most important is, that we haven't hit a showstopper yet. 
Even with the current release we can move along. It might not be 
perfect in all aspects but good enough and comparted to R2 base not 
worse. That's enough to do it and get some apps done with R3.

ah ok, that makes sense, but then you are limited in that each gob 
has to fit within a rectangular area, and do 2 checks.  first on 
the area then on the mask.

resizing: no, Carl does not like RebGUI resizing model, nor some 
look-alikes. Neither do I. That is why Cyphre and I had to try two 
distinct prototypes not being fully content with any of them (the 
second one being able to deliver some nice pictures already). Tomorrow, 
it is time to try yet another resizing model, this time adhering 
to Carl's original idea more, than his own implementation, so the 
system is going to be quite advanced (it took a lot of time to fine-tune 
some algorithm details, we almost gave up).

if you can reference strings from outside the GUI, that shouldn't 
be a problem to do on your own. I don't find it generally to be a 
good idea to provide language support inside a GUI engine.

But, are you saying, that you could get a picture like 216 being 
scaled so, that the two boxes in the middle do not change their sizes, 
while the first one and the last one do so, that the boxes remain 
next to each other all the time?

Well, Steeve, you do not have to use it, but it will be available 
in case it is needed

It's not proportional resizing ONLY, if you want your elements to 
stay whey they were, you're free to do so.

Cyphre ... do you know the answer to my question?

The only thing I can do right now is to point you to new GUI docs, 
maybe by reading the docs you will understand, how things are layered 
....

http://www.rebol.com/r3/docs/gui/gui.html

Sure, I was aware there are other things being worked on, but I was 
asking if the resizing functionality that was discussed earlier is 
specifically part of defining a "layout description dialect" (as 
mentioned in the docs), and, if this is so, do I understand correctly 
that if you want a new layout engine, than it is "just" this dialect 
that needs to be redifined.

Ok, but does this mean that a new "layout specification dialect" 
would not be able to redefine sizing? It seems that it should be 
able to do so as the sizing of GUI elements is intimately part of 
laying things out.

What do you mean by "redefine sizing"? You want to have the ability 
to redefine (whatever it means) sizing from within the layout = VID 
dialect?

If you want to do it right, resizing is a fundamental concept. That's 
why we take care that early. It will be used by all styles. Hence 
if you want to replace it, you have to touch the code. The GOB objects 
might look differently, the dialect needs adjustments etc. So, a 
lot of ripple-effects.

'Are you saying that you can vary the "layout specification dialect", 
but not have to have a resizing implementation that takes this changed 
layout engine into account?' - certainly, we can do whatever we like, 
especially create two different layout dialects using the same resizing 
implementation, if that is what we wish

surely you can, if you want to do that

The way that Java does it is unnecessary in R3GUI: For Java, they 
have to maintain an object hierarchy; REBOL doesn't need to do that, 
so even the layout managers are styles. The group and panel styles, 
for instance, are only layout managers and have no inherent appearance 
of their own.

cache are always a good thing for repetitive task if you draw use 
is to draw 1 square or 1 circle or 1 line of texte will you don't 
need a cache buuuuuuut

if you do  a document rendering like area-tc with alot of  time the 
same calls over and over again then you see the obvious optimisation 
brought by a cash

Graham, from what I remember from the old "host kit" (2007), i don't 
think you can do that, as you had to pass a function table to the 
dll.

As the interpreter is plain C is should be portable to different 
platforms very fast. That's something that Carl always needs to do. 
Than all the host-kit stuff (meaning the interfaces to the Rebol 
interpreter) need to be ported to the target platform.