AltME groups: search

Tiny (about the same size as TCC), and a good first project that 
could be adapted to wrap LLVM if we like, as long as we keep our 
portion of the extension code license compatible with BSD.

We don't have unsigned *operations* in REBOL. We can have unsigned 
*values* in REBOL by making our own operations that treat the signed 
values of the same size that we do have as if they were unsigned.

the frame size is an artificial limit. 


the frame is just an array, there is no real reason for it to be 
limited to only 7 items, its just an initial limitation, (probably 
to simply the macros and support code).

as an example, we could just represent a draw structure using primitives 
as objects (which can include several AGG primitives) and call AGG 
native code directly from the object tree.

something like 
draw context [
	prim: 'cross-box
	offset: 10x10
	size: 20x20
	thickness: 1
	border: black
	cross-color: red 
]


would draw a box and two cross lines, without the need to reduce 
this at every refresh when its refreshed and data comes from external 
manipulators:

draw compose [
	pen (prim/border)
	fill-pen none 
	line-width (prim/thickness)
	line-pattern none
	box  (prim/offset) (prim/offset + prim/size - 1x1)
	pen (prim/cross-color)		
	line (prim/offset) (prim/offset + prim/size - 1x1)

 line (prim/offset  + (prim/size * 1x0)) (prim/offset  + (prim/size 
 * 0x1))
]

It seems to me that the such a method result will be a program that 
is many times the size and complexity... and hence cost and brittleness.

Of course, I may not be understanding precisely your method.

