AltME groups: search

There is a difference between loading image using 'load function 
and loading using 'load-image function (which is used by VID). The 
second one stares data in cache.

It may not seem obvious, but 

	view layout [image %file.png]

does make use of LOAD-IMAGE, as Oldes pointed out.
Here is where the IMAGE style does it:

	print mold get in svv/vid-styles/image/multi 'file

Doc wrote async-call which would also work .. except it locks up 
VID when I recently tested it.

Not for me .. I get vid extension kit!

I guess additional refinements to a function as fundamental as INSERT 
are a no-go for performance reasons. Probably ALTER/INSERT or ALTER/ONCE 
though:

	>> alter/once [] flag
	== [flag]
	>> alter/once [flag] flag
	== [flag]


See the dance REBOL/View's FLAG-FACE is doing to achieve something 
like that (and a little bit more):

	flag-face: func [
	    "Sets a flag in a VID face."
	    face [object!]
	    'flag
	][
	    if none? face/flags [face/flags: copy [flags]]

     if not find face/flags 'flags [face/flags: copy face/flags insert 
     face/flags 'flags]
	    append face/flags flag
	]

Graham, here's the issue: I have some vid objects such as ua-fname: 
field. They follow a pattern in that the "ua" stands for "User Add" 
and the rest corresponds to the actual field name in the DB. The 
function I am writing is created in a way to be very generic and 
knows how to handle an insert into the DB based on a few parameters. 
What I am looking for is a way to "create" a name by joining "ua-" 
and field name which refers to the actual vid gadget.

Is that not used somewhere in VID ?

Not that I've noticed, but I seem to recall that VID flags is what 
ALTER was originally for.

e.g. for me, RebGUI is a dead end. I talked to Bobik, and he is back 
to VID for simple stuff. There were many changes lately, and some 
things got broken, and it does not seem to be supported anymore. 
As for GUI, I believe that in 2-3 months, you will be able to talk 
otherwise, as Robert wants to move his tools to R3 definitely ...

see the VID-CONTEXT function here: http://www.colellachiara.com/soft/libs/utility.r

but i found it very useful with VID

layout vid-context [....]

vid-context/to

yep, vid-context/to [...] 'word

I have a screen ( VID) and a function that loads values into that 
screen.  I was hoping to reuse that screen elsewhere by enclosing 
into an anonymous context, and use the function that loads the data 
with the same.

Graham, use the /to refinement of my VID-CONTEXT and pass the object 
to the function

c: does [	f/text: copy "hello" show f ]

view layout [
	f: field
	button "test - c" [	c ]
	button "Clear" [ f/text: copy "" show f ]

	button "New" [
		context [
			f: g: none
			view/new center-face layout vid-context/to [
				f: field
				button "test" [ c ]
				button "Clear" [ f/text: copy "" show f ]
			] 'c
		]
	]
]

Gabriele, this doesn't work for me ...

Graham, you have misused the /TO refinement of VID-CONTEXT.

The function help states:  /to word [word!] "Set this word to the 
context created"
That's "set to", not "bind to", the context created.

So you've not bound C's body block as you intended. Instead, C loses 
its initial function value when it is set to the new context created 
by VID-CONTEXT.

Furthermore your context (created by CONTEXT above) ought to be no 
longer necessary since using VID-CONTEXT.

hello: func [word][do bind [f/text: copy "hello" show f] word]

