World: r3wp

:) The next problem is: why is the "Open" button asking to save ?

open tries to save the last file. it thinks it is modified, instead 
its missing. but text <> attempt[read file], so..

Ok...

Gosh! the two scrollers interact with each other...

its tricky to stop the timers. hide works but flashes. hide on window 
does not flash on linux, so i thought i had a good way.

yes, use the left. the right scrolls a fixed amount.

sometimes i have files with some 100kb. than the normal scroller 
scales not fine enough. then i use the right one to scroll in that 
area.

Ah yes, a relative scroller. Middle-mouse button would be good for 
this one day...

yes, poor mans middle mouse :)

Maybe we can trap right+left combo ?

hmm, worth trying

I wanted to make one of those relative scroller icons as seen in 
Firefox. One day...

Well, I got it to colourize some code. Pretty ugly ! ;-) but you're 
getting there. Interesting "floating" coloured blocks.

interesting point is, you give it a text-face, a start and end, and 
a template for markup and do:
  markup-face ta make markup-face! [color: local/2] start end
and then you have markup :)

Very cool Volker! You never cease to amaze me.

*=blush*= :)9

:.)9 -> :)

Does anybody know if it's possible to catch third mouse-button's 
up and down events? I know of the scroll-line and scroll-page thing, 
but ...

I don't think so. Let me check the binary :)

Nope, there's only down, alt-down, up, alt-up

On windows maybe the system port will see the WM_MBUTTONDOWN & UP 
messages.

Did you know you can do the whole markup with iterated faces? 1766 
markups ~8000kb.

ChristianE, see (if you haven't already) the "Windows (MS)" group, 
where I posted some extra notes showing the beginning of how these 
messages can be captured using the system port (only on Windows, 
obviously).

I remember reading problem about using serial port with View window 
: you have to move mouse to get proper serial transfer (if not port 
take 1 sec to respond). Can't remember what was the conclusion about 
it ?
Anybody ?

Petr says he owes me a beer cause I told him the solution to that 
.. but now I can't recall what it was!  :(

neither I .... hmm, I will look into my sources ...

wasn't it addition of timer to layout?

timer: sensor 1x1 rate 0:01 feel [
        engage: func [face action event] [
            if all [action = 'time] [
                do-face face none
            ]
        ]
    ]

yes, I think it was.

www.rebol.net is working (showing the new server) OK.
link to rambo is OK  (and rambo lists newest bug OK.)
link to http://mail.rebol.net/::: 503 Connect failed

Your request for http://mail.rebol.net/could not be fulfilled, because 
the connection to mail.rebol.net (209.167.34.210) could not be established.

(sorry)

Paul, irregular windows - Cyphre did one I'm pretty sure.

Thanks Gregg.

http://www.rebol.cz/~cyphre/trans-gui.r
http://www.rebol.cz/~cyphre/trans-win.r

Is this a bug or by design?


A faces pane, if of type block!, may contain not only face objects, 
but allows for words too (and maybe other types, but I didn't check 
this). At least it works and View doesn't complain.  

I sometimes use this for easy access of faces in crowdy pane; e.g. 
for faces A, B, C and F I can set do F/PANE: REDUCE ['a A 'b B 'c 
C].


But now I noticed in some popup-faces' code that SYSTEM/VIEW/WAKE-EVENT 
fails in such cases because of the line IF GET IN ITEM 'ACTION [BREAK/RETURN 
FALSE], which I had to patch to IF ALL [OBJECT? ITEM IN ITEM 'ACTION] 
[BREAK/RETURN FALSE] to make it work through such panes.


Well, I'm really uncertain whether it is a good idea to build panes 
that way and if I have to think of WAKE-EVENT as being buggy, or 
if by design pane blocks really should consist of nothing but faces 
and the bug is me ignoring that.

So, what do you think?

I should have mentioned that I do that to - in the above example 
- refer to the face B by F/PANE/B without having to extend F with 
an explicit 

'reference' to B as in F: MAKE FACE COMPOSE [A: (A) B: (B) C: (C) 
PANE: (REDUCE [A B C])].

Christian, I don't think there are any official docs on the contents 
of pane, but I would avoid this approach. Most code would be expecting 
only faces, eg. code that shuffles faces in order to do depth arrangement 
is probably not expecting words in there too (and, if it did expect 
them, should it assume the words are associated with the faces ?)

there are two problems: some mezzanine code doesn't work with that 
(but this could be fixed), and view actually tries to lookup the 
words.

that is, if your pane is [b], and b references a face, view will 
look it up and use it as if the face object was there instead of 
the word. because of this, your faces will be in the pane TWICE as 
per the example above.

IIRC Cyphre used this approach (using words or lit-words) in SWIS. 
It does make lookups quite simple, but then again it is not too hard 
to maintain a separate index block if needed. Keepning the workload 
down for the rendering of faces is probably a good reason to avoid 
the 'word approach.

Strictly I would call wake-event buggy. But then popup-faces are 
usually not that complex. So its a 80/20, the complex faces are easier 
with words, the simple popups a bit  restricted.

So i favor christians patch.

Gabriele, thanks for the "being in the pane TWICE" explanation: you 
pointed me to a mysterious "face in more than one pane" error message 
I wasn't able to track down to it's origin. Should've read "face 
more than once in pane", though ;-)  Then again, it seems to work 
fine if the word-lookup doesn't evaluate to a face (even non-face 
objects seem to be allowed).


Did you had some special mezzanines in mind which may stumble over 
this? WAKE-EVENT currently is the first and only one I know of for 
now. Of course the number of idioms like FOREACH FACE PANE [FACE/...] 
is legion, so this really may turn out to be problematic.

Allen, yes, I too expected the extra type cast required to eventually 
slow down the view engine. As always, it seems to be the old choice 
between being fast or elegant. But please don't cite me as saying 
that fast code couldn't be elegant ;-)

It's just that the approach seems to fit into the 'code is data and 
data is code' idea quite nice.

christian: i remeber seeing the "bug" in the event func that handles 
keys, too.

Fine, thank you, I'll have a look at that.

(that is, i once had a panel with buttons that had a key defined; 
the keys worked in one case but not in another. basically, in one 
case i was using a style that used words instead of faces in the 
pane - so it was easier to probe it for testing - and the function 
find-key-face didn't recurse into that pane)

so there's a possibility that this is going to happen somewhere else 
too... everyone is just expecting faces there, if pane is a block.

Yes, you name the problem. I'm very likely will choose something 
like Allen suggested or store the references in the face's user-data. 
They're fixed number, so that wouldn't be much work, it just makes 
code somewhat lengthy in comparison. Thanks again!