AltME groups: search

Created this group to enable REBOL 3 extensions chat ... not web 
public, unless more wider audience agrees ...

I've got impression, that OGL is slowly dying, and feature lacking, 
in comparison to DirectX?


I don't see that. All *NIXs use OpenGL. OS X GUI is based on OpenGL. 
Playstation 3 use OpenGL (PS1 and PS2 used a proprietary Sony API).

From http://www.opengl.org/

The Khronos(TM) Group, today announced OpenGL(R) 3.2, the third major 
update in twelve months to the most widely adopted 2D and 3D graphics 
API (application programming interface) for personal computers and 
workstations.

It seems, OpenGL is growing.

Years, ago I said that information channel fragmentation in a small 
community is evil. We still have the same situation or add new channels.

But OK, I use R3-Chat and will post to Extension group.

created a new group for this specific extension.  we should continue 
any discussion about /library  there .

Ah, I was searching for !REBOL3 Extension. Maybe we can rename this 
group.

Robert, did you ever upload your macros stuff that you mentioned 
in Jan?  I looked in the extensions group and didn't see anything

Oops ,, should have been in the humor group

anyhow... object use is central to this, since its the most approachable 
way to group & bind things in context .

I need to find a group to discuss the PAIR changes happening. Suggestions 
anyone?

I guess. Kind of general group tho. Was hoping we had a graphics 
or datatypes group.

Has every group become the Humor group now? My grandma would say 
we are getting punchy :)

(And no, we'll not just dump it to the group, because I don't want 
to flood Curecode due to non-tested status. Best to wait on it.)

This is going to take some discussion. Probably not here in this 
group, because it may get rather long.

PeterWoo - you talk nonsense, which belongs in advocacy group :-) 
If you work for 35 years in enterprise, then tell me, if you met 
spread there. The messaging is done by so called middlewares. IBM 
has MQ series, SAP has XI. Those engines use the so called connectors. 
Everybody went the web-services route, hence having ability to talk 
SOAP might be more important for REBOL. I never argued against having 
as much libraries as possible wrapped to REBOL, the only thing I 
argued against is eventual 200KB library inclusion in REBOL, just 
to do IPC between REBOL tasks ...

Graham IMO almost every IPC need somewhat daemon runing. The library 
"could" be linked in extension and try to open communication with 
daemon, when it doesnt find the daemon let start its own (first process 
trying to comunicate), what is nice in Spread it combines P2P and 
multicast and members/group policy, and of course single/multi machines.

If we want to pursue IPC chat, make suggestions, and get Carl involved 
(at least get some his thoughts), we should do it in a different 
group or somewhere else. Should we do it on AltME or somewhere else?

see the announce group

I predictate your faillure in less than 4 more moth ... January 2011 
maximum the actual bounty hunters R3 group will be disbanded and 
nothing concrete will have been done apart the extraction of VID 
from R3.exe to hostkit. When you take money you do things like professionals 
that's the minimal things this means a list of what will be done. 
A roadmap with important steps and release dates  for those important 
steps before starting anywork you make that dev plan to appreciation 
to the public you debat it serriously you remove things you add things 
... You try to get involve the most possible people that have been 
already involve in R2 GUI use or creation because they have the practice 
knowledge and experience. 


Thousand way of being serrious starting a positive attractive motion 
for this part could have been done but by lack of interrest and generosity 
you end doing what you are doing ...

I predictate your faillure in less than 4 more moth ... January 2011 
maximum the actual bounty hunters R3 group will be disbanded and 
nothing concrete will have been done apart the extraction of VID 
from R3.exe to hostkit. When you take money you do things like professionals 
that's the minimal things this means a list of what will be done. 
A roadmap with important steps and release dates  for those important 
steps before starting anywork you make that dev plan to appreciation 
to the public you debat it serriously you remove things you add things 
... You try to get involve the most possible people that have been 
already involve in R2 GUI use or creation because they have the practice 
knowledge and experience. 


Thousand way of being serrious starting a positive attractive motion 
for this part could have been done but by lack of interrest and generosity 
you end doing what you are doing ...

Shadwolf - "as my futur contribution ? plain and simple their will 
be none  of it ..." - ok then, leave us alone, and please save us 
from your constant ranting noone is interested in, especially here 
in that group - please move that to advocacy ... ...

