AltME groups: search

Cyphre says the bug is due to a missing box model. Will be fixed 
soon.

Robert - this is OK with me. In the past, I worked with Cyphre, Romano, 
to do personal testing ... lot's of errors and misconceptions caught 
on my side. In such early phase, I might cause a flood, so if you 
want, I might stop for few more releases ...

so - if anyone wants - Cyphre, Rebolek, I can test privately in early 
phase, and report privately too, to not cause much of the flood here 
.... or I can simply shut-up for a while :-)

With a107 (that I build with the MS compiler), go.r3 seems to run 
quickly when launched, but slows down dramatically after just a little 
bit of mouse movement. If I stop moving, the speed resumes after 
a little while. I don't remember seeing this in older builds. Has 
something changed wrt event processing?

Adrian, this is using a core without r3gui compiled in and just run 
normally

i see that some people recommend that your GUi should run in a separate 
thread from the rest of your application so that while's it's busy 
doing things, the GUI still remains responsive.  How can we apply 
that to R3?

I suppose the event model that Carl talked briefly about could rectify 
that, so there would not be a need for threading.

can anyone explain why there is a 'MOVE event every second when we 
have a gob! window open...  ?


I'm guessing its for blinking type handling.... but it should have 
its own type.  This also occured in R2 and its extremely annoying 
when handling events.

box clipping of gobs is making them harder to use than they should 
for general graphics use when gobs are nested into panes. 

it would be nice to be able to support a clip? parameter.


for example, it would be nice to be able to use 0x0 as the origin 
in which to draw (so that negative offset values be used in the draw 
block), but we can't unless we always add a transform to the draw, 
which has to managed along with the size at any change in size.


go three pane deep, and we have to manage all the hierarchy all the 
time its pretty complicated for nothing.  


pane grouping should allow them to be used, just for transform, not 
only for visibility.

henrik, ok, in any case, we can use them within a draw block, which 
isn't that hard to do anyways... in the meanwhile

ok well... I'm getting an assertion failed #1207 error crashes with 
large blocks... using to-draw on a large block closes R3 without 
any warning!

will reduce the problem to a reproductible crash test.

yeah, I was thinking of doing another test run... the current generating 
script is pretty convoluted as it goes through a complex liquid dataflow 
network to be built.

right now I'm busy integrating OpenGL within a gob!  :-)

a question... is there a single place where a gob is destroyed (maybe 
a callback or some method) within the host-kit?  just so its more 
invisible, when I need to detach a gob from the OpenGL rendering 
context... at this point I have all I need to build an OpenGL gob.. 
but nothing to get it automatically cleaned up.

GOB is 'destroyed' by GC AFAIK so you shouldn't rely on that event 
imo. I don't know details of your implementation but making separate 
OpenGL context for every GOB doesn't seems to me as a good idea.

another question.  if I have a region of ram which contains rgba 
pixel data as an array.    what is the function I need to call within 
the compositor::cp_process_gobs() func so that I can copy that array 
within a gob's pixel buffer?


I've been running around the source and its a bit complicated... 
there are so little comments in the agg code... I'm not sure what 
does what.


I was thinking that the clue lies somewhere in the undefined code 
within 
case GOBT_IMAGE:

the gob will act as a container for an OpenGL context (and viewport).


so a single gob! will store the whole 3d scene, not just a single 
poly/shape.   I guess I'll have a command block similar to gob!/draw 
 to define some aspects of a 3D scene (though not everything... since 
3D is pretty heavy... probably things will be loadable from ram and 
disk)

case GOBT_IMAGE: is a place where the gob/image content is rendered..as 
I said this code was disabled when Carl updated the hostkit. I'll 
be updating that part this week.

my goal is to allow an dynamic linking of any external gfx engine 
within the current system.   hopefully DirectX, Cairo and ImageMagic 
integrations will also be possible, but I have no idea about their 
API so it might still be a pipe dram at this point.

one of the strengths of image magic is that it can render using DISK 
memory.  which means that you can render images larger than your 
ram.  I am done a few tests in the past and ended up merging 20GB 
of images into a single render.  a part from it taking 30 minutes, 
it all went well, and the quality is fabulous.

it has a selection of ~ 10 filters, and it can render at any bit 
depth, as well as supporting all image formats known to man, and 
even a few video formats too.

(do you really think I would release a GUI that looks like that?)

