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

World: r3wp

[!REBOL3 GUI]

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
[7077x2]
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 ...
Ladislav
22-Apr-2011
[7079]
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
Pekr
22-Apr-2011
[7080]
et-panel-content
clear-panel-content
insert-panel-content
append-panel-content
change-panel-content
remove-panel-content

set-content
clear-content
insert-content
append-content
change-content
remove-content


; Disadvantage of following group is, that it does not relate to 
the content, and hence we are reserving/blocking those names for 
our particular purpose.
set-in
clear-in
insert-into
append-into
change-in
remove-from

Think about them in the usage scenario,e .g.:

insert-content my-panel [content here]
insert-into my-panel [content here]
Gregg
22-Apr-2011
[7081x2]
1) Do you find the 'a layout' and 'layout style' notions to improve 
the current 'a panel' ambiguous terminogy, or do you prefer something 
else?


To me, a layout is a specification, not an instance. I don't know 
that using a different word (container or compound) helps. You just 
need to be explicit about whether you're talking about a panel face 
or the panel style (which has a layout specification).


2) Which of the three [[hpanel vpanel] [panel vpanel] [panel panel 
vertical]] alternatives do you prefer?


My view was based on there always being a base 'panel style, with 
'hpanel and 'vpanel being shortcut styles to set the layout mode.
Sorry I don't have time to dig into the other conversation right 
now.
Ladislav
22-Apr-2011
[7083x3]
You just need to be explicit about whether you're talking about a 
panel face or the panel style (which has a layout specification).

 - hmm, it never occurred to me how much the question could be misunderstood.
Do you think it is really the the sense I meant?
I never wanted to be able to discern the panel style and panel face