Ah, wrong group then. The layout dialect is implicit in R3's VIEW 
function now, not implemented by a separate LAYOUT function.

Actually there are several changes by Bolek and Cyphre, that I've 
not yet studied, but much of the work that was handled by LAYOUT 
before is now relegated to PANEL and GROUP, which is why we talk 
so much about them and not a central LAYOUT function. They call various 
subfunctions that specifically focus on creating faces and laying 
them out and resizing them.


So the styles themselves are capable of custom layouts and resizing 
mechanisms and also mechanisms such as face init and triggers. So 
that means you are no longer a "slave" of the LAYOUT function.

That's also why:


1. I was talking a while ago about that you can build a style that 
emulates VID, complete with a dialect, or replace the layout mechanism 
with your own, by rewriting PANEL or GROUP or adding new panel styles.

2. That whenever you want to do a new thing, you should make it as 
a style. That's where you start.

Gregg, see august 28th in the REBOL3 group

Ah, different group. Thanks.

Links were posted in the host kit group ... check them out

I would suggest that the difference is the spacing that is provided 
around the check-boxes and the buttons is consistant and the group 
boxes properly surround the objects.

A basic example of how it looks right now:

f: view [
	form-panel: panel 2 [
		group 1 [
			title "Record fields"
			bar
			group 2 [
				label "Name"		name: field		; stored as name
				label "Address"	address: field	; stored as address
				label "Age"		age: field		; stored as age

    label "Skipped"	skip-field: field options [skip: true]	; not in the 
    list
				label "Ignored"	field			; not in the list
			]
		]
	] options [record: 'rec]
	group 6 [
		button "New" obtain 'form-panel add-record
		button "Save" emit 'form-panel update-record
		button "Delete" do [delete-record]
		pad
		button "<" obtain 'form-panel next-record
		button ">" obtain 'form-panel previous-record
	]
]


The 'rec is a record object, which is filled with data from the server, 
using the backend function, and when submitting, is used to gather 
data from the form and into the server.

Pekr, I'd like to hear your opinion on this: Instead of PANEL and 
GROUP there will be VPANEL, HPANEL, VGROUP and HGROUP. Is it end 
of the world as we know it, or are you fine with it? ;)

Yes, unlike in Carl's R3GUI, PANEL and GROUP are now different internally.

Rebolek, yes,hence my question on making PANEL and GROUP behaviour 
an attribute ;-)

I do understand that you want to express the behavioural symmetry 
in PANELS and GROUPS. It's a bit like multiple inheritance: Inherit 
behaviour from PANEL or GROUP, inherit orientation from HORIZONTAL 
or VERTICAL. That's 4 possibilities, and any name chosen is likely 
to overemphasize one aspect over the other.

Rebolek - I have always had the problem with the PANEL vs GROUP, 
because they used different native axis orientation, why NOT being 
the same style in design. I objected to Carl, that I always forget, 
which direction which particular style goes by default. But Carl 
told me, that it is OK the way it is ... I still don't agree, unless 
both styles have the same visual qualities ...

btw- I never liked GROUP name. I want just one - PANEL - with vertical 
or horizontal orientation.

Originally, GROUP and PANEL were same styles with different orientation. 
That has changed and now GROUP and PANEL are two different layout 
engines. So we need to come up with names for horizontal and vertical 
variations of GROUP and PANEL. So far we've got H*/V*, but if there 
are better names, it can be changed.

Also the names GROUP and PANEL can be changed if someone can come 
up with a better word to describe the layout engine (like GRID for 
PANEL, but I think GRID should be reserved for true GRID style).

we still talk mostly about naming in regards to orientation. But 
what about GROUP or TIGHT (if TIGHT style still exists), which use 
different layout mechanism? If we would user COLUMNS/ROWS, it would 
not work as far as naming is concerned ....

Back to ACROSS and BELOW, then? Those have never been misleading, 
they just weren't styles in R2/VID but layout directives which were 
lost after the layout phase finished. And make the difference between 
PANEL, GROUP, TIGHT behaviour an attribute to them, with reasonable 
defaults. Would that even work?

layout [
	below [
		across [ ... ]
		below [ ... ]
		below 'tight [		; TIGHT behaviour
			button
			button
		]
	]
	across [
		...
	]
]

