World: r3wp

1) One internal style may be related to more styles.

2) Is this really a problem? I see no benefit of having such a simple 
function as part of R3GUI - because R3GUI doesn't need it.

I see no use forguie/widgets, style dependencies can be covered in 
documentation.

Henrik - tags - very nice!

1) It's possible to make the style tree, when the styles are being 
initialized. In fact I already have this as a separate script, but 
it has not been used lately.

btw - when I derive style by 'stylize, is there the 'parent field 
being set, so that the hierarchy can be created?

Tags are really trivial. They are just a list of words and we have 
a few TAG functions to set/unset/inspect them during runtime. It's 
entirely up to styles or the higher level code to use tags correctly 
and this is for example done with face navigation.

'stylize hierarchy, not at this time, I think. it would be easy to 
implement if we need it.

The hard part about tags is to name the right ones, so they won't 
overlap too much.

Was just trying out the r3-gui.r3 script and found out the fonts 
are hard-coded for Windows. I changed them to some Amiga fonts and 
the hello world GUI popped up. We'll need to find some way of handling 
fonts on non-Windows platforms via freetype to keep that script generic...

Thanks for info. Passed on to Carl.

ssolie - IIRC Cyphre reported here, that he has FreeType support 
done for A110, he just has to release it. That should help platforms 
like OS-X, Linux, Amiga IIRC .

Pekr: I'm using Cyphre's patch along with my own changes which enables 
the FreeType support on Amiga to function.

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.