AltME groups: search

Is there a document that describes each feature in view and all the 
options etch please?  e.g. for slider

So far I can find tutorials that mention some aspects of slider, 
but nothing complete.

First, there needs to be a distinction between VID and View. View 
is the basic display engine, faces, feel. (lower level). VID is the 
layout dialect, styles, etc. (higher level)

yes and no. it's a VID face, which is a more complicated version 
of a face. You would typically lay it out with VID and you would 
use and manipulate it with View functions.

You could create and manage a layout with View alone, but it would 
be a lot harder, since you have to specify faces manually. That's 
why VID was created.

? face

will show you a basic face.

? system/view/vid/vid-face

will show you a VID face.

I have not quite understood what a face is yet.

I quite like learning by going through command descriptions, but 
it seems tricky to find them with Rebol.

Perhaps I should try & write the ones I need in the Wiki?  It seems 
strange that slider is not documented anywhere.

Then there is also DRAW, which is another engine used in conjunction 
with View. In REBOL 2 it works as a slap-on solution to more complex 
drawing with anti-aliasing, etc. It also has a separate font rendering 
engine, but DRAW is close to useless for layout. It's best for pretty 
drawings, that do very little.


REBOL 2 generally suffers here with multiple overlapping solutions 
for slightly different purposes, so it can be a bit confusing. View 
and VID is probably the most hacked part of REBOL.


In REBOL 3, DRAW is the only engine combined with the concept of 
GOBs: Light weight graphical objects. There are now 3 wholly separate 
parts and that concept is much less confusing.

If you do:

? face


you'll see that a face is a simple object. If you do something like:

f: make face []

view f


It'll display a gray area in the upper left corner of your screen. 
View simply takes that object and converts it into graphics.

That's about as fundamental you can get. Now, a more complex layout 
consists of many faces and this works by grouping them in a tree 
of objects.


In the FACE object, there is an entry called PARENT-FACE, which is 
how faces are grouped together in a tree. PARENT-FACE can be another 
face object or a block of face objects.


This is fundamentally how a typical View layout works, and you can 
build a layout like this by hand, by creating each face, setting 
position and size, color, text, etc. for each face, and put them 
together in a tree and display them with View.

? f shows offest    & ? f/offset shows F/OFFSET is a pair of value: 
479x202
I guess that is as much as I can find out about offset?

yes, offset is just a pair which positions the upper left corner 
of the face. nothing else.

it's jumping a little far, but essentially the face tree I talked 
about is where the slider would be.

if you make a layout with VID, a set-word! would allow you to reference 
a single face:

view layout [
	button
	field
	s: slider
]

escape to console

? s

brings up the slider face.

is there a list of documented featurs so I can try to avoid using 
the undocumented ones like Slider please?

That is very good... I was wondering if there was a tree type view 
of some of the functions in Rebol.

After this, probably go to Demos and Easy VID, for a simple VID tutorial 
(unfortunately it was never completed, but it has good parts)

Thanks for your help again :-)  I can see I could spend hours looking 
at the tree view alone...

I had a quick look at the view top when I first instaleld it, but 
it was all too advance for me then, and then I forgot that it existed.

I have studied all the information about VID that I can find, for 
2 hours mostly trying to find out how to use a slider that is shown 
horizontaly, rather than verticaly but I cant find where this is 
described.  Have deliberatly not asked how I do this because I want 
to learn how to find the answers to these sorts of questions myself.. 
Without telling me the answer directly, can anyone suggest how I 
should learn to find this information for myself please?

where face is any face you have setup in a layout.

and rebol, as a language is extremely easy to search on the net... 
you start any search on google with the word REBOL  and you'll end 
up with mailing list chats, altme pages, scripts on rebol.org, etc.

slider is sensitive to its size. if you give it a horizontal size 
bigger than vertical, it goes horizontal.

