World: r3wp

I've got one question. There's face/faces for all faces that are 
part of a face. There also needs to be some container for faces that 
are part of face but are not visible (hidden) right now. Currently 
it's called face/cache, but I think the name should be different. 
Any ideas?

face/hidden ?

Thanks! Native speaker is always appreciated when chosing right names 
for words :)

I'm considering a rewrite of the validation prototype as there are 
some parts missing with regards to initial state.


Have there been any considerations on how to use the DIRTY tag? I 
have some ideas on when DIRTY is set:


- The user creates an edit in a field, changes setting in a radio 
group, etc. It would not be enough to focus the face, but a specific 
action would have to be taken.

- When the user deliberately moves the edit back to the original 
state, the field is still dirty, so we can observe which fields were 
manipulated.

- Using a function DIRTY?, we can observe whether a field or a panel 
is dirty.

- It's not possible or logical to set the DIRTY tag programmatically 
(other by forcing it in with TAG-FACE face 'dirty)

It would be cleared when:


- Using a function CLEAN, we can unset the DIRTY tag in a face or 
panel of faces. This would be the only way to unset the tag.

- When the user deliberately moves the edit back to the original 
state, the field is still dirty, so we can observe which fields were 
manipulated.

 - I don't like this one. Than we should have a manipulated flag. 
 As dirty means: changed.

ok, we need specific scenarios for the use of both DIRTY and MANIPULATED.

What about finally releasint useable GUI with more than useable button 
style? :-)

For DIRTY being changed, that has relevance for when validation is 
not used, for enabling submit buttons. But this also means the original 
value should be stored, which may be covered by the undo system. 
I'm not sure that's useful, if the undo system can show the number 
of changes in a field.


For MANIPULATED doing what is described above, it overlaps most of 
what DIRTY would do and it would also overlap most of what validation 
already does, namely detect and approve/deny changes in a field. 
I'm not sure it's useful either.

It all depends on what DIRTY would be used for.

I have a very basic question, that I have already asked to Carl : 
how to get a working gui.r version ? when doing load-gui, I get the 
following error message : ** Script error: size-text has no value. 
It seems to me that this point should be definitely fixed, as it 
prevents anybody to do view tests (for instance the ones given in 
the reference doc http://www.rebol.com/r3/docs/gui/guide.html) I 
think that this should be done quickly and independently of any improvement 
and evolution of the gui styles and functions.

you're loading the wrong gui

load-gui references Carl's old GUI but you need to manually load 
Henrik's Gui

script

which is a result of the work of the RM team

Is it the r3-gui file ? Then the gui doc page should be corrected 
accordingly ...

yeah .. it should be if anyone has the time and rights

Now provides a visible frame for keyboard navigation:

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

nice!

Henrik, what happened to your skin of a few years ago? That looked 
much better

Kaj, it was very hardcoded, but it will probably be reimplemented.

That would be good

This won't start until sometime later though, so it's going to look 
like this for a while. I'd hate to do too many rewrites, if I were 
to start now.

henrik, could you tell me if your r3-gui.r3 will works on linux ?

not until the View part will be enabled in the hostkit

you can possibly test under Wine. Earlier R3 alphas worked there.

i just try it now with wine ;-) and it s works

do you think carl will choose your gui for R3 standart ?

that's not certain yet as he has not made any evaluation yet, but 
it will be a publicly distributed GUI, so you can at least get to 
use it.

could you give me an url to try all your style ? like tour.r on rebgui 
 ?

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

I think that works.

thanks you

I should update it soon. There have been quite a few changes since 
that version...

i just download your last version of r3 and r3lib.dll. i will wait 
for it ;-)

I cannot build right now, so you might as well play with that one.

oki thanks

Henrik: I have buttons working on the Amiga now using your r3-gui.r3 
script. I'll blog about it soon-ish.

Guys - what is the reason of kind of slow R3 GUI progress? At least 
from external observer point of view? That is not complaint nor is 
it any kind of attack. It is just that I thought that you need R3 
GUI for a commercial project? And from external pov we could see:

- new resizing system
- some new higher-level systems (validation, tabbing/focusing)
- some news about low level tweaks
- Cyphre posting REP about new possible rich-text system
- some endless work on styles


However - from external point of view, and unless it all plugs together, 
Carl's original VID felt more concrete, more complete. Is there any 
estimate when stuff will plug together to form usable system? Simply 
put - maybe if system would be docced, ppl could start working on 
additional styles? Or is it still too early, and non-yet-finished 
subystems could break any such code?

Pekr, A110 doesn't work with the build system, so no new releases 
recently. Pace is the same as before.

ssolie, cool :-)

Pekr, also, I have no estimate other than ASAP.

ASAP sounds good :-)

Pekr, if you think Carl's version is more complete, then you can 
use it...AFAIK Carls version is simply incompatible with current 
R3 and doesn't work ;)

We are fighting on all fronts to get our stuff in better shape everyday. 
I must also note we are working on other things that needs to be 
done. The system is in final phase of stabilizing its internal parts. 
We are now focusing on a good way how to do automatic testing before 
we start doing more styles...

As always, you can wait for our stuff or be active on your own, use 
what we gave to the comunity and make everything better, faster, 
longer, stronger and quicker!

My whole point was, that Carl took some rewrite route back then, 
and in 2-3 months timeframe produced kind of basic, but working GUI, 
which could be demoed by 'demo function of R3, while with R3 GUI, 
we are not there yet. I don't need to be pointed out to such facts, 
that 2 years old GUI apparently does not work with latest R3 builds 
:-)


Also - "you can wait ... or be active on your own ..." is not an 
argument for me. Noone apart from maybe 1-2 guys here want to work 
on yet-another GUI project. The whole thing is about me (and maybe 
others) not seeing a "big picture" - things plugging-in together 
into useable form timeframe. I know that giving any terms is very 
tricky, but my point was not to get exact nor even estimated date 
- just some rough ideas about what's still left to be done ....

what's still left to be done

 is very wide question and everyone has porbably different opinion 
 on that

Otherwise the "ASAP" answer from Herik is probably correct answer 
to your questions ;)

I'll post a small list...

What's left (not necessarily in order):

- test framework for GUI
- dialogs
- form validation, which meshes with dialogs
- help system, which meshes with form validation
- database record management, which meshes with form validation
- actor documentation parsing

- better View function that supports initial states for forms and 
dialogs
- some issues with resizing
- work on text editor core
- general style work
- skin comes last


Of course over time we get new ideas or stumble into design issues 
that need to be solved, before we can move on. That's necessary to 
make sure that some future feature is going to be simple to do.


All this is of course separate from hostkit, font rendering, and 
DRAW enhancements.

Henrik - as for higher level stuff - form validation, db record management 
- let's say I don't need it for some simple stuff. How is that implemented? 
I mean - I don't mind supporting code sitting there, but e.g. I don't 
want validation supporting "visuals" being visible on the screen 
for some simple "embedded" stuff? Could such concepts stay invisible?

sure

OK, good to hear that ...

I noticed visual representation for the focused button. Just curious 
- how is that done? Is that a part of a margin/border of the style? 
Simply - is it drawn inside the style, or outside of it?