AltME groups: search

Rondon: the styles for the Detective were designed and implemented 
by Romano and Chris. The code is under the GPL; i guess you can contact 
them about them. bear in mind they were not intended to be generic 
styles, but were done just for the detective.

hmm, so during the button-press, you simply make sublay [] In such 
case, you get clone of sublay face definition, right? So you also 
need to iterate thru sublay pane elements and recreate them for made 
face?

Ashley - I think it is like I described it now ... Cyphre is making 
new sublay face ... and original sublay can contain xy elements, 
e.g. field with some filled-in info, so he imo iterates thru its 
pane and recreates it ....

Ammon, I was attempting to use your dropdown.r with view version 
1.2.56.3.1 (agg9 version) and notice the dropdown list items don't 
appear in the list.  Are you aware of this change from earlier versions 
of view and if so, did you fix it yet?

Does anyone here use later betas on an ongoing basis

 REBOL/View 1.2.10.3.1 30-May-2003, as it's a good match for the latest 
 [working] SDK  (REBOL/Encap 1.2.0.3.1). It is frustrating how REBOL 
 has become more and more "write once, test everywhere" over time 
 - hopefully /Platform will provide a unified base so we don't have 
 as many of these "which version(s) of View does this work" on type 
 issues in the future.

Of the 25 View facets, I have been able to prove (via simple test 
cases) that 19 are used in some shape or form; which leaves 6 that 
I cannot prove are used:

	type		; view make face [type: 'blah] works just fine
	span
	data
	saved-area
	line-list
	action


For the record, passing an empty  face to 'view changes the following 
facets:

	text            string!   ""
	old-offset      pair!     0x0
	old-size        pair!     100x100
	face-flags      integer!  1


and doing a "view make face [pane: make face []]" will additionally 
set the sub-face's 'parent-face facet.

Oh for some low-level documentation!!! ;)

'line-list is only used on "long 'text" face (more than 200 chars 
IIRC). Be carefull with it.


'span was used in View 1.2.1 to set a pixel ratio (zoom) between 
'offset, 'size and correspondng real screen values. I think recent 
beta/alpha does not care of it.

'saved-area is considered if  value is 'true IIRC.


'action is checked by 'feel function, so can be used if 'feel does 
not care of.

'data depends of  'feel too.


'type could be used. Only 'layout or other VID functions use it AFAIK

After extensive testing, I've come to the following conclusions about 
the View facets I mentioned before:

	type		; required, but not used by View directly
	span		; required, but is depreciated / not used
	data		; used by VID styles
	saved-area	; used by View
	line-list	; used by View
	action		; used by VID feel system


So, if you create a View-only GUI I believe you can safely use / 
redefine the following four facets: type, span, data and action.

Which leads (sort of) to my next question. Does anyone think it is 
worth developing a simple, high-performance, low-memory GUI alternative 
to VID? The aim would be to have it built on View from the ground 
up such that you could (for example) use enface / rebface (or equivalent) 
without needing %view.r (and the over 120 KB of mezz it pulls in). 
If there's sufficient interest I'll document and release the Alpha 
implementation I have.

I've built GUIs from hand and when the whole GUI is built by hand, 
I found it to be considerably faster and much lighter on the memory 
usage.

I think it is a great idea - after all - wasn't VID just something 
to get the ball rolling and show the rest of us how we 'could' do 
things?

I thought Steel was not going to use VID though .. and Glayout was 
just a temporary and unsupported thing

Ashley, it's a good document, separating the View and VID attributes.

Graham: It's *Alpha* so no hard benchmark results yet, but moving 
from VID to View for mdViewer cut the WinXP process size from 15MB 
to 12MB and improved speed threefold ... I'd expect similiar things 
from a View-based GUI.


Anton: "No it doesn't Ashley, read again." - I thought the opening 
paragraph of the referenced document made it pretty clear; "Facets 
are attributes of a face. Facets include the face's location, size, 
color, image, font, style, paragraph format, rendering effects, behavior 
functions, and other details.", but I'll probably use the term attributes 
anyway as facets might be confused with faces.

Louis: Good documentation can make *anything* seem simple! ;)


Robert: Maybe. Main purpose of a View-GUI is for high-performance 
scripts where you really want to know what *every* face is doing.

RebGUI (alpha) and draft documentation available at http://www.dobeash.com/it/rebgui/


