AltME groups: search

by forcing it to front, do you mean modal or just moving any window 
to front? (The kit has a simple function for the last bit)

What I want to do is keep a separate menu window open so that no 
matter what other windows are open, the menu window stays on top.

I use the Windows API to do it Graham, but I don't have a cross-platform 
solution.

Inside a view window, you can remove the face from the pane and append 
it again, so it's a the top of the z-order. I can't remember trying 
that with screen-face though.

Thanks I'll give it a go.

I want to make a program that zooms in on a picture while I hold 
down the left mouse button and that zooms out when I hold down the 
right mouse button. Any ideas?

Could I flick over to event detection every tenth of a second somehow?

Here's a prototype

This is the first step to creating a zooming user interface

In easy-vid, Carl creates layouts of a fixed size, and fits all his 
text accordingly.  Hypernotes creates layouts that are variable in 
height.  How is this done?

Maybe it's just a rebgui issue ...

Yes, it seems to be a result of using rebgui's display/parent ...

Does anyone know if IMAGE-FILTER BILINEAR is working in Draw? I see 
no differences with NEAREST mode (which looks horrible when scaling 
down a big image, even with preserved aspect ratio).

If BILINEAR filter is not working or not implemented (while being 
documented), that would be really a pity to have to code my own bilinear 
filter in REBOL which would be probably too slow to use, or install 
a 10MB library like ImageMagic...

... well, just kidding ... I thought it is a one-time job ....

Doc, I might have a resizer to make thumbs...

Ah nice! I started looking at http://en.wikipedia.org/wiki/Lanczos_resampling
to see if a REBOL implementation would be fast enough.

Just a test:

set 'resize func [img /local sz c1 c3 i2] [
	if file? img [img: load-image img]

	scale: img/size/x / 160
	sz: as-pair 160 round img/size/y / scale
	c1: 1x0 * sz
	c3: 0x1 * sz


 i2: to-image layout [origin 0 box sz effect [draw [image img 0x0 
 c1 sz c3]]]
	save/png %img.png i2
]

Call RESIZE with a loaded image. It'll save the img.png file, that'll 
have x-size of 160. It looks ok here.

Looks like NConvert is a good solution for now. It's simple enough, 
supports the right filters and is multiplatform.

view layout [text-list "this" "is" "a" "text" "list"]
myFile.txt contains "this" "is" "a" "text" "list"
how can I:
view layout [text-list read %myFile.txt]
? 
tia

everything inside the layout [  ]
is not rebol code .. it's a dialect

I think I'll drop View support in Cheyenne completely in the next 
release and search for a suitable third party graphic library to 
add.

If View sucks, well then. But it is a good measure of how it is "usable" 
in real-life ...

at this rate, we could have a dozen extensions by spring.

Not available yet. Not sure they will be, but maybe. Robert is working 
on an SQLite extension and a Windows COM interface.

there is a text to speach extension that has been released on the 
extensions group.

I have done three  "experimental" extensions : a text to speech, 
a matlab engine extension, a simple windows api with some useful 
calls : http://www.colineau.fr/rebol/R3_extensions.html

Cool Jocko. I have an old send-keys dialect as well. I think I did 
a dialect experiment over MCI command strings, but I'm not sure if 
I posted it anywhere.

Max, thanks for the additional info. Actually, NConvert is great 
but only as a command-line tool, it's not available in library form, 
so I'll probably end up wrapping Image Magick.

Other possibilty would be to use my R2 JIT compiler and program the 
filter as JIT function. Could be a good test example but not sooner 
until I get it to 'alpha stage' ;-)

If Carl have time for including/testing the change then why not. 
I can add the low-level code in a hour or so. But the dialect parser 
change needs to be tested after Carl compile the new r2 exe.

Looks like a job for Pekr! ;-)

It would be really helpful, firing a 10MB package just to get decent 
thumbnails is hurting my programmer's feelings. Making thumbnails 
is one of the most common task today in web sites for a graphic library.

If yes, then you could make a thumbnail algorithm in plain C and 
build your own dll. Calculating each pixel in the thumbnail as a 
mean value of a number of pixels in the original image should give 
a nice result, I think.

I thought about it but don't have enough free time to implement it 
myself. Btw passing image! datatype through a routine! is quite tricky 
IIRC?

with proper thumbnailing in r2, you are good on the way to implement 
a photo album browser. as it is now, that's not possible.

Oh, I forgot that the server it's running on has a mono-core Atom 
as CPU! Speed should be ok starting from a mid-level CPU.

I haven't got experience with routine! calls, so I can't say. A way 
to get the data to the C code is to save it on disk as BMP from REBOL 
first. If you need really high speed, this might not do it for you 
though.

the issue being that image magic does things incredibly fast.  its 
a library with its origins in very high-end visual effects, and is 
used massively by that industry.

but for stuff like web sites... an encaped and purposed-build view 
could be viable, if a few filters added a bit more quality/options 
to their mantle.

and a few other image formats too.  (image magic loads/saves more 
than 100)

We could certainly use a save/jpg option.  That's gotta be a longstanding 
request by many.

Rebolek, like many other options, things like save/jpg may not need 
to be included in the default slim installation of REBOL, but I'm 
sure there are many users who would love to have the option of downloading 
a 100k+ library, function, plugin, etc. to easily enable this functionality. 
 I don't care if I have to download and do some code, that's trivial 
- just having the option available would be phenomenal.

Here's a Gmail notifier app for Firefox, so it must be doable.

libgmail is a Python binding to gmail

http://libgmail.sourceforge.net/

can use a ws socket or whatever, and skip opening port 993 on the 
client as well.

