AltME groups: search

It will seamleslly integrate to my Custom Gob Renderer so the same 
GLASS style will be able to render in any renderer for which a compatible 
style was built.   


this means the same layout and interface for a button will be useable 
in a normal AGG render up to a 3D game representation of that button, 
with no user code change.  just a swap in the skin being used.

Robert: here is a proposition for presenting View + VID + REBOL coding:


1) Show this code on a slide, explain briefly what it does and run 
it: 
REBOL []

view layout [
	code: area 300x200
	btn "Run" [view/new layout load code/text]
]


2) Enter some VID code in the textarea, click Run and listen to the 
"wow" in the audience ;-)

You can type, for example:

across
text "Name:" f: field
btn "Say" [alert join "Hello " f/text]

but one thing you need to highlight, is that for all of your needs 
(code, style, layout, server, client, templates, controls, localization, 
etc) you are using a single highly natural language.    This is the 
power of Dialects, (DSL). 


datatypes are also a great differentiator of REBOL... just run code 
and leave an HTML tag in the code, as-is... that is cool.  most languages 
require literal data to be assigned, but in rebol data IS an expression 
so as long as there are no syntax issues, you can just embed data 
within the code (for whatever reason you need it in source managing 
tools).

show that you also use the same language for creating style sheets, 
new controls, sending a VID layout over tcp, etc.  just showing how 
small the code snippets are is enough I guess.


Make a little parallel between the web nonsense, and the simplicity 
of doing the same thing in rebol. (5-7 different languages, vs one)

Sunanda... I've had my PC for 10 months, and I'm still not completely 
acustomed to the new keybord  :-(


some of the layout decisions are also quite dumb (like using half-size 
keys for the arrows... now how clueless can you be to think about 
that kind of nonsense?)

that's true of any layout engine.  if you look at pdf.. it actually 
doesnt include any text layout algorythms.. those must be built externally. 
 all pdf does is display vectors where you tell it to.

R2 doesn't have any rich text you can direct.  which means you have 
to do all of the layout work manually.  as long as we have sizing 
examination of rich text atoms, then we can tell it to position things 
like we want and measure the result in order to properly convert 
the data to other formats.

you must realize that the format  of a document (encoding of the 
layout) isn't directly  tied to its content.

as I said, we need to know the offsets... if you really want to use 
another layout engine, just wait for extensions to support image! 
and go crazy  :-)

Robert - I think not. Henrik named few fundamental changes Carl is 
after. You surely remember e.g. frames concept, which was later removed 
for e.g. IIRC, things like - better resizing, changes to layout engine, 
layers, etc. are planned. What is interesting is, that it would take 
imo max 1 week to implement them. So - dunno when Carl is back on 
GUI. As for me, I would not like him to jump from topic to topic, 
which happened today, as Carl is moving to website topic for few 
days. BUT! - I think he just needs break from heavy coding ...

I've been thinking of how to separate code from display and have 
come up with the following ideas http://rebol.wik.is/Cheyenne/Page_Title/HTML_dialect


Basically the idea is to create all the html, js, css beforehand, 
and then emit in a template.  When the parser runs through the layout 
block, it builds all the CSS and JS links.  Once it reaches the body, 
it recursively parses the div tags building and closing them.  In 
the same way html, head and body tags are built and closed.

the element id or divs are used to control the layout of the template

It looks like similar ideas are involved .. complete separation of 
layout from code

how can i define a common layout for my webpages? should i split 
the layout into header and footer and use include explicitely on 
each page?

i wish rebol/view was that good to replace the browser, but im typing 
this on a mac w ugly, aliased, miniature fonts and i can't even use 
the maximize button because it fucks up the screen size and layout...

This is both against the structure of Unix and modern Windows systems.


UNIX filesystem layout usage are not identical. Here are the Apache 
error log location in just 3 UNIX flavours (among dozens):

* RHEL / Red Hat / CentOS / Fedora Linux Apache error file location 
- /var/log/httpd/error_log

* Debian / Ubuntu Linux Apache error log file location - /var/log/apache2/error.log

* FreeBSD Apache error log file location - /var/log/httpd-error.log

and here are the possible locations of configuration file:
* /usr/local/etc/apache22/httpd.conf
* /etc/apache2/apache2.conf
* /etc/httpd/conf/httpd.conf


Notice how the file name changes too (both for the log and conf files). 
BTW, I personnally prefer the GoboLinux approach ;-).


