World: r3wp

This is not obvious with VID, because you might build such a layout 
in a special setup, but in the VID Extension Kit, you have face constructs. 
A face construct is simply a style that accepts a particular dialect 
as input. The dialect is parsed into VID which then in turn generates 
an internal face tree. This means you can build styles that do something 
like:

view layout [
	paper [
		size a4
		dpi 300
		at 20x20 image bay.jpg
	]
]


The point is that every time you feed the paper new data, using SET-FACE, 
it's re-rendered from scratch using VID.


You can also build very complicated list views that dramatically 
change appearance and number of faces, every time you feed it new 
data.

The issue is that VID makes many things simple and so is very enabling 
in that respect.  But difficult things are close to impossible for 
seasoned users ...

Even now I see that having a true rich text we can type with is not 
possible in R3 gui

That's incorrect. Who's spreading this information?

I think noone is. It is just a guess, based upon a fact, that none 
such usable rich-text editor appeared yet :-)

I'm getting tired of hearing that if something is currently not there 
in the R3 GUI, it's completely impossible to do. Sorry.

I don't want to give up dynamic GUIs, and I think we have a perception 
that everything should be as easy as VID, or at least not too much 
harder. We are missing some key ingredients, which makes things much 
harder, but if you ever tried to develop a custom Windows control 
in the early 90s, you might not say REBOL makes it too hard. Then 
again, you might. :-) Entire companies were built around, and devoted 
to, providing small sets of custom controls, sometimes just one. 
TrueGrid comes to mind.


Great things have been done, even without docs or all the right pieces 
to make it work well. If R3 can provide the necessary hooks, events, 
and docs, I think we can do the rest. Honestly, at this point, I 
would be happy to have RT *just* provide the core pieces. If Henrik, 
Gab, Ashley, Cyphre, and a few others can agree on what to tell Carl 
they need, all Carl has to do is be willing to give their work an 
official blessing.

I fully agree with Greg here. Especially on the first part - for 
the Visual Objects we bought expensive GridPro product :-) I think 
that it would not take Carl more than 1-2 hours to write down his 
ideas on guides, resizing, layers, etc., or to hold 1-2 hours discussion 
with the team ... why not to coordinate?

If I want to keep a View window in front of all other windows, what 
is the best way to do this?

search this thread for when I asked the same question?

I did, so no answer, eh?

well, I found this post from Dec  from Luis http://pastebin.ca/1718241

but I guess it should have been posted to stackoverflow instread

activate-on-show is mentioned in http://www.rebol.com/docs/view-face-funcs.html#section-1
 now I am remembering some old hack I did where I had two windows 
that played hide-and-seek...but right now the app is hiding...

user32: context [
    dll: load/library %user32.dll

    HWND_BOTTOM:    1
    HWND_TOPMOST:   -1
    HWND_NOTOPMOST: -2
    HWND_TOP:        0
   
    SWP_SHOWWINDOW: to integer! #{0040} ;&H40
    SWP_NOSIZE:     to integer! #{0001} ;&H1
    SWP_NOMOVE:     to integer! #{0002} ;&H2
   

    GetActiveWindow: make routine! [return: [integer!]] dll "GetActiveWindow"
    SetWindowPos:    make routine! [
        hWnd [integer!]
        hWndInsertAfter [integer!]
        X [integer!]
        Y [integer!]
        cx [integer!]
        cy [integer!]
        uFlags [integer!]
        return: [integer!]
    ] dll "SetWindowPos"
   
    set 'arrange-window func [
        "Arrange window z-order."
        window [object!]
        mode [word!] "One of BOTTOM, NORMAL, TOP or TOP-MOST"
    /local
        hWnd
    ][
        window/changes: 'activate
        show window
        hWnd: GetActiveWindow

        SetWindowPos hWnd do select [bottom HWND_BOTTOM top HWND_TOP top-most 
        HWND_TOPMOST normal HWND_NOTOPMOST] mode

            0 0 0 0 to integer! to-hex SWP_SHOWWINDOW or SWP_NOSIZE or SWP_NOMOVE
       
    ]
    	SetWindowText: make routine! [
		handle			[integer!]
		Title			[string!]
		return:			[integer!]
	] dll "SetWindowTextA"
	
	set 'WindowTitle func [
		Title [string!] 
	] [
		SetWindowText get-modes system/ports/system 'window Title
	]	
]

I hope you meant on windows ....

...yeah...thanks!

WIP on a tiff viewer for r2 http://www.digicamsoft.com/cgi-bin/rebelBB.cgi?thread=%3C19Feb2010232555055824100%3E

use Show popup.

show-popup.... sorry.

if you don't do a call to do-events, it won't be modal (blocking 
events to the main window)

