AltME groups: search

This is where persistent data structures come in. Based on the work 
of Phil Bagwell, Rich Hickey described how he used bit partitioned 
hash tries to make efficient "copies" of data structures, and this 
forms the basis of data storage within Clojure. Essentially all data 
is stored in a tree and when one makes a copy with a small change, 
one can create a tree with a new root and only the path to the changed 
item needs to be copied and modified. The rest of the tree's branches 
remain precisely the same. This significantly reduces the amount 
of copying that is required and makes multiple "versions" of a data 
structure entirely practical.

Anyone have an example of how the drop-tree works?  This brings up 
a drop tree but can't figure out how it is supposed to work yet


display "drop tree test" [ drop-tree data [ "root" [ "item1" [ 1 
2 3 ] "item2" [ 4 5 6 ] "item3" [ 7 8 9 ] ]] [ pri
nt face/text ] box 40x60 ] do-events

Gregg: drop-tree works like a menu system.

display "drop tree test" [
	drop-tree data [
		"root" [
			"item1" [ item-1-action-code]
			"item2" [ item-2-action-code]
			"item3" [ ]
		 ][root-action-code]
	]
]

That's it.

Further: http://trac.geekisp.com/rebgui/wiki/WidgetList#drop-tree

problems with tooltips

 ... note that since 11-Mar these and other problems have been solved 
 in the latest RebGUI Beta 2 builds.

Isn't Ashley making a Chat widget?

 ... chat, icon (SVG) and a simple tree widget (suitable for request-dir) 
 are in development.

RTF Style ... possible to use it in Rebgui

 ... RebGUI had this initially, but it was more trouble than it was 
 worth IMHO as (a year and a half ago) TMD (Text Markup Dialect) was 
 going to make it redundant. I believe R3 includes rich-text support.

http: ...

 ... I based my %render-rich-text2.r on this code but improved upon 
 it dramatically as we (shadwolf and I) were trying to use it to render 
 MD2 and MDP documents. Remember all the MDViewer and MDP-VIewer stuff 
 that was floating around a while back? ;)

Ashley - Cyphre was supposed to strip tree vidget from drop-tree 
IIRC. Dunno the status ...

IIRC I saw some tree stuff. But didn't tested it yet. But will need 
it soon.

you will find it in the RebGUI directory on xpeers

 ... got it the first time, just making sure I was looking at the 
 most current version. FYI, tooltips had me baffled for a long time 
 (they worked for you, consumed tons of CPU for me) until I realized 
 they were only a problem with the new tab-panel implementation ... 
 which now stores all tabs in a pane and uses the show? attribute 
 to work out which one is visible or not (the original stored hidden 
 tabs in a data block). The fix was simple, change the tooltip code 
 to ignore faces with show?: false.

strip tree widget from drop-tree

 ... the tree widget I'm working on is similar to text-list but with 
 leading triangles (indented by level) that toggle between sideways 
 (close leaf) and down (open leaf). Not sure whether Cyphre's one 
 is based on the same [simple] concept.

Can we somehow align while you do RebGUI 2?

 ... as discussed previously (see post from 10-Mar), with the key 
 points being:


 1) Use (and possible extension) of global UI settings (colors, sizes, 
 effects, behaviors) in %rebgui-ctx.r

 2) Widgets should define a 'rebind func if they need to change a 
 statically bound UI setting (e.g. color)
	3) Use the new tab-panel widget

and a fourth:


 4) Layout uses 'tip (not 'tooltip) to specify the widget's tip string!


Note that the current build has had most widget-specific exceptions 
removed, especially from %rebgui-edit.r; and that /dialog (hence 
popup) code has been rewritten to support true modal dialogs (that 
can in turn call additional modal dialogs). The later improvements 
are courtesy of recent REBOL/VIew popup changes.

