World: r3wp

yes

on linux it does nothing, except stopping timers and flash a moment.

so that should be changed to [hide main-window/pane perhaps.

somewhere in the [window: func]

Mmm.  HIDE doesn't work on latest Rebol/View betas, but it minimizes 
a window face on View 1.2.1.3.1

doesn't work

 = doesn't change appearance of the window (don't know about timers 
 yet)

published a fix. can you try it again?

Open still tries to save, obviously, but when I cancel now it does 
not minimize (I see a quick flash of the window though)

:) 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.