AltME groups: search

The thing is, the more speed we gain, the faster all this stuff will 
become useable by all of us. And, it's the necessary basics that 
need to be done to make R3 useable for GUI development.

And don't forget to make builds for platforms other than Windows 
available as well.

Yep, we will do as well. OSX and than Linux.

New http://94.145.78.91/files/r3/gui/r3-gui-src.zip


This one seems not to be as stable with the tests, and the style 
browser won't run, but offering it anyway.

The old version from 24-dec-2010 for diff is available at:

http://94.145.78.91/files/r3/gui/r3-gui-src-002.zip

The host kit should be synced at reasonably stable checkpoints. That 
way the GUI people are free to experiment, and people who are working 
on hosts that don't need a GUI or are using a different one can have 
a base that doesn't change as often and is a little more reliable.

btw... many host-kit fixes are pretty easy if you know where to look... 
for example to enable image gobs in Carl's host-kit, one must just 
remove the temp_remove and replace:
	int gobw = GOB_CONTENT(gob)->size & 65535;
	int gobh = GOB_CONTENT(gob)->size >> 16;
to:
	int gobw = GOB_W(gob);
	int gobh = GOB_H(gob);

https://github.com/rebolsource/r3-hostkit/blob/4d3bdeaa77cf1ec7c5d97738509ecec4fdf4b7e7/src/agg/agg_compo.cpp#L594


And that's all... I really wonder why you keep the host-kit updates 
hidden. Even Carl was able to put it on github:/

Carl is the one to release host-kits. He has full access to our code-base. 
As Brain said, from time-to-time RMA changes are merged.


IMO it doesn't make sense that we fork the host-kit and have two 
release in the wild.

I don'tt see the harm in making your branch (and thereby, your changes) 
public.

It makes sense... because I could save some time if I could work 
with your version or to be able make a diff between Carl's and yours.

And I was somehow thinking we want more than one man to fiddle with 
the host-kit... but maybe I'm wrong :) also we are probably almost 
out of topic here.. sorry for that.

And for a couple months or so before then he didn't touch the host 
kit or GUI. That is what "focusing on core development" means.

BrianH: there is no need to "defend" Carl here. I don't need to speak 
in a way for anyone to feel comfort on not to feel comfort. Let's 
follow facts - no matter what HostKit allows us, there is still the 
need for Carl being involved. Oldes is right - repos should be merged, 
period, or it still feels like we are somehow blocked. Yes, RMA or 
anyone else can experiment at will, and this is cool about the HostKit 
indeed, but as you can see, some developers might get reluctant to 
waste their time, if repos are not merged for a long period of time 
....

Not defending. We gotta do what we gotta do. I was there for a lot 
of the core development phase and involved with most of it, and it 
had almost nothing to do with the GUI or host kit. It was a major 
change that required a huge amount of work by Carl and me, probably 
the most extensive core change in the entire R3 project so far. We 
were glad that the GUI and host kit were being worked on separately 
so we could focus on this.

And by separately, I mean that even the GUI isn't really yet benefiting 
from the new module system. It's more than just syncing code.

Actually, yes. The Unicode changes had a lot of scope, but were still 
pretty shallow. The system structure was still the same. A107 was 
in many ways pretty similar to R2. We had planned for the A108 changes 
for two years, and a lot of the existing R3 code was written with 
that in mind, but to actually do it was a big deal. Plus, I've had 
to rewrite the module system from the ground up 3 times now, one 
of which took me 2 months and was never released publically.

There are many missing parts and a lot of bugfixes and changes that 
I know very little about, since I don't work with the lower level 
stuff. Some of the styles are already begun internally and it's possibly 
not a good idea to include them on the roadmap as community projects.

Also with the SCRUM tool, it probably needs to be finished, before 
we can tell what else is missing and that will not be a community 
project.


Each part mentioned above really needs to be done, but it was a lot 
less clear to me what exactly is ready in the GUI to do those things 
until some analysis today.