Jocko, I was able to compile your tts example under visual studio 
express 2010 but with a lot of difficulties :(  
Size of the dll was 19.5 kbs vs your example which is 8.5kb

Has some useful new ext funcs:

	void *(*make_block)(u32 size);
	void *(*make_string)(u32 size, int unicode);
	int (*get_string)(REBSER *series, u32 index, void **str);
	u32 (*map_word)(REBYTE *string);
	u32 *(*map_words)(REBSER *series);
	REBYTE *(*word_string)(u32 word);
	u32 (*find_word)(u32 *words, u32 word);
	int (*series_info)(REBSER *series, REBCNT what);
	int (*get_char)(REBSER *series, u32 index);
	u32 (*set_char)(REBSER *series, u32 index, u32 chr);
	int (*get_value)(REBSER *series, u32 index, RXIARG *val);

 int (*set_value)(REBSER *series, u32 index, RXIARG val, int type);
	u32 *(*words_of_object)(REBSER *obj);
	int (*get_field)(REBSER *obj, u32 word, RXIARG *val);
	int (*set_field)(REBSER *obj, u32 word, RXIARG val, int type);

BTW, I'm not opposed to using something like Spread... does anyone 
know its general size (e.g. complexity level?)


Also, if we went that direction, wouldn't we also want to look at 
MQ in general?

REBOL doesn't have pointers, it has references, and it doesn't have 
addresses. So the only way you could legitimately get a pointer is 
to return it from a command. But you don't want to have any way to 
construct an illegitimate pointer in REBOL and pass it to a command 
because that would be a much worse security and stability problem 
than just having commands at all, and treating pointers as integers 
lets you do that. So there is the handle! type to store pointers. 
A handle! is an immediate value that is the size of a pointer, but 
that you can't convert directly to or from any other value, or even 
mold it to see its contents. When you return a pointer from a command 
you set the value to the handle! type. Then that handle! will be 
usable when passed back to other commands in the same extension, 
and maybe even when passed to other extensions, depending on address 
space issues. Handles are also used to store function pointers in 
R3, and other opaque system values like library addresses.

Oldes: HAve you tested the function with a string including a unicode 
code point which translates to a three-byte utf-8 character? The 
size of utf8str appears to beonly  twice the number of codepoints 
in the REBOL stirng.


A good example of a three-byte utf-8 character is the Euro sign - 
Unicode 20AC UTF-8 E2 82 AC

now I see that in host-graphics.c is used something like:
u32 w = RL_FIND_WORD(graphics_ext_words,RXA_WORD(frm, 1));

            switch(w)
            {
                case W_GRAPHICS_SCREEN_SIZE:
                    x = GetSystemMetrics(SM_CXSCREEN);
                    y = GetSystemMetrics(SM_CYSCREEN);
                    break;

                case W_GRAPHICS_TITLE_SIZE:
                    x = 0;
                    y = GetSystemMetrics(SM_CYCAPTION);
                    break;
...

hm.. I think I understand how it's supposed to work now, but it looks 
it's just a temp solution. Here is the init part for graphics:
words: [
	;gui-metric
    screen-size
    border-size
    border-fixed
    title-size
    work-origin
    work-size
]
;temp hack - will be removed later
init-words: command [
	words [block!]
]
init-words words

Brian: actually the values on the 'command frame' are 'free value 
slots' as they are not part of any series...they are just in plain 
fixed size array. But  this is probably just playing with words ;)

Next question.. when I have:
		case CMD_MagickGetImageColors: {
			if(current_wand) {
				RXA_INT32(frm, 1) = MagickGetImageColors(
					current_wand);
				RXA_TYPE(frm, 1) = RXT_INTEGER;
			}
			return RXR_VALUE;
		}

While compilation using GCC I get this warning: use of cast expressions 
as lvalues is deprecated

The command is working, just would like to know if I can improve 
it somehow. The function is defined as:
	size_t MagickGetImageColors(MagickWand *wand)

there is a method to restrict the window size. perhaps it is a bit 
too aggressive, but the option is needed in some cases.

Henrik - dunno what you mean by crash - but no, R3 console does not 
crash, but I get rebol level crash:

handler added
** Script error: cannot use pick on none! value

** Where: second all resize-text-face remove-text-face switch either 
do-text-key

 if actor all do-style until either do-event do-event either applier 
 wake-up loo
p applier wait do-events if view

** Near: second get-facet face 'viewport-size tgob/size/x: face/facet...

>>

gmask: make gob! [image: bmask]
gmask/offset: 30x0
gmask/image: bmask
probe type? bmask
probe gmask

== image!
== make gob! [offset: 30x0 size: 60x60 alpha: 0 image: none]

weird.  maybe the image gob type has been dropped?

box clipping of gobs is making them harder to use than they should 
for general graphics use when gobs are nested into panes. 

it would be nice to be able to support a clip? parameter.


for example, it would be nice to be able to use 0x0 as the origin 
in which to draw (so that negative offset values be used in the draw 
block), but we can't unless we always add a transform to the draw, 
which has to managed along with the size at any change in size.


go three pane deep, and we have to manage all the hierarchy all the 
time its pretty complicated for nothing.  


pane grouping should allow them to be used, just for transform, not 
only for visibility.

cause the picture size had to be small and since their is auto resizing 
that means nothing ...

http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3


Newer version too. Sorry about the ballooning in size, but this is 
due to a change in the build system.

what I did was create a GUI similar to this one:

view [
	panel 1 [check]
	panel 1 [button button button]
]


When you resize this vertically by a few pixels, the bottom panel 
will resize incorrectly. That is known and will be fixed. What I 
managed to do, was to either move or resize the window in a way, 
that would cause resizing to get stuck in a loop (!), so it goes 
up and down in size by a few pixels vertically on its own, and the 
window just sits there shaking up and down in size. If possible, 
we would like some help with reproducing that.

I haven't tried it, and I'm not sure it's a specific size that does 
it, but more a series of events. The testing system is not yet in 
place to do it this way.

I don't care if it 30MB in size.   I could help you with the debugging, 
but right now its very tedious to do.

the same result ... I would expect y size of field being bigger?

It was caused by some difference in window size handling between 
XP and Vista/W7.

They seem to be the same size, but, just to be safe:

http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

Got a pattern on the resize loop bug, but I guess it requires a very 
specific VM setup:

1. Start the R3 GUI and make a window. Maximize it.
2. Resize the VM desktop window

3. Hope that your resize action is slow enough to allow you to doubleclick 
the titlebar to de-maximize it.
4. Now it loops between maximized and normal size.

Perhaps there is some confusion about screen-face size changing.

re 'area style - trying auto-scrolling or scrolling in general:


1) still the same bad aproach as with R2 area - I don't care that 
it does not hilite right now, that can be added, but when dragging 
the mouse outside of the area, it stops scrolling, and that is wrong 
- it should scroll even if I move mouse out of the window, wherever 
around my 2 monitors ....