One the Windows front, it is barely better. The registry database 
is fine for storing parameters (name/value couples), but not a REBOL 
dialect file. A common way is to store files created at runtime in 
%USER%/AppData/Local/<appname>/. Cheyenne stores all his files (including 
config file) either in the local folder or in %ALL_USERS%/Cheyenne/. 
Storing them in %USER% hierarchy should be better.


Taking into account every OS specificities (or oddities) is not always 
a good choice for a cross-platform product. I know that Cheyenne 
needs to be gentle with the OS best practices, so I am willing to 
improve it whenever it is possible, but without sacrificing the default 
behaviour (because that is the way I want it to work for me).


BTW, I am also willing to test the centralized logging approach, 
but it has to be a cross-platform solution. So an abstraction layer 
needs to be built with connectors for UNIX syslog daemon and Windows 
Event Logger (they are two types to support: pre-Vista system and 
new Vista/7 one). Has anyone already worked on such wrappers with 
REBOL?


I personnaly need that the log files be exactly in the same format 
and if possible at the same place across platforms to make my life 
easier, so this will keep being the default anyway. The current -f 
internal Cheyenne command line (Windows specific currently) could 
be extended to work on UNIX too (and no Max, this one cannot go into 
the config file, because it indicates where the config file is located 
;-)).

cyphre... use this as a basis:


view layout [box 200x200 effect [
    draw [
        push [
            translate 119x119 
            pen none 
            fill-pen black 
            box -50x-30 50x50 
            fill-pen blue 
            pen red 
            line-width 3 
            circle 50x50 25 
            fill-pen red 
            pen blue 
            circle -50x50 25 
            fill-pen blue 
            pen red 
            circle -50x-30 25 
            fill-pen red 
            pen blue 
            circle 50x-30 25
        ]
    ]
]]


adding new black, red, blue, black, circles in betwen colors may 
give very poor results.  sometimes 1 pixel width lines practically 
disapear horizontally!


playing around with the line width will also have a different visual 
impact, since the aliasing will spread the error more or less.


as I said, i know part of the issue is related to the screen's rgb 
sub-pixel channel components but I remember trying some of this in 
other softwares and the effects weren't as image degrading.


to me the main defect is that you will notice a WHITE ringing effect 
between the red and blue on one side and a black ring on the other.


I can understand the black ring, but can't explain the white one, 
which is why I think it coule be related to gamma issues.


also, the black ring seems to be wider than it should &  the effect 
seems the most apparent at ODD line widths, which is a bit strange 
too...


I'm wondering if AGG has an algorithm which is trying to compensate 
for pixel to pixel color defects and gets it wrong.  


maybe it could be enhanced to support subpixel aliasing (or gets 
it wrong if it already does so).

Yeah, already tried with IE8. I got the same behavior, plus layout 
bugs in the file upload submit button.

Layout bugs with IE: known issue, need to curecode it to not forget 
it again.

BTW: I'm going to redo the diagram using yworks yEd editor. It's 
a fantastic graph layout editor and now supports swimlane diagrams.

noob question ....  how can I define a function that accesses a field 
before the layout is created?

I used to use 

l: layout [ f: field ]

and then write my function access f after the layout was created.

Now we have 

view [ layout block ]
...

glayout already implements 90% of what we want to build for VID 3.4, 
down to the dynamic layout engine, which is just about the same.

no we can't. the layout engine depends on it for weighting elements 
at their "correct" sizes. the resize engine must be fixed in order 
to fix layout.

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.

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.

OK, a meta-gob to recreate R2 functionality (given that a gob! can 
only do one thing)? I understand why layout was a "face factory" 
under V2, just thought we'd naturally move to a "gob! factory" approach 
with R3. I'm not being critical, just trying to understand why we 
still need the concept of faces under R3.

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.

Yes, it should not be there. There are many subsections: Styles, 
layout, View, Text, DRAW, etc. We may face hundreds of reports on 
styles alone.

The currently used words for styles:

name:    ; WORD!   - style's name (identifies the style)

facets:  ; OBJECT! - the modifyable attributes of the style (properties)

draw:    ; BLOCK!  - draw block with facet words (from face and style)

actors:  ; MAP!    - face actor functions (e.g. on-click, on-resize)
options: ; OBJECT! - prototype of face/options object
parent:  ; WORD!   - parent style (if specified)

state:   ; BLOCK!  - prototype of (extensions to) face/state object
content: ; BLOCK!  - panel layout for composite styles

