World: r3wp

There could be some number of image binaries so it takes as long 
as 10's of seconds to a minute....long enough to make user think 
program as frozen!

the mysql protocol is sync, and not async asfaik, so you can't out 
of the box.  if view could display animated gifs then you could but 
it can't

You could do the animation in a separate process and kill it when 
the transfer is done

or do the insert in a separate process and check the result while 
showing the animation.

I'm using Christopher Ross-Gill's animation style. I wrote a little 
function to convert an animated gif to an image file that the style 
can use....

Kaj, I thought about doing something like that but how do you kill 
the process from rebol?

I guess that's system dependent. You could also keep a status info 
or transfer process running and communicate with it via 0MQ

Re: animation, Nick wrote a cool example using "anim" in rebol.org

BTW, this function, anim, seems to be one of the least documented 
ones. Anton has done the best explanation I could find. http://www.mail-archive.com/[rebol-bounce-:-rebol-:-com]/msg00604.html

What "help" command to I need to issue in order to see what value 
are accepted by a refinement? e.g.
  view layout [
     button  ????
     size  ????

help layout/styles - didn't work
help layout styles - nope!
help layout styles button - nope!

So what is it?  :)

There is no built-in help to get the settings for the LAYOUT dialect 
(other than SOURCE LAYOUT....and a lot of code reading :).
Easiest starting point may be the user guide:
    http://www.rebol.com/docs/view-guide.html

Just did a bit of poking:

>> layout [X: button]
>> ? X/doc
X/DOC is an object of value: 
   info            string!   "rectangular, rendered buttons" 
   string          block!    length: 2 
   image           block!    length: 2 
   logic           none!     none 
   integer         string!   "width of button" 
   pair            string!   "width and height of button" 
   tuple           block!    length: 2 
   file            none!     none 
   url             none!     none 
   decimal         none!     none 
   time            none!     none 
   block           block!    length: 2 
   keywords        none!     none 

>> ? X/doc/block

X/DOC/BLOCK is a block of value: ["execute when clicked" "execute 
when alt-clicked"]
>> view layout [button [print "clicked"][print "alt-clicked"]]
clicked
alt-clicked

Rebol 2.7.6, so hopefully it holds in newer versions  =)

@izkata -- Much obliged!! BTW, works great with REBOL/Core 2.7.8.4.2 
(2-Jan-2011)

Just so I learn a bit more, can you tell me exactly what your code 
snippets are doing, please. Like:
layout [X: button]  ??

? X/doc => you're asking for help about the word X with the "doc" 
refinement

Where did the /doc come from?

? layout

tells you, what LAYOUT is. By knowing what layout is, you may see, 
what the layout call does in the example. An effect is, that X is 
being defined.

? x

tells you, what X is. Look near the bottom, and you see DOC as being 
part of X. DOC is an abject within X, which also is an object. So
? x/doc
simple ask info about doc within x.

Duke: You can use dump-face function to get list of styles in your 
layout.

>> win: layout [bt: button 30x20 "Hello" lb: label "Test"]
>> dump-face win
Style: none Offset: 50x50 Size: 72x87 Text: none
     Style: button Offset: 20x20 Size: 30x20 Text: Hello
     Style: label Offset: 20x48 Size: 32x19 Text: Test

Or write your own:
>> win: layout [bt: button 30x20 "Hello" label "Test" led red]
>> foreach p win/pane [print bind [var text style offset size] p]
bt Hello button 20x20 30x20
none Test label 20x48 32x19
none none led 20x75 12x12

@Geomol: Where do you X in ? layout ???

If I'm learning, how would I ever "guess" to do an ? X or ? X/doc 
???

Sure ! It's being defined by "layout" - but how is a noob suppose 
to know that? 


Originally, I wanted to get help with the "layout" refinements. To 
me, it seems intuitive to simply do:

? layout/styles

But I guess that's too easy :))

@Endo: Thanks ....

More poking around:

>> foreach [name style] system/view/VID/vid-styles [? name]
NAME is a word of value: face
NAME is a word of value: blank-face
NAME is a word of value: IMAGE
NAME is a word of value: BACKDROP
NAME is a word of value: BACKTILE
NAME is a word of value: BOX
.....more...

Duke, it's maybe not the easiest task to try to understand the graphical 
parts of REBOL as the first thing. Maybe get a feeling for how objects, 
functions and the other parts of the language works first?

For my previous snippet:

>> layout [X: button]

X is just a generic variable name I use when I need a throwaway, 
like others use "foo", "bar", and so on.  Layout is just assigning 
the button object to the word X, which I'm exploring in the next 
few lines like Geomol explained.


I explored system in the same way to find view, then VID, then vid-styles. 
 vid-styles is a block containing a series of alternating names and 
definitions, which the foreach loop is simply going over

@Izkata:  I understand your X now!  If /doc is simply a refinement 
to "help", then that fact is not showing up when "help" is entered 
by itself.

