World: r3wp

Shadwolf - this is not the right group to discuss advocacy/strategy 
kind of things. But here's my take:


- RMA is a commercial entity, and Robert made it clear enough - they 
develop GUI to the point, when it will be usefull for their business 
apps. The chances are, that if it is good for them, it will also 
be good for others


- Robert is a good guy! He pays several top community guys, and - 
he gives result of such work - FOR FREE!


- RMA guys are VERY open, to listen to other's opinion, it is just 
they will accept only REALISTIC proposals - trying to convince them 
to change to differet underlying toolkit CAN'T work at this point. 
Even if such a toolkit would be good time solution, there are no 
free resources to make such a big change


- RT (Carl), plus the community, should be gratefull, to have at 
least RMA's GUI, if there is not other gui in the spot, and RT itself 
is not active in that regard.


- If I should name at least something what I am not considering so 
optimal, then it is a bit of a closed nature of development. I mean 
- I might wrongly understand initial impression of a SCRUM model. 
I missed the big picture, plus particular reports ... but - ANYTIME 
I was not lazy to ask, my questions were answered. Anyone but me 
can do just the same - ask. This is called - communication :-)

So much for RMA and their relation to development of R3 GUI ....

As for the move to other toolkits. Reading some of your opinons, 
and not being good in low level details, I still dare to say, that 
you might get some things wrong. There would be imo no direct benefit 
in moving R3 Graphics to GTK+, Qt, etc. Most of those toolkits are 
just bigger. You also seem to overrate the difficulcy of porting 
View to different platforms. Just look at Steve Solie - he did Amiga 
port in nearly a no time - one month? Noone imo expected R3/View 
running on Amiga. All is needed imo is - free hands, knowledge, and 
will to do the port.

It would be nice if Cyphre would isolate platform specific layer 
of gfx, but that is what I understand from one of his latest messages 
he is going to do  ... then the porting should be even easier.

Ok, except that the power of REBOL was that it can run under 40 different 
OS !

Nowadays, it runs good for R2/View under Windows and MacOS... Linux 
lots of problems because there's so many version of Linux...

And for R3/GUI we have Windows version... and when Windows 8 will 
be released... not sure it will work.

Community has falling down and it is hard with no open source to 
attrack new developpers... I know host-kit is hybrid open source 
model...

Real question in 2011 is : port language on JVM because every computer 
and device (except iPhone) has a JVM in order to reach the mass market.

Make it popular and then we can found money, people to work on small 
VM that make the power of Power.

Used MDP to generate docs. Not optimal, but at least something. What 
I did was:

- replaced =image-code by =image
- shortened path, as images are just in the same dir as doc

- gui-panel-sizing-3.PNG should be renamed to gui-panels-sizing-3.PNG
- gui-panels-visibility.PNG is missing

nve - Rebol View never run across more than 3-5 OSes - Windows, Linux, 
Mac was always incomplete, Amiga R3 1.2.1 was last supported IIRC, 
maybe BSD OSes, dunno.

I expect R3 being ported to JVM would be - slow. Carl can compile 
R3 library to the target OS in almost no time. The problem is the 
rest - OS dependant stuff - and this IS actually open source. It 
needs to be ported to target system no matter what ....

Not sure it would be slow. Groovy++ can overperform Java and both 
are running on JVM.

Scala can reach the performance of Java. Computers are now powerfull 
enough.
And device too, Android SDK is Java.

What is the point, if you as well can be native?

Pekr native is a pain that's all ... it took already 5 years to do 
rebol VM version 3 on windows 32 and it's not over and according 
to the source code of r3-host-kit there is no GUI part in linux or 
macOS X.. we don't know either if more than the 3 main os will be 
supported and in what extense. Doing a change on 1 VM  means finding 
a way to do it on all other VM that's why if i remember well along 
the years R2 was supported on lesser and lesser OS and that's why 
too the rebol VM source code grow to a point that it was impossible 
for Carl to maintain it .That was the main justification for the 
retrofiting of Rebol VM  in the rebol 3  project... mean while all 
the  industry changed can you seriously say that  java vm is the 
same now that it was 5 years ago same goes for mono.

Industry has move to the cloud, so we have to focus IMHO on the language... 
and RT must offer cloud Services... 

and when you reach the mass market you may consider to built small 
VM for specific OS... 

RT has fail his idiom to be portable on over 40 different platform... 
and worth of that is REBOL has no VM on iPhone, Android, Symbian, 
or WebOS... 

even if R3 and with host-kit in theory you can do it, who is going 
to do it ?

You seem to be assuming that it will never happen. Why not entertain 
the idea that it will happen?

Nicolas, those 40 different OSes weren't really 40 different OSes, 
they were mostly different builds for at most a dozen different OS 
variants. Most of those OS variants are now no longer developed, 
or have changed so significantly that they are essentially different 
OSes now. The platforms that RT is actively supporting now for R3 
covers the vast majority of the current market, more than would be 
expected for an alpha product, and the host kit allows you to port 
it to the most obscure OS you want, as long as it can work on the 
scale that REBOL works at (not your microwave).


every computer and device (except iPhone) has a JVM in order to reach 
the mass market

 - Of the most popular smartphone platforms, only RIM and Symbian 
 (sometimes) have a JVM; iPhone, Android, WP7, and WebOS don't.

