AltME groups: search

I've posted this bug in the comments to 2.7.4 OSX build, but I'll 
repeat it here, in case it's being seen here first. It's a colour 
problem, when transforming in the DRAW dialect. Code example:

i: make image! [100x100 255.0.0]
draw i [pen green line 10x10 90x90]

view layout [box effect [draw [image i transform 0 -30x-20 2 2 0x0 
image i]]]

Does line-join in the DRAW dialect works with Windows version? There 
seem to be a problem with OSX version:


view layout [box 200x100 effect [draw [pen red line-width 15 line-join 
round line 10x10 90x10 90x90 10x10 polygon 110x10 190x10 190x90]]]

I think, they both should be with rounded corners.

What about line-cap?


view layout [box effect [draw [pen red line-width 15 line-cap round 
line 10x10 90x10 90x90]]]

view layout [
	origin 0
	box 400x100 white effect [
		draw [
			pen red
			line-width 15
			line-join round
			line 10x10 90x10 90x90 10x10
			spline 110x10 190x10 190x90 110x10 
			spline 210x10 290x10 290x90 210x10 closed
			polygon 310x10 390x10 390x90
		]
	]
]

example:
view layout [
	origin 0
	box 200x100 white effect [
		draw [
			pen red
			line-width 15
			line-cap round
			line 10x10 90x10 90x90 10x10
			line-cap butt
			line 110x10 190x10 190x90 110x10

		]
	]
]

hmm, what's wrong with this?
i: make image! [100x100 255.0.0]
draw i [pen green line 10x10 90x90]

view layout [box effect [draw [image i transform 0 -30x-20 2 2 0x0 
image i]]]

REBOL [
	Comment: {
		Inspired by http://www.rebol.com/how-to/feel.html
	}
]

view/new layout [
	across
	tabs 120
    the-box: box 200x200 "Test Events Here" forest feel [
        engage: func [face action event] [
			ac/text: mold action show ac
			ty/text: mold event/type show ty
			of/text: mold event/offset show of
			co/data: event/control show co
			sh/data: event/shift show sh
			ke/text: mold event/key show ke
			kt/text: mold type? event/key show kt
			ti/text: mold event/time show ti
			dc/data: event/double-click show dc
        ]
    ] return
	lbl "action:" tab ac: info 100 return
	lbl "event/" return
	lbl "type:" tab ty: info 100 return
	lbl "offset:" tab of: info 100 return
	lbl "control:" tab co: led off return
	lbl "shift:" tab sh: led off return
	lbl "key:" tab ke: info 100 return
	lbl "type? key:" tab kt: info 100 return
	lbl "time:" tab ti: info 100 return
	lbl "double-click:" tab dc: led off
	key #"Q" [quit]
]
focus the-box
do-events

No :)


We need a place, page, website, (i.e. the original purpose of REBOLCentral) 
where a new person can come, and in a really nice layout EVERYTHING 
REBOL is there.

It points a person to everything else.


The Library,  the blogs, the knoweldge of this place, a REBOL "ReadMeFirst.txt" 
if you will.

can someone else confirm if flood is broken in R2?
view layout [
    box snow 100x100 effect [
        draw [
            box 20x20 80x80
            fill-pen orange
            flood 2x2
        ]
    ]
]

Andreas, corresponding concepts:
- The place where the program is installed/located.

- The place where the installed program version is listed, so you 
can know whether an update is needed.

- The place where user files, particularly the view-root and desktop 
files, needs to go.

- The place where machine-specific user settings should go (console 
layout on Windows).

- File associations, where possible. Not assuming that these are 
possible on platforms other than Windows.


Where these go depends on the installation profile. Yes, not installing 
at all is one of those profiles.

I mean - once I define e.g. layout, objects get defined, and unview 
just hides the window, but the rest is still in the memory without 
any way to be cleared. Is that even solvable? I have no idea of how 
to track all possible references to be unset :-)

Your example is not layout but stylize example, but ok.

regarding th emoving style settings from FACETS to TAGS..this is 
not much practical as it is not to redefine TAGS by inline definiton 
in the layout.

User poll questions:


1) Do you find the 'a layout' and 'layout style' notions to improve 
the current 'a panel' ambiguous terminogy, or do you prefer something 
else?

2) Which of the three [[hpanel vpanel] [panel vpanel] [panel panel 
vertical]] alternatives do you prefer?

Maybe we're just tired of user polls, or we don't have the time to 
dig into this. If you don't have a clear view of what a good GUI 
should be, and therefore need polls, then maybe use some time to 
get a clear view. Only suggestions. :-)