what about GROUP or TIGHT...

 - in case of GROUP it would become VGROUP and HGROUP. The TIGHT style 
 I see more loke a shortcut that can be specific to single kind of 
 container. Even if we have only PANEL and GROUP it would be specific 
 to only one variant. IMO the TIGHT style shouldn't be probably in 
 the basic style set. It would be better that user 'stylyze' the basic 
 styles  which with different box-model parameters according to  his 
 own needs.

Bolek +1 - Don't use GRID for these names, unless we call it a canonical-grid. 


Christian, I thought of across/below as well, but understand Cyphre's 
reasoning.

Panel 1

 or "group 2" give little meaning to the numbers. H and V prefixes 
 make things clear, but...


groups flow faces by their individual size, like Google Images, while 
panels use a grid of cells.
 


What are the use cases for each style? Is it accurate to say that 
PANEL is for cases where you want things neatly aligned, and GROUP 
is for cases where alignment isn't important, and tighter positioning 
based on face size is desired?

My example was not to show what I want (thought I said that), but 
to show that the orientation affects how you might lay out your code, 
to group things contextually, and how that relates to making it easy 
to add new items.

Yes, sort of. Like switching between across and below today so I 
can group related things together in the code.

I propose to use guie/widgets then, to group related styles. By related 
I don't mean derived, but more of a compound styles - table is good 
example ...

I'm considering a rewrite of the validation prototype as there are 
some parts missing with regards to initial state.


Have there been any considerations on how to use the DIRTY tag? I 
have some ideas on when DIRTY is set:


- The user creates an edit in a field, changes setting in a radio 
group, etc. It would not be enough to focus the face, but a specific 
action would have to be taken.

- When the user deliberately moves the edit back to the original 
state, the field is still dirty, so we can observe which fields were 
manipulated.

- Using a function DIRTY?, we can observe whether a field or a panel 
is dirty.

- It's not possible or logical to set the DIRTY tag programmatically 
(other by forcing it in with TAG-FACE face 'dirty)

It would be cleared when:


- Using a function CLEAN, we can unset the DIRTY tag in a face or 
panel of faces. This would be the only way to unset the tag.

the style-browser I have is a bit old, but it should work. There's 
a link earlier in the group.

http://94.145.78.91/files/r3/gui/r3-gui.r3


PANEL and GROUP no longer exist. You need to use HPANEL/VPANEL or 
HGROUP/VGROUP.

(moving to Android group...)

nve, the test framework runs roughly 4000+ tests and reports the 
results. See the "testing & tools" group for more details.

Yes... so we still need the simple example to show it.. best to use 
different group (R3 graphics) as it's not related to GUI.

Maybe RMA team could set-up a blog too (re Amiga group post about 
OS 4.1 progress). I know there's probably not much time for that, 
but I do remember some of Henrik's articles, and it was really nice 
to read :-)

And, to not forget, thanks to Cyphre's effort, the VGROUP and HGROUP 
styles now properly use the RETURN keywords allowing the *group styles 
to have rows/columns with unequal lengths