is not it possible to keep the compatibility with the Carl's demo 
and gui, which achieved a rather good level of usability up to A94, 
and which were rather well documented ? From this time, where alternative 
gui's were launched, we have nothing, apart from low level graphics 
programming, with almost no documentation.

My question is asked to the R3-GUI team and also to Carl

Jocko, the level of usability of Carl's demo was not satisfactory, 
and is lower than that now, since nobody cared to keep it compatible 
with the low level changes to the hostkit. That is the situation. 
Documentation - the same level of documentation exists (written by 
me), but Cyphre decided to publish it after the changes to the remaining 
styles using the panel implementation take place.

I think that talking a graph style, if we don't have tabs, tree, 
grid, is a bit preliminary. We need imo basic styleset, usefull to 
work with general DB apps, then we need more modern skin, and only 
then we need additional styles. We still can't see even concepts 
as accelerator keys being displayed, etc. :-)

The idea for the roadmap was to remove the need for RM Asset to do 
these styles ourselves later, when we are busy writing R3 end user 
apps, otherwise it could take a good 1-2 years before they would 
be publicized. The roadmap would be shaped around which styles are 
needed and which basic features need still to be implemented in the 
GUI.

Henrik - when I scroll above, you created the list of windowing and 
more advanced styles needed. Could we get the list, which will be 
delivered with initial release? E.g. we know, that Cyphre was working 
on some grid engine, etc., so that devs can know, what they don't 
need to focus on?

Pekr, I can't be sure at this time, because currently the styles 
are worked on via immediate need for fixes for things like the SCRUM 
tool, which is partially why I couldn't complete the roadmap. It's 
probably fair to say that the styles currently present in the style 
browser will be completed by RM Asset, but that may change.


What I imagine is that some of these styles that I mentioned will 
be comprehensive, long running separate, autonomous projects. A style 
like graph will need a ton of features, possibly separated into substyles 
and it would hopefully not depend on anything, but low-level features 
in the GUI system. Someone like Maxim could do this as he knows how 
to do high performance graphics. A windowing system can also be run 
as a separate project. Each project could be immediately stored on 
github.


RM Asset can do everything ourselves, but in the end, this will just 
take much, much longer, perhaps an additional year, which affects 
everyone interested in the GUI.

We follow a very simple strategy: We develop what we need, step-by-step 
and immediatly use it. So, we are not going to develop anything that 
we might need later at the moment. And, we are not first developing 
all styles, add a ton of features and than do our apps. We develop 
the styles just to the point where we can use them and than stop 
untill we need more.

Henve, you all can wait and see what styles we will do. If you can 
make use of them too, good. If not, sorry.

Of course there will be some changes to the basic concepts, and new 
concepts will be done when we need them.

And, I don't see a problem if we have 2-3 different implementaitons 
of the same style. First, the code can be merged, we all learn more 
which patterns are good for style development and the whole GUI will 
be much better challanged from different POVs.

We'll be releasing new version of R3GUI later today with the docs 
Ladislav mentioned.

Unfortunately I had not enough spare time to update the old 'gui 
demo'. So now a question to all who cried here :) Is there any volunteer 
who will try to convert the demo? I think this is great oportunity 
to:
-learn how the new version works

-found possible bugs and issues and report back to RMA team or even 
provide fixes
-give back something usable to comunity

So anyone interested?...

this quote implies any comunity work have to be based on a first 
step which seek the compromised best solution... which fundamental 
step wasn't done with the R3/GUI since their purpose is not to manage 
a  compromised vision of  R3/GUI edicted by the community but it's 
just to implement on top of the design edicted by Carl. In the actual 
design the least I can says is that you will need at least to do 
the work three time to support Win32API , X11 API and Quartz API.. 
+  any other windowed api. Knowing you are only 5 guys in RMA is 
it stupid to notice that and from this try to get the better solution 
the one that will give you best chance of success ?