This is of course not the way it's meant to be. Unfortunately VID 
development stopped a long time ago, but there are alternatives, 
like RebGUI and GLayout. All energy is now focused on bringing an 
incredibly improved and highly well documented VID to REBOL 3.

I need to learn that trick in time as I think it is the only way 
to find out a lot of things. It can feel frustrating to know what 
is likely to be possiable, but to spend hours trying to work out 
the very first step.

I spent a couple of years figuring out the FEEL concept, so you're 
not alone.

Yes, one thing we really need in the Rebol world is for someone to 
site down and create a full example set of what is possible with 
what we have.  I too am pretty weak with VID and View, but it's been 
something I think about every time I see a new Javascript library 
with lots of examples available.

mhinson.  To give you some perspective.  Carl never intended VID 
to be the end-all-be-all graphic system.  He said he built it over 
a couple of days and expected someone to use that as motivation to 
either build their own or enhance what was started.  Ashley Trutter 
created RebGUI, which is more complete that VID.  He also received 
awards at Rebol DevCon's for his efforts.

Hi, I have read the recomended http://www.rebol.com/docs/view-guide.html
 so I have an idea of some of the stuff to expect from VID, but as 
soon as I try to do anything not explicity shown in that document 
I find my understanding is really very thin & flimsy. This is an 
example of me failing to get the results I expected. Perhaps there 
is just one basic step I have omitted that is messing everything 
else up?  Any tips would be welcome & appreciated, but dont miss 
a Sunday snooze on my account please :-)
mmm: layout [

 space 0x0         ;; thought this would make items touch each other. 
 dosnt work?
	my-sldr1: slider 300x10 [print "1 clicked"]  ; ok
	my-sldr2: slider 300x10 [print "2 clicked"]  ; ok

 space 1x1         ;; thought this would make items 1 pixel further 
 apart. dosnt work
	my-sldr3: slider 300x10 [print "3 clicked"]  ; ok
	name1: text "Inital text" 100x30             ; ok

 button "Change text" [name1/text: "Text now changed"  show name1] 
  ; ok

 button "Cente" [my-sldr2/size: 100x40 show mmm]  ;; this breaks, 
 but does make a change

 my-sldr1/step: 25             ;; imagined this did soemthing, but 
 cant see or guess what, seems to break the lat button

    my-sldr3/edge/color: blue     ;; this works but also applies its 
    self to the last button
	my-sldr3/dragger/color: red   ;; doesnt seem to work 
]

view mmm   ;; ok

? mmm      ;; shows components of object, reference for what they 
all mean is not available
? my-sldr1 ;; again guessing what they do is frustrating 

probe my-sldr1 ;; I know what the parts are but cant guess which 
ones work or what they do.

With ?, you can only see one face at a time. The subfaces are stored 
in PANE. If you try:

probe mmm


watch the console scrolling a lot of code. That's the entire face 
tree.

yes, that's fine, because that is an action of the button. The action 
is a function with 'face and 'value passed and is regular REBOL code.

ok, i moved the changes to outside the layout block, but this dosnt 
work
	my-sldr3/dragger/color: red 

and this button dosnt redisplay the layout, it just overwrites the 
existing stuff.

 button "Cente" [my-sldr2/size: 100x40 show mmm]  ;; this breaks, 
 but does make a change

I am guessing that the display is not dynamic in the way I am expecting?

When altering a facet of a face, it must be shown before the change 
can be seen.


This is a little complicated to explain: You have chosen to resize 
a slider, which is a face with subfaces. Thus if you resize a slider, 
you need to access its internal resize function, in order for it 
to properly resize the knob as well. if you alter the size of a face 
like above, you are literally only altering the size of the outer 
face of the slider. VID does not know what you are trying to do there.


BUT: Given it's incompleteness, SLIDER does not have an internal 
resize function. :-) This is not intentional, and you've stepped 
into the mud here. This is one of the most lacking parts of VID, 
in that when the layout is set up, it can be laborious to change. 
Fortunately there are unofficial solutions to that, so I suggest 
you don't bother with this and try something else.