I looked into it quickly, and I would at this point go for just have 
panel, letting vertical be a layout-mode option. Reason: K.I.S.S. 
(and vertical is an option anyway). And if you support user-defined 
styles (I'm not sure, you do, as I'm not very much into R3 GUI), 
then programmers can just make their own vpanels, if they need it. 
If I, as new to some GUI, can get it up and running in a very short 
time, because it's so simple, that's a huge benefit.

That is possible, actually, having just the panel style, it is trivial 
to derive a vpanel style from it, since you have to only set the 
LAYOUT-MODE to 'VERTICAL, and that is all.

But, the concern here was to make the Layout dialect look "acceptable", 
which, for many people may mean many different alternatives.

view layout [zen]

While the "container" word is used in some GUIs, I like "layout" 
word, as we are used to it. The question is, if we want to preserve 
"layout" word for something else, or not. But generally "layout" 
translates to my brain like a "design", "description", whereas "panel" 
is concrete - just a panel.

also - layout-mode alternatives could be - direction, orientation. 
But those are not much shorter. Maybe just a "mode", but there might 
be xy modes, so not enough self-explanatory

For example,(this is not much a documentation issue, it is a coding 
issue, in fact): There is an INSERT-PANEL-CONTENT function. The function 
is supposed to insert contents to any layout face, i.e. the name 
is inadequate, in fact, and it should preferably be renamed to INSERT-LAYOUT-CONTENT 
(or INSERT-LAYOUT-CONTENTS, respecting the results of some of the 
previous polls).

but - imo insert-layout-content is not logical. Imagine OOP way of 
things. You have a panel style = class (let's pretend it is a class). 
Then in normal OOP environment, you would see "insert", as it's method, 
no? Hence panel/insert, panel/delete, etc. So you should not imo 
name your function using a "layout" word, while keeping the style 
named "panel"?

I am probably OK to stay with the panel name of the style, panel 
name in supporting functions, and still referring to it as a panel. 
I simply regard panel style being one of possible implementations 
of the panel layout concept  :-)

INSERT-LAYOUT-CONTENTS actually is OOP style, since:

- you don't specify the style, the style of the face is used

- the "/" is not used in all OO languages, and is not the only way

- as noted above, the current INSERT-PANEL-CONTENT name is inadequate, 
since it does not respect, that the layout may not be a panel at 
all

Right, the function is a method to insert contents to any layout: 
vgroup, backdrop, my-pink-panel, ....

Then I can imagine:

INSERT-LAYOUT-CONTENT
INSERT-CONTENT
INSERT-INTO
INSERT-PANE

1) Do you find the 'a layout' and 'layout style' notions to improve 
the current 'a panel' ambiguous terminogy, or do you prefer something 
else?


To me, a layout is a specification, not an instance. I don't know 
that using a different word (container or compound) helps. You just 
need to be explicit about whether you're talking about a panel face 
or the panel style (which has a layout specification).


2) Which of the three [[hpanel vpanel] [panel vpanel] [panel panel 
vertical]] alternatives do you prefer?


My view was based on there always being a base 'panel style, with 
'hpanel and 'vpanel being shortcut styles to set the layout mode.

You just need to be explicit about whether you're talking about a 
panel face or the panel style (which has a layout specification).

 - hmm, it never occurred to me how much the question could be misunderstood.

So, for "a panel" we have the following two meanings:

- "a face that is a layout of faces" (this is what Carl used)
- "a face that is an instance of the panel style"


These two meanings are different, since "a layout of faces" may be 
a vgroup, e.g.

A layout of faces

 could be an instance of any number of styles, yes. We just have to 
 accept that as a non-specific definition. That is, a panel is a face 
 that is a layout of faces, but it is not the *only* type of face 
 that is a layout of faces.

Before, 'panel' was used as a style name. At present, it is not. 
It is still used in the documentation, but there it means something 
else (a "layout of faces"), which is inappropriate.

In a simplified form:

- the DO-STYLE function will be renamed to DO-ACTOR

- both Henrik and Robert wanted to be able to influence the behaviour 
of actors from the Layout dialect,
- which was not possible yet,
- and was not compatible with the idea of reactors

- therefore, it looks like the best idea to introduce one new Layout 
dialect keyword (ATTACH),
- and allow to influence actors from the Layout dialect,
- making reactors unnecessary

- forgot about yet another Layout dialect keyword: OVERRULE

- making reactors unnecessary ...

 - understood, but doesn't it break Carl's idea of having most common 
 actions directly available in a layout, without any overhead? I mean 
 - reactions like DO, SUBMIT, BROWSE, CLOSE etc.?

Could syntax example be shown? E.g.