2) when I start dragging, the proportional size of scroller is lost, 
and it gets reset to its full-size dragger ....

min-size was too small, that was all :)

I don't understand! Scroller can do only following work - move slider, 
set slider size, react upon mouse-over. That is all. And scroller 
will never do anything else. The rest is the work for corresponding 
style on-scroll handler, which can do whatever is needed for the 
style ...

Henrik -- FYI: Can you confirm an odd behavior for me?  Whenever 
I minimize a panel and reopen it, it works as expected.  When I resize 
the object to a bigger size, minimize it, then reopen it, I get a 
weird strobe effect of the two panels, one the original size and 
then the other at the bigger size.

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

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

 - that is important to know, and it will be missed by many, unless 
 properly documented ...

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?

Max - Which brings up the point of what controls the size. Do the 
sub-faces control the size of the panel, or does the panel control 
the size of the sub-faces?

Ladislav - Yes.

Maxim it looks great but it's too open ... in my idea what you show 
with elixir should be part of  it  the "free to add thing" part but 
the other part is we have a set of ready made boxes/items you just 
need to set an execution path and give them some related information 
like position size text etc...

Imagine saving the size, ordering, freezening of grid columns for 
e.g. It would be tiresome for user set it each time app starts .... 
just an idea ...

I have a very basic question, that I have already asked to Carl : 
how to get a working gui.r version ? when doing load-gui, I get the 
following error message : ** Script error: size-text has no value. 
It seems to me that this point should be definitely fixed, as it 
prevents anybody to do view tests (for instance the ones given in 
the reference doc http://www.rebol.com/r3/docs/gui/guide.html) I 
think that this should be done quickly and independently of any improvement 
and evolution of the gui styles and functions.

The patterns will be repeating for a good size of already existing 
styles, such as fields, buttons, so I don't agree with the current 
approach. It will also take longer to create the skin, when we get 
to that point.

Just tried to run the style-browser.r3 on Amiga and hit the following 
problem
>> do %r3-gui.r3

Script: "Untitled" Version: none Date: none

>> do %style-browser.r3

 Script: "R3 GUI Style Browser" Version: $Id: style-browser.r3 1179 
 2010-11-19 18:11:46Z Rebolek $ Date: none
** Script error: cannot 
 MAKE/TO image! from: make gob! [offset: 0x0 size: 400x300 alpha: 
 0 draw: [clip 0x0 400x300 anti-alias false pen false fill-pen 192.192.192 
 box 1x1 399x299 0 fill-pen false pen 64.64.64 line-cap square line-width 
 1.0 variable line [0x0.5 399x0.5] line-cap square line-width 1.0 
 variable line [0.5x0 0.5x299] line-cap square line-width 1.0 variable 
 line [0x299.5 399x299.5] line-cap square line-width 1.0 variable 
 line [399.5x0 399.5x299] clip 6x6 394x294 translate 6x6 line-width 
 1.0 variable pen 255.255.255 fill-pen false anti-alias true clip 
 0x0 0x0 pen false line-width 0.0 variable grad-pen linear normal 
 1x1 0x2...

Any ideas?

GUI version 0.2.1 snip ...size-text has no value ... snip

I aven thought about possibility to link to native widgets, but just 
to mimick skin parameters. I am not sure it is possible, but when 
you e.g. create skin, which looks like OS native one, then users 
will be confused, if you set OS native feel differently. Under windows, 
there's not much of possibilities, except for some Windows bar size/decoration, 
or font size. But under AmigaOS and e.g. MUI, you can change the 
look of widgets quite a lot. The question is, if someone would be 
willing to simulate such a complex system as MUI is, and define all 
the skins. The app would also have to be notified, that user changed 
central setting, to readjust ...

Am I missing something really basic......Here's my first attempt 
in many months to play with the R3 GUI.
New console session, R3-a110.exe:
    >> load-gui
    Fetching GUI...
    GUI Version: 0.2.1
    (Developer test GUI theme)
    ** Script error: size-text has no value

    ** Where: font-char-size? make make-text-style parse fontize do do 
    either load-gui
    ** Near: font-char-size? self

A show face user poll:


We decided to introduce a face attribute allowing to implement the 
following show states of a child face of a panel (or, eventually, 
other container):


1) the face is visible and it resizes/repositions together with its 
parent panel

2) the face is invisible, but it resizes/repositions together with 
its parent panel, reserving the appropriate amount of empty space 
for itself

3) the face is invisible, it does not resize/reposition itself together 
with its parent panel, the positions of other faces in the panel 
aren't influenced by the presence of the face