faced:  ; OBJECT! - prototype of face/facets (face instance facets)
about: "Not documented."

These are the words for a face instance:

style:   ; WORD!   - name of the style for this face

facets:  ; OBJECT! - properties unique to this face (from style/faced)
state:   ; OBJECT! - state variables (not properties)
gob:     ; GOB!    - graphical object(s) for this face
options: ; OBJECT! - optional facet changes as specified

; NOTE: optionally extended in face creation with:
;name    ; WORD!   - reference name
;reactors; BLOCK!  - block of user actions

; PANEL faces also add:
;grid    ; OBJECT! - layout parameters and limits
;faces   ; BLOCK!  - faces of the panel:
;triggers; BLOCK!  - triggers used by panels

you can access them freely from other faces in the layout.

You're too generous. The GUI is pre-alpha, and wouldn't be considered 
alpha without the layout model changes Carl has said he has planned 
(but then had to take a break to work on lower-level stuff for a 
year).

A frozen face does not respond to input, but is otherwise normally 
visible. A disabled face is visibly disabled. Frozen faces may not 
be necessary, but they are a first step toward creating a GUI layout 
editor.

Either blocks in FACE/FACES or FACE/FACES doesn't exist. Some parts 
of a face is built dynamically as the layout is made, so if the part 
is not needed, it's not there. Yay for the ability to extend objects, 
I guess. :-)

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?

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?

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.

Robert and I are discussing field persistence, i.e. tieing fields 
directly to database tables in a layout. Going to be a bit about 
our conclusions in the R3 GUI specs soon.

The way that accessors on panels work in R2 is a good start (almost):

	>> lay: layout [pan: panel [foo: field "Foo" bar: field "Bar"]]
	>> set-face pan ["Bar" "Foo"]
	>> get-face foo
	== "Bar"
	>> get-face pan
	== [foo: "Foobar" bar: "Barfoo"]

Tie that to validation, eg:

	import get-face pan [foo: string! [some char] bar: opt string!]

Or an active record:

	record/update get-face pan

Not perfect as is, and perhaps simplistic, but I could imagine finding 
a way to add more semantic hooks to a layout and have a somewhat 
automated way to set/retrieve data from parts or all of the gui...

Especially recognising that the layout structure may not represent 
the application data structures.  I've toyed with the idea of a 'ref 
keyword - ui: layout [field ref 'user/name] - ui/get 'user/name, 
ui/set 'user/name, ui/get 'user == [name ...]

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

Something more to consider...

dynamic: group 1 [field field field] record [table1]


For when you want to set up fields where you know the order, and 
really want to minimize the layout code.


The outer panel would be set up with an ON-EMIT actor that traverses 
the inner faces. We already have this in the prototype, so maybe 
we can map the traverse order to the table columns.

We'll be building another prototype. The current one works against 
SQLite, but the next one should be built so that we can demonstrate 
that the layout shouldn't care about which db it's connected to, 
so we'll also make a flat file database version.

no, the point is that this will be part of the main layout dialect, 
so it's important to consider now.

this really is about as minimal as it can get with the layout dialect. 
validation would be another reactor.

And if possible, the top-level layout object...

Chris, the top level layout object is the window and it should be 
possible to get that too, but by using GET-PANEL directly. GET-FACE 
on the WINDOW style returns a value that would be stored by clicking 
an ok or cancel button in the window.

Looking at reactors now, this seems to be the way to store these 
emit functions. Reactors are more powerful than I thought and according 
to docs, under the place Graham links to above, we can write our 
own. The MAKE-REACTOR function doesn't exist though, it's called 
MAKE-FACE-ACTIONS.


I hope to make use of triggers as well. Triggers are faces that are 
not stored in the layout after they have been processed. They are 
performed either when entering a panel during layour or when exiting 
it (possibly also other places). I hope that triggers can be used 
to pass specific options to already laid out faces, making triggers 
appear as options to a face.

P: Validation ('import) and Active Record (RoughCut) are essential 
components of QM.  Validation (along the lines of 'import) could 
easily be part of a panel/layout's specification...

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

http://rebol.hmkdesign.dk/files/r3/gui/212.png- this is a layout 
using a PANEL style, elements are layed vertically, (in columns), 
center-aligned, having different (randomly adjusted) sizes

We're afraid because we've see some of these before, and they didn't 
turn out well. Specification dialects that don't require much specification 
and are easy to understand, make and maintain are preferred. If you 
were able to show us some layout dialect source with the resize specification 
markup, it would help a lot.

214 - vertical layout, in which all elements happen to have the same 
transversal size

216 is a more special layout in respect to resizing. It is defined 
so, that it can be resized only horizontally, and only the first 
and the last element are allowed to change their sizes when being 
resized. (that is something you cannot define in RebGUI as far as 
I know, neither it was possible in Carl's resizing algorithm, afaik)

yes, but I was asking, whether that layout was possible, expressing 
the opinion it was not, but I may be wrong, of course

Steeve, that would defeat the purpose of buying a large screen so 
you can see more stuff. Used a spreadsheet lately? Graham, that can 
change the whole layout. If it autoadjusts, cool, but you'd at least 
need different layouts for languages that go in different directions.

Hello guys, just few notes from my side regarding the layout sematics 
and min/max-size etc:
-the layout will be still as simple as in the current R3GUI

-most of the time only 'style maker' will need to handle min/max/init 
size of the specific style

-by default layout elements have to be organized either in PANEL 
or GROUP structures (though it is possible create your super special 
style for circular layouts or whatever ;))

-at the PANEL/GROUP layout level there will be only three kinds of 
elements:
1) style with absolute size (in any axis)
2) style with elastic size (in any axis)

3) optional RETURN keyword used for line breaking to create variable 
number of rows/cols(default ehaviour is to set fixed number of cols/rows 
for GROUP/PANEL)