open-window: does [
	view/new center-face layout vid-context [
		f: field

  button "Hello" [hello 'f] ;  Pass to HELLO any one of the words in 
  this context (here 'f).
		button "Clear" [clear-face f]
	]
]

open-window
do-events

What about Gabriele's vid-context ?

window-functions: [
	hello: does [f/text: copy "hello" show f]
]

open-window: has [ctx] [
	view/new center-face layout bind vid-context/to [
		f: field
		button "Hello" [hello]
		button "Clear" [clear-face f]
		button "New window" [open-window]
	] 'ctx context bind window-functions ctx
]

open-window
do-events

Gabriele's vid-context is a pretty nice function.

hello: does [f/text: copy "hello" show f]

bind-funcs: func [word] [

 foreach window-function [hello][bind second get window-function word]
]

open-window: does [
	view/new center-face layout vid-context [
		f: field

  button "Hello" [bind-funcs 'f hello] ;  Pass to BIND-FUNCS any one 
  of the words in this context (here 'f).
		button "Clear" [clear-face f]
	]
]

open-window
open-window
do-events

hello: func [ctx] [do bind [f/text: copy "hello" show f] ctx]

open-window: does [
	view/new center-face layout vid-context [
		f: field

  button "Hello" [hello self] ;  Pass to HELLO this context (created 
  by VID-CONTEXT).
		button "Clear" [clear-face f]
	]
]

open-window
open-window
do-events

hello: does [f/text: copy "hello" show f]

bind-funcs: func [ctx] [

 foreach window-function [hello][bind second get window-function ctx]
]

open-window: does [
	view/new center-face layout vid-context [
		f: field

  button "Hello" [bind-funcs self hello] ;  Pass to HELLO this context 
  (created by VID-CONTEXT).
		button "Clear" [clear-face f]
	]
]

open-window
open-window
do-events

You can see here the block: function

print mold get in svv/vid-styles/button 'multi
...
block: func [face blk][
        if pick blk 1 [
            face/action: func [face value] pick blk 1

            if pick blk 2 [face/alt-action: func [face value] pick blk 2]
        ]
    ]


It has all it needs to determine the context returned by VID-CONTEXT.

From the FACE argument (eg. the newly created BUTTON face), you can 
climb up to the window face, then search through its subfaces for 
one with a word VAR facet. That word should have been already bound 
by VID-CONTEXT, so that means we can pre-bind the action block to 
the context (just before the action function is created from it).

svv/vid-styles/button/multi/block: func [face blk][ ; <- This only 
does BUTTON for now.
	if pick blk 1 [
		;face/action: func [face value] pick blk 1

  face/action: func [face value /local window word] compose/only [

   window: face/parent-face ; Find the window face <-- (simplistic for 
   now)

   word: window/pane/1/var ; Find a word which references a field in 
   the window. <-- (simplistic for now)
			print "Remake action function."

   face/action: func [face value] probe append append copy [bind-funcs] 
   to-lit-word word (pick blk 1)
			do-face face value
		]

  if pick blk 2 [face/alt-action: func [face value] pick blk 2] ; <- 
  Also need to remake alt-action similarly to action, above.
	]
]
bind-funcs: func [word] [

 foreach window-function [hello][bind second get window-function word]
]

hello: does [f/text: copy "hello" show f]

open-window: does [
	view/new center-face layout ctx: vid-context [
		f: field
		button "Hello" [hello]
		button "Clear" [clear-face f]
	]
]

open-window
open-window
do-events

svv/vid-styles/button/multi/block: func [face blk][ ; <- This only 
does BUTTON for now.
	if pick blk 1 [
		;face/action: func [face value] pick blk 1

  face/action: func [face value /local window word] compose/only [

   window: face/parent-face ; Find the window face <-- (simplistic for 
   now)

   word: window/pane/1/var ; Find a word which references a field in 
   the window. <-- (simplistic for now)
			print "Remake action function."

   face/action: func [face value] probe append append copy [bind-funcs] 
   to-lit-word word (pick blk 1)
			do-face face value
		]

  if pick blk 2 [face/alt-action: func [face value] pick blk 2] ; <- 
  Also need to remake alt-action similarly to action, above.
	]
]
bind-funcs: func [word] [

 foreach window-function [hello][bind second get window-function word]
]

hello: does [f/text: copy "hello" show f]

open-window: has [window ctx] [
	window: view/new center-face layout vid-context/to [
		f: field
		button "Hello" [hello]
		button "Clear" [clear-face f]
		button "Clear window2's field" [clear-face window2/user-data/f]
	] 'ctx
	window/user-data: ctx
	window
]

window1: open-window
window2: open-window
do-events

USER-DATA in the window faces seems unlikely to be used to me. You 
could also probably use DATA without problems as well. It depends 
on whether any other VID extensions are being used in your system, 
which could theoretically use that facet for something. Of course 
you can associate the window with it's vid-context by other means 
which doesn't touch any of the window facets at all...

Graham: when you use vid-context/to, the word you pass in is set 
to an object. the object contains all the set-words you used in the 
vid block. example:

>> lay: layout vid-context/to [f: field g: button] 'ctx
>> ? ctx
CTX is an object of value: 

   f               object!   [type offset size span pane text color 
   image effec... 

   g               object!   [type offset size span pane text color 
   image effec...

what's 'vid-context/to'?

I get an error?

there were somethings I could not do in rebgui so I would switch 
to using ViD in the same application

 ... there shouldn't be any. Both VID are RebGUI are just "face factories" 
 ... feed them a spec and they produce a face object. All other functionality 
 is neither VID nor RebGUI specific. I get a lot of emails asking 
 "how do I do x in RebGUI", but 99% of them are really "how do I do 
 x in REBOL", or, "how do I use the SDK to do x" type questions.

I use VID to do a print preview ... using a draw dialect

 ...RebGUI's use of the effect facet (and hence draw) is no different 
 to VID's. Also note that 'draw is available as a native from the 
 console (i.e. you don't event need VID or RebGUI to use it).

Just something like the VID toggle is fine for me.

My main screen was ViD based as it used a toggle widget .. and then 
the rest was rebgui

And when I tried to port it to the latest build .. then I discovered 
vid/rebgui were no longer bed mates

Hi Ashley, i would like ask you, are you thinking about auto-scroll 
in widget AREA, because of  i can not select text bigger than area 
size.  Cool example in VID has Didier Cadieu, see http://www.rebol.org/view-script.r?script=area-scroll-style.r&sid=ptn126rv

Does splash still work?  I get an error when I supply a spec block
Also, is there any alternatives to the vid 'flash ?

perhaps because rebgui is no longer compatible with Vid ...

I know - VID method engage has EVENT, where can i get event/offset...... 
so how to get such value in rebgui to avoid do new widget :-) ?

I never used RebGui, but if you can get the object constructed like 
with VID:
b: box red 10x10 on-click [print face/feel/pos]

then you can patch b with something like:

b/feel: make b/feel [
	pos: 0x0 
	engage: func [f a e] compose [
		pos: e/offset 
		(get in b/feel 'engage) f a e
	]
]


That overloads the engage function wihout losing her actual content.

In VID you specify the feel directly, in RebGUI you let the widget 
worry about these low-level implementation details. None of the default 
widgets need to pass mouse offsets back to the application, so if 
you need to do this then creating a new widget is the way to go. 
Having said that, I could always add another action handler (on-anything 
face action event) which would fire instead of the above case statement 
(i.e. handle the event as in VID or let RebGUI delegate it to the 
appropriate handler).

ok but with new vid  in R3  what will be the future of rebgui ? ashley 
do you plan to keep rebgui as an enhancement and laboratory ground 
for new kind of widgets design in the new VID ? Or does the new VID 
will kill  rebgui ? What will be the link betwin R3/VID and rebgui 
do you think some of the fun widgets from rebgui will be adapted 
by default in R3/VID ?


If you remmeber i asked this like 1 year ago to carl and didn't get 
any reply...

re: RebGUI and R3/VID. I'll probably put something up on my website 
on this topic as I get asked this quite a lot. Basic thinking at 
this stage is:

	I need to create SDK GUI apps for Windows and OSX
	R2/RebGUI is the only practical alternative at present for *me*
	I'd love to use R3/VID to create SDK GUI apps today
	This probably won't be possible for quite some time

 If and when this *is* possible I'll port all my apps over to R3/VID

 To do this I'll either create a compatibility layer that lets RebGUI 
 apps run on R3/VID, or

 Write a conversion script that tries to convert (if possible) RebGUI 
 scripts to R3/VID

 I'd hope R3/VID is complete enough that it doesn't require any of 
 RebGUI's basic widgets!

Gabriele, could you try the style browser for the vid extension kit, 
please? AFAIR there is little to no DRAW used in it.


do http://97.107.135.89/www.hmkdesign.dk/data/projects/vid-ext-kit/downloads/style-browser.r

vid-ext seems to work fine for me, using rebview 2.7.7 on ubuntu

the vid ext style browser works, that is

Ashley - what is your status re RebGUI and its future? It seems to 
me, that R2 brach is not going to be further developed? And also 
- I noticed you mentioned some flawor of even more simplified RebGUI 
like engine for R3. Is this still a plan, or do you wait for how 
R3 VID emerges?

And of course, VID is still valid as well.

VID is the native REBOL GUI dialect. If you're just getting started, 
and doing basic UIs, it's worth a look.

(I suppose that you are mistaking VID and RebGUI)

Max, fonts should work the same between View, VID and RebGUI. Please 
provide a small snippet of RebGUI code that demonstrates the problem.

No, he solved the problem with Linux by providing an absolute filepath 
to the font.

The problem is trying to use VID's LAYOUT (and maybe also VID's VIEW) 
after initialising RebGUI.

If I remember correctly, RebGUI unsets 'LAYOUT, or redefines it for 
its own use. So it won't work anymore as you expect with VID.

Well, it's not going to be easy to mix them. Ashley made the decision 
early in RebGUI development to specifically unset (the majority of?) 
the built-in VID functions. I think primarily to reclaim memory use, 
but maybe also to avoid mixing code. (I didn't really like this decision, 
myself.)

You could probably modify the RebGUI sources so it doesn't do that, 
or ~maybe~ redefine the VID functions yourself (I think more challenging). 
Every time there is a RebGUI update, you'd have to remodify the RebGUI 
sources, so I wouldn't be inclined to do that myself. It depends 
how badly you want them to coexist.

You can use VID styles with the 'style word:

RebGUI (b117 and later) does *not* redefine layout. It does however 
redefine alert, confirm and many of the request-* functions.

The fact that starting a fresh console session and entering:


 view layout [box black 100x100 effect [draw [pen white text "Hello"]]]


no longer works on the linux and Mac ports of REBOL is I believe 
a REBOL/VIew bug (despite a workaround that may work for VID but 
not RebGUI).

nickA didn't provided a font information in his draw block plus he 
didn't gived a different color... plus R2 VID sux with fonts and 
specially under linux.

That's all VID-specific, NA for RebGUI.

And my answer is it's not a RebGUI problem. Try the following code 
on 2.7.7.3.1 (Windows):

	view center-face make face [effect: [draw [text "xxx"]]]


You should see 3 black x's in the top left corner of a new window. 
Now try this on 2.7.7.2.5 (Mac) ... a blank window appears. I suspect 
the same thing happens on Linux. This is not a dialect problem (VID 
or RebGUI) but an issue with REBOL/View AGG font support on non-windows 
platforms.

Also note that while the following works on Windows:


 view center-face make face compose/deep [effect: [draw [font (make 
 face/font [name: "Verdana" size: 18]) text "xxx"]]]


path-qualifying the font name on Mac (and I suspect Linux) still 
does not work:


 view center-face make face compose/deep [effect: [draw [font (make 
 face/font [name: "/Library/Fonts/Verdana" size: 18]) text "xxx"]]]

in view (not VID) you need to do a show on a face for its parent-face 
to be updated.  but the face must be actually visible IIRC.

I've never experienced PARENT-FACE as reliable, so for the VID Extension 
Kit, I made separate functions to set it properly.

The question is what that would be. But I have noticed way too many 
times that parent-face is NONE for faces that should be set up properly, 
particularly in VID, but apparently also in RebGUI.

I do recall that parent-face doesn't work during INIT in VID.

Is there a way to monitor all events ?  In vid you can do 'insert-event-func 
but in Rebgui we have this system/view/screen-face/feel: none	; kill 
global events system (used by 'insert-event-func)

calling WAIT inside a vid face action is not really supported by 
REBOL. In practice, there are cases where you may need to do this, 
but it is always a bit tricky.

Thanks for the information Gabriele, I've been using this inside 
vid face action to wait for a data from serial port. Until now I 
have not encountered any issue. But maybe I'm just lucky.

here is an example of how we could use the unit system if it where 
implemented.


ANY unit moniker could be used, and in fact the switch tables below, 
could be context-specific and dialect-configured, adding to the DSL 
power of  REBOL... 


ex: dm could be decimeter or deutchmark (the later should be DM anyways, 
no?) , based on context, the convertion units could mean either or... 
with a default convertion table explicitely defined.

a simple func could let us append or change the conversion tables 
used throughout the system.  


Imagine if the VID would use units directly.  you set your locale 
(or get it from OS) and see values as they should be for your locality.


unit-convert: func [
	in "unit value to convert"
	to-moniker "to what unit type to you want to convert to"
][
	; note: incompatible types set 'IN to value none
	in/value: switch to-moniker any [
		switch in/moniker [
			{mm} [
				[
					{m} [in / 1000]
					{dm} [in / 100]
					{cm} [ in / 10]
					{'} [in * 0.0032808399]
					{"} [in  * 0.0393700787]
				]
			]
			{"} [
				[
					{m} [ in * 0.0254]
				]
			]
		]
		; empty result set, switch on nothing
		[]
	]
	in/moniker: to-moniker
]


unit-convert 100mm "m"
== 0.1m

unit-convert 100" "m"
== 2.54m

unit-convert 2mm  {'}
== 0.0787401575'

I started a deep deep thinking process wich is a heavy task for an 
idiot biain of mine concerning the futur of viva-rebol and where 
i want to lead it.


If you have a little interest for what i'm doing actually you know 
that i'm actually working  on 2 projects viva-rebol and rekini. I'm 
interrested in transforming viva-rebol into a real time collaborative 
project. manager/editor something like wave but done in rebol to 
create rebol application.


The idea that comes to my brain is to mix IRC and vivarebol. IRC 
would be the supplier for sharing real time documents content information 
and viva-rebol will be at the same time manager and the renderer 
that will catalise the informations collected by irc.


Why irc?  first because they have lot of control feature wich can 
allow anyone to join and see an onShared-creation docuiment  or script 
and only look at it without active participation. That can allow 
a hierachy system with master, co-writer and only viewer. and the 
allow the master to select who participate or not to the création.


We saw with area-tc that rebol and VID and the dialect concept was 
really feat to handle uncomon text handling  at light speed so the 
appears clear for me that this is the next step to go.


Some people will say to me "but it's more important to have an advanced 
rich text editor tool"  which i answer that boring to do and in the 
result the gain in notority for rebol is close to 0. So instead of 
 clonning MS-Word using VID I prefere move to the next step wich 
I hope will lead us to make people see all the potential of rebol.


It took me looooooooooong time (6 years in fact) to see how to merge 
all the interresting part of rebol to make a big project wich we 
could be all be proud of and show all the interesting part of rebol.


Our comminuty is small and working together to make advance the projects 
is obvious if we want our project to be recognised in some way. If 
we all work on our sides on our own project achieving a high quality 
for those projects is hard.  So externally we only show to the world 
project that looks more like teasers than completed project and that 
not a good thing for rebol promotion. We can say all we want about 
the way rebol is done by Carl but us as community which goal is to 
spread rebol world wide we have a part of reponsability in that too.

all series data was shared... 
but its easy to copy on demand... its impossible to "uncopy"


the reason for the change was essentially that it made VID easier 
to use.

I doubt it ... do you think that module can have easily binary code? 
:-) You can remove VID, but what about View kernel? I doubt it. But 
we still have to see Core and Host isolation interface. Extensions 
are something different. We are still waiting for Host code release 
...

So, I am still curious, how Core and Host parts are being abstracted/separated. 
And even then such separation does not mean, that View can be easily 
extracted outside as a module. Extracting only VID is imo nonsense.

I would modify the VID behaviour instead, to treat definitivly that 
case

it's easy to make a VID front end to pilot a oggvorbis player for 
example it's more difficult to mix VID and opengl.

actually it isn't hard to mix VID and OpenGL  :-)  all we need is 
a way to do a quick memcopy of the OpenGL pixel buffer into an image! 
datatype... that's it.  really simple.


now I dont want to be forced into using View though.  I want to be 
able to use extensions to control the windowing too.  I need to be 
able to use other window managers if I want to integrate into better 
engine which are already ported to all major platforms.  Things like 
open scene graph or other game-oriented 3D engine, DirectX, whatever.

no one said there will be no VID.

OK then ... because VID like methodology of GUI creation is the correct 
answer to go simple GUIs. Remember that JavaFX has stolen some ideas 
from View - just look at the GUI syntax - so close ...

even current VID can't deliver on that since it can't guarantee the 
same fonts on all OSes.

I prefer one well supported engine instead of 10 less supported. 
Everybody is free to do anything. What I don't like is, that sometimes 
new stuff distracts the crowd and splits the effort. In the same 
way I think that VID Ext Kit, in current days, is contraproductive 
product, but this is just my opinion.

Maxim - I might not care. This is just one measure, what client want. 
I provided clients with many solutions, from DOS apps via Windows 
native apps, some web apps, and VID/RebGUI small apps. They don't 
care.

View/VID is not rebol.

If R3 has VID3 working, I'll probably use it for some projects... 
but when GLass will start to work (using OpenGL) then I'll probably 
never need VID anymore.  simply cause it'll do 5000 frames a second 
for my interfaces, including very advanced looks and next gen functionality 
like run-time interface manipulation by end-users.

Graham - how can you think that language itself, without any kind 
of killer app or niche area could be succesfull? If anything, View/VID 
is good attraction for MANY new potential newcomers. They will be 
hardly attracted by REBOL itself, mainly due its syntax difference 
to "more traditional" languages ...

Name me any candidates for a killer app on vid now.

I can do se very easily, but I will revert - name me any candidate, 
which will attract millions, without the View/VID. Cheyenne? CureCode? 
Those are cool in itself, but how they will attract any new ppl to 
REBOL specifically?

and vid ??

I asked you for a candidate vid application ...

I don't understand, what is the fear about - noone is distracting 
Carl from Core work, by View/VID requests. Carl will be back to gui, 
once he feels Core is stable ...

VID is now 8 years old now??

Could Cyphre's vconsole help? He did complete console simulation 
(except multiline capability) in VID ...

Yes ... but we might please some ppl in future, by doing VID-2-*, 
where *=Silverlight, Flash, JS ... the question is, how capable would 
it be, without complete REBOL-in-* implementation (which would be 
slow)

I think I will not take part in this discussion this time. There 
was already something like 80 posts to naming VID/View or REBOL in 
the past, with no particular result. Unless someone shows me that 
we know what the strategic plan is, I regard it being a pointless 
discussion ...

How is 'limit used? I set it once, as like we set spacing in VID 
once, and then I have to reset it? Or does it apply only for one 
following argument? I can imagine using limit with multiple to/thru 
...

The parse enhancements, particularly OF, were prompted by the failure 
of DELECT to simplify the new VID.

Once again - free yourself from REBOL, gee. Who said said EITHER 
should compare anything? Copy breaks normal copy rebol logic. VID 
'at command is completly different in semantic meaning to REBOL 'AT. 
So - how is that that for EITHER we do care about what it means in 
REBOL? The word EXACTLY expresses what you are doing ...

Today I posted more philosophical topic, and Carl noticed it - we 
ares shooting ourselves in the foot. Here's what I posted:
-------------------

There will always be problem with dialects, if they contain the same 
keyword names as REBOL functions. So we have to somehow live with 
that.


So the question is, where to introduce new name and why, just to 
be different, and where to not. E.g. parse 'copy keyword has already 
different semantics to REBOL's one, or VID's 'at has different semantics 
to REBOL's one. Now can users be confused? It depends.


I try to think about each dialect in the context of the dialect itself 
- so the only measure for me actually is, when reading the source 
code (or trying to understand one's), how quickly I am able to understand, 
what is going on?


But then we could as well replace 'stay by 'save-position, 'of by 
'any-of, 'if by 'only-if, etc., which would imediatelly map the meaning 
to what the keywords are really doing. But we are somehow mysteriosly 
looking for one-word-only-mantra naming convention, and I suppose 
it is already our style, and we will not change it :-)


... so, the topic is a little bit more abstract - it is about contexts, 
and user/programmer switching between contexts, and his/her ease 
of understanding of the code.


In above case, all 'if, 'check, 'either are OK, even if their semantics 
is a bit different to their REBOL counterparts.

your rant towards EITHER not fitting anything breaks the initial 
purpse dialecting was brought to REBOL! And the meaning is - the 
same word, might mean different things in various contexts. We don't 
care for VID to use potentially the same keywords to REBOL functions, 
let we do care somehow mysteriously about PARSE to NOT use the same 
keyword naming as REBOL functions. Let's judge EITHER by its name, 
not by its REBOL level meaning.

i ned some help what is the equivalent of init in R3/VID ? and is 
there a draw: embeded to a gob how can i say my custom face inherits 
from box style ?

The R3 equivalent of VID isn't done yet, and some revisions are planned.