4) the face is visible, it does not resize/reposition itself together 
with its parent panel, the positions of other faces in the panel 
aren't influenced by the presence of the face

Possible implementations:

===A


Define a new SHOW? facet (you may indicate your preference to use 
a different attribute name, if you like), which could be set to one 
of the following four REBOL words, corresponding to the above defined 
face show states:

A.1) VISIBLE
B.2) HIDDEN
C.3) IGNORED
D.4) FIXED


(you may indicate your preference to use different words, if you 
like)

---Advantages


*The user can to determine the show state of the face by examining 
just one attribute, the SHOW? attribute.

*When using an appropriate function, the user will be able to change 
the show state of a face by evaluating a

    SHOW-FACE state

expression.

---Disadvantages


*Data are not normalized, seen from a data-related point of view 
- if a user sets the FACE/GOB/SIZE value inappropriately (e.g. if 
FACE/GOB/SIZE is 0x0, while the SHOW? attribute is set to FIXED, 
or, if the FACE/GOB/SIZE is non 0x0, while the SHOW? attribute is 
set to HIDDEN), the state he obtains will not be consistent.

*Speed - since it is necessary to test which of the four variants 
has been chosen, we need to use four tests in resizing code, i.e. 
the code becomes slower.

*More complicated code - it is necessary to take care the state is 
consistent, which may require more complicated code, maintaining 
state consistency.

*Documentation - the users need to be aware, that not all changes 
produce consistent state.

===B


Since the invisibility of faces is already implemented by setting 
the FACE/GOB/SIZE value to 0x0, we need to implement only an attribute 
telling, whether the face resizes/repositions with its parent. A 
RESIZES? attribute (you may indicate your preference to use a different 
name of this attribute) is used for the purpose in this variant, 
possible values will be TRUE and FALSE.

---Advantages


*Normalized data - all four possible state combinations are meaningful, 
and consistent.

*Speed - when needing to test whether the face needs resizing, only 
the RESIZES? attribute needs to be checked.
*Code simplicity

*Documentation - the user does not need to memorize the possible 
inconsistencies

---Disadvantages


*The user does not have the SHOW-FACE function, but, if required, 
it can be implemented easily, it can even use the keywords mentioned 
in the A variant, just translate the state to respect the B implementation.

*The user will not find the keywords in the face data, but it does 
not look like a disadvantage one should be afraid of.


So, please, indicate your preferences for the show state implementation. 
As far as I am concerned, I am strongly in favour of B, so the initial 
score of the show face poll is:

A:B = 0:1

hmm, regarding your question: the VISIBLE is OK. The initialization 
of HIDDEN is probably not, since 0x0 sets up the INIT-SIZE, which 
is needed for resizing, i.e. it should be nonzero even for HIDDEN, 
I guess