the point here is the dialect edicted by carl can be adapted to any 
other library so why not considere taking a library already ported 
to the 3 main OS. Wich we would have the full sourcing and the would 
even in a shrinked version of it to save us the pain to do X times 
the work X being the number of  OS we want the R3/GUI on ...  and 
this  will too avoid us compatibility issues...

And I thoght the reason why we make gui in REBOL is not to need different 
gui for each system. I totaly don't understand your toughts.

do for a R3/GUI we need the whole GTK+ or the Whole QT ? first of 
all lest analyse the way R3/GUI interface to win32 API it doesn't 
use that whole api specification it's limited to the ground management 
and rendering fonctions.

you have you windows manager API (win32, X11, Quartz)  then a brigde 
called the dialect that will parse your rebol files commands imputs 
and translate them to signal and calls to trigger the proper data/ 
functions calls to your window manager API

Are we talking about same GUI? What I know Rebol gui does not use 
any native api and there is nobody I know working on it.

so yes the goal seeked is for the rebol programer to have a transparent 
and portable API in rebol to make graphical user interface. But on 
the ground level you need to adapt the C code to your OS window management 
solution... With some specific tweaks for example on linux you are 
not obligated to have X11 started so you linux rebol/view -hostkif 
R3/GUI- have to detect if the X11 server is run and if it will be 
able to display things or warn you it can't

that's window... that's not eaqul to gui for me.. and I really don't 
understand what's the point.

Oldes that's because you are not aware that all your R3/GUI calls 
need to be displayed on your screen  and that rebol doesn't handle 
that part ? and that the same for the mouse / keyboard events...

oldes there is .... using GTK QT or wxwindows or even glut... or 
any other library that is already ported to those 3 OS and there 
is alot...

but as R3GUI only need the basic fonctions of those API and not their 
whole thing  then adding them full seems dumb ...until you considere 
the runtime libraries of those libraries are already integrated by 
default in linux...

and since i'm considere as a pain in the ass and you all try your 
best to not have this discussion with me  or with the others in the 
community then you go to what Carl did without any second thoughts 
in the end we will end with a strong win32 API based R3/GUI and no 
linux or macOS X ports. That' s the the projection I can make base 
on the actual work.

GUI is system independent.. if you need it on win, you just must 
modify host-lib as it was for AmigaOS. And it was possible for R2 
so I really don't know why it would not be possible with R3... the 
only true is, that just opensourcing host-lib will not bring people 
who want to do the work.

oldes glut is compact, it's C based, it's portable on linux, windows, 
macosx only 117Ko and it opens a big gate to opengl since that's 
it's main purpose... Agg could be adapted at some point to use hardware 
accelerations proposed by OpenGL API at some point or at least we 
can investigate that part... Glut is old so this means it's super 
documented, and glut goal fits what r3/GUI basic goals are manegment 
of windows and management of user's inputs

oldes in the end project like area-tc or vivarebol don't works on 
rebol/view 2 on linux and macOS X so where is the portability here 
it's not even the same rendering result betwin windows XP and windows 
seven

Ok.. so we are in a big trable and I should dust of my PHP skills, 
that's what you want to hear?

sorry.. I really should work and not just chat.

Oldes > "so what.. so try to make glut extension. what are you waiting 
for?" >> once again with the if your not happy do it yourself is 
that what a community should stand for? Problem is Oldes this debat 
I try now to start you should have started it like in feb 2010  and 
come with conclusion out of that ...  but no RMA took the project 
in hands and since then there is nothing more to talk about and that's 
serves your purpose because you only want minimal involvement in 
this matter

GUI is system independent.. if you need it on win, you just must 
modify host-lib as it was for AmigaOS. And it was possible for R2 
so I really don't know why it would not be possible with R3... the 
only true is, that just opensourcing host-lib will not bring people 
who want to do the work.

it was possible in R2  but with loss an incompatibilities and linux 
and mac OSX version camed looooooooooooooooooong after the VID for 
windows like 5 years after ... and they were never maintained ...

