AltME groups: search

So much questions, great :)

I want freaking to change the color of the scroller
 - If not possible right now, it's bug and will be fixed.

How do I 
destylize" panel for e.g.?" - use material NONE

What is the correct way to call an actor?

 -  do-style FACE [object!] ACTOR [word!] DATA [any-type!] ; for example: 
 do-style face 'on-update none


how can I recognise, what arguments particular actors should obtain

 - good question. I have some ideas how to solve it, but right now 
 you should ask or study source :)

How can I properly attach scroller to progress bar?

 - In your case it should be auto-attached and 'attach shouldn't be 
 needed. Maybe 'attach doesn't work at the moment as the auto-attaching 
 of scrollers is actually a very bad thing that brings more problems 
 than it solves.So ATTACH is going to be reviewed and fixed when necessary.

I really wonder, if R3 GUI sees ANY regular development?

 - It does, but the developement does occur in areas you're probably 
 not interested in (GUI internals, TEXT-TABLE...)


Recent R3 GUI status is, that it is not usable for more than simple 
dialog box
 - Typical Pekrovina ;)

- Rebolek - if a button and field are enough for you forms, than 
yes, GUI is usable for a real-life apps :-)


- do-style - OK, understood. I also found do-face in the sources. 
Is it relict of Carl's GUI, or is that function good for something 
too?


- actor arguments - Carl did so by simply put them in the comments 
of the first line, right after the left bracket. All it needs is 
imo a discipline, when writing styles :-)


- I am not much interested in attaching the scroller to progress 
bar, apart from getting demo ported. But - it surely should be allowed 
and fixed. I will ask different question here - how do I display 
scroller, with minimal sized knob?

Scroller attachment is actually a bad method as attachment code is 
rather complicated and error prone, hence it has been removed. Scroller 
will likely only be used where it makes sense. Better to use SLIDER 
later for demoing things like this.

Pekr, the reasons for why things should or should not be allowed 
is not for ideological reasons, but results of many hours wasted 
on trying to make such attachment code work and failed.

ATTACH is useful, it's just auto-attaching that isn't that great 
idea. If ATTACH doesn't work, it's a bug and will be fixed.

Ultimately a scroller and an item to scroll has many subtleties that 
you don't notice at first, such as step size, whether you want smooth 
or non-smooth scrolling, and the structure of the item to scroll, 
and whether you want separate behaviors for vertical and horizontal 
scrolling. Then there is also placement of the scroller. Do you want 
the scroller to automatically "sense" what direction it has to scroll 
in?


All this means that the scroller should treat each such case as a 
special case and you can't ask a style developer to meddle with attachment 
code inside the scroller style to deal with this issue. It's better 
and simpler to have a "dumb" scroller that will do your bidding for 
your style.


It "works" in Carl's demo, because he only has 1 or 2 cases to work 
with, but it doesn't really work that well. He never implemented 
tables, image-pans, icon lists, chat lists, maps, browser windows, 
etc.

Yes, replacing SCROLLER with SLIDER works well and is better in this 
case.

Usually when you work with IDEs, you are able to choose scroller, 
and the know size is at the minimal position, not at the maximal 
one, imo ...

What is the situation with compound styles? When you e.g. design 
scroller - is it a mixture of two styles? Slider (in old gui sense) 
+ arrows? I mean - if we have arrow style, and you will use the arrow 
in some compound style, then when you change/restyle arrow, will 
it change also inside of compound style?

SCROLLER is not compound style and arrows are "hardcoded".

Well, the STATE object is for internal parameters that shouldn't 
be changed by user... We got rid of FACED already, as it was only 
causing confusion and wasn't solving anything. STATE will probably 
stay, but various words may be rearranged and moved between STATE 
and FACETS.

My secret plan is that SET(GET)-FACET should one day probably work 
as SET(GET)-FACE/FIELD but currently there's only one style that 
supports fields, so this will take time.

I think the original idea was that user should always use SET(GET)-FACET 
for accessing values and should pretend that FACE/STATE/... is impossible 
to do, so STATE would stay internal and inaccessible.