yes, we could use gob-size in OPTIONS block as 'gob/size setter' 
too.

I did not mean GOB-SIZE - that already exists as INIT-SIZE, what 
I had in mind was the HIDDEN keyword

Do you really hide something by setting its size to 0x0?

I didn't mean that. Of course you hide something when it is set to 
0x0 size. I was asking if that was how you set something to be hidden: 
setting it to 0x0 size. That might have interesting effects on the 
layout of its contents when it is unhidden, while a hidden property 
would not.

About showing faces: In R2 I found it quite annoying not to be able 
to create an image of a layout without viewing it on screen first.

If I did things like set the face size to 0x0 or move the faces outside 
the window bounds, clipping would introduce artefacts (black regions 
not supposed to be there) in the image created by TO-IMAGE.

So, in R3 at least, I'd like to be able to create an image of a panel 
layout in R3 without first viewing on screen.

I think I thought that an UPDATE FACE function, being similar to 
SHOW FACE, except without the final copy to the window buffer, might 
be what's needed.

Late to the game, but


as for A) - don't we have already tags? It could all be in the tags 
block, not in the new field. And if tags block is just flat, and 
those for states could collide with another flag names, we could 
use nested blocks flags: [ show? [visible]]. I see no reason why 
to introduce new field, unless from the speed reasons

Generally I like B) more, but:


I definitely don't like being dependant upon the size of 0x0? That 
seems really strange to me. Visibility state in the gob-tree should 
be imo independent from the size? E.g. look at Cyphre's code example:

button 0x0 "test" options [resizes?: true]

Do you really want to see code like that in the VID level?

Cyphre: "Brian, yes, what would you want to see on the screen if 
something has zero size?" - really, I am not sure I care about if 
something is theoretically visible in 0x0 size, because face itself 
will not have a meaning even with 1x1 size, but I think that visibility 
(event flow) should be separate. OTOH, I can't find any practical 
reason how it could be internally usefull to have some inner state 
as shown, while being at 0x0. I thought about some graph models, 
event flows via the face hierarchies, etc., but with 0x0 size, you 
can't receive events anyway (apart from timer events maybe)

Max - speak on :-)

If so, you can't auto-hide the face by just setting its size to 0x0? 
That seems like an ugly hack to what could be implemented by 'hide 
function? Well, if we have 'show, why don't we have low level 'hide 
one?

Yes, not a big deal for me ... except the idea of using size 0x0 
to express the hidden state :-)

Image the UI animated. You have button with size 100x20 that gets 
smaller until it reaches 0x0 which effectively means it gets hidden.

I don't agree with having 0x0 as hidden. It is an implied state, 
that would occur any time the X or Y size becomes zero. There are 
behavioral issues to consider, such as, whether you want to obtain 
data from the face, using GET-PANEL, or how tabbing and disabling 
behaves with a zero sized face. If the layout is dynamically created, 
so that a face is inadvertently presented as zero-sized, you will 
get topological side-effects.


For animation, you would have a start and end position. Animations 
should not express anything about face states. Only dimensions, offsets, 
transparency, colors, easing are relevant with animations.

I agree with Henrik, and I reiterate my uneasiness with face size 
0x0 == hidden. Conflating the two concepts creates the problem of 
how to separate them, which may be difficult, or impossible.

I would not like that in order to hide a face, I would have to set 
its size to 0x0. That means that in order to restore the visibility, 
I must store its previous size somewhere else. So squashing two concepts 
into one value means one or both of them just pops out somewhere 
else, confused, or some state information is lost.

New 'X-mas' release of R3-GUI is available for download at http://www.rm-asset.com/code/downloads/

top-level changes:

-smarter face update mechanism
-improved dynamic panel content handling
-internal optimizations and more system-friendly redesign
-cleanup of obsolete code parts

some more detailed notes:


- panels can now contain normal, VISIBLE faces, HIDDEN faces (just 
invisible, but taking the same space as the visible faces), IGNORED 
faces (invisible, and not taking any space), FIXED (visible, but 
not resizing with the panel, having a fixed position and size)

- the ON-CONTENT actors for all panels (HGROUP, VGROUP, VPANEL, HPANEL) 
now are as much compatible with series function as practical, taking 
an integer index, high-level function can take a gob or a face to 
specify the position as well

- Data optimization: FACES attribute removed to not need to store 
and maintain the same information twice, risking the conflicts (they 
were already present, order of faces was not identical)


You can also download the latest R3.exe from our site which contains 
LOAD-GUI that directly loads the actual release. This way you are 
always using the latest R3GUI codebase.


We'll be updating the 'old' documentation soon to be up-to-date with 
our current R3GUI version. So interested developers can start using 
it for real or participate on the project.

boxg: make gob! [offset: 20x20 size: 320x320 Draw: [pen red box 10x10 
317x317]]
win: make gob! [text: "Test" size: 500x500]
append win boxg
view win

In RMA A110, this simple lines gives error too :


boxg: make gob! [offset: 20x20 size: 320x320 draw: [pen red box 10x10 
317x317]]
view boxg

** Script error: expected command! not pen
** Where: show view
** Near: show window if all [
    not opts/no-wait 1 = length? screen...

Is that a resizing bug? I tried to lower the Y size of panels-21.r3 
test window, and got following:

http://xidys.com/rebol/resizing-bug.jpg

Why some buttons got thinner?

Ok, I see now what it means. That looks like correct behavior to 
me, as you are in the child VPANELs adjusting the vertical min/max 
size of the button. The demo inadvertently uses both child VPANELs 
to define the maximum vertical sizes of the parent VPANEL cells. 
This overlaps the resizing behavior of the child VPANELs, so I can't 
tell from this test, what is causing the buttons to be squashed. 
A child HPANEL that takes up the entire vertical size of the parent 
VPANEL should display identical behavior to a child VPANEL.

On a side-note: Faces like buttons should not have any flexibility 
in the vertical size. That makes the UI less consistent to look at. 
The smaller the elements are in a direction, the less you want them 
to resize. A horizontal SPLITTER face or a horizontal BAR does not 
resize in its vertical direction.

The parent "vpanel2" contains 2x vpanel, 2x hpanel. And one of vpanels 
and one of hpanels gets the Y size of button stretched ...

Sorry, I mistook the third panel for a VPANEL, but that just simplifies 
the explanation that this is not a bug:


1. The button can vertically resize, as its min/max size is not the 
same. This is correct behavior according to the specs of the style. 
This is not the same as saying that this is esthetically sensible 
behavior in the button style.

2. The panel in which the buttons reside can also resize vertically, 
because the button can resize vertically. This is correct behavior.

3. The parent VPANEL, when resized vertically, can resize its inner 
faces to their limits, like an accordion. The limits are defined 
by min/max size. The second and the third panel, which both display 
squashed buttons do this, because their vertical size define the 
vertical size of the two cells of the parent VPANEL. This is correct 
behavior.


To get rid of the problem the button should have vertical min/max 
size being the same. That's all.

A simpler way to show exactly the same behavior is:

view [vpanel 2 [hpanel [button "1" button "2" button "3"]]]

Guys, time to crank up the volume and build a concrete roadmap for 
the GUI. I have a suggestion to further accelerate the development 
of the GUI: RM Asset will over time require some specific, but complex 
styles, that the community will need as well. We are developing a 
SCRUM tool, which you will need to use as a basis for discussions 
and development of these styles. Consider it also training to become 
a good style developer. For any needs, Cyphre, Bolek, Ladislav and 
I will be available to extend the UI base as needed to create the 
styles mentioned below. We also provide examples, training and help.


Many of these styles are focused for development of particular types 
of applications that open many, small windows inside a large work 
area for flexible construction of data analysis tools and other traditional 
Windows or Linux applications.


It could be a combination of how graphics shader networks are built 
(though without the need for zooming), to regular multi-document 
management. The ultimate goal is to build styles that allow a highly 
user configurable multi-document GUI to be described, using only 
the R3 GUI dialect and some helper functions that we already have.

These styles are generic enough to be usable in plenty of apps.

Inspirations for window arrangements:


http://houdini.dreamerzstudio.net/wp-content/uploads/2010/05/reflectiveShaderNetwork.jpg
http://www.codeproject.com/KB/docview/TabbedMDI/TabbedMDI.gif

Inspiration for segmented area management:


http://www.solidsmack.com/wp-content/uploads/2010/12/modo_501_RayGL_sample_002.jpg
http://jedit.sourceforge.net/jedit-snap-12.png

A list of general styles that definitely are needed:


- Style for doing multi-document window management, using various 
arrangements, window linking features, as borrowed from apps like 
Photoshop.

- Style for segmented area management, editable by users, for arranging 
tool areas, view areas. Segments are adjustable in size. Inspiration 
is JEdit and Modo.
- Multi-document window style, for use in window management style
- Tool window style, for use in window management style

- Tear-off style for toolbars and tool windows, for use in window 
management style

- Regular Windows-style menu bar with submenus, also for right-click 
popup menus.

More specific styles that will be needed later:


- High-performance style for graphing points and curves in a coordinate 
system, with zooming and panning.
- Gannt chart style: http://en.wikipedia.org/wiki/Gannt_Chart
- Harvey Ball style: http://en.wikipedia.org/wiki/Harvey_Balls
- Year calendar style
- Month calendar style
- Week calendar style
- Day calendar style

- MacOSX style tag field: http://kitara.nl/wp-content/uploads/2010/05/31.png

- Console style for input and listing results. This could eventually 
grow into the base for a View based R3 console.

- Highly ergonomic numeric input styles, that support unit conversion, 
inline math.

The question is where to start and what fits with you.


The time table is simply ASAP, and preferrably want some results 
within the next 2 months.


If you are planning R3 apps soon, it would be a good idea to have 
a look at the list to see where you may be able to contribute, as 
the GUI moves to beta status. RM Asset needs to spend time building 
end-user apps for R3 and the GUI is becoming ready, except for the 
above mentioned styles.

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

I can see, that along the min-size, max-size parameters, we can now 
set init-size parameter. Why was option to set max-size removed from 
panel? Because resizing system does take care for that? I also noticed, 
that make-panel can't anymore accept options block. So you found 
it not being necessary?

MIN-SIZE and MAX-SIZE of panel - currently, those values are computed 
by the updating software. Do you think we should allow the user to 
set these? When you think this should be allowed, and for what purpose?

MIN/MAX-SIZE: I'm not fond of the idea of having the ability to set 
certain style variables in too many places. That said, setting them 
in styles rather than in layout is a decision that is hard to predict 
the outcome of, when using the styles in different layouts. I never 
really liked MAX-SIZE, but I suppose we can't get rid of it.

MAX-SIZE is totally necessary, if you want to have a resizing algorithm 
respecting the MAX-SIZE attribute.

none of my algorithms have max-size and its never been a problem 
in any layout I wanted to do.

though there is nothing stoping me from adding it to a specific frame 
variant within my stuff.  I've just never found it to be that usefull. 
in general, when you want max-size, actually what you want is static 
size.

the problem with max size is scaling the extra-space.  it never ends 
up scaling, quite right.  its better to have some of the things static 
which leaves space for the "space benefiting" areas.


then, whatever would need a max-size, should have a manual resize 
bar (which might be blocked so  but doesn't require support in the 
actual layout)

the problem with max size is scaling the extra-space.  it never ends 
up scaling, quite right.
 - again, did you see some of the examples?

I've never, ever found MAX-SIZE useful for anything, because it doesn't 
fit intuitively in a layout situation, where there are much simpler 
means to produce a similar result. I suppose it makes sense for Carl 
in his old resize system, where MAX-SIZE was (shudder) tied to weighting, 
which produced some completely unpredictable results.

MIN-SIZE makes perfect sense, though.

Well, relating MAX-SIZE to weithting was a bad idea, and we corrected 
that.

Ladislav: ""I can see you use empty rows...Aren't we wasting memory 
here?" - how can an empty row waste memory?" - :-) This is misunderstanding 
:-) My question relates to my previous discussion with Cyphre, about 
removal of 'faced element. Previously, we had facets, and faced (instance 
locals). Cyphre pointed out, that now everything is instance local, 
and goes into facets. If you want stuff to be shared, new 'intern 
slot should be used.


