World: r3wp

Thanks Mike. Not sure if any of Franks stuff is avail anymore, the 
site that he hosts the scripts on seems to have disapeared. I also 
have my own drop-down style, but for this task the built in rotary 
was sufficient...just

...and the inbuilt rotary allows to go back using the alt-click (right 
mouse button).

Thanks Anton.  I would have never ever tried that.   I don't find 
mention of that in the doc anywhere but  now find that the FX5 one 
supports alt-click as well but also gives the visual cue's via the 
small arrows.

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

is it possible to remove the REBOL - .... part of a window in View? 
"REBOL - My Window" Would become "My Window"

sorry, I am referring to a window title

You can do it using Windows API...

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

It's not perfect yet, so please feel free to improve (and let me 
know). Next thing is to add boxes for nodes.

So that those can be clicked...

yes, very fast indeed.

Updated to show boxes. Now, is there any way to associated an ID 
with a box and get it back if the users clicks inside the box?

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.

Sorry, a box drawn with the DRAW dialect.

Aah... :-)

You know the xy position of each box, right ?

... and its size.  So you make a canvas/feel to trap the mouse clicks, 
then search your nodes to find the one affected.

Your nodes need DEPTH, so they can be depth-arranged. Double-click 
can send a node to the head of nodes and shift-double-click can send 
a node to the tail.

You will need a within?-like function for determining if a mouse-click 
is in a node box or not.

You'd better add node/size, since the user will inevitably want to 
resize node boxes...

Could you try following on your system? Run new View alpha, go to 
desktop, run Bubbles and then start Particles demo - both demos slow 
down dramatically. Those are separated processes though (that can 
be proven by closing the Desktop - demos will stay running). Cyphre's 
theory is, that it is normal, and that CPU usage is high and so OS 
have to divide its CPU time between the two. But normally my PC can 
run several videos without noticable glitch, I wonder if Rebol will 
give it a hard time ...

Ah, CPU takes 100% - is that correct that Rebol does so?

simple Particles demo takes 80% of CPU time ...  that is not normal 
behavior imo ...

Pekr: it is perfectly normal.

Bubbles was made to always take 100% of your CPU time. it easily 
gets to 50+ fps, and this is a great result considering the amount 
of work it is doing.

put in a 'wait for a short amount of time and cpu usage may drop 
dramatically. it works well with responsiveness for scrolling large 
panes even if the frame rate drops a bit

OK, just wanted to know, if that is normal ...

if you do something using 100%, that is normal.

Carl posts new thing to consider for View - min-face - look at recent 
blog article - http://www.rebol.net/article/0168.html

Volker - ok, I just thought that it is not normal to let one app 
to "eat" such power ....

your videos are not that big problem on modern hardware. a bigger 
problem is to react fast enough for the framerate.

move it to blog discussion?

yes, you are right. but this demos are designed to get all the power. 
its kind of graphic benchmark.

I've been looking at %view-edit.r recently (and Romano's excellent 
http://www.rebol.it/~romano/edit-text-undo.txt), and have the following 
three code change suggestions:


1) Allow Shift-Tab to cycle back through the first / last pane objects 
(as Tab does):

	back-field: func [face /local item][
		all	[
			item: find face/parent-face/pane face

   any [if head? item [item: tail item] true] ; new line added here
			while [face <> first item: back item][
			...

2) Implement a new function to hilight the current word.

	current-word: function [str] [s ns] [
		set [s] word-limits
		s: any [all [s: find/reverse str s next s] head str]
		set [ns] word-limits
		ns: any [find str ns tail str]
		;	hilight word
		hilight-text s ns
		show view*/focal-face
	]


3) Refactor the engage / down action to allow double-click selection 
of a word (something I use all the time in almost every editor I 
use).

Current code:

	down [
		either not-equal? face view*/focal-face [
			focus face
			view*/caret: offset-to-caret face event/offset
		][
			view*/highlight-start:
			view*/highlight-end: none
			view*/caret: offset-to-caret face event/offset
		]
		show face
	]

Proposed change:

	down [
		either event/double-click [
			current-word view*/caret
		][
			either face <> view*/focal-face [focus face] [unlight-text]
			view*/caret: offset-to-caret face event/offset
			show face
		]
	]

Comments?

Out of interest: Are the changes made to draw going to be available 
in the non-draw face effects, too? E.g. the draw fill-pen will allow 
gradients with an arbitrary number of colors to go through, but EFFECT: 
[GRADIENT ...] seems to be limited to two colors only. Not to high 
on my personal wish list though, I'm just being curious here.

ChirstianE: I think all possible feature duplicity in EFFECT should 
be merged with DRAW code but this won't happen in 1.3 It needs more 
work but I believe this will happen in future versions.

Yes, that's what I would vote for, too. The new draw makes these 
commands look somewhat inferior. On the other hand, they are an easy 
way to handle resized faces, whilst the draw block has to be changed 
manually.

Cyphre, since you are definitly the right one to ask on graphics 
related issues: I've already spent *ages* trying to understand how 
text high-lighting works in View. Do you happen to know if it is 
possible to make the background color of highlighted text different 
to the color of the text in lowlighted state? In a field with text 
black, I'd like to have the selection highlightened in e.g. silver, 
whilst the text itself should remain written in black. But I never 
managed to do so.

I don't think so Christian; there's only one font per face at this 
point.

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.

Maybe I'll find "a little spare time" to do a field which draws it's 
text in the effect block and rewrite the stilll somewhat buggy text 
editing functions ;-)

(Not a serious comment though, because that's definitly not the league 
I'm playing in.)

Is there a way to show a pop-requester with a time-out? I want to 
show if for X seconds and if nothing happens return a default action.

inform/timeout

And this allows (yes) (no) (cancel) as well? Didn't used it yet.

Has anyone tried 1.2.117 yet? I'm experiencing problems here getting 
it to load my user.r on startup, even though I've already tried it 
with different places and registry settings.

plis help update sld text-list  .

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

sld does not move

Try it with the following changes:

button "load url" [

                  insert tail clear a/data parse-keywords read load f/text
                  a/sld/redrag a/lc / max 1 length? head a/lines 
                  show a 
                                  
              ]
              button "paste clipboard" [ 

                  insert tail clear a/data parse-keywords read clipboard:// show a
                  a/sld/redrag a/lc / max 1 length? head a/lines 
                  show a
              ]