Alternatively, try working a bit with RebGUI.

one thing about the space, is that it needs to be specified BEFORE 
the next face, cause the space is calculated when it encounters a 
face, so if you use space after a face, the space accorded to the 
previous face has already been allocated.

Resizing a slider is on reflection a fairly odd thing to want to 
do, and I was only doing it because "size" was the first thing I 
came across that sounded straight forward to do to test my understanding. 


On reflection, I think that it is unlikely for me to grasp much of 
what can be done with VID until it gets a makeover with the documentation. 
Perhaps I could contribute to the documentation on the Wiki by listing 
all the items that can be changed for slider & then discovering what 
each one does by trial & error.  would this be helpfull, or just 
cause another job for someone to delete it in favor of a master plan?

it has a few bugs, but you can play with it. docs are public.

I looked at RebGUI and had a play with the demos. Afraid RebGUI looks 
as if it would be even more complicated. I may as well start learning 
about R3 graphics as by the time I have learnt R3 I expect  R4 wll 
be in development.  :-)

there are just a few pointers to know if you want to create completely 
new styles, its not very complicated.

I am using it for my ssh-tool, which will be online within a few 
days (once I get my web server fully operational).

how do I get to the r3 console please?  I just get a dos type box 
with a >> prompt.

what do you mean by interactive?  its the same but instead of being 
a separate windows app, the console is directly within the dos prompt.

Sadly: <The R3 alpha uses the default Windows console. This is a 
temporary situation until the new console has been created. >
http://www.rebol.net/wiki/Notes_about_Windows_Console

working in a telnet/ssh session for example, I can (in theory at 
least) use rebol remotely.

for my part, I'd rather use a rebol session as a remote shell, than 
bash.

Ah that sounds like a plan

You don't even need a REBOL header anymore (I changed that).

The R3 documentation shows this example for view
view layout [
    h2 "The time is currently:"
    h3 form now
    button "Close" [unview]
]

But it does not work. Am I expecting too much from the documentation 
(sorry)    Could someone give me a graphics example that works please 
to start me off.

Sorry, I see the R3 docs are a work in progress.  I better back out 
of R3 graphics for now I think or I will get classed as a troll. 
sorry.

I have found an example for R3 here  (about the only one I could 
spot so far)

http://rebol.net/wiki/Script_Writing_With_The_Visual_Interface_Dialect

It looks quite nice with rounded corners to the buttons too.

The example crashes when you try to exit so I suppose there is lots 
to do before this is ready for general use. I know how long developmnet 
cycles can take so I won't be holding my breath :-)    


I suspect the R2 functions built in will do more than enough for 
what I want & that I just need stick with one thing till I can understand 
it enough to know what it will do & what its limitations are. 


I showed my parsing project ot a work coleague & he suggested some 
additional data that it should colect, he was very impressed when 
I implimented his suggestion & tested it all in under 3 minutes.

In the Rebol console, look at the help for, for example, Foreach 
and Forall.


Under the description of Foreach, it says "FOREACH is a native value" 
- this means it is implemented directly in C in the interpreter. 
 FORALL says "FORALL is a function value" - it is written using other 
Rebol commands, and you can see the source of it using "source forall". 
 Mezzanine refers to this second type.

Perhaps a new group "Bash Carl" should be more convenient

I was hoping to get something like this working with the data structure 
Henric helped me with above.
foreach bb b1 [ print b1/:bb/1]

but the foreach itterates all the vlaues, not just the words.

I have been thinking about this for a week or so, but dont really 
know how to get any further with it.


I suspect that if I had the right structure I could use it to store 
my data, then add additional details when I find some more, and finaly 
export the whole lot, grouped together by the key value (that I will 
only know when the script is running).


Im aproaching this in the right sort of way?  Or is there a recognised 
way to create these sort of structures please?

That is just what I wanted, thanks Brian. Is this a recognised way 
to deal with data that is presented in a different order to the output 
requirement?

