AltME groups: search

But of course then - we have altready those facilities for all faces 
- a box model, where's the space to draw any borders,etc. Well, we 
could say then, that FRAME is special decorative kind of style. The 
question is, if it would not be overused by uesrs, putting even buttons 
inside of FRAME, to have a decoration? :-)

ok, got to go. So the only yet unexplained part to me is that of 
a resizing. As Rebolek hinted, it might be caused by the text being 
resized. It is just, that with examples I mentioned, the result is 
(of course IMO) not a desired one.

Regarding Henrik's FRAME note - that is a surprise for me, never 
heard about such a proposal, and disagree with it.

E.g. try also panels-26.r3 - why the last line of boxes stays "attached" 
to the bottomof the window, causing a space?

Ladislav, I discussed it a few days ago, but not to worry. Rebolek 
disagrees too, so it probably won't be done. My worry is that the 
act of creating a border or frame around a style will be an obscure 
part of a base style.

#[[Pekr

E.g. try also panels-26.r3 - why the last line of boxes stays "attached" 
to the bottomof the window, causing a space?

Pekr]] - that is an example "inherited" from Carl, and it behaves 
as it should, taking into account, how it was defined. You need to 
take a look at the code

#[[Henrik

My worry is that the act of creating a border or frame around a style 
will be an obscure part of a base style.
Henrik]] - you need not worry, it already works for all styles

Two notes:

- RMA is neither me, nor Henrik

- RMA has a unified point of view, it is the one you can observe 
when examining the published code and docs, all other things are 
just speculations

So what is problem with me not eventually agree with what you cook 
behind the doors?

- since we publish our results, I see this as a clear attempt to 
insult our good will.

And, especially from you, it is unfair, taking into account, how 
many times you did not put to use the oportunity to present your 
preference in various user polls. 'The informations about user preferences 
were much needed then, and it is a pity you, instead of helping us 
to know user preferences in many cases, try to dishonest our efforts 
publicly by misrepresenting it as "cooking behind the closed doors".

Ladislav - sorry, but now you should really take a break. What are 
you talking about here?

WTF is an attempt to insult your good will? Damned - this is SW development 
and desing, not a religion!

What I can see though, is a kind of syndrome of a developers, who 
live behind the closed door, and then wonder if another point of 
view is presented. It very often ends with statements like "you can 
take Carl's code, and do your own GUI". And I am far from alone receiving 
such a reply. And THIS is what I call as an insult, to ppl expressing 
different pov on the direction taken.

I very much respect Robert's explanation - this is not a democrary, 
this is RMA's business, and i have no problem with that. I just really 
don't understand, why when I put explanation to why I mistakenly 
marked panels-26.r3 demo as incorrectly behaving here, Rebolek comments 
that I am resisting something. I just put it here, because the group 
is searchable, and my reply contains explanation, which might be 
helpfull to others ...

Guys, let's relax. Everyone can comment of course and people going 
through the code and comment help us. And it's OK if there are different 
POVs. As you can see even within the RMA team we discuss things back 
and forth and have different POVs. Which IMO is absolutly essential 
to come up with a good solution.

Cyphre:

box-model:
---------------


Few notes. Certain systems use FLAGs, which could be thought about 
as kind of switches, or representing certains states, etc., used 
in binary masks for e.g. Then we have TAGs. Even R3 GUI uses tagging 
- it is used mostly to mark particular face as behaving some way, 
belonging to some area, etc. And in that regard, I wonder if box-model 
type could be done just by using TAGs? 


What I think about TAGs in GUI in general is, that we don't use the 
concept to the max. I mean - if tags were not be flat block, but 
block of blocks, it could be used even more, e.g.:


tags: [box-model [tag1 tag2 tag3] style [internal] draw-mode [normal] 
resizing-mode [.....] ....]


Of course that might not work for us in all cases, because as you 
could see in above example, it would be difficult to distinguish, 
if something should be a facet, or a tag. E.g. if we would move DRAW-MODE 
into TAGS, then why not moving MATERIAL there too, etc. My question 
is - is there any rule for me to remember - what should be a facet, 
and what could be a TAG? (I expect the difference in how you work 
with them underneath)


My general problem is, that FACETS block is becoming long and messy, 
so what to do about it? There were following suggestions to think 
about:


1) close particular settings in subobjects/maps (whatever). There 
are settings belonging to the areas of resizing, colors, box-moderl, 
others, etc. The question is, if we want to refer to such values 
by face/color/bg-color for e.g.?


