World: r3wp

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.

:-)

Besides it is the adjustment of one single integer that decides that.

I am not stating it is a bug, but for me a usability problem, if 
I have to constantly remind myself, which places its elements which 
way ...

You might need to deal with that anyway. I find myself needing to 
place a number on how many columns I need most of the time, and how 
hard is it really to type a single digit? :-)

Henrik - do we have anything like "anchor"? I do remember, from Romano' 
s styleset resizing model, that you could anchor your element to 
some other, and it stayed that way. Maybe it is not needed with recent 
resizing model?

How does 'tight differ to 'group (both without frame), if I would 
choose 'group and set spacing to 0x0?

group is based on tight, with different spacing.

the question is how much you want to write. often it makes sense 
to make a new style if we find that certain options are repeated 
a lot for a specific style, even if it's just one little thing.

There is no anchoring as far as I can tell.

when i tried to develop my own vid engine, i used negative offsets 
to rely a face (anchor) to the previous one in the pane.

it was quiet simple and effective

ah, I get what you mean now. yes there is something like that to 
anchor popups to a parent face.

Any clues as to why Carl decided not to build the new GUI to support 
Unicode from the beginning?

He's too busy writing a BBS

There will be unicode support in new gui, as the all R3 core is already 
unicode aware. Problem is probably the input, but it's not such a 
big problem and will be done soon.

I wondered if the problem was AGG?

I suppose the way it supports Unicode is different from the way R3 
does.

I guess that in AGG you just must call unicode functions of the api. 
But I really don't know details. But the unicode in gui must be, 
else the changes in core were useles.

But first someone must change Cyphre's task on Qtask from coding 
JS to work on R3 at least 3 days.

JS ?

i really wonder why it's needed to modify R3 to support  the devlopment 
of the BBS

should be a standard app

with standards functions

except if R3 is soo buggous that nothing can work without  patch 
it

Cyphre is  not working on R3. He is working on Qtask. I don't know 
what exactly.. it was a joke a little bit. It has nothing to do with 
Carl and any BBS

Oldes, not true...

So he already has the R3 task? Fine.

Yes, in fact he does

And... https://www.qtask.com/files.cgi/ForREBOL3?tab=get&uuid=EXBGS47FCJ7A291SVTW9WDTTD1QT&filename=For REBOL3

Reichart, are you the big guy ?

Yes, but Cyphre is bigger:)

Reichard...it's by design, that you must download the image to see 
it, or it is bug in Qtask? :)

perhaps this is the other which are hobits

Brian looks crazy

ahah