World: r3wp

ah - and how?

download http://94.145.78.91/files/r3/gui/r3-gui.r3
do %r3-gui.r3

thanks!

you're welcome :)

We should make this a FAQ

download the file as directed, when doing it:

>> do %/c/r3/gui/r3-gui.r3
Script: "Untitled" Version: none Date: none
** access error: cannot open: shape reason: "module not found"

This looks like you are using the /Core version no? Where did you 
download the 2.100.110.3.1?

You'll need a "/View" build of A110, such as:
http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

Mine is of the same version as Kai's. I hope the core and view versions 
do not share the same version number.

Thanks again!

Henrik, so far there is no difference in the 'about' output when 
you build r3/Core or r3/View exe. Even system/product is always set 
to 'core . Something that needs to be solved by beta.

ok, mine shows a window when using View, so I suppose it's the View 
version.

Henrik: I have style-browser.r3 running on Amiga now. It tends to 
stop running a lot with script errors... how complete is this app?

ssolie, styles like pane, table-* and doc are not yet fixed. Other 
styles shouldn't produce any errors, afaik. If you find some problems 
from other than mentioned styles, please, send me the errors privately 
to keep the noise low here.

ssolie, since it tests styles, the app should be complete, but may 
occasionally encounter styles that are unfinished. the program should 
be used, every time r3-gui.r3 is updated.

Isn't R3 GUI in CureCode?

I think it would be too noisy to have curecode bugs for the GUI just 
yet, but that's up to Carl or Rebolek.

Doc can add it as a new project I guess.

yes, agree

But then the GUI project could be on GIThub as well.

Doc can add an R3GUI project, when he's ready and then we'll start 
using it.

Github: depends on how we continue to handle sources, but maybe this 
can be done.

style-browser kind of runs under AmigaOS - http://solie.ca/

cool :-)

font quality is not nice, but still - Amiga got R3 View almost running. 
One year ago I would not believe it. Now we could get some Linux 
guru onboard ....

http://94.145.78.91/files/r3/gui/panels.zip

All panel tests.

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


PANEL and GROUP no longer exist. You need to use HPANEL/VPANEL or 
HGROUP/VGROUP.

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

Style browser is updated as well to reflect this change.

Note that TABLE and its related styles are outdated and will cause 
crashes.

(same for DOC and PLANE)

Button can be focused. Small enhancement request - can we add enter 
reactor for the button? I would find it usefull being able to run 
the button action hitting enter :-) btw - panels-2 - can't focus 
any button after the script start. Only after I invoke first button 
press ... now R3 crashed big time :-)

Pekr, does it work with the spacebar? There could be a collision 
when using Enter, because it may be used to confirm the default button, 
which may not be the same one as the one in focus. That depends on 
keyboard shortcut layout, though.

Yes, spacebar works, thanks ...

Henrik - I just watched behaviour in Mozilla's Thunderbird, re button. 
There is 'default button in focus on particular page, so that enter 
works for that button. But - when tabbing, and IF the type is button, 
then default button is no more hilighted, and tabbed button is hilighted 
instead. When you tab away from the button, default button goes hilighted 
again. That way, both enter and space-bar works for actually hilighted 
button ...

The same goes for default Windows dialogs, and it is imo good behaviour. 
Simply put -enter stays as a default action for the form's default 
hilighted button, unless another button is tabbed. It unifies enter 
| space-bar behaviour for button types. If we stay with current behaviour, 
users might be confused, as enter will fire action on different button 
than the tabbed one. Of course it depends, and I would like to know, 
what is the functionality on non-Windows platform?

If you are able to move the default button using tab focusing, then 
IMHO, default no longer makes sense, because it overlaps tabbing. 
This is one thing that OSX does quite well and the idea is taken 
from there.


The alternative is to get rid of the default action and simply place 
the focus where default would be, but that means potentially lots 
of tabbing, if you need to activate a specific field.

Hmm, so OS-X behaves differently. Now what we do? Do we simulate 
each platform differently?

Activating a specific field would also occur in validation, when 
focusing an invalid field, so it would disrupt default functionality, 
if they are one and the same.

That is possible, since the behavior model is not very big.

But even under Windows, the different GUI systems may not behave 
identically. I would try things in Control panel and other Windows 
standard dialogs.

I expect it being possible. The question is - do we want rebol app 
to behave in OS native way, or just the same thru all platforms? 
I am for the former ....

yes, I agree on that.

I tried Thunderbird and IT Internet settings (which is Windows native 
dialog)

I aven thought about possibility to link to native widgets, but just 
to mimick skin parameters. I am not sure it is possible, but when 
you e.g. create skin, which looks like OS native one, then users 
will be confused, if you set OS native feel differently. Under windows, 
there's not much of possibilities, except for some Windows bar size/decoration, 
or font size. But under AmigaOS and e.g. MUI, you can change the 
look of widgets quite a lot. The question is, if someone would be 
willing to simulate such a complex system as MUI is, and define all 
the skins. The app would also have to be notified, that user changed 
central setting, to readjust ...

if we do that, there might be a need to define a behavioral model 
as part of the skin, but I'm not sure how much it encompasses. There 
are some little details that I expect to work in a specific way in 
OSX, which don't work in Windows, and vice versa. This means that 
styles may not implement these behaviors directly, but that is probably 
difficult to avoid.

I think we should categorize typical differences, such as:


- whether certain buttons are activated on mouse-down or mouse-up.

- whether a button action is activated when dragging out of a button 
and releasing.
- whether default follows tab focus.
- etc.


Then these could possibly be implemented in styles and abstracted 
away from the style as a behavioral profile for a specific OS.

Mozilla apps are not a good place to observe native system behaviour, 
because they use their own toolkit

Abstracting the things Henrik lists would be very nice

That is why I checked with native Windows dialog box :-)