2) the simplest solution is to at least use some source code conventions. 
E.g. Carl introduced comments to particular ACTORS, desribing what 
arguments are supported for the function. So my idea is:

facets: [

   ; colors
   bg-color:
   other-color:

   ;resizing
    resizes: 
    init-hint:
...
]

ALIGNment:
----------------


It is probably not wise to change all subsequent areas to halign, 
valign. But anyway, we are a bit chaotic here, unless someone tells 
me, what's the rule here - to stay compatible to html/css, or to 
be consistent REBOL wise? I mean - if various areas use ALIGN/VALIGN, 
then my logical question is - why HPANEL/VPANEL, and not PANEL/VPANEL?


My comment is just food for thought, not a claim to change anything.

If I understand Graham correctly, he suggest to have default a horizontal 
alignment = compatible with underlying align/valign. Hence what he 
imo proposes (and I agree with), is to remove "H" letter from PANEL/GROUP

Rebolek, yes, I was just teasing. Perhaps it's not a bad idea. VID 
itself also has a default direction that it lays out in, which can't 
be seen in layout code.

Is there a plan to use 'switch-panel function in future, along with 
its transition effects (fly-outs)?

I'm thinking about a style that is basically a fancy text list with 
the specific purpose of using it as a panel switcher. But specifically 
the animation part, it may be better to have some kind of actor (on-switch?) 
where the animation is handled and can be specified separately.

We had a small discussion about MAX-SIZE this morning. In short, 
I don't like it and think it's not needed. Everyone else loves it, 
so it won't go away. Therefore I'm proposing a RESTRAIN facet (name 
not final). Without explaining what it is, can you guess what this 
does:

Before:

bar: box [
	facets: [
		init-size: 100x2
		min-size: 20x2
		max-size: 10000x2
	]
]

After:

bar: box [
	facets: [
		init-size: 20x2
		restrain: [vertical]
	]
]

why it's a block?

Decided that it may not need to be a block: Another suggestion is 
words: HORIZONTAL, H, VERTICAL, V, or BOTH.

also if you give me such a piece of code (both), I'm not sure what 
the results will be, but I'm not following the developement so I 
don't know details about resizing.

Oldes, it means a full width line across the widht of the parent 
face

facets: I'm all for keeping one single place to keep all these properties 
and throw everything in there. No further sub-structuring. Why? Because 
this would require a MECE approach (which is IMO a very subjective 
thing) and I have to remember more things. Now I know the stuff is 
in: facets/<some-meaningful-word>

Rebolek, same issue: STYLIZE may be used by a third party person, 
not knowing the original style size or not wanting to depend on it, 
if the original style changes.

Robert - OK, then lelt's keep the organized a bit by spacing (new 
lines) and comments, as I suggested ... that might be enough imo 
and grouping certain areas together helps users to faster identify 
particular related facet?

No problem with this. What I would like to have is a way that I can 
write:

? text-table/facets


And get a dump of all available facets and a description what it's 
for.

Hi, guys

Once again, congratulations for the excellent work done.

As Rebolek suggested in ALTME, I have some modifications to submit 
(of course, to check from your side) for the next r3-gui release.


I must first mention that I just realized this morning that the r3.exe 
 pre-compiled version of march 11th was not working properly, bugging 
with some very simple text displays (probably an old version). That's 
the reason why I did not update the demo with the most recent r3-gui 
file. By the way, the  build date displayed by the exe remains the 
same whatever the real building date. I don't know how we could have 
an automatic update of the build version.


Rebuilding from your sources (march 11th) allowed the demo to work 
properly apart from some appearence differences (I have even seen 
some bugs solved compared to my demo version). However, I will wait 
for your next weekly release ;-) to update my demo.

Coming back to the propositions of modifications :


It seems that there are definitions problems, or incompatibilities
in r3-gui (around line 66)        
;-- circle: [pair! | number! | number!]    
circle: [pair! | pair! |number! | number!]

in r3-gui (around line 1729) 
;-- scale: [decimal! decimal!]  
scale: [pair!]

