World: r3wp

Not soon. This is a hack to support common editable widgets, whereas 
a proper solution should support every widget that is editable *and* 
selectable (e.g. tab-panel, table, drop-list, check, radio-group, 
etc). It means adding 'info support to a lot of widgets that currently 
do not have it.

is there also tree-view part of Robert's submissions? I could need 
one in few weeks :-)

There is already a working tree

probe btn/color
probe btn/size
probe btn/text

how come size & text return what i expect but color always returns 
none?

btn/effect/draw

Asley ~ where do I read up on what is what in that block?

http://www.rebol.com/docs/draw-ref.html

Uploaded build#107 with new tree widget:

USAGE:
	tree data ["Pets" ["Cat" "Dog"] "Numbers" [1 2 3]]

DESCRIPTION:
	Values arranged in a collapsible hierarchy.

OPTIONS:
	'expand starts with all nodes expanded


It's very basic, can only handle a couple hundred entries, and still 
has some UI quirks ... but it works and is only 3Kb.

Go Ashley ! :)

Uploaded build#108.

1) Fixed UI quirks with tree widget

2) Renamed vid widget to style

3) Added a new scroll-panel widget

	USAGE:
		scroll-panel data [calendar]
		scroll-panel data [field field]

	DESCRIPTION:
		A panel used to group widgets within a scrollable container.

4) Added a new sheet widget

	USAGE:
		sheet
		sheet options [size 3x3 width 2]
		sheet data [A1 1 A2 2 A3 "=A1 + A2"]

	DESCRIPTION:

  Simple spreadsheet, based on rebocalc.r, with formulas calculated 
  left to right, top to bottom.

  A cell is either a scalar value, string, or a formula starting with 
  "=".

  Scalar values are automatically right-justified, series values left-justified.

  Remember to put spaces between each item in a formula and use () 
  where needed.

	OPTIONS:
		'size specifies number of columns and rows
		'width specifies cell width in relation to cell height


5) Updated %tour.r to incorporate examples of tree (List), scroll-panel 
(Grouping) and sheet (List) usage.

Enjoy!

hehe, so cool. Will imediatelly find usage for tree-view. Now the 
grid and we have cool data manipulation capabilities .... :-)

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.