For better understanding of material system. I can see code like 
this:

		material: 'scroller

		area-color: 200.233.245
		edge-color: 0.0.0.128
		arrow-color: black

		area-fill: 
		over-fill: sky
		down-fill: coal 

And late in the on-make, this:

			; Prepare materials
			make-material face get-facet face 'material
			set-material face 'up 

Questions:


1) why are those  facets being set? Is it just that you need to give 
them some initial value? Is my understanding correct, that during 
on-make, those values are being overriden? Most probably not, because 
materials field hold up/down/over values.


2) is material system sufficient, if it holds only gradients? It 
should imo hold all values, which might influence the design of the 
widget. And hence even bare-bones colors. The question also is, if 
draw-blocks shold not be part of the material system too, because 
my impression is, that so far, it does very little to be any usefull, 
and the difficulcy to understand the whole concept might not be worth 
the effort.


3) There is an architecture discrepancy - materials do use central 
storage (kind like old VID kept 'feel actions block together - nice 
idea, but really not any usefull, and VID2 design mistake imo), while 
draw blocks are contained per style definition. I think it might 
be wise to think about moving materials: [up [] down [] over[] ] 
slots to the style definition itself

As for fields - what you are trying to say is, that just recently 
set-facet uses only direct assignment method, and what you want to 
achieve is set/get accessors, doing more stuff? What would be the 
usage syntax?

I am going to suggest the rename of do-style and do-face. Those names 
have absolulty no sense. DO-ACTION, DO-REACTION would be better one 
imo ...

You must define map! with code for each field (two map!s actually, 
for get- and for set-). Unknown fields are ignored. This way you 
can also very easily get overview of what's possible to set(get) 
in particular face.

...rename do-style and do-face. Those names have absolulty no sense
 - Yes, I agree that those names aren't very good.

I am about to write CC ticket for 'options. There is naming discrepancy 
here, as well as I think, that those things could be made declarative, 
and move inside the style definitions. Ditto for materials ...

I spent a bunch of hours in the code, and thinking about the architecture, 
so hopefully you don't dismiss them in 10 seconds :-)

current behaviour allows inlined set of init-set, which has no effect 
though, and hence causes user confusion 

 - that is not true again, since the user can examine the INIT-SIZE 
 attribute, he can easily find out, that it has been set as specified. 
 What was not set (and not specified) is just the MIN-SIZE and MAX-SIZE 
 values.

- allow max-size override. If user requests 400x400 button, which 
exceeds max size in x and y axis, set new max-size to that value. 
The argument that that might not be eventual max-size user might 
imagine does not hold any water. 

 - as said, MAX-SIZE shall be independent from INIT-SIZE. What I do 
 want to preserve is the independency between INIT-SIZE and MAX-SIZE, 
 since that *is* needed in reasonable cases.

To not be misunderstood:

- everybody is allowed to set INIT-SIZE howewer he likes
- everybody is allowed to set MAX-SIZE however he likes

- nobody is allowed to ask me to be more clever than him and to "correct" 
(read: "mess up") the MAX-SIZE for no reason, in fact

There was very long discussion, towards if we should allow to change 
the size of the button to allow any size being set" - did you really 
mean it? One can easily make sure, that the init-size of the button 
is set as specified." - Yes, I meant it, because IIRC there were 
opinions, trying to suggest here, that it should not be allowed at 
all :-)


All stuff you write - I know. It is just that I might not necessarily 
agree with the outcome. I am trying to think form user's point of 
view. I wonder to what points you would agree, and to what not:


- Let's assume I set button in bounds (between what min-size/max-size 
allows): I tried various scenarios, and I almost never got button 
of requested size. The reason is in how resizing system works. In 
fact, when inspecting various sizes - init-size, min-size, max-size, 
those don't contain actual button size. Actual size is in face/gob/size. 
Button gets different size due to resizing system cell alignment 
imo. From the resizing system point of view, it is correct behaviour, 
but from the user's perspective, it is questionable, if the result 
is OK?