If the ground api isn't a problem then that' s again another reason 
to me to choose something else  that exists as same everywhere without 
need for you to change your C code  you just recompile it on the 
3 os and that's it .... Then we can talk  on  what is needed can 
a GTK+ or a QT 4  limited versions can fit our need. limited version 
means the ground functionnalities - widows management; display and 
event management -

OLdes henrik and any other that wants me to make my own R3/GUI ok 
but since your are the gurus then I'm pending on your teaching and 
leading  for me to achieve that goal :)

Shadwolf,  if you think you have any 'gurus' they should teach you 
devotion and patience first :-)

Sorry, what I want has nothing to do with you and your 'gurus' :)

you talk about patience ... but problem is my patience would be filled 
if  there were a discussion about things choice futur  perspective 
documentation and not the way things are settling up since many month 
with a one sided discution you come with your own wishes fullfilled 
and you come here to show them and based on that get crowd admiration 
and support what you expect of us is being cheap beta testers nothing 
more nothing else...

I looked at  R3hostkit some month ago it was a mess ... I looked 
it now on the 110 it's still a mess  and there is no one here with 
a spine to have a technical level discussion with me !! as professionals 
how can you live with that ...!!??

I tryed to have this discussion in the early stage of R3/GUI project 
I was pushed aside I tryed to have it again some month after  with 
same result and now again some month after nothing have changed and 
you tell me to be patient ?

sorry to point out that in 6 month of your project leading guys there 
is nothing to read apart RMA's propaganda on how they are great and 
how they will do awesome things for rebol...

I'm doing actually an API map for the R3-hostkit and this single 
page document is already much more instructive than any of what was 
done in 2010 ...!!!

that's something we discussed too alot and concretly altme didn't 
changed since i start using it in 2003 ....

Repeating from above:


We'll be releasing new version of R3GUI later today with the docs 
Ladislav mentioned.

Unfortunately I had not enough spare time to update the old 'gui 
demo'. So now a question to all who cried here :) Is there any volunteer 
who will try to convert the demo? I think this is great oportunity 
to:
-learn how the new version works

-found possible bugs and issues and report back to RMA team or even 
provide fixes
-give back something usable to comunity

So anyone interested?...

will that documentation be anought to start another branch R3/GUI 
? I think that's not the topic in fact. That's documentation to allow 
us to test your product and be productive beta testers.

Pekr, that's the trick, I suppose. You have to translate the visual 
appearance and capability rather than looking too much at the old 
code.

once angain those documents are just here to serves you own interest 
not our... My interrest is to have a R3/GUI that is based on a community 
real effort and organisation, that produce documentation and that 
tends to involve everyone and not limiting them to the role of beta 
testers.  My interest is having this library with one to one link 
everywhere. My interest is to have this module/library  discussed 
all aloing and with futur granted ... We don't know if RMA will produce 
something affortable we don't know if after this first shot what 
will be the level of evolution we can expect from it ... Do we will 
need to pass to bounties to get new things added to it once the main 
release is done ? how will be integrated and rewarded external contributions 
to that project ? why only the 5 of RMA should get money out of this 
project?

We should start talking look & feel at some point too, as it really 
looks completly strange :-) Cheap gradients with Aqua like old Mac 
look mixed with 70ties Unix grey aproach :-). How can anyone create 
anything like that nowadays? This is really strange, as I remember 
Gabriele's effect-lab, Cyphre's styles pack, and also Henrik's first 
UI attempts, and those looked much better ...


I need to know, if it will be adressed, as I am scared to touch the 
gui, as I fear it will do really something bad to me :-)

Pekr, what you think is ugly and cheap design, is actualy THE FUTURE 
of UI design. Every GUI will look like this in 2-3 years, I wonder 
you don't see it. At least you understand this is the definite and 
final design of R3GUI.

