World: r3wp

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?

Rebolek implemented it, so he knows that, although I suggested using 
a GOB.

Anyway: Just start using the GUI now. The style browser is built, 
I have a build system test GUI also and both work fine, so what we 
need is input on things that are silly or missing in the GUI now.

Exactly, you can use it NOW. You can wait for years for ideal full 
featured version. It is hard to make it perfect without real-world 
usage feedback.

BTW all the old demos form Carls version can be done in the current 
version so if want to be helpful you can just 'port' all the demos 
and update the docs along the way.

If you find problems during the 'porting' then just tell us so we 
can fix them or explain any difference.

What is broken with A110?

not sure it's updated yet, but I had problems with ENCODE and thereby 
SAVE.

The text codec is pretty stupid in a110, doesn't handle almost all 
datatypes.

henrik,  it seem's that style doc have a problem  => ** Script error: 
text does not allow command! for its text argument

** Where: show foreach unless show-now view catch either either -apply- 
do
** Near: show f

with last version of style-browser.r3

There are few problematic styles such as doc or table.

re focus - It's not definite implementation, it's test of whether 
it's better idea to have some universal highlight mechanism or to 
implement highlighting on style level. I'm still not sure which approach 
is better, having system-wide mechanism is a good thing, but doing 
this on style level allows better implementation.

Pekr, what is the reason you don't help either by:

* wring tests for Parse
* writing test for Mold

* writing tests for CureCode tickets that don't have tests in the 
core-tests suite yet
* writing some GUI styles

* responding to user polls, letting us know what your preferences 
are

* reading the documentation and/or new proposals pointing out at 
the problems you are having with them
* doing other useful work to help R3?


That is not complaint nor is it any kind of attack. It is just that 
I thought you needed R3? And, from my point of view there is no obstacle 
you could not do any of the above? However, you have still a lot 
of stuff you can pick and help to make R3 better. Do you still not 
feel like wanting to do something? Simply put, there is enough oportunities 
for you to pick from, and the quantity is getting bigger over time. 
Or, is it still too early, and any effort from you can be expected 
only when none will be needed?

My take on focusing: I think ultimately only each individual style 
can know how best to represent its focus. Obviously consistency among 
the styles is a desirable quality, and to encourage that, the system 
should provide some functionality which each style can opt to use, 
to derive its focus functionality from, or not to use at all. That 
choice depends on the style, obviously.

I don't think it's a good idea to be too rigid and require all styles 
to use a single focus rendering functionality. That's just being 
short-sighted, presuming to know how all possible styles will be 
written, and will cause problems.

I would probably agree, if I didn't have other experience with the 
VID Extension Kit. The trick is to make the focusing mechanism flexible 
enough to handle all situations. We are not building a GUI that handles 
specialized situations. We are building a GUI for large business 
applications with dozens of windows, hundreds of widgets and tons 
of forms. We absolutely do not want to have something like focusing 
being a special case per style as other than a special option.

More and more I think that visual representation of focus should 
be handled by style in on-focus actor with some help by system like 
providing default system-wide focus-color etc.

Rebolek, it means the focusing mechanism per style changes with the 
skin.

I don't mind an on-focus handling, but there should really be a standard 
method.

The problem with standard method is that you're trying to force one 
visual method on all style and it may look wrong with some (irregural) 
styles.

I don't think we will have that many irregular styles. Besides, each 
style will have a click mask, which could be used for drawing up 
an irregular focus ring. The only problem is to draw the focus ring 
inherently as a part of the face, and not as a layer on top of all 
faces, otherwise there would be problems with partially or fully 
covered faces in, say, scroll-panels.


Also, having differently appearing focus rings per style will be 
confusing to end-users, if the style designer can decide his own 
look for focusing.

If the style designer wants to make confusing widgets, there's nothing 
we can do about it other than providing some style guide lines.

Anyway, right now I prefer to do this in style's on-focus actor. 
After few more styles are done we can check for repeating patterns 
and try to make it more general.