As RebGUI is aproaching 1.0 release, I would like to know your opinion 
on following - how do you construct and optimise your GUI? So far, 
if you look at tour.r, it reminds me of one big dialog configuration 
box. Not sure what to do about it, maybe it is a given, as widgets 
we have do suggest such layouting. This debate could open discussion 
about eventual addition of potentially missing widgets. My questions 
are:


- are you missing kind of MDI application scheme? Parent window, 
containing one or more child windows, which are not able to being 
moved away from its parent. We used that design much, but I am not 
sure anymore it is vital, as with latest system, we use two monitor 
set-up, and by simple accelerator key we can navigate window being 
moved between displays. Having MDI available, we would probably need 
rebol/view native windowing system. So - is anyone missing something 
like that?


- do you somehow optimise your display? Isn't it like following? 
- with using tabs, everything is in memory, whereas it eventually 
is not needed? How do you divide your application, if you would like 
to have kind of load-on-demand aproach?


What styles do we miss, to further help us have more complete GUIs? 
I created screenshot of potentially two usefull widgets:

http://www.xidys.com/widget-drop-tab.jpg
http://www.xidys.com/widget-vertical-tab.jpg


Especially with the second one, I think it could be usefull. It is 
used by many applications. It is kind of mixture of tab and tree, 
but not necessarily with multi-level aproach, just one level of nesting, 
mostly represented by icons, text, or icons plus text. I would like 
to know your opinion.

drop-tree ?

yes, its in drop-tree

chart, 
drop-tree, 
grid & 
input-grid need a bit of work to get 
them working again with Beta 2.

chart, 
drop-tree, 
grid & 
input-grid need a bit of work to get 
them working again with Beta 2.

I wonder if chat widget etc. are more important than e.g. tree :-)

It's more efficient for Cyphre to fix his drop-tree widget

Is the tree widget review part of the equation?

A simple tree widget, suitable for request-dir, is in development.


I hope that R3 splits VID off as an optional dialect (much like the 
SDK already does), leaving View as the raw graphics engine to which 
many domain specific dialects can be written (e.g. an animation dialect, 
a gaming dialect, an HTML dialect, etc).


I'm hoping R3 introduces at least these View changes at a minimum:

	Rich Text Support

 Different face types (e.g. min-face, text-face, draw-face, image-face, 
 etc)

 Fixes the long-standing detect face bug (or defines the current behaviour 
 as being correct)

I wonder what does it mean "simple" tree widget :-) it will not be 
full-blown tree? Will automatic scroll bars, hilite, keyboard navigation 
as in OS? I will ask Cyphre if he was successfull in extracting tree 
widget from drop-tree ...

A tree widget is not necessary for me but would be nice

Yesterday I saw interesting widget - kind of tree combined with list-view. 
You simply had tree-view as basic view, but when you uncollapsed 
the node, list-view (table) appeared ... interesting - It allowed 
to logically nest into subcategories, e.g. company, orders, companies 
- list of orders in table style ...

it is a pity Cyphre is busy. I asked him to adapt grid, and he also 
promissed to extract tree out from drop-tree. But otoh I am glad 
he works on some parts of View for R3 :-)

Robert - any other widgets with your branch of RebCode? E.g. tree-view?

Yes, we have a tree-view as well.

sounds interesting .... tree-view is handy sometimes.

is there also tree-view part of Robert's submissions? I could need 
one in few weeks :-)

There is already a working tree

Uploaded build#107 with new tree widget:

USAGE:
	tree data ["Pets" ["Cat" "Dog"] "Numbers" [1 2 3]]

DESCRIPTION:
	Values arranged in a collapsible hierarchy.

OPTIONS:
	'expand starts with all nodes expanded


It's very basic, can only handle a couple hundred entries, and still 
has some UI quirks ... but it works and is only 3Kb.

Uploaded build#108.

1) Fixed UI quirks with tree widget

2) Renamed vid widget to style

3) Added a new scroll-panel widget

	USAGE:
		scroll-panel data [calendar]
		scroll-panel data [field field]

	DESCRIPTION:
		A panel used to group widgets within a scrollable container.