- In regards to above point, I really wonder, if buttons should be 
resizable at all. I said - resizable, not settable. I wonder, if 
I would like buttons to be of consistent size. I might try with face/resizes?: 
false, if that would make the trick.


- Then, in regards to above - I might think of init-size setting 
the requested button size


- Maybe (and I am not sure about that one), we could allow some debug 
info - "out of bounds", if my init-size value does not fit in between 
the min-size, max-size, as style author defined it. I have heard 
that guys are working on some field accessor functions - those might 
be able to print some debug info to console, at least when in interactive 
mode.


Othere than that - this one is a minor issue for me, I e.g. care 
more about architecture, and so far I can see materials having real 
low benefit, for how complicated it turns out ...

My opinion is, that noone will be ever able to work with materials 
in any gfx tool. So for me the central material storage is a wrong 
decision. The same as it was with Gab's GUI to have central storage 
of skin and look. At some point, it makes sense, yes. But otoh, I 
prefer the source readability, and I think RebGUI was better, keeping 
stuff related to one style together.


What is more - we keep style draw "frames" at the style level too. 
I would like materials to move in the style too. I don't expect having 
tonnes of material skins, to switch between.

Pekr, materials are inspired by 3D modeler tools, which work the 
same way, with centralized resources of materials. They use similar 
parameters to adjust the appearance of a material, which is lifted 
above the direct approach of manipulating colors. Materials are a 
way to have designer friendly methods for adjusting the appearance 
of a style quickly and to provide logical connections between the 
highlight, color and shadow of a style.

Henrik - I am not sure I am denying materials. I can understand the 
abstraction, although so far I can't see the PRACTICAL benefit. The 
reason is, that the whole "skinning" is overrated, especially in 
regards to REBOL. Because - can you take R3 GUI style, and open it 
in Photoshop, do some skin/material simulation, and have it being 
saved? If not, the idea of central storage, regarding it being kind 
of collection of hundreds of contributed skins, might not follow 
the reality :-) I wonder if there ever be more than one skin :-)

Hence - this is the reason I might prefer in-style storage.

They should exist, because they are words used by the draw block, 
I assume. But the specific colors should be set somewhere outside, 
and then you use materials to derive the correct color.

I don't understand - so color fields should be regular facet fields, 
but just settable by material system? And that is not implemented?

In the following document (images don't work), there was a way to 
show, how one can create complete style. No need to go outside the 
stylize. No imagine incorporating material system in there. First 
you have to know, how it works, so it is not enough to work with 
style draw frames, but you have to react accordingly in various phases, 
as on-init, on-draw. 


Then you have to go to completly different place, to define it. And 
that is breaking the workflow for me ...

1) Anyone yet has to prove to me, that having centralised skin/material 
storage will be practically usefull. What tool on Earth will you 
use to visually edit them? Imo none - we will have to come up with 
own REBOL based tool, which might understand all those draw defnitions 
imo


2) Having materials stored in the style (being part of stylize) means 
you can internally do whatever you want with it. In fact - what material 
system does in on-init style phase is, that it physically stores 
the material object into face/material. You could work even the opposite 
way - knowing the list of styles, you can collect all materials, 
if you need them to have in one place - what for, I don't know, maybe 
for some visual tool, where you will be able to tweak them ... one 
day ... maybe ... as surely Photoshop is not usable ...


The fact is, that having materials stored centrally is correct design-wise. 
But having to deal with styles, and based upon practical merits, 
having definitions scattered around lowers usability of the system, 
and easiness of understanding of system internals ...

Rebolek - yes, and that is why I prefer things having in one file 
per style ....

Even current source distribution is wrong for me. What would be cool 
would be system internal functions being separate. And all particular 
style functions being part of the style itself.

And all particular style functions being part of the style itself
 - what exactly do you mean?

I mean - there is an engine. And then there are styles. My idea (maybe 
wrong :-) is, to have one file per style, containing everything style 
related. Or at least having max 2 files. panel.r3, panel-funcs.r3. 
I just don't know - looking into style definitions is a disappointment 
for me - there is only few basic things, and there should/could be 
more. First things which come in my mind is materials, then options 
block handling, and I can imagine even functions: [] slot, where 
all related functions could be put.


