World: r3wp

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 :-)

Small bug -  view [bar box check radio arrow-button slider p: progress 
field] .... type something in the field - the text jumps up and down 
as you type ....

fixed...

that was fast :-)

min-size was too small, that was all :)

btw - why field style metrics are so wrong? Sometimes I can see proportionally 
too big fields - e.g. Facebook main page. And new R3 GUI uses too 
thin field. Look at old R3 View demo, section 'Form, how nice it 
looks :-) I just hope it is just question of some tweaking :-)

Modern field = 1pixel think colored border, NO FREAKING SHADOWS :-)

We don't need style browser

 - the demo app did not display styles in an organized way. That's 
 what the style browser does.

think=thin

OK, whatever ... if it would work like in RebGUI, showing some automated 
help/parameters, or old R2 Word browser, it would be nice ...

Easy VID was nice too, as it contained examples you could click ...

scroller: I'm not sure it makes sense to attach scroller to various 
styles inside the layout. You may not realize it, but that code is 
very complex to write and also difficult for the style writer to 
use. It's easier to write styles with scrollers attached in a fixed 
way and much easier to maintain.

Pekr, if you want field 50px tall instead of 24px, I can change it, 
I have no problem with it. But I think that you concentrate too much 
on the look, which is really not top priority right now.

Rebolek - those are details which could be corrected in 1 minute, 
and make the overall feel for the tester much better. The whole team 
is not even at the level of Carl's VID, not unless R3 GUI can do 
anything usefull. I don't care for look now, but correct system metrics, 
closer to typography rules, are always welcomed. The screen forms 
should look relaxed. E.g. I was lately suprised, that I tried some 
Air app, and it was unpleasant experience in that regard ...

correction... looks are VERY long to get right.  the slightest change 
in one style, has repercutions on all others.

a 5% color difference can completely fix/destroy a style.

Henrik - are you trying to suggest, that scroller will not exist 
as a stand-alone style, and that you will not be able to attach it 
to other style, like Carl's VID? While I really don't like it, if 
it is that way, I at least hope that the code is reused, and not 
hardwired for any widget, which needs scroller, once and once again 
...

Pekr, R3 is still in alpha stage. There are going to be changes in 
Rich Text Dialect, PARA handling will be different from what's it 
now, so focusing too much on look right now would mean wasted time.

Yes, and that is exactly the thing we are missing - the big picture. 
Noone said there's anything wrong with Rich Text, para handling, 
etc.

Pekr, as I see it, it's not necessary. If you want a specific style 
with and without a scroller, first write the style without the scrollers. 
Then write a new style with the scrollers and appropriate scroller 
code attached. Very easy to debug and maintain. I know the convenience 
of "oh, I'll just throw in a scroller right here", but the code behind 
that is a nightmare to maintain for different types of scrolling, 
because it has to go both ways and some styles have very particular 
ways of handling scroller behavior that is not easy to resolve with 
actors alone.


I assume Carl added this, because he didn't consider the implications 
of adding scrolling to other than a pixel based area.

but that completly sucks :-) Even Windows 3.1 IDE builder allowed 
you to add scroller right next to the area, even if you had to connect 
its behaviour by corresponding code.

The problem with original scroller is, that is was 'too smart', it 
was scrolling area it was attached too. That may seem like a good 
idea at first unless you don't need the scroller to do something 
different like instead of setting area's offset, you need to change 
e.g. text's scroll. So right now the scroller just returns value 
and the style needs to handle that value by itself.

connect its behaviour by corresponding code

 - That's what we do per style, rather than shoving 5-10 different 
 methods into scroller.

You still can attach scroller to any style, but if the style has 
no code to handle scrolling, the scroller will just sit there, doing 
nothing. That's a good thing, because scroller cannot know how to 
scroll all styles it can be attached too. Carl's scroll did this, 
but all the styles must have supported only the one method of scrolling 
the scroller was able to use.

Change text's scroll? That would be the work for corresponding on-scroll 
handler for particular handler, no?

for particular style I mean ...

Pekr: "Noone said there's anything wrong with Rich Text, para handling" 
- that means only that noone has looked at PARA deeply enough. It's 
hardly usable the way it is now.

I don't understand! Scroller can do only following work - move slider, 
set slider size, react upon mouse-over. That is all. And scroller 
will never do anything else. The rest is the work for corresponding 
style on-scroll handler, which can do whatever is needed for the 
style ...