r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 GUI]

Pekr
26-Jul-2010
[2189]
I would stay with recent naming them - both names kind of represent 
a "container" kind of a meaning. It is a documentation thing imo.
Robert
26-Jul-2010
[2190x3]
group is OK,
Than how about BOARD?
Like a chess-board.
Pekr
26-Jul-2010
[2193]
Board, matrix, box (that one would collide with the style name, the 
same goes for grid, table). Board sounds good, but I still can't 
see the reason, why panel does not fit ...
Robert
26-Jul-2010
[2194]
Petr, just don't care about it. Suggest a good name :-)
Ladislav
26-Jul-2010
[2195]
We can go along with Group and Panel, as Pekr suggests, no problem 
either
Pekr
26-Jul-2010
[2196]
If we will not find better use-case for a Panel style, then let's 
stay with panel. If not, use Board instead ...
BrianH
26-Jul-2010
[2197x2]
Panel is a good name. All of these are pretty arbitrary when applied 
to a GUI system. Pick something traditional like Group and Panel, 
that sounds nice.
Not Board though, it focuses too much on the flatness and not any 
more on the layout.
Henrik
26-Jul-2010
[2199]
Bolek got hurt in an accident, which is why he was not so active. 
He should be back in business in a couple of days.
Pekr
26-Jul-2010
[2200]
uh, hope he is OK!
Graham
26-Jul-2010
[2201]
Must be okay if he's back in a couple of days?
Henrik
26-Jul-2010
[2202]
Broken clavicle.
Graham
26-Jul-2010
[2203x2]
You guys didn't make him lift too many heavy widgets??
Is Carl still in the R3GUI scrum ??
Henrik
26-Jul-2010
[2205]
yes, although he's focusing on host kit right now.
Graham
26-Jul-2010
[2206]
on callbacks? or IPC ?
Henrik
26-Jul-2010
[2207]
callbacks
Graham
26-Jul-2010
[2208]
Good to hear
Anton
26-Jul-2010
[2209]
How about WRAP-PANEL  (or ARRANGER or "CONSECUTOR") ?
BrianH
26-Jul-2010
[2210]
Remember, whatever name we choose will be written out a lot. The 
two main layout styles will show up a lot in user layouts. So short 
is good.
Graham
26-Jul-2010
[2211]
Won't we have styles to allow us to choose our own names?
BrianH
26-Jul-2010
[2212]
Yes, you can make your own styles. But most code sill be just layouts 
and behavior, which are separate from style creation. You don't do 
derived styles in the layout itself.
Anton
26-Jul-2010
[2213]
I agree.
But I have some ideas for making a very general layout mechanism.

It looks to me that the layouts above can be expressed by two nested 
levels of arrangement.
BrianH
26-Jul-2010
[2214x2]
Remember, the goal is to be able to write layouts with as little 
style information as possible, just the style names, data and options. 
Keep the need to specify sizes to a minimum, colors never. The layout 
dialect is for app programmers, not graphic designers.
To give you an example, I would be the target market of the layout 
dialect. I am not a graphic designer, nor should I have to be. And 
you don't want me picking colors.
Anton
26-Jul-2010
[2216x3]
(It seems dubious to me that a graphic designer wouldn't be interested 
in layout, but I can understand the merit of separating the specifications 
for colours and the specifications for layout.)
Here's the notes I tried to post before when you were discussing 
LAYOUT-MODE:
HTML refers to this as "inline" (and the line may wrap).
I used 
grid-face/LAYOUT-DIRECTION: 1x1  and  
grid-face/MOVE-FIRST: 'horizontal
in my old GRID style.
	do http://anton.wildit.net.au/rebol/gui/demo-grid.r

But the parameters needs to be clarified some more.

Academic papers published as PDFs often have two columns of text.

That means a single line of text wraps horizontally, vertically, 
and horizontally again.

Eg. The line of text first wraps (horizontal) when the right hand 
edge of the first column is reached,

