World: r3wp

Ashley is making the same point I am, "end user" vs. programmer (or 
tech).  Any time a programmer says "I do X all the time" all I think 
is that if "I can bottle the exact opposite of X I can make a billion 
dollars."


Hence I wrote above "The exception is when people are dumping databases, 
and those are not using formulas, but rather are for working out 
data.  This is done by programmers, not by users in general."


Never-the-less, if the goal here is the goal, which is for technical 
people to do this, we all still need a solve, which is speed to do 
it.


In Qtask we did part on the server, and part on the client.  So, 
we let you sort columns locally, but would send all the data to the 
server.  What we learned is:

The server would send down all the data.  Slow, but needed.
Then JS would arrange everything into a table.  Slow but needed.

Then JS would sort.  And we allowed 4 levels of sort… Slow, slow, 
slow, and turns out, not so needed.


It turns out that with anything more than about 20 lines it was better 
in the long run to just sort form the server side.


This is not to say this is how this will work where with Rebol.  
My point is more to the idea of playing with UI until you strike 
the right balance of speed and convenience.

Just noticed that we don't have a request-text requester

.

One I hadn't seen before ... 
** Script Error: foreach expected data argument of type: series
** Where: next-field

** Near: foreach sibling siblings [if target: any [tabbed? sibling 
into-widget/forwards sibling] [
return target]] all
** Press enter to quit...

Was just tabbing thru my windows on my desktop...

How can I access (further parametrise widget) in terms of display 
code? E.g. simple color change - I miss something like VID's 'with 
directive ...

the only thing I came up with is using 'do [show-color widget value]

text "blah ... " font [ color: red ]

Why does table/selected/n not work?  I have to do .. pick table/selected 
n

Is it because it is a function and not a path?

that could be a reason

A little confusing ...

How does one display a window so that it stays in front?

display/dialog doesn't work for me.

Graham - are you missing a ' or : in your question above?

if "pick table/selected n" works, I think you should try "table/selected/:n"

because "table/selected/n" means "pick table/selected 'n", which 
doesn't seem right  =^_~=

Sorry, it was a math thing ...

I think it doesn't work because it's not a path

Graham - I mean - how do I know, what facets are exposed to 'display 
dialect level? My friend simply asked me, if there is alternative 
to VID's 'with keyword with raw access to widget internals ...

how do I know?

I ask Ashley :)

Lines 308-337 of http://trac.geekisp.com/rebgui/browser/rebgui-layout.r
plus any widget specific attributes from http://trac.geekisp.com/rebgui/wiki/WidgetList

Cyphre and I have continued to fix bugs and enhance RebGUI. We still 
have some bugs to fix but than it's time for a new release. As new 
widgets we have done a CHART widget that lets you do bar, pie, torus 
charts.

The CHART stuff is based on draw.

nice ... I am working on initial doc for grid, however I am more 
than one week late ... hopefully I will be able to release it in 
3 days ...

btw - combo-box - you can still scroll under the horizont - the bug 
that was there with table too ...

some way to ensure a window stays in front would be nice .. ..

Does that by default:

	display "A" [button "A" 40x40 [display "B" [button "B" 20x20]]]


Click button A, then B, then A again ... at least that's the way 
it works under 1.3.2.3.1

display "A" [button "A" 40x40 [display "B" [button "B" 20x20 [ display 
"C" [ button "C" 10x10] ]]]]

It doesn't for me ... button C will not stay infront of button B, 
but will stay infront of button A

ie. both stay infront of A, but C does not stay infront of B.

>> rebol/version
== 1.3.2.3.1

Easy enough to do ... just change line 83 of %rebgui-display.r to 
read:

	... reduce ['parent last ...


Consequence of this change (in the example above) will be that closing 
window B will close C. I'm loath to introduce specific 'parent declarations 
... how about a refinement that overrides the default "parent is 
first" behaviour? e.g:

	display ...	-> the default, parent is first window

 display/parent	-> parent is last (usually previous/calling) window

if C stays in front, then, closing B causing C to close is okay with 
me.

Actually, a refinement would be good having tested the change above 
which does not suit.

Added rev#31 with above refinement change to SVN.

radio-group: I think we need to enhance this widget by introducing 
an ID per selection option, that can be stored to a database. If 
you store the text, problems araise if the text is changed. If you 
store the selection poistion problems araise of the order is changed.

What do you think?

I'm happy with the current behaviour.

I'm not sure what enhancement you are proposing.

radio-group data ["Option 1" "Option2"] while developing your app 
becomes radio-group data ["Feature B" "Feature A"] 

How do you handle old records?

I use the index

sometimes ...

othertimes, I translate the text into T/F for storage into database

Char(1) takes up less space, no?

Yes, but TRUE/FALSE is position dependent. If you swap the order, 
you restore the wrong value.

Don't swap the order.

Sorry, it's been some time since I last used RebGui, so I've got 
a few questions.
(How) is it possible to ... ?

- change double-click handling of an area? (I would like to call 
a function with the position or word clicked on)
- change keyboard handling in an area? (like add auto-indent)

- have timer event, that fires after specified times (it would be 
ideal, if the timer could be reset on every key-press)
(I don't know how many changes RebGui adds in these areas).

Thanks,

Ingo

fld [ single click ] [ double click ] [ right click ]

Not what you're asking?