World: r3wp

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

Pekr, and all I'm saying is that the irreguarly shaped styles drawing 
can be solved with access to the face click mask, that either is 
or hopefully will be implemented by Cyphre. Therefore I find it pointless 
to work on a per-style solution.

I'd like to differnitate two things - focus "subsystem"  - that's 
already implemented at R3GUI level and actual focus draw - that's 
better to be solved at style level but the system may provide general 
focus mechanism for retrangular shapes.

A110:

http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

thanks ..

Henrik, the per-style solution are two or three lines in draw block 
and one line in on-focus that changes color, that's all (and that 
on-focus is same for all button based styles).

that's all

 - and then you have to change it per new style and every time you 
 change a box rounding, etc.

and for cases where you use a highly irregular bitmap, you will have 
to use some kind of mask anyway.

Actually, when it's in-style, you do not have to take care of box 
model - that's problem only with universal solution.

does it currently fallback to a simple frame, if no highlight option 
is available?

I'm still just talking about visual representation of focus, nothing 
else. Catching focus should definitely be done on system level, I 
agree.

does it currently fallback to a simple frame

 - It should, but border seems problematic somehow. I'm working on 
 the gob mask, you were talking about, it's just not finished yet.

Simple frame: OK.

Catching focus, yes, we agree.


Visual: I still think the visual representation could be done automatically. 
The ancient Deluxe Paint III on my old Amiga could do the same with 
brushes, in that it would draw a single-pixel wide line around the 
bitmap. Do that a few times with fading colors and you have the look. 
If they could do that 20 years ago on a simple 68k machine, we surely 
can do the same today in REBOL3, if we have the clickmask and perform 
a simple blur on it.

Ah, ok I understand the mechanism you've got in mind. But implementing 
this would take more time than I spent implementing focus in-styles. 
But this would be nice to have, I agree.

a small glitch with style browser - I do mouse over of preview tab, 
it crashes. In console I do unview none, but consecutive start of 
style browser fails. Ditto when I try to re-do r3-gui.r3

mouse wheel scrolling works only upon the scroller of list. It should 
imo work even when upon the list itself ....

Mouse over on tab-button opens tooltip with preview that's done using 
to image! I saw some problem ssolie had here some time sooner and 
to image! was in the error description. I wonder if you've got latest 
R3, I had preview disabled in previous versions because to image! 
was causing crashes.

mouse wheel scrolling works only upon the scroller of list
 - bug, I'll fix it.

This is what I get for mouse-over upon the preview tab - it displays 
the preview and crashes with:

** Script error: tooltip: needs a value

** Where: either if function! all do-style either if either do-event 
do-event ei

ther -apply- wake-up loop -apply- wait do-events catch either either 
-apply- do
** Near: either arg [
    buttons: compound-face? face
    tab-box: c...

Pekr, if you've got some time to help, please, have a look at keyboard 
nav and post any problem you find to me personally to not polute 
this channel. This will help very much.

ok

Dunno if it would be good concept (it might be confusing for user), 
but some time ago I was thinking about nested tab system. What I 
mean is - most of tabbing systems do work in a flat way. It is kind 
of primitive. But - sometimes you might want to use the same navigational 
keys for more complex styles, typically subpanels, grids.


What we recently got (and can be seen with e.g. style browser) is, 
that e.g. tab panel can be tabbed. Then arrow keys do switch between 
tabs. What I had in mind was to be able to press enter, to nest the 
tabbing, so that you "enter" the subpanel, and esc to escape back 
to the upper level (this part might be tricky for users, not sure 
about it - they might feel being locked inside of some style).

Any ideas?

Recently we use tab  key .... maybe it is good enough, I don't know 
- first tab tabs to the subpanel, next tab tabs to its first element. 
When at least subpanel tabbably position, next tab moves to next 
style ...

btw - will there be added visual representation to field tabbing 
too? It feels a bit inconsistent the way it is ....