World: r3wp

Allen, auto-fill: sure, but is there something wrong with it ?

Latest build available at: http://www.dobeash.com/files/RebGUI-031.zip


*** Unzip this file into your existing RebGUI 0.3.0 distribution. 
Requires View 1.3. ***

Highlights include:


 - Replaced scroller & slider widgets with Anton's new combined slider
	- Updated widgets to use same and set dragger size
	- Tab-panel now accepts actions (to enable dynamic tab displays)
	- Improved text-list selection logic
	- Prototype request-dir function added (needs a lot more work)
	- Large number of bug fixes
	- http://www.dobeash.com/it/rebgui/display.htmlupdated

Known issues:

	Unchanged.

On the drawing board

	Unchanged.

where's the tour.r file?

Unzip into your existing rebgui 0.3.0 installation.

ok, now it exists :-) ashley, language seems easy, so I'm gonna write 
a Danish language file for you

posted to you privately

** Script Error: scroller has no value
** Where: display
** Near: attribute-color: get arg
>>


This is all I get when I start 031 after installing it on top of 
030...

SCROLLER has not been defined in the lastest rebgui-widgets.r

I get the same error.  A quick hack is to add this before the last 
line in rebgui-widgets.r:

; hacked in by Anton
	scroller: make slider [data: [arrows]]

Having done that, though, I see weird scroller behaviour - bugs I 
should say, with the operation of the scrollers in the tour.

Maybe it's something to do with being inside a tab panel. I will 
investigate.

Anton - even with your line it does not work ...

There is also a problem with   slider-face/color: colors/widget  
 which is the same as tab-panel's background color. I tend to think 
that is an inherent problem with tab-panel, it being a container 
for other widgets.

Pekr, it works for me - what's the error you get?

(note: the last line is the last end square bracket ]  )

Slider bug fixed.
This is the patch:
	;;offset: event/offset - either action = 'time [face/offset][0]

 offset: event/offset - either action = 'time [win-offset? face][0]

I must say it's very cool to be able to use functions like win-offset? 
without worrying about backward compatibility :-)

how to apply that? Still does not work ...

wouldn't it be better to re-release instead of adding xy lines here? 
:-)

>>  scroller: make slider [data: [arrows]]
** Script Error: slider has no value
** Where: halt-view
** Near: scroller: make slider [data: [arrows]]

Anton: backward comptability wasn't  the only problem - VID functions 
aren't used to allows /Face (SDK) compatibility without VID components.

ok, finally got it working ...

Vincent, you're right.  Happily, the Widget Designer's Guide says 
I am allowed to use win-offset?  :)

good :)

If you didn't mention that I would not have checked, though.. :)

site: http://www.lexicon.net/antonr/rebol/
load-thru/check site/rebgui/slider.r 1.0.6
do site/rebgui/demo-slider.r

Sorry guys, my fault for the confusion as I forgot to include the 
modified %tour.r. I've refreshed the zip with a "b" suffix to avoid 
any caching issues, and added Anton's fix as above:

	http://www.dobeash.com/files/RebGUI-031b.zip

We forgive you ;)

Well at least I forgive you ;)

the images directory is missing ...

In teh readme.txt it could be usefull to make some text about your 
web site; You can find illustration about how to use rengu in tour.r 
file and you can refeer to http://www.dobeash.com/reguifor complete 
and detailled documentation. You can contact me directly for any 
suggestion bugreport improvement in AlteME REBOL3

rengu mean rebgui  I don't know why I have some problems to tip text 
today :)

Done. Correct link is: http://www.dobeash.com/it/rebgui/

Geat the thing is that people will use it in a test mean then have 
readme.txt and found lot tips to where to find more documentation 
and samples

like the initial intro. on what rebgui is..as oppose to 'why NOT 
VID'

a very clear focus of rebgui purpose

I think that's more a joke than a real lite motiv ....

RebGUI intents to extant and embeter VID but it's obviously a layer 
over VID ;)

I can CTRL+A and CTRL+C to get password field.

So, although the actions are happening, the visual feedback is not 
ie. the password field does not highlight

it does not highlight but it should not let me to copy password

Just wondering whether the tab in a tab panel should perform it's 
associated action each time it is clicked as opposed to the current 
behaviour.

In this way, it differs from the action of a button.

But it does perform its action each time it is clicked ... *unless* 
it is already "active" (i.e. we ignore clicks on the currently active 
tab). If the intent / desire is to have a "refresh" type ability 
then specifying a button for that tab (which calls the action) is 
probably the better way to go.

I'm not sure of that.

the only reason to click again on an active tab would be to refresh 
the panel.

presumably there is code there that checks to see if the tab is active, 
and disallows the action.

ie. ordinarily, the programmer is trying to save a few cpu cycles 
by doing nothing when the user clicks again on the current tab.  
But if the tab already has an active action associated with it, might 
as execute it. Otherwise, the programmer has to use up valuable display 
space by adding another button, or the user has to click on another 
tab, just so that they can click on the first tab they originally 
wanted to click upon.

You're forgetting the, "Oops, I didn't mean to click that again / 
twice" factor. ;) Also, how often [in windows] does clicking an active 
tab refresh it's contents? I can't think of any off-hand. I'm not 
saying it's a bad idea, just how familiar would most folks be with 
it.

A simple image-based button replacement. Thoughts?