World: r3wp

consistency over conciseness for me, so perhaps 2-2, if that's what 
we already have, otherwise I would prefer 2-1.

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
 - interesting point, should make a note

You might not have noticed, but the reason why I am using polls is 
to make something that you would find preferable to other altermatives. 
If you don't know what you prefer, then, you are free to not answer.

In the case of the above poll, all alternatives have their advantages, 
as is already mentioned in the article. That is why a "good GUI" 
can use any of the alternatives. A "preferable GUI" should use the 
one the majority prefers.

Aha, I did not notice the smilie at the and :-)

err: "end"

I guess, it's extremely hard to create a really good and preferable 
GUI. I'm struggling with Cocoa and Interface Builder on Mac OS X 
atm., and I haven't seen any glimpse of a 'perfect' GUI in that yet. 
If I was to design a GUI, I would go for simpleness, and still make 
sure, advanced users can make the advanced things.

Suggestion: If you have user-defined styles, then why not just go 
with a very basic set of styles to begin with, like only panel, group, 
etc. And then you could make an advanced version of the GUI (by including 
some script with styles), where you give users vpanel, vgroup, etc.

Result will be, new users don't read very much documentation and 
can start using the GUI very quickly. If you wanna do more advanced 
things, read the advanced docs, include the extra script and there 
you go.

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.

(the same holds for the vgroup style)

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

And that's a problem with polls, you get many opinions. Better to 
set a strategy, define some good basic rules and make the thing without 
asking anybody. Keep K.I.S.S. in mind, as that's the most often (but 
yet very basic) rule broken.

A R2 GUI document, I've used a lot over the years, is:
http://www.rebol.com/docs/view-guide.html


About everything is there in a small space. It's a very good document 
to get you going, almost perfect. Maybe just a little too long still.

I find that if something should be decided, you should look at how 
easy it is to change the code based on that decision. The easier 
the code is to change, the later you can make the decision. This 
gives people a chance to test the GUI with that particular decision. 
In this case, we are working purely with style names, as far as I 
can see, which is possible to change in a few seconds, if we don't 
like them.

It is more of a problem in the documentation, there it surely takes 
more time.

And, it becomes a problem with existing code, since nobody wants 
to rewrite all the code he is using.

(by "existing code" I mean the code already using the affected styles)

Are there much R3 GUI code, that people actually use?

not too much, but we already have demos, styles based on styles, 
etc...

I did mean it to some degree, that it's a good idea to get a clear 
view first, when doing such things. Then you don't have to change 
anything later. But it's hard.

So make a cup of green tea, sit in lotus position, close your eyes 
and think. After a while, you might see it clearly and don't have 
to poll. ;-)

view layout [zen]

As far as I am concerned, I "see it clearly", but I do know, that 
if I wrote it that way, you would come and say: "my dog prefers the 
other alternative".

That is why I am asking beforehand, when I feel the time is right 
to ask.

Ladislav - in your GUI terminology doc, panel/vpanel section, isn't 
there a typo in the source code? Imo it should be panel [button button], 
not hpanel [button button]

Interesting - I really don't know, if it is a problem or even confusing, 
when docs talk panels in general, and panel as a style. How often 
do you need to refer to the panel style in your text? And if so, 
you can always use "panel style".

Imo it should be panel [button button]

 - that is just copy&paste, as you correctly noticed, describing the 
 current state

panel style

 - the problem is not much about "panel style". It is more about the 
 need to refer to faces, that are layouts (like windows, backdrops, 
 vpanels, I don't remember what, ...) , or faces, that are panels 
 in the sense of having the panel style.

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.

I don't understand your last sentence. Could youcome up with short 
documentation sentence, which might show what the trouble is?

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

just a brainstorming on my part, no suggestions yet ...

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

Does that suffice to illustrate the problem?

yes, thanks ...

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

We should also admit, especially as proposed by Henrik and Gab in 
the past, that maybe, many users will create descendants, calling 
them my-panel, my-red-border-panel, whatever. Then I can imagine 
some docs:


My pink-big-panel panel, is a special purpose panel, designed for 
my girlfriend :-) It differs from default PANEL STYLE in having red 
and pinky design ....

I think that ppl will find their way around it ...

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

aha, I thought that insert-panel-content is only good for inserting 
stuff into panel style pane, but now I remember, that when we met, 
you already explained to me, that the style is more general?

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

insert-into my-panel [content here] looks short and reads nicely 
....

no need to explicitly explain in the function name then imo, as it 
is defined by the followed argument?

OK, we shall consider this alternative as well, when doing the renaming.

It makes also the function shorter. What are other content function 
names though? We would have to come up with some short names even 
for other such funcs ...

OK, I can see them ... will provide some alternatives shortly ...

list of the *CONTENT functions (current names):

SET-PANEL-CONTENT
CLEAR-PANEL-CONTENT
INSERT-PANEL-CONTENT
APPEND-PANEL-CONTENT
CHANGE-PANEL-CONTENT
REMOVE-PANEL-CONTENT