World: r3wp

and lot of information of what I done and how :)

for all people reading this groups tab-panel problems have been solve

Excellent Shadwolf. Glad to see things are still active and progressing 
on this. I wish I weren't so busy at the moment, and I hope the community 
will help to make RebGUI a model for future projects.

for this project I think the most important thing is the continuty 
there was so mutch widgets lib more or less evoluted that have been 
abandonned because no body was conserned by the futurs of those library 
I want to participate more but my implementations in general are 
very code consumming ;).

but I'm learning lot of things.

Alpha2 build available at: http://www.dobeash.com/files/RebGUI-020.zip

Highlights include:


 - New, unit based sizing model (see http://www.dobeash.com/it/rebgui/display.html)

 - Improved language localization (see http://www.dobeash.com/it/rebgui/locale.html)

 - New arrow, chevron, check-group, led-group, scroller, spinner and 
 drop-list widgets
	- Lots of minor fixes
	- show redefine removed
	- Use of -1 instead of 9999 to denote auto-size
	- Aesthetic improvements (use of gradients)
	- %tour.r substantially rewritten

Known issues

	- spinner and drop-list widgets need more work
	- scroller needs more work (resizeable dragger)

In progress

	- Improved tab-panel (shadwolf)
	- Menu (cyphre / shadwolf)
	- tabbing
	- field input validation (field input masks, etc)

That leaves less than half a dozen widgets to go!

	list		single column
	listview	multi-column
	treeview
	popup-menu	context menu
	status		status bar with one or more “segments”

Great stuff!! One question WRT fields uses in specification and runtime, 
for example LED-Group. Is it possible to alter the led-group content? 
Adding or removing possible entries in it? Or is this a one-time 
action when the widget initializes?

resizing system: How about a method that will store the layout if 
altered by the user and reload the GUI in the same layout? It always 
drives me nuts if I have to resize application splitter bars, panes 
etc. when starting again.

Rebgui starts to look very nicely polished (UI wise), just a bit 
WinXP-ish, but it never mind here ... maybe OSx users will complain 
later :-)

I do not remember now, if it was said that skin system will be available 
later?

beautyfull ;)

robet adding some thing to a group coud be done by append My-group-var/data 
compose [etc...] then my-group-var/init :)

Drop list seems to have some issues. Doesn't keep the selected value. 
Maybe just a demo thing.

Looking awesome though!

gregg it's just a demo thing ;)

Known issues

	- spinner and drop-list widgets need more work

would it be ok if i try to make this stuff style-compatible? so that 
it could be used both ways?

Volker sure but once you get a working code you need to submit it 
to Ashley ;)

to allow him interger it and ptimize it

optimize it ;)

I'm starting a portage of a very good list widget made by Claude 
RAMIER (cr8825) this code offer many things

sorting, text, field, image, check, info

colom rezising using mouse

returning selected mouse, enbeding non showed information

I will made maybe a merge betwin cyphre my-list and Claude table 
widgets first because Table is twice biger in code than my-list and 
second because some fonctionnality interresting in table made by 
claude.

Robert: LED-Group attributes can be changed at runtime with:

	led-handler/pane/2/data: true
	led-handler/pane/2/text: "Test"
	show led-handler


but the specification (number of LEDs and orientation) is fixed at 
specification time. I have no plans to change this.


Pekr: Most folks are familiar with WinXP, it is something to model. 
The basic RebGUI color scheme is controlled by less than a dozen 
words, and arrow / chevron / other is fully inheritable; but the 
"look" (e.g. tab shape and active shading) is hard-coded in most 
cases. So the answer is that you can easily change the cosmetic aspects 
of the UI but not the fundamentals.

Gregg: known issue.


Volker: Not sure which way you mean. If you want to contribute new 
widgets that work with both VID and RebGUI then I'll be spending 
time optimizing them for RebGUI which will break their VID compatibility. 
If you mean that you want to make the RebGUI widgets work under VID 
then feel free to do so with the widgets I have authored. For other 
widgets, please contact their author(s).

Nice.

multi-column-list: Please consider adding the auto-filter feature 
as present in Excel. This is a super-fast filter / search feature 
that can be used in most applications.

Robert hum first we will try to make it as somplete as we can ;) 
the autofill feature is neede to for drop list IMOO

so it will come but it's in my opinion a non vital feature it"s like 
the chery on to of the cake not the cake it self  hehe if you see 
what I mean ;)

Ashley: changing RebGUI and vid sothat styles are interchangeable.

IMO this complicates the RebGUI widgets unecessarly. It would be 
nice to have a wrapper for RebGUI widgets that make them VID compatible. 
But than only as a oneway. RebGUI -> VID not the other way.

a simple way could be 

1) VID -> RebGUI : a 'face widget for RebGUI, to put any prebuilded 
face (ie made by 'layout) in a display,

2) RebGUI -> VID : a 'make-face -like function to build a reusable 
RebGUI face

Auto-fill or similarly auto-filter is done fairly nicely in Carl's 
Rebodex.

Anyone made a non rectangular gui layout?

Yes, that has been done.  I've seen it somewhere but for the life 
of me I cannot recall where or who it was that built it....

have the rebgui-button working in vid (great success ;) developer/users/volker/mrg/test.r

shadwolf: posted my header-list-1 in users/volker too. yet another 
multi-col-list, maybe it helps.

Nice, I understand what you want to do now ... create a GAL (GUI 
Abstraction Layer) that enables RebGUI widgets to be used in VID 
with zero RebGUI changes. Interesting to see whether you can get 
it working the other way (VID -> RebGUI) as painlessly! ;)

i hope. after all, both create faces. thee are a few differences 
in your api (action has 2 arguments, init is function). and you have 
a resize-system. will look what i can do. at least something like 
  vid[ vid-stuff ] ; symply calls 'layout
should be doable.

btw related dialects: how about using #xywh instead of that tuple? 
then it could be easier detected on the vid-side (issue! -< resize-options)

Good idea, I'll change that in the next build.

btw is the verbose dialect by design or to keep parser short. i guess 
i could do some automatic with few lines overhead. to allow strings 
and actions without the extra brackets.

By design, to keep it as simple (and efficient) as possible. I'm 
open to a more VID-like parse-based approach as long as the complexity 
/ efficiency doesn't blow out as a result.

My old autofill is here. do http://www.rebolforces.com/reb/auto-fill.r

Thanks, I've had the code lying around for ages and was trying to 
find a link (for attribution purposes) the other day. ;)

Paul, you mean like Q ? That used windowsXP-only window transparency 
feature for the window.  Inside a rebol window I can think of a circular 
color-mapped gadget (who was it again...?)

Yes Anton.  I'm looking for a brief example - a small layout that 
shows the capability.

I remember when /view first came out it seemed there was someone 
that made a gui that was eliptical using only faces and no layout.

For VID in RebGUI, an external face widget :