World: r3wp

So, instead of forcing the conversion of the bytes stream in the 
block data model. The list view could interrogate the controller 
to extract the data from the base model.

So list-view will say to an intermediary function give me the first 
row of values. This intermediary function ask the conversion func 
aka the controller to extract and conver the data from the reall 
*data model*. The controller returns this to the list-view list-view 
displays the row of data.

So LIST-VIEW will use the MVC paradigm. (Model-View-Controler http://en.wikipedia.org/wiki/Model-view-controller)

This way LIST-VIEW is *data-model* independant. Programmer doesn't 
waste ram or cpu cycles converting all data to from *real data model* 
to LIST-VIEW expected *data model*. The programmer only need to write 
the controler part. Which is taylor for efficiency. You only need 
to extract the values that are visible by the LIST-VIEW at any given 
moment from the *real data model*.

The current list-view is quite nice. ;-)

are there any real life rebol widget examples doing this ?

Nope. One of my problems with VID and RebGUI is that the gfx are 
to tightly couple with the data representation. So a change in data 
representation implies a change in the gfx code.

It think it will be nicer if we could decouple the gfx widget code 
from data representation making it data model agnostic

what it can do right now is append, change, remove and insert rows. 
so this would be kind of an ACQUIRE function that calls a controller 
function that returns a value that can be inserted into DATA with 
insert-row or append-row?

with the point being, that you call your data source and insert the 
data into the list using a single function

Yes. That sounds good. ACQUIRE.

I'll take a look at it, maybe tomorrow. close to bedtime now :-)

Anyone point me to where Cyphre's pattern generator is ?

It was supposed to be in viewtop/view/tests ..

Henrik, just looking at your list-view, and noticed a little thing 
that can be optimized:
b: []  insert tail insert tail b 1 2
b ;== [1 2]
b: []  insert insert tail b 1 2
b ;== [1 2]

Also this:

 toggle "Single" 70 [li/select-mode: to-word face/text] of 'select-mode

 toggle "Row" true 70 [li/select-mode: to-word face/text] of 'select-mode

 toggle "Multi" 70 [li/select-mode: to-word face/text] of 'select-mode

 toggle "Multi-row" 70 [li/select-mode: to-word face/text] of 'select-mode

 toggle "Column" 70 [li/select-mode: to-word face/text] of 'select-mode
can be optimized to this:

 style my-toggle toggle 70 [li/select-mode: to-word face/text] of 
 'select-mode
	toggle "Single" 
	toggle "Row" true
	toggle "Multi"
	toggle "Multi-row"
	toggle "Column"
halving the amount of code in this case.

I see you are successfully basing on FACE. Just a point about placement 
of custom facets; I would put all the facets that already exist in 
face at the top, then follow with all your custom ones. That way, 
someone who reads your code can see which is which. Furthermore, 
if by some chance the FACE definition ever changes (adding or removing 
a facet), it will be easier to see where the fault lies. Eg:
	list-view: face with [
		size: 500x300
		edge: make edge [...]
		
		; my custom facets

  colors: [...]  ; <--- this is the same name and I suppose the same 
  concept as used in VID 
				; (but it's still custom from list-view's point of view)
		select-modes: [single multi row multi-row column]
		; etc...
	]

What I meant to say about the face definition changing - say for 
instance a COLORS facet was added to FACE. Then, you would be unintentionally 
overriding the View system's one and probably introducing bugs, because 
the View system would expect it to be used a particular way and might 
render the face incorrectly given the data you've put into it. It 
might also change that data when you expect it to remain, etc etc.

mvc - thats like supply in the real list works. So there are demos 
:)

Not "real", the inbuild one.

anton:

First one: Alright. :-)

Second one: All that code will be thrown out and there will be a 
different demo later

Third one: You have a point. I'll look at the issue of sorting standard 
vs. custom facets.

Henrik, Cyphre once did a list-view for me. It has some really nice 
things in it. Take a look at http://www.robertmuench.de/projects/data-form
for some docs on it.

Let me know, if you want to take a look at the source code.

thanks! I'll take a look at it.

Cool stuff.

yes, absolutly ... IIRC Robert suggested his form dialect to be accepted 
for VID, no?

it would be good if RebGui had similar schemas ...

version 0.0.14 uploaded

Changes:
      Fix: Documentation updates
      Fix: Multiple lists accidentally shared the LIST-SIZE value
      New: Custom layout block can now have multiple rows
        at the cost of horizontal resizability
      New: Now using ROW-FACE to store the custom layout block
      New: If HDR-COLS is set to a single word in a block,
        it will take the width of the list view.
      Fix: Code size optimization of navigation functions

      Info: The version between 0.0.12 and 0.0.14 is mysteriously missing... 
      :-)


The demo has been changed a bit to test custom layouts and multiple 
lists.

http://www.hmkdesign.dk/rebol/list-view.r
http://www.hmkdesign.dk/rebol/list-view.html

possible to configure slider width as an option ?

try list-view/scr/resize/x <value>

i'm using your list in my chatclient ...

nice. :-) screenshot?

.. well, using version 0.0.11 :)

http://www.compkarori.com/reb/if you have IE and plugin.

or, http://www.compkarori.com/reb/pluginchat.rif using rebol.

please note that now when using custom layout, it's not possible 
to have a horizontallly resizable list, because it's hard to determine 
how the elements should be resized without making the layout code 
complex (if no one has any suggestions, that is...)

I think rebgui assigns percentages to each column for horiz resizing.

that's a good idea! I think I'll implement that soon.

oh well... off to bed. lots of work tomorrow

** Script Error: case has no value
** Where: read-msg
** Near: case [
    parse clientmsg ['cmd set usercmd block!] [
        case [

            parse usercmd ['set-userstate set chat-users block!] [
                update-chatlist]]]

    parse clientmsg ['action set userblock block! set cmdblock block!] 
    []

    parse clientmsg ['chat set userblock block! set payload block!] [
        if error? set/any 'err try [
            payload: load payload
            insert tail payload now
            if all [payload/1 = "Eliza" f-10/data] [
                return]
            repend/only chat-list msgline: copy payload
            either viewed? chat-lay [

                f-chat/pane/size/y: append-msg reduce msgline f-chat/pane/size/y

                f-sld/redrag f-chat/size/y / max 1 f-chat/pane/size/y
                f-sld/step: 1 / max 1 (length? chat-list)
                if f-sld/data = 1 [
                    slide-chatpane 1]
                show [f-chat f-sld]] [
                display-chat/new 10x10]] [
            probe disarm err]]
    true []]
foreach channel chatroom-peers
>>

That's an old version now.  As you've discovered, 'case isn't defined 
in the plugin.  I've used Ladislav's 'case for the later versions 
.. 
Don't know why you're seeing this now .. unless it was cached.

A later version if not the latest is http://www.compkarori.com/reb/pluginchat5.r

bug: the background doesn't scale above something that looks like 
800x600

is something supposed to happen when you select a user from the list? 
It reacts very slowly and sometime require multiple clicks before 
it responds

The list doesn't work in the browser as the list needs AGG.  It works 
in View, but doesn't do anything at present except display online 
status.  It scales for me fine up to 1024x768.

Make sure it is version 0.0.15 ...

Just tried it again .. you're right.  The list elements react very 
slowly.  Wonder why that is ?

Maybe I need to try your latest list-view ?

the buttons at the list top react okay though .. just the rows are 
sluggish.

Just playing with it .. I've only got two list entries, and the top 
one responds each time.  It's the bottom one that is resistant.

So, looks like a bug in that version of the list-view.