World: r3wp

Latest build available at: http://www.dobeash.com/files/RebGUI-021.zip

Highlights include:

	- Specification dialect is now VID compatible (and 35% slower)
	- request-color and request-date added
	- Span attribute changed from tuple to issue
	- Couple of minor fixes
	- %tour.r has an additional "Requestors" tab


I wanted to get this build out before folks went too far down the 
converting from VID to RebGUI and vice versa path. If a parse expert 
(I'm not one) could suggest performance improvements for the main 
display parse loop that would be great.

I like very mutchthe requestors :)

there is quirk with them: If you select a color, the requestor button 
keeps the highlighting frame. Should be reseted to neutral.

I like the new way to hadle face parameters :)

I addapted my actual listview work to rebGUI 0.2.1 ;)

compatibilty bug with set-words in definition - investigating

How does this line work?
	| set arg word! (

  either in widgets arg [append-widget widget: arg] [attribute-color: 
  get arg]
	)


append-widget checks for 'widget but 'widget is set after the call 
to 'append-widget


Further, in the parse-rule the above line comes last. But it parses 
the widget words. When do the parameters get parsed? I would have 
expected this rule to be the first after the keyword rules.

0.2.1 i see the memory use growing up from 5976 kB to 7090 KB then 
it's stable is it normal ?

bug found:
line 243 in display.r : 
| set arg set-word! (append-widget word: arg)
arg should be a get-word :
| set arg set-word! (append-widget word: :arg)
to work with 1.2.1

speed: Ashley, the parse spec looks very much like a degenerated 
'switch statement to me. You are not doing anything wild that requires 
parse. Have you tried to loop through the spec block and use a switch 
statement instead? It might require a bit state handling but could 
be faster.

Robert, not that simple : we have selection on both datatypes and 
keywords, with optional parameter of various datatypes. The 'switch 
wouldn't be trivial

There is a room for improvements in the parse loop, as a set-word! 
is always followed by a word!, and file!, string!, issue! (and others) 
are never alone.

the datatypes are unique. Each on only shows up once. I don't see 
any optional parameters. The parameters can either be of type A or 
B, ok. But that can be handled in the action block of the matching 
switch. And there we can reposition the spec block to skip those 
handled cases.

I make a sample data table of 5 by 100 entries to allow me to test 
the resizing / scrollings issues ;)

Shadwolf, did you consider to specify names for the columns so that 
I can provide a name/value block? With this the name/value block 
can contain much more values than the grid should handle. Very handy 
feature.

robert yes this feature was yet passed to me by cr8825 on french 
forum for non visible data what I plan to do Is hadding a special 
flag like hid for example:)

I figured out a little problem when I ste up the scrolling has the 
header and is in the same countainer as the column and row scrooling 
make desapear the header buttons :)

shadwolf: Adding a hide flag requires me to alter all my data. Just 
wrap it around, if the grid doesn't know about it, just skip it.

Robert: on switch version : trying - but some difficulties. A rebgui 
declaration is of kind :
any [ global-parameter | global-parameter-with-arg argument | 

         opt set-word! word! any [integer! | pair! | ...  | keyword [integer! 
         | pair! | ...] ] ]

the problem with that is a) the optional set-word!, b) for widgets, 
both values and keyword/values are allowed

with 'switch it's far less readable (for arguments, we have to separate 
keywords and datatypes and use "switch/default [] [swtich []]"), 
and takes more code

I solved the problem with  the scrolling ;)

?? don't understand ...  but we have lot of time to have me understanding...

you want to be able to join directly the column is this what you 
want  ?

or being able to make formula like in Excel  = AA:01 + AB:02

n: 100'000
bench: func [code] [t1: now/precise loop n code
	print [difference now/precise t1 mold code]
]
bench [switch 'f [a [] b [] c [] d [] e [] f [] g [] h []]]

bench [parse [f] ['a () | 'b () | 'c () | 'd () | 'f () | 'g () | 
'h ()]]

parse is 3* faster here.

parse loop in display.r needs some work, as a lot of wrong combinaisons 
are allowed like [s: 10x20 #1010 button] and not easy to trap.

tuning parse: first thing would be to put the frequent things first. 
like string! and block!. and soemthing like 'rate last. if parse 
is the slowdown.

its a sequential search.

A related improvement (if possible) is to group all the word tests, 
something like:

	set arg word! (
		switch arg [
			return [...]
			at [...]
			"a color" [...]
			"a widget" [...]
			...
		]
	)

to see my advance on list-view widget report to the first working 
sample http://shadwolf.free.fr/rebgui-list2.r

I redone it completely ;) changing the way data was handled ...After 
a little chat with Vinxent it appears that sort algorithms would 
be easier to write if the data was handled by rows instead of beeing 
handled by row ;)

I expect switch is slower.

maybe the native case can compete.

volker I just made a 1ko lesser more opimized version  ;)

native case ? how that ?

looking how case works ;)

oh oh case word is not in the dicionnary  ;)

plz Volker can you explain me how it works ?

huuuuuuuuuum I wouldn't be using  case because it's an alpha feature 
only support in rebol/view 1.2.5x

its in the very latest alphas.

now i see you found it.

I remake another time the buil-table function for the listview widgets 
( acording to Ashley  advices) build code is pretty easier to understand 
and the buildtime spend in the fonction is pretty inferrior than 
in the previous implementation (on an other data organasation ) rebgui-list2.r 
build-table time is 0.047 with regui-list3.r it's 0.31 (both  with 
data countaining 5cols  100rows on a PC ( win2k SP4, Amd sempron 
2600+, SDRAMM DRR PC3200) )

According to ashley advice the new data organisation is faster and 
it will be easier and fast for the sorting algorythm (still not implemented 
in rebgui-list3.r ;)

you can download here my current work here http://shadwolf.free.fr/rebgui-list3.r

Hey shadwolf, how about english comments :-)? My French is a bit 
rusty.

Esperanto? ;)

listview: Pretty cool :-)) Some ideas:

- add a line highligh feature for the selected line and the line 
the cursor is currently pointing to

- double clicking the column-resize bar resets the column width to 
the default value

- add an up/down arrow to the column which was used for sorting, 
to indicate sorting order

I'm sorry working in french is just easier for me ...

the code is so easy that we doesn't need comments I facts :)

Nice work absolutely.  One comment...

I believe the 'typical' behaviour of column resizing that each trailing 
column is offset the amount the column was resized.

I was also thinking about the feature that was being discussed that 
allows for more tabs than the width of the layout.  How about an 
option to allow the tabs to wrap when larger than the layout?  Take 
the number of tabs, divide the total by two and auto-size the tabs 
to the full width of the layout, just now there is two rows.  I think 
this would be a nice alternative behaviour for when the user interface 
benefits from being able to see all possible tabs.