World: r3wp

Another stumble block in my slow attempt to write my little program. 

Try to select edit-list and hit enter key.

>> display "" [table options ["a" left 1.0] data [] edit-list []] 
do-events ;-- works as it should

>> display/dialog [table options ["a" left 1.0] data [] edit-list 
[]] ;-- window disappears

It maybe related to the table problem I mentioned before.

I made a little mistake, but it makes no difference.


>>display/dialog "" [table options ["a" left 1.0] data [1 2 3] edit-list 
data []]  ;-- it still disappears, even if first line selected

Problems noted for build#218.

Build 217
- added dbl-click support to request-dir
- added keywords to RebDOC (descriptions to follow in build#218)

Ashley - why tree-view node icons (arrows) were removed? Or is it 
only in tour.r?

One more test to help with debugging. It works with build 207. It 
stops working with buid 208. At least for me.


>>display "" [field table options ["a" left 1.0] data [1] field] 
do-events


Click on field and try to tab around. You can't even select any field 
any more (208). Using empty table is even worse. With 2 rows at least 
it works, but one may need to grow table gradually.

(btw www.dobeash.com is still down for me)

It may be last one, I don't know.


display "" [table options ["a" left 1.0] data [1 2] [set-text el 
first face/selected] el: edit-list data []] do-events


Select row 1 and row 2. Build 205 works ok. Build 207 doesn't with 
first row of table - nothing shows on edit-list. Replacing edit-list 
with field makes it work ok in 207 (and up) again.

why tree-view node icons (arrows) were removed?

 ... tree-view was reimplemented to face-iterator ... havn't got around 
 to adding arrows/icons for the nodes yet
... dobeash.com is still down

 ... getting the domain transferred is taking much longer than expected, 
 hope to have it back up within 3-5 days
... stops working with buid 208 ...

 thanks marek, most of those issues are due to the major tabbing changes 
 that occurred in 208. Fixing them is still a WIP.

Build 218
- fixed area resize bug
- added dbl-click support to request-file
- added /only refinement to request-dir
- improved editor save logic
- generalized RebDOC keyword support
- face-iterator now supports toggle-row

Ashley;  you da man.   Thanks for the RebDOC update.   That level 
of information at the fingertips is sweet!

The missing dobeash.com domain is #1 in feedback messages this week 
here at RT.

(Actually, that was last week. :)

if someone creates content, we can create rebgui.com and host it 
on my server - the process would not take longer than one day ...

Did Ashley say that he had a backup of the content?

Dunno, but I hope so. Loosing domain does not mean you loose your 
content ...

... but - that is just some backup plan, Ashley said he is going 
to get his domain back.

Apart from that, let's hope that in few months, we are back to R3 
GUI, and that is where the most of interest of outer community is 
going to be ;-)

He made a note above about a problem... and cancelled the entire 
account.

Yes, R3 GUI is very important to me as well.  The question is...

let's move to R3 group here ...

What does it take to get more active participation of developers 
on it?

ok

The issue is the DNS record....

Serious bug introduced in build 218 or even 217.

Drop-list and edit-list widgets produce past-end error on list selection. 
Tested tour.r, RebDOC.r and in terminal. Nothing works.

All these changes appear to have degraded the usability of rebgui 
somewhat

This is interesting bug.


>>display/dialog "" [edit-list data ["a..." "b..."]] ;; try to enter 
something starting with "a" or "b"
** Script Error: Invalid path value: lines
** Where: wake-event
** Near: pf/lines: to integer! pf/size/y /


Any other start is OK. No modal mode is OK. Happens with 218 (less 
selection bug) and 216 as tested by me.

pf is pop-face

re: dobeash.com
	- transfer of domain OK
	- ftp of backup content to domain OK
	- http access ... not working ... will investigate

R3 GUI is very important to me as wel
 ... ditto!!!


All these changes appear to have degraded the usability of rebgui 
somewhat

 ... remember that these are development builds, only accessable via 
 SVN. I was hoping to stabalize and "release" by end of this month 
 (September), but the domain issues I've been having have probably 
 pushed that back a month.

Fixed domain server entries 24 hours ago ... so dobeash.com should 
once more be accessable.

resolves for me

Hi Ashley, i would like ask you how to make new widget after you 
have removed function append-widget. I have not found any function 
to do it... sorry i am a dommies and may be there similar func exists 
 :-)

The RebGUI documentation looks great.   Is there also an advanced 
comprehensive example application for viewing ala CureCode as a Cheyenne 
application?