Pekr  na i know it's not the ended thing I repeat the  overall widgets 
are cool  their organisation is cool  but its the grey scale .. 2) 
anyone ? not me at least since people are paid for that the least 
they can do is do a professional default skin ... Henrik i judge 
what is shown that's you don't want to be commented don't show imperfect 
not ended things ...

shadwolf - dunno if Robert proceeded, but someone sent him a contact 
to some cool guy doing some GUI designs. We will see, if anything 
will happen in that area. Robert? :-)

http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3


Newer version too. Sorry about the ballooning in size, but this is 
due to a change in the build system.

ok, there is a bug (surprise), that I've been able to trigger once 
by accident. I've not been able to do it more than once, but we need 
a way to reproduce it.

what I did was create a GUI similar to this one:

view [
	panel 1 [check]
	panel 1 [button button button]
]


When you resize this vertically by a few pixels, the bottom panel 
will resize incorrectly. That is known and will be fixed. What I 
managed to do, was to either move or resize the window in a way, 
that would cause resizing to get stuck in a loop (!), so it goes 
up and down in size by a few pixels vertically on its own, and the 
window just sits there shaking up and down in size. If possible, 
we would like some help with reproducing that.

I haven't tried it, and I'm not sure it's a specific size that does 
it, but more a series of events. The testing system is not yet in 
place to do it this way.

In my opinion, you not only aren't a "free worker", but, actually, 
you are very costly in taking time and effort to deny the nonsense 
you are spreading here

Henrik - to your above code example - what I don't like is, why the 
resize system dictates me, how to shring the window. When I want 
to maximize a window, it should not do so only in horizontal axis, 
but also in vertical one. That's just my opinion, but I would find 
it more predictable.

Pekr, actually not. On a style level, the style itself is contained 
within one file. It's been like that since Carl's first prototype 
and it stays that way, but a table may contain a variety of different 
styles, such as fields for editable input, but you really don't want 
field to be in the same source file as for table.

yes, but working a failsafe mechanism into table that makes it slightly 
less functional if a field is not there... I'm not sure that's a 
good idea. It's better to dictate dependencies and follow them. What 
if you decide to derive table? You might get different R3 GUIs that 
work differently. It's now starting to make me think that it's a 
bad idea to allow removal of certain styles. :-)

is there a way we can get the r3-gui not compressed?  I'm getting 
strange handler errors which cause rebol to halt whever I try to 
open another window not from r3 gui.

I'm preparing a different build script, so it will appear uncompressed. 
Should be up within a day or so.

cool


also, is there a way to link an arbitrary gob within the gui defintion?

seems using view/as-is when r3-gui is loaded prevents r3-gui from 
doing its stuff... it craps out with a handler-related error...

(this is on a window not using r3-gui, btw)

view is probably broken with non-standard windows. I made a few changes 
in it to make it work properly, but it could use a rewrite.

it could be nice to add a simple style called gob, which just uses 
a gob! as its setup data


basically, it would be a static gob, which only displays itself, 
doesn't resize or just doesn't respond to the resize re/actors.


this would allow integration of different graphics tools which weren't 
setup using r3gui.

just a thought.

thxs


are the online docs usable for style definition or has it changed 
so much that there's no point in trying to make a custom style right 
now?

ah there is a box style I can easily use.

thanxs for all.

hum... using stylize doesn't seem to add to the global style sheet... 
is there a function to call first to setup or assign to a specific 
stylesheet?

such as to replicate stylize/master   in R2..

it should do that. it's a bug if it doesn't.

cause right now, the gui looks totally dead a part for the fact that 
it resizes (though its late by one window resize event.)

since it's a temporary skin to test the materials system

does the material support some sort of accumulation?

a very loose example

I want gui in style dark
I want aluminium

the issue here being that dark is not a value but a process.

so you get dark aluminium ?

ah ok, so it doesn't accumulate the materials.  since color is a 
property, not a process.  here dark is a concept... 

which might ultimately apply to all styles, but which isn't resolved 
by the aluminium, but by dark itself...


it was just a question, I wasn't expecting a yes ... its a very advanced 
shading (are rare, and complex) process.

(its definitely not a limitation on the part of the engine, for those 
who might mis-interpret my question)

you can have a look at the materials section to see the specs for 
a material

yeah I did briefly.. but there is a lot of code to sift through... 
it is 216 kb after all  (which is pretty lean for a GUI complete 
engine ;-)

There are two primitive formulas used to create a simple specular, 
but one is broken. I'm terrible at that kind of math, so maybe they 
should be revised. I could use some help in creating a designer friendly 
few speculars that emulate brushed metal, plastic, glossy, glass, 
etc.

