World: r3wp

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?

to the focus discussion. I don't know why, but I agree with Rebolek 
this time :-) I know that I am fan of concepts, and subsystems. IIRC 
VID2 used something like abstracted feel storage. Maybe it was initially 
a good idea, but how often were 'feel objects actually reused? This 
was imo an example of a concept, which did not live to its expectations.


I know that R3 GUI is abstracted in better way. But I also feel, 
that we more clearly kind of encapsulated styles - they have all 
those on-* actors, which let the style to react to various events 
in its own way.

So - stating above - are we really sure that:


1) having abstracted all-styles-related visual representation of 
focusing brings us an advantage? One advantage might be, that if 
it is not central, lazy style coder might not implement visual focus 
representation, and then half of styles might miss it, or we might 
face some weird situations, when the style author implements the 
visual focus representation a different visual way.


2) are we sure that one central system will work for e.g. for some 
complex styles, where some special tricks might be needed to display 
focus visual representation correctly?

Henrik, Ssolie - beware - I just got the samy error with A107

I would try to build A110, but I am not able to get sources from 
Carl's git. I tried to download his .zip archive, changed to TO_WIN32 
in the .h config file, but it does not build - probably a linux distro 
...

Whenever you are creating a concept in a GUI, such as keyboard navigation 
and focusing, you immediately want to centralize it with the option 
of per-style overrides. This is the illusion of control in that you 
want to meddle, when in fact, you are moving toward a lack of control 
a lack of unification and opening up all sorts of opportunities for 
bugs.


It is *much harder* to develop large applications, when concepts 
are not centralized, in the same way if you don't have a single mechanism 
for help bubbles, for determining which button is default, have a 
single, unified resizing system (hello, RebGUI), have a standard 
method for exiting windows, have a standard method for creating and 
displaying any number of dialogs (hello, VID), have a standard method 
for validating forms, have a standard method for reading and writing 
face properties (hello again, RebGUI).


With all these things properly in place, GUI development is reduced 
from weeks to hours.


Of course the other method of thinking may prevail, if you have never 
coded a large GUI before, and therefore don't consider the testing 
process, which can take *weeks* and *costs money*, because you have 
to test every single implementation (N number of implementations) 
of the concept that would otherwise be done in a central system (1 
implementation). It's really the testing that constantly is underestimated.


One can only determine that something cannot be centralized if it 
will create too much code, compared to a per-style solution, but 
it will in general always cause the GUI developer to create functioning 
and *bug free* layouts with much less work.


In that same thinking, R2 View centralizes the generation of a face 
image gradient, background, text display and edge appearance. It's 
not flexible, but it makes it darned simple to skin and generally 
does not have bugs.


And you FEEL object question: Yes, they are reused a lot, otherwise 
VID would probably be 100 kb bigger.

I don't know why, but I agree with Rebolek this time :-)

 - sounds like it's unusual. I though we're in agreement most of the 
 time :)

btw, when implementing focus, I found that about 50% of styles are 
irreguraly shaped and therefore need focus-draw support on style 
level.

Henrik - I can understand - but I also am aware of other possible 
aspects, and you can see that in Rebolek's comment: "I found that 
about 50% of styles are irreguraly shaped and therefore need focus-draw 
support on style level.". Maybe the solution is centralised (abstracted) 
system with per-style possible override?

what about new gui not working with A107? Is there A110 exe somewhere? 
I was able to get it built using Carl's git, but I somehow can't 
sync it now ....