Aside from PCs and smartphones, there is no mass market that REBOL 
can fit into.

perhaps some embedded hardware, though.

anyone seen or heard from Bolek? he has not been around since wednesday.

I can see him from time to time on Facebook, but right now he is 
not there. I believe Cyphre has his cell phone  ...

One naming tip - I noticed, in button.r3 source file for e.g., that 
we started to use multiple draw blocks? That's good. So - e.g. clicker 
style has two draw states (frames) - normal, and focus. Just a question 
- does "normal" sound good in english? Shouldn't be "default"?

Cyphre tried to call him, but no response.

we started to use multiple draw blocks?

 - they've been there for a good while now. :-) regarding naming, 
 I think it should reflect the specific state, rather than having 
 a "default". I usually prefer 'up, 'up-hover, 'down, etc. This is 
 easier to map to a state machine.

Thanks for new relese!

I have one qeustion towards "faced" attribute. In fact I liked it 
- it clearly distinguished attributes, which are meant being local 
to each instance of the style. Could anyone elaborate on why it was 
deprecated, and how is such functionality replace in new release?

Pekr, in the older version there was FACED and FACETS definitions 
which in the end(during the face creation) got merged so we decided 
to use only FACETS for now to make the style definiton simpler. In 
fact almost every programmer who tried to dostyles got confused why 
there is FACED and FACETS(and noone really know the reason why it 
is there). So from now it's easier and every face attributes are 
defined in one place - FACETS.

I doubt it is a good decision :-(

then tell me why?

In fact in R2 I always wondered, what influences all instances, and 
how do I prevent sharing of stuff. So in R3 Carl introduced 'faced, 
which made obvious (at least for me), what is style local = not shared 
between instances.

I think that every novice, when trying to change e.g. button color/border, 
find himself in a situation, when he influenced all buttons, etc. 
It was because direct path modification vs using make for subobjects. 
That is why I welcomed the move to declarative style definition, 
where the distinction could be made ...

Or am I missing something?

try this:

load-gui
stylize [red-button: button [facets: [area-color: red]]]
view [
	red-button
	button options [area-color: green]
	button
]

I think this wirks just fine no?

The faced block is similar to facets block, but makes them local 
to each instance of the face. Now, they can be modified without effecting 
any other faces that are of the same circle style.
 It is taken from: http://www.rebol.com/r3/docs/gui/styles.html

Why Carl introduced it then?

In fact this never worked correctly in the old Carls version IIRC.

In our version FACETS are 'local' to each face instance. To use shared 
properties(among the instances) you can specify INTERN block in the 
style definition.

OK - so - is there a need to distinguis local vs global style settings? 
Because in fact, I think that pushing user to use make edge [] just 
to prevent sharing, was pretty much crap in R2. That should be avoided 
if possible, as it creates burden on a user to know, that subobjects 
are shared in REBOL.

what's intern?

OK, I will try new version, and see how it goes. I would welcome 
an example on 'intern, maybe I will find it in sources. Starting 
to warm-up to new gui :-)

As I said you can use the INTERN to store shared (static) variables 
among all face instances of the specific style.

faced/facets, I like that it's gone. I never really learned what 
the difference was. That introduces sloppy coding, when you don't 
realize it.

Henrik - then you never read docs :-) Old docs are removed from wiki, 
but when I first saw faced, I reacted like most ppl - what is that 
good for? Then I read an explanation, and the difference was very 
obvious to me ....

Cyphre - any quick example of inteern? Just:

intern: [area-color: red] ???

I also remember the discussion with Carl, if we should change naming 
- e.g. attributes (attr to be shorter), local, global ... and in 
the end I liked faced :-) I can live with intern - it just reverses 
the aproach - it creates all facets instance-local by default, and 
shared stuff should be stated explicitly, right? It just might mean 
more memory consumption, but I don't know how much :-)

yes, that is enough...then every face of the style will be access 
face/intern/area-color as shared value

(but this will be used mostly by internal style code, that's why 
we called it INTERN)

ok, then I like new aproach more ...

BTW what was the difference if you had:
faced: [area-color: red] ?


In the end the 'area-color was local to each style as well in face/facets. 
In Rebol you cannnot have mixed 'shared' and 'local' values of direct 
type in one object together.

(the only way how to make 'shared' values is using indirect values 
(object! string! binary! block! etc.)

I think that the difference would exist in the dialect translation 
phase, when new style is instantiated? If there is 'faced, it would 
be in object field, whereas where in facets, it would be in some 
subobject = shared.Well,but then I don't know, how accessor would 
look-up style attributes, if those would exist in two places, but 
you have to somehow solve it with 'intern too ...

Don't loose your time with further explanations, time to read sources 
and do few tests ... some things will become obvious, some not, and 
then I''ll ask ...

From our expereinece with R3GUI styles, properties that user should 
easily access (like colors etc.) are meant to be usually local to 
each face inastance. That's for what FACES are good enough. If style 
creator think he could 'save' some memory by using shared values 
among faces of the style then he(she) can use the INTERN 'shared 
context' as storage.

BTW how is the R3GUI demo conversion is going? ;)