if you feel like it, you can just look at the show-popup and hide-popup 
 mezz source code and improve it to let it do what you need.

the only issue here is that if you try to do use a title'less window, 
it won't obay the "stay in front" property... strange.

the only thing to know is that the default wake-event is pretty dumb 
in how it manages the exit application condition when a windows is 
closed.

so if you do play around or make your own show-popup style commands, 
you will probably have to insert a line or two into the main wake-event 
so it knows not to close the whole event port when you close your 
custom stay-in-front windows.


note that these windows CAN resize... VID 2 just never allowed us 
to control it in the popup code.

that creates a modal window

no.

I have to fix view everytime I use my own requestors... its pretty 
quickly designed code which was patched by Gabriele in later VID, 
but even those changes, break up pretty quickly.

for a window to be modal, a new call to wait must be done at some 
point.

part of the modality is managed in wake-event IIRC.

but for a fact, just looking at the wake-event function for view, 
show-popup and hide-popup  you have ALL of what you need to make 
View manage windows the way you want it.


(I've had to play in there countless number of times... GLayout completely 
removes show-popup, for example.  and adds a /modal refinement to 
its 'view command instead)

When a mouse button is held down and the mouse is moved it triggers 
"over" events, during which a right mouse button event is ignored. 
In windows, either mouse button being pressed will cause the system 
to stop triggering "over" events. Does anyone know how I could get 
this kind of behaviour?

Sorry, that should be "when the left mouse button is held down"

the over are sent to allow you to do drag events.

Yes, I know, but I wish to receive a right mouse button down while 
receiving left mouse over events.

I have to go to work.

How to determine if a font is installed?

This is the code I use for RebGUI:

get-fonts: make function! [
	"Obtain list of fonts on supported platforms."
	/cache file [file!] "Obtain fonts from file"
	/local s
] [
	all [cache exists? file] [insert clear fonts unique load file]
	if empty? fonts [
		either OS = 'Win [

   call/output {reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows 
   NT\CurrentVersion\Fonts"} s: copy ""
			s: skip parse/all s "^-^/" 4
			request-progress/title (length? s) / 3 [
				foreach [fn reg style] s [
					fn: trim first parse/all fn "("
					all [
						not find fonts fn

      not find ["Estrangelo Edessa" "Gautami" "Latha" "Mangal" "Mv Boli" 
      "Raavi" "Shruti" "Tunga"] fn
						not find fn " Bold"
						not find fn " Italic"
						not find fn " Black"
						not find fn "WST_"
						insert tail fonts fn
					]
					wait .01
					step
				]
			] "Loading fonts ..."
		] [
			call/output "fc-list" s: copy ""
			s: parse/all s ":^/"
			request-progress/title (length? s) / 2 [
				foreach [fn style] s [
					all [
						not find fonts fn

      (size-text make widgets/gradface [text: "A" font: make font [name: 
      fn size: 10]]) <>

      size-text make widgets/gradface [text: "A" font: make font [name: 
      fn size: 12 style: 'bold]]
						insert tail fonts fn
					]
					wait .01
					step
				]
			] "Loading fonts ..."
		]
	]
	sort fonts
]

thanks ... I knew that you had done something but a google search 
failed to find anything

MESSAGE TO ALL  :-)


I've finally found the way to drastically improve the overzealous 
mouse event handling within the lowest level of view directly without 
causing any noticeable side-effects in the normal face event handling.

its a small patch in view's wake-event function.


the only requirement is that you have at least one face (usually 
the window, if you can) which has a rate set to the response you 
need...  usually around 15 -20 is enough.


this makes face scrolling based on mouse mouse VERY smooth as there 
is no more lag ... which occurs because we can receive 2 to 3 times 
more events than view/AGG can refresh itself.

if you need this, please speak up, I'll gladly offer the recipe.

Maxim, why you aren't using the event compression technique from 
Gariele+Romano?

cause I don't know about it  :-)


and any I've tried before (which might include this one, I don't 
recall) created problems which forced me to adapt my code.

using the rate, I can with almost perfect precision measure that 
there will never be more mouse events than the rate which is set.

check this one: http://www.rebol.org/view-script.r?script=eat.rnot 
sure if the script is up-to-date but the technique described in it 
works pretty well.

and because the rate IS NOT triggered when REBOL is busy, it will 
actually send Less events on its own, making the trick scalable in 
real-time.

I will thanks.

tested...  in 2.7.6, at least, the example windows break up, the 
moment we touch some of the sliders .  ' :-/  


we might need to update the eat-event example for later view releases.

will try something...

no success... still causes errors.

Max, if the patch is small, can you post it for review?

Anyone know the reasons http://synapse-ehr.com/forums/showthread.php?31-Vid&p=237&viewfull=1#post237