I'll leave it where it is now, before the system is more complete. 
But later on, if I have a feeling, that there is some usability problem 
for users, I'll restructure the system myself.

No, because it is not of course true. What you show to user inside 
of stylise, is only part of the style. For some styles, as shown 
in the above link, it might be true. But when you start to add things, 
you need to go outside the stylize, and I would like if stylize would 
be able to contain everything, having following slots:

style: [
    about:
    tags:
    facets:
    options:    
    actors:
    draw: 
    materials:
    funcs:
]

Plus the naming of inline options, options block, and style level 
facets vs options - http://curecode.org/rebol3/ticket.rsp?id=1847&cursor=7
should be resolved too ...

Not exactly. Because in fact, there are both material, and materials 
words in the final face object. What I would like to see is the materil(s) 
word(s) for the style/stylize phase.

I don't see a single reason why code like option block handling should 
be part of every style, it simply bind words from options to facets 
and one function does it for every style.

Petr, maybe it helps when you think about "programming in the large". 
I like self-contained stuff too. It's simple and fast to use. The 
problem is, it doesn't scale.

Imagine 20 customers, all wanting their own branded version etc. 
with an externalized material system you just link in a different 
setup code and you are done.

One rule we follow with the GUI is, that everything that provides 
"additional features" should be plug-in able. If you want to use 
it, you can include it and you won't notice an artifical break. If 
you don't need it, don't use it.

I don't see a single reason why code like option block handling should 
be part of every style, it simply bind words from options to facets 
and one function does it for every style.

 - Rebolek - what function is that? I found that e.g. for panel, it 
 seems to be an init-panel function, which maps options block to facets. 
 And no, it is not about simple binding, it does more than that.

Robert - my long time experience is, that code reuse is very often 
being a trade-off. I can't even imagine, how you make new material 
for your new customer. You don't have any visual tool for that anyway. 
And I am not sure if I can if it is in separate file, or with each 
style. I can understand the plug-in mechanism, but I am just right 
now not sure, if it outweights the usability aspect. I simply remember, 
that I liked to use the AMOS basic. Because it allowed cool things 
rather easily. And if users like the system they use, they will use 
it, and extend it. And sometimes it is about how cleverly the code 
is organised. We will see, how it turns out ...

Show me other basic allowign rather easy animations, sound, and game 
creation :-)

their cow and camper racing game was hilarious  :-D

How on earth I define, in stylize level, how is options block mapped 
to facets?


Why do you want to do that? Let's say I want to write KNOB style. 
I can set for example it's value, color and size, so options would 
be something like:

options: [
	level: [percent!]
	knob-color: [tuple!]

 knob-size: [integer!]	; it's round, so diameter is enough for size
]


Then I can use knob-color, knob-size... in draw block without any 
manual mapping.

And because style has 'options block, which maps to inlined parameters 
("OK" string in above example), what I am claiming is a name clash/confusion 
here ...

I can rephrase the question - how does user define, creating a style, 
what might be declared in an options block (dialect level, my-field: 
"test"), and how is such options block being evaluated, and values 
being assigned to facets?

Let's assume I set button in bounds (between what min-size/max-size 
allows): I tried various scenarios, and I almost never got button 
of requested size.

 - yes, the size is always a result of resizing rules, as applied 
 in a specific style. There are two methods working quite differently, 
 the first one is used by vgroup/hgroup, the second one by vpanel/hpanel. 
 If none is what you like, then there is a possibility, that you would 
 like to have a completely different style, with different resizing 
 rules...

- In regards to above point, I really wonder, if buttons should be 
resizable at all. I said - resizable, not settable. I wonder, if 
I would like buttons to be of consistent size. I might try with face/resizes?: 
false, if that would make the trick.

 If you set the RESIZES attribute to OFF, you get a completely different 
 behaviour, than what you expect:


- the resizing algorithm will leave the button untouched, which means, 
that it does neither compute the position, nor the size, and the 
button would just "float" - the next version will contain more than 
20 different examples, Cyphre's visibility example manipulating the 
RESIZES attribute included


- if you just want the resizing algorithm to not change the size 
of an element, while allowing the resizing algorithm to compute the 
position of the element, you should do it differently. Just set the 
INIT-SIZE, MIN-SIZE and MAX-SIZE of the element all to the same pair. 
You will notice, that the size of the element will not change, no 
matter what, only the position may change.

Cyphre - what you just said says it all. I don't care for different 
context and word meaning, if those contexts are so close one to each 
other, that it might confuss users :-)

I think I understand the difference, but I was not easily able to 
see what is what, unless I studied it more deeply, and unless Ladislav 
told me during our meeting, that layout level 'options does not necessarily 
directly map to face/facets ....

- if you just want the resizing algorithm to not change the size 
of an element, while allowing the resizing algorithm to compute the 
position of the element, you should do it differently. Just set the 
INIT-SIZE, MIN-SIZE and MAX-SIZE of the element all to the same pair

 - this is the worse solution from the two offered, while more usefull. 
 I can imagine I simply don't want buttons being resizable. Then 'resizes 
 field does not express the meaning of the word, as in fact it does 
 not resize, but it also floats, which is imo not that much usefull.


In order to prohibit e.g. button from resizing, I need to derive 
the styles, and remove the init-size options from being set.

Hmm, you don't have to forbid setting INIT-SIZE. As I mentioned, 
it suffices to make sure INIT-SIZE, MIN-SIZE and MAX-SIZE are all 
equal.

Pekr, you said "layout level 'options does not necessarily directly 
map to face/facets"...that's why I don't want to rename OPTIONS to 
FACETS in the layout block. Also so far you are the only one who 
has problem understanding the 'options in layout vs. 'options in 
style definition and in fact you haven't proposed any concrete solution 
(evenin your CC ticket).

I'm not saying I'm against reasonable change here but since there 
is no good viable solution(and noone except you cares) we should 
 either wait until it pops out from someones head or just let it 
be as it is now.

Cyphre - let's be realistic - I am the only one, because in fact 
I am most probably the only one, who is investigating GUI in such 
a deep manner, if not at all. This is imo a result of bad RT's treatment 
of R3, which is bringing REBOL into isolation even further more, 
making less and less ppl interested with almost zero RT's action 
... and that's the reality ...

OK, and I think you are wrong too, and we can let it that way :-)


the fact that some options may be inlined (i.e. the name may be used 
in another context) does not change that in any way

 - yes, it does. So far I can only follow my brain logic, which simply 
 was confused. Well, I could admit, that I am dumb :-) But the chances 
 are, that some other ppl might be confused too, so my answer is:


- style/options does NOT clearly define, what options user can set 
in dialect options block, because that block, is SUPERSET of the 
style/options. It allows you even to define whatever word, without 
the word being a regular facet field:


>> view [b: button options [ble: func [][print "huh?"]] do [b/facets/ble]]
huh?


I wonder if that might even be a security issue, to pass such a function 
via the options block? So - how is that options block even closely 
similar to what style/options is? Those two have completly different 
meaning/functionality :-)

Ladislav - let's not just take it personally :-) For me, and as you 
can see, it is a good experience to experiment with the GUI, as I 
am gaining some internals knowledge. I published the tickets for 
RMA team to consider the consequences, and it is up to you, to react 
accordingly. So - if you guys feel that it is ok, then just dismiss 
the ticket, ad the comment there, and it will server for future GUI 
users as a knowledge base, that's all ...

This is part of Carl's original design and I imagine that he made 
the idea of "slots" as you call it, so there is a simple way to map 
grouped areas of code to faces, when they are created. Note in the 
source, the definition of a style and a face are right next to eachother. 
So it becomes "how do I create a face from a model of a face, as 
quickly and easily as possible?"

What Ladislav proposes is interesting, because it leads my thoughts 
even further, and then my concepts probably break anyway :-) Imagine:

style [
options: ; renamed facets
inline-options:
]


