AltME groups: search

The last one seems to happen if COMMENT is used inside a spec block.

Checkout is to grab a copy of the repository.

Yes, once you do an "SVN Checkout" the folders and files are displayed 
with a green tick. Editing a file causes it (and the folder it appears 
in) to be displayed with a red changed icon. Right clicking the root 
folder, RebGUI in my case, and selecting "SVN Commit" prompts for 
which changed scripts (and a comment) you wish to save back. Pretty 
straight forward once you've done it.

Ashley, I didn't make a history entry in rebgui-widgets.r for my 
changes, which I have commented next to the changes - would you prefer 
I did make a history entry ?

The change comment (which appears under Last Change when doing a 
"Browse Source") is the more important thing.

Not sure whether putting %tour.r up is a good thing as it has dependencies 
on images, dat files and / or dictionaries that don't really belong 
in SVN. I sort of wanted the repository to only contain code needed 
to produce %rebgui.r, while the %get-rebgui.r process delivers an 
"end-user" bundle with %tour.r, demos, etc ready to run (i.e. the 
repository is for developers/documentors only).


Likewise the build script has dependencies on prebol.r and prerebol.r 
so I'll need to extract the bits it uses before I put it up. Any 
ideas on what this script should be called? build.r, merge.r, make.r, 
compile.r, other?

when the cursor reaches the bottom of the area, it suddenly then 
jumps up about a third of the way of the area on the same line.

Ah yes, that's a separate problem.

Hmm.. yes, kind of. But I see the problem as you first described 
- or at least a variant of it. In my case it always jumps to the 
bottom.

Yes, it's a simple algorithm for determining the scroller position 
I think. It needs to have a "window".

I'll see what I can do with this a bit later.

Why not add prerebol.r etc. to the reposititory as well? Into an 
own folder: distribution. Those files belong to a good repository 
as well. Normaly you even add the interpreter version this one works 
with.

If there is a licensing issue, let's ask Carl.

I'd rather, as mentioned before, extract the bits needed (#include 
processing) from prebol.r and prerebol.r into the one script. No 
licencing issues and only a single script to maintain.

anyone got a checked version working with tour.r?

Would you check in a version of Tour.r into the SVN ( and the images 
as well ) ?

When trying to set the value of a radio group, I usually got an error 
about pf being none

I didn't see a way of creating layouts with no borders, so, in rebgui-display.r, 
line 50, I added this to the list of refinements

does rebgui have a toolbar widget?

How would one provide function keys that are globally accessible? 
 I want to make F1 a help key that is context sensitive ( sensitive 
to which pane has focus etc )

In VID you would just assign a key to the window face:

My apps are generally small, and I consider function keys as an optimization, 
which means my apps usually reach a usable state before I get round 
to adding function keys, and so I never get round to adding them. 
:) I have one or two apps which use them, I think.

This is a bit hacky but it works:

I remember cloning the feel of the area face so I could process Control 
keys but thought it might be more complicated for a global handler.

So, I can alter the process-keystrokes function to handle the function 
keys in a global fashion.

Nice hack Anton, and you've pretty much nailed how the whole thing 
hangs together.


Graham, I used to use F1 (for help) in my apps extensively but I've 
replaced them with buttons / icons recently (bit hard to press F1 
on a TabletPC). For that reason I was never worried about providing 
a "Global Keystrokes" block handler or similiar (apart from the fact 
that you then run into issues like, "I want this keystroke handled 
globally except for these cases ...").

Enhancement request posted to trac: there should be a setting to 
switch the drop down and edit lists to popup rather than drop down 
if there is no space below the widget.

I'm setting up a preferences screen for users to assign functions 
to the function keys .. no space at the bottom of the screen for 
the drop down lists :(

Ideally, and this is similiar to what you stated above, drop/edit 
lists that can't otherwise fit their contents by drop-down should 
then drop-up if the space above the widget is greater than the space 
below. This should be the default behaviour (i.e. display as many 
lines as possible, with a preference for 'below').

Another option is to have a list popup that covers the whole of the 
space above and below.

Interested to see Carl is suggesting RebGUi as a possibility for 
R3.

Just a note to all of you: I contracted Cyphre to develop some RebGUI 
widgets. In the next couple of weeks you will see two new widgets:
1. drop-tree: Is a mix of a drop-list with a tree view.
2. tree widget as we can derive this from the drop-tree

Much appreciated. Tree widget is a requirement for an improved directory 
requestor.

area getting a face lift. Any objections to scroll-wheel support 
?

Is there a way to PAD vertically?

1) Vertical pad. No such concept in RebGUI as its layout engine is 
purely left to right carriage return (although you can often achieve 
the desired result by ending a line with a box of the appropriate 
height)


2) group-box and DATA keyword: this is required as a block without 
a keyword is taken to be an action (even though for some widgets 
like tool-bar, tab-panel, group-box, etc it doesn't make as much 
sense ... but I think consistency is more important than concise 
expression for a subset of widgets).

