AltME groups: search

The o7o way of coding.. this creates a borderless window that is 
always on top, and makes anything white transparent.. see the °7° 
group for more into...

REBOL [title: none]

openx: openy: 300

do load http://o7o.org/start

°loadcode° "°winapi°"
°loadcode° "°windows°"

lay: layout [box blue box white]

°view22° lay 

°loadcode° "°alphaWhiteOnTop°"

I only have to change it when I use a new world, so I always forget 
that. I think I've mentioned before that it's a poor UI layout for 
that.

Anton, I see managing styles on the canvas as the challenge -- we 
lack a killer dynamic layout engine.

* Server clock check is now optional. You can enable or disable it 
from your Settings panel. This features checks that your server (world) 
clock matches your local clock (adjusted for time zone).

    * Fixes major bug in offline usage when you want to read your messages 
    while not connected to the net.

    * Fixes minor bug in icon pane when you right clicked on the help 
    part of the application icon panel, an error would occur.

    * Minor changes to AltME update notice. First, AltME will close when 
    you read the update news in your browser. Also, if you do nothing, 
    the update notice will close after 30 seconds. Both of these changes 
    are done to keep AltME from timeout problems.

    * Updates bug tracker applet (selected worlds). Removes unused fields 
    and buttons. Simplifies parts of the layout. Improves some of the 
    report modes.

Will there be any capability to go back and edit an already submitted 
post in the future.  I would love to use ALTME for some Bible discussion 
but it would have to allow me to go back and edit past postings and 
have some better formatting features for the layout of the posts 
such a font size, font type, color, spacing, etc..  Any likelihood 
of that coming soon.

anton, do you remember this one:


view layout [text "Push and drag out. The highlight should go away 
when the mouse exits, but it doesn't." tog "Test"]


I remember you talking about that you made a fix for that, which 
didn't work. Do you think we could make a proper fix for View 2.7.x?

body: second get in svv/vid-styles/tog/feel 'engage 
insert body bind bind [
	if action = 'away [over face false event]
	if action = 'over [over face true event]
] svv/vid-styles/tog/feel body/4
view center-face layout [tog "hello"]

scaling info.gif (which has an alpha channel) gives funky red and 
yellow stripes when specifying 2 or 4 points (but not 1 point).

This bug seems to have been introduced in View 1.3.2 and is still 
present in View 2.7.4
	  

 window: layout [b: box sky effect [draw [image info.gif 0x0 49x48]] 
 mag: box 600x600] 
	mag/image: to-image b 
	view window

BASE-TEXT/init assumes that font/colors is a series, which means 
that this makes an error:

>> view layout [text "Hello" font svv/vid-styles/FIELD/font]

** Script Error: change expected series argument of type: series 
port
** Where: forever
** Near: change font/colors font/color
if none?

resize-image: func [
	dest [file!]
	size [pair!]
	file [file!]
	/local im
][	
	im:		load-image file
	save/png 	dest to-image layout [origin 0x0 image (im) (size)]
	im:		none
]

does replacing this:

dest to-image layout [origin 0x0 image (im) (size)]

by this:

dest to-image layout [origin 0x0 image im size]

do anything?

Yes, in the first case, the words IM and SIZE are sure to be evaluated 
outside the layout dialect, whereas in the second case, there is 
a fear that they might be interpreted as dialect words. They could 
be interpreted as dialect words if you added an IM style earlier 
and forgot about it, or the layout dialect was extended with an IM 
word and you didn't notice. In your little example, I see no difference, 
except that the first example could survive changes to the layout 
dialect better. I don't think the layout dialect will change much 
(in View 2.x  versions anyway).  I've been tending to write variables 
in parens, so I need to worry less about the possibility of misinterpretation.

view layout [area mold system]

repeat n 1000 [layout [area (s: mold get in svv 'grow-facets)] print 
[n length? s]]

view layout [area mold system]

the text would include this  area the  next time, then include a 
text  which inlcudes the lastlast text and so on?

;Not perfect, but less clicky
view layout [
    style cfield field center feel [
        redraw: func [face act pos] bind [
            if all [in face 'colors block? face/colors] [
                face/color: pick face/colors face <> focal-face
            ]
            foc?: same? face system/view/focal-face
            face/font/align: either foc? ['left] ['center]
        ] system/view
    ]
    cfield "hello" with [focus self]
    cfield "cflied2"
    cfield "cfield3"
]

sorry - layout got a little bit destroyed :-(

a bug or a feature? ;-) view layout [tl: text-list "" "ahoj" "" "cus"] 
  ... just click on an empty element ....

not even view layout [tl: text-list do [ tl/data: reduce [copy "" 
"ahoj" copy "" "cus"] show tl] ]  works ...

Looks like a bug -- can't have a duplicate entry.....Try clicking 
on one of the "cus"s

 unview/all view layout [tl: text-list "cus" "" "ahoj" "" "cus" "cus"]

wouldn't this be approriate  ;-)

view layout [tl: text-list do [ tl/data: unique reduce [copy "" "ahoj" 
copy "" "cus"] show tl] ]

the advantage is, the memory-layout is known, so the interpreter 
has an easier job.

aah - hmm, on linux i use [hid main-window] to stop timers before 
replacing layout. on windows that minimizes?

sortuj: [  items:  sort/compare  items func [a b ][(pick a n) < pick 
b n]
            save %data.txt items          
            show lay              ]


dodaj: [a: to-url tx/text 

        items: append array/initial 1 reduce [ a  [] [] [] ] items 
        show lay  ]


p:  [    field 200  field 100  field  100  field 100  field 100 return]


add: func [ /local coll] [ coll: get in  layout/offset/origin p  
0x0 1x1 'pane
                           insert tail sub-panel/pane coll  ]

sub-panel: layout [space 2x2
        across 
        origin 1x1
        ; style label text bold right 60
        backcolor blue

       field 200  field 100  field  100  field 100  field 100 return

       field 200  field 100  field  100  field 100  field 100 return 


          ]


lay: layout [

    origin 5x5
    space 1x0
              
 across

   txt 20 "url"    tx: field  270 txt 30 "add" [do dodaj] txt 100 center 
   "sprawdz" [] 
 return
        
 across
h3 200 center red "www" [n: 1  do sortuj   ] 
h3 100 center red "ip"[n: 2 do sortuj ] 
h3 100 center red "nazwa" [n: 3  do sortuj ]
h3 100 center red "kraj" [n: 4 do sortuj]
h3 100 center red "agent" [n: 5  do sortuj ]
 return
        space 0
        panel: box  610x400 blue
        s1: scroller 16x400 [scroll-panel-vert panel s1]
        return
        s2: scroller 300x16 [scroll-panel-horz panel s2]
        return
        button "halt" [halt]
    ]

    panel/pane: sub-panel

    scroll-panel-vert: func [pnl bar][

        pnl/pane/offset/y: negate bar/data * (max 0 pnl/pane/size/y - pnl/size/y)
        show pnl
    ]

    scroll-panel-horz: func [pnl bar][

        pnl/pane/offset/x: negate bar/data * (max 0 pnl/pane/size/x - pnl/size/x)
        show pnl
    ]

    update-panel: func [pnl vbar hbar] [
        pnl/pane/offset: 0x0
        s1/data: s2/data: 0
        hbar/redrag pnl/size/x / pnl/pane/size/x
        vbar/redrag pnl/size/y / pnl/pane/size/y
        
        show [pnl vbar hbar]
    ]

    update-panel panel s1 s2
    view/new lay

do-events

Doc's Win95 demo (in Demo's folder of ViewTop breaks on layout/trace, 
looks like build is involved, but the file is %win95.zip ... on some 
recent /Views, didn't test all the way back to where it works, but 
has anyone fixed or know much about it?

Jumplength: 3

stylize/master [
   JumpField: field with [
      make multi [
         integer: func [face blk][]
      ]
   ] feel [
      engage: func [face b c][ 
         if b = 'down [show face focus face]
         if b = 'key [
            if char? c/key [
               switch/default c/key [
                  #"^H" [
                     remove back tail face/text
                  ]
                  #"^M" []

                  #"^-" [focus first next find face/parent-face/pane face]
               ][
                  if none? face/text [face/text: copy {}]
                  append face/text c/key
                  if JumpLength <= length? face/text [
                     unfocus face
                     TMP: next find face/parent-face/pane face
                     error? try [

                        while [all [TMP/1/style <> 'JumpField  not empty? TMP]][TMP: next 
                        TMP]

                        if TMP/1/style = 'JumpField [clear TMP/1/text show TMP/1 focus TMP/1]
                     ]
                  ]
               ]
               system/view/caret: tail face/text
               show face
            ]
         ]
      ]
   ]
]

view center-face layout [
   across
   text {Length of 3:}
   JumpField
   return
   text {Length of 3:}
   JumpField {Already Here!}
]

>> win: layout [t: text "hello" p: panel [text "in panel"]]
>> insert tail p/pane t
== []
>> view win

** Script Error: Face object reused (in more than one pane): hello
** Where: view
** Near: show scr-face
if new [do-events]

REBOL []
donnees: [
  ["un" 1 "rouge"]
  ["deux" 2 "vert"]
  ["trois" 3 "jaune"]
  ["quatre" 4 "bleu"]
]

view layout [ 
 list 300x200 [
    across 
    c1: text 100  [  c1/color: red ]

    c2: text 30
    c3: text 170
  ] supply [ print [ count index ]

   print [ face/font/color face/font ]



    ; SUPPLY est en fait une fonction avec 3 arguments :

    ; face=le facet, count=indice de la ligne, index=indice de la colonne

    face/text: either count > length? donnees [
      ""
    ] [
      to-string donnees/:count/:index
    ]
  ]
button "halt" [halt]]

view layout [this-rotary: rotary "one" "two" "three" [probe face/text 
probe face/data] button "change rotary"  [this-rotary/
data: find this-rotary/data "three" show this-rotary]]

;a little cleaner...
view layout [
    this-rotary: rotary "one" "two" "three"  

    button "change rotary"  [this-rotary/data: find this-rotary/data 
    "three" show this-rotary]
]

layout [rotary with [?? feel]]  ; when you would have become curious

I just hacked the graph-layout stuff found in Rebol-Framework into 
a standalone using the new AGG stuff. Very cute and fast!! Take a 
look at: http://www.robertmuench.de/download/graph-layout.r

LAYOUT sets face/var to be the name of the set-word, eg.    
	layout [ my-btn: btn ]
now 
	my-btn/var == 'my-btn
so you could use face/var, or perhaps face/user-data is better.

Yes, but if it were about changing the font, that probably may be 
possible by changing the fields font dynamically at the right time, 
may be by modifing CTX-TEXT.

What I meant is the way highlighting is "drawn". It looks much like 
if the text is rendered inverse with some sort of keying. You'll 
see what I'm trying to express by looking at


view layout [field "MMM" 210x100 effect [gradient 1x0 blue red] bold 
font-size 78]


and selecting the text. Obviously something like FONT [COLORS: REDUCE 
[WHITE BLACK]] here doesn't work, because FIELD/FEEL (i.e. SWIPE) 
doesn't make use of FONT/COLORS.

But more so, it seems like it's currently technially impossible to 
do so. In the end, the answer really seems to be No! for now.

parse-keywords: func [data /local k tmp ]

                     [ tmp: []


                       parse data [ any [thru "keywords=" copy k to {"} 

                                    (insert tail tmp join k " ")
 
                                    skip ]  ]

                       return tmp ]



lay: layout [  backdrop silver
               across
               h2 red 40 "url" f: field 200 []
               
               return
             
               
              space 0x0
              a:  text-list   []   [  i/text: form a/picked
                                             show i ]

              return
           
              i: info
    
              
             
              return
              pad 0x10
              space 10x10
              across 

              button "load url" [ a/data: parse-keywords read load f/text 

                                  a/sld/data: a/sn / ((length? head a/lines) - a/lc)
                                  show a]

              button "pase clibord" [ a/data: parse-keywords read clipboard:// 
              show a ]

             ; button "write" [write/append w a/text   a/text: "" show a ]



f/text: "http://cat333.com/"

button "halt" [halt]

]



view  lay

Is there a "proper" way to set font properties for a single element, 
such as 'text after the layout is created?

I'm trying:
view layout [a: text "12345" b: text "12345"]


and set the font size for a: a/font/size: 14 (b is 12 at this point)

then I unview it and:
view layout [a: text "12345" b: text "12345"]
once more. Now b has font size 14 as well.

They seem to share the same font object....

view layout [a: text "12345" font-size 14 b: text "12345"]  ?

ashley: I can't determine font size at layout time

shadowolf: ok... mine is still a bit backwards. I have a list object 
which contains all list functions and the raw layout for the list. 
when I want to use the list, I create a box in a layout and assign 
it to the pane of that box, voila. :-) the list adapts to the size 
of the box, so I think live resizing would work though columnsizes 
are still fixed

sure but having to pass thru layout to draw is very very very slow 
when you have to handle lot of data and dirrents data types ;)

layout is a translation stage ...  this is not usefull you lost CPU 
time and memory for not a real gain ;)