Because then writing "button "OK" options [field: value]" could lead 
users to think, that they are directly setting facets (options, if 
renamed), which is not the case either, as there is an abstraction 
in between the options and its mapping to facets. Besides that I 
think, that Carl would surely not like to give-up on facets name 
(although for me as non-englishman) the word has not meaning, although 
I know it exists in vocabulary ...

So, what he does is create an object that contains "slots" that are 
relevant to the style, and then another object with "slots" that 
are relevant to the face.

Yes, no problem if explained - just my thought chain was - how is 
that I can see some values being specified in an options block in 
a dialect level, which I can't see defined in style/options? That 
is all. If documented, maybe no confusion is going to happen. And 
maybe - not all ppl will think the way I was ...

You named them "slots" first, so that was the word I use, but the 
words you use there are distinctly different. because this is an 
attempt at creating a sane interface for the face. In VID, you didn't 
have that. There was one single object and it was flat, and therefore 
could become large.

I would not mind, if style/options would be renamed to args or params. 
And if it will unify with reactors, then - why not? I know that other 
pov might be, that those really options, just inlined. So - you can 
have RMA voting, as now you imo clearly understand, why I had the 
problem with the recent naming. Maybe you will decide that it is 
fine as it is, it's your GUI after all :-)

ARGS and PARAMS are ugly abbreviations of technical words. If the 
problem is that OPTIONS do not map directly to options in the face, 
it seems that WITH was the better name :-)

USING comes to mind too, but then WITH is probably nicer, and "compatible" 
with VID :-)

release date: Cyphre will not be available to commit a new release, 
and some scroller, etc. changes are on the way, so, the release will 
happen on Monday or Tuesday

OK, I am fighting for three weeks with this or that, and I feel like 
giving-up and going to health-leave too ... I should not have played 
a soccer yesterday :-)

This doesn't seem to happen if I load the single GUI file and write 
my own Hello World

And under Windows?

pekr, how is your attempt to port the Carl's demo ? I did some work 
on it, and I have some results, but I had to adapt some points. Some 
tests are not working.

yes, but with my compiled version, I load the RMA R3 without problem, 
and I also have done some adaptations of the Carl's demo

with the adapted Carl's demo, there are still some bugs . Some styles 
seem incompatible, and it's difficult to debug without knowing the 
bases of this design.

if you use a request function to display a message, this is the cause 
of the problem: the request function from RMA is bugged (and also 
the alert). You should either correct in the RMA r3-gui.r3 file, 
or, better, overload it. change the words group  by hgroup , and 
change the line doc (message) by text-area (message)

>> do %r3-gui.r3

Script: "R3 GUI - load and start" Version: $Id: $ Date: 9-Dec-2010/10:32:04+1:00
>> do %demoJC.r3

Script: "R3 GUI - Development Test Script" Version: 0.1.1 Date: none

Script: "R3 GUI - load and start" Version: $Id: $ Date: 9-Dec-2010/10:32:04+1:00
** Internal error: stack overflow

** Where: reduce switch parse to-text reduce parse to-draw all update-subgobs 
foreach update-subgobs foreach update-subgobs foreach update-subgobs 
show-native show-native show-native show-native show-native show-native 
show-native show-native show-native show-native show-native show-native 
show-native show-native show-native show-native show-native show-native 
show-native show-native show-native show-native show-native show-native 
show-native show-native show-native show-native show-native show-native 
show-native show-native show-native show-native show-native show-native 
show-native show-native sho...

to summarize: open a new cosole, launch directly demo:
do %demoJC.r3, and it should work ok.

This GUI and GLASS are also terribly slow

Pekr, we are by and large at the same point. Your version is compatible 
with the a111 version that I compiled, except for a certain number 
of tests, like mine. Did your version work with the a110 of RMA for 
the drawing test ?
Kaj, I agree, Carl's version was demonstrable.

Some basic functions like request or alert, and styles like doc are 
still bugged in r3-gui.r3

Some basic functions like request or alert

 - because they are an entirely separate scheme that is not yet implemented. 
 Carl's version of these were unorganized and lacking.

