World: r3wp

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 ...

Yes exactly. That was the scroller is doing right now, but it wasn't 
case with old implementation.

That was = that is what

Yes, so the only thing I miss now is, that scroller could be placed 
on the form, not doing anything :-) Or how would you do style browser, 
for IDE purposes for e.g.?

I mean - view [scroller] should work ...

as I said, it's not working right now becasue the re-implementation 
is not finished.

I'm starting to think that this "release often" strategy is not a 
good idea at all and a waste of time.

good then. One other thing - I am seeming table related styles there, 
which surely are not displayable on their own, yet those are legitimate 
styles - table-row, table-cell, table-header ... that is why I think 
we really need get-styles or similar function, which depending upon 
the tag, would get you list of only ready-to-use on the form styles 
... but that can come later ...

Table doesn't work because it's old version done before new resizing.

Rebolek - I will be harsh, but others might feel, that what is waste 
of time is lack of communication and providing big picture. You accepted 
SCRUM methodology, but only for your team internal purposes. The 
rest of us knows nothing about what's happening at particular levels. 
If you stop informing ppl, then the only thing we would know about 
the GUI would be, that team of 4 ppl are working on it for 4-5 monts, 
with no visible result. Ppl are very eager to have GUI.

It took me 5 minutes, to find area style misconceptions/bugs. If 
you are not ready to accepts comments/critique (CC), then just don't 
release. But then don't wonder, if ppl will not accept the way GUI 
turned out, if you keep it private for 1 year ....