World: r3wp

I just wanted to say, that sometimes it is easier to not use some 
framework, because 1) each framework can do only certain stuff 2) 
you have learn this stuff 3) more complicated things are difificult 
to do. Goog example is that overhyped DB for Rails, don't remember 
the name. In 5 minutes, I needed more complicated set-up, and the 
answer? Bad excuse about framework being good just for certain things 
... no, thank you ...

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.

It is often about the clash of how we are used to think, and use 
some functionality, about our workflows. If everything is gluable, 
well then. I would not just like to see, that each style has tonnes 
of fields, to support upper layer frameworks. I hope you keep it 
streamlined to some flags, and custom data fields ...

btw - would it be (let's say later in the process) possible to introduce 
some other form of release? I mean - I would like to look into sources, 
but it is flattened recently.

I don't want to push you to Tortoise, etc., but there surely be some 
distribution form of the GUI? I mean stuff separated in files, etc. 
It helps studying some stuff

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.

or at least small changelog?  :-) Is it difficult to provide in recent 
stage of development? E.g. when you release new version - what actually 
changed, what should be tested, etc.?

changelog needs to be done by rebolek. I don't have an overview of 
the changes happening right now, of which there will be some more.

You are trying to tell me, that DB record linkage to form is dependant 
upon certain naming of the fields?

it's logical to bind the name of the field to the record name, yes.

Direct link of form fields to db rec is imo the worst illusion I 
have seen :-)

oh, no, now I lose all flexibility!
, but no you really don't.

I worked with similar aproach in Clipper, and most of the time it 
was not flexible enough ...

you solve this in the functions that link to the database.

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.

yes, I can confirm that ...

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 names are up for grabs, so we can discuss that now.

well, I guess using db nomenclature is better when refering to db 
services... no?

I don't like the underscore prefix, but this is Robert's idea.

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

is CRUD not more encompassing to persistent storage in general, than 
just SQL?

I mean thereby the SQL terms insert/change/remove/select

Regarding the _, we can get rid of it. I use it to "indicate" private/internal 
stuff, you shouldn't mess around with.

And _data should be renamed into BAG, because this better describes 
what it is.

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

Because, schema updates will be done automatic. Hence, adding fields, 
renaming fields etc. will work.

Small status update:


Cyphre has completed first version with keywords for draw blocks. 
This means you can now use the vertices of the box model for coordinates, 
instead of tediously calculating them inside the draw block.

http://94.145.78.91/files/r3/gui/240.png

New R3 GUI uploaded here

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

It should contain the feature.

http://94.145.78.91/files/r3/gui/resizing-new-9.r3

Contains example.

Go GUI-team go!

Not sure it is now the right time to report bugs for area style, 
I simply regard it being very incomplete,  but - writing some czech 
chars into area/field does not work ...

does this only occur for the area style? what about field?

ditto for fields ...

some chars do work, but half of them don't

Behaviour for chars under particular keys:

2 - losing the focus of area
3 - tpyes "a"
4 - arrow down
5 - writes "Y"
6 - writes "~"
7, 8, 9, 0 - types correct Czech chars ...

interesting, let me see if you have the latest compiled version

They seem to be the same size, but, just to be safe:

http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

OK, new executable + dll did the trick ....

ok, good

New R3 GUI uploaded here

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

Fixes slider crash. Is 21 kb bigger. For some reason. :-)

what's precisely "some reason?" :-)

I don't know.

Got a pattern on the resize loop bug, but I guess it requires a very 
specific VM setup:

1. Start the R3 GUI and make a window. Maximize it.
2. Resize the VM desktop window

3. Hope that your resize action is slow enough to allow you to doubleclick 
the titlebar to de-maximize it.
4. Now it loops between maximized and normal size.

Perhaps there is some confusion about screen-face size changing.

re 'area style - trying auto-scrolling or scrolling in general:


1) still the same bad aproach as with R2 area - I don't care that 
it does not hilite right now, that can be added, but when dragging 
the mouse outside of the area, it stops scrolling, and that is wrong 
- it should scroll even if I move mouse out of the window, wherever 
around my 2 monitors ....


2) when I start dragging, the proportional size of scroller is lost, 
and it gets reset to its full-size dragger ....

probably still some bugs in those areas.

I think, that system metrics are still under-developed. In fact, 
they were never correct in REBOL, and it is known fact, that R2 crashed 
when you changed resulution of window. I would like to see screen-face 
more developed - it should be a block, along with proper system metrics, 
number of monitors, their orientation, resolution, etc.

Uploaded panel scoping prototype:

http://94.145.78.91/files/r3/gui/panel-scoping.r3

Test support file:

http://94.145.78.91/files/r3/gui/file.txt


It's an earlier prototype that eventually became db-reactors, but 
it shows much more of the panel scoping features and uses EMIT, OBTAIN, 
ACQUIRE and SUBMIT.

metrics: I'm not sure what's being considered here. Cyphre may have 
something in the works.