bottom line: I simply wanted to use the "help" system to explore 
 what's available in "layout" and how to use each component. I was 
assuming that the "help" system was a comprehensive reference. It 
may not have been designed as such.

You are being thrown off, because LAYOUT processes a dialect, which 
HELP has no chance of understanding.

It helps to understand, what LAYOUT is doing: As you may know, VID 
is a dialect, which is a parsed collection of words, numbers, strings, 
etc. in a specific format, essentially a sub-domain language, within 
REBOL. The job of LAYOUT is to parse the dialect block and convert 
that into a face tree (a face is just an object, try typing FACE 
in the console). The face tree can then be fed to the VIEW function, 
so the layout can be displayed, so:

VID -> layout -> view -> window displays with content


You can also create a face tree manually, but that's far more laborious, 
which is why VID is there.


When LAYOUT creates a face, it does so in accordance with a style 
from Izkata's shown style list, such as IMAGE or FIELD. A style is 
essentially a prototype face.

VID is however quite sparse, as it was written in a week, by Carl, 
a decade ago. There are some extensions and replacements available.

as it was written in a week, by Carl
 is that true? Cool or pity :)

That's what he told me some years ago. It was only meant to be a 
demo of View.

the initial version, yes. but, vid has been worked on after that...

Wasn't R3 going to add help for dialects?

@Henrik:  I now understand the "hoops" that need to be jumped into 
in order to get graphics to happen in REBOL. 
Is REBGUI an extension/replacement for VID? 

I sure hope that the answer to Kaj's question is "yes" - cuz that 
would make the "help sytem" much more useful, IMO.
Thanks for the input!

Rebgui is an alternative to vid ... it has more widgets but is less 
flexibles

Kaj, I think Carl is still thinking about that. The R3 GUI will provide 
some documentation.

In the past I proposed help to use a refinement, e.g. /custom, /dialect, 
and the format would then be:

help/custom dialect-name "button"


It is a problem right now, as 'help uses just one argument. But maybe 
it could just accept more types, e.g. a block, and then we could 
have a dialect to help us with dialect help :-)

I think one solution is to add a uniform domain based dictionary 
(one domain for styles, one for VID, one for other dialects), that 
help understands, but it can unfortunately not make dialects themselves 
self documenting. Possibly there would be automated dictionary builders, 
but these take a lot of time to run during startup, so maybe they 
should be some sort of callbacks from help to get just-in-time help 
on a domain.

Then you could use:

>> help/on styles

to get a dictionary on the styles, based on a dictionary builder.

@GrahamC:  Thanks for clearing that up in a nutshell.

@Henrik  & Pekr:  IMHO, enhancing the "help" system as you suggest, 
is the greatest form of advocacy that the REBOL community can undertake. 
let the "help system" be as comprehensive as possible - whatever 
form it takes, so that REBOL novices are not faced with yet another 
source of stress and uncertainty - especially if they come from a 
non-Forthish or LISPish background. If a novice can solve - by himself, 
using the "help system" - what he perceives to be an ambiguity, already 
that is a success  which can only give impetous to continueing his 
exploration of REBOL.

Question:


If you have a window face and SHOW it, does it perform a different 
kind of SHOW, if the window face /CHANGES is set to TEXT or ACTIVATE? 
I have some problems refreshing a table along with changing the window 
title during the same SHOW.

RebGUI SHOW is not the same as SHOW for VID

I know. The problem is however the same with RebGUI's SHOW-NATIVE.

IIRC, /changes meant that show did not do all the work, but only 
what it was asked to do by /changes

ok, thanks

I'm studying a possible font alignment bug with Cyphre:


view layout [origin 0x0 space 0x0 t1: text 100 black white "Boo" 
right t2: text 100 black 200.200.200 "Boo" right bold]


Does the last "o" line up to the same pixel for you (correct) or 
is there a slight misalignment (wrong)? State your OS, please. Thanks.

I can't see any mis-alignment (we're looking for it to be flush right, 
yes?)
  Win 7  rebview 2.7.6

Correct alignment here, and bold doesn't seem to have an effect, 
as both texts looks the same.

OS X v. 10.6.8, View v. 2.7.7

Correct alignment under WinXP on same Mac using VirtualBox. Here 
the 2nd text is bold, starts 1 pixel before, so it's correct aligned 
on the right side.

Looks OK here, XP x64.

View 2.7.7

Not sure what we are looking for, but here the bold text i shifted 
cca 1 pixels to the left = both "Boo" texts are not aligned to the 
right to the same pixel ... View 2.7.8, Windows Vista

Ubuntu 10.04, View 2.7.6


Both the 'o's in the lines start at the same place as the one above/below, 
but the bold ones are 1 pixel wider on the right.

The 'B's end at the same place, but the bold one extends 1 pixel 
further to the left.
Neither is flush with the right side of the pane/window