4) Added a new sheet widget

	USAGE:
		sheet
		sheet options [size 3x3 width 2]
		sheet data [A1 1 A2 2 A3 "=A1 + A2"]

	DESCRIPTION:

  Simple spreadsheet, based on rebocalc.r, with formulas calculated 
  left to right, top to bottom.

  A cell is either a scalar value, string, or a formula starting with 
  "=".

  Scalar values are automatically right-justified, series values left-justified.

  Remember to put spaces between each item in a formula and use () 
  where needed.

	OPTIONS:
		'size specifies number of columns and rows
		'width specifies cell width in relation to cell height


5) Updated %tour.r to incorporate examples of tree (List), scroll-panel 
(Grouping) and sheet (List) usage.

Enjoy!

hehe, so cool. Will imediatelly find usage for tree-view. Now the 
grid and we have cool data manipulation capabilities .... :-)

Ashley, I read that request-dir uses the new tree-view, but when 
I tried it out on a few checkout, and clicked on the "Home" button, 
rebgui froze on me. Reproducibly.

Just wondering if the tree might return more information than just 
the face text. Say you want to retrieve stuff from a database but 
only want to do so if it is a level below a node.  At present you 
don't know if you're at a node of a leaf.

Similar sorts of problems occur if you want users to be able to add 
to the tree.

Ahsley, did you took a look at my TREE widget? It's quite matured, 
so why reinvet the wheel?

Robert, can you post a screenshot of your tree widget.  Remember 
there's also the drop-tree widget too.

Robert, yes. Your tree-view widget is a superset of what I need / 
want (and is 21Kb vs my 3Kb).


Ideally, I'd like every widget to be 5kb or under, with 10kb a max. 
After developing and merging over 40 widgets I've come to the following 
conclusions:

1) 90% of the basic usage cases can be coded in under 5kb
2) Double the code size to increase this to 95%
3) Quadruple this size to get it to 99%

4) Time required to maintain / fix and document a widget increases 
exponentially as code size increases

5) A widget that tries to do many things is no longer a widget ... 
it is an app (list-view and grid fall into this category)

6) While developing the sheet and tree widgets I came to the realization 
that the scroller logic could be externalized in another widget (scroll-panel) 
thus removing much of the duplicated scroller handing code found 
in a number of widgets


Where does this leave grid? Near as I can figure it's a combination 
of table and sheet, but supporting cell types other than plain old 
field. I can see how folks want to pull data from a DB and put it 
into a grid, so does that mean we have 'typed' columns or can every 
cell be different. If the later, then aren't we just talking about 
a sheet with support for more datatypes?


And now for the accessors. We obviously want functions to load and 
save data, put and get cells, and add / delete rows; but do we really 
need functions to move columns around? Or hide and reveal columns? 
It's very easy (and tempting) to over-engineer ... but keeping things 
as simple as possible (but no simpler) makes for a stable system 
that is easily fixed, extended, maintained and documented.

I see your point and I totally agree. On the other hand doing a real-life 
full-fledged application requires most of the time more than just 
a basic widget.


What I found out is, that most simple widgets are ok from a GUI POV 
but not in these areas:
- storing / saving widget state and user-data

- be programmatically controlable (like setting a tree to a specific 
state, hiding stuff, setting sort-oder etc.)

- implement always returning usage patterns in a more programmer 
convinient way

- using a common approach for specification (nested blocks, key/value 
pairs etc.)

Uploaded build#110.

1) Improved scroll-panel and tree widgets


2) Replaced request-dir with a simpler tree-based version (WARNING: 
it reads the entire tree from the path given so don't use it to browse 
a root directory)


3) Added a new heading widget (basically text at twice the font size)


4) Added prototype of new RebDOC app (still needs to be generalized, 
and the code / data that drives it still needs to be cleaned up a 
bit - but it shows the direction I'm heading with regards to "self-documenting" 
apps / code)


