World: r3wp

Well, if everything is factored like it is now, we can just include 
other widgets in rebgui-widgets.r as we need them.

Ashley, was it deliberate decision to remove the functions tab from 
tour.r ?

There is something nice though about making it clear in the name 
what you have, and why it is where it is.

I agree with Ashley completely in that RebGUI should remain small, 
and simple.
This seems like a way that everyone can be pretty happy.

I was going to post this in !Qtask, but it applies here too...


http://www.qtask.com/qwiki.cgi?mode=previewSynd&uuid=VXACRJTP9S31QF517PEJ1EC383QT

the request-dir function has lost the "home" button so there's no 
way of backing upwards in  a directory tree.

from where you started

the neat scroll-panel now means I can have enormously wide tab-panels 
:)

Reichart: Microsoft - "Never require users to click an object to 
determine if it is clickable. Users must be able to determine clickability 
by visual inspection alone." Hahaha :-) That one is really nice. 
It is related to AltME group chat, where I wondered, how's that clicking 
radio-button brings you to entirely new sub-screen :-)

btw - nice description of Quilt. First "screenshot" shown - it looks 
like native app, much better than what Qtask is using now. Hopefully 
it is faster ....

was it deliberate decision to remove the functions tab from tour.r

 Yes, RebDOC now covers the same ground. My goal is to pull the content 
 across from %tour.r into RebDOC and then obsolete it (%tour.r that 
 is). In RebDOC the examples will become stand-alone scripts.

RebGUI Core

 ... I like it, and it means we can distinguish general RebGUI app 
 issues from RebGUI Core issues (e.g. keyboard navigation is a core 
 issue, lack of a domain specific "bells & whistle" widget a RebGUI 
 app issue). For me the line is quite simple: if it is an issue that 
 can be fixed by creating a new widget (either from scratch or based 
 on an existing one) then it is probably an app issue; if it is an 
 issue that effects most if not all widgets and / or the fix is to 
 the RebGUI engine itself (e.g. a %rebgui-* script) then it is probably 
 a core issue.

request-dir function has lost the 

home" button" ... yep. The old request-dir function was dynamic and 
only read dirs as needed. The new one, due to the "static" nature 
of tree, pre-reads all dirs. It's also lost the "make dir" button. 
These features maybe important to us as developers, but if users 
need to navigate the entire file system or create dirs to use an 
app then the native request-file is probably a better choice. The 
[new] request-dir is really intended for the simple "which of these 
directories or sub-directories do you want to use" case, and assumes 
the developer will use the /path refinement to start in the relevant 
directory. These changes were requested by one of my clients who 
didn't want their staff "seeing stuff they shouldn't and creating 
directories everywhere".

neat scroll-panel now means I can have enormously wide tab-panels

 ... I had that in mind when I created it! Note that the horizontal 
 and vertical sliders only appear as needed and the space they occupy 
 is given back to the child widget. Also note that the button on the 
 extreme bottom right of scroll-panel toggles between "home" and "end".

RebGUI core - Agreed.

Only minus with wide tab-panels is that I have to go right to get 
to the right tab, and then scroll left to see the left hand contents 
of that tab.

Maybe we need a "reading ..." flash for the request-dir as it reads 
it's data

Also, would it feasible to include in rebgui/core a way to size check 
boxes ?  I am trying to overlay some widgets on a PNG of a PDF so 
that users can take existing PDF forms and overlay the correct widgets 
for data entry.

ie. size as rectangles or boxes

and color

this is an example http://synapse-images.s3.amazonaws.com/cms1500-1.png

I've got a couple of check boxes over the first two check boxes of 
the PNG.

I've had to do something similar and you really need pixel-level 
precision with a domain specific app (or widget). Isn't that hard 
as the number of form elements is limited. The version I was doing 
was trying to automatically place and size fields after filtering 
the form to create a B&W image (for element placement purposes). 
Another approach might be to create a widget that lets you easily 
move and size boxes, then save the face offsets and sizes and apply 
them to a RebGUI display that has the same number of widgets in the 
same order.


I'll take a look at check, led and radio-group sizing later this 
week. All these widgets *should* be able to scale without a problem 
(much like symbol does). In fact I was contemplating using webding 
symbols (for the tick and cross) in lieu of draw.

Would be cool if you think of it in terms of simply clicking inside 
the center of a printed checkbox, and the widget-checkbox simply 
scales (expands) until it hits the edges, and then some (several 
more pixels).