Only a few basic widgets defined at this stage, so don't try and 
convert your VID layouts across just yet! ;)


Being an alpha, the design is still settling down so feel free to 
question anything that seems wrong. If there's sufficient traffic, 
feel free to start a RebGUI group.

Or just grab the source (and run %test.r) directly from http://www.dobeash.com/files/RebGUI-010.zip

Ashley, since you have separated the View and VID facets, does this 
mean that RebGUI can work closely with VID, without the two affecting 
each other ? Eg. could faces from a VID LAYOUT be moved into a RebGUI 
DISPLAYed layout, et vice versa ?

actually when I resize a layout by clicking left mous button and 
pointing to one of it's borders I have an ugly thing

event system is stopped when you resize the window: try to do something 
at each clock tick (at 'rate speed,) and you'll see that no event 
is processed while resizing

sorry, even busy loop are stopped. no code execution while resizing: 
when you start resizing with mouse, all executed code stops, when 
you finish resizing, code resumes and an event 'resize in generated. 
So no refresh during window resize or movement (white background 
visible, truncated display, and others glitches), but only after.

Ashley, is the intent that one develop first in VID, and once finished, 
recode in Rebgui?

I looked at the example and the references are hard coded ..

So, I presumed that you prototype first in VID and then optimize 
in rebgui

II think that's from a minimalistic POV.  If you're still learning 
View then perhaps you should use VID to prototype and explore your 
styles and then just move the values that you need into a style definition 
for RebGUI, however, if you are a seasoned expert such would not 
be necisarry...

say you have 20 odd faces, and you insert one in the begining .. 
then that's 20 references have to do a find and replace on ...

If you're talking about styles then the only way I can see that happening 
is if you are building something like a text-list but then you should 
be using itterated faces which elimates the problem.  If your talking 
about referencing the faces from elsewhere in the code then I disagree 
110% with the idea of not using a word to reference the face, but 
then we're just talking about convention too and you're free to reference 
values pretty much however you like. That's the power of REBOL!  
;~>

Oh, and Ashley, good work BTW! ;~>

one of the first widget that I want to work on is a status bar that 
can encap text, progress and the resize logo

good work Ashley!

- changing the "foreach [style facets] spec" loop in display.r to 
something like "parse spec [any [opt [set varname set-word!] set 
style word! opt [set block block! (...)]]" would allow the use of 
"return" in place of "return none" and let users to define var names 
for faces in definition block.

- found the problem with /View 1.2.1 : i did define 'as-pair as func 
[x y][add 1x0 * x 0x1 * y], and it crashes here, but it works with 
as-pair: func [x y][to-pair reduce [to-integer x to-integer y]]

VID is great for prototyping, and for apps where saving a little 
memory and speed aren't critical. So, I think VID is still a valid 
prototyping tool because you don't know what you want to build the 
first time out (in many cases) and it allows you to play around more, 
with less effort. Now, there's no good reason you couldn't use the 
VID dialect, limit yourself to what REBGui can do, and use the VID 
spec to generate REBGui code. Best of both worlds.

RebGUI 0.1.1 released ( http://www.dobeash.com/files/RebGUI-011.zip
) and View facets documentation updated from feedback ( http://www.dobeash.com/it/rebgui/facets/
).

Anton

 1) VID working with RebGUI ... no reason why not (haven't tried it 
 yet though)
	2) display help cleaned up
	3) Minimum window size ... can be set to 0x0 with /limit

 4) Progress bar using effect ... agree. I want to emulate the WinXP 
 progress bar with image / effects

Graham

 1) Intent ... Ammon & Gregg answered this already; bottom line - 
 whatever folks feel more comfortable with

 2) Positional references were only meant to be for sub-faces of a 
 widget ... documentation corrected
	3) display now accepts set-words as per Vincent's code

Vincent

 1) Changed all occurences of as-pair to to-pair so your prob is fixed 
 (and RebGUI can now run from rebface)

 2) Change 'foreach to 'parse ... done (with the benefits you listed)

Shadwolf

 1) "Ashley is one of the few VID artist" ... thanks, but I defer 
 to Chris in all matters graphical! ;)

Gregg
	1) Agreed. (Need I say more? ;) )

