World: r3wp

SIZE

you could: view layout [list-view 600x200]

I'll give it a go with a width block... hopefully it won't come back 
and take revenge later :-)

try using a height of 350

the last row is higher then the others

BTW, I'm trying to make it blend in as good as I can with the rest 
of VID by using the same keywords and functions.

no, the bottom portion happens to be in the same color as the last 
row, which isn't entirely at the bottom. that was an easy/quick fix 
at lists that don't add up height wise.

We don't have a resizable bsd licensed multicolumn list ... so carry 
on :)

so the background behind the list rows is simply 240.240.240

I made it BSD licensed, because maybe someday a thousand years into 
the future, when the code is good enough, it could be included officially 
in VID

are the row heights adjustable ... or do I have to hard code them 
?

manual layout again, yes... do you need variable height like in AltME 
so it fits the text?

No, don't need variable height.

where to change the row height and font size for the rows ?

also by manual layout... I think it's actually easier to create the 
manual layout if you want to set a lot of parameters such as:

list-text 75 right bold font-size 17

which is standard LAYOUT dialect

then you can set all parameters of the list-text face

this is also how LIST in VID works

I'll have to read the wikibook again :)

luckily I managed to write a section on LIST in the wikibook :-)

LIST is grossly underdocumented in the original VID docs... If I 
had found it sooner, I could have saved 3-4 weeks of work this summer 
:-(

I've got a new version (0.0.9) version of the chat client at http://www.compkarori.com/reb/

which incorporates Henrik's list ( not used yet though ), and Allen 
has added his link parser :)

http://www.compkarori.com/reb/pluginchat.rfor those not using IE.

version 0.0.12 uploaded.

Changes:
      New: Documentation!

      New: WIDTHS block to let you determine the widths of the columns

    Docs are available in makedoc2 format at:
    http://www.hmkdesign.dk/rebol/list-view.txtand
    http://www.hmkdesign.dk/rebol/list-view.html


Note the new url for the source code for LIST-VIEW is http://www.hmkdesign.dk/rebol/list-view.r

In the coming versions, I will remove the original demo and rely 
more on the docs. I might provide an updated demo later when the 
list view is in a more reliable state.

Henrik it will be cool if you can make list view model independant.

What I mean by this is that list could request a model to give the 
data to display for the specific row. Instead of enforcing a particular 
model for the data representation.

hmm... could you give an example? my brain is a bit fried right now 
:-)

Right now all *data model* is a block. But you may want to be able 
to access a file of bytes and some particular fields in that stream.

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.