AltME groups: search

Add this to your configuration, and you will be able to use Ctrl-5 
to run rebol3. Change the path as needed.
command.name.5.$(file.patterns.rebol)=RunRebol3File

command.5.$(file.patterns.rebol)="C:\usr\local\rebol3\r3.exe" "$(FilePath)"
command.subsystem.5.*=2
command.is.filter.5=1

Pekr, that's list-box (text-list) style problem. This style is currently 
updated to support more columns than one (called text-table) and 
text-list will be only sub-case of text-table.

The new distribution channel may bring problems like this for regural 
users, at least before BETA is reached. Some developers prefer to 
put changes to SVN only when everything is ready, other developers 
prefer to push changes more often, it might temporarily broke functionality, 
but  it's much more crash-proof strategy.

It's a question to debate if every submit should be a release, or 
if only some special versions should be released, with first option, 
you will get latest release, that may be broken because of we're 
still in alfa-phase, with second option you will get more or less 
working release, but you're definitly going to complain that it's 
not updated too often (even if my estimate of 1-2x week is hit.)

i just try it and it gives me that >> do %style-browser.r3

Script: "R3 GUI Style Browser" Version: $Id: style-browser.r3 1220 
2010-11-26 13
:18:02Z cyphre $ Date: none
** Script error: guie has no value
** Where: catch either either -apply- do
** Near: catch/quit either var [[do/next data var]] [data]

xavier - see my previous message and Rebolek's explanation. My take 
is,that it sould be adapted to release, or ppl will find GUI highly 
non-working ...

The trick in communications is to keep reminding those people that 
this is alpha work in progress and that if they want something that 
works, now, they have to go look somewhere else.

Otherwise, the only option is to shut down completely and not do 
any development work in the open, but only in invisible elitist circles. 
We all know how well that approach has served REBOL in the past.

well, it did not show single styles. It more showed whole topics, 
so you could see the whole forms with various styles, their setting, 
resetting, etc.  And yes, it was about the impression. I'll wait 
for style-browser fixes - the truth is, that it was never bug free 
:-)

whatever ... this is just playing with words, and I think it does 
not matter, as it is not a big deal (btw - when I found the bug, 
I reported it). My observation though is, that ppl naturally expect 
some visual demo or something like that - being it a former demo, 
or a style-browser - it does not matter. So - hopefully when things 
turn more stable, we could ask Carl to link R3 console demo function 
to launch a style browser?

this is just playing with words, and I think it does not matter

 - sorry, I think you don't understand the importance of the style 
 browser as a *testing* tool rather than as something to show off 
 with.


If we blamed the style browser for the bugs, we'd never finish the 
GUI. I really mean that style browser bugs are irrelevant. Any more 
development on it would be to make testing more thorough. At this 
stage, it's important to build the programs as we want to see them 
working, and if they don't, the underpinnings are to blame and should 
be change to accommodate the needs. That is what's going on now.


We publish the style browser to help users get the quickest possible 
overview of the styles as they are right now, crashing or not. Showing 
off is too early.


It should be possible to have the style browser as part of the demos.

Browser still sounds like a working utility. It could mention that 
it's for testing the styles and they are currently expected not to 
work

Jerry, the R3 stuff we have uses Freetype and should be able to handle 
Unicode.

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

And, as another poll question: do you find all four alternatives 
useful, or would you prefer to use just some of them?

I prefer a normalizexd model, as long as it makes sense and is easy 
to work with. So, tentative support for B unless we can come up with 
something easier.

So my and Ladislav's decission so far:

-use SHOW? hidden | visible | ignored and optional GOB-OFFSET in 
OPTIONS block during layout initialization only (after the face is 
build the valueas are unaccessible in this form)

-use SHOW-FACE face hidden | visible | ignored function in all other 
cases when layout is already initialized.

Does RM-asset version of A110 support the SHAPE dialect? I can access 
the glyphs in OpenType Font File now, and I would like to draw the 
Chinese characters using SHAPE dialect in R3.

wow, a progress ... will read it shortly .... guys, I have one question, 
which will most probably get dismissed, but I'll at least try to 
ask:


- when prototyping stuff in console, and e.g. when your gui crashes 
from some reason, I am very used to just "unview". But - in R3 I 
have to do either "unview none" or "unview 'all" (not caring about 
the name of the window)


So my question is - couldn't the aproach be rethought, and old R2 
functionality brought back? Especially "unview 'all" in comparison 
to (imo) more rebolish R2 "unview/all" is non intuitive for me ...