Out of interest, I started rebface (REBOL/SDK) and did several recycles 
before looking at its process size under WinXP. Did the same thing 
again but after do'ing %styles.r and %display.r, and repeated the 
procedure for %view.r (the SDK func that pulls in VID). Results were:

	rebface	3,540 KB
	RebGUI	3,628 KB
	VID		5,224 KB


So I can say that (at this early stage) RebGUI seems to use 88 KB 
while VID uses 1,684!

That will shrink your code and user code down a bit.

I'm using the SDK rebview 1.2.10 as my baseline. The only three mezz 
funcs I have had to abandon so far are:


 as-pair		; better off using to-pair reduce [x y] as I'm dealing with 
 integer-based co-ords anyway

 center-face	; was used once in the 'display func and it's inline 
 representation is more efficient

 span?		; used in render-rich-text with a check as per your suggestion 
 (render-rich-text is used from REBOL/VIew more often than not)


It's only the RebGUI code that has to conform to these restrictions; 
user code can use whatever mezz funcs and run under whatever REBOL 
version they want. I used the same design philosophy with RebDB (if 
it runs under SDK/rebbase, it will run anywhere). In the majority 
of cases the extra mezz funcs are more usefull at the user code level 
anyway.

Thanks Anton. That makes sense when I see it. I was thinking it had 
to be a file and not just a path. Cool. That will have me a lot of 
clicks. : ^)

So, I have either not defined the bx1 and bx2 faces correctly as 
panels, or the function is not limiting itself to only affect the 
panel provided as  the parameter to the function

Poking around a bit in the View executable (1.2.10.3.1) I "discovered" 
the following undocumented words (and have assumed they belong to 
the indicated facet based on the position of other known words). 
I've worked out what a few of them do, anyone care to comment on 
the others (or point to documentation if covered elsewhere).

Draw
--------
fill
font

Effect
--------
dither
alphamul
anti-alias
func
merge		; I know this was covered, just can't find where
chisel
	view layout [box 20x40 effect 'chisel box 40x20 effect 'chisel]
round
	view layout [box 20x40 effect 'round box 40x20 effect 'round]

Feel
--------
inactive
active

Options
--------
parent
	view/new a: layout [size 400x400]
	view/new/options layout [size 200x200] compose [parent (a)]
	do-events
min-size
	view/options layout [box blue 400x400] [resize min-size 200x200]
activate-on-show

'activate-on-show : like the name said.

There is different behaviour with it. I notice that on Win2k, the 
window come to front but don't take the window focus. sometimes, 
the window stay behind and just the task button blink (the current 
active window remain active).

But on WinXP, the window become active and take the window focus. 
Very annoying when you are typing something.

I use it to bring a window to top when there is something new (lecture-forum 
script).
I don't w=know how it works on Linux.

merge (with Chris's example) behaves differently under 1.2.10 and 
1.2.48 (later is correct)

fill (DideC's example) dosen't seem to do anything (same result by 
removing the "fill 50x50" bit)

My example give different results :

on 1.2.1, 1.2.8 and 1.2.10, fill is OK, but there is not the red 
line.
on 1.2.48, it's ok

Tried on both 1.2.10 and 1.2.48. Note that the lack of a red line 
on 1.2.10 is due to a known bug with polygon (fixed in 1.2.48).

On 1.2.48 I can't see a difference between:


a) view layout [box 100x100 effect [draw [pen 255.0.0 fill-pen 0.0.255 
polygon 0x0 0x90 90x90 fill 50x50]]]

b) view layout [box 100x100 effect [draw [pen 255.0.0 fill-pen 0.0.255 
polygon 0x0 0x90 90x90]]]

So I'm still not sure what 'fill is supposed to do. ;)

Yes, I'm wrong. 'fill is ignored on 1.2.8 and 1.2.48 :

You're correct -- it is 'clear-fields.  When you set the text value 
for the 'application field, it comes directly from the face/text 
of the last clicked toggle button, ie. it is the same value.  When 
you 'clear-fields the application field, it does 'clear on that value 
clearing the field and the last clicked toggle.  A quick fix would 
be:
    if last-sgrp <> "" [application/text: copy last-sgrp]
or
    if last-sgrp <> "" [change clear application/text last-sgrp]

; the latter retains the same string value for the application field...

Brock, check out the source of CLEAR-FACE, and you will see that 
it tries to do  
	face/access/clear-face*

, therefore you should look at the access object to see what it really 
does:
	layout [text with [?? access]]