BUTTON "browse" BROWSE http://www.rebol.com

will become?

BUTTON "browse" ATTACH ????

the "it will be complex for event handling of the rest 95% of normal 
cases" is the reason why I prefer #3. As Gregg noted, in case of 
having #3 we can still define some "shortcuts" either by defining 
a simple actor "propagating" some event, or even adjust the layout 
dialect to accept a keyword

I can still get hard crasches of R3, in various phases:

do %r3-gui.r3
do %examples/run-layouts.r3


Two times I got a crash, when just closing the windows, and when 
at layout #15, clicking in the form. Once I got it with layout #20, 
and once at layout #27, clicking the big red button ...

jsut a short update: We build our first real-life R3-GUI based tool. 
It's a little thing but needed in a lot of companies. It's a tool 
you can interactively create things like heat-maps with. Heat-maps 
for how your IT system landscape looks like, organizational things 
etc. It's a nested layout created with color-mapping for visualization.

robert, can you post a screenshot from a sample headmap?

nested layout means you are arranging small gobs as grid and color 
them or is it a pixelbased image created on the fly?

I had mentioned earlier that it would crash due to complex layouts, 
but this is not the case. The layouts can be very simple. For example 
this one:

1. run graphical version of r3.exe

2. load following R3GUI release from web:

do http://www.rm-asset.com/code/downloads/files/r3-gui.r3

3. execute  this simple layout example:


view [tab-box ["tab1" [] "tab2" [] "tab3" [] "tab4" [] "tab5" []]]

Is there a way to retrieve the name of an object that is referenced 
by another word?
layout  [ a_field: field [ ]  ]
b:  a_field
....
What I want is to somehow get "a_field" given b.

James, in th case of LAYOUT dialect you can get the name this way:

>> b/var
== a_field
>> type? get b/var
== object!

etc.

Wouldn't position-independent code be required even on Windows if 
you wanted to support address space layout randomization (ASLR) and 
other such tricks?

Interfacing with C++ functions and objects requires matching the 
name mangling and structure layout conventions, and those are different 
between compilers. There are some attempts to standardize these conventions, 
but their success is limited. This is why the developers of most 
Unix clones tend to hate C++. The best solution on most platforms 
tends to be to use C wrappers or one of the binary object interop 
standards like COM or CORBA.

C's struct! type is a roundabout way of specifying memory layout. 
A more direct way for specifying memory layout would certainly be 
nice, but if you want to interface with C-like code a lot, you'll 
want memory layout (storage) specifiers that allow you to mimic C 
(ABI) semantics.

Otherwise we can just drop the whole attempt at easier integration 
with C and go with a much more sensible storage layout dialect (think 
e.g. Erlang bitstrings).

the binary emitters (PE, ELF) need to adhere to the respective format 
specification, which is usually supplanted with C struct definitions. 
the primary issue is that C structs have particular (platform-specific) 
memory layout rules, which REBOL's struct! mimicks.

About the [variadic] attribute used in imported functions declaration, 
as you can notice, you don't need to declare any arguments. In this 
context, the attribute is interpreted just as "variable number of 
arguments" and the C calling convention will be used in such case 
(the Red/System variadic stack layout is different than the C one, 
as it also passes the arguments count).

If the Red variadic stack layout is different from C, how can you 
import printf() from the C library? Or do you mean it's compatible 
for imports?

gtk-view window [
	gtk-position-center
	"Widgets Overview"
	icon "Red-48x48.png"
	vbox [
		label "Vertical box"
		fixed [
			label "Fixed layout"
			5 25  button [50 25  "Quit" :gtk-quit]
		]
		hbox [
			label "Horizontal box"
			button ["Fill"] yes
			button "Expand"
			button ["Fixed"] no
		]
		vbox [
			label "Vertical box"
			button ["Fill"] yes
			button "Expand"
			button ["Fixed"] no
		] yes
	]
]

Not many floats are used in GTK, but I need them for layout alignment

I left them in for a while to make the separation with the optionally 
following layout parameters clearer, but in the latest version I 
reconsidered

Implemented a dialect shortcut in most layout styles by adding a 
bare string element, to make the label directive optional

New handier (I hope) chapters layout: http://static.red-lang.org/red-system-specs.html

The only drawback for now is that 64-bit values break the typed/variadic 
stack layout (meant for 32-bit values only). I need to find a workaround 
for that.

The stack layout has changed for typed functions arguments, but it 
is backward-compatible, so all your dialects should work with the 
new version (not tested yet).

Oh and also try "Auto Layout" under Format menu, it makes it nice, 
but make a copy before use it.