World: r3wp

Ashley: changing RebGUI and vid sothat styles are interchangeable.

IMO this complicates the RebGUI widgets unecessarly. It would be 
nice to have a wrapper for RebGUI widgets that make them VID compatible. 
But than only as a oneway. RebGUI -> VID not the other way.

a simple way could be 

1) VID -> RebGUI : a 'face widget for RebGUI, to put any prebuilded 
face (ie made by 'layout) in a display,

2) RebGUI -> VID : a 'make-face -like function to build a reusable 
RebGUI face

Auto-fill or similarly auto-filter is done fairly nicely in Carl's 
Rebodex.

Anyone made a non rectangular gui layout?

Yes, that has been done.  I've seen it somewhere but for the life 
of me I cannot recall where or who it was that built it....

have the rebgui-button working in vid (great success ;) developer/users/volker/mrg/test.r

shadwolf: posted my header-list-1 in users/volker too. yet another 
multi-col-list, maybe it helps.

Nice, I understand what you want to do now ... create a GAL (GUI 
Abstraction Layer) that enables RebGUI widgets to be used in VID 
with zero RebGUI changes. Interesting to see whether you can get 
it working the other way (VID -> RebGUI) as painlessly! ;)

i hope. after all, both create faces. thee are a few differences 
in your api (action has 2 arguments, init is function). and you have 
a resize-system. will look what i can do. at least something like 
  vid[ vid-stuff ] ; symply calls 'layout
should be doable.

btw related dialects: how about using #xywh instead of that tuple? 
then it could be easier detected on the vid-side (issue! -< resize-options)

Good idea, I'll change that in the next build.

btw is the verbose dialect by design or to keep parser short. i guess 
i could do some automatic with few lines overhead. to allow strings 
and actions without the extra brackets.

By design, to keep it as simple (and efficient) as possible. I'm 
open to a more VID-like parse-based approach as long as the complexity 
/ efficiency doesn't blow out as a result.

My old autofill is here. do http://www.rebolforces.com/reb/auto-fill.r

Thanks, I've had the code lying around for ages and was trying to 
find a link (for attribution purposes) the other day. ;)

Paul, you mean like Q ? That used windowsXP-only window transparency 
feature for the window.  Inside a rebol window I can think of a circular 
color-mapped gadget (who was it again...?)

Yes Anton.  I'm looking for a brief example - a small layout that 
shows the capability.

I remember when /view first came out it seemed there was someone 
that made a gui that was eliptical using only faces and no layout.

For VID in RebGUI, an external face widget :

x-face: make face [
    size: -1x-1
    init: does [
        pane: get data
        pane/offset: 0x0
        if negative? size/x [size/x: pane/size/x]
        if negative? size/y [size/y: pane/size/y]
    ]
]

Usage: 
my-face: layout [field "just a field" [print face/text]]

display "A RebGUI display" [
    ...
    x-face [data 'my-face action [print "Hi!"]]
   ...
]

sorry, correction (some VID widgets need a block as parent face) 
:

x-face: make face [
    size: -1x-1
    init: does [
        pane: reduce [get data]
        pane/1/offset: 0x0
        if negative? size/x [size/x: pane/1/size/x]
        if negative? size/y [size/y: pane/1/size/y]
    ]
]

(note the 'feel is replaced by 'action definition when one is specified)

Well after one day of work on the multicolumn list  here is a little 
screen shot of what I succed to do http://shadwolf.free.fr/rebgui-list.jpg

What I need to do :

* Vertacal and Horizontal scrollers management
* Header rendering
* Column content resizing management (internal & external)

* Line Selection with a filled fill (not sure of the wanted way to 
make this work ...)
* Inseting rows 
* Deleting rows

* More widgets support (for the moment I can handle images checks 
and texts)

Actually my code is about a little less than 100 lines

Ashley: changed %display.r to use more parse-features. Hope you like 
it. but introduced a bug, scrollers are broken now. Would now be 
easy to detect something like
 button "hello"

but then that string has it has to be merged with the attributes-block 
somehow. I let you think about it ;)

because the attributes are in a block we clash with vid-style action. 
MAybe we could put the action in parens then, like parse does?
  button "quit" [size 200x100] (quit)

Volker: ( ) for actions - it will be a pain to use with compose/deep 
(needed because 'display evaluation is kept to minimal).

True.

lastest screenshot of the listview item ... http://shadwolf.free.fr/rebgui-list2.jpg

TODO: 
* Vertacal and Horizontal scrollers management
* Column content resizing management (internal & external)

* Line Selection with a filled fill (not sure of the wanted way to 
make this work ...)
* Inseting rows 
* Deleting rows

* More widgets support (for the moment I can handle images checks 
and texts)

* Sorting ;)

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