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

World: r3wp

[!REBOL3 GUI]

Ladislav
22-Apr-2011
[7028]
The wording of the http://www.rebol.net/wiki/R3_GUI_terminologyarticle 
corrected and enhanced.
Geomol
22-Apr-2011
[7029]
Maybe we're just tired of user polls, or we don't have the time to 
dig into this. 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. Only suggestions. :-)


I looked into it quickly, and I would at this point go for just have 
panel, letting vertical be a layout-mode option. Reason: K.I.S.S. 
(and vertical is an option anyway). And if you support user-defined 
styles (I'm not sure, you do, as I'm not very much into R3 GUI), 
then programmers can just make their own vpanels, if they need it. 
If I, as new to some GUI, can get it up and running in a very short 
time, because it's so simple, that's a huge benefit.
Henrik
22-Apr-2011
[7030]
consistency over conciseness for me, so perhaps 2-2, if that's what 
we already have, otherwise I would prefer 2-1.
Ladislav
22-Apr-2011
[7031x5]
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"
Geomol
22-Apr-2011
[7036x3]
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.
Ladislav
22-Apr-2011
[7039x3]
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.
Geomol
22-Apr-2011
[7042x2]
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.
Henrik
22-Apr-2011
[7044]
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.
Ladislav
22-Apr-2011
[7045x3]
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)
Geomol
22-Apr-2011
[7048]
Are there much R3 GUI code, that people actually use?
Ladislav
22-Apr-2011
[7049]
not too much, but we already have demos, styles based on styles, 
etc...
Geomol
22-Apr-2011
[7050x2]
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. ;-)
Henrik
22-Apr-2011
[7052]
view layout [zen]
Ladislav
22-Apr-2011
[7053x2]
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.
Pekr
22-Apr-2011
[7055x2]
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".
Ladislav
22-Apr-2011
[7057x2]
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.
Pekr
22-Apr-2011
[7059x4]
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 ...
Ladislav
22-Apr-2011
[7063x2]
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?
Pekr
22-Apr-2011
[7065x5]
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 ...
Ladislav
22-Apr-2011
[7070]
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
Pekr
22-Apr-2011
[7071]
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?
Ladislav
22-Apr-2011
[7072]
Right, the function is a method to insert contents to any layout: 
vgroup, backdrop, my-pink-panel, ....
Pekr
22-Apr-2011
[7073x3]
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?
Ladislav
22-Apr-2011
[7076]
OK, we shall consider this alternative as well, when doing the renaming.
Pekr
22-Apr-2011
[7077]
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 ...