I have put a new version of test-demo, where the status of what is 
working and what is not is mentioned, and the crashing actions and 
faces are disabled. Pekr, I have not yet integrated your fix for 
the doc style ... later
http://www.colineau.fr/rebol/downloads/tests-R3Gui.zip

well, some of tickets are not clearly a bugs, but misconceptions 
... which most probably might get dismissed because of my incorrect 
understanding of the topic. But I wanted to have it "recorded". I 
just don't know, if RMA works with those tickets, as e.g. Doc style 
fix is not yet commented. I will wait for new release and we will 
see. Hopefully together we might get the demo working. I expect the 
biggest problem being in the area where new box model is involved 
... we will see ...

I agree with you. The point is, as there is not enough documentation, 
we may "translate" incorrectly the code. Anyway, I would be pleased 
to contribute with you to make this demo work, as I feel it very 
"sexy" and representative of the potential of the gui. Of course, 
RMA is welcome to do on their side this kind of demo, showing the 
various functionalities of r3-gui

Guys, I don't know how often I have to repeat it:


1. we get basic concepts implemented. All these basics are seperated 
as much as possible. That's why it will be totally incompatible to 
Carl's GUI. And, we don't try to be compatible. Our goal is to have 
an enterprise enabled GUI framework.


2. To do step 1, we just pick 1-2 styles, and enhance and change 
them exactly to just work with the concepts from 1. And, please see 
the plural in "concepts". We are doing step 1 & 2 by concept.


3. If this stabelized, we take the next style and adopt it. This 
might lead to some changes in 1. which than have to be carried forward 
again.

4. Then either next style or next concept.

It's quite simple. The GUI is not functioning in general purpose. 
Anyone expecting this is just pure wrong... you have to wait or help. 
And the concepts and styles we care are priorized by what we need.

I agree, that's why we bite the bullet and invest a lot of money 
into the development of a useable GUI framework. It's a hell lot 
of work as we mostly started from scratch, and need to fight on the 
c-level as well.

But it doesn't work. And you'll have great trouble getting back to 
a working state, with so many issues interfering. This alone explains 
the long time spans

Maybe it would have been better to have kept Carl's GUI as something 
that could have been used warts and all, .. and the GUI team continue 
to work on their alternate GUI?  Would that have been possible?

Graham, I guess, that you realize, that the original Carl's GUI is:

*kept and available

*maintained, the RMA is just the continuation of Carl's GUI, correcting/improving 
things that have been found necessary to correct

What exactly are you asking for, then?

If something does not work, it is just because what you call "Carl's 
GUI" is the old version, while the newer version of the code are 
(somewhat improperly) called "RMA GUI". Nevertheless, everybody crying 
for it, can easily take it and update everything that he sees fit.

Just making few notes:

1. we don't push anyone to use/accept R3GUI from RMA


2. anyone who is missing "Carl's GUI" can download it at http://www.rebol.com/r3/gui.r
and happily use and enhance it. (It really works much better than 
RMA version...especially with A111 :-))


