r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!RebGUI] A lightweight alternative to VID

Kai
19-Dec-2007
[7072]
Oops - disregard that last one -just found it
Ashley
19-Dec-2007
[7073]
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
	]
]
Pekr
19-Dec-2007
[7074]
Ashley - any news on Robert's RebGUI enhancements integration?
Kai
19-Dec-2007
[7075x2]
Is there a spot where I can store values I want to restore later 
- like user-data in VID?
per widget that is...
Ashley
19-Dec-2007
[7077x2]
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.
Kai
19-Dec-2007
[7079]
Ashley - thanks for the snippet. What would I use for buttons? Setting 
on-focus and on-click does not give usable results...
Ashley
19-Dec-2007
[7080]
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
		]
	]
]
Kai
19-Dec-2007
[7081]
Thanks!
Ashley
19-Dec-2007
[7082x3]
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.
Kai
19-Dec-2007
[7085]
awesome - any ideas when drop-lists & checks will be supported?
Ashley
20-Dec-2007
[7086]
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.
Pekr
20-Dec-2007
[7087]
is there also tree-view part of Robert's submissions? I could need 
one in few weeks :-)
Graham
20-Dec-2007
[7088]
There is already a working tree
Kai
20-Dec-2007
[7089x2]
probe btn/color
probe btn/size
probe btn/text
how come size & text return what i expect but color always returns 
none?
Ashley
20-Dec-2007
[7091]
btn/effect/draw
Kai
20-Dec-2007
[7092]
Asley ~ where do I read up on what is what in that block?
Ashley
21-Dec-2007
[7093x2]
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.
Graham
21-Dec-2007
[7095]
Go Ashley ! :)
Ashley
22-Dec-2007
[7096]
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!
Pekr
22-Dec-2007
[7097]
hehe, so cool. Will imediatelly find usage for tree-view. Now the 
grid and we have cool data manipulation capabilities .... :-)
Jean-François
22-Dec-2007
[7098]
Ashley, Is there a simple way to get this version, or do I have to 
download & install a SVN client?
Pekr
22-Dec-2007
[7099]
Probably via svn ... I just did it, rather easy - right click on 
the folder in filemanager, selecting update and it gets all downloaded 
...
Ashley
22-Dec-2007
[7100x2]
write %rebgui.r read http://trac.geekisp.com/rebgui/browser/rebgui.r
write %tour.r read http://trac.geekisp.com/rebgui/browser/tour.r
Graham
22-Dec-2007
[7102x4]
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
Ashley
23-Dec-2007
[7106x2]
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.
Graham
24-Dec-2007
[7108x4]
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.
Ashley
24-Dec-2007
[7112]
face/data has what you want.
Robert
24-Dec-2007
[7113]
Ahsley, did you took a look at my TREE widget? It's quite matured, 
so why reinvet the wheel?
Graham
24-Dec-2007
[7114]
Robert, can you post a screenshot of your tree widget.  Remember 
there's also the drop-tree widget too.
Ashley
24-Dec-2007
[7115]
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.
Robert
24-Dec-2007
[7116x2]
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.
Graham
24-Dec-2007
[7118x2]
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.
Ashley
24-Dec-2007
[7120x2]
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)