then, after many rows are similarly wrapped, when the bottom of the 
first column is reached (vertical wrap).

All of that occurs again for the second column (and perhaps more 
columns) until there is no more room on the page,
so the final level of wrapping is horizontal. 

So I would have 
	face/WRAP: [horiz vert horiz]

which specifies three levels of wrapping, horizontal for chars, vertical 
for lines of text, horizontal again for columns (so that the next 
page is underneath the first one).

To put pages horizontally, you would just have 
	face/WRAP: [horiz vert vert]


Or you could specify an extra level of wrapping, eg. so that you 
could have groups of two pages shown horizontally
	face/WRAP: [horiz vert vert horiz]


The direction for each level of layout should be specified to correspond, 
eg.
	face/LAYOUT-DIRECTION: [1 1 1 1]
which would give left-to-right and top-to-bottom.
(Use -1 for right-to-left  and bottom-to-top directions.)
BrianH
26-Jul-2010
[2219]
If we see styles like 'red-button, we've failed in our design of 
the R3 GUI system.
Anton
26-Jul-2010
[2220x2]
I don't agree about RED-BUTTON.
I think it should be possible to make a style like that, if you really 
want it. (Most of the time, you don't want it, but when you do, you 
do.)
BrianH
26-Jul-2010
[2222x2]
As long as there is nothing to imply that the red-button style would 
actually be red at runtime, sure. Colors are for theme designers.
Most of the time when a programmer thinks that they want to specify 
colors, they are wrong.
Anton
26-Jul-2010
[2224x3]
No, I specifically disagree about that. If I want a style to be forced 
red, then I want it forced red.
I agree, most of the time the programmer doesn't want to think about 
it, and it's best to get the colour from a theme. BUT, WHEN YOU WANT 
A BUTTON ALWAYS RED, YOU WANT IT ALWAYS RED!!!!
(Sorry, that should be "when *I* want ...")
BrianH
26-Jul-2010
[2227]
You are a graphic designer then. We are assuming that the "programmer" 
and the "graphic designer" and the "style designer" could be the 
same person in practice, but the roles need to be kept distinct even 
when the same person is doing them.
Anton
26-Jul-2010
[2228]
(Gee, sorry I shouted.)
BrianH
26-Jul-2010
[2229x2]
That means that styles get functional names, not graphical names. 
Layouts should make sense if the user is color-blind. It is up to 
the theme designer (which may also be you, in a different role, or 
it may be someone on a theming site) to decide colors.
Keep in mind that is the layout dialect that shouldn't have colors. 
Styles are specified with a different dialect, and they can have 
colors in their draw blocks.
Anton
26-Jul-2010
[2231]
Yes, I agree this is the best way 99.9% of the time. And this separation 
of specification has all been discussed before.
Henrik
26-Jul-2010
[2232]
Anton, you are free to do that, but it will break the philosophy 
of how styles work together. I think this point is not properly understood, 
but it will move the GUI to the next level, where you spend zero 
time thinking about colors or theme, can properly divide UI design 
between a graphical designer and one producing programs.
Anton
26-Jul-2010
[2233x2]
I just jumped (somewhat pedantically) on BrianH for making an absolute 
statement. (I've also just turned down the heater in my room, I didn't 
realise I was heating up.)
So I apologise. I'd prefer to get back to the layout discussion above.
BrianH
26-Jul-2010
[2235]
For the other 0.1% you can write your own styles, or your own themes. 
Of course, when you are doing that you are being a style developer 
or a theme designer, not an app developer. The app developer (possibly 
you) will use the style developer's styles.
Anton
26-Jul-2010
[2236]
Yes, yes yes, I *understand*...
BrianH
26-Jul-2010
[2237]
You jumped on me for making a statement you misinterpreted completely, 
so I take no offence :)
Henrik
26-Jul-2010
[2238]
I had actually wanted it to be even more strict, that styles should 
not be possible to set appearances for in layout at all. But I can 
see that colors have snuck in, anyway.