World: r3wp

great artist are poor but so prolific ;) and so revolutionnary ;)

I am hoping that when REBOL/Coop goes online, we will have a good 
way to deal with these issues.  We will be posting a lot of REBOL 
code (and C code too) for developers who feel that they can make 
them better in various ways that are most important to them.  In 
other words, if Pekr wants the REBOL console to scroll better, then 
he will have access to make that happen.

Shadwolf - what you say is very true.

I'm certain this will start a newer trade impact and even attrack 
those borring people that do all the day clic and sell apps ;)

making art deals with beauty not with capitalism :) But sure in this 
materialist word if you can sell your art at a good price it's even 
better but that's not the main purpose ;)

Yes, I hope so.  I also hope that it helps us from losing so much 
code that people come up with. I remember so many good enhancements 
that have been made for REBOL that over the years get lost somewhere 
on the network.... on servers that are long gone.

Carl me too that's why I'm support REbGUI and I was claiming for 
a such ambisious project since many time ;)

instead of carring in our hown corner our little tasks it's better 
to try  to merge our knowledge that's not new GNU and other free 
software projet/foundation are doing it yet (like blender what amazing 
software ... think of it it is a very hudge project and ambisous 
(it's using PYTHON API to make script what could be done using rebol 
in blender 3D renderer software for scripting ??? ))

Blender ambition is to be better than dynosors like maya and 3DSMAX 
supported by billions of dollars ...

REbGUI has a simplicity in it that most of other intens doesn't have 
that's a good point to hope for futur  improvements ;)

being simple is not only a better CPU usage but it offers too some 
rest and easy path to our totured brains ;)

My formation is around 3D gaming from design to realization so I 
know what brain torture is ;)

can't wait to start shipping glass... ;-)

Maxim, how about using RebGUI as a base? Or are you already looking 
into this?

Carl, I don't want better scrolling for console, but better keyboard 
navigation - ctrl arrow for skipping words, ctrl shift for hilighting 
...

Chris and I did some work on an ARROW style some time back. We'd 
like to offer it up if RebGUI can use it.

sure we need it for dropdown ;)

How should we submit it?

hum depending on the size if it's low sized you can put it on rebol.org 
with a comment and naming it ARROW4REBGUI.R for axample

I'll need to look at dust it off a bit I think. If you don't see 
it, via mail or on REBOL.org, in the next few days, please ping me 
on it.

I'm working on dropdown adaptation to REbGUI  so send it to me

I give you in private my direct mail

I can get it from here. Will send it shortly.

Chris noticed that under AGG things are a bit blurred since we use 
draw commands.

Check and Radio-Group? AGG looks better for these than the pre-AGG 
pixelated look. The lines have more definition and weight IMHO. Can't 
see any difference with Tab-Panel and Button.

Looking forward to that arrow style once its been dusted off; please 
post the URL here once it's up.

gregg recived arrow script

Asley if you want to have a look to it it's here (no adapted to RebGUI 
yet ;) maybe tomorrow or sunday comming with a dropdown first implementation 
at the same time if I have enought time ;) ): http://shadwolf.free.fr/arrow-RebGUI.r

your arrows are pretty shinny ;)

it's totally what we need

I will see how to port them well I yet look to the code it's seems 
to be adaptable easyly ;)

more news on sunday nigt (paris time ;))

Ashley, simple question.  Is the display/min-size expected to always 
open atleast the size of min-size.  I noticed it does not, however, 
when you attempt to resize the window, it will not allow resize smaller 
than min-size.  See example 2.1.2 in your RebGui Display guide.

Min-size limits the OS window size on resize only, the documentation 
will be updated to make this clearer (note that the OS window size 
includes an unknown number [to REBOL/View at least] of border / title 
pixels that varies by OS / Window style).

when is 018 due out?

I work a some time on the porting of arrow widgets  basing me on 
gregg submition ;)  you can find it there: http://shadwolf.Free.fr/arrow-RebGUI-port.r
some work must be done ;) but I think Ashley could understand more 
than me what is needed ;)

i like pretty mutch the idea of gregg's arrow to offor thru glyph 
var the variation of the design of the arrow allowing us to make 
simple to sofisticate I like very mutch this vision ;)

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

Highlights include:

	- New pwd-field widget
	- Updated tab-panel & radio-group widgets
	- Timer widget removed
	- Added Ctrl+Left & Ctrl+Right (word left / right) to edit feel
	- Display User's Guide updated to reflect previous changes
	- Menu widget and tabbing deferred until 0.1.9


Note that face edge, font, para and feel now default to none. Use 
default-* objects if your widgets need these attributes (this brings 
these attributes in line with the RebGUI philosophy of "absent unless 
specified"; and removes all the attribute: none assignments).

Ashley, it would be really interesting to learn why you decided to 
write RebGUI and how you went about doing it. It would make a great 
article for Rebol.org.

I think you can find some elements on it in the very first message 
of this topic ;)

Thanks. I've increased the message limit so that I can see the start 
of the group. I will start reading from the top.

It would still be great to read a short article from Ashley.

My post of 2-Mar-2005 in the View group which kicked things off:


Which leads (sort of) to my next question. Does anyone think it is 
worth developing a simple, high-performance, low-memory GUI alternative 
to VID? The aim would be to have it built on View from the ground 
up such that you could (for example) use enface / rebface (or equivalent) 
without needing %view.r (and the over 120 KB of mezz it pulls in). 
If there's sufficient interest I'll document and release the Alpha 
implementation I have.


I'll jot down a few notes for an article before I forget too many 
of my streams of thought. ;)

nb. Shadwolf: as our Arrow style was pre-AGG, glyph rendering does 
not take advantage of the newer draw commands.  Therefore, it may 
be possible to reduce or eliminate calculations used in 'compose-arrow.

OT: the problem with AGG AA on smaller glyphs (not just arrow) is 
that it tends to have an adverse effect on glyph weight.  'course 
it beats bitmaps when it comes to scaling, but even pre-AA Draw gave 
more precise control -- hence the deterioration of the Arrow glyph 
post-AGG.  Illustrated here: http://www.ross-gill.com/r/chevron-test.png

Btw, if they are any use, I still have some UI design guides online: 
http://www.ross-gill.com/r/guides.html

Chris: i think that your example above turned out being a bug in 
gamma handling in earlier versions of view/agg. i'm not sure if it's 
the same on the latest version (especially if you adjust gamma properly 
for your monitor - the default should be ok for crt monitors i think)

UI design guidelines: thanks Chris, I was trying to find those the 
other day. I'll add that link to the RebGUI Widget Designer's Guide.

Just noticed some cursor placement issues with the new pwd-field 
widget. Add these two lines to fix:

	font:	make default-font [name: font-fixed space: 2x0]
	para:	make default-para [origin: 5x2]

Have you been following what Ashley has been doing with RebGUI ?