World: r3wp

excuse for ma poor english ;-p

The first issue is due to the fact that 'table expects its data to 
be flat, as in:

	["A" 1 "B" 2]

not blocked:

	[ ["A" 1] ["B" 2] ]


Graham (a long time back) requested that 'table optionaly accept 
data in this format. I'll add it to the list of issues.


Second one is a known issue (#26 at: http://www.dobeash.com/it/rebgui/issues.html#section-2.1
)

Here's a link to an experimental RebGUI widget TIME-PLAN I'm working 
on. It's starting to get useable, even though it's far from beeing 
useful yet (and since it's my first RebGUI widget ever, it's far 
from being very compliant to the RebGUI coding standards, too):

do http://www.diefettenjahresindvorbei.de/rebol/time-plan.r

Hopefully, one day one will be able to use it for e.g. resource planning 
systems. Use left and right mouse buttons to edit the periods and 
the right mouse button to scroll the plan around. The bird-view in 
the widget's top left edge isn't editable in the sense that it would 
yet allow scrolling, but that's it's intended use, of course.

*Very* nice. I wouln't worry too much about how RebGUI complient 
you are at the moment as it looks like you are going to have to code 
a lot of it directly in View / AGG anyway! ;) Watch out Apple iCal 
...

Thanks, Ashley. I'm mainly thinking "lacking compliancy" in terms 
of deep copying and memory concerns as well as regarding resizing 
due to unoptimized code at this stage. 

Not worrying isn't an option for me, I'm always worrying way too 
much! ;-)

Yes, that's great work! IMO it makes sense to get to a state where 
the widget is mostly feature-complete and than we do a peer review 
to get it optimized and RebGUI compliant.

tried to download rebgui via get-rebgui script and it installed into 
view-root .... the strange thing is, that HKCU\Software\Rebol\View\Sandbox 
says C:\REBOL\View\public .... I wonder where View is getting view-root 
from?

Pekr, what version of rebol did you use ?

1.3.2

Later today I will try to remove registry entry and to install View 
from the scratch ...

Here is a bug report:

** Script Error: Expected one of: pair! - not: none!
** Where: edit-text
** Near: margin: face-size - caret
either

What I do is, that I check the input of a field with on-unfocus and 
change TEXT and DATA to default values "0.0" and 0.0 and stay in 
the field. The error happens if I than enter a text longer then 3 
chars (the length of TEXT). If I just enter 3 or less chars it works.

Try setting a field/text field/data to a default text and enter a 
longer text. Should bring the error as well.

Idea: I'm using a lot of data-entry forms in my apps. So getting 
a data-record from the form and putting a data-record into the form 
is a common task. It would be great to have a function SAVE-FORM 
and LOAD-FORM, that collects/restores all necessary widget values.


We could specify a SAVE flag via the options facet for each widget? 
If the SAVE flag is set the widget is collected/restored.

I have used this approach in my own data-form dialect and it's a 
real time-saver.

The format could be: my-record [name/text "Robert" name/data 5]

So it makes sense to be able to specify either the SAVE option in 
which case the default "value" of the widget is collected/restored 
or to specify an other block: SAVE [text data user-data]

in FoxPro, those methods were called Scatter and Gather ...

That is imo what get-face, set-face accessors were supposed to be 
initially imo ....

Yes, on a per widget base. I'm talking about a complete data-form 
with several widgets.

robert: see my devcon registration script. it fixes a few bugs on 
get-face and set-face for panels, and uses the panel accessor for 
the window too. then it just uses get-face and set-face like your 
save-form and load-form.

(i've always been using something like this in my projects.)

100th RebGUI issue logged: http://www.dobeash.com/it/rebgui/issues.html

Gab, you have a link to your script?

; default one is very stupid
my-access: make ctx-access/panel [
    set-face*: func [face value /local val][
        if all [block? face/pane block? value][
            either set-word? value/1 [
                foreach [word val] value [
                    set-find-var face/pane to word! word val
                ]
            ] [
                foreach f face/pane [

                    if any [find f/flags 'input find f/flags 'panel] [
                        if not empty? value [
                            set-face f value/1
                            value: next value
                        ]
                    ]
                ]
            ]
        ]
    ]
]

How about adding: get-text, get-data? I'm always using those non-existing 
words ;-))

