World: r3wp

Thery are also developing a compatibler ELICA LOGO compiler called 
Lhogho. refs are also included.

Has there been any recent releases here?

Still into deep rewrites.

The current overview of all styles:

http://rebol.hmkdesign.dk/files/r3/gui/253.png

Some more images here:

http://rebol.hmkdesign.dk/files/r3/gui/

A bit of status:


- Cyphre has recently fixed a bug in the hostkit with the display 
of some unicode characters. Will see if there can be a release.

- Cyphre has been working on fixing various low level issues in the 
R3 GUI source

- Cyphre is working on testing scheme for GUI and some documentation

- Bolek is working on styles and a TODO test application, called 
"Notation" for Robert

- We still need Carl to fix one particular bug, which is prevents 
creating complex layouts

Thanks a lot for an update, both Robert and Henrik. It is encouraging 
to see some activity. As I personally offered to Rebolek - I can 
make some quick testing/private reporting, so if you can prepare 
some interim release, I am interested. But - I can wait for the official 
one.

btw - what's the bug preventing to create larger layouts?

it's the old assertion failure

actually it doesn't have to be particuarly large, but there are some 
specific triggers, like this one:


view [tab-box ["tab1" [] "tab2" [] "tab3" [] "tab4" [] "tab5" []]]

Thanks for the update Henrik!

how powerfull is a table style? I expect it not being full grid capable, 
as Cyphre did in the past, however what's the basic functionality 
to expect?


- column sorting - two state, or three state? (I don't like when 
I can't get back the original sorting = unsorted), but that's just 
my point-of-view, and not importan feature initially
- column filtering like in MS Excel
- how much data the table handles?

I am referring to: http://rebol.hmkdesign.dk/files/r3/gui/255.png

- hmm, no horizontal scrolling?

column sorting: three state.
column filtering: yes.

how much data: lots of. In normal mode you're limited by memory, 
in DB mode you're limited by your DB system.

horizontal scrolling: not yet, but can be easily implemented (you 
can already select which columns to display).

interesting, thanks ...

btw - do you work with the db/query-obtained data block "as-is", 
just selecting which column to display at what position, or do you 
have to pre-build/modify your data first to be displayed?

It queries db on table refresh for visible rows.

DB mode? That's exciting news. Thanks Rebolek for the update and 
Pekr for asking.

Simple demo of automated testing:

http://rebol.hmkdesign.dk/files/r3/gui/010.mov

Very nice

Most excellent Henrick (and RMA).

That's impressive Henirk

Thanks Henrik. I'm curious if you have found things that didn't work 
using these methods.

Perhaps that's a question for Cyphre?

James, I wrote first round of basic tests for some styles and so 
far this method works well. I haven't tested recording of realtime 
resizing and dragging so far but I'm sure if there are any issues 
they'll be fixed along the way. Otherwise this method doesn't cover 
only recording of user input, but it is possible to insert 'checkpoints' 
with REBOL like code to check specific conditions during the testing 
sequence. Cmobination of both makes this testing subsystem very flexible 
and relatively easy to use.

We are currently discussion an option how to write GUI dialects. 
The thing is how to access face stuff. At the moment you write it 
like this: get-face/field my-table [cell 2x3]

Whereas I like path notation more: my-table/cell/2x3


Using path notaion is not possible but we could enhance the dialect 
in a way that: "get-face my-table/cell/2x3" would be converted internally 
to: get-face/field my-table [cell 2x3]


So, what do you think? I'm not sure if supporting the path notationis 
worth the effort.

I like path notation better, too

How one distinguis obfuscated path notation from the real one? I 
have headache because of path notation usage from VID2, where one 
could cause "unexpected" changes :-)

We found a way to support both without big effort. The non path version 
is better if things are script generated.

And, there won't be any changes. It's just to access stuff in a face.

Thanks Cyphre for the explanation.

Tag field style:

http://rebol.hmkdesign.dk/files/r3/gui/257.png

Is that just CHECK, or does it work differently?

I think the intention is to emulate the MacOSX tag field. You write 
in a "floating" text field and when pressing enter, it becomes a 
tag, which can be deleted or moved around. Deleting or moving doesn't 
work yet.

looks like it removes the widget

Ah, so you enter the text. Thanks

One thing I would like to see is the ability to keep focus on a field 
and not let it be lost to other faces/widgers appearing

without having to create a modal requester

or dialog

noted. perhaps Bolek can answer if this is already possible (I'm 
already doing that in the VID Extension Kit).

In an async application you can't control which windows popup in 
the background ... so you want to keep focus on a field where you 
are entering data and not be kicked out of that field

Taken from RMAsset Twitter: "We plan to release a new R3-GUI version 
next Friday." Any significant changes about tobe expected, in comparison 
to latest release?

If I understand it correctly, your NLPP app, version 2.0, is going 
to be done in R3, hence using R3 GUI?

NLPP 2.0 is R2 and RebGUI based.

ok, thanks ... Ithought that R3 GUI is suited for that task, but 
that would be probably a preliminary assumption :-)

The timing is bad, as NLPP 2.0 has already been in development since 
early 2011 and it's almost leaving alpha development. Furthermore, 
there is a lot of development time invested in some special RebGUI 
widgets for NLPP and converting this work to R3 would take a significant 
amount of time.

That time is better invested in allowing people to work on specific 
things, like the automated testing system for the R3 GUI, rather 
than specialize ourselves into a corner this early.

Are the RebGUI widgets being released?

Not sure, as the usefulness is probably limited outside NLPP.

Thanks for the new release.

With our R3-GUI test-system available now, we could really need some 
help in creating test-cases. The more the better. We want to build-up 
a huge test-suite for GUI tests that we run on "every commit" to 
keep quality high and identify breaking changes.

The more help to build test-cases and submit them to us, the faster 
we will be in pushing R3-GUI forward.