There, you will also see RESET-FACE, which would have also solved 
your problem

because it does a COPY as well. I think COPYing to start with as 
Chris showed is a safer way, though.

Chris and Anton, thanks for taking a look and making the above suggestions. 
 It looks like there is a simple solution mentioned by Chris and 
I will study the additional suggestions from Anton.  Thanks again.

Chris, looking at your [change clear application/text last-sgrp] 
suggestion.  I don't see any obvious reason I would want to use this 
method other than it being more REBOLish, and/or avoids falling into 
the trap of missing the 'copy statement.  Can you please suggest 
why?

When you press a tog, this happens:
	last-sgrp: t1/text
Now  t1/text  and  last-sgrp  are pointing to the same string.
When new-ticket is done, this happens:
	application/text: last-sgrp

Now  t1/text, last-sgrp and application/text are all pointing to 
the same string.

Brock: where I am tempted to use 'copy, I'm often try and think of 
any potential benefits of using series modifiers instead.  Depends 
on the situation I suppose...

size of draw-text: you want wrapping? afaik not. there is a complicated 
handmade way, you make a face of that size with 'wrap and use that 
to calculate the lines.

I have a text-list in a layout and I have a simple log-function:
log: func [message [string! block!]][
	append log-list/data rejoin [now/date "/" now/time " " message]
	show log-list
]

If MESSAGE is longer than the width of the text-list MESSAGE isn't 
shown. Why this? The first two parts NOW/DATE and NOW/TIME are shown.

aahhh, no matter how deeply you know something, there is always something 
that gets on your nerve...

changing the button font color seems to be a genuine pain... can 
someone refresh me why its impossible?


this doesn't work... altough I've allocated a stand-alone font and 
have removed all the dynamic code which AFAIK plays around with the 
font or text:



view layout [button "ok" font [color: red] with [feel: make feel 
[redraw: none over: none]]]

yet, this works:


view layout [text "ok" font [color: red] with [feel: make feel [redraw: 
none over: none]]]

you have to set 'colors, not 'color:

view layout [button "ok" font [colors: reduce [red white]] with [feel: 
make feel [redraw: none over: none]]]
for a button with inactive color red and active color white

strange I tried it earlier and it didn't work...

I'm hoping this a false reading, and my machine hasn't been infected/hijacked

I tried to send a rebol archive the other day using my hotmail account 
( testing attachments with my webmail ) and it said it was infected. 
 Scanned it with bitdefender which said it was clean .

Does any one have a HINT on how i can make a dragg & drop Face to 
DROP within the bouderies of an underlaying face.. I.e. Im dragging 
a Face over a field of faces, when I drop it on the face below and 
then the dropped face should FIT itself inside the face below. Is 
there someting default for this in view/vid ? or do i need to calculate 
it myself? .. Its a kind of a Puzzle-piece drop...

I sent you a drag and drop example from Developer (Thanks, Volker) 
as private message.

Ok, so know which face is getting dropped and which face it is being 
dropped on, right?

and append itself to the /pane of the face recieving the drop

What if you gave every peice of the puzzle the proper offset and 
if it gets dropped close enough to the position that it is supposed 
to be at then it snaps into place

So when the peice gets dropped then you find the location that it 
should be at, if it is within a certain distance of where it is supposed 
to be then you set the offset of the puzzle piece to its proper location 
and remove the drag feel.

I use confine and snapping in my drag-feel this script. though it 
isn't very pretty code example. http://www.rebolforces.com/plugin/gridlock.r

It is getting better and better as we improve it for use in Anvil...

Playing with alpha channels requires some skill and experience. ;~>

Can you give us a quick snippet that demonstrates how you attempting 
to create the transparency and how the faces are being moved over 
each other?

AFAIK It's not possible to set the transparency amount (alpha) between 
faces.

Maybe, you can approximate transparency with 'gradmul and 'gradcol 
:

I do a a: make face [ ....... color: something text: '"OK" ] and 
a  b: make face [ .... ]

Face B moves over Face A.. and Face A has the Word '"OK" ... I like 
to see the word "OK" Through Face B while im dragging Face B over 
Face A... Therefor Face B can be transparent in its own color not 
100% transparent...

aaa right.... remove and append ;-) I thought that would do it too.. 
 great thanks !