-to achieve more complex layout user can redefine min/max sizes according 
his needs

Pekr: the MAX-SIZE is optional. That means it depends on designer 
of the UI element/layout if/how use that.

Cyphre, is the layout framework pluggable in any way? Could it be 
replaced with a different model? I'm just thinking how layouts are 
done in Java where there are quite a few different layout managers 
available and one size doesn't have to fit all. Here are some options:


http://leepoint.net/notes-java/GUI/layouts/90independent-managers.html

I am not sure I understand what you mean :-) GUI elements in our 
case are not something which is easily encapsulated in its source 
code and hence can be used with different engine, at least I think. 
But maybe I just don't sufficiently undersand, what "layout manager" 
means, so I will let the question to be answered by others ...

Does the declaration of REBOL GUI elements need to be so different 
from how other toolkits handle them? It just seems that needing to 
have only one way (one layout engine) of laying things out is a lot 
to ask of both the layout framework designers and the users of that 
layout engine.

It seems from reading:

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


that you might be able to define a new "layout" function implementing 
a different layout description dialect to achieve a new layout. Am 
I understanding it correctly? Is this layout description dialect 
specifically what the gang is working on?

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

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.

'I was asking if the resizing functionality that was discussed earlier 
is specifically part of defining a "layout description dialect"' 
- actually not, the resizing functionality affects the functionality 
at a lower level, the "layout specification dialect" is a layer above 
that

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?

I would think that a GUI element's size is relative to the layout 
model defined by a particular layout implementation - that is, GUI 
elements that are being managed by a grid/table-like layout manager 
would resize differently than those being laid out by a layout implementation 
that "flows" it's managed elements or fixes their positions to absolute 
coordinates.

It's not the idea that resizing is separate from the layout implementation 
that I'm wondering about, it's that the layout implementation is 
swappable. My assertion earlier, that resizing is intimately tied 
to a particular layout implementation, still stands, though. 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?

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?

My assertion earlier, that resizing is intimately tied to a particular 
layout implementation, still stands, though.

 - you can assert whatever you like, but it is beyond my understanding 
 why. Certainly, a layout dialect implementation may be "tied to" 
 a particular resizing method, since for different methods you may 
 need different data structures, so what? You can always use different 
 resizing, and if the respective layout dialect is not able to specify 
 all options the resizing algorithm offers (quite unlikely), you are 
 free to change the dialect.

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.

'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

yes, this is what I'm getting at - if I were to define a new layout 
dialect could I re-use/take advantage of the code that is already 
written behind the parsing and behaviour of those elements that are 
not layout specific

AdrianS, I've worked with Swing and know what you are talking about. 
The equivalent to a Java swappable layout model in the R3 GUI (when 
last I worked on it) is a group style. The "group" and "panel" styles 
are two such grouping styles. More group styles and other composite 
styles can be added. What you request is built into the model already.

