World: r3wp

Pekr, regarding the Box-model: did you read

http://www.rm-asset.com/code/level1/r3-gui/resizing/

, where the box-model description (needs update!) is?

To recap:

- Kaj has reported crashes of a111 on WINE, both RMA's and Jocko's 
builds. He doesn't use Windows, the supported platform.

- RMA needs to update its modified date for r3-gui.r3 when it changes 
its component parts.

- Jocko now knows his build was outdated, and has likely updated 
it. This will solve the additional Jocko build problems.


- Ladislav, please note that Kaj's crashes with the RMA build were 
WINE-related. Only later did he try Jocko's build. Testing on WINE 
might help.

- Kaj, please try demoing on Windows if possible, and if you aren't 
too annoyed to demo the RMA GUI stuff.

Could the RMA build be updated to alpha 111? This all started because 
the release notes of alpha 111 said that R3 was now compatible with 
the RMA GUI, but RT's build is a core build. This is why Jocko had 
to compile his own build from the alpha 111 host kit.

the change log for A111 does not claim such a thing

Agreed, but that is how "The most current graphics library changes 
have been included. Many thanks to Cyphre and the RMA project." was 
interpreted.

The update is planned for the next Friday, or later (some changes 
are on the way, and Cyphre was sick, planning originally do make 
some adjustments, so we do not expect to post an update sooner).

Could we be pleasant to each other ?  This type of sniping is becoming 
worse .. though I gather stress can causing this.

I've been in this community from the very beginning .. this has only 
started to happen in the last year or so

( ignoring evolution threads )

Ladislav, thank you for the link http://www.rm-asset.com/code/level1/r3-gui/
. The point is that this link is a presentation page, referring to 
a second one (downloads) which at last leads to http://www.rm-asset.com/code/downloads/files/r3-gui.r3
... the link that I used from the beginning. And so far I have no 
means to check if the file that I use is the latest one. Are you 
sure from your side that this file has been updated, and corresponds 
to the version issued 28th, january ?

Brian, thank you for your clear recap and action list.

After checking, I confirm that the version that I used is different 
from the version presently available at this url. I will do a first 
trial with the new version (but probably not an extensive check).

>> probe info? http://www.rm-asset.com/code/downloads/files/r3-gui.r3
connecting to: www.rm-asset.com
make object! [
    size: 263986
    date: 2-Feb-2011/9:31:04
    type: 'file
]

good idea !

watching out for caching by ISPs.

Pekr, Kaj :

checking, and modifying the code. In some tens of minutes,I will 
put a new version, with the latest r3-gui.r3 version. Later (in some 
days) I will go more deep in the non working tests.
Pekr, thank you for the doc patch : it works

Thanks

just posted an updated version of the test-demo (version 0.3.0). 
It includes the latest version of r3-gui, dated 28-Jan-2011.
http://www.colineau.fr/rebol/downloads/tests-R3Gui-3.zip

Brian, I don't have Windows. My life here is hard enough without 
adding that back into the mix

Kaj, please test it under wine ... and then focus on ReBorCon ;-)

Yep. Brian, in any case thanks for your constructive summary

RMA seems not to understand (or it is not its priority) the importance 
of visuals

 - That is not correct. The visual design is prioritized exactly where 
 it needs to be: When the architecture is settling. It would be *crazy* 
 to start doing skin work now, as styles are changing all the time. 
 I once fell into that trap on a project and spent 6 months redesigning 
 the same skin and in the end, we got nowhere.

Is the way of how styles are being drawn compatible with Carl's GUI. 
I definitely request scroller being progress + arrow button based, 
as I have goose bumps looking into the recen one, which has to come 
from different planet probably :-)

I mean - Carl's scrollbar was nearly perfect, is there any easy way 
I could port it?

You mean Car'ls scrollbar in R2? Because the R3 version is one big 
draw block, AFAIR.

I definitely request scroller being progress + arrow button based

 - I suppose you mean slider instead of progress? Anyhow, I'm not 
 sure that's likely to happen, as a slider is not the same thing as 
 a scrollbar and there would be too much code needed to write both 
 so they fit together.

no, taken from Carl's gui. How the hell scrollbar can be 16pixels, 
whereas progress is 22 pixels? It look like Mac OS-9 relic of the 
past, and is completly off with the rest of the design? I want to 
have it fixed, before I go mad :-)

I'm not sure any of that makes sense. Sorry. :-)

Progress is even *less* compatible with scrollbar and would take 
even more code to fit into scrollbar.

My opinion is, that design wise - scroller could be just progress 
+ 2 arrow buttons. And that is also where I am not sure about your 
aproach. It is clearly visible, that you are not using compound styles? 
Why scroller has different arrows from arrow-button?

scroller could be just progress + 2 arrow buttons

 - and that won't happen, because it's an inflexible solution, when 
 we start working more seriously on the skin, where each arrow will 
 likely have individual draw blocks customized for each direction. 
 It only works in simple GUIs like VID, where the appearance is just 
 a pixel edge and some flat shading. In that sense, it might make 
 sense to have a separate arrow style, but it won't work here.

well, the fact is, that we have separate arrow-button, no?

... and it has to solve the shadows anyway ....

view [progress 50% slider scroller] - try this code to see what I 
mean ... and try the same code in Carl's gui. What is wrong with 
his scroller? It looked much better.

we have an arrow style?

yes :-)

I don't see it. What's the name?

view [arrow-button]

I see. But the result is the same. You are too focused on the appearance.

If we don't reuse the code, then I wonder, if we have not failed 
design wise. Because then it leads to reimplementation of arrows 
for each particular style, and then no wonder that we are in a messy 
situation, if each style uses different arrows?

We reuse the code when it makes sense. In this case it doesn't necessarily 
make sense, because an arrow is a rectangular button with a particular 
draw block. There is no gain in trying to cram it into the scroller 
style, because skin-wise you will need to adjust it anyway, which 
is more code. That may not be the case in the finished scroller style.

ergh... delete the last sentence.

ok, then appearance wise, it should use identical draw blocks? E.g. 
in Windows apps, arrow is arrow, being it part of drop-down, spinner, 
scrollbar - still the same style?

it should use identical draw blocks
 - you can't count on that.

I don't necessarily want styles being somehow magically compound, 
if the only thing you need is to use a draw block, and in fact "integrating" 
multiple styles together is even beyond my imagination technically 
wise, but I request identical visual representation ....

OK, different qeustion - how is materials influencing draw block? 
only via parameters?

identical representation may not make sense, but again, you are probably 
used to only using Windows.

Because I am thinking into looking into Carl's scroller, trying to 
replace RMA's draw block. I wonder, if it could break because of 
material system, or would it work?

In the draw block, materials are gradients and colors, so they are 
only color and gradient parameters to draw primitives.

Hmm, I don't have Carl's styles available :-(, only some GUI related 
code. I wonder if it was ever available.