Bobik, to create a new widget:

	1. Add your new widget to the %Widgets/ directory

 2. Edit %rebgui-widgets.r to add an #include entry for your new widget

 3. Run %create-ditribution.r which will "compile" a new version of 
 %rebgui.r for you

MikeL, thanks. Have a look at %tour.r, then %RebDOC.r ... there's 
not many comments but the code should be fairly easy to follow.

Sweet! Sorry I missed %tour.r on my first look.

Ashley: thanx a lot! :-)

So i have just one question - is it possible to get  position info 
of mouse on event ON-CLICK , for example when i have box 10x10 on-click 
[get mouse position ....] ?

I know - VID method engage has EVENT, where can i get event/offset...... 
so how to get such value in rebgui to avoid do new widget :-) ?

Hmm, on-click gets face argument. The only thing I am able to come-up 
quickly is

box red 10x10 on-click [print face/offset]


But that just gives you face offset. From face/offset and face/size, 
you can get idea about the area, but not sure about the mouse event 
offset ...

face/offset - you get offset of face(in such case offset of box) 
but not offset of mouse

That is what I said - "but that just gives you face offset".

box red 10x10 on-click [print mold get in face 'feel]

make object! [
    redraw: none
    detect: none
    over: none
    engage: func [face act event][
        case [
            event/double-click [face/action/on-dbl-click face]
            event/type = 'time [face/action/on-time 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]
        ]
    ]
]


Now how to get into the feel, and hook somehow into 'engage method 
:-)

I never used RebGui, but if you can get the object constructed like 
with VID:
b: box red 10x10 on-click [print face/feel/pos]

then you can patch b with something like:

b/feel: make b/feel [
	pos: 0x0 
	engage: func [f a e] compose [
		pos: e/offset 
		(get in b/feel 'engage) f a e
	]
]


That overloads the engage function wihout losing her actual content.

In VID you specify the feel directly, in RebGUI you let the widget 
worry about these low-level implementation details. None of the default 
widgets need to pass mouse offsets back to the application, so if 
you need to do this then creating a new widget is the way to go. 
Having said that, I could always add another action handler (on-anything 
face action event) which would fire instead of the above case statement 
(i.e. handle the event as in VID or let RebGUI delegate it to the 
appropriate handler).

would be nice.

why not allowing the event as a default parameter for any action 
?

I mean, you only furnish the face as argument, can't you add the 
event too ?

Steeve it sounds good! FYI:   I needed widget "box" with drag and 
drop features :-) I know it is possible to make new widget atc.. 
So after append-widget was removed, new widget creating is a little 
bit  cumbersom  and i have tried to catch FAE values directly in 
rebgui dialect...:-) I think there are more cases where to catch 
FAE would be useful for app programmer......

can't you add the event too?

 ... I can, but that breaks a lot of the internal handler code. I'm 
 more interested in seeing what the other FAE cases are (I've yet 
 to hit any myself).

As append-widget removal was oversimplification imo, especially for 
the widget authors, I created short script, which kind of automates 
the process ....

1) Save the script, e.g. make.r, into the RebGUI root dir

2) create one file, called %my-widget-list.r, containing unnamed 
block, containing file-names. Your widgets can be placed anywhere

3) create backup of %rebgui-widgets.r, call it %rebgui-widgets.old.r, 
in order to be able to easily "remove"  widgets by commenting them 
out in file 2)

Here's the script:
REBOL []

;--- to enable removal of unwanted own widgets, create
;--- copy of rebgui-widgets.r into rebgui-widgets.old.r

;--- remember to do so, when official distro release contains new 
widgets!
if exists? %rebgui-widgets.old.r [
  write %rebgui-widgets.r read %rebgui-widgets.old.r
]

;--- load list of widgets you want to include
;--- file containing un-named block of list of files to include
widgets-to-include: load %my-widget-list.r

template: "^-#include %widgets/^/"

;--- read RebGUI widget list (%rebgui-widgets.r)
tmp: read %rebgui-widgets.r

widget-buffer: copy "^/"

foreach widget-filepath widgets-to-include [ 

   widget: last split-path widget-filepath

   ;--- copy widget to the widget-directory
   write join %widgets/ widget read widget-filepath
  
   ;--- build string containing widget names you want to add ...

   ;--- but only when not already on the list - prevent duplicate entries
   if not found? find tmp widget [

        append widget-buffer (head insert find/tail copy template "/" widget)
   ]

]

;--- append to RebGUI widget-list (%rebgui-widgets.r)
change back back tail tmp (append widget-buffer "]")
write %rebgui-widgets.r tmp

;--- rebuild RebGUI distribution ...
call "create-distribution.r"