World: r3wp

Pekr, i was confused too. thought you want to extract rebgui without 
/view, /core only. "not installed" .. :)

No directory: I guess it takes the default sandbox without installation, 
that one it suggest while installing.

Multiple views, not installed: i guess you can keep multiple exes 
and run them. maybe rename them with version. They would share registry-setting, 
but i dont think they relaunch the installed exe. Although the default 
rebol for Ü.r would change.

With your usb, do you have a private account on the machines? So 
that you have own registry-settings?

sandbox-location: the '*-thru with the url. And you can launch rebol 
with an url too, it uses sandbox then. (newer feature).

Oops, are we are a bit OT here, its not rebuis problem? Was in answer 
mode. Although, get-rebgui could download to  the currenent folder, 
not the sandbox. Its for developers, but developers need to find 
the scripts after running it.

SVN: Yes, can handle binary files very well. SO let's just add everything 
required to build a complete developer and end-user distribution 
of RebGUI.

Makes keeping everything in sync much simpler.

Agreed. %tour.r and associated images added (also added pie-chart 
to tour under 'Graphic' - previously 'Picture' - category).

It would be nice if we could use the same jargon for the same action.

So, /redraw = /update ?

Had a look at porting Henrik's list-view over to RebGUI. Main challenge 
would be to convert / merge 4 styles (list-icon, list-field, list-text 
and list-view) into a single rebface. This would require quite a 
bit of code restructing. The actual internals don't need too much 
work (functions and feel code are pretty VID/RebGUI neutral), but 
a lot of references to RebGUI 'standards' need to be added; such 
as:

	default-* objects instead of system objects
	ctx-rebgui/sizes
	ctx-rebgui/colors


And the span facet needs to be added (and support logic added) to 
enable dynamic resize / rescale. Given the amount of code that needs 
to be changed, I don't believe a VID and RebGUI version can be [easily] 
built from the same code-base (i.e. the port will in effect create 
a fork).


Also, from a code complexity POV, the list-view widget is almost 
as large as *all other widgets combined* ... and it includes functionality 
that could probably otherwise go into a grid / spreadsheet type widget 
(list-view is almost a GUI framework in its own right now! ;)). If 
anyone's in doubt, I think Henrik's work rocks and fills a much needed 
gap in VID functionality. ;)

In rebgui-functionality too or not?!

ashley, I'm not even sure that many methods I'm using are entirely 
correct. I've seen bugs in it that would be caused by incorrect usage 
of CTX-* objects, for example, which causes some information to shared 
where it shouldn't be.

So if it would be possible to have someone look at it (while not 
laughing) and point out what things could be better designed, that 
might help a lot.

I've also thought about splitting the code in more levels to achieve 
better abstraction. Whether this would help for a RebGUI version 
or not, I don't know. I do think that there would be a need to create 
automation for building both for VID and for RebGUI.

another solution again is to simply wait a bit longer until I get 
some more critical features in and then simply fork the thing. This 
I don't particularly like.

I guess I need to make use of RebGUI in the near future and figure 
out how it works. Then I could make the port myself

Having converted (or at least used as a starting base) a number of 
VID styles to RebGUI widgets I've observed that the final code is 
40%-60% smaller (YMMV) and easier to understand in that most of the 
logic resides in the widget itself (i.e. it is self-contained). But, 
once the code to be converted reaches a certain size where I can 
no longer 'grok' it in a single reading (about a hundred lines for 
me) I find it easier to code from scratch. ;)


I'd also break it into two separate widgets: grid and list-view, 
and look at the minimum function set each requires (KISS).


Simplest way to start is to read all the doco under 'RebGUI Documentation' 
at http://www.dobeash.com/RebGUI/then look at the source code of 
a few widgets (start with something simple like %button.r then move 
onto %table.r which shares a lot in common with list-view).