my opinion is, that most of the time I just want to unview everything, 
and only from time to time I want to unview particular window

Jerry, shape dialect is fully supported. Also note you can use chinese 
glyphs as normal unicode chars in the richtext dialect so no need 
to render it custom way in R3. Also any feedback on the rendered 
unicode fonts usage would be useful as it was just tested in basic 
tests and not in any native language like chinese, japanese etc.

Cyphre, Thanks. I'd just tested it. Chinese characters can be rendered 
correctly and perfectly.

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?

I see no reason why to introduce new field, unless from the speed 
reasons

. Yes, it's faster and the code is also easier to handle for user.
already decided
 - really?

Rebolek - by "decided" I meant Cyphre's message stating what they 
agreed upon with Ladislav, and Robert kind of seconded :-)

SHOW-FACE and HIDE-FACE allowed only two states, this method allows 
more states.

compare the code:

show-face face 'hidden
hide face


which looks more readable to you? ;-)  Why to overload show? We have 
'View, and 'unview. And with two separate functions serving its purpose 
you can implement more functionality for each of them imo ... I must 
be missing something :-)

you can use refinement. I can see, that with R3, we departed from 
refinements ... why? Look at 'unview ... unview none, unview 'all 
.... why not just uview, and unview/only, as with R2?

it's not just show/hide face anymore. SHOW-FACE sets face's visibility 
and usability mode. Maybe you can come up with better name, this 
one is left from previous implementation even if does currently something 
different.

Yes, generally all possible states - visible ignored fixed hidden 
no-resize etc. could be part of a bitmask, and IIRC that is the aproach 
win32 is taking. I thought that named bitmasks are implemented, but 
they were removed.

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.

Animation should be an entirely separate part, to make it easier 
to discuss, design and change when the time comes, possibly an extension 
of SHOW-FACE.

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.

I prefer to have it designed properly, rather than to rush the implementation. 
And I agree with Max - there is imo long time plan to have extension 
API for devices ...

I used it only several times - to initialise GUI automatically, and 
to create a primitive gif-anim player ...

It seems like the SHAPE dialect in RM-Asset version of A110 is different 
from the original one. Is that intentional? I cannot draw and fill 
Chinses character glyphs using this version.

Actually, I think It's bug. For example, MOVE seems not working at 
all. LINE used to mean LINE-TO, now LINE are just LINE. ... and so 
on.

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

Oldes, VIEW is due for an overhaul and the concept of viewing any 
(or at least most) REBOL datatypes is something I wish to implement, 
but that's low priority at the moment.

That's the main reason why to have public repo.. so one can at least 
see what is changing... and maybe also why.

GUI work log update: currently, the ON-CONTENT actor is being reworked. 
Interface and behaviour are being changed (different arguments, adjusting 
"boundary case behaviour"), some bugs revealed and corrected during 
reworking as well.

re blogs - maybe not examples, but it would be nice to know, what 
is e.g. planned. As e.g. Ladislav posted on-content, I believe Cyphre 
might be planning/doing some low-level stuff changes too, or some 
changes for some styles. But I can understand the "busy" argument, 
so maybe the best aproach for those interested is to trying to test, 
and when having the questions, just asking here ...

And it is related to GUI project as GUI project is the one where 
the draw is implemented as commands.

I can't guarantee that it will work. There is a build script missing, 
but the resulting build should be similar to previously released 
builds. We have diverted from the build system to something else 
now, and I can't publish that build scheme.

There are also some docs and comments in code:)

GUI work log update: ON-CONTENT revision done, debugging the changes. 
One of the changes is a removal of the PANEL/FACES block. Reasons:


- data aren't normalized, since the contents of the panel are listed 
both in panel/gob and in panel/faces

- thus, twice as much memory used, and unnecessary maintenance of 
the panel/faces block is necessary

- the not normalized nature was visible anyway, since the order of 
faces was not guaranteed to be the same

- to get the block when needed, it is possible to use a FACES? function 
returning such a block on demand

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.

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

well some guru could do this job and show us bests practices with 
load-gui !

For example I would prefere FACES-OF instead of FACES? as Anton sugested.. 
in the latest sources is used faces? And there is more such a cases 
which I don't like. I really use the names ended with ? only for 
logic.

the functions map-inner and map-outer are not used anymore?

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

Updated to latest sources and a build is now inside as well.