Nick, then you use things like ImageMagick, there's a script to support 
it on rebol.org and I have an improved version somewhere on my HDD,if 
you're interested.

Nevermind


The /async was removed a while ago. If you want to use async, you'll 
have to use Gabriele and others' async protocols

when using the REQUEST-FILE function anyone know how to prevent rebol 
from adding its own filters?


I'm specifying one, and it adds REBOL, *.*, and images... but its 
a stupid setup since I can't manage JPG or GIF images in REBOL.

maybe we should make a wish for it in the next R2 release?

Is there a way to retain highlighting?

In standard VID, it's quite a pain to do anything before the unfocus 
action. You have to manipulate the field and area styles to allow 
an action before that.

I was introducing someone to REBOL, and he made a button that modifies 
the highlighted text.   It works fine with the intialized text, but 
if you type more in the 'area and then press the button, the highlight 
variables are set to none, and I can't figure out why there is a 
difference

return-highlight: func [fac /a b la lb ans] [
	la: length? a: system/view/highlight-start
	lb: length? b: system/view/highlight-end
	either (la > lb)	[
		ans: replace a b ""				
	] [
		ans: replace b a ""
	]	
	return ans
]
view layout [
	size 600x460
	across
	choice "<w pos>" "N" "ADJ" "V" "PRO" "PREP" [
		t: return-highlight textfield
		before: rejoin [{<w pos="} value {">}]
		after: {</w>}
		textfield/text: rejoin [ before t after ]
		show textfield
	]
	
	below
	textfield: area 575x360 "try me out"
	btn "display selected text" [ 
		alert return-highlight textfield
	]
]

in the choice, you are copying a new string into the textfield. that 
destroys the relation to highlight-start and highlight-end

sorry, but you are giving me a lot of ideas for the VID Extension 
Kit :-)

That's good! :)  Things need more extension.   I just hope that there 
is a easy enough solution so I don't scare my friend away from REBOL

I don't have a fix for now, but I'll keep this in mind.

yes, I did. there is clearly a pattern there.

local-request-file is only available for Windows and Mac ... and 
the Mac version supports a subset of the functionality available 
on Windows (e.g. no multi-item selection). Two simple examples of 
usuage:

	open-file: make function! [
		/dir path [file!] "Default file name"
	][
		all [ 

   local-request-file path: reduce ["Open" "" clean-path %. either dir 
   [compose [(path)]] [copy []][][] false false]
			join third path first fourth path
		]
	]

	save-file: make function! [
		/dir path [file!] "Default file name"
	][
		all [ 

   local-request-file path: reduce ["Save" "" clean-path %. either dir 
   [compose [(path)]] [copy []][][] false true]
			join third path first fourth path
		]
	]

ah, ok. I don't use 2.7.7 as I have a big project that relies on 
2.7.6 and don't want to mess it up.

Good idea, I'll improve it a bit and post it.

Posted a response.

VID was a revolution at the time of its invention .. but we hope 
that it will be soon superceded by R3 GUI  and we won't have to worry 
anymore :)

That could indicate a deficiency in the method of dialecting visual 
interfaces .. it's just not flexible enough

No, the dialect is simply a tool for building a face tree and it 
can be as complex as we want. Same in the R3 GUI.


How that face tree is otherwise managed during runtime (resizing, 
events, etc.) is up to other functions that exist elsewhere in VID, 
long after the role of the dialect is gone. What the VID Extension 
Kit does is add keywords for resizing and a few other elements, so 
the face tree holds a bit more information.


The resizing system is then used later to perform adjustments to 
the face tree, when you resize the window. That's just one example 
of doing only minor modifications to the dialect itself.

It's all the "meat" that comes after using the dialect to generate 
the face tree. There just isn't enough functions to manipulate the 
face tree. VID is almost a misnomer in this sense, because the dialect 
only performs the very first part of controlling the UI. The rest 
is up to the meat.

It's been many years since I've used an IDE, but I recall selecting 
widgets and placing them on a screen, setting the Z order, and various 
properties for certain events.  Isn't VID just a RAD tool for doing 
this in a dialect ...

yes, and also for doing layouts programmatically, which you can't 
with a point'n'click IDE.

it's a very nice feature for doing certain lists and face-constructs 
(part of the VID Extension Kit)

Presumably in a completed GUI we wouldn't need to generate anything 
on the fly

that would be a complete nightmare to do

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.

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

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

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.

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

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

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

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

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

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?

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

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.

hide is discarded,  because after having done the action, view do 
a show on the face, uhuhuhu.
try this instead.
>>view layout [ mbutton: button "hello" [face/size: 0x0] ]


but you have to remember the size indeed, for further showings of 
the button.

Steeve is not quite correct to say that "view do a show on the face". 
It is VID which does the SHOW, which you can see here.
>> print mold get in svv/vid-styles/button/feel 'engage
RebGUI probably does not use this code.

a way around it, would be to do a "soft show": all [face/show? show 
face]. this can be installed in feel/hot in the vid-feel.r file, 
if you have access to the VID sources.


also using size 0 would not work in the VID Extension Kit when resizing.

Is there a way to get anti-aliased fonts in an area?

It's unrealistic to expect people to do without alt-keys. They're 
used in practically all programs as hotkey components. With respect, 
there should be a way to do this.

Rebol opens a system port, that is to say a port with scheme 'system, 
but when I look in system/schemes there is no system scheme.

View never run on more than a few IIRC - Windows, Linux, initally 
maybe BSD, Amiga ...

Yes, for apps where OS/platform consistency is more importend than 
cross platform compatibility, there is a need for things like thing.