World: r3wp

(assuming both positions are available)

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.

Aha, so you want the layout to be always related to the source, i.e. 
the second graphic object to be to the right of the first one? (assuming 
that the position below the first one as well as the position to 
the right of the first one are both available)

I'm trying to think of a good scenario where I would use Vpanel. 
The first thing that comes to mind is a multi-column file or directory 
listing. Is there a particular need it's meant to fill?

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

Myabe it's on my mind because I had to do some SQL recently, where 
the insert statement was one col per line, and lots of lines, followed 
by the values to insert, also one per line. :-\

Hmm, but that does not lay e.g. the multi-column listing in the expected 
order, where the second one is usually below the first one, not to 
the right of it

Yes, sorry, don't look at my example for that, look at Daniel's (Izkata). 
Mine was not done to show that.

Aha, OK, Cyphre and I were wondering...

Right now, my mind wants to say vpanel = below, hpanel= across.

Regarding Graham's note about RebGUI - Cyphre checked it, and there 
we can use just a PANEL (which corresponds to the above proposed 
HPANEL, as it looks), and an AFTER X value, which corresponds to 
HPANEL X specifying the number of columns, not the number of rows, 
as Gregg/Izkata seem to propose for HPANEL

New R3 GUI which fixes a few styles, like text list, although text 
list will eventually be rewritten:

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


Style browser now shows style options, alphabetic sorting of style 
names, face debug option (currently broken in the R3 GUI):

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

I think that having VPANEL and HPANEL is very helpful. I have buiilt 
a few screen layouts with Flex which has VBox and HBox which layout 
the elements they contain vertically and horizontally respectively.


Typically, I have used VBox as the "outside" container to enclose 
a number of HBox.


In Flex, both VBox and HBox are descendants of  Box which includes 
a direction property, the default of which is horizontal.

I find it much clearer to write:
 <VBox>
  <HBox>
  </HBox>
  <HBox>
  </HBox>
</VBox>

than

<Box direction="vertical">
  <Box>
  </Box>
  <Box>
  </Box>
</Box>

Just to throw another idea in .. yahoo grids - they analysed common 
grid useage and then you specify which grid pattern you want to use 
but of course you have to know what those patterns are.

So, what's the outcome? :-)

Peter - thanks for mentioning the approach, I think, that in REBOL 
we can define it analogically

Pekr, if noone can come with something better that HPANEL, VPANEL, 
HGROUP and VGROUP it's going to stay this way.

I'm going to rephrase my idea: In general it could be possible to 
use blocks of blocks inside the layout. This would make it easier 
to generate layouts and not care about style argument lengths:

view [[button button] [field field]]


Of course you can't split a style in two blocks, but this wouldn't 
be needed anyway:

view [[button] [do [something]]]


This is similar to how gradients can be put in blocks inside DRAW. 
Is there anything that would conflict with that?

Yes, Henrik, your idea looks interesting as well

Henrik, good point. We need to consider "generate by script" in all 
dialects etc. IMO being able to use even more abstract descriptional 
approach and generate on the fly is a key pattern.

yes, but ads lots of visual clutter, especially if the code is short.

Pekr, no it doesn't, because you are free not to use it. The point 
is that auto-generated layouts would be much easier to make and rearrange.

When Cyphre did the grid for RebGUI for me, that is what I suggested 
to him - to enclose column VID description into block, so that you 
can reorganise it easily .... so I am OK with that ...

Status:


Not much new. We are discussing how to formalize actors, as this 
is only half-done. Other than that, it's simply bug grinding of styles.

what do you mean by formalizing actors? Any problems with recent 
aproach?

No, we just want to make it really simple and common, so you don't 
have to know how things are named in styles.

what about this kind of IDE looks like small talk but for rebol and 
Rebol/GUI having such a tools could be crazy look at this and try 
it 
illumination Software Creator 
http://radicalbreeze.com/

maybe in a different way / shape but since along ago i like the idea 
very smalltalk like to organize Applications like a UML model ... 
And i think rebol GUI could shape that and use that ...

what i like is the hightly visual and abstracted side of this kind 
of IDE...  It's intuitive it's simple ... Rebol must have it ;)

as a matter of fact some lot of years ago we tryed something like 
a MERISE model representation of database with some people of french 
community (coccinelle; lucho) the project was Called LadyReb it was 
dropped  but the idea behind it was pretty similar.

main problem of this kind of representation is that it lacks flexibility 
you can't think out of the box.... But this would means finding some 
way for the user to add new items. Since rebol is easier to handle 
than most of languages around this interaction could be something 
really stunnish

you means something like this:  


http://www.pointillistic.com/open-REBOL/moa/files/elixir-desktop.png

?

;-D

hum ...  yes but more with a meanning behind items  on the graph 
pattern. Featuring relations betwin item one to another

lets say more adapted to general programing ....

component based programming ..

yeah but in the rebol way ....

ah... did you actually read the node names?  they are actually functions. 
  connecting them actually shows the value in the gray box in real 
time.

using such a tool is like describing your application steps through 
 you have the start point of your application then comes the splash 
screen then comme the main window  in it you put those items etc...

Maxim hum on the graph i can't say you where it starts where it ends 
or what it does ... but the main idea behind a graph representation 
is the one look to it you understand it

elixir actually is a generic procedural data engine.  follow the 
arrows... its just sprawled right now... but if you ordered them 
from left to right, or top to bottom it would be very clear.

but the pic I posted is just a very preliminary prototype... though 
it still works well for demoing the idea for the other levels of 
the system which have never been attempted... well only a little 
bit in my latest glass work.

sounds like i'm feuding ... lol well the idea is since GUI is planned 
to evolve then maybe we can start thinking toward that kind of extensiv 
graphical use to see how this can be meaningfull with rebol context 
of writing applications...

even my current R3 Open GL work is to push forward this vision... 
(to make this back on topic  ;-

)

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

that's already limiting in my POV.   elixir actually allows you to 
build the system that you describe interactively  (In theory, not 
in practice, since its really not done yet(

i like the idea of having a really simple way to look at rebol app 
and then you can edit part of it add new boxes with crazy new stuff 
etc.... it's somehow what we do in text based coding 

but on heavy fragmented project it's hard to have an over view to 
it ...

I just wanted to show you that there is someone already tackling 
the idea... thoug it will still be a few months before I have any 
R3 version of elixir (the move to R3 and the wait for extensions 
is the main reason I stopped working actively on elixir)... it was 
just tooo demanding for the R2 platform, in just about every way 
possible.

problem with this kind of representation as a former small talk extensive 
programer is deeper you go in the specifications more blurry is you 
view ... it's like a melt of lot of boxes everywhere with arrows 
linking them to any direction ... that's pretty hard to handle ...

it can be.. with some compositing I've done I had hundreds of nodes 
in a single shelf... at some point we would do node art   ;-)