AltME groups: search

It's important to lift the UI out of the domain of appearance and 
into the domain of meaning. When your UI intelligently finds the 
default window close button or the first field in a form automatically, 
and automatically assigns correct keyboard navigation shortcuts, 
because of the underlying architecture's emphasis on meaning, there's 
no need to write any code to handle that at all. It's just there. 
You build your styles to adhere to the meaning that was setup by 
the GUI system. In the VID extension kit, this is done through flags 
and powerful face handling features. You don't need to add any code 
for that in the dialect.

but VID R2 has some very serious platform limits which we can bypass... 
which is nice to be able to have access to in the next implementation 
of R3 View which is outside the core dll.

Ashley, my VID had examples of using caret for fields etc. I assume 
Carl's one too...

Weighting happens by "pushing" other elements aside, like soap bubbles 
pushing against eachother. The bigger the element is, the more it 
pushes. But space is also divided between the number of elements 
available in a given group, so a group of 5 buttons takes a little 
more space than a group of 3 buttons.


That gives the problem you see with strange spacing before and after 
the vertical scroller, because it's size is not big enough to provide 
push. and the other elements are too small to provide enough push. 
Combining the size of the face and the push factor is why resizing 
is broken.

But there are more bugs in it than that. If you push too much, the 
elements overflow and will be clipped by the right and bottom edges. 
Furthermore, the calculation of space to the right edge and bottom 
edge is also broken. It's almost impossible to predict in your head 
how the layout will look.


I'd like to replace the resize engine with something more concrete, 
perhaps with springs instead and fixed pixel sizes (oh, maybe similarly 
to what the VID Extension Kit does) or depending on whether Carl 
get's started again with his specs list (which I unfortunately can't 
locate). I hope we'll get to start this month.

Graham - shouldn't we better finish/fix Carl's VID, if that one is 
going to become official distro?

I was just curious to see how Gab's systemm worked .. and I tried 
%test.r but 

>> do %test.r
Script: "Test vid" Version: none Date: none
Script: "REBOL View System Functions" Version: none Date: none
Script: "rewrite-tree function" Version: none Date: none

Script: "Simple dialect to create/resize gobs" Version: none Date: 
none

Script: "REBOL VID 3: Definition of FACE prototype object" Version: 
none Date: n
one
Script: "REBOL VID 3: Functions" Version: none Date: none
Script: "REBOL VID 3: Events Handling" Version: none Date: none
Script: "REBOL VID 3: Styles" Version: none Date: none
** Script error: cannot MAKE/TO map! from: none!

** Where: make either make handler parse parse-set-dialect make-styles 
catch eit
her either applier do catch either either applier do
** Near: make map! style-spec/options

VID was confusing for all newbies .. clarity is essential

facets is also used in VID. it's an old term.

Well, to be honest, while Graham is imo right, that especially to 
novices, better wording could mean faster learning curve, I also 
have to say, that it is not the most important topic. Finishing VID 
is :-) I would like to see incorporated Carl's planned changes, and 
other subsystems being built-in (still not mechanisms for tabbing, 
accelerator keys display (can be done via layer), full keyboard navigaton 
etc.)

Aspect is also talked about in aspect ratio, which could become a 
function in R3, like it is in the VID Extension Kit.

No, not wrong attitude. Styles are built by experts, i.e. people 
separated from those that build layouts. In VID, you don't have this 
distinction as you can manipulate styles directly in the layout, 
but you do, somewhat, in RebGUI.

btw - what I liked about Gab's VID was gob dialect to build multigob 
composited styles ... but maybe Carl's VID does not need that ...

Pekr, Carl's VID uses a stack of identically sized GOBs that each 
perform separate tasks: Skin, text, debug. Each GOB stack makes one 
face. When designing a style, you never need to touch GOBs at all.

http://www.rebol.net/wiki/VID:_Face

Is that VID document I referenced still up to date?

Or does it refer to Gabriele's VID ?

last update Aug 2007 .. that was before Carl wrote VID+

Ashley, "just trying to understand why we still need the concept 
of faces under R3." - The role of faces in R3 are just what they 
were in R2, a collection of features and functions inside an object, 
but instead of the underlying View system being closed, they are 
now linked to a fixed set of GOBs, that we eventually can extend 
with all sorts of features. So:

R2:

Layout -> Face tree -> View

R3:

Layout -> Face tree -> GOBs -> View


Faces are what are generated by the layout. So the "face factory" 
is still needed and styles are the "molds" or prototypes. Within 
the face factory, the GOB factory exists. I would assume this separation 
makes HW acceleration or replacing GOBs with a different structure, 
much easier later. GOBs are redrawn using DRAW-FACE and that is handled 
inside the styles.


Styles use resources like fonts, colors, materials and standard draw 
blocks. This eventually helps skinning and abstracts these things 
away from the styles themselves.


The obscure FEEL object is replaced with a set of on-* actors that 
are run at specific times in specific sequences during runtime. They 
are more fine grained, so you can determine what you want to do, 
for example during various stages of face initialization.


The relationship between the layout dialect and faces is a bit different 
than under R2: you can't access the whole face in R3, only facets. 
For example the GOB itself, is not a facet and neither are internal 
states. So in order to change a deeper element of a style, you need 
to create a new style. This seems cumbersome, but is badly needed 
for large layouts, where we are semantically separating appearance 
from purpose. VID allowed this to be an organic mess. We may figure 
out a way to make creating derivative styles a bit easier.

Henrik: make-gob is "complete" in the sense that it has all the features 
that were necessary for VID. I'm not sure I'd call it "finished" 
though - for example I wanted to add hinting, and a number of things 
may need improvements. Also, maybe the code can be cleaned up.

We really need all of them. Badly. I use all of them in the VID Extension 
Kit.

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

There are a few changes in this, from the VID Extension Kit: All 
error generation is removed and replaced with NONEs. This was due 
to how VID is not pure enough a structure to work in. Consistency 
in the face tree for R3 GUI seems much better, but also because only 
a few styles exist and they all adhere to structure.

main line should be SAME VID SCRIPT PRODUCE SAME RESULT ANYWHERE 
!!

I'm starting to think that keeping a set of rules to parse for tags, 
may not be a great idea after all:

- Each rule is largely used only once.

- The rule list is quite short and there are not that many places 
to use rules.
- Building the parser is complex.

- The rule would have to be parsed on each invocation of a function 
which takes longer than simply searching for a tag. This would have 
to be done potentially hundreds or thousands of times on opening 
a single window and just consumes more memory.

- Setting and unsetting tags by using the rules as part of a state 
machine just leaves a new need for further processing the result 
where you use it, and perhaps slows it even more down, because you 
need a state machine engine to drive it.


The list of rules is good as a design guideline as I've used it for 
the VID Extension Kit, but no further than that. Tags are of course 
still needed.


I think I'll reduce today's prototype not to include rules, but simply 
manage tags directly.

hum you mean on the VID side no need to adapt the R3's script to 
any OSes. Yeah that's how it's promoted man ... REbol a unical VM 
of less  than 1Mo giving you the same thing avery where that's what 
the advertising said from the begining twelve years ago. And twelve 
years later we are still not there ...

I pretty like the idea of a more reactive VID made and maintained 
by the community   something with really open source that I could 
acces any time solve the bugs that's slows my  dev and share the 
patch i made. I'm better at finding solutions to existing problems 
than inventing new problems

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

and even VID 3.4 can be a school for people to get a first concrete 
access to what is in rebol and how things are done in it

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.

right now... what we are waiting to get R3 VID going as an open, 
steady, team effort, really is the next host release with VID implemented 
as an extension.

well, such claims sound very strange. One of the reasons why Carl 
forked GUI was, that he did not agree to some concepts. So it really 
surprises me, that you plan to continue to work on VID, without any 
coordination ... that once again asks for later fork. I think that 
for Carl to explain/document his ideas would not mean more than few 
hours of his work ...

Even if an official GUI is released tomorrow it will not be all things 
to all people and some will develop other gui's (rebgui, maxim's 
glass etc) why not start now as opposed to later. It need not be 
considered a folk of the offical vid...just an alternative choice. 
the official when released will be adopted if it works well enough 
so you won't be stepping on carl's toes.