Brian, what you're saying though is that a containing GUI element 
is responsible for the layout of it's children as opposed to delegating 
that functionality to a layout manager. In Java, each GUI component 
that can be a parent can have a different layout manager added to 
it,but it doesn't manage the layout itself.

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.

You can create your own layout manager styles with little difficulty. 
Or you can create container styles that layout their children in 
a specific way for a specific purpose, like a scroller pane with 
scrollbars. You don't need separate layout manager functionality 
since laying out stuff in a custom way is an inherent feature.

AdrianS: as I said in my last message here, "-by default layout elements 
have to be organized either in PANEL or GROUP structures (though 
it is possible create your super special style for circular layouts 
or whatever ;))"

By this I meant there will be two default 'layout generator' styles 
GROUP and PANEL but you can create own styles that will generate 
their content differently.

I suppose I just had the expectation that REBOL styles would only 
concern themselves with look and behaviour (group acting as a tab 
group, for example) and that layout would be handled by other types 
of constructs in the dialect, the way I'm used to. As for needing 
hierarchies in Java, these are there in the GUI component declaration 
to match the visual hierarchical arrangement and to make control 
of child visibility, event passing  and layout match what you would 
expect to see coming from such a visual arrangement. If similar control 
can be achieved by REBOL in a different way, so be it.

base-url: http://rebol.hmkdesign.dk/files/r3/gui/
img-url: func [id] [rejoin [base-url id %.png]]
ids: [%220 %221 %222 %223 %224 %225]
imgs: copy []
foreach id ids [repend imgs [id load read/binary img-url id]]
cur-id: first ids
show-next-image: does [
    cur-id: select join ids first ids cur-id
    set-face f-img imgs/:cur-id
]
view layout [
    f-img: image (imgs/:cur-id)
    btn "Next" [show-next-image]
]

Max - it is just a structure, which was reshapen, and the page was 
also de-stylled. The layout, styling and gfx of the new site is not 
done yet, as well as front page segmentation for particular target 
groups interests ...

The pricniple behind VID - simple dialected GUI layouts - is REBOL's 
strength. The actual implementation would not be as much of a strength 
on a memory-constrained system with a native GUI toolkit and strict 
UI design rules. However, you can make a simple cross-platform layout 
dialect for phone UIs that tells the native toolkit what to do, and 
then make platform-specific implementations for the various native 
toolkits. Dialecting is REBOL's greatest strength.

a lot of VID's dialect can be used to describe the layout even on 
native GUI toolkits.

Exactly! You would need to redo your layout anyways for the small 
screen (unless the layout dialect is *really* properly strict about 
not allowing sizes, offsets and real colors in its layouts, the way 
the R3 GUI is supposed to be), but the layout dialect itself could 
be very compatible and you could reuse a lot of code.

They where coding at opposite ends of the spectrum, now they are 
fighting to merge the two together.  that's how I read it.


IMO its just a question of getting it to work again. with new contexts 
layout and new, better module functionality.

The module system has grown to include many advanced features, which 
are all usefull and viable.  Brian has been working to simplify the 
code by breaking it up into smaller pieces.   At some point you can't 
have features without at least a minimal amount of code.


The new contexts layout makes it a more complex task because my guess 
is that basically, its broken everywhere and that is hard to debug.


The original module system wasn't very powerfull in the sense that 
it didn't add much more than special objects... what Brian is doing 
is sooooo much more than that.

13-Sep-2006 Anton Rolls

WAIT without also waiting for events:

view layout [
	button "wait 2" [
		remove find system/ports/wait-list system/view/event-port 
		
		wait 2 ; wait two seconds
		
		insert system/ports/wait-list system/view/event-port
	]
]

The module model is stable for now, and has no current errors in 
the mezzanine code, though OSX has some errors in RESOLVE. When tasks 
are supported better there will need to be some minor underlying 
changes, but not many because the module system was written with 
the proposed multitasking model in mind. The module list hasn't been 
locked down from a security standpoint, though its layout was designed 
with that in mind. There are still bugs and missing features in the 
(UN)PROTECT functions that are blocking the locking down of R3, so 
don't run untrusted code yet.

If that were the case, the 'layout would fail ...

When are the paths in the layout evaluated? The only part I don't 
know is the View part.

In that error there are only 3 path roots that could be none: db, 
db/:counter and FN. If the db is empty then db/:counter would be 
invalid even in the layout. That leaves FN.

If ''layout completes, then FN will be a VID field object