World: r3wp

Tracked down the edit-list tab problem ... it's the on-unfocus handler 
it inherits from drop-list that is causing the problem. Need some 
way of conditionally wrapping the hide-popup so it only does it if 
the edit-list is actually active.

Other issues are noted.

Thanks.

Ashley, one question. As you have created the best GUI solution for 
REBOL2 I ask to myself why your still not involved in REBOL3 GUI. 
Are you waiting the final VID version to port your great experience 
in this area ?

hum logically because R3 is not official and completed so stabilised 
etc...

if you do a hudge work to have to redo it from scratch next week 
that's not fun

REBGUI 117 whaoooo version  the looks really really pro and mature 
project congratulation Ashley

how can i add a custom rebface to rebGUI  to make it dynamical know 
the existance of my custom rebface

ok i found the documentation on deboash.com  ^^

documentation is not reflecting actual rebGUI structure T___T (reb-widget.r 
is old)

just reporting this error ... no expectations

make object! [
   code: 300
   type: 'script
   id: 'no-value
   arg1: 'event
   arg2: none
   arg3: none
   near: [case [
           event/double-click [face/action/on-dbl-click face]
           act = 'up [face/action/on-click face]
           act = 'alt-up [face/action/on-alt-click face]

           act = 'key [face/action/on-key face event face/action/on-edit face]

           act = 'scroll-line [face/action/on-scroll face event/offset]

           act = 'scroll-page [face/action/on-scroll/page face event/offset]
       ]]
   where: 'wake-event
]

I'd like a text variant .. eg. a-text for active text which highlites 
on over and returns to its color on away.  I can get the over working 
okay, but the on-away doesn't restore the color.

lol, why do you use CASE here ?

not my code .. it's Rebgui code

Pardon my ignorance, by why wouldn't you?

Not clear to me why this error occurs

>> display "" [ table 40x100 options [ "name" left .99 ] data [ "a" 
"b" ] [ face/remove-row 1 ]] do-events
** Script Error: Invalid path value: remove-row
** Where: action
** Near: face/remove-row 1

when you click on a row to remove it

try

>>display "" t:  table 40x100 options [ "name" left .99 ] data [ 
"a" "b" ] [t/remove-row 1 ]] do-events ... (untested)

just naming the table?

Hmm.  works.

display "" [ t: table 40x100 options [ "name" left .99 ] data [ "a" 
"b" ] [ t/remove-row 1 ]] do-events

Hi Giuseppe, I'll respond in full to your questions here as I've 
had quite a few emails recently asking similar questions about the 
future of R3 and RebGUI.

As you have created the best GUI solution for REBOL2

 ... Thanks, remember that "best" is in the eye of the beholder though 
 ;) ... RebGUI was created only because VID wasn't up to the task.

I ask to myself why your still not involved in REBOL3 GUI.

 ... Apart from the fact that I cannot give the project the time it 
 requires, the R3 GUI is in far more capable hands than mine. I'm 
 looking forward to it making RebGUI obsolete! ;)


Are you waiting the final VID version to port your great experience 
in this area ?

 ... When the R3 GUI is stable I'll look at how best to port apps 
 from RebGUI to it. I'm thinking either a compatibility layer or an 
 outright script conversion utility. But while we wait for that glorious 
 future (stable R3/GUI SDKs on Windows, Mac and Linux) RebGUI is still 
 the only R2/GUI game in town (IMHO).

Does this apply to all the table functions?

I'm thinking that perhaps I've always used table names for the other 
functions ... such as select-row

Yes, the functions belong to the widget not the row face.

face/parent-face/remove-row then?

display "" [ table 40x100 options [ "name" left .99 ] data [ "a" 
"b" ] [ face/parent-face/remove-row first face/picked ]] do-events

seems to work

RebGUI was created only because VID wasn't up to the task. damn right 
ashley but nothing guaranty us the VID next set of widget will be 
hum more reliable (to not say more usefull ...) but still VID remain 
 a powerfull things so with our without cool widget set from base 
since VID stay a powerfull base and draw still remains too it's still 
possible to make a set of widgets more hum .. more to feet our taste 
and needs ?

R3 is not for tomorow ( or maybe Carl done some crazy amount of work 
in the night and gets all ready for tomorow morning ???) so rebGUI 
still has a couple of years to go on ^^ and as a matter of fact i 
prefer i good VID /DRAW  system with no widget than lot of widgets 
with a not extendable dialect what makes all the interrest of VID 
is therefor the high flexibility of it and it's relative simplisicity 
and that aspect have to remain and even been enhanced

however main goal of rebGUI was to provide a cool widget enhancement 
library for VID propose a "example" set of widget people want to 
use the most in their software ( well that list of widgets can be 
found in any advanced graphical library such as GTK+ winap32 aqua 
QT WxWindows Tcl/tk etc...)

REbgui has in a background to show to that VID has many lacks (because 
no one really focus his attention only to design it. at least on 
teh VID2 version)  widget and event system could be simplier and 
provide more efficiency (less memory use more widget set ). REbgui 
was done in waste that's my own opinion

REGui wasn't done in waste that's my own opinion (damn i missed the 
n't ...on my previous lines)

>> display "" [ tree 45x10 options [resize] data [ "one" [ "4" "5" 
"6" ] ]] do-events
** Script Error: Cannot use path on none! value
** Where: show-tree

** Near: all [parent-face parent-face/action/on-resize/child parent-face]

Looks like resize does work if the tree is enclosed in a scroll panel.

This isn't strictly a Rebgui question ... but here goes.  I want 
to double click on a word and perform an action.  That action involves 
interacting with some gui elements on the current screen.  Now, there 
is a function 'hilight-text inside the rebgui 'edit object which 
is inside the rebgui-ctx context.  So, I can hook in there with my 
dbl-click function.  But how to make it call my function which is 
defined for each window?

I can create a global dbl-click-edit function, but since the widgets 
have names all made local, I can't effect the changes I want unless 
I make the widget names global as well.

Ashley, how about a refinement for display that opens a window relative 
to the current face ... so like /position

Define "current face". We could certainly do sometjhing like:

	display/relative-to face 20x20

yeah ... that would be good

That would allow popup menus where the mouse is.

Anyone done a request-calculator requester ?

You mean like the basic one in View/Desktop?

forgot about that one ... but yes.

Actually I was just thinking of allowing users to use a gui to enter 
numbers into fields ...but why not use a calculator requester for 
that?

You could make it a special field so if someone enters a literal 
("12") it doesn't do anything, otherwise ("10+2") it parses and evaluates 
it (perhaps putting "ERR!" in the field if the expression couldn't 
be evaluated).

The main thing I wanted was a way to input numbers using the mouse 
which is easy enough using a calculator layout.

Puzzle time .... I have this


add2script: has [ t1 ] [
    display/parent "test" [

        t1: table 40x40 options [ "item" left .99 ] data [ "one" ]
        on-click [
            either value? 't1 [
                alert first t1/selected
            ][
                alert "t1 has no value!"
            ]
        ]
    ]
]


Now if this is invoked by single-click on an element in a table, 
it's fine.  If I invoke by double-click on the table to invoke, it 
 gives the error.   If I remove the single click action, and allow 
it to be invoked on double click, then it is also fine.

however, I can't reproduce it outside my app yet.  
Now if I replace the above with 

add2script: has [ tl ][
    view/new layout [
        t1: text-list 100x100 data [ "one" ] [ print t1/text ]
    ]
]

then double click always produces two windows ...

but I don't get the error where the t1 variable becomes none!