Guys, remember that Carl WANTS help?  that means accepting ideas. 
 especially from like-minded people.

AFAIK, Henrik is closest to the source as to how Carl wants VID to 
evolve.  So if you (Henrik) want to put time and effort while the 
next host gets released, I say GO!  


Its time this community stops asking "what does Carl want" all the 
time.  He wants REBOL to be used.  he wants his last 15 years of 
life to mean something to more than himself.


Everything going into R3 is a direct response to what WE have been 
asking for the last decade.  He wants R3 to be what WE need, within 
a few guidelines we all agree to in the first place.


He wants REBOL to grow, and like a child that has grown... Some parts 
of REBOL will grow without him, others will grow with his counsel.

And I don't find my set-words I used in the VID spec block.

people are so used to R2 VID, that it's hard to get out of that thought 
process that the GUI must be completely hackable. :-)

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

No, you are right. There was one user who's name I forgot, something 
like Dr. Bacon, who tried to reorganise docs. Good intention, but 
he mixed VID and VID3.4 docs, and he thrown it also into pieces ....

as well as the R2 VID

Carl should imo write down notes about how he envisioned GUI 3.4 
to work, especially non finished things like events (still from Gab's 
VID), layers, guides, resizing, etc.

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

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

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?

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

Remember that Carl rewrote vid as he found Gab's vid too hard to 
use

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.

in my soon to be released application, the dataflow aspect of the 
code is less than 20% of the time spent, yet it represents at least 
80% of the actual usefull software capabilities.  


most of it was fixing View and VID themselves... the styles, the 
event mechanism and bugs, AGG bugs, enhancing http, etc.

Currenlty, i try a new way.

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

@ 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

The question is: How to get from GUI to a DB and back without cluttering 
the VID code, or having to code to much. The idea is to collect the 
GUI elements belonging to one record and than auto-create tables 
and columns. So, people can concentrate on the app code and get the 
75% always necessary database code for free.

so - it is supposed to be part of VID dialect?

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.

I just don't understand the purpose. Can you give me short VID level 
code idea?

I guess my bias is that the burden of what input goes where is on 
the data/application model. To give the UI that responsibility would 
seem unnecessarily complex (that's not to say it wouldn't be favourable 
to some applications, but this is core design, right?). I'd find 
it more useful to have the UI have an independent data model where 
I could extract some data to send one (or more) place, extract other 
data to save another, and so on.


I find that's what I miss when working with R2 VID, not so much that 
it doesn't bind to data sources...

there is also the case for displaying multiple records in one form. 
I've solved that in the VID Extension Kit, by providing an alternative 
form with fields that are disabled. clicking a checkmark enables 
the field and lets you set a value. when the value is set and you 
submit, the involved records have that value updated.

i try something like this in my VID, i have a scheme named animator 
(basically a collection of animations, plugable in styles)

What do you mean by "my VID"? :-)

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 use this to merge effects with existing draw blocks (it's called 
by the constructor of each animation).

It's up to you to merge the effects with inner gobs if the style 
got many.


The VID, I build, doesn't matter if the style contains several gobs.
Thanks to my propagation model of events.

I use the same idea than R2, events are propagated from inner gobs 
to outer gobs, so that i can have only one reactor on a parent gob 
(the container) which trigger the same actions on all its inner gobs.

It's the thing i don't like in the current VID and it's why styles 
can't deal easly with several children gobs to my mind.

I use this to merge effects with existing draw blocks (it's called 
by the constructor of each animation).

It's up to you to merge the effects with inner gobs if the style 
got many.


The VID, I build, doesn't matter if the style contains several gobs.
Thanks to my propagation model of events.

I use the same idea than R2, events are propagated from inner gobs 
to outer gobs, so that i can have only one reactor on a parent gob 
(the container) which trigger the same actions on all its inner gobs.

It's the thing i don't like in the current VID and it's why styles 
can't deal easly with several children gobs to my mind.

those things you mention (more styles) can be done even in recent 
VID state? Do you regard architecture being stable? E.g. - I remember 
you (and me too) did not like max-size. But it is basis of Carl's 
resizing model calculation. So no fear of later changes on your side?