The patterns will be repeating for a good size of already existing 
styles, such as fields, buttons, so I don't agree with the current 
approach. It will also take longer to create the skin, when we get 
to that point.

I don't agree. We don't have some good model for this right now. 
Before we have some good design of visual representation of focusing 
in our current box-model, then we can make it system-wide. But right 
now it's too soon.

We don't have some good model for this right now.

 - We have the VID Extension Kit. It's been doing focusing centrally 
 for two years now and it works quite well, sans some well-defined 
 problems, which we have a good chance of fixing for R3.

I'm far from the GUI project, but I guess that the best would be 
centralized default focusing with possible per style extensions (using 
style's own focusing if required). Style should provide some required 
info of course.

My opinion above is for special focusing-- like using tab to cycle 
thru gui items (like buttons).

Yes, that's the goal.

I'm not against central processing in draw-face. I'm just right now 
not sure what's the best way in our current box model. I need to 
do more tests before implementing this so I don't have to rewrite 
it later because of bad design.

Ok, that will do. We just don't want to end up in a situation where 
a central mechanism for rendering the focus ring becomes impossible 
to do. we will have a similar situation with help bubbles. Perhaps 
it's best to have a general mechanism for generating a gob near any 
face. We can use that in the help system as well.

We have that mechanism.

It's used for tooltips.

Then, at least initially, is it very difficult to render a gob with 
a colored 1-2 pixel edge and simply have it rendered with the same 
dimensions as the focal-face? Later, a more sophisticated drawing 
mechanism could be used.

It will need some changes to event handler to ignore the highlight 
gob, but it's possible solution.

if you do that, you're 80% done. that leaves a few problems to solve, 
but that can be done down the road.

To have event transparent gobs is on my wish list for a very long 
time already.

I thought actually they were event transparent and the face concept 
was the part that dealt with events, but oh, well.

Face makes gob event transparent (can pass event to other face/gob).

Are there any GUI tests available that will demonstrate all the various 
GUI features available in R3?


I'd like to know how complete my GUI port is for Amiga so I was hoping 
there was some benchmark to work towards. I imagine all the platforms 
will need such a test in the future to guarantee a certain level 
of basic functionality across all platforms.

There's style browser that's for testing styles, but you probably 
wait when Henrik builds new version of r3 gui.

the style-browser I have is a bit old, but it should work. There's 
a link earlier in the group.

It may be good idea to build new one. Keyboard navigation improved 
a lot and can be good for testing key events.

ok, I'll try to build with A109 to circumvent the build problem.

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

Both style browser and GUI updated.

Just tried to run the style-browser.r3 on Amiga and hit the following 
problem
>> do %r3-gui.r3

Script: "Untitled" Version: none Date: none

>> do %style-browser.r3

 Script: "R3 GUI Style Browser" Version: $Id: style-browser.r3 1179 
 2010-11-19 18:11:46Z Rebolek $ Date: none
** Script error: cannot 
 MAKE/TO image! from: make gob! [offset: 0x0 size: 400x300 alpha: 
 0 draw: [clip 0x0 400x300 anti-alias false pen false fill-pen 192.192.192 
 box 1x1 399x299 0 fill-pen false pen 64.64.64 line-cap square line-width 
 1.0 variable line [0x0.5 399x0.5] line-cap square line-width 1.0 
 variable line [0.5x0 0.5x299] line-cap square line-width 1.0 variable 
 line [0x299.5 399x299.5] line-cap square line-width 1.0 variable 
 line [399.5x0 399.5x299] clip 6x6 394x294 translate 6x6 line-width 
 1.0 variable pen 255.255.255 fill-pen false anti-alias true clip 
 0x0 0x0 pen false line-width 0.0 variable grad-pen linear normal 
 1x1 0x2...

Any ideas?

The script properties look corrupt

ssolie, if you instead of running the style browser try:

view [button]

Do you get a window with a button?