World: r3wp

Yeah, that's more like it.  But it can be used to provide simple, 
clean OS independant applications too...

where does Glyout/Steel/Liquid thingy stands in comparison?

GL goes for a more dynamic approach while maintaining performance. 
 Did you see Maxim's rework of a multi-column scroll list?  Fast, 
very fast.

Vincent: rate suggestion ... done (overlooked in 0.1.3)

Robert: Will the splitter be integrated into the next release? ... 
Yes

Pekr: "I want full OS compliancy in behavior" ... which OS and what 
skin?

Ammon: "RebGUI is ..." ... spot on, and I like that sentence so much 
I'll add it in some shape or form to the main page ;)

Ashley - it was long discussion at some stage of View 1.3 project, 
but shortly - my opinion is, that we don't need to skin anything. 
IMO it is good and vital, if we are distinguishable, so ppl can say 
- it is that colorfull app, Rebol :-) What I have in mind by OS compliancy, 
is behavior, so mainly keyboard handler, but also mouse reactions 
etc.

Romano did nice job with keyboard handler, but e.g. - because of 
no rich-text ability, we are not able to display accelerator key 
(underlined char). VID styles also are not ready yet, to visually 
distinguish it has focus or not ...

Proper and OS compliant behavior is imo MUCH more important, then 
skin ...

pekr sure this will come in time but in a 0.1.3 version I don't think 
this is actually the priority ...

first we have to make the  set of widgets then tune them IMHO

a little correction to 'progress (didn't count the 'edge size and 
0x0 origin in draw):

face/effect/draw/box: to pair! reduce [

    to integer! face/size/x - 3 * face/data: min 1 max 0 face/data face/size/y 
    - 3
]

a one-face horizontal slider prototype :

hslider: make face [
    size: 200x20
    data: 0.0

    effect: [draw [pen 48.48.48 fill-pen 192.192.192 box 1x0 10x17]]
    feel: make feel [
        redraw: function [face act pos][delta][
            if act = 'show [
                face/effect/draw/7/y: face/size/y - 3

                delta: 5 + to-integer face/size/x - 12 * min 1.0 max 0.0 face/data
                face/effect/draw/6/x: delta - 5
                face/effect/draw/7/x: delta + 4
            ]
        ]
    ]
    init: does [
        feel/engage: func [face act event][
            if find [move down] event/type [

                face/data: min 1.0 max 0.0 event/offset/x / face/size/x
                show face
                face/action face
            ]
        ]
    ]
]

shadwolf - that can be mistake. You have to keep those things in 
mind at least, as e.g. adding visual representation of focus may 
require different kind of measures of borders of widgets etc. (depends 
upon how you choose to represent it)

for 'hslider

- 'init is used to allow 'action in definition, as with 'action feel/engage 
is modified
- must be tuned and modified according to futur specifications

- usage example, in %example-misc.r, you can test it adding "hslider 
[size 200x20 data 0.75 action [p/data: face/data show p]]"
- for a 'vslider, same code with all x and y swapped

Pekr: visual focus like which OS? It isn't the same on Windows 95->2k 
and Windows XP, and there are other OS. Mouse reactions changes a 
lot between OS too.

a little set of existing controls makes it easier to discuss common 
behaviour. but it's important to discuss it as soon as we can.

Vincent - right. That means, we have to adapt to OS we run on ....

more complex widgets shouldn't be done until we have a more detailled 
specification about global look and feel (colors, text size, ...)

... or ppl will feel hostily about your app .... they can imo forgive 
different look, but not different behaviour .... that is my experience 
... even one slight difference can make ppl annoyed ...

Pekr: that's mean we need different versions of each widget?

why not totally different look and behaviour - the nearly same is 
annoying, the different is... different

Pekr that's right but I think that"s a second stage of consern first 
we have to make those common widget we have to make them speedy then 
we culd let spent some cpu calc to look & feel  purpose ;)

OK, I read it is a community project - what is the concrete plan, 
if any?

For VID 1.3, the spec was to be close to XP while maintaining open-endedness 
for custom and legacy projects (Surfnet Detective is imo an XP-alike 
that 1.3 may have ended up as).  As RebGUI is more focussed (and 
streamlined) than VID, I would recommend working toward a neutral 
style optimised for the kind of UIs that RebGUI is designed for.

Pekr: "What is the concrete plan, if any?" ... shadwolf was on the 
mark.

1) Create a set of base widgets with the desired *functionality*
2) Select a look & feel to approximate
3) Apply this look & feel *consistently* to all base widgets


