World: r3wp

Henrik good one I like it you yet input in it some simpatical capabilities 
that I was planned to add into the list view of rebgui like line 
to field editting conversion ;)

Henrik  listviex + shadwolf listview  = the best listview ever seen 
in the world ;)

And man, it's fast. I notice no scrolling delay!

our point with ashley is to gatherring the VID widgets de effort 
into a single process

hehe... well, there litterally are about 50 things missing yet. I'm 
emphasizing on having speed even on huge lists and minimal editing 
capabilities.

christianE: what it does is I create simply a fixed grid of textboxes 
and replace the text in them on the fly. that's much faster than 
setting offset for a very big pane. this way it doesn't matter how 
big the list is, it'll stay fast

Since the very beginning of VID we have seen lot intent of widgets 
improvements make by pationnated people but we never take the time 
to enclose those work into a trully thinked system that's why we 
don't have a reable and durable widget design effort and RebGUI  
tryes to fit this need

PANE is a function I guess, hence no scrolling involved.

that doesn't mean that we can't anymore work on our side to search 
for better widgets and better interactivity system but havng RebGUI 
 improvement as goal makes our work to have a meanning

I don't know how rebgui is built, but if my list turns out as well 
as I hope it will, I'll gladly donate the code for you to adapt it. 
I'm going to use it myself for my VID applications

once our work is achieve we can confront it to the other ones and 
than enhance it more and that's the assurance that if one day we 
are not anymore interrested on develpping this idea our whole work 
wont fall to the pitfall of forgive

:)

right now there still are a ton of functionality improvements to 
come, and it'll be even faster than it is now. I want to implement 
dynamic column sizing, graphics in lists, drag'n'drop and proper 
handling of list actions

Henrik truelly RebGUI  is simple you have basic object (rebface) 
with only the needed things and starting from this point you can 
make new widgets enheriting of rebface basic things and extended 
them ;)

Same here, I expected to need WinXP simulating menus and thought 
others may be interested, too. No deeper strategy involved here, 
shadwolf  ;-)

you have the 	assurance that your new enherited object will only 
countain the needed things and no more ;)

nice demo, Henrik - most of list style attempts miss horizontal scrolling 
though ...

Shadwolf - look at Cyphre's stylepack - it contains pretty advanced 
grid. It is kind of "engine". It even uses some caching IIRC, so 
you can scroll millions of records easily ...

shadowolf: ok... mine is still a bit backwards. I have a list object 
which contains all list functions and the raw layout for the list. 
when I want to use the list, I create a box in a layout and assign 
it to the pane of that box, voila. :-) the list adapts to the size 
of the box, so I think live resizing would work though columnsizes 
are still fixed

pekr, it's on the list, but low priority. :-) my apps currently don't 
need horizontal scrolling, but it'll get there

sure but having to pass thru layout to draw is very very very slow 
when you have to handle lot of data and dirrents data types ;)

rebgui works like that you fill the pane field of the box with all 
your needed widgets and then you make a show box and voila ;)

As do VID styles, I thought?

layout is a translation stage ...  this is not usefull you lost CPU 
time and memory for not a real gain ;)

RebGUI is really nice attempt and only few styles are missing from 
general well usability ...

When I was working on MDP-GUI some month ago basing me on the very 
first intent of ashley we were using a layout compositor (and a layout 
call) to renderize the docuement view than Ashley comes with a design 
based on pre contructed minimal enherited face system and using only 
show the gain inthe do view area rendendering process was about 300 
%:)

I don't understand what you mean by "constructed minimal ...."

so the actual RebGUI is the soon of the work and research of Ashley 
on the MD-Viewer program ;)

my-face; make face [ font: [color: black] ] text: none ]

for example

p: number: bullet: bullet2: bullet3: make face [
			size: as-pair page-width 1
			color: white
			edge: none

   font: make font [size: font-size offset: 0x0 align: 'left colors: 
   []]
			para: make para [origin: margin: 0x0]
			feel: make feel [
 				over: func [face act pos][
					feel-face-docs: 'docu
				]
	 		]
			state: none
		]

		©: make p [
			font: make font [size: to-integer font-size * .75]
			para: make para [origin: as-pair 0 para-indent]
		]

		define: make p [font: make font [style: 'bold]]

yu have some primitive object based on a father object (make face) 
 and then there sons inhert and enhance there capabilities

how is that different from layout? Layout parses your VID code and 
creates View face level one ...

but once you apply layout, you can't get back and decompose to VID 
code ...

so you have 3 levels of inherence in this case face -> p -> @ or 
define

actually it is possible to decompose a face to any dialect, it's 
just not built in and an exercise for an expert. ;-)

Pekr layout is a dialectal parser so he treat the key work (consoming 
CPU and if you have a lot of widget to renderise like into a MD view 
area or a list it's a nightmare...) and the used widgets are the 
VID default ones with lot of unneeded thing ...

words ...

key words not key work ;)

how is that? Even with VID, you can set facets to 'none, if you don't 
need them. And layout is involved only during parse and VID decomposing 
phase, not later, so imo only time it takes is to initially parse 
and build View face level hierarchy, no? Then there is imo no difference 
from RebGUI.

a: box 300x300 ... a/pane: layout heavy-list-of complicated-widgets 
and a: box  ... insert tail  a/pane tiny-widget then show a are not 
the same

when you work with layout you have a loop that create in the VID 
dialectal compliant way the futur content of a/pane then you have 
a second loop (layout) that treats the VID dialect content of you 
temporary object to insert the result into the pane and then you 
have show that draw on screen what you have on the box/pane buffer 
;)

Petr, I think RebGUI is faster because it's not concerened with styling 
schemes as VID does; it's benefit is that it's doing less than VID 
always tried to accomplish but never fulfilled as much as it would 
take to call it complete.

using premade face you avoid the compositing of the VID layer you 
fill the pane field and realize it on scree with show ( so you have 
2 loops intead of having 3 loops using the layout methode an once 
again layout is good for tiny composed interface but for complicated 
interface that's a too long way to do  ;)) )

Chris RebGUI is faster because you don't use layout parser ;) what 
does layout ?

it takes what you write in VID  and convert it into face  based object 
... RebGUI skip this stage and works directly with the objects ;)

VID  use a translation process and REbgui on use it once to make 
the window first design but then not any more for the design ;)

of internal widgets

interna to the window ;)

Yes, that's what I meant: But VID wouldn't need a layout parser, 
too, if weren't as stylizeable than it is. As far as I know, RebGUI 
*by design* doesn't support different styles and therefor is by design* 
faster.