World: r3wp

ryan, that's a possibility

selected behavior by default. seems nice.

yeah, however there might be a slight confusion: Currently the -HERE 
functions take in account filtering and sorting, so that you always 
edit or retrieve the right row regardless of these settings. the 
other functions get and put directly in DATA. The behaviour would 
either need to change or I'd have to add another refinement

there could be a /direct refinement.

-marked ?

(because I believe that direct editing of data would be rarely used, 
but I'm not entirely sure)

I don't use the term "marking" anywhere...

suggestion:

insert-row - would add a row at the selected position


insert-row/at - would add a row at the position that can be seen 
in the list after filtering and sorting


insert-row/at/direct - would add a row directly in DATA at the position

insert-row/direct - would be ignored? (I don't like that)

poke-row?

poke would be like change

/raw ? raw index?

yeah, that would be good

insert-row/raw could be the way

I dont know, good luck with that guys. Seems to have a whole lot 
of innuendo's. BTW Henrik, this is a very needed control, I commend 
your efforts!

wait a minute... 'at is an existing function. will that work?

ryan, thanks :-)

sys-at: get in system/words 'at

you must be carefull in that function. and use system/words/at for 
the real one.

I don't think it's good, because I already use 'at in the raw functions

a less elegant option would be to use separate functions: INSERT-ROW, 
INSERT-ROW-AT, INSERT-ROW-RAW

first infunction::
  at-ref: at at: get in system/words 'at
and the rest can stay the same. not elegant, but..

I don't like it...

I dont love it

or INSERT-ROW, INSERT-ROW/RAW and INSERT-ROW-AT

/raw and /at wouldn't be used simultaneously anyway

doing it this way, will require a minimum of changes to the code

maybe INSERT-ROW, INSERT-ROW-AT and INSERT-ROW-AT/RAW would fit better...

from the interface i like /at

I like it too, but I'd hate to code it :-)

why?

its one ugly line.

because of the above indirection

/here maybe just as good for this func...

(coming full circle)

could be, but DideC would then ask "where?" :-)

Since here is a refienement, it assumes you the specify. selected 
behavior by default.

I you want it to be real slick, I would graph them out, pro and cons, 
etc. If you want it finished, keep up the good work.

well, thinking about it, /here is a pretty good suggestion. Then 
we'd have INSERT-ROW, INSERT-ROW/HERE, INSERT-ROW/HERE/RAW

Anybody got a rebol routine for saving gifs? Perhaps the one I wrote 
years ago and happen to lose?

words: [data [new/user-data: second args next args]]

I sometimes miss a "soft" SHOW, which only shows faces that have 
the SHOW? flag already to be true. Is there an easy way around that?

soft-show: func [face] [if face/show? [show face]] ;)

and if I have a large set of faces in a pane?

and more grouped faces inside those faces :-)

soft-show: func [face [object! block!]] [
	...
	either object? face [
		if face/show? [show face]
	][
		foreach obj face [...]
		...

get's to be too complex, I think

It does get complex, and possibly too slow, but you may be able to 
patch show usefully for your application.

Check out a patched SHOW near the bottom of http://www.lexicon.net/antonr/rebol/gui/mimic-do-event.r

It uses a TREE-FACE function.to recurse to all subfaces of the face 
you are SHOWing.

The thing is to optimize the show-tree. If you have to show more 
than 50% of the sub-faces I can imagine that showing the partent 
face is faster than checking each sub-face.

Is this the latest anamonitor ?  http://www.rebol.it/~romano/#sect1.1.
It has header problems when I try and run it.