World: r3wp

and set the font size for a: a/font/size: 14 (b is 12 at this point)

 <--- I don't set a to a/font/size there although it looks that way, 
 sorry.

should be "and set the font size for the variable a to: a/font/size: 
14"

I'm not sure just how that changed, Ashley, but I did hear some talk 
somewhere here about execution of user.r being removed because its 
a security issue...

A and B share the same, so what you need to do is

view layout [a: text "12345" font-size 14 b: text "12345"]  ?

a/font: make a/font [size: 12]

ashley: I can't determine font size at layout time

christianE: interesting, I'll try it. thanks

christianE: it seems to work, thanks :-) now to integrate it into 
my program...

You're welcome.

Ah, should have mentioned that it's not necessary to do that *everytime* 
you change the fontsize. It's necessary only for the first time you 
alter it.

After that, you simply can A/FONT/SIZE: 13

I didn't think it was either :-)

yes, works in my program too! solves an age old problem for me :-)

Shadwolf, yes, you're right. Today VID is a bit loosing the focus 
in favour of REBOL/View 1.3.0 and probably RebGUI, but I'm sure there 
will be efforts again.

RebGUI  have it's own phylosophy first make tiny useful widget set 
that take the lead over VID ...

someone tried to port Cyphre's menu to RebGUI?

Yes, it's a whole new approach.

Shadwolf is doing so.

but my ask in the reflexion process is why to consum less code less 
memory less CPU  and be sharpen if we are only at the level of what 
we can see with winAPI ....

ChristianE's looks more polished, but - way too large, especially 
for Carl to include it in official distro - 75KB ...

No, it's really no 75 KB pure code, far less.

We must IMOO  have a widget set that is similar than what are  people 
habbits and be smoother and able to be distinguish directly

I think Rebgui could be an OS independent link to user Interaction

we abstract from OS capabilities and set of widget and we introduce 
a commun set

That's right, shadwolf. My approach was more of the kind of simulating 
existing OSes, I had a need for that.

this is in my opinion the same intent as GTK+, WxWindow, TK, QT and 
other in this mood libraries ;)

As I said - we need tree-view, grid (or little better list), tabs, 
group-box, and maybe even menu. Those missing styles will make it 
difficult to newbies to start using View as full-fledged dev-tool 
replacement ....

That was my starting point. These bunch of missing styles, no resizing, 
...

I am developing a better listview myself... hopefully it'll be generally 
useful in a few weeks

As I said - I can definitely tolerate different look. It is imo even 
vital to be slightly different. Today that is once again a trend 
- just look at Ad-aware for e.g. But - ppl will not tollerate that 
well, if app behaves differently, commone keys don't work etc. - 
that is my experience ...

Chris your code can be bettered more people will work on it more 
sharp it will be and if we have as goal to include it into a state 
of art basement library like rebGUI I think this will be very enthousiastic 
for people who will participate ;)

@shadwolf:  : D

I make a listview widget multicolumn multi resizing with drag&drop 
Viewed bar effet like in Win32API and multi widget type capable in 
only 3 weeks and using less than 300 That's the illustration that 
REbgui and VID base concept are pretty good  !!

Pekr, regarding the sliders in the menus: You know AMIGA, do you? 
Remember these popup-slider's in MUI? IMH way ahead of fiddling with 
this 4x4 arrows in InDesign, Freehand etc.

These UIs indeed are coming to their end, way to cluttered.

http://hmkdesign.dk/rebol/listbin.r<--- very, very quick and dirty 
demo...

Great stuff Henrik, this definitly doesn't *suck* as all the list 
entries say  ;-)

Henrik good one I like it you yet input in it some simpatical capabilities 
that I was planned to add into the list view of rebgui like line 
to field editting conversion ;)

Henrik  listviex + shadwolf listview  = the best listview ever seen 
in the world ;)

And man, it's fast. I notice no scrolling delay!

our point with ashley is to gatherring the VID widgets de effort 
into a single process

hehe... well, there litterally are about 50 things missing yet. I'm 
emphasizing on having speed even on huge lists and minimal editing 
capabilities.

christianE: what it does is I create simply a fixed grid of textboxes 
and replace the text in them on the fly. that's much faster than 
setting offset for a very big pane. this way it doesn't matter how 
big the list is, it'll stay fast

Since the very beginning of VID we have seen lot intent of widgets 
improvements make by pationnated people but we never take the time 
to enclose those work into a trully thinked system that's why we 
don't have a reable and durable widget design effort and RebGUI  
tryes to fit this need

PANE is a function I guess, hence no scrolling involved.

that doesn't mean that we can't anymore work on our side to search 
for better widgets and better interactivity system but havng RebGUI 
 improvement as goal makes our work to have a meanning

I don't know how rebgui is built, but if my list turns out as well 
as I hope it will, I'll gladly donate the code for you to adapt it. 
I'm going to use it myself for my VID applications

once our work is achieve we can confront it to the other ones and 
than enhance it more and that's the assurance that if one day we 
are not anymore interrested on develpping this idea our whole work 
wont fall to the pitfall of forgive

:)

right now there still are a ton of functionality improvements to 
come, and it'll be even faster than it is now. I want to implement 
dynamic column sizing, graphics in lists, drag'n'drop and proper 
handling of list actions