What I want to do is to make a box with an Image as borer pen. Not 
able to do it with R2 nor R3 (see 'View group).

btw - I seem to have problem understanding v/h group/panel wrapping, 
when accompanied with integers:

view [hgroup 2 [button "1" button "2" button "3"]]

... I would expect button 3 to be placed under button 1?

I am curious about the docs, as I miss main purpose in difference 
between panel and group. In the past, IIRC, panel and group differed 
visually, and also in default layout orientation, and if it would 
be the case, I don't understand, why group differs in using RETURN 
keyword instead of using integer as an option ...

OK, so the option parameter of group styles is an ommision?

That is understandable, for the styles ... but what about missing 
features? Will we add them, as needed? I mean e.g. - there was a 
discussion about the hilite/glow effect. One group of ppl wanted 
to have central abstracted behaviour, other ppl were talking about 
the per-style implementation, while there is third possible aproach 
- the mixture of both - central solution with possibe per-style override. 
Such things you need to account for, when writing your style, depending 
upon the decision about how it will be solved architecture-wise?

(Pekr, I think we should move your HW question to !R3 Graphics group)

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

I can see you use empty rows to separate some items in facets block. 
Why is that? I did not find any example of 'internt being used, so 
I think that might be the reason? To simply separate/group some items? 
Aren't we wasting memory here?

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

Henrik, when switching panels, there's following function I need 
to adapt:

	unless pan [
		pan: make-panel 'group pick test-blocks index [columns: 1]
		poke test-panels index pan
	]

I translated it into:

	unless pan [

  pan: make-panel make-face 'vpanel (pick test-blocks index) 'group 
		poke test-panels index pan
	]

I changed it to:

	unless pan [

  pan: make-panel make-face 'vpanel (pick test-blocks index) 'group 
		poke test-panels index pan
	]

But something is "not bound" ... I get following error:

** Script error: when has no value

** Where: make make make-face unless view-sub-panel do switch -apply- 
apply if f

oreach if do-face switch do do-bind-actor actor all foreach do-style 
set-face sw

itch do do-bind-actor actor all foreach do-style case do-event do-event 
do-event

 either -apply- wake-up loop -apply- wait do-events if view catch 
 either either
-apply- do

** Near: make styl/facets opts options: make object! any [opts []] 
ta...

trying to do some tests with Carl's demo, and it is going to be pain-in-the 
a..., to insert returns in there

 - that is an error, the group style is not the style Carl had, so 
 you should not do that at all

The style Carl named group was just a kind of a hpanel, with its 
box-model characteristics adjusted to not have a margin, IIRC

I can see you use empty rows...Aren't we wasting memory here?

 - how can an empty row waste memory? For example, I use empty to 
 make something like 'paragraphs' to group code parts that are somewhat 
 "related". E.g. if I resize a panel, the 'paragraph' resizing lines 
 precedes the 'paragraph' resizing columns, which is followed by the 
 'paragraph' resizing subfaces.

In general, if you don't want to use the RETURN keyword, don't use 
the *group styles, they are designed *for the purpose* of supporting 
the RETURN keyword

In general, if you don't want to use the RETURN keyword, don't use 
the *group styles, they are designed *for the purpose* of supporting 
the RETURN keyword

 - not a big deal, really. My problem is, that what I want is behaviour 
 of panel style, but without gfx borders. But - I could create new 
 style, removing the visual elements of panel. Maybe such a style 
 could be added by default, but not sure others would find it usefull, 
 nor do I know what name to use ...

Ladislav - did not read all your posts here, but as you are here, 
and for me to proceed - how do I "easily" create panel, if I have 
layout stored in a block? Carl's demo uses:

view-sub-panel: funct [
	index
	main-pan
	desc
][
	set 'current-panel index
	set-face desc form pick test-notes index
	pan: pick test-panels index
	unless pan [
		pan: make-panel 'group pick test-blocks index [columns: 1]
		poke test-panels index pan
	]
	switch-panel main-pan pan 'fly-right
]

his

 make-panel used three values. OK, options block is not needed, nor 
 supported right now. Function attributes are now reversed (dunno 
 why, the argument order is not compatible with make-face for e.g.). 
 That is still easily fixable. But now "rma's" make-panel accepts 
 face, not dialect block. I tried to use make-face on a dialect block, 
 but no luck ....

I simply need to fix this line: "pan: make-panel 'group pick test-blocks 
index [columns: 1]", if possible. Henrik suggested that the aproach 
is different, and that I should use 'content functions, which I know 
nothing about yet.

Regarding the

	unless pan [
		pan: make-panel 'group pick test-blocks index [columns: 1]
		poke test-panels index pan
	]

code, you should be good with:

	unless pan [
		insert-panel-content/pos/no-show test-panels compose/only [
			pan: hpanel 1 pick test-blocks index
		]
	]

Cyphre's "as usually" most probably means "on Friday", and I bet 
Cyphre will put a note to the announcement group when the update 
will be available.

I still miss simple style to group things. I always wanted a panel, 
with border, gradient, etc., but then also exactly the same style, 
but with zero visuals ...


IIRC, in Carl's GUI, it was panel vs group - except the fact, that 
it group used opposite coordinate system - very unwise btw


In RMA's GUI, if I am not mistaken, group is internally completly 
different - it is here for those users, used to VID2 - you have to 
use RETURN keyword, it does not align in grid cells, etc.


So - how do I easily define inline style, which removes panel visuals? 
I don't want to create new style for such a simple and usefull thing. 
And I start to think, that 'group style is here just to confuse users 
...

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)

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.

Kaj, I bet your r3-gui.r3 was definitely not the latest version from 
http://www.rm-asset.com/code/downloads/files/r3-gui.r3