5) Removed a number of unmaintained widgets (due to growing incompatibilities)

This is a philosophical dispute ... but there is nothing to stop 
Robert uploading his tree widget etc under another name to the svn, 
and we can optionally choose to use it.

the request-dir function has lost the "home" button so there's no 
way of backing upwards in  a directory tree.

was it deliberate decision to remove the functions tab from tour.r

 Yes, RebDOC now covers the same ground. My goal is to pull the content 
 across from %tour.r into RebDOC and then obsolete it (%tour.r that 
 is). In RebDOC the examples will become stand-alone scripts.

RebGUI Core

 ... I like it, and it means we can distinguish general RebGUI app 
 issues from RebGUI Core issues (e.g. keyboard navigation is a core 
 issue, lack of a domain specific "bells & whistle" widget a RebGUI 
 app issue). For me the line is quite simple: if it is an issue that 
 can be fixed by creating a new widget (either from scratch or based 
 on an existing one) then it is probably an app issue; if it is an 
 issue that effects most if not all widgets and / or the fix is to 
 the RebGUI engine itself (e.g. a %rebgui-* script) then it is probably 
 a core issue.

request-dir function has lost the 

home" button" ... yep. The old request-dir function was dynamic and 
only read dirs as needed. The new one, due to the "static" nature 
of tree, pre-reads all dirs. It's also lost the "make dir" button. 
These features maybe important to us as developers, but if users 
need to navigate the entire file system or create dirs to use an 
app then the native request-file is probably a better choice. The 
[new] request-dir is really intended for the simple "which of these 
directories or sub-directories do you want to use" case, and assumes 
the developer will use the /path refinement to start in the relevant 
directory. These changes were requested by one of my clients who 
didn't want their staff "seeing stuff they shouldn't and creating 
directories everywhere".

neat scroll-panel now means I can have enormously wide tab-panels

 ... I had that in mind when I created it! Note that the horizontal 
 and vertical sliders only appear as needed and the space they occupy 
 is given back to the child widget. Also note that the button on the 
 extreme bottom right of scroll-panel toggles between "home" and "end".

Ashley - will sheet and tree-view support at least keyboard basics?

What color does it use for borders?
 ... none, it's transparent.

will sheet and tree-view support at least keyboard basics?

 sheet already supports tab, tree at present has no keyboard support. 
 These are on the "things I'd like to improve one day if I have nothing 
 better to do" list. ;)

List of some inefficiencies of RebGUI - decide what could be fixed 
with no significatn effort (e.g. widget redesign or particular subsystem 
redesign (tabbing))

1) no keyboard navigation to swith between the tabs (ctrl + tab)

2) no default focus on page? (maybe just not defined in tour.r), 
but if there is e.g. table, I would expect it being in-focus, so 
that keyboard immediatelly works without the need to click the table

3) are othere elements tabbable? I noticed that e.g. on tab with 
sheet demo, buttons are tabbable. IMO there should be also one primary 
element selected as being "in-focus", it should be reflected in UI, 
or I regard it being faulty.

4) sheet widget - define ENTER action doing the same as TAB action. 
Enhancement request (not necessarily needed) - ability to define 
tab/enter movement direction - vertical vs horizontal.

5) menu - when mouse moves, menu should collapse/expand upon the 
movement, not needing 2 clicks (to collapse old position menu, and 
another click to open one - please reduce at least to one click)
6) tree-view - add arrow support
7) area - hilite by mouse or keyboard should auto-scroll area

8) state elements - add tabbing support with visual reflection - 
imo you are wrongly assuming, that users might not use keyboard here 
(space selects)

Is the original data block for a tree available?  I wish to traverse 
the tree and prevent users from adding duplicate leaves

Is the original data block for a tree available?
 yes, as face/data
there are no accessors to add leaves?
 correct, it's a very basic widget at this stage
Does set-data work?
 ... only from within init at present