1) Ok, how about a RETURN 5 or so?
2) Ok, I agree.

Q: How can I change the number of columns of a table at run-time? 
I want to use three tables and change semantics depending on user 
action. Sometimes table 2 has 2 columns, sometimes 4.

Table widget wasn't designed to be that dynamic. I normaly have a 
dedicated function for more complex displays, structured like:

show-my-display: make function! [
	...
	
	display "Title" compose [
		...
		button "Redo" [
			unview/only face/parent-face
			show-my-display
		]
	]
	...
]


Not ideal, but works well when the 'refresh' is tied to an action 
at the end of the work-flow such as save, commit, next, prev, etc

I guess a grid widget would do this.

Could I specify a table with the maximum required number of columns 
and than set the sizes of not required columns to 0?

radio-group: What's the best way to create a readio group (vertical) 
and get fields aligned to each radio on the same line? At the moment 
the only solution I see is to use asbolut positioning for the fields.

That or have a group-box beside it. Which gets me to thinking that 
a place-holder widget (based on group-box but with no borders) might 
be a good thing.

That's a good idea to keep the layout engine comfortable.

That error used to happen in initial versions because I didn't check 
to see if there was a caret. The latest code does check.

The 'edit-text func (in %rebgui-edit.r) traps ESC. Comment out the 
show-focus and it works. /dialog "works" as ESC is trapped at the 
window level and does a hide-popup.

on-focus / unfocus glitch: If you CLICK outside a field or into an 
other field, the unfocus action isn't triggered. That's a bit weired 
because it can break control logic for things like: show form A if 
field get's entered, hide form A if field is left.

Excellent. If he can also have a quick look at SVG Renderer (SVG 
-> AGG) that would be good (scaleable icons / tool-bar have been 
blocked on this for a long time).

Step by step. With List-View we have a very good implementation that 
"just" needs to be made RebGUI compliant.

I'll have a look at it over the weekend. Is the current version stable? 
(i.e. are further changes pending)

I expect more changes to come, but I think it would be a good idea 
anyway to figure out a method to quickly update for both VID and 
RebGUI, maybe with separate code sections and a small build script.

