World: r3wp

If the added functionality can be isolated, or perhaps made optional, 
then I'm all for more functionality.  Sophisticated applications 
need more ... but only if stability can be maintained.  I wouldn't 
want unstable but more functional widgets.

If everything is isolated, I hope that eventually even complex functionality 
can be stablised.

Yep, a lot of that code is app / context specific; although the widget 
should allow you to extend its functionality via APIs rather than 
having to "roll your own" every time you need a bit of extra functionality. 
scroll-panel is a move in that direction; "I'd like a spreadsheet 
here, and I'll put that in a scroll-panel because I want to scroll 
a large sheet; and I'll add left-click and right-click handlers to 
handle load and save; and assign a screen dump routine to F3, etc". 
All that is currently possible. "I'd like to move this cell from 
here to here" is not currently possible, and I doubt anyone could 
create an API that could let you do *everything*. (take something 
simple like alternating row colors; I had someone ask if the *number* 
of alternating colors could also be specified!)

Uploaded build#110.

1) Improved scroll-panel and tree widgets


2) Replaced request-dir with a simpler tree-based version (WARNING: 
it reads the entire tree from the path given so don't use it to browse 
a root directory)


3) Added a new heading widget (basically text at twice the font size)


4) Added prototype of new RebDOC app (still needs to be generalized, 
and the code / data that drives it still needs to be cleaned up a 
bit - but it shows the direction I'm heading with regards to "self-documenting" 
apps / code)


5) Removed a number of unmaintained widgets (due to growing incompatibilities)

BTW Robert, please don't feel any of the work you and Cyphre have 
done is wasted or unappreciated. You created a solid fork early on 
that meets your requirements. The chart widget in particular just 
blows me away whenever I see it (you should post an image of %test-chart.r 
somewhere, it's one of the most beautiful displays I've seen). Even 
though none, or only a few, of the widgets you sent me may ever make 
it into the standard distro; they have proven invaluable as a source 
of ideas, coding techniques and motivation. Many specific things 
you did (e.g. tool-tips) have slowly but steadily migrated across.

Ashley - by your aproach though, RebGUI will be first class REBOL 
gui toolkit for some time, but always second league to any normal 
toolkit. I can't agree to ANY kind of simplification, it is just 
does not deliver what normal OS user is used to. It is surely fine 
to keep simplicity and maintainability in mind, but we should be 
real - who cares if widget has 1 or 100KB? I don't, and what end 
users will judge is only comfort of usage.

What is table? Are you really serious? It is so much of a joke it 
is not even funny. And I don't care much about in-line editing, I 
never provided any such facility with any of ISes I collaborated 
on. If someone wants to edit, there is screen for that. But - grid 
without horizontal scroll? Without programtic navigation? Ability 
to hide, show columns? Come on ...

by that aproach, there is no other possibility than to fork ...

Or integrate someone else's control.

This is a GUI framework, not an app. You have to add code to a framework 
to make an app anyways - it's not any different to add other GUI 
controls. I realize that intregration is a process in itself, but 
it can be done, and sometimes it is simpler than rewriting the code 
yourself.

Sometimes the code that you integrate bears little resemblance to 
what it was before, but it still helps to have a starting point.

Petr, simplification can be a feature in projects like this.

only end user experience counts, really. RebGUI is much better than 
VID, although any REBOL based UI really lacks proper behavior (mystly 
keyboard). But discounting style like grid is imo fatal mistake. 
I have never seen any db app with such weak grid as table is ...

Im can't seem to be able to download from http://trac.geekisp.com
I have Tottoisesvn but I kep getting errors. I tried to down load 
from reb console as Ashlley described above but the file is html 
not rebol code.

strange - no problem with Tortoise here ....

svn://svn.geekisp.com/rebgui - is the correct address. All I need 
to do is to go up to see RebGUI dir, click on it, and select Update 
from right context menu in my file manager. Works here ...

If you add ?format=raw to the url Ashley gave, it is working
So just 

write %tour.r read http://trac.geekisp.com/rebgui/browser/tour.r?format=raw

Ashley;  RebDOC.r  Nice.  Way nice.

This is a philosophical dispute ... but there is nothing to stop 
Robert uploading his tree widget etc under another name to the svn, 
and we can optionally choose to use it.

Agreed, and it seems time (and a good move) to simply offer RebGUI 
Core, and RebGUI Robust, no?

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?