World: r3wp

I think it's preferable to have some type of visual clue that the 
behaviour has changed.

The code that determines true/false focus could also change the color 
perhaps.  But on-focus does not write-protect the contents from code 
re the "content manipulation' part, so you'd need to write a modifier 
layer (and promise yourself to not use direct  access ... ever) that 
also honoured the focus flag.


Being me, I probably didn't think up and down the affect chain, but 
I use the on-focus for user entered key fields.  Once set and verified 
ok you can't enter the field anymore (with the background color change). 
 I played with on-unfocus locking but found the behaviour of getting 
stuck in a field as too irritating so that logic had to move to become 
an extra step in another func.


Umm, not a dis or anything Ashley;  on-unfocus is just one of those 
features I'd need a strong reason to include in a user interface 
- nice that it is there and all.  :)

Brian ~ do you have a snippet for me demonstrating how you do things?

How can I determine the type of a widget (i.e. field vs button) in 
code? I don't see a 'kind or 'type attribute...

Oops - disregard that last one -just found it

This code shows how to implement dynamic 'info for 'field and 'area:

display "" [
	a: field
	b: field
	button [
		alter b/options 'info
		b/color: either find b/options 'info [
			b/action: make b/action [
				on-focus: make function! [face] [false]
			]
			ctx-rebgui/colors/widget
		][
			b/action: make b/action [
				on-focus: make function! [face] [true]
			]
			ctx-rebgui/colors/edit
		]
		show b
	]
]

Ashley - any news on Robert's RebGUI enhancements integration?

Is there a spot where I can store values I want to restore later 
- like user-data in VID?

per widget that is...

widget/init ... which is set to none! after the widget is displayed 
and is not referenced again.

grid integration ... perhaps over Xmas; all depends how easy it is.

Ashley - thanks for the snippet. What would I use for buttons? Setting 
on-focus and on-click does not give usable results...

display "" [
	a: button [print "a"]
	b: button [print "b"]
	button [
		alter b/options 'info
		either find b/options 'info [
			show b
		][
			b/feel/over b false 0x0
		]
	]
]

Thanks!

Uploaded build#106 with new set-state function:

USAGE:
    SET-STATE face /info /edit

DESCRIPTION:
     Toggle and show widget state.
     SET-STATE is a function value.

ARGUMENTS:
     face -- (Type: object)

REFINEMENTS:
     /info -- Exit if already info.
     /edit -- Exit if already edit.

Used like this:

display "" [
	field
	f: field
	button [set-state f]
]

Only works with:

	area
	field
	edit-list
	button

widgets at this time.

awesome - any ideas when drop-lists & checks will be supported?

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.