No, it was on a field widget :(

Do you have a small example ?

I was just back spacing on a field widget when this happened.

I have a field which I clear when I add the contents to the database. 
 But the caret is not set back to left edge.

How to create a RebGUI widget http://www.lexicon.net/antonr/rebol/doc/create-a-rebgui-widget.html
sends me to http://w3.eftel.com/home.cms

Now available here:

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

How is the svn related to get-rebgui?

 The SVN is for developers / experienced REBOLers ... it is used to 
 manage individual widget source files. %get-rebgui.r obtains a pre-built 
 distribution (including a merged %rebgui.r, %tour.r, images and demo 
 scripts). It is targeted at 'end users' who don't want to use SVN.

%tour.r is missing

 I want to add it *without* having to also add sample icon images 
 to the SVN. I'll probably just 'inline' the images so it's all in 
 one big file.


min-size: read this very carefully: http://www.dobeash.com/RebGUI/display.html#section-2.1.2


The Note says it all: "The min-size limit will only be enforced upon 
a window resize, and the size is inclusive of an OS specific number 
of border / title pixels. Also note that if any widgets are resizeable 
(#H and #W) and min-size has not been specified then RebGUI will 
assign a default value equal to the initial window size."

I know that two ppl is not enough as a representative amount of users 
following some logic, but :-)

rebgui is a developer's tool.

well, you can always state anything. Being a developer's tool does 
not tell anything how ppl are using Rebol to develop. I am not comfort 
with idea of installation, simple as that. I never use double-click 
to launch my scripts and never will do, untill we get one exe and 
components (file associations issue). And noone should explicitly 
tell, how do I use any tool.

There is a View group ...

- Why not images in svn? AFAIK it can handle that. (download-size?). 
Would be nice if i could checkout and have the real rebgui-demo after 
running some build-script.

- min-size: it was easy to enforce an initial resize if some dimension 
is to small. I did that with a small example, area only.See the posted 
lines (maybe they need to be reversed. I experimented a bit). But 
it fails with other things. (obviously needs a check for presence 
of /min-size, but then the sizes dont change right.)

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

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.

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. ;)

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.

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'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.

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.

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"

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

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

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

Adding a new keyword like BELOW would be OK.

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

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).

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.

But as a hack on button?

But I thought of a better hack. Put the non-tabbing widget into a 
group of its own. Looks like rebgui doesn't recurse into subfaces 
when tabbing.

Can widgets be derived from each other? If i make a lookalike of 
button and change only the name, it would be the same?

;hack but  tab works:
display "Example" compose [
    button "a" field "a" return 
    button "b" field "b" return 
    do [
        foreach [but fie] face/pane [but/type: 'untabbed-button]
    ]
]

Well, it's referred to a few times in rebgui-edit.r

Robert

 Docs: the 'Widgets' section of the 'RebGUI Display User's Guide' 
 is already in the Repository (the WidgetList Wiki entry) ... I'll 
 be removing that section from the guide once all the widget details 
 have been copied across. Feel free to update the Wiki with any widget 
 specific usage notes / instructions. Forward any other doc changes 
 to me and I'll put them in. I plan to eventually move all the docs 
 across to the Wiki, just haven't got around to doing it yet.

 "do you first want to take a look at the changes or should I just 
 check them in?" ... Just check them in thanks.
	screenshots: added to the ToDo list

 widget placement: I'm coming around to the idea that BELOW may be 
 unavoidable, even if undesirable from a design / complexity POV
	tabbing: Anton about summed it up

Volker
	Type: also used by accessor functions

;is this ok? vertical tab
display "Example" compose [
    button "a" [alert "hi"] field "a" return 
    button "b" field "b" return 
    do [
        out: copy [] 
        append out extract face/pane 2 
        append out extract next face/pane 2 
        insert clear face/pane out
    ]
]

Is there a no-wrap option for area?

The other trick is telling whether a specific user has View set up 
on a multiuser system. There are still some multiuser-unfriendly 
bugs in the REBOL/View installer, mostly for backwards compatibility 
with View 1.2 registry settings. At least the file handling has been 
made multiuser safe - we'll see if REBOL 3 solves the rest of the 
problems.

the problems were described ... in general we should be able to have 
choice to install for a) all users b) one particular user .... and 
with uninstall to a) keep private data b) remove data .... uninstall 
is flawed though, as when you uninstall, the icon is removed from 
control panel and other user has no option to uninstall ... or you 
remove the rebol even when other user did not agree to :-)

A mind blank here ... what am I doing wrong ?

>> do %rebgui.r
Script: "Untitled" (none)
>> i: load %skype.png
== make image! [21x21 #{
FBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFB
FBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBFBF...
>> display "" [ image i ]
** Script Error: Cannot use path on none! value
** Where: init
** Near: size/x: image/size/x

display "" [image %skype.png] also works


http://trac.geekisp.com/rebgui/wiki/WidgetList#imageis pretty clear 
(needs a file! or image! *not* a word!)

Probably better to provide a small example under each widget description. 
Updated the above Wiki entry. How about that?