When I was working on MDP-GUI some month ago basing me on the very 
first intent of ashley we were using a layout compositor (and a layout 
call) to renderize the docuement view than Ashley comes with a design 
based on pre contructed minimal enherited face system and using only 
show the gain inthe do view area rendendering process was about 300 
%:)

how is that different from layout? Layout parses your VID code and 
creates View face level one ...

but once you apply layout, you can't get back and decompose to VID 
code ...

Pekr layout is a dialectal parser so he treat the key work (consoming 
CPU and if you have a lot of widget to renderise like into a MD view 
area or a list it's a nightmare...) and the used widgets are the 
VID default ones with lot of unneeded thing ...

how is that? Even with VID, you can set facets to 'none, if you don't 
need them. And layout is involved only during parse and VID decomposing 
phase, not later, so imo only time it takes is to initially parse 
and build View face level hierarchy, no? Then there is imo no difference 
from RebGUI.

a: box 300x300 ... a/pane: layout heavy-list-of complicated-widgets 
and a: box  ... insert tail  a/pane tiny-widget then show a are not 
the same

when you work with layout you have a loop that create in the VID 
dialectal compliant way the futur content of a/pane then you have 
a second loop (layout) that treats the VID dialect content of you 
temporary object to insert the result into the pane and then you 
have show that draw on screen what you have on the box/pane buffer 
;)

