World: r3wp

Henrik - the problem with the list is its complexity. I am not sure, 
I would like to see hidden advanced styles, but various variants, 
and styles as 'clicker, which has no benefit for an end user, unless 
he/she is ready to produce his own ones, based upon 'clicker.

Simply put - when you look into RebGUI widget directory, you can 
see all widgets, which imediatelly make sense for user - when you 
compare it with the list provided, the difference is very obvious 
- every one single self-descriptory, usable, vs. chaos ...

The distinction boundary and suggestion of how to think about tagging, 
is imo - VID level user, making GUI, not wanting to create style, 
vs style tweakers, vs style authors ... - but that is only suggestion.

As for MAX-SIZE - what does Carl thinks conceptually about your concerns?

Carl has not responded much to MAX-SIZE, so I am only thinking that 
he will at some point solve the issue when he gets annoyed with it 
enough himself. :-)

The style list is only there to describe the styles as they exist 
and are defined in the system: As a single flat list. The 'parent 
value is the only thing to make it into a tree. A tag block would 
help us group it however we want. I don't think there will be problems 
describing the styles in the documentation in a clear fashion.

How it looks with unicode in VID texts?

not yet

Henrik - what is in system metrics? Is there resolution only? Or 
also other aspects? In the past, I tried to wrap rebol to win32 funcs, 
to detect properly multiple monitors and their orientation, but was 
not successfull at the task. It would be nice, if we would have such 
funcitonality ...

pixels are used here

I will try today one test with r3-alpha - connecting my notebook 
to LCD TV. IIRC, REBOL then reports screen size of monitor1-X + monitor2-X/max 
(monitor1-Y, monitor2-Y), or something like that ...

Henrik, I went through all of your videos and it looks awesome. Had 
there been any discussion on an HTML viewer widget?

Not at this time, no. I think that will be left up to a 3rd party 
to do such a thing.

I'm wondering now if it's going to be possible to write an R2 client 
for RebTalk. I've not asked Carl about this yet.

Why not ? It's just using LNS isn't it?

Is the source available?

to Rebtalk?

Is rebtalk downloadable yet?

only for the chosen ones ...

ie. the famous five

I wish the teasing would stop or at least be backed by a well thought 
out and valid date.

I think actually it's just using HTTP.

Graham, it's currently useless due to HTTP bugs. So it was a pretty 
good thing to work on.

Oh ...?  I looked at the data format and it looked similar to LNS 
format

Oh yeah ... I used a web client!  :)

Rebtalk is very small, smaller than the entire of LNS.

So plain ordinary http

looks like it.

http bugs??  Oh oh ... Gabriele has some work to do then :(

Carl and Maarten are working on it now.

Henrik, you're sleep talking!

well, I did express my opinion that we needed a BBS ...

CharlesW: for html viewer, it would be best to wrap webkit :-)

Henrik - nice - http://rebol.hmkdesign.dk/files/r3/gui/166.png

Just two questions - 1) what it the space at the bottom grid? A layout 
bug? Or just wrongly set container size? 2) Will there be anything 
done to font rendering? Some letters look rather blurry. Is it a 
bug, or just we are not still using more advanced font rendering 
techniques? I thought that moving to AGG will solve it for us ...

1. Some kind of error, possibly due to the wonders of MAX-SIZE.
2. Cyphre will need to handle that.

I wonder what Carl thinks about MAX-SIZE concept. In fact, when thinking 
about scallable apps, I am not sure you can make it work in required 
way.

What is the style the picture shows? List-view? Or some grid prototype?

I will explain the construction in a minute. Need to run an errand...

Ok, I'm building it of several parts. (This may change if I find 
some more clever way of doing it.) First there is a DATA-GRID, which 
is a TIGHT style that contains actors to generate a grid view and 
links to a block of data. DATA-GRID is a slave style in that you 
link it to a data block and then it will display what it can display 
of that block from a start index set in the style, so it works like 
a data window. TEXT-GRID is currently just a variant of DATA-GRID 
with different spacing between cells.


Next, we can move that start index around by attaching a scroller 
to the DATA-GRID, and set the DATA-GRID's ON-SCROLL actor to set 
a new index, based on the input from the scroller. The scroller will 
be set based on the size of the data block versus the size of the 
data grid. Presto, a functioning list view.

I will explain sorting, filtering and all that later.

Please don't make the mistake, typical for few grids I tested - that 
you can't unsort :-)

If I get to do it, sorting will be non-destructive, like LIST-VIEW. 
This means keeping a sort index. But that depends on how complex 
it will be. Carl tolerates only little complexity.

I think I need to re-read all those tight, panel, group, container, 
as those styles are similar and I don't understand why and when should 
I pick, when starting to do something ...

yes, I am with Carl here = VID should come with some basic, but rathere 
complete styleset for forms, data navigation, etc. Somethink like 
your grid can come later, from 3rd parties.

PANEL - When you need to group faces together loosely with a nice 
frame.

GROUP - When you need to group faces together loosely without any 
frame.

TIGHT - When you need to group faces together tightly without any 
frame.

CONTAINER - When you need to group boxes and controls. This is for 
specific styles and not for beginners.

For me, we need - container (resizable), icon bar, tabs, tree, data-grid 
(naming those more complex styles)

Is content elements orientation unified for panel ang group, or still 
it differs? Is it really a bug, or Carl wants it that way?

an icon bar could be a simple group

I don't know if it's a bug. It has not been touched. Quite frankly, 
I've not noticed it at all until you mentioned it.

:-)