yeah, without some support libs, designing shader stuff from scratch 
is hairy at best...


the only help I can give you is to use light energy-based math instead 
of color math.  I've seen some VFX compositing tricks where  you 
can simulate this by scaling colors with a gamma of 2 blending your 
colors and then applying the inverse gamma of 0.5.  the way the colors 
will merge usually provides better results, but still doesn't clip.


the idea here being that the gray areas won't merge the same way 
as low and high-color areas... might be usefull to play around with 
gamma in the draw block too... though I'm not totally sure how it 
all works in agg.

shaders must be very simple for speed. I'm not so terribly interested 
in actual realism, just a way to map a linear value to a specular 
value, which then gets tinted with a color.

these are my private builds and they will not come in a regular frequency 
yet.

Pekr:  I had a contact who worked for Adobe and was a gui designer 
on many of their applications.  He is now an indepent contractor, 
but now that he's contracting he's enjoying his time to be with his 
family.  Adobe worked him hard for many years.  So, unfortunately 
he is not available to help out.

my first post above is a reply to Henrik's images regarding the box 
model.  It was an attempt to answer Shadwolf's question about waht 
the difference was between the two images.

yes, correct, however, I'm going to provide a new build in just a 
moment.

uncompressed build is very welcome - we can look at sources here 
or there, if there is a need ...

field is weird a bit ... it places caret out of the box on the left 
side by default ...

text fields are comprised of two gobs. maybe it makes sense to add 
a debug option to color the text gob.

Pekr, right now I rewritting scroller. Carl's scroller was "too inteligent" 
and needs to be "dumbed down" a bit.This will make things like area 
working again.

it is indeed a bit too small, but the text alignment stays inside 
the field for me.

Is anyone writing a styles demo?

I see the random characters are now gone from a button with no name

I'm still getting a divide by 0 error for an area as well

is there stil a cache problem from my version?

the revision 0 thing in the header will be fixed, once the build 
system can get a revision ID from SVN. if anyone knows how to do 
that, I would appreciate it.

`svn info` will give you, amongst other things, the latest revision 
for a repository (can also be used directly with a repository URL). 
There's also some helper programs such as "svnversion" (should come 
with SVN) or SubWCRev (comes with TortoiseSVN).

I got the new exe and dll, the re-downlaoded r3-gui.r3, dialog and 
validation too, but get this error when clicking on a button in the 
dialog demo:

** Script error: path win-gob/text is not valid for none! type

** Where: any view either create-dialog request-user do switch applier 
apply if

foreach if do-face if actor all do-style if do-event do-event do-event 
either ap

plier wake-up loop applier wait do-events if view catch either either 
applier do


** Near: any [opts/title win-gob/text "REBOL: untitled"] ds: screen/s...

It looks like the feature for keeping several draw blocks in the 
same style was removed or changed by accident. this means that the 
validation icons won't work, so I have to find a different way to 
test validation. I want to separate the dialog code from validation 
and then make a proper validation test window, so you can look at 
the code and see how it works.


Furthermore, there is a database extension, I want to test more: 
Parts of validation (the scoping part) was inspired by this one and 
I think it would be good to get this out in the open, as it can be 
extended either to a file database or any SQL database by the community. 
The point of it is to make it very simple to connect the logic of 
a form to a database record and it works a bit differently from setting 
up a regular form.

several draw blocks in the same style is a must, or I really don't 
know, how you want to support a bit more dynamic styles ....

yes, I'm sure just something was disabled. I built a new version 
today, but it's less stable than the current build, so I'm not going 
to release it.

is "changing language" a new feature of w7  ?

yes... especially since AFAIK the idea of gobs is to use many sub 
gobs for a single face...

well, actually the faces do contain other faces, in a VID style configuration, 
but it may very well be that event handling is not done correctly.

I don't explicitely want to use a face within a face...  for graphics, 
I want multiple gobs in a single face... so event detection, which 
starts at the gob, should allow us to have a state where if its user 
data is none, its just ignored from the stand point of the generic 
face handler...  at some point, it will hit the actual parent gob 
which IS the face, and event handling should occur there.


just ignoring the none user data is all event detection rountines 
in the r3gui you posted, did just that. IIRC.

Pekr, AFAIR, a single gob is used per face. Several gobs were manually 
managed by the style writer in Gabriele's VID3 and was part of why 
styles were harder to write. I don't think, however there is much 
that prevents the style writer from writing a style that uses several 
gobs.

