World: r3wp

interesting, let me see if you have the latest compiled version

They seem to be the same size, but, just to be safe:

http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

OK, new executable + dll did the trick ....

ok, good

New R3 GUI uploaded here

http://94.145.78.91/files/r3/gui/r3-gui.r3

Fixes slider crash. Is 21 kb bigger. For some reason. :-)

what's precisely "some reason?" :-)

I don't know.

Got a pattern on the resize loop bug, but I guess it requires a very 
specific VM setup:

1. Start the R3 GUI and make a window. Maximize it.
2. Resize the VM desktop window

3. Hope that your resize action is slow enough to allow you to doubleclick 
the titlebar to de-maximize it.
4. Now it loops between maximized and normal size.

Perhaps there is some confusion about screen-face size changing.

re 'area style - trying auto-scrolling or scrolling in general:


1) still the same bad aproach as with R2 area - I don't care that 
it does not hilite right now, that can be added, but when dragging 
the mouse outside of the area, it stops scrolling, and that is wrong 
- it should scroll even if I move mouse out of the window, wherever 
around my 2 monitors ....


2) when I start dragging, the proportional size of scroller is lost, 
and it gets reset to its full-size dragger ....

probably still some bugs in those areas.

I think, that system metrics are still under-developed. In fact, 
they were never correct in REBOL, and it is known fact, that R2 crashed 
when you changed resulution of window. I would like to see screen-face 
more developed - it should be a block, along with proper system metrics, 
number of monitors, their orientation, resolution, etc.

Uploaded panel scoping prototype:

http://94.145.78.91/files/r3/gui/panel-scoping.r3

Test support file:

http://94.145.78.91/files/r3/gui/file.txt


It's an earlier prototype that eventually became db-reactors, but 
it shows much more of the panel scoping features and uses EMIT, OBTAIN, 
ACQUIRE and SUBMIT.

metrics: I'm not sure what's being considered here. Cyphre may have 
something in the works.

Henrik - new build possible? Rebolek told me, there should be new, 
improved version of area available. I would like to test :-)

one second...

done

is it better?

Area style report:


1) hilite some few chars, then you click elsewhere in the text, or 
just move the caret using arrows - the text stays hilited, whereas 
default OS behaviour is, that the hilite is discarded. The question 
is, if we are targeting for REBOL specific behaviour, e.g. allowing 
to move caret, and have multi-hilte areas? I think not.


2) hilite autoscroll works chaotically. Sometimes it scrolls the 
area, sometime it does not. Dragging the mouse outside the window 
does not work at all.


3) scroll by mouse-wheel. When I reach the "bottom" of the area, 
I loose my focus, and scrolling back up does not work


4) moving up/down by arrow. It seems that in OS native widget (Notepad), 
the caret position is counted by the follow-the-leftmost-tex-length 
rule. So if I e.g. go via an empty line, caret should stay at the 
beginning of line for all other rows.

5) cut and paste into Notepad discards newlines


6) cut and paste from Notepad inserts text in hilited form - random 
behaviour here, ot it needs more observation ...


7) hilited text should be deleled by hitting delete, backspace, or 
by typing any character

8) when hiliting the text by mouse, scroller gets reset to 100%

Is that enough bug-reporting for the starter? :-)

Bolek will see to these, thanks.

Thanks for report.

New R3 compile should fix a scroll-wheel issue:

http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

Is there some easy way of of hot obtain list of available styles? 
Are styles somehow divided upon internal (thsoe are more of classes 
you use to construct other styles) and user useable styles?

words-of guie/styles

I need a function to figure out the style tree. Will have to write 
it later. That would be part of the documentation.

Yes, style tree would be useful, but I think it's not top priority 
right now.

btw - I really hate guie name. It reminds me of Internet Explorer 
and I can't decode its meaning at first sight ....

is there anything like 'flags item in new VID? I find tagging very 
usefull technique. That way you could simply add a tag, e.g. 'internal, 
and such style would not appear int he list of styles for something 
like get-styles function. Simply put - only styles/widgets which 
are able to function on their own, would be shown ...

GUI Enviroment. I didn't like it at first too, but I get used to 
it. OTOH, you don't need to acces guie most of the time.

This will have to be done anyway, or how are you supposed to display 
styles for REBOL IDE, which you can place on a form? Unless you are 
supposed to do it manually of course ...

yes, there's supprot for tags, although it's not used as much as 
it should be right now.

scroll-wheel now works like expected ...

supprot=support

Since the GUI is not a module yet, I don't know whether the GUIE 
name stays.

there definitely have to be accessors like get-styles (get-style-list) 
or something like that. Playing in console and trying to display 
tabbox, container, errors out ...

Tags were implemented by me. They are used in validation and keyboard 
navigation for now.

tabbox, tab-box and container are tests of tab-box implementation 
and only tab-box (name) will stay. They actually shouldn't be in 
SVN, so ignore them for now, please.

Relobek, btw. the tabbing that is done inside the field style needs 
to be removed, which will make tab navigation work for fields.

Ok.

They get into a "fight" and the field tabbing "wins".

:)

OK, so there's recently no way of how to programatically cycle via 
available and displayable widgets, and put them on screen. Just remember 
my request for the tagging and obtaining the list of usefull styles/widgets 
:-)

I'll see if I can make one similar to the style browser for the vid 
extension kit, but that depends on the state of certain styles.

How do I display stand-alone scroller?

noone needs style browser - that is high level stuff ... we need 
architecture

scroller has been rewritten and is not fully axis-independent yet, 
so displaying stand-alone scroller is problematic right now.

we need a style browser, because that is a very quick way to check 
which styles are crashing. could not have shipped the vid extension 
kit without it.

I agree with Henrik, style-browser is good test suite.

I tried the code which worked in Carl's VID: view [p: progress scroller 
attach 'p], but no luck either ...

We don't need style browser, we need the demo app once again, or 
it is really difficult to learn/test. It was already written, so 
it should be imo adapted ...

Please do something about 'field, this is just so wrong :-)