World: r3wp

You are missing line-pattern in your code... this is working:

view layout [box 120x70 effect [draw [pen black green line-pattern 
1 5 polygon 0x0 119x0 119x69 0x69]]]

(anyway.. it's a bug.. which should be easy to fix I guess)

if you don't want to use line-pattern you should not use 2 colors 
for pen..

Darn..  =P   I was taking it as, for polygon, the line would be the 
first color and the inside would be the second.


Are there any more recent draw docs, then, so I don't get overly 
confused like this time?

but it is in the doc.. (the link above) If you want to make fill 
use fill-pen

...I was about to say, "then why is it called 'foreground' and 'background' 
color under pen?", then took another look - I somehow completely 
missed the last line under the "Pen" section...

Okay, just a lot of my mistakes..  ~innocent grin~

Challenge;  A REBOL face face.  Ok all you graphically inclined; 
come up with a face that is a face.

Given this graphically PT version ... what can you do to make the 
face of REBOL.

face-block: [
    pen blue ellipse 150x150 100x120           ; head

    fill-pen green circle 110x110 10  circle 190x110 10             ; 
    eyes
    fill-pen black circle 110x110 3  circle 190x110 3
    fill-pen pink ellipse 150x150 10x20        ; nose
    fill-pen red ellipse 150x200 25x10         ; mouth
]


view layout compose/deep/only [box 300x300 sky effect [draw (face-block)]]


Extra points for blinking, winking and moving lips, but simple is 
better  - plans is to show students.  :)
(For those that need to know ... PT is short for part-tard).

hoping for some help. I copied my desktop view install to a usb pen 
drive for my laptop and made the mistake of not doing an install 
so now it does not see my local dir.I used regedit to delete all 
calls to view I could find rebooted and still the same problem :( 
Any hints ? Thanks !

What happens if you actually do an install?

Is http://www.rebol.com/docs/easy-vid.htmlthe only documentation 
from REBOL Tech we have for vid  ?

Surely not - there is at least one other ...

and also very precise View documentation - just go to rebol.com docs 
section

http://www.rebol.com/docs/view-guide.html

Pekr,  I need the other VID guide for the REBOL2 DocBase pages but 
the only one I have found is a VIEW guide http://www.rebol.com/docs/view-system.html.
Are you sure another and updated VID guide exists ?

you mix two things - vid and view ... the best doc for view is view-system. 
As for VID, there are just those two links present here. In other 
words - if you can't find it on RT's site, it probably does not exist.

Excuse me but isn't http://www.rebol.com/docs/view-guide.htmla VIEW 
guide or is it a VID one ?

VID

Mostly  ;)

Those 2 guides are both from 2001. So VID has 2 guides and VIEW only 
one updated in the year 2005.

I have reflected your statements in the REBOL2 wiki

I more and more often feel, we need at Style Guide for REBOL. Not 
for the source, Carl have already written about that in the Core 
guide, but a guide to user interfaces. What key combinations should 
mean what? Should labels for fields be left- or right-aligned? etc. 
I know, many of these things are different in different operating 
systems, but we build applications, that can run across many OS's. 
So I feel, we need at standard guidance to do these things.

Agree? Disagree? Comments?

I'm definitely planning one for R3. Perhaps it can also be used for 
R2.

Maybe we should put a group together to figure this out? Or is it 
best, if one person do it? We also need input, ideas and viewpoints.

we definitely need some input, but I think one person should write 
it.

Yes, less babble, faster decisions! Why don't we have ... like 10 
Carls around? ;)

We need cloning technology for REBOL.

I own the original Commodore User Interface Guideline manual. I hope 
to build something like that.

The dark-grey cover one for Amiga? I have that one too somewhere.

yep

but... I also hope that we can build some very high level user interface 
elements, like entire skeleton windows with content. they will be 
guidelines in themselves.

imagine a preferences window like in Amiga MUI: The left side is 
a list. The right side is a set of switchable panes.The bottom would 
be functioning OK/Save/Cancel buttons  If that is available as a 
standard window type with all the mechanics for switching, so you 
only need to fill out the list in the left side with titles and some 
GUI elements for each pane in the right, and then be able to use 
it.

there are many different common window types.

I may be biased ... no, I know I'm biased.  I'd start here;
http://developer.kde.org/documentation/design/ui/index.htmland

http://developer.kde.org/documentation/standards/kde/style/basics/index.html

of note;  http://developer.kde.org/documentation/standards/kde/style/basics/badInterface.html

But none of this is of much use without  Menu   we really really 
need Menu  until then, View apps look just plain wrong, designed 
by people then never read CUA.

I remember seeing the GUI/Program builder for the NeXT computer, 
when it first came out. That seems awesome. You specified, what type 
of application, you needed to build, and voila you've got the sceleton 
with menues and everything. Maybe it's something like that, you're 
after, Henrik.

This is also a must-see, when doing interfaces:
http://www.useit.com/

It's a bit like that (XCode for OSX does exactly the same thing, 
BTW), but I think it's on an even higher level. Where XCode and its 
predecessor gave those easy hints at first, when you got your window 
and user interface elements, then you needed to know next how to 
connect the dots. The trick is to learn that, and then it's probably 
easy, but after following several tutorials, I'm still lost. It's 
actually a bit like in VID in R2 when you suddenly must learn about 
FEEL and the various CTX-* objects in order to understand what's 
going on. I'd hate this sudden jump in difficulty to be present in 
VID3.

Hm

I think there is to much emphasis on building super easy and fancy 
interface builders. Then when you need to code, you go "OK, now what?" 
and all the time advantages are out the window.

One thing is for sure: We need to keep it simple!

I think it would be a good goal to be able to build an operational 
Preferences window in 2-3 lines of R3 code.

Does routines to let you do that need to be in R3? Or can it be a 
software-builder-library, that you load, when you build applications?

that depends on how big they are and how well they are put together.

How about a great tutorial on how to build the preferences window. 
 Then you kill two birds with one stone ;-)

Henrik, your comments on Xcode are spot on, for the easy first step 
you are rewarded by a sudden learning curve to understand why things 
need to be wired up in a certain way.

.

I'm using a single "area" right now to display a list of notes but 
would I like to do something like what we see here in Altme; that 
is, a scrollable list of rows that have differing heights. Any thoughts 
about how I can accomplish this feat? I tried list with supply but 
all I get is a bunch of areas the same height. I think that you cannot 
have such a thing with list/supply so there must be another trick.

Look at DideC's altme viewer, or, look at the source to my chat client.

Basically you have to construct the whole row as 3 separate faces 
and keep appending them to a much larger face.

James, it is quite difficult to make an iterated list of AREAs using 
LIST, retaining all the correct behaviour as expected for an AREA. 
I remember trying pretty mightily to achieve this, but, in the end, 
I have no example to show. If you were going to try, you would program 
the pane function directly yourself, rather than letting LIST use 
its default pane functions.

So I recommend the approach, as Graham above, of generating real 
faces (at least for the visible part of your list).