No, it's just a way to treat a block as fixed records, this time 
of two values each.

If you want variable records you either put the data in an inner 
block (as you have), or use a distinct datatype for the keys ans 
search for values of that datatype to find the next key.

Are you trying to get a specific data* or to enumerate all of random*?

Ah I think I am being a numpty. your structure already returns the 
data, but I need to be able to print the keys with the associated 
data.

*a block of* name value pairs.

Sorry, missing a last ]

The pairs idea sounds productive, so it is a highly structured array 
with named groups?

Thank you very much for you time & help.  I will need a while to 
digest this & make it work with my existing code.

I think this type of structure is going to be the core of most of 
the data extraction I need to do, so I must get to understand it 
very well. I have a section that uses an array, but some of the more 
interesting data manipulation needs to cope with more varied keys. 
Thanks.

This a pretty standard way for REBOL to do lightweight data structures. 
Blocks are lighter-weight than objects. Enjoy :)

I know I could put "" values in when I create the structure, but 
I wondered if the was a neater way to do this.

if you wrap a path in ATTEMPT, it will return none.

The task I am trying to accomadate is to output my data as a table. 
so I think I can adapt your example to return "" Thanks.

I cant work out how to turn that into a function, because if I do
att: func [paf][any [attempt [paf] ""]]
att this/leads/nowhere 

the invalid path returns an error before it can be passed to the 
function.   I bet there is a good answer. I have been looking at 
using :paf, but that makes it return the invalid path

so I try to find a way to pass it as that sort of data type?

You suspect well, but you suspect too much.

It would be better if you knew all the data types in Rebol and their 
usages.

Currently you're only trying to "guess"  how to programm with Rebol, 
not to learn it.


I don't think it's always a good method to "give" the answer directly, 
especially when they are obvious.
It' gives some bad habits to the newcommers.
Sorry.

BTW, I think   any [ attempt [paf] "" ] should be any [ attempt [.. 
] copy "" ] ... ie. you need a 'copy in there.

Mhinson, i think we all enjoy to answer to people like you.
Especially because you're a nice and psersistent personn.


But after some weeks, there are questions, we don't want to see comming 
from you.anymmore ;-)

Steeve, I suspect you doubt the time & effort I have been putting 
into learning Rebol. If you have a clear idea about which sorts of 
questions I really should be able to answer from my own research 
it would give me some useful direction to my study I think. It is 
frustrating thatl I am often trying to guess how to create the structures 
I want, perhaps if I had a better foundation I would know know better 
how to learn more directly.

My advices for a very efficient learning of R2.

1/ Go on Rebol.com and read all the documentation published (it's 
your bible).

2/ Go on Rebol.org and download all the scripts published.  Test 
thoses you can, read their sources and try to figure how they work 
and what technics are used.

3/ When you have questions, At first , check on Rebol.org (the mailing 
list archive) most of the time your answer is there.

But with the time, you'll see some strange reactions like mine.

Some of your questions will be not well considered if they not reflect 
your current level.


Your current status is not anymore "i'm a newbie", be aware of that 
fact.

Steeve, I've been holding off in saying this but you have been pretty 
rude to a few people here over the past couple of months with some 
people.  Because you are such an expert, you are putting others down 
for both their efforts and questions.

The one thing that Rebol has that is somewhat unique, is a nice community, 
with varied talents, interests and programming experience both with 
Rebol and other languages.  I feel your sharp answers can be detrimental 
to those lurking, and push people away, such as myself and mhinson. 
 Your tolerance would be appreciated.

Everyone appreciates getting a response to a question.  The fact 
that this is a group called I'm New, you should maybe consider ignoring 
it if you don't want to answer questions that are repetitive or simple 
[to you].

It's a group labeled I'm New... that pretty much says it all.

people usually stop asking basic questions when they don't need to. 
  some people learn quick, some learn slow, some have a lot of catching 
up to do.. there are many reasons for someone not to *get* rebol 
from the bat.