In theory you could do the same thing for areas where you are meant 
to fill in hand written items as well.  Basically looking at where 
the cursor was clicked, "falling" down until you hit a line, then 
expanding left and right until you hit stuff.


I designed a cool tool about 20 years ago called Snarfit that allowed 
artist to just draw where ever they wanted, and then it would grab 
everything on the page and save them out as separate objects.  It 
basically looked for blank space, and sucked up to the objects.


~ sad when we have to be compatible with printed technology.  We 
are about to undertake a huge project of making Qtask a Content Management 
system for scanned images.  I plan to make it just like Google maps, 
where the images are scalable (in chunks) and then you can draw on 
them, add tasks (as PostIts), etc.

My plan ( provisional ) was to turn the PDF into a PNG, and map the 
widgets to the PNG.  With that in mind, I know the relative displacements 
to the pdf which I would then turn into an EPS.  I can then turn 
my widget content into postscript and write that onto of the eps 
to give me perfect printouts.

I'm not sure pixed perfect is needed... just invisible widgets of 
approx the same size as the PNG background fields.

ontop of the eps...

invisible widget outlines

RebGUI/Core - Forking: I agree with you. I have talked about this 
with Cyphre too. I think developing a simple but layerable toolkit 
is the way to go. But it's hard, because there are a lot of different 
requirements coming up when doing an appplication.


I think I will provide my RebGUI fork on my web-site and try to document 
all the differences.

pixel perfect

 ... not so much perfect, but more the fact that RebGUI deals in units 
 (default of 4 pixels per unit) which probably is a bit course if 
 you're just going to use straight displays without manually setting 
 offsets and sizes.

Normaly I'm not a big forking-fan, because it wastes ressources. 
I preferr to help the mainstream distribution by contributing my 
stuff too.

Much in the spirit of the once discussed RPC (Rebol Professional 
Community). Focusing our efforts should help us all to move forward 
much faster. And since RebGUI is really a nice piece I'm more than 
commited to help it evolve.

I agree, and thanks.

Cool...Robert, will you set up the same SVN and Trac interface?

rebgui's trac/svn is being sponsored by Jaime.

He has not gotten back to me in Email of note

phone??

Hmm, I don't know that I have a "phone" number for him...I did talk 
to him on Skype, but don't see his contact now that I look...I have 
a LOT of people in my skyp

His company pages are still up http://www.whywire.net/contactUs.html

Anyway, it's only $5 a month to get an account on geekisp.com

I had one but let it lapse because I had too much trac spam.

OK, I shot an email to those addresses too.

Could always use Curecode .. which is being actively developed by 
Dockimbel

http://softinnov.org:8000/curecode/

I'm having a brain blockage .. :(

Given 

tab-panel data [
	"panel1" [ ]
	"panel2" [ ]
]
button "Change layout in panel1" [ how do I do this? ]

Ashley, a gift if you want it http://www.qtask.com/files.cgi/ForAshley?tab=get&uuid=9GDW7JPA1J8M822FQ5PD2RYC45QT&filename=For Ashley


Also, if you want any changes it should take seconds.  I did this 
because while looking at all the polished logos for Ruby I looked 
at the RegGUI logo and...well...

looks cool ...

opens as octet stream

looks good

Thanks

I looked at the RegGUI logo and...well

 ... yeah, I'm not a graphics guy and there is only so much you can 
 do with MS Comic font ;)


New one looks polished and I'd like to adopt something new for 2008 
as I plan to release Beta 3 (last one prior to a 1.0 release) soon. 
I'm open to suggestions on color (my preference is for red but I 
think that's taken by ruby :( ) ... also, I'm not sure about the 
X-Internet bit; REBOL and various RebGUI apps may be, but RebGUI 
itself isn't. Perhaps the word "Core" instead.


Let's get a few suggestions / comments in before you do another one.

I'm open in all ways.  Meaning, when you have some feedback, I will 
do up a bunch (differnt colours, etc.), use or don't use what you 
like.  It takes me just minutes to pop one out.  I have a system 
set up to make such art...

The X-Internet bit did get me thinking again about RebGUI server 
applications. Here's my basic thoughts.


We create a server-side RebGUI engine (branded as, say, "RebGUI Server") 
which accepts events other than mouse movements from a RebGUI client. 
The server is responsible for generating displays (as a face object) 
and "running" the app, whilst the client merely displays the faces 
it receives and sends events back.


Is there any value in this idea? (and, "so and so already does this 
so why bother" is a fair call).