TomBon - I think, and I hope, that not much changed in underlying 
architecture design. But you probably refer to Carl's Spring skin 
:-) First time I saw it, I found it strange, now I miss it :-)

Well, at least I have something to play with. If I will somehow proceed 
with adapting demo, I might try to experiment to change some style's 
look, to see how the design and functionality are separated.

Pekr, that's great! So let you dog do the draw blocks for some styles 
and we will add them!

Pekr, if you need any help with porting, I'll be glad to help. Just 
start with something easy as button, and let me know if you have 
any questions.

I will not participate to any bug tracker, bug correction, or testings 
regarding R3/GUI until we don't have a full detailled schematic of 
R3-host-kit, while we don't know where we are going with this project, 
and while we don't know if a better path can be found to avoid this 
project to fall in porting maze.

And I bet his dogs learns faster, that we stated more than once that 
we currently don't spend any time on eye-candy. Maybe Petr learns 
it too ;-)

I have to support Petr's dog here. I fully understand why looks are 
not a priority for development, but I also know that if we proudly 
present the GUI functionality to the world with the current skin, 
almost everyone who sees that will confirm in his mind that REBOL 
is a thing of the past and will never touch it again

But I think the problem is that you want "the community" to do that 
work for you and profit from their work without doing anything yourself...

I have only a couple of request: please consider now the modification 
to the event system to support multitouch devices and whatever is 
needed for smooth GUI animation. It is important for further porting 
on other platform.


Also, keep in mind that good documentation is essential to let people 
use your work.

A last note for ROBERT: I have read that r3GUI stiles will be developed 
until they are functional to the project specification the where 
created for. 

A clear, written, specific, development path to further develop these 
style and the missing other would be good to have a clear global 
view about the final goal apart this project specific development.

Petr, the problem is, it's not MD(P) format and we don't have the 
generator script (yet).

from the page of RM-Asset.com we can read and I quote:

What's special about RM-Asset?

We are very productive. This is good 
for you because we need less time than you might have thought.

We 
are very efficient. Internally we joke and say 
All good software fits onto a floppy-disk!"


We keep things simple. Our solutions are simple, easy to install, 
maintain and use. Most solutions are designed to complicated. We 
have streamlined designs making us faster while resulting in higher 
quality."


Fine but since you took over this proect we don't even have a prospective 
documentation (list of the widgets you want in it, the condition 
of this project, the stepstones on the road)or an api documentation 
etc... this means 0 lines of code. you claim to be the best to work 
fast to be serious. I just ask you to prove it.

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.

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.

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.

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 ?

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.

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"?

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.

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.

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 :-)

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

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 :-)

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.

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

not going at all - coming home from work at 19:00 and later :-) First 
thing I want to try is trying to play with different draw blocks 
:-) E.g. trying to "port" Carl's button :-)

Simply put - it is supposed to be a fun. We (rebol community) forgot 
about the fun a long time ago :-) I looked in some R2 demos, and 
was amazed - we need new demo contest, and the condition is simple 
- R3 only :-)

Any tip of how to play with gradients, trying to simulate some existing 
ones? IIRC, there was some R2 script? In the end I would like to 
mimick my HTC sense environment, as I like it and it looks decent, 
albeit maybe too white - http://204.145.67.138/shared/ScreenShots.png

Question towards style tagging. I noticed some styles are tagged 
as 'internal, and some as 'compound. I would like to know, if it 
serves any other purpose, than for style listing/grouping, to distinguish 
it? 'Internal is probably just a tag, but does 'compound has any 
meaning further down in the code?

And, the tag system is generic to flag styles as necessary.

I am still not sure I am comfort with group having different semantics 
to panel :-( .... trying to do some tests with Carl's demo, and it 
is going to be pain-in-the a..., to insert returns in there. From 
the very beginning of the R3 GUI projects my opinion was, that group 
should be just de-stylised panel (no visual borders), but identical 
in behaviour ...

I hope I will change my mind later in the proces ....