World: r3wp

Doc updated. http://home.wilddsl.net.au/anton/rebol/doc/create-a-rebgui-widget.html

See the problems caused by documentation ? *See* ! ?

documentation is vital, however, at least there *is* documentation. 
:-)

No... *source* is vital. Documentation is a mere reflection.

Anton - are you sure? :-) I just looked lately at the source, and 
there seems to be one param -inbound, or outbound, for drop-list 
.... inbound is set by default. Separate window - why? We have show-popup 
...

Pretty sure, unless I misunderstand you (I didn't look at the source). 
 How can a rebol/view face hang over the edge, overlapping its parent 
window ?

maybe it can?

It would not be *in* the window, then. It would have to be a new 
window or layer of some kind, supplied by the OS.

(rebol would have to get the new layer from the OS so it could do 
that.)

I've made a pop-menu which uses borderless windows. It works on WinXP 
but the problem is we can't guarantee that windows on other platforms 
don't have forced decorations on their windows.

so each menu level would look less like a menu and more like a window.

but we have working examples of menu/context menu, which look awesome 
....

So you're just saying you'd like the drop-list to also use borderless 
windows in its implementation.

This is a problem with drop lists. I thought though that this was 
one problem Cyphre was tackling

uh, the Trac is really a stupid system .... damned, where have we 
moved? Can this system produce some simplistic way of how to get 
particular widget source? Without line numbering? That is just crazy 
....

uf, there is, at the very bottom ... that system is pretty denerving 
for normal typical user, who is not a developer, and can't get easily 
to source of widgets, as rebgui.r comes in despaced version ...

hmm, you are probably right, Anton ... just downloaded drop-list.r, 
changed 'inline to 'outline, but nothing changed, it can't go outside 
the parent window ... (which is maybe logical, as everything lives 
in screen-face/app-window/pane .... unless show-popup does not allow 
for other modes ...

If it is within a window face it can't go outside, with rebol/view 
system as it is currently.

hmm, and if it would be put in screen face directly?

Pekr, the trac system is for developers!!

I know ... but users are almost forgotten .... I would welcome if 
widgets would still come (be downloaded by get-rebgui) in separate 
dir ... from time to time it is educative to look at the source

that possibility was removed ... and rebgui.r comes despaced, so 
source code is ruined

what is the metrics for box? :-) I thought it is too tall, so I ended 
up putting box 20x1, and it definitely does not seem like 1 pixel? 
:-) Is it affected by unit size?

** Script Error: max expected value1 argument of type: number pair 
char money date time tuple series
** Where: action
** Near: view*/caret: offset-to-caret parent-face min max
** Press enter to quit...

more area problems...

I was updating an area field ...

Work round by clear-text on the area field before updating it.

Pekr, what is so difficult about browsing the source. The particular 
code you are interested in is at  http://trac.geekisp.com/rebgui/browser/widgets/drop-list.r

All that long message before the code is the notes of the comments 
sent by the creator when commiting the code. So that other developers 
understand his work.

All the code is available from thhis URL.

http://trac.geekisp.com/rebgui/browser

And there are some widgets wo/. comments like http://trac.geekisp.com/rebgui/browser/widgets/bar.r

So,  I will think that trac is not stupid is actually very easy an 
useful.

I suspect it is just intimidating when you use it without reading 
the docs

Got this error again !  third time now, and this was a screen with 
2 fields, and a couple of buttons

** Where: into-widget
** Near: unless find [object! block!] type?/word get
** Press enter to quit...

stack overflow ...

Referencing Henriks message in Ann-Reply "I need a way to show a 
sub-layout" and my own from 26-jun-2006


This is another point that the way 'display works is sub-optimal: 

When building a gui we need 3 actions: layout, display, event-handling.
Having these 3 as distinct actions works well.

Having 1 action for layout and 1 other for display and start of event-handling 
works.

BUT having 1 action for layout AND display doesn't make sense. Because 
you can't build sub-layouts, and you are stuck with a displayed but 
non-functional window after this step.

That said, Henrik, have you tried ctx-rebgui/layout ?

Ingo, no I haven't. I looked through the 'display source, but could 
not find the context of the layout function. If this is right, then 
thanks. :-)

Ashley, is there a way we can halt the recursion before it causes 
a stack overflow?

I thought there was supposed to be a switch in display to allow you 
to construct a layout without viewing it.

If not, it should be easy to add.

] [

Sorry, AltMe became the active window when I was typing code elsewhere. 
 Better to shut it down. Bye.

Anton - today I consulted with Cyphre, and it is really how I thought 
about it - drop-list, and its inside/outside argument really allows 
you to have the drop-list to go beyond the border of parent app. 
The case is, that there is simply a bug, which Cyphre nearly fixed 
(hilite stopped working)

Ah, sorry, I interpreted your initial comment poorly. My apologies.

Anton - that is absolutly ok :-)

guys, I would like to open some UI look chat .... not much, but a 
bit.... Cyphre will look for me to do some slight improvements, e.g. 
to allow gradients for tabs, etc.

Is there anyone else who thinks, that rounded tabs do not work? As 
well as rounded buttons? While we tried to stay WinXP look compatible 
as much as possible, in some situations, rounded buttons do not work 
- try to change tour.r background color to any of darker colors - 
those tabs look more like a leak, than real shape - simply disturbing 
a bit. I have such reaction independently confirmed by Bobik, and 
my brother objected too, without telling him what to judge ....