World: r3wp

Wow, RebGUI really picked up speed again. I'm still not biting the 
bullet to backport my fork of RebGUI.

But it looks like the current version of RebGUI is highly matured.

how to replace append-widget funcionality?
 ... make your own custom distribution in three easy steps:

1. Put your new widget in the widgets directory
2. Add it to %rebgui-widgets.r as an #include
3. Run %create-distribution.r

The append-widget function relied on extending the widgets object 
... which isn't really supported under REBOL2.

just that I was able to find 1px difference on our company website 
- 14 vs 15 pixel in one paragraph

 NP, I've actually been using DigitalColor Meter on my Mac to find 
 both pixel and RGB discrepancies ... so when you see something like 
 "pad 0x-1" in request-edit you now know its because I wanted to collapse 
 two 1 pixel edge borders into a single shared 1 pixel border. As 
 I mentioned elsewhere, its attention to trivial aesthetic details 
 like this that make the overall UI "look good".

I only get the 'load-stock error using the latest rebgui.r

 & "rebgui.r is doing something funny to VID" ... yes, it sure is. 
 The guilty lines of code are in %ctx-rebgui.r:

	view*: system/view
	screen*: view*/screen-face

 screen*/color: screen*/edge: screen*/font: screen*/para: screen*/feel: 
 none
	view*/VID:
	view*/popface-feel:
	view*/popface-feel-nobtn:
	view*/popface-feel-away:
	view*/popface-feel-away-nobtn:
	view*/popface-feel-win:
	view*/popface-feel-win-nobtn:
	view*/popface-feel-win-away:
	view*/popface-feel-win-away-nobtn: none


There's a long explanation for this, but the short explanation is 
that previously RebGUI could co-exist with VID (and I was careful 
not to redefine existing VID words/functions), this made sense so 
long as RebGUI shared some of the same basic View/VID mezz code (in 
particular the popface-feel-* functions, hide-popup and show-popup). 
Once RebGUI v2 went down the path of using its own, simpler, popface 
code then the need to maintain "Chinese walls" between VID and RebGUI 
lessened ... and the option to reuse/redefine View's basic objects 
(instead of creating parallel RebGUI objects) made sense. Once I'd 
made the decision to cut with VID support it made other decisions 
like redefining standard VID requestors (alert, confirm, etc) a lot 
easier. RebGUI can now be developed without worrying about VID compatibility 
or "breaking" VID.

Any suggestions for a replacement for the VID toggle?

 ... isn't the toggle just a drop-list less the drop component? It's 
 a fairly trivial widget to add to RebGUI, but it's not a widget I've 
 seen in any Windows or Mac apps. What do folks think about this widget 
 from a UI POV?

I'm sure I've seen buttons that change their appearance ... to indicate 
two different states.

I use them in a forever loop so that the user can start or stop  
People also use them for playing movies ... it changes from a start 
to a pause button.

Shame about breaking vid compatibility .. there were somethings I 
could not do in rebgui so I would switch to using ViD in the same 
application.

For instance I use VID to do a print preview ... using a draw dialect. 
 Never tried it with rebgui

Yep, windows media player has a play button that toggles to a pause 
button.

hence no further ability to mix VID with RebGUI
 ... correct.
promise of 

much lower" memory requirements, but the opposite is true" ... not 
quite. A lot has been added, in particular 4 inline images, without 
noticeably increasing memory. Also remember that many of the improvements 
(reduced dependency on View/VID mezz code) will only be apparent 
when using RebGUI with enface/rebface (tour.r uses 13,817Kb under 
rebview here, and 11,223Kb under rebface). Lastly, reduced memory 
usage is not apparent with tour.r as it doesn't reuse a lot of the 
same widgets (i.e. tour.r is a good reflection of "base" memory usage 
not runtime memory usage). If I find the time I'll knock up an example 
that demonstrate runtime memory differences.

looks like the current version of RebGUI is highly matured

 ... thanks, I hope to have an "official" release with updated docs 
 by the end of September.

THAT is very cool news.

And toggle?

I'd like to see an option to use a vertical layout for request-value

Enter the url for your website here. It looks like this http://www.rebol.com/
 [ .......]
is a pretty long requester.

there were somethings I could not do in rebgui so I would switch 
to using ViD in the same application

 ... there shouldn't be any. Both VID are RebGUI are just "face factories" 
 ... feed them a spec and they produce a face object. All other functionality 
 is neither VID nor RebGUI specific. I get a lot of emails asking 
 "how do I do x in RebGUI", but 99% of them are really "how do I do 
 x in REBOL", or, "how do I use the SDK to do x" type questions.

I use VID to do a print preview ... using a draw dialect

 ...RebGUI's use of the effect facet (and hence draw) is no different 
 to VID's. Also note that 'draw is available as a native from the 
 console (i.e. you don't event need VID or RebGUI to use it).

And toggle?

 ... does it need to support more than two states? Does it need to 
 support text (like a button) and images (like icon)?

Well, I personally don't use icons for buttons ...

Just something like the VID toggle is fine for me.

different text and different colours for the buttons

more than two states is a rotary widget ...

BTW what's wrong with set-state [ block of widgets to disable ] ?

Ah, I confused the toggle and rotary widgets. OK, I'll add toggle 
(text button version only).

what's wrong with set-state [ block of widgets to disable ] 
 ... do you really mean set-disable and set-enable?

could be .. the function that changes info

options [info] was replaced with set-disable and set-enable .. and 
you can specify disable like this as well:

display "Test" [
	field
	f: field disable
	field
	button "Off" [set-enable f]
	button "On" [set-disable f]
]

I've been looking at the jqGrid ... http://www.trirand.com/jqgrid/jqgrid.html
and many of these grids use a data source instead of a static block 
of data.

(see why I'm keen to redo the docs :) )

why not just ... set-enable f true/false

with a data source you can let the pagination occur within the widget

And let the widget handle the "loading ..." indicators

What I do at present is use a tab-panel and have the loading gif 
in one, and then replace that panel with the table once the data 
arrives

Having pagination would really help a lot ... sometimes i have tables 
full of hundreds of items.

why not just ... set-enable f true/false
 ... makes sense, I'll think on that one
use a data source instead of a static block of data
 ... live data?

sql query

What do you mean by pagination in the context of a table?

say you have 1000 rows... but you only want to display 20 at a time

having all the data inside the table at once means big slow down 
time

better to feed the table from a sql query, or another function that 
holds all the data

so you can use the scroller to move within the 20 items .. but not 
to scroll past them.  You have to paginate to the next 20.

The slow-down is from the query side not the RebGUI/table side. Table 
uses an iterator function so whether the table has 10 rows or 1,000,000 
it should be the same speed ... fetching 10 rows or 1,000,000 across 
a network is another story.

That's not my observation.

Anyway, 20 rows will be faster than 40 right?

Anyway, scrolling thru 1M rows is impractical.

I presume altme uses an iterator function as well... I just switched 
from 1000 to 4000 in preferences and now scrolling is a dog.

Try this on 10, 100 and 1,000 rows:

d: copy []
loop 20 [insert tail d reduce [random 10 random 10]]
s: now/time/precise
display "A" [
	table 20x100 options ["A" left .5 "B" left .5] data d
]
print now/time/precise - s

seems to scale pretty well here (on a Mac).