The bug you showed has been fixed in the release from 28.1.2011 (see 
the announce group)


It looks more like you have been loading the r3-gui.r3 from Josko's 
http://www.colineau.fr/rebol/downloads/tests-R3Gui.ziparchive ;-)

That provokes another request from me: please stop presenting "political 
opinions" here. The purpose of this group is to discuss the GUI.

Cyphre: "Kaj, I bet your r3-gui.r3 was definitely not the latest 
version from http://www.rm-asset.com/code/downloads/files/r3-gui.r3

The bug you showed has been fixed in the release from 28.1.2011 (see 
the announce group)"

Aha, so, you are stating, that what you mentioned in the ReBorCon 
2011 group was not true?

And now you introduced another group of settings:

			;turn auto-sizing on		
			init-hint: 'auto
			min-hint: 'auto
			max-hint: 'auto

btw - I am not sure "hint" is a good name? I know term hinting, being 
related to fonts. But - above is the way - group values together, 
add comment, use empty line as a separator from other group of settings 
...

you use panel style, so you've got 2x2 grid. "ok" button is simply 
on 1x2 position and 2x2 position is empty. If you don't want grid, 
use group style.

I don't like the group style :-)

the group style is not for forms

I am just not sure. What I am still confused about is the different 
semantics of particular styles. I wonder, if there could be just 
panel-like semantics, so I could use:

hframe 2 []
hpanel 2 []
hgroup 2 [] ; with no need for return keyword


But that would be limiting to the group style, as it has no cells 
- each row is separate IIRC ....

But my above example is some food for thoughts. When I think of forms, 
I know that form might be enclosed in some pane (being it group or 
panel or frame I don't care - just visually separated from the background). 
Then it usually contains pairs of labels and fields. Btw - in R2 
it was easy to right-align label - is that possible with R3 GUI? 
And I think that some buttons belong to the form - e.g. Edit, Submit, 
Cancel, and some might belong to the Window.

hgroup for buttons does not work either, because that group is part 
of the first cell of the second row ...

GROUP and PANEL would by default not create a frame. Derivative FRAME 
styles would create a frame.

Rebolek says, it should now be changed so that TIGHT, GROUP and PANEL 
no longer draws any frames, as this is relegated to higher level 
FRAME styles.

if this group was corrrupt, this would be VERY bad ... please can 
someone confirm with Carl?

Ladislav may still be executing them - he's in the development group.

Related to text handling discussion, which I suppose occurs at the 
host-kit level. But it should probably have a separate group.

Andreas, \thanks for the Fix notes (posted int !REBOL3 group)


I'll add your changes to my A109 and embed the latest CGR code into 
it.  I'll to release this by tomorrow, but no guarantees, i've got 
a lot of other stuff to do.

btw, I released a new host-kit which has custom gob rendering enabled 
(very early prototype) but its got an OpenGL rendering engine running 
within view.


you can see the download link in the announce group, if you want 
to try it out.

Andreas, we should probably switch to a different group to keep all 
this together... is there a group already on this?

this is old Carl's gui. I am not sure it works, most probably it 
does not. Go into R3 GUI group here, and find some of Henrik's links 
and download RM Assets' GUI

If you want just to try A110, go to REBOL3 GUI group here, there's 
a link to download a binary and dll .... we will have to wait for 
Carl to resurface and correct the release, or even better - to merge 
the changes to official location ...

I still miss something like general R3 porting group. Or will we 
set-up one group per target platform here, as we did with Android? 
I think this group is good for technical host-kit stuff, not general 
porting stuff ...

Since there are so many questions, here is a group for those who 
want help with R3's new module/script system. If you need help with 
LOAD, SAVE, IMPORT, DO-NEEDS, Needs header syntax, the new binding 
conventions or the new semantic model of scripts and modules in R3, 
ask here!

The discussion in bug#1625 is turning into a fairly deep explanation 
of the R3 script and module bbinding models, the meaning of FUNCT 
and why we have it, and the inherent limits of REBOL that were why 
we did things the way they are now. Take a look, it could be an eye-opener 
to anyone interested in this group.

The new option names are a good choice because all of the /no-* options 
are a way of breaking modules that otherwise depend on acting the 
way that they were written. The whole group of them needs a warning 
label.

Created new group.