Well, the keyboard navigation in the VID Extension Kit is a much 
bigger hack than in the R3 GUI. That's thanks to a good design and 
treating the window itself as a style. There are still some issues 
with Carl's method of tab navigation colliding with mine. Carl has 
a tendency to work functionality that should be generic into a few 
specific styles. I don't really get why he does that, because it 
scales like crap.

i liked pretty much the idea of an advanced high end side widget 
library like REBGUI . It evolved so much faster than View in  last 
years. and the result is nothing to deal with the rough aspect of 
the basic VID

Shadwolf - why don't you just read new VID3.4 docs? It is clear new 
VID does support creation of advanced styles, and IIRC Cyphre will 
do grid (table) widget for R3 ....

just a quick (yes/no) question wrt VIEW R3 (not VID) cause I've got 
no real R3/view experience:


can we draw graphics clipped within other arbitrarily shaped graphics?
like a box clipped to a circle or spline curve?

Pekr, from specs: "This might be a problem for VID, because we use 
only simple text for UI styles. Will we have to switch to rich-text 
instead, to fulfill the needs?" - it should not be a problem since 
all text in R3 GUI is rich text.

Well, it will allow Cyphre (or others) to work on View kernel. But 
as for VID, the work could continue in theory even without the above 
mentioned work?

As for VID, we probably need Carl's input too, to know what he has 
in mind for some concepts (layers for e.g.), but the hostkit is imo 
more important, so I think that we should not disturb him right now 
:-)

I just wish one thing - things to not add layers of complexity. The 
initial VID work was imo really nice, and I hope it will not complicate 
much ...

From rm-asset.com website - "# R3-GUI Library: Our internal extended 
and enhanced VID. We add a persistent layer so that GUI elements 
can be stored into a database backend. Further we added element-tree 
traversal code to simplify accessing GUI elements. Beside this we 
develop a bunch of GUI styles like TABLE, DROP-LIST, DROP-TREE etc." 


What's persistent state for GUI good for? And also - why the element 
traversal code, if we can use path in gobs and their "panes"?

We take VID34 AS-IS and patch the code-base. So it's easy to find 
the differences. Most things we try to add non-intrusive. So you 
load an additional file and get new functionality.


The styles are all "self-contained". If Carl wants it can all be 
integrated into VID.

I still don't like "we patch VID" attitude though. It is understandable, 
from your business POV, but it still sounds as a fork to me. It would 
be really good to get Carl cooperating, so that the work could be 
accepted for official VID distro, or there is a risk, we will end-up 
with two VIDs ... just my opinion ....

If Carl wants it can all be integrated into VID.
  is the most important aspect ... to prevent eventual fork ...

Well, can't wait to test something :-) Last active VID work happened 
2 years ago or so :-)

Max, yes, we can add different emitters. It would even be possible 
to generate HTML out of a VID form.

Hmm, as you posted here, guys should make some greetings demo using 
new VID :-)

building a layout dialect for Remark which is compatible to GLASS/VID 
3 is pretty easy.  its my next main Remark project.

exactly - it's there right now, as opposed to VID 3.4 which is only 
going to be fully available some time from now (in a more polished 
form)

A downside is that when you define the style, you also need to define 
a click area, to avoid getting a click registered on a space between 
two buttons.

  ..... I am not sure I can understan, how it is done. Is another gob 
  used to define click-area?. Carl reduced VID to one-style = one-gob, 
  and it was clear it can't work for more complex style, you had to 
  "switch" drawblocks anyway. Now if I understand it correctly, we 
  are back to kind of  "border" aspect of R2? 


I still liked maybe more complex but also more flexible way of Gab's 
VID, where one style was compound of more gobs, if needed ....

Good, because I've been waiting for the R3 GUI resizing model to 
be finalized before I retrofit the R2 VID resizing patch with its 
algorithm.

so it is a mixture of original Carl's VID model, plus some new alghoritms?

Mondrian indeed. :-)


What does the code look like to define sizing behavior, or is this 
still all low level and will be wrapped in VID++?

I hope it does not make VID code to look bad, and that most of the 
behaviour is kind of "hidden" ...

