World: r3wp

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

Many questions are put here unnecessarily by me. If app like deme/style 
browser would be working, I could see example usage, instead of looking 
into flattened source code. You live with the sources on daily basis, 
so you might understand, that I would like to help with testing, 
but without any instructions it just might generate many questions 
on my part. I might stop complaining about the look for now, but 
that's all I can save you from :-)

Actually, I'm very glad for your bug-reports, they're very helpful. 
But discussing all that "big architecture stuff" just keeps me from 
fixing bugs. That's all.

pekr... you seem to miss the point that no one is saying it is finished. 
  most of what you point out seems to be readily obvious.


give them a break, they are releasing as a curteousy since it helps 
make it obvious that its progressing.

OK, I can test personally. In the past I worked privately for Romano, 
Cyphre. We can concentrate upon some more concrete stuff. You can 
say just few points, like - new area, please test. And I will do. 
Recently Henrik releases new version without telling what has changes, 
just 21KB was added :-) That is really difficult to estimate what 
changes should be tested :-)

Releasing often is a waste of time.

The appropriate way is to have a public repository

And testers pull the source down.

They can diff the changes and not wonder what that 21kb was that 
was added.

public repository is not likely to happen, as RM Asset keeps private 
sources in the same repository as the R3 GUI to accommodate private 
projects and build system, but I will continue to release the r3-gui.r3 
file until a better arrangement is made.

We release often and I think we should continue to do it but it helps 
a lot if we just focus on the stuff that is there, and not the stuff 
that is not there.

Petr, a lot of your points are valid and have been discussed several 
times. Nevertheless, we need to do it all.

And, let's make a test:

How want to work with the RMA team on the R3-GUI? By work I mean, 
really getting something done. Writing code, styles etc. not discussing 
generic, high-level architecture stuff and future things to do.

How0Who

0== ;-)

And by work you mean paid?

No, because this will than become a community project. I'm going 
to pay the RMA Team, which is than indirectly a sponsoring of the 
R3-GUI project for the community to keep the momentum.

*want* = yes

*can* = only sporadically.  Tough I'll make it a point to make integration 
of my research stuff into yours (so I guess that counts as working 
*with* you :-).

(like I did with testing of the custom renderer in r3 gui)

Henrik -- FYI: Can you confirm an odd behavior for me?  Whenever 
I minimize a panel and reopen it, it works as expected.  When I resize 
the object to a bigger size, minimize it, then reopen it, I get a 
weird strobe effect of the two panels, one the original size and 
then the other at the bigger size.

At least for Win XP SP3

Patrick, can you post the layout you are using?

Hi Henrik, I'm back -- Very odd, now I can't repeat the same results. 
 Resizing is NOT causing the strobe effect that I witnessed before. 
 In any event, that suggests it was something else -- not related 
to your code!

I'm not able to produce it either.

Robert - I can't work with RMA team by writing code etc. My primary 
job makes me come home between 18:00 - 20:00, then I have another 
company where we run 700+ wifi users, some other projects. I am not 
complaining, I like it :-) It is just that a) little of free time 
remains b) you would not want my "code" to oficially accept :-)


But - I don't necessarily be the one, who just talks. Give me something 
specific to test. I think I now will find my way with Henrik/Rebolek 
on my own. It is just the current release format (flattened source) 
is a bit uncomfort to study code segmentation and separation, and 
- difficult to know what changed, if there's no changelog. (I know 
I could use diff on 256kb source, but ....)


So - I think I will let it as it is - it is enough if e.g. Rebolek 
says just few words for the release - e.g. - please test new tab 
... and I can look at it, and givi it a run ...

Ok, that's a good start and helps us.

We are still buildin a bunch of infrastructure on our side, so that 
we can release stuff faster, know it will build for you, generate 
automatic change-logs etc.

Style browser as it looks right now:

http://94.145.78.91/files/r3/gui/241.png


Second validation prototype test window. The use of multiple draw 
blocks still doesn't work, so I'm resorting to funky yellow text 
fields to indicate validation state:

http://94.145.78.91/files/r3/gui/242.png

Good to have at least something visual! As for use of multiple draw 
blocks - is it feature which is going to be implemented? I remember 
when Carl did VID 3.4, it was not plan. But I could not understand, 
how else some more complex styles, could be built, displaying various 
states, which are not easily doable by only parametrisation of one 
draw block. If it is planned, it is a good news.

Yes.it will be definitely supported.