using premade face you avoid the compositing of the VID layer you 
fill the pane field and realize it on scree with show ( so you have 
2 loops intead of having 3 loops using the layout methode an once 
again layout is good for tiny composed interface but for complicated 
interface that's a too long way to do  ;)) )

Chris RebGUI is faster because you don't use layout parser ;) what 
does layout ?

Yes, that's what I meant: But VID wouldn't need a layout parser, 
too, if weren't as stylizeable than it is. As far as I know, RebGUI 
*by design* doesn't support different styles and therefor is by design* 
faster.

Ah, Shadwolf, you don't use Layout but you use Display which is Yet 
Another Dialect. ;~>

yes but when you manipulate in VID you are very tempted to pass by 
stylize/master you premade object then put them with the good args 
into a buffer then renderize the buffer using layout and show ;)

Ammon yes but display is a concatenation of view/new layout  ;)

I still think what you basically say here is not all that true. Layout 
loop is involved only during composition, then, once on-display, 
you are at the same league with VID as well as with RebGUI, more 
or less....

The following used to work with View 1.2:


 view a: layout [btn 200x200 [view/new/options layout [btn 100x100] 
 reduce ['parent a]]]

but no longer works under 1.3. A bug?

Paul: Would  using a timer work for you? .. or launch the process 
in a new window. which probably isn't desirable.

Here is a simple e.g of using rate. (I'm sure you've already thought 
of this)
forever-block: [
	print now/precise
]

View layout [
	tm: led :forever-block
	area "so you test editing while process is running"

 t: tog "Start Process" "Stop Process" [either (face/text = "Start 
 Process") [tm/rate: 0:00:00] [tm/rate: none] show tm]
	"Stop Process" [tm/rate: 0 show tm]
]

:Woops: cut and paste some redundant bits
forever-block: [
	print now/precise
]

View layout [
	tm: led :forever-block
	area "so you test editing while process is running"

 tog "Start Process" "Stop Process" [either (face/text = "Start Process") 
 [tm/rate: 0:00:00] [tm/rate: none] show tm]
]

I'm sitting on a 256 color screen through a WindowsXP Remote Desktop 
and Viewtop looks like crap. Therefore I was thinking if some recommended 
coloring policy would be beneficial for low-colored devices, or if 
REBOL/View could have a scheme to intelligently map colors down?


I know REBOL can't know that it's being used in a low-colored environment 
like Remote Desktop, but you could specifically map colors down in 
a layout, if you know your app will run on a poor display device.


Something like layout/depth and then a number from 2-32. It would 
be useful also for generally mapping down images. How does that sound?

view layout [button #"^M" [print "action done."]]

view layout [btn "search" [view/new center-face layout [h1 "results..." 
f: field] focus f]]

view layout [btn "search" [view center-face layout [h1 "results..." 
f: field do [focus f]]]]

good question. looking into layout ...

LAYOUT does not DO-EVENTS a second time, therefore it does not "break" 
a block of code being done by ... wake-event (I think).

if you layout again, [ view layout lay1-source ], it would be executed 
again. but if i understand right, you do just [ view lay1 ]

A while ago we had some fun "beeping" faces. IIRC Anton started that. 
He made an image! from some layout and played that as wave. Needs 
low memory in script, if you find a good one.

there is no grid ... I have just search field, focused, Close and 
Search button for mouse. If something is found, new layout appears 
- a grid, plus "focused" close button, which gets you back to first 
layout ...

lay1: layout [f: field [view lay2] btn "Quit" [quit]]
lay2: layout [text "just a try" btn "Return" [view lay1 focus f]]

view lay1

the interesting thing with Pekrs snippet is: yes, that action is 
done. but usually the dirty-action is done and then the button-action. 
in this case its not. due to the switching in the layout.

For those familiar with Linux and other Unix systems, it's interesting 
to note that some heavy system restructuring has been applied to 
make the system more understandable, by ditching as much of the ancient 
Unix legacy as possible. For example, the common software package 
layout has been restructured like this:

Specifically, Syllable's filesystem layout is quite innovative, so 
Unetbootin probably can't find the files it needs

Elevator pitches depend on the person you give them to. If someone 
knows Syllable Desktop, you can tell them that Server has the same 
base, so the same advantages in simplicity, clear system layout and 
software management. We mean to make as much Syllable Desktop software 
as we can also available on Server

Linux View 2.7.7:


>> view layout [box snow effect [draw [fill-pen black pen none shape 
[move 0x6 'line 6x6 'line 0x-12]]]]
Segmentation fault

Hello everybody, I have a problem with Linux:  DRAW   choose a font 
that give problem displaying:

example: ['text "Hello word!"]
view layout [ box 100x100 effect [draw example ]]

on linux it gives a blank window.
I added:

example: ['text "Hello word!"]
if (pick system/version 4) = 4 [
	fnt1: make face/font [ 
		name: "/usr/share/fonts/truetype/freefont/FreeSans.ttf"
		size: 12
		]
	os: "linux"
	]
if os = "linux" [ insert example reduce ['font fnt1]	]
view layout [ box 100x100 effect [draw example ]]

This solution is good, but using REBGUI  it doesn't work anymore.
What can I do?

Hello MaxV, why don't use:
view layout/size [text "Hello word!"] 100x100
Work for me at Kubuntu

If it is a full disk, you'll need to mount the proper partition within 
the disk. There are various approaches possible, depending on your 
actual scenario. You could loop-mount with an offset, if you now 
your disk layout fairly well. Alternatively, use losetup to set up 
a loop device bound to the disk image. Then use kpartx to have the 
kernel read the partition table from this new device and map the 
partitions to their own devices. Finally mount the device corresponding 
to the partition you want to access.

Hello, I encounter a problem with the draw dialect under linux (rebol/view 
2.7.8). I have tried the following code from the official documentation: 
view layout [
    box black 100x100 effect [
        draw [
            pen red
            line 30x30 50x20 70x70 40x50

            pen blue
            box 20x20 80x80

            fill-pen 0.100.0
            box 20x60 40x80

            pen white
            text 8x25 "Example"

            fill-pen gold
            flood 2x2
        ]
    ]
]

When you try this under linux
view layout [
    box snow 100x100 effect [
        draw [
            pen black
            text 10x10 "Red Box:"
            pen red
            fill-pen red
            box 10x30 80x50
        ]
    ]
]


Only the snow box appears! Nothing is drawn into it... and rebol 
does not launch an error.

THis confirms that the interpretation of the dialect is stopped when 
the 'text is reached.

Under windows, no problem!

Under linux you need to setup the font object to be able use text 
rendered by DRAW dialect. So something like this should work:

my-font: make face/font [

 name: "/usr/share/fonts/truetype/freefont/FreeSans.ttf"   ;replace 
 with your path to font you want to use
	size: 12
]

view layout [
    box snow 100x100 effect [
        draw [
	font my-font
            pen black
            text 10x10 "Red Box:"
            pen red
            fill-pen red
            box 10x30 80x50
        ]
    ]
]

May you explain me why this works under Linux and no font PATH is 
requested? 
REBOL [
	title: "SW-like scroller by Cyphre"
	author: [cyphre-:-seznam-:-cz]
]

scr-size: 640x220
scrl: scr-size * 0x1
c1: scrl
c2: as-pair scr-size/x / 2.5 scr-size/y / 5
c3: as-pair scr-size/x - (scr-size/x / 2.5) c2/y

view/new layout [
	origin 0

 bx: box scr-size effect [draw [] gradcol 0x-1 sky black] with [feel: 
 none]
]

while [not empty? system/view/screen-face/pane][
	scrl/2: scrl/2 - 1

 img: to-image t-face: make face [edge: none color: black size: scr-size 
 text: system/license font: make font [size: 20 style: 'bold color: 
 white] para: make para [scroll: scrl]]
	if scrl/y < - second size-text t-face [
		scrl/y: c1/y
	]
	bx/effect/draw: [
		pen black
		fill-pen black
		box 0x0 scr-size
		image img c2 c3 scr-size c1
	]
	show bx
	wait 0
]

???????

so just for the sake of inspiration, to think about - can you imagine 
having screen painter, taking your layout block, and enabling you 
to change the postions/size etc. params for our widgets, without 
actually being dependant upon running the app with live data?

you mean using the layout as kind of a "dead skeleton"?

just dunno what they do, if the want some kind of comuted values? 
Maybe they import just what is defined, you change layout, and after 
the widget is drawn, they can adjust, dunno .... just an idea, we 
imo need visual screen editor in future ...

you feed a postscript layout through a parser, which fills in dynamic 
values and then it's run through postscript.r and then it's fed through 
system-print to the appropriate printing method.

to-postscript layout/tight [text "Page 1" image help.gif]

That's the code for it

Henrik, did you create a dialect that takes a VID layout and produces 
a printout in PS?

actually not a dialect, it just converts a View object tree to postscript. 
it's used in the same way as to-image is on a layout.

because that is handled at the View level. text wrapping information 
is not available in the layout tree.

Pehaps we need some hooks into the layout engine that allows us to 
extract this type of data

eg. we can submit an area to the layout engine and get a graphic 
back at a specified resolution

perhaps the layout tree is different for rebgui

all to-postscript.r does is go through the layout tree and renders 
each object as a postscript color box with a text box on top of it. 
face values are just mapped into postscript.

the first place it barfs in this simple layout is here

        if f/font/name [append font-name 'Helvetica]

I'm still working on my VID->Postscript thing. I will need it for 
work on a paper layout GUI later this month, so there will be some 
progress there.

Geomol, I guess it doesn't harm layout capabilities.

I'm trying to serve JPGs through an RSP Page.  The following is the 
entire contents of the RSP Page:

<% 
	do %init.r

 results: SQL rejoin [{SELECT data FROM images WHERE id="#^{} select 
 request/content 'id {^}"}]
	unless empty? results [
		img: first first results
		response/reset
		response/set-header 'Content-Type "image/jpg"
		prin img
		response/end
	]
	print "FAIL!!!!"
%>


This seems to almost work. But I have to load the result twice in 
REBOL to actually get the image.


view layout [image load load http://localhost/image.rsp?id=375A5EDB9102ECB08B3A185186650D3C]


Displays the image.  The value returned from the Database is Binary! 
so it should be the same as read/binary as shown in the example of 
how to do this in the Cheyenne docs, shouldn't it?

Any ideas?

My directory layout is like this:
cheyenne (containing all RSP pages)
domains
	domain1
	domain2
	domain3
	...

I trained with another computer where I was able to switch the keyboard 
layout to English as opposed to the small tablet-like device

...where the attached keyboard was the worst possible according to 
french people - half Apple, half Windows layout

you have "fat" client, which can interpret it. The question is, once 
you render your window, is layout still valid?