margin: Setting the margin in a bigger layout somewhere in the middle 
"margin 4x4" reset the layout cursor so that the next widget is displayed 
at the "top". Seems that changing MARGIN and SPACING inside a layout 
several times has some problems.

group-box: Today an other idea striked me for group-box. How about 
a way to collapse the group-box like a sub-tree in a tree control? 
With this a GUI could be make very dense and only those parts expanded 
that are currently worked on.

This approach is good for top-down approaches in applications.

Robert: I'm using hypernotes for this. There's tree-list on left 
and you can define whatever layout you want with VID tag. I also 
patched hypernotes with SCRIPT tag so I can write code in hypernotes 
and script is generated automatically.

Robert - something like following? - http://www.xidys.com/winbox.jpg
... it is taken from Winbox app, which we use with our Mikrotik routers 
... dunno what they use as their toolkit,maybe Qt?

margin/spacing: added to the list.


The drop-down widget panel is actually a standard interface element 
on Mac (forget the name of it) which looks surprisingly similar to 
the JPG Pekr posted. A worthwhile addition I think, although hard 
to implement (as it changes the offset of every widget below it and 
forces a window resize).

Petr, yep something like this.

Ashley, shouldn't the span stuff help here? I mean it's somehow like 
a spliter put between the box and the next widget line.

Rebolek, is/could the tree-list be made RebGUI compliant? That would 
be really great!! Especially the idea with the VID tag and the SCRIP 
stuff.

Robert: I don't know, I'm not author of HyperNotes, Martin Johannesson 
is. However, he wrote to me, that current version of his list is 
little bit tricky and he's working on new version. So maybe the new 
version may be rewritten for RebGUI. If you like to have a look at 
my patched version of HyperNotes, just let me know.

The problem I see with the general get-face/set-face approach on 
panels is that values are ordered and unnamed. This makes maintenance 
a problem because, depending on how you deal with that data, you 
have to change things, be aware of the order of fields, etc. It can 
be a nightmare IME. Of course, I want a solution that minimizes my 
code, but I'm even more concerned about keeping it correct.

Gregg, I totally agree. And it's one of those things that drive me 
nuts in VID / View. Sorting faces for z-ordering etc. is really no 
fun. And I have no way to get a reference that's stable.

My standard approach is to write collect and display routines, which 
isn't so bad if we have a form framework that can do it intelligently, 
or generate the code for us.

;-) Issued the request to add this to rebgui.

The nice thing is, that if you create a set of faces that need to 
be collected/restored you don't have to use a zillion of face words. 
You specify them via flags.

Gregg: my code above fixes just that, uses name: value instead of 
just block of value.

The approach I'm looking at will flag widgets (via the options block?) 
with both a reference word and an [optional]  datatype specification. 
You will than have functions like:


 put-values my-display [f1: "Some text" f2: 3-Jan-2005 f5: $20.50]

 put-values/all my-display ["Some text" 3-Jan-2005 3x4 "Fourth field" 
 $20.50]
	get-values my-display [f5 f2]
	get-values/all my-display []


so you can put and get values either by reference, or just do the 
whole lot directly with a /all refinement. The optional datatype 
specification will force a conversion on the returned value. get-values 
will stop at the first failed datatype conversion, instead returning 
the widget reference word.


Still in the planning stage, so other / further suggestions welcome.

The interface should be compatible with SQLite, so that no block 
transformation is required. Getting data from SQLite directly to 
the GUI and back.

options block: Yes, good approach.

I expect /ALL only to use ALL widgets that have been flaged.

data-conversion: It would be nice if I can register a call-back function 
that is used.

Just had an unusual enhancement request from a customer of mine. 
As they fill in fields and areas on a form, they want the ability 
to press Ctrl+B to bold the contents of an entire field / area so 
as they can visually note and review what is important prior to clicking 
"Save" and moving to the next form. It would be fairly easy to add 
this to RebGUI (a Ctrl-B bold toggle), but would anyone else find 
this useful?

quite non typical ... I wonder ppl don't miss underlined accelerator 
keys, ctrl + tab to toggle between the tabs and clicking away from 
list-down to close :-)