I've been programming (scripting) with Rebol for many years, on a 
casual basis, and I can't answer mhinson's question without sitting 
down and looking at it and fumbling through some of this.

It would be good if there were enough newbies to form their own huddle 
& ask each other the questions that the more experienced people find 
tedious to answer. It takes me a good while to work out very basic 
things, even if I have an overview of more complex areas.  I have 
been learning Rebol for 2 months, it is the first serious attempt 
I have made at this sort of thing for over 20 years.

some people can't learn from documents... I know I can't.  reading 
reference documents doesn't give you the why or the other inside 
knowledge... the *better* way whcih is directly applied to a problem.

My problem is I jump in for a few weeks, then jump out for a month 
or two.  I never get past the previous level and don't stretch the 
boundaries or delve into new areas.  I will always be a newbie.

some might say I'm a guru, but yet I still do newbie error in REBOL 
sometimes... its a very "dig your own grave" kind of language.

I make newbie errors every once in a while too, and there are some 
areas where I am a newbie full time (like GUI and networking).

I'm sure he does to.  He's been very helpful for some people, including 
mhinson.  It's just a matter of being a little more tolerable when 
he doesn't agree with something.

The level of help on this group is spectacular. I think I have picked 
up a great deal, paticularly about parsing, but I know I still have 
a lot to learn about passing data types, which might seem more basic.

when mhinson won't feel like a newbie, he will start answering questions 
naturally, like we all do... this is what is so great about the community... 
everyone gets the help he needs and feels like he ows something back 
a bit.

>> a: context [b: 1]
>> a/b
== 1
>> 'a/b
== a/b
>> do 'a/b
== 1
>> att: func ['paf [path!]] [any [attempt [do paf] ""]]
>> att a/b
== 1
>> att a/c
== ""

Now the lit-word! argument 'paf is a little advanced - it means don't 
evaluate the actual argument. The alternative is this:
>> att: func [paf [path!]] [any [attempt [do paf] ""]]
>> att 'a/b
== 1

In this case, you have to pass a lit-path! as the actual argument. 
When the lit-path! 'a/b is evaluated, it converts to the path! a/b

Some of us like to answer questions, and learn by doing so. This 
group is like a REBOL-specific version of the Puzzles group :)

Brian it was not my words. 

I never said to not respond (strange it's not your habit to perform 
false denouncements) 
And i gave a Hint.
Anyone else could have completed it at this time.


But it seems some of you guys ,like to bash for nothing using false 
reasons.
And that , it's certainly more offtopic than anyting else.

Thanks Brian, I am afraid I didn't manage to solve this without your 
explicit example. "do" seems like a powerfull function that I have 
minunderstood. I have created a similar solution using lit-path! 
as well (just to learn).

mhinson has just not yet learned, how to learn a programming language. 
I've noticed that by his stumbling on every little bit of basics, 
such as lit-path and why it doesn't make sense to him, because he 
can't extrapolate how it works inside a function.

mhinson,


REBOL, like any other programming language, is a system. It's a design 
with intentions, methods and patterns and it's designer has spent 
about 25 years thinking out how REBOL should work, in order for you 
to see the elegance and simplicity of the system.


A good programmer can predict what happens in a programming language 
with a specific piece of code, not by remembering what every little 
single thing does, but by knowing how the system behaves. If you 
study the works of Ladislav (such as Bindology), you'll see how much 
time he spends on figuring out the system of REBOL. REBOL wasn't 
put together randomly. Figure out the system of REBOL and programming 
becomes way, way easier. This goes for any programming language.


It helps to, when you get to a problem, to try to figure out why 
REBOL does this and that, while you're trying to figure out how to 
solve the problem. Why do you have to pass a lit-path to a function 
for it to be understood as a path in the function?