I think that it might be easier to replace whole VID with something 
different :-) .... or link Core to Qt, wxWidgets, or some other toolkit, 
replacing completly View  .....

Apart from the fact that I can't properly answer your question, my 
understanding is, that the team is working on all aspects of GUI, 
in following areas:


- low-level (in C) - new GUI is based mostly on AGG, some fixes and 
enhancements are going to be done. Carl, and Cyphre probably too, 
is also working on HostKit GUI isolation, so that the GUI can be 
fully open-sourced, becomes part of Host environment, and can be 
eventually replaced


- various GUI subsystems are being worked on - layout, resizing, 
keyboard navigation/tabbing/accelerator keys, skinning/themes/materials, 
GUI transition effects, etc.


- GUI styles - new VID is supposed to be released with some advanced 
styles, as e.g. tabs, grid, hopefully tree too, maybe a menu (dunno 
about that one) 


- some other things come to my mind - browser plugins, video codecs 
etc. - good times ahead once we are there, but first things first 
:-)

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?

What do you mean by "layout implementation"? The VID layout dialect?

Yes, the layout implementation is the code that is behind the function 
"layout" in a face, for example. See:

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


The dialect parsed by this code is specifically called "layout description 
dialect" in the docs. This is different, as I understand, than VID, 
is it not?

The way I understand it, VID is a superset of the layout description 
dialect. So, to reiterate, if there is such a thing as a "layut description 
dialect" and there could be more than one defined, how come you are 
saying that resizing of GUI elements managed by any number of layout 
implementations is independent of these implementations when, as 
I tried to describe above, the resizing that you should get for a 
GUI element should take into account the "bounds" set by a particular 
layout implementation.

VID is a superset
 - VID is a layout description dialect, no superset

Hmm, well words in VID that declare the GUI elements, button, text, 
for example, are not layout specific. If I were to change the layout 
dialect, would these not stay the same? Doesn't this mean that the 
VID is a superset of any layout dialect in that it includes words 
for defining layout and words for declaring GUI elements?

Hmm, well words in VID that declare the GUI elements, button, text, 
for example, are not layout specific. If I were to change the layout 
dialect, would these not stay the same? Doesn't this mean that the 
VID is a superset of any layout dialect in that it includes words 
for defining layout and words for declaring GUI elements?

 - no, this is REBOL, and you can define a totally different dialect 
 than VID, and such a dialect surely does not have to be a subset 
 of VID in any sense of the word

As I see it, your goal is actually different: you would like to have 
a VID-replacement dialect compatible with VID in properties you call 
"non layout specific". Yes, that is possible too, of course.

If we wanted to, I'm sure VID from R2 could be "emulated" in an R3 
VID face.

We are now going to replace VID resizing code with our version and 
adopt some styles to use it. Than some more tests and if all went 
good, we are soon back to style development.

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


220 to 225 shows the resize engine in use with globally set borders 
with quite good pixel accuracy. the border style should be possible 
to set globally according to cyphre in a similar way as in VID, of 
course without the artistic limitations of VID.

What is the plan towards low-level of GUI? I mean - we now have new 
model - host-kit. My understanding is, that Carl created only few 
API functions, to get it running. So - how long will it take for 
VID being able to work upon new host-kit architecture?

VID shouldn't be affected. The host-kit change with the low-level 
part: VID | VIew | Rebol Core | AGG | OS. We need to implement all 
DRAW commands yet.

From the API point-of-view, VID should not be affected, but - if 
you don't have all draw commands implemented yet, it can't work yet, 
no?

but there is 2 things differents ... you have the dialect draw wich 
gives access to the insertion of  drawn shapes into a VID face and 
AGG is the engine can then beanything
....

the thing is draw and so agg can be used on any widget  componing 
VID and that's a hugde constraint

what really sux with opengl are those  half assed IHM interface i 
know glut, x and w32 extension that allows the opengl rendering engine 
to recive user

events and then display  on screen in the particular area set for 
it.


Those interfaces are not 1% as fun as VID... Vid is total flexibility. 
we never did that in vid be you can imagine heavy animation using 
draw dialect on any kind

of preset styled face. I think carl tryed to show that with the animated 
sliding widget when you open a window in his R3 GUI demo.