And that was my question - I can't see intern used anywhere in the 
stlyle definitions. What I noticed is, that in the facets blocks, 
stuff is somehow visually separated by empty rows. Hence my question 
- if I see things like min-size, max-size - aren't those a good candidate 
for items being shared? And if those are not shared (referenced), 
we are kind of "wasting" memory here. I think that it will not be 
significant though ...

well, the margin shouldn't be probably relative to the gob/size but 
rather absolute pair position  so it is possible to define paragraphs 
that can be scrolled.

( so in this example it could be: margin (gob/size - 20) )

margin only inside the size of the column of course.

Oldes, imagine you have gob of 200x300 size but you want to have 
layout of two paras in total size of 400x600. In such case you'll 
set MARGIN 400x600 to ensure the paragraph layout is filled inside 
this space. And then you can use SCROLL to move the content inside 
the gob.

Using margin for specifying width of the text is strange.. or I miss 
something. When you want text with size 400x600, why to specify it 
by margin?

sorry, SIZE

I'm trying to compile a host-kit for amiga.. getting an error from 
RL_Init() stating Host-lib wrong size

ok in the include file  "host-lib.h"

there is an entry at the begining that says:

#define HOST_LIB_SIZE 31

ssolie, try a size of 33.

so the HOST_LIB_SIZE must match whatever the libr3.so thinks it should 
be?