Vincent is correct when he says we should discuss this sooner than 
later as look & feel can effect how a particular widget is implemented. 
As an example, a 'button widget trying to mimic WinXP might use multiple 
images and / or effects to mimic the various states a WinXP button 
can be in; while a minimalistic approach might just make use of 'edge 
and 'effect to toggle between several states.


I'm leaning towards a minimalistic yet modern look & feel (perhaps 
even PDA-like) so put any useful links / comments / opinions / designs 
here for folks to look at. Here's one to get the ball rolling: http://projects.o-hand.com/matchbox/screenshots.html

Pekr and every one have to understand that starting a sutch project 
from scratch (white page) is a true challenge.In french scene we 
have an example of a heavy skinnable widgets library that became 
deprecated because several reason in witch there is no one to take 
in charge the continuity of the lib and that's pretty difficult to 
make a relevent work while we don't know what could be the VID futures. 
This library is interdependent of VID so while we don't know how 
Carl plan to extend it in futur it's hard to make up plans to maintain 
it.  The name of this lib is libskins v3 witch was made by Etienne 
Alaurent.. What I want for RebGUI  is that every one can participate 
on it apporting  he's hown ideas to it but conserving the main project 
lines. I think Ashley is totally in this mood and try yet to make 
documentation around RebGUI concepts. In futur one posible idea to 
simplify the documentation elaboration could be to use the rebol 
french scene douwiki.Every people that creates a modification significant 
to RebGUI would write the related documentation directly to the dokuwiki 
this way the documentation task that had to make Ashley would be 
lighter. Ithink as Ashley have the "code vision" he must take in 
charge the code merging and releasing (that's yet what he do actually 
;) ). If we want RebGUI to be maintained and constently adapted we 
must  work as a team. This allow us to have more knowlege and more 
inovent ideas in the topic ;)

Latest release available at: http://www.dobeash.com/files/RebGUI-014.zip

Highlights include:

	- Several new widgets (15 in total now)
	- A simple WinXP-like look (not final, just something to model)
	- New %tour.r script to view all widgets in action
	- ESC to return to the console (for Graham)
	- Numerous minor improvements and fixes
	- Documentation update (the Display User's Guide in particular)

thanks Ashley :)

.. %tour.r quits on closing the window :(

you guys are making phenomenal advances.

Looking forward to the list widget.

re: quit ... have you tried just pressing the ESC key? (if that fails, 
what REBOL version are you using?)

well, I could use esc key in any of the previous versions .. I am 
talking about closing the window using the close gadget

It's not a biggie.. but like Anton, some of us use the console preferentially.

When you resize the tabbed view to a smaller size, I notice that 
the window obscures tabs to the right.  Can you put an arrow widget 
to scroll the tabs across ?

Cyphre has that feature in his tabbed view widget.

wonderfull work !!!! 0.1.4 version is beautyfull ;)

yes, I can confirm that closing window does not return back to console, 
but quits rebol ...

0.1.4 demo is cool! Reminds me of those tiny drawed embedded environments 
:-)

Ashley I have a good idea to submit you conserning widget positionning 
http://rebol.dev.fr/view.php?sid=72

instead of using offset to set the position of a widget we use north 
south east west container ;)

I don't like cardinals point in UI. I prefer top/bottom/right/left

names doesn't matters ... that the system witch is interresting ;)

Interesting, and I'm certainly open to new ways of doing things ... 
but two marks against it for me are:

	1) It's overly complex [for RebGUI]
	2) I tend to design like I write - left to right, top to bottom

Nice concept though.

offset is still needed for precise effect but using this kind of 
organisation that is more powerfull than below accross  we ca  make 
quite and easy beatifull graphic interface

you can start be texting the contribution code I submit you then 
try to find a relevent way to adapt it to rebgui  ;)

in a 'tab-panel, auto-resizing don't work

it's managed at window level, so faces in a face/pane aren't affected 
by resizing. it will be a problem with all container widgets. the 
resizing should be modified to recurse into pane faces and blocks.

Latest release available at: http://www.dobeash.com/files/RebGUI-015.zip

Highlights include:

	- New LED widget
	- Tweaked check, splitter and tab-panel widgets
	- Basic edit feel added to area and field widgets
	- Resizing is now fully recursive
	- Added a light-weight request-file function for Win32/SDK use
	- Numerous minor improvements and fixes
	- Documentation update (the Display User's Guide in particular)