It is the code in the middle you're looking for...  The Remove and 
Append to the parent-face's pane

That particular How-To is EXTREMELY useful and not known nearly well 
enough...

Rebolingth, I tried on earlier and later beta versions.

and that ne need to be transparent

one way is to break wait is to throw an error, as long as it is not 
catched in between. 

another to use wait with timeout, and "poll" a variable every second 
or so.

'halt may be an option, because you can put code in system/options/prompt, 
and if the console want to draw the next ">>", it restarts the main-loop 
:) but do not know how stable that is.

but do you really need the wait? or could you give the thing you 
wait for a fresh /awake, and return?

what's the facet now for a password field ?  Not value, and not text 
...

how do I display a GIF image with a transparent background. The GIF 
image is White and Blue and the background of the image is BLACK. 
I want to make the BLACK part transparent to its background face 
it is floating on. (The image is dragged and dropped). Is this possible 
??

and want to detect per face.. Do i need to Name the face perhpas?

With insert-event-funcs, face and event/face are the window face 
where the event happens. You have to search yourself what is the 
face under the cursor. Very boring OMO.

I thought the face param was the main face and event face was the 
face getting the actual event, in the case of 'move, etc.

face is always screen-face and face/event is the window.

If have a problem with Caching in rebol..seems everytime i need to 
restart view/console to make sure the PICTURE is reloaded to the 
currect on... im using 'IMAGE %file.png to load it... and a recycle 
does not fix the problem

You can see under "file:", that LOAD-IMAGE is used. Check the source 
for load-image and the second item (a block) is where the images 
are actually cached.

Woudl be OK. It should be acceptable in that it's easy to remember 
and doesn't interrupt the programming flow.

I'm not sure but it isn't just resolution that will do it.  Sometimes 
changing the Appearance and sometimes changing the color depth as 
well as various other display settings will kill all View applications.

Well I do, as such a switch happens when you connect to Remote Desktop, 
and I use that a lot.

Really?  Never had RD kill my View apps before and I have used it 
alot...

In my experience there are a number of applications, games, etc that 
use there own display settings but do not seem to change the actual 
desktop settings and therefore do not affect other running applications 
such as View.  This may or may not be what is actually going on I've 
just come to this conclusion because when some applications change 
the display settings or use different display settings then all the 
desktop icons are moved to fit within the alternate resolution whereas 
other applications do not have this effect.

Benjamin -- There is no native way to change cursors in REBOL. Cyphre 
has done some experiments with it, and the APIs should be easy enough 
to call if you have /pro. Can't remember if I ever mapped those or 
not.

Volker -- colours for code will be highly subjective.
See Carl's choices here:

     http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=color-code.r
And  REBOL.org's choices here (look for "script colorizer"):
     http://www.rebol.org/cgi-bin/cgiwrap/rebol/css-view-system.r

Numbering: that's one central question. Currently the numbering is 
global to all projects for a given CC instance. When I made the first 
CC version, I wanted to follow the Mantis application as much as 
possible while make things simplier. I wasn't sure if the numbering 
should have been global or local to each project. Now, I think that 
I used it long enough to think that the local numbering is more natural 
and user-friendly. I'd like to switch to that local numbering in 
a future CC release while keeping the global numbering as an install 
option (for Mantis users and for migrating Mantis databases).

If you use global numbering it will be easier to reference tickets 
externally, and to move tickets between projects.

Otherwise you'd have to change the ticket number if it was assigned 
to the wrong project, and to include the project number in the ticket 
references.

It depends what you use it for I guess... 


for myself, I'd also use global numbering cause I have many projects. 
but I might want to have different sets of numbers on the same server. 
 


maybe you could just have an uid table name as part of the CC project... 
that way the decision is up to user and totally flexible.

I was thinking about keeping the current ticket number as a "technical" 
number for external references and moving between projects while 
providing a local numbering in the UI (with the option to reference 
a ticket by its local number+project ID, or by it's absolute and 
unique internal ID). I feel like maybe it would be overcomplicated 
and not worth the effort?

if you use external uid tables, you can have a dual id... the ticket 
global uid, and the projects-related id.

use the global uid internnaly, and show the project on on displays.

Well, I would need to be able to work on more than one project at 
the same time so I can copy tickets that apply to more than one product, 
like R2 and R3. The advantage for using CureCode would hopefully 
be to reduce work.