I find it easier to use many gobs for many styles... especially when 
mixing different gob types to form a single face.

well, I found it harder, so this is a relief. :-) but inside a style, 
I think it's possible to freely use any number of gobs.

oh it was mostly hack and slash rambo stye fixes... the most important 
is just adding a sub to any style and trying to make it go thru events... 
its easy ... it crashes until all events flow thru gobs which have 
user data set to none.

sort of, yes. write a form and add a few keywords and you can add, 
edit and delete records in a db.

what would be interesting would be to have the community write a 
simple flat-file database backend for it

Pekr, the reactors link to some functions, which then in turn create 
the specific procedures for adding, editing and deleting in a table 
for a specific database.

A basic example of how it looks right now:

f: view [
	form-panel: panel 2 [
		group 1 [
			title "Record fields"
			bar
			group 2 [
				label "Name"		name: field		; stored as name
				label "Address"	address: field	; stored as address
				label "Age"		age: field		; stored as age

    label "Skipped"	skip-field: field options [skip: true]	; not in the 
    list
				label "Ignored"	field			; not in the list
			]
		]
	] options [record: 'rec]
	group 6 [
		button "New" obtain 'form-panel add-record
		button "Save" emit 'form-panel update-record
		button "Delete" do [delete-record]
		pad
		button "<" obtain 'form-panel next-record
		button ">" obtain 'form-panel previous-record
	]
]


The 'rec is a record object, which is filled with data from the server, 
using the backend function, and when submitting, is used to gather 
data from the form and into the server.

The trick is that a panel acts like a record. You specify the record 
object in OPTIONS. Then any named field, checkbox, slider or whatever 
participates in the record unless the option SKIP is true.

SKIP allowed reading the record, but not writing back changes, such 
as a "last updated" field, which you don't want to write back.

http://94.145.78.91/files/r3/gui/db-reactors.r3

This shows a simpe skeleton of what it's made of.

The SKIP and RECORD options are scoping, so if you define a panel 
with SKIP, everything inside it is skipped on EMIT.

henrik there is already a decent db on rebol.org from Pavel... might 
want to look into that.

the point was really not to find a database, but to connect to it 
from the db reactors.

yeah... just saying that its a nice rebol-based experiment.

Pekr, db-reactors and validation are optional features. Reactors 
are made using the MAKE-FACE-ACTIONS function, which specifically 
is designed to add a new aspect to the GUI in a way that doesn't 
interfere with its original functionality. And while you don't care 
about it, we do, because we need specifically to builds apps that 
use them, and I've missed these things in VID since I first used 
it. There's also that little detail about shaving off months of development 
and testing of large apps. The "bloat" you talk about would be around 
5 kb of code for now.

Bloat of functionality: That's not the point of these frameworks. 
The point is to make certain rudimentary things quick and easy to 
set up for anyone trying to write a GUI. I'm pretty sure that once 
you've fixed the 657283th bug in a javascript/HTML webform, you will 
really wish this was already worked out for you.


If the frameworks don't work out for you, then they are poorly written.

You have some rules that you need to follow in any framework, otherwise 
they won't work for you. In the case for, for example db reactors, 
you need to know about the specific options, the rule that fields 
must be named for them to be used and how. But really, there are 
only few rules and once you've worked with attaching database records 
to a form, in a manual  way versus this way, you probably don't want 
to go back.


The other thing is an illusion of control with absolute flexibility 
without a framework. It simply lengthens development time and introduces 
bugs (something that we keep overlooking, eh?), and generally keeps 
the customer unhappy.

I can make a zip file of the sources later.

Can anyone else confirm that on Windows (at least on Win 7 64 bit) 
the last r3.exe that Henrik posted a link to here, pops up a security 
dialog ("Open File - Security Warning")?  This isn't the UAC dialog 
that you get when you run an executable as administrator, btw. Other 
r3 executables that I had lying around don't do this.

Henrik, thanks for posting your db-reactor ideas. Is there a reason 
not to use the standard REBOL series func names for actions. i.e. 
insert/change/remove/select rather than add/update/delete/get? Another 
option would be the names from CRUD. 


What does the underscore in your _data naming convention indicate?


I need to look at your validation design again, to see how things 
work together.

the _data option is a multi-field field formed as a map!, to allow 
extending a table, without adding columns in the table.

Petr, being able to get a database / table design right from the 
GUI is IMO a very good approach :-).