World: r3wp

Ashley, Is there a simple way to get this version, or do I have to 
download & install a SVN client?

Probably via svn ... I just did it, rather easy - right click on 
the folder in filemanager, selecting update and it gets all downloaded 
...

write %rebgui.r read http://trac.geekisp.com/rebgui/browser/rebgui.r

write %tour.r read http://trac.geekisp.com/rebgui/browser/tour.r

Print support - how about a button that will turn the face/parent-face 
into a PNG, save to drive and invoke the browser on it?

this is for rebgui screens .. or perhaps better still, a way to capture 
the shift-print scr on any rebgui window

Ashley, I read that request-dir uses the new tree-view, but when 
I tried it out on a few checkout, and clicked on the "Home" button, 
rebgui froze on me. Reproducibly.

new checkout

Ah, I had to revert request-dir but forgot to revert read-dir in 
%rebgui-functions.r ... will fix this later tonight.


re: Print support ... I'll look at adding a handler that you can 
assign to an FKey of your choice.

Uploaded build#109 with above fix. Handler is as simple as:

ctx-rebgui/on-fkey/f3: make function! [face event] [
	save/png %screen.png to image! face
	browse %screen.png
]


Just click on the window you wish to print and press F3. I'll add 
this as a cookbook entry.

Just wondering if the tree might return more information than just 
the face text. Say you want to retrieve stuff from a database but 
only want to do so if it is a level below a node.  At present you 
don't know if you're at a node of a leaf.

or a leaf.

So, you have to traverse the data of the widget to find out where 
you are .. and if a node and leaf both have the same name ... then 
you're stuck.

Similar sorts of problems occur if you want users to be able to add 
to the tree.

face/data has what you want.

Ahsley, did you took a look at my TREE widget? It's quite matured, 
so why reinvet the wheel?

Robert, can you post a screenshot of your tree widget.  Remember 
there's also the drop-tree widget too.

Robert, yes. Your tree-view widget is a superset of what I need / 
want (and is 21Kb vs my 3Kb).


Ideally, I'd like every widget to be 5kb or under, with 10kb a max. 
After developing and merging over 40 widgets I've come to the following 
conclusions:

1) 90% of the basic usage cases can be coded in under 5kb
2) Double the code size to increase this to 95%
3) Quadruple this size to get it to 99%

4) Time required to maintain / fix and document a widget increases 
exponentially as code size increases

5) A widget that tries to do many things is no longer a widget ... 
it is an app (list-view and grid fall into this category)

6) While developing the sheet and tree widgets I came to the realization 
that the scroller logic could be externalized in another widget (scroll-panel) 
thus removing much of the duplicated scroller handing code found 
in a number of widgets


Where does this leave grid? Near as I can figure it's a combination 
of table and sheet, but supporting cell types other than plain old 
field. I can see how folks want to pull data from a DB and put it 
into a grid, so does that mean we have 'typed' columns or can every 
cell be different. If the later, then aren't we just talking about 
a sheet with support for more datatypes?


And now for the accessors. We obviously want functions to load and 
save data, put and get cells, and add / delete rows; but do we really 
need functions to move columns around? Or hide and reveal columns? 
It's very easy (and tempting) to over-engineer ... but keeping things 
as simple as possible (but no simpler) makes for a stable system 
that is easily fixed, extended, maintained and documented.

I see your point and I totally agree. On the other hand doing a real-life 
full-fledged application requires most of the time more than just 
a basic widget.


What I found out is, that most simple widgets are ok from a GUI POV 
but not in these areas:
- storing / saving widget state and user-data

- be programmatically controlable (like setting a tree to a specific 
state, hiding stuff, setting sort-oder etc.)

- implement always returning usage patterns in a more programmer 
convinient way

- using a common approach for specification (nested blocks, key/value 
pairs etc.)

And those things make widgets quite big. I would bet that for complex 
widgets 75% of the code is not GUI related.

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".