You are right Henrik, even the programming I have done years ago 
was based on learning a set of tricks that worked in the context 
I needed, then sticking to those tricks for everything.  I can see 
that Rebol demands to be taken more seriously & I also appreciate 
the potential for "elegance and simplicity". I ride a unicycle & 
part of the appeal there is also the enjoyment of minimalism, no 
chain, no gears, no freewheel etc.


My understanding of "the system of REBOL" is about 5% I think & I 
feel like I haven't grasped enough of it yet to make my understanding 
move forward efficiently. I am just at the start of passing data 
to functions & because REBOL seems to automatically typecast a lot 
of data, it has not been in my mind that I may have to do it manually 
in some cases, but now I know that, I still can't predict which cases 
yet. 


With the lit-path! and path! data passing I understand that the invalid 
path I want to test must not be evaluated before it gets into the 
ATTEMPT section of the code, so I would expect to need to pass the 
data in a literal form I suppose (or as a string perhaps). One of 
the conclusions I am drawing from the example given is that I can 
pass this thing called a literal (I don't fully grasp what that is 
yet) but receive it in the function as a path! so it would seem that 
the passing of data to the function is also doing a type conversion.. 
At that point I don't know how the path! is not evaluated enough 
to cause an error.  If I search the core manual for "type conversion" 
it has only one mention, & not in this context. This is the sort 
of thing I do a lot to try & understand without asking too many questions, 
but my techniques must be flawed as I often fail to find anything 
relevant. (This isn't intended to be a question, just a picture of 
the muddle inside my mind).


Now I will read Bindology & hope that my understanding will be transformed. 
 Thanks again for all the help.

There are two types that get evaluated to get the value ther refer 
to and DO them: word! a and path! a/b.


If you want to just get the referred to value and not DO it you use 
get-word! :a, and in R3 get-path! :a/b, or in R2 a more complex expression 
that depends on the type of what a refers to.


If you want to set a new value you use a set-word! a: or a set-path! 
a/b: - this will evaluate as a SET expression.


If you want a literal word or path, you use a lit-word! 'a or a lit-path! 
'a/b. When a lit-word! 'a evaluates, it returns the corresponding 
word! a, not the value assigned to a. You can then pass the resulting 
word! value around, assign it to stuff, and maybe DO it later.


That lit-word! 'paf formal parameter in the first version of ATT 
that I posted blocks evaluation of the actual argument. It is treating 
the actual argument path! as a value, rather than evaluating it. 
In the second version of ATT the formal parameter is specified  with 
a regular word! paf, so the actual argument is evaluated normally. 
In order to get a path! value you have to use a lit-path! 'a/b and 
let it evaluate to get the corresponding path! a/b.

The evaluation rules follow a pretty consistent pattern, and even 
more consistent in R3. Once you get the pattern you can answer most 
of your questions yourself with a little experimentation. Don't let 
that dissuade you from asking here though :)

Thanks Brian, this is very clearly explained. so now I understand 
things like
n: 'o  probe n  probe do n  
a: 'a  probe a  probe do do do do do do do do do do a

This took me by surprise :-)  but I do understand why it happens
p: 'q  probe p  probe do p

'bind is used to bind a word or words to a context.

mhinson, BIND is all about contexts. A word is usually bound to a 
specific context (or object if you will), giving it a specific value 
that exists in that context. You can have:

a: make object! [
	b: 7
]

c: make object! [
	b: 9
]


'b is a word, but for 'c, it has one value and is bound to 'c's context. 
'a is a different context where 'b has different value.

So if you are in a situation where you have the unbound or incorrectly 
bound word 'b, BIND will allow you to change its context:

>> do [b]
** Script Error: b has no value
** Near: b

; no context above, so we bind:

>> do bind [b] c
== 9


This allows you also to refer to words inside a specific context 
without path notation.

mhinson, when I made Tretbase 1.0 engine, I used Bind quite a lot. 
 The only time I really like to use 'bind is when I have iterations 
where performance is an issue.   That way I could write a block of 
code and then just bind it into a logic based loop.  This way I didn't 
have to record additional loops to meet the logic.