the HOST_LIB_SIZE is generated via a script according to the header 
comments

Let's just do a quick sanity check before wasting more time on this. 
Change the #define HOST_LIB_SIZE in host-lib.h from 31 to 33 and 
see if you still get the "wrong size" error.

ignore the SUM/SIZE stuff at the top, which obviously has changed

libr3 on Linux and Amiga expects a hostlib vector of size 33, r3.dll 
on Win32 one of size 31.

win: make gob! [text: "Test Window" offset: 100x100 size: 300x200]

ssolie: the really 'bare-bone' sequence to show window is:


show append system/view/screen-gob make gob! [text: "Test Window" 
offset: 50x50 size: 200x200]
wait system/view/event-port

I'm trying to run the hello world example at http://www.rebol.com/r3/docs/gui/guide.html

Here is what happens when I try load-gui:
>> load-gui
i
Fetching GUI...
GUI Version: 0.2.1

(Developer test GUI theme)

** Script error: expected command! not font

 ** Where: size-text font-char-size? make make-text-style parse fontize 
 do do either load-gui

** Near: size-text gob

Is this a host-kit issue or ?

Downloaded .zip file. Tried it now - it works. It just does not seem 
to copy dll to the place of the exe, or something like that:

Linking executable: bin\Release\r3.exe
Output size is 317,50 KB
Running project post-build steps
post-build-win.cmd bin\Release\

Execution of 'post-build-win.cmd bin\Release\' in 'C:\!rebol\!R3\r3-host-kit-A110\make-cbp' 
failed.
Nothing to be done.

It still does if you use msysgit. But not much of an issue unless 
you really care for download size.

Git is Small
 is referring to repository size.

When looking at my pc I installed this in these days: msysGit-fullinstall-1.7.0.2-preview20100309.exe 
then installed Tortoise over it.

Then when I check size of c:\msysgit\ dir I got 1 307 758 191 bytes


I'll try to uninstall and use the latest version to see if it is 
better.