also, I overload the drawing style by this code :
stylize [
    drawing: sensor [
        about: "Simple scalar vector draw block. Can be clicked."
        tags: [input tab]
        facets: [
            init-size: 100x100
        ]
        options: [
            drawing: [block!]
            init-size: [pair!]
        ]

        actors: [
            on-make: [
            ;    if block? drw: face/facets/drawing [
            ;       bind face/gob/draw: copy drw face/facets]

            ]
            ;-- JC
            on-draw: [face/facets/drawing]
        ]
    ]
]


Concerning the discussion of this morning on groups and panels, I 
would also prefer to have a default horizontal arrangement, and only 
precise when vertical: group, panel, vgroup, vpanel. A side effect 
is that it would remain compatible with Carl's doc.

By the way, it seems that tight is vtight. Logically, it should be 
htight.


That's all for the moment. When debugging the last demos, I may find 
other issues.

My notes to the HPANEL versus PANEL issue:

* Carl appears to prefer PANEL

* unfortunately, the situation is not as easy as it looks at the 
first look, since Carl's documentation uses the word 'panel' it yet 
another sense, every style able to contain faces, such as a group, 
etc. is called "a panel" in Carl's documentation, which would immediately 
lead to confusions, requring rewrite

* e.g. the INSERT-PANEL-CONTENT, or some other function names would 
be confusing because of the above mentioned issue, since the function 
in fact inserts content to any "face containing style", not just 
to HPANELs


So, the amount of rewriting both the code and the documentation would 
be quite big.

Everyone else loves it

 - I expect a little more objective statements than this. In fact, 
 I don't "love" MAX-SIZE at all. I just know (you have proven it), 
 that some relevant frameworks (like the OSX GUI) include it. I am 
 sure that is the reason, why Carl insists on it as well. So, if we 
 want Carl to "throw our changes to the R3-GUI to the basket", we 
 can remove the MAX-SIZE to achieve that goal.

Ladislav, Carl told me that MAX-SIZE was necessary so that buttons 
would not become unnecessarily wide, but it is the wrong way to solve 
such a problem, much like putting a rock under the gas pedal to prevent 
the kid from going more than 30 mph in dad's car. Nevertheless, when 
(hopefully) we get some parts automated here, I will never need to 
deal with MAX-SIZE again directly.

And OSX does not provide maximum size for widgets, only windows.

Henrik - two things - first you should consult Carl (if he is available 
to RMA), and second - Ladislav will probably state, if there is a 
way of how to adapt his alghoritm, so that we can work without the 
MAX-SIZE? I personally don't mind MAX-SIZE anymore, as I have to 
set xy things anyway - hints, init-size, min-size, as needed. And 
if I am a style authoer, then I can always set MAX-SIZE to some artificial 
value, so :-)

Pekr, a solution has been found, so no worries.

much like putting a rock under the gas pedal to prevent the kid from 
going more than 30 mph in dad's car

 - that is a nice metaphor, but I would use a different one. In many 
 contemporary cars there are means to limit the revolutions of the 
 engine. They are there, and I do not think they are meaningless. 
 They limit the revolutions of the engine exactly like a rock under 
 a gas pedal eventually could (rock under a gas pedal certainly cannot 
 limit the speed).

Cyphre, thank you for the info and the link.

Please don't do special changes for me, unless you see a real interest 
to do so.

By the way, I probably should only be given 0.1 of a vote as I have 
hardly done any GUI programming with REBOL and certainly none with 
REBOL3.

I checked the Oxford English Dictionary for Content when referring 
to a container of some kind:


(usually in plural) what is contained in something, especially in 
a vessel, book or house.

As a non-native speaker CONTENTS sounds quite strange... and I wouldn't 
remember to add the S after a couple of weeks not using it.

...after a couple of weeks not using it
 - in fact, there was UPDATE-FACE/CONTENTS from the start

As a non native speaker, I would prefere just CONTENT

'Content sounds singular; 'contents  sounds plural. Are there more 
cases than resizing and members changing to consider? It's a very 
general name, and 'content or 'contents doesn't add a lot of meaning 
to what it does exactly.

If a book only has one chapter, will it be called "table of content"? 
:-) Sorry, I'm probably creating more confusion.

http://en.wikipedia.org/wiki/Content
Funny it's called a "content provider", not "contents provider".

My understanding is that content refers to what is inside, contents 
refers to a list of the content

After looking in dictionary on my computer, I'll say contents (plural) 
is more correct english.

The plural form:

the things that are held or included in something : he unscrewed 
the top of the flask and drank the contents | he picked up the correspondence 
and scanned the contents.
The singular:

the amount of a particular constituent occurring in a substance : 
milk with a low-fat content.

I think both forms would be correct, with contents a little more 
specific, and content a little more abstract, and shorter

when you have to move on short notice and you sell everything in 
your house, it's called a "contents sale"

but if the object only had a single item, we would have to switch 
to use /content

in a contents sale, one can list each item ...

a suggestion for the next release of r3-gui : the doc style (the 
doc parser) interprets the first line of text as a title, which is 
not always appropriated. For instance, in a simple 

alert "this is an alert", the text is displayed as title. I think 
that this feature should be removed.

on CONTENT/CONTENTS:  As a native speaker, the singular word can 
be thought of as referring to a single collection.

It's a draw, so make both available. Mayby not in this situation, 
even if more than one option can be good in many cases.

It's a draw, so make both available
 - although possible in this case, it prevents unification

is it possible to find a different word?

Would it work to make update-face/contents the default, so removing 
that refinement, and add a /resize refinement for that case?

Actually, the behaviour of UPDATE-FACE/CONTENTS called e.g. for a 
vpanel is equivalent to the behaviour of UPDATE-FACE called for a 
face contained in the same vpanel.

Is the behaviour recursive, in the sense the if a vpanel includes 
some hpanels the faces inside the hpanels are also updated?

So if I have a vpanel which contains two hpanels and call UPDATE-FACE/CONTENT(S) 
will the contents of the hpanels be re-sized?

I was going to suggest a couple of alternatives but it is hard to 
find something that fits in with the VIEW/VID/GUI metaphors.

Two notes:

- update is not resize, but can provoke a resize as well

- if I call UPDATE-FACE/CONTENTS on a hpanel, then the hpanel is 
updated (row and column sizes are recalculated, the total panel size 
is recalculated), but the panels contained are not

UPDATE-FACE/RECURSIVE
- this is a misunderstanding, as I said.


- UPDATE-FACE if always recursive, i.e. the it updates all the parents 
as well.
- UPDATE-FACE does not "recurse to children"

UPDATE-FACE/CHILDREN
 - a misunderstanding again, see above

UPDATE-FACE/ALL
 - a misunderstanding as well

I'm afraid that I'm a little lost - You said that UPDATE-FACE/CONTENTS 
called e.g. for a vpanel is equivalent to the behaviour of UPDATE-FACE 
for a face contained in the same vpanel.


To me the faces contained in vpanel can be considered children of 
the vpanel.

Yes, but that does not mean any children recursion, that is a parent 
recursion.

Parent recursion means, that when I start with you, I continue with 
your parents, grandparents, etc. As opposed to that, when I do a 
child recursion, when I start with you, I continue with your children, 
grandchildren,...

I'm confused. :-)


I agree that /SIZE is a better name, and now see the problem with 
it.


What does the docstring say for the function? That is, can we approach 
it from the documentation side and see if the functionality is clear.

and, you got me, it currently does not have a docstring (maybe it 
is too low-level, but I will definitely write something)

Personally, I think that ANCESTORS, PARENT, CHILDREN  and DESCENDANTS 
are very useful words for precisely defining relative positions in 
a heirarchy.


They do not seem to sit well with the REBOL though as firstly they 
are comparative long (and many rebollers appear to worry about having 
to type one or two extra characters) and secondly they don't really 
fit in with the existing VIEW/VID/REBOL3 GUI metaphors (which are 
more facial - FACE, GOB etc.)

it'll be up on the site, once Robert gets around to it. I just didn't 
want to spam this group with a list.

report towards panel #32 - make the window so large, that on Y axis 
(vertical), the scroller is 100%. Then try to move the scroller (or 
press its arrow). The panel jumps in a strange way?

yes, merged, sorry. Simply put that when Carl reappears, and starts 
eventually to proceed with RT's releases, to not find ourselve in 
a situation, when Carl uses old and different hostkit View sources 
...

User poll questions:


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?

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

Notes:


1) not seeing any reactions to the question, am I to understand it 
means agreement?
2) the favourite seems to be 2-2 currently

- regarding Graham's panel -45 question: if 2-2 is chosen, then this 
alternative would need to be panel-45. Somebody may define such a 
style, but it does not exist now.

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.

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

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.

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.

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.

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.

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

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

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.

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

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

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

Right, the function is a method to insert contents to any layout: 
vgroup, backdrop, my-pink-panel, ....