If you run into any brick walls (or find yourself asking, "why oh 
why did they do it that way?") just drop a note here. ;)

I just want to inform you what enhancements I needed and Cyphre did 
so far for RebGUI:


table: Add an API to table that allows to change the columns layout 
at runtime: my-table/set-columns ["Column 1" left 0.25 "Column2" 
center 0.75]


drop-list: fire action only if selection was made/changed, at the 
moment action fires if clicked on field too


general: on-un/focus should be fired if user clicks an other widget, 
not only if carets leaves the widget when TAB is pressed


table: moving bar up/down with keyboard should fire click-action, 
alternativ: pressing RETURN can fire click action

table: align header text like data (left, center, right) at the moment 
always left
table: TRAC #21


TRAC #5 Cyphre: should be fixed but please test it and let me know. 

TRAC #6

I'm going to test all those changes and than we are ready to publish 
them back to the official RebGUI repository.


Ashley, do you first want to take a look at the changes or should 
I just check them in?


What about the docs? Who is going to update them? Should the RebGUI 
docs be added to the repository as well?

WRT Henrik's list-view: I think Ashley is right, that we should try 
to seperate the list-view and grid-view and see if we can extract 
common code to both. I would preferr a layered approach, where I 
can add more "comfort layers" if I want but I'm not forced to always 
have this code included.

I'd also like to see the drop list drop down on clicking on the text 
and not just the down arrow.

Graham, all things I mentioned are implemented.

So just give us some days to see if it really works.

Robert - would it be problematic to "port" Cyphre's grid? It contains 
nicely abstracted engine too, is rather small. IIRC you contracted 
Cyphre for that earlier and even I did, to add horizontal scrolling 
...

Yes, that's an option as well.

Ashley, how about adding some screenshots to paragraph 3.3 of the 
docs? Would make it much easier to understand what's going on.

So, how can I create a column based layout? I need first to draw 
several buttons downward and than right of them several fields downward. 
I can't layout out them by line because I need the focus to cycle 
through all fields and not to jump from button to field to button 
etc.

Better: Is there a way to remove a widget from the focus cycle?

Do you have a short example? Maybe i find some interesting lines 
in the source.

of rebgui

Example: At the moment I use
	button "a" field "a" return
	button "b" field "b" return
and I need
	below
	button "a"
	button "b"
	return ; return right of button "a" positon
	field "a"
	field "b"

So something like GUIDE in VID but more convinient to use. The VID 
GUIDE isn't very logical to use IMO.

Maybe a LINE or COLUMN keyword would be good. And the COLUMN width 
is derived from the widest widgets placed in one line.

removing focus would save your problem too?

Yes, if I could specify for each widget in the OPTIONS block if the 
focus can be set to the widget via keyboard or not, that would solve 
the problem as well. Pressing TAB should search so long until an 
"open" widget is found.

Would preprocesing help for now? something like
below[
	. button "a" 
	. button "b"
	return ; return right of button "a" positon
	. field "a"
	. field "b"
 
]

What do you mean with pre-processing?

how to add this than to a bigger layout?

giving it a layout like the above and turning it into 
    button "a" field "a" return
	button "b" field "b" return

compose?

i hope rebgui has sub-panels.

Adding a new keyword like BELOW would be OK.

But i dont  know the internals for now. If you can wait for Ashley 
ok, just playing around.

No, i made a thinking-error. preprocessing would not work.

table: Can I set the selected row at run-time? I would like to pre-select 
the first entry.

display "Example" compose [
    button "a" [face/type: 'untabbed-button] field "a" return 
    button "b" field "b" return
]

in rebgui-edit
	tabbed: [area field edit-list password button]

    tabbed?: make function! [face [object!]] [all [find tabbed face/type 
    face]] ; [che] Returns TRUE if a face itself (not one of it's pane's 
    subfaces) is tabbable (NONE otherwise).

how to do that type-change on creation?

my demo: after pressing button "a" its no longer tabbable.

Yes, rebgui asserts that certain widget types are tabbable. It is 
not an attribute of a widget instance that can be changed, except 
by a trick such as Volker's, above. Changing the type is not recommended 
because it is bound to break other rebgui behaviour.