3. Having 'good looking' demo doesn't mean anything when the system 
cannot be used in real application. (That was the first thing we 
realized when checking the "Carl's GUI" and that's why we continued 
to improve our own version based on Carl's design)

4. It has been said by defferent RMA-members:

-this project is still in 'alpha', we are working frequently on it 
to be better
-we are publishing/sharing our work-in-progress code
-we invite any good contribution to the wip code

So far the major reaction to our effort is none,negative or contra-productive 
here even from some people who have experiences with mangement of 
larger projects(*sigh*). I don't understand why.

This has of course nothing to do with constructive critics which 
we hear, discuss and think about every useful comment (even if it 
is not accepted in the end). Unfortunately we could count 'useful 
comments' in this group on fingers on both hands max.


5. even with all the negative energy that is 'pumped' on us from 
Rebol3 we will continue with releasing our work and inform people 
here about the progress etc.

Cyphre - just some friendly opinion exchange, hopefully you will 
be able to understand my explanations (which don't necessarily represent 
my exact point of view):


- most ppl here are well aware of the fact, that RMA is a business 
entity, and hence has absolute right to do what makes sense for its 
business. The trick is, that in the end, it does not work for ppl, 
I will tell why later.


- The point above is even more difficult to understand, as RMA is 
offering its work for free, yet ppl still complain to something (including 
me of course)


- What might have failed is, that ppl might think, that accepting 
SCRUM method will mean, that we have finally found a viable model 
for  general R3 development, which will allow Carl to stay available 
 to small agile team of developers, isolated from the noise.


- Ppl were expecting GUI to probably appear in 2-3 month period. 
Althought Carl's GUI worked mostly on the surface, it was something 
ppl could experience. RMA's aproach is much broader aproach to usability 
and architecture. But - that resulted into refusal to provide usable 
demo. There was some attempt to provide style browser, but it was 
highly unusable to attract ppl.


- RMA seems not to understand (or it is not its priority) the importance 
of visuals. You surely remember the "design sells" claims, which 
are know for ages. Do you remember your Rebcon AGG demo? So much 
joy, so much applause. The current look of the GUI and its metrics 
just ruined the "hmm, nice" first look experience, and for no apparent 
reason, then constantly repeating "the skin will be done later". 
If so, it should not have been changed in the first place. (After 
porting the demo, my next area to play with is to try to play with 
material system, etc., and box-model style metrics)


- Ppl are well aware, that RMA is mostly on its own, and that even 
SCRUM methog did not work in regards to keep Carl attracted to such 
method in the long run. We are now facing the worst ever period of 
R3 development, where Carl apparently has some other projects, and 
R3 is almost stalled. Ppl are clever enough to realise, that we are 
being fed with some mid-time blogs, which should keep us distrated 
from the facts (huh, rebol file suffix importance anyone?), and we 
are also facing rushed releases as A111 is, and 2.7.8. was. You are 
free to not agree, but that is how I personally feel about the situation 
towards the RT. In the past I would probably write some letter to 
Carl, but I am at the point where I think, that RT is effectively 
burrying R3 under month by month. So - Carl is not able to find free 
time to continue with R3 development on a regular basis, and noone 
is denying his right to personal life, but - the fact is, that R3 
situation is at least - worrying. We wait for the beta plan for more 
than 4 months! If someone does not have time to even think how to 
proceed, then it is probably time to close the shop ... or open-source 
... but that will not happen. So - welcome the Amiga fate ... 


- And before someone else adds it, I will add it myself, as I believe 
I have my points right :-) Amen! Could I be wrong? Of course I could. 
You can easily state - hey, the situation is not like that, we know 
Carl works on this or that. Well - RMA knows, but that's it - the 
rest of the community is kept in information embargo from Carl. And 
that is difficult to deal with for many of us, who really like REBOL, 
and would like to see some coordinated development and the light 
in the end of the tunel once again ....

And now also - back to point 5, away from politics :-)


- New resizing model. Will API change too? Or is is just internal 
change, so I don't need to care about it, apart from knowing, that 
in some cases, resizing model will be more efficient?


- Is RMA building any commercial app using R3 GUI right now? Because 
I still might miss something, but style-wise I find it difficult 
to imagine, how it could be used. (Tables, lists, tree, area, tabs 
missing or buggy?)

- What I am interested at more than in the skin is better system 
metrics (spacing). Is there doc describing the box model, and how 
should it be used? E.g. I have styles like text, panel, button - 
what should be put in margin, edge, padding?

Expectations: That might be correct... RMA doesn't do expectation 
management, we do result management. So, whatever people expect and 
why, I can't read their minds.

R3: You all know that Carl is on his own. So, he can spend every 
hour only once. And you all know that Rebol is no commercial success. 
The rest is common sense...

And, we don't have any secret versions, code base or so. So it's 
mostly the same for us as for you. At least the result is the same.

Or in any case, I made sure to also test with your version, as the 
discussion shows. It was solved, I didn't think about it further, 
and I never brought it forward as a complaint

And where can I find an up to date version ?

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.

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