World: r3wp

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?

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).