Hmm.  Anyway of refreshing the tree to show a new node/leaf??

So, I have to recreate the whole layout for tab in order to refresh 
the tree ?

Got this on clicking on the tree

make object! [
    code: 312
    type: 'script
    id: 'cannot-use
    arg1: 'path
    arg2: 'none!
    arg3: none
    near: [pane/1/offset/y: pos 
        pos: pos +
    ]
    where: 'show-node

I hope it's not because I've been adding to the tree/data ....!

That would be it. Unlike other list widgets, which use a face iterator 
to only display visible faces, tree takes a brute-force approach 
and pre-builds the entire tree based on face/data. At runtime it 
uses face/data to work out where to position faces.

Ahley : How do I change  dinamically the tree  widget ? (nodes and 
texts)

Ashley, the tree widget is not indexed here http://trac.geekisp.com/rebgui/wiki/WidgetList
though it appears in the source code list

tree is not new is it??

Anyone using the RebGUI tree widget?  I'd like to use it ... but 
I don't see a way to have a hidden field that could be used to retrieve 
a db record

Any ideas on enhancing the tree widget to have a hidden field we 
can use to access db records?

Something like:


 tree data ["Pets" ID-10  ["Cat" ID-11 "Dog" ID-12]] options [value]

which returns the value instead of the display string?

but only one is displayed in the tree

Any chance of navigating the tree with the cursor keys?

>> display "" [ tree 45x10 options [resize] data [ "one" [ "4" "5" 
"6" ] ]] do-events
** Script Error: Cannot use path on none! value
** Where: show-tree

** Near: all [parent-face parent-face/action/on-resize/child parent-face]

Looks like resize does work if the tree is enclosed in a scroll panel.

In build 122, in tour.r  and in List/Tree the right hand tree is 
now missing.

re: list/tree missing ... a half-implemented change that I had to 
pull out several builds ago.

If I have tree data like this [ A [  B B B ] ]


how can I tell which of the B's that I am clicking on?  Do we need 
some type of index or picked?

I have unique ids .. but putting them into the tree looks ugly :(

Ashley I think we discussed this before .. is there a way to have 
a hidden id so we have both a display element in the tree, and a 
hidden id.

Yes and yes ... but the tree widget really needs to be totally rewritten 
to support that.


If I have tree data like this [ A [  B B B ] ] ...how can I tell 
which of the B's that I am clicking on?

 Isn't this the same issue with drop-lists, edit-lists, text-lists, 
 tables, radio-groups and check-groups? In what case does it make 
 sense to have user options (text strings) that appear identical but 
 have different "real" ID's behind the scenes?

The tree data could be in the form [ A [ B [p] B [q r] B [s t u] 
]

and so the user could differentiate between the different B's by 
examining their contents.

At present a block next to an element indicates a further nesting 
of the tree

Now, yes I could use the CCRDataObjectID to index into the object 
... but that would not look intuitive for a tree choice.

RebGUI v2 RC1 (build 200) uploaded to SVN

Focus of this version has been:
	* Make it look good (color scheme based on Windows 7)

 * Take into account OS sensibilities (different corner rounding, 
 window colors, system fonts)

 * Get rid of the cruft (removal of little-used widgets and options)
	* Improve tabbing
	* Make it load and run faster



Added
	icon
	get-fonts
	confirm
	request
	request-calc
	requesst-verify
	rebface/old-color
	rebface/over?



Reimplemented
	arrow
	calendar
	drop-list
	password
	slider
	tool-bar
	set-state
	set-color



Enhanced
	chat
	edit-list
	spinner
	table
	request-char
	request-font



Removed
	question
	request-ui
	pie-chart
	symbol
	options [info no-click]
	options [arrow options]


WIP
	A disable/enable function and layout option
	Rewrite of led widget
	Rewrite of tree widget

hmm, SVN says:

RebGUI v2 RC1

Added
	icon
	get-fonts
	confirm
	request
	request-calc
	requesst-verify
	rebface/old-color
	rebface/over?

Reimplemented
	arrow
	calendar
	drop-list
	password
	slider
	tool-bar
	set-state
	set-color

Enhanced
	chat
	edit-list
	spinner
	table
	request-char
	request-font

Removed
	question
	request-ui
	pie-chart
	symbol
	options [info no-click]
	options [arrow options]

WIP
	A disable/enable function and layout option
	Rewrite of led widget
	Rewrite of tree widget

LED design is absolutly terrible
 ... please provide a link/image of a better design

Why horizontal scroller shows different dragger symbol than vertical 
one?

 ... vertical uses "=", horizontal wasa "||" but those characters 
 don't center to well

what is the active part of the scroller, and what is the background
 ... you mean the dragger is hard to distinguish from the gutter?
Other than that (and pop-up bugs)
 ... table, text-list and tree still need a lot of work
zero-divide error with  tour.r
 ... thanks, added to the list of bugs to fix

Maybe tree widget could benefit from row coloring too? Would look 
consistent with table and text-list.

nothing pops up when clicking the button, why?

 ... the display function exits if it hits a duplicate window title 
 (before calling layout) ... this means you don't have to worry about 
 the user hitting a button that calls a display multiple times and 
 getting multiple (near identical) windows popping up!

tree widget could benefit from row coloring too?

 ... it will, once I've rewritten it to use the same face-iterator 
 func that table and text-list use (which means it'll get all the 
 extra goodies like auto-slider support as well!

I remember that a previous tour had the tree inside a scroll panel 
and as you expanded the tree, sliders appeared in the scrollpanel. 
 Sometimes you can now display all elements of a tree without that 
functionality.

Build 208
- Fixed unfocus bug
- Fixed table focus bug
- Enhanced request-verify (auto-calc label widths)
- Reworked tree to use face-iterator
- Reworked request-dir

Note the reworked tree widget only has one option [only], and currently 
defaults to expanded mode with no leading graphics. It accepts input 
in either nested block or file/path notation. Selected items are 
now fully qualified by default. Due to it's use of face-iterator, 
it no longer has practical data limits (previous version created 
a face for each item).

How can I collapse nodes in new Tree? Tree without graphically distinguished 
nodes looks strange :-)

I can see edge object for tree - can it hold an image? The way it 
is done in tour.r tree widget does not look like tree :-)

- what happened to the tree-view? I can see I can't collapse it by 
double-clicking parent node in the tour.r, nor can I see arrows in 
there. Is it just not configured, or?

Ashley - why tree-view node icons (arrows) were removed? Or is it 
only in tour.r?

why tree-view node icons (arrows) were removed?

 ... tree-view was reimplemented to face-iterator ... havn't got around 
 to adding arrows/icons for the nodes yet
... dobeash.com is still down

 ... getting the domain transferred is taking much longer than expected, 
 hope to have it back up within 3-5 days
... stops working with buid 208 ...

 thanks marek, most of those issues are due to the major tabbing changes 
 that occurred in 208. Fixing them is still a WIP.

I want to give Rebgui a try for an app i need to do. So, i need a 
tree in there, which should be filled from database request  when 
the app starts. Not via button click.  Can anybody give me a small 
example how to achive this. Searched the docs, but couldn't find 
something like that.  And be kind with me as i am not too familiar 
with Rebgui till now. I downloaded build 218. What i tried so far 
is set-data via button, but that doesn't seem to work.  A sample 
would drastically shorten my way to get this working. Thanks in Advance!!

Tree is not a fully developed widget, so the easiest way of modifying 
it is to dynamically generate the spec. For example:

	blk: copy []
	append blk ["Pets" ["Cat" "Dog"] "Numbers" [1 2 3]]
	display "Test" compose/only [tree data (blk)]

You say that tree is not fully developed. Can tell me, what limitations 
it has?? Is tree able to react  on events, when i click on one of 
the branches of the tree??

Many widgets have accessor functions (e.g. add-row) that allow you 
to dynamically modify them. The tree widget lacks these but is fully 
functional in all other respects.

No immediate plans to update tree widget. For accessor functions, 
search for the word accessor in hhttp://www.dobeash.com/RebGUI/widgets.html

what about the accessor functions? BUILT-TREE etc. any change via 
this?

I mean, top the tree ..ie. trim the branches

yes, list of widgets ... we should not release without widgets like 
tab, tree-view, basic table (list-view), accelerator keys (needing 
redesign of all relevant styles imo, because rich-text will be needed), 
tabbing support. VID2 show stopper was missing more advanced styles, 
at least above mentioned. Those are needed for basic prototyping. 
Newcomers will not be able to produce them themselves. Most ppl would 
prefer such things instead of fancy color requester etc.

dialogs are nice (although I hate them as a concept :-), but the 
most important for ppl will be lists - tex-list, list, grid, tree-list. 
Those are more complicated style, and highly expected ones (looking 
into blog comments). At least one of those styles should be tried 
to proof the concept. So far the most difficult style which was build 
seems to be scroller (area)?

Henrik, do you also have "tree" lists?

There is no tree style yet.

james - your request is along of mine request and another blog posters 
- we should not even dare to release without at least simple table, 
tree, tabs. I have two friends, who use REBOL for quick prototyping 
and connection to DB. One of them works with MS SQL. He creates quick 
tools to help him manage some jobs and some of his colleagues already 
asked about the tool. I really hope that for such guys (who are not 
interested to create widget themselves, but to use some ready-to-gon 
ones) we can come up with some data friendly widgets ...

Also of note: Making an extra style for a new situation is the way 
to go as it gives less code than trying to make a single style very 
smart. Smart styles are harder to code. This creates a lot of styles, 
so I'll have to create a style tree.

Slider is really nice, but quite honestly - how often, if ever, do 
you use slider in your app to represent data? I would welcome more 
practical styles as tabs, tree-view, list-view (grid)

Small status update:


- Mostly doing code cleanups and bug fixes now, so changes are not 
very visible.

- Carl has worked on window positioning and popup offsets, which 
were not working correctly. This should finally enable us to get 
popup styles done. Actually I've already done the first for date 
field. Popups are very simple to do, compared to VID. Just open a 
modal window without a border.
- Icarii has begun working on R3 styles too now. Thanks!

- Still baffled at the concept of MAX-SIZE. There are some places 
where it just doesn't work (see my later screenshots with a funny 
curled-up scroll-bar).

- I'm very pleased with my container style. It has proven to be very 
useful and we will build many more styles with it.

- Autogenerated style list and style tree (will publicize this soon 
here. R3-alpha users can see them in Users/Henrik/style-tree.rmd 
and style-list.rmd)
- Over 80 styles now. I suspect there will be 10-20 more.

- Color policies are being settled, so you can abstract colors away 
from a style into a theme.

- Each style will eventually get a tag block. This makes it possible 
to tag a style as 'internal or 'advanced, depending on where it's 
intended to be used and what it can do. This is very useful in documentation, 
and for some styles that need to work together in specific ways. 
It also makes it possible to hide advanced styles from end-users, 
who won't need to use them directly.


For those who have missed it, screenshots and videos are here: http://rebol.hmkdesign.dk/files/r3/gui/index.rsp

The style list is only there to describe the styles as they exist 
and are defined in the system: As a single flat list. The 'parent 
value is the only thing to make it into a tree. A tag block would 
help us group it however we want. I don't think there will be problems 
describing the styles in the documentation in a clear fashion.

For me, we need - container (resizable), icon bar, tabs, tree, data-grid 
(naming those more complex styles)

My rank is high enough, but I don't think the commands work yet. 
There wasn't even a public decision on whether the file tree would 
be seperate or integrated with the message tree.