Oldes: there are a number of REBOL functions with a ? that return 
something other than boolean - length? and type? immediately spring 
to mind!

I can see that they would be more meaningful if they were called 
length-of and type-of  though.

Ladislav: and what about words-of, values-of? Those did not exist 
in R2, but were added to R3. Faces-of fits that naming scheme ....

having consistent naming conventions across the board is imo always 
a tough call. Naturally I can understand, why you have selected short 
"faces", and adding question mark ...

Even in R2 we had maximum-of and minimum-of.

In R3 A110 we have 8 "-of" words and 16 non-logic! "?" words (+4 
"?" console convenience words).

I don't mind '?' being use to indicate a question, but I think the 
"-of" words more accurately reflect what information is being extracted 
FACES?
 - it's like  "huh?" - it's vague, someone's secret language.

(Maximum-of and minimum-of were poorly named; I wanted them changed 
to 'at-maximum(-of)' etc since they return the series at the index.)

Just a warning.
Don't be seduced by the Dark Side of the Force. 

It's what I dislike the most in all actual popular languages. I mean 
, the bad habit to outrageously extend the names of variables and 
method.

The exact meaning of variables and methods is given by the context 
of the use case.
That's why they don't need to be over explicit.
And If you have any doubt, you can use HELP, at least in Rebol.

Btw, I vote to keep FACES?.

When i see ? in a word's name, i know it may be a boolean or a calculated 
value (actually a function).
If the context is not clear enough, I invoke HELP.

Actually, I would have choose the name CHILDS. It's more polymorphic, 
and it can apply on faces or gobs.

It was just a warning.
The Devil is in the details. 
-of

 could be the devil seed and give birth to abominations, like: get-faces-of-a-face
But I am conforted now ;-)

Just throwing something out here (as I'm not actively involved in 
R3 and mostly lurk):  I see "-of" as a "what" or "what are" type 
of question, while "?" more like "what is" (and all the rest) type 
of question.
(does it) exist?
(what is the) length?
(what is the) size?
(when was it) modified?
vs
(what are the) faces-of
(what are the) values-of

Then of course, minimum-of and maximum-of break this idea:
(what is the) minimum-of
But this works just as well IMO:
(what is the) minimum?


So looking at that, I'd consider the "?" or "-of" question to not 
so much be based on logic values, but whether it returns a single 
value, or a list of values.

Ladislav, actually I don't see what you said in this function. I 
 only see that a gob and its gob/data/gob must be the same, which 
is rather curious

I  only see that a gob and its gob/data/gob must be the same

 - that is what I thought as well. But, aftter causing crashes, I 
 had to rewrite the FACES? function to make up for the "faceless" 
 gobs, as I mentioned.

To my mind a faceless gob may have its gob/data == none!
And even if it has an object , the gob property may not be here.
the faceless? function is not safe

hello.  I got to run the R3 gui and got some troubles : i use the 
r3-a110-3-1(1).exe and the r3-guihttp://94.145.78.91/files/r3/gui/r3-gui.r3
and run this : do %r3-gui.r3 and got this in return :

>> do %r3-gui.r3

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

** access error: cannot open: shape reason: "module not found"

>> import %r3-gui.r3
** Script error: datatype assertion failed for: spec/version
** Where: assert -apply- make catch case -apply- apply import
** Near: assert/type [
    spec object!
    body block!
    mixins [o...

>>

question... why do you use:   [ face: face/gob ] and not  [ gob: 
face/gob ]  and  why you need   [ same? gog/data/gob gob ] ?

The last one: Gobs with a face have the face assigned to the gob's 
data field, and the gob assigned to the face's gob field. Yes, this 
is circular, but this is because there are two tree roots. FACELESS? 
checks for that circular reference.

What I'm worried about is that it will fail if the gob doesn't have 
any face assigned to its data field.

 - surely, Steeve and Brian, it has to be done, if such a situation 
 is expectable. Is it?

Throw in enough conditions and it becomes faster to just use an ASSERT/type 
[gob/data/gob object!]. Or just use a get-path :gob/data/gob and 
just accept that errors will be triggered if the function is applied 
to inappropriate gobs.

I don't want to begin a flamewar, but troubles are poping continously 
out of my mind. 

And I wondering, Wy did they choose to use a face (an objet) as the 
entry point of most of their low level graphic functions instead 
of a gob! (which is more convenient to my minf).

I can not take away the feeling that the faces?  function should 
just be a shortcut for gob/pane.

Maybe I should not expose my impression after having eaten and drunk 
in a good restaurant :-)

Gobs were introduced so we had something lightweight and low-level 
to implement appearance, without all of the overhead of a full face. 
That is why a face can have many subgobs without necessarily having 
any subfaces.

Right, because a face has (among other things) behavior, while a 
gob only has appearance and the pane.

Throw in enough conditions and it becomes faster to...

 - I do not want to throw in any unnecessary conditions. The condition 
 I used was verifiably necessary, but I do not know whether there 
 is any other.

Put the path last in the function, or use a get-path, and there won't 
be any code injection possibilities.

It might be possible that the GUI will only be used by safe code, 
so it wouldn't need the kind of hardening that the module system 
and mezzanines got. There are other ways to make things safeish, 
in theory. And code injection attacks aren't quite as bad as they 
could be if the security permissions were user-specific. Still, I'm 
in the habit now of looking at code as if I wanted to attack it :)

A110 : need to dowload it and test...

Couldn't there be some "default" simply one, for minimal gob based 
display? I mean - it should not be imo problematic to start ahead 
with displaying simple gob. I see no reason, why user should use 
some mysterious view/as-is, or cryptic append system/view/screen-gob 
win, to get basic gob display. I hope 'view and especially very badly 
designed 'unview will be reworked ...

Henrik: I get crashes of R3 when doing following:

>> do %r3-gui.r3

>> do %panels-21.r3 ; close a window, and do the same example again 
- it takes 2-3 runs to crash the R3

Win Vista, 32-bit. RMA A110 build, tried with downloaded and also 
on-line r3-gui.r3 populated using load-gui function. Do the script 
once, press some button, close it, do the script the second time, 
press the button - crash ...

That is a problem that Ladislav, Cyphre and Bolek are attempting 
to clarify and fix right now.

It seems that the memory can't be recalled back. I just watch task 
list, and I can see that running R3 takes some 2.4 MB, doing an %R3-gui.r3 
goes to some 4.8 MB, doing %panels-21.r3 starts at 7.9, but slowly 
grows to 8.8 MB, pressing some buttons/tabbing/resizing, grows the 
memory consumption to 11.2MB (why? ), closing the window does not 
return the memory back (maybe correct, as the window is just "hidden", 
but still interanlly exists?)


I wonder, if there would be any possibility to "unload" window (layout) 
and/or even to unload the gui?

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?

no, just that on the left-top, and bottom-right are OK, but left-down 
and top-right are thinner ...

And botton-left is vpanel, and top-right is hpanel style ... so I 
wonder how it is calculated :-) If you say it is OK, then it is OK, 
it was just an observation ....

Pekr, thinner buttons: Good catch. I'm not sure why the height would 
be different for VPANEL and HPANEL, but IMHO, they should not be 
different for any reason.

of course there could be different cell heights for VPANEL and HPANEL 
that I did not notice.

Just tested it, and it does, so behavior is correct.

Just tested it, and it does, so behavior is correct.

 - Henrik, I don't like any cryptic explanations to what apparently 
 looks like buggy behaviour?

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

ok, then behavior for HGROUP and VGROUP is also correct.

That is the difference between HGROUP and HPANEL.

I thought that the difference is in the visuals. OK, so if hgroup 
wrapping is supposed to be done using RETURN keyword, what is the 
purpose of following code?

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


Or is that some left-over from previous implementations, and "hgroup 
2" does not make sense?

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

Well, it's evident from what you say at the end. The flow control 
is the difference between the two. It makes more sense to have two 
general purpose types of mechanisms for grouping faces and afterwards, 
make derivative styles for particular appearances.

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... the main problem I see is, that current R3 is not able load 
PNG24 image. If I would like to do own GUI, and or game in Rebol, 
I would like to use semitransparent images. (I know that there is 
a lot of people who don't like bitmaps, but I see bitmap usage useful). 
I can load any image to Rebol using ImageMagick, but that is not 
a way we want to go... IM is too large to be used as common Rebol 
way how to deal with basic images.

Kaj, yes that is correct. My own idea is to simply have behavioral 
variants of ordinary windows with slightly different keyboard navigation. 
With any luck, it can also be usable as a generic window manager 
for a general desktop. Each style can present its own layout mechanism, 
and I expect that the window management style simply provides that.

We will provide a developer guide for styles to get you started and 
some styles are included in the current release as well.