AltME groups: search

it would be logical with a "Make Zip archive and download" button 
on the front page of that file list...

Agree fully with the color argument, if I say red I mean red. If 
I want a lighter red then I can always write code like:

	button (red + 0.0.0.128)

what do you think of Henrik's buttons/fields

 Buttons are a definite improvement over mine. Fields (and related 
 widgets like area, drop-list, password, etc) get interesting. Let 
 me start by saying that button is by definition a "graphically intensive" 
 widget. The basic view facets (text, edge, effect (non-draw)) only 
 let you do so much so to get buttons that look reasonable you have 
 to go down either the bitmap/effect or draw paths. Fine, I accept 
 that.


Field, and it's related widgets, are mostly textual and you can achieve 
reasonable results using standard text, edge, para and maybe a basic 
effect such as gradient. You can do all this in a dozen lines of 
code. Adding fancy draw effects, and ensuring that they scale as 
the widget is resized, adds significantly to code size/complexity 
and adds another feel over and above the basic edit/feel.


Now, you can be in the aesthetic camp on this one or the KISS camp. 
Does the current field look so bad it warrants such as massive structural 
overhaul? I think not. By all means come up with a better color combination, 
and use simple effects such as gradient that don't rely on setting 
and maintaining draw object sizes.


A few comments suggested that making changes with the current WinXP 
backdrop colors is problematic ... don't use them. If major aesthetic 
improvements require that a different default color set be used then 
design to that and if it all hangs together that will become the 
new default. I'm very open on this.


Another thing I have been thinking on is Window color and Widget 
color. Do we need the later? Another way to handle this (having a 
grouping widget such as tab-panel appear with a color different to 
the window it appears on) is to darken a grouping widget relative 
to its parent. This would allow nested grouping widgets (e.g. tab-panel 
within a tab-panel) to have visually distinctive colors, something 
the current implementation does not handle.

What's the "standard" keystoke(s) to make a drop-list appear? Down 
arrow?

Time to clean up radio-group and drop-list. With radio-group I'm 
contemplating getting rid of all the ID code and making it default 
to:

	data [1 "Opt 1" "Opt 2"]


if no option is selected. You'll still be able to start with no option 
selected (either by specifying none or 0), it's just that having 
no option selected by default is confusing to new users.


For drop-list, I want to fix some of the remaining bugs and add the 
two changes discussed above; clicking anywhere in the area to activate 
the drop list and pressing DnAr to activate it by keystroke. The 
first change could really confuse folks used to changing focus by 
mouse click so I'm thinking of making it an option, say "options 
[click]". Comments?

A word on my design philosophy, which might help determine whether 
you can live with the standard widgets or not.


I like widgets that are small, efficient and satisfy the majority 
usage case. I want to be able to look at a widget I or someone-else 
wrote and "grok" it quickly. When I rewrite a widget I'd like to 
make it simpler and more efficient. Let's look at tab-panel as a 
case in point. It now does everything I'd reasonably expect it to 
do:

	1) Multiple tabs
	2) Auto label size determination
	3) Automatic widget size and resize
	4) Supports Tab actions

 5) Options to start with another tab selected and fire the initial 
 action


The code is simple, clean, efficient and weighs in at just over a 
hundred lines. I can look at it and "grok" it in a couple of seconds. 
But there are many additional things it could do:

	1) Ability to add/remove tabs at runtime
	2) Ability to rename/reorder tabs
	3) Handle case where tabs > available display width


But you get diminishing returns when you implement functionality 
to support these operations as they don't constitute the major usage 
case, and you can code most of them at the app layer by treating 
the tab-panel data block as a block of data that you can manipulate 
and display (via an unview/redisplay sequence).


But what about the third point, where the tabs don't fit? Isn't that 
a problem? No, that's an app design issue. It's no different from:

	display "Test" [
		text 10 "Some long text that doesn't fit"
		radio-group 20x5 data ["Option 1" "Option 2"]
		drop-list 15 data ["Some long text that doesn't fit"]
	] 


You have to allocate sufficient space for your widgets to render 
correctly. If you need to render volumes of data that won't fit then 
use area or a list type widget (e.g. text-list, drop-list, table, 
grid, etc).


My aim is to progressively review and rewrite each widget to conform 
to the above design philosophy, starting with the simpler widgets 
and leaving the more complex ones till last. I'm about half way through 
at present.

And I can guarantee you, that once the style is "over-simplified", 
it can just piss-off ppl. Just look at list-box, allowing you to 
scroll-under the border. The style is small, yet I I am not able 
to fix it myself, and I don't want to care - I just want to use it.

Is there a suitable widget that can simulate the messages list here? 
 I built one before for Vid based upon DideC's code ...

you will find it in the RebGUI directory on xpeers

 ... got it the first time, just making sure I was looking at the 
 most current version. FYI, tooltips had me baffled for a long time 
 (they worked for you, consumed tons of CPU for me) until I realized 
 they were only a problem with the new tab-panel implementation ... 
 which now stores all tabs in a pane and uses the show? attribute 
 to work out which one is visible or not (the original stored hidden 
 tabs in a data block). The fix was simple, change the tooltip code 
 to ignore faces with show?: false.

strip tree widget from drop-tree

 ... the tree widget I'm working on is similar to text-list but with 
 leading triangles (indented by level) that toggle between sideways 
 (close leaf) and down (open leaf). Not sure whether Cyphre's one 
 is based on the same [simple] concept.

Can we somehow align while you do RebGUI 2?

 ... as discussed previously (see post from 10-Mar), with the key 
 points being:


 1) Use (and possible extension) of global UI settings (colors, sizes, 
 effects, behaviors) in %rebgui-ctx.r

 2) Widgets should define a 'rebind func if they need to change a 
 statically bound UI setting (e.g. color)
	3) Use the new tab-panel widget

and a fourth:


 4) Layout uses 'tip (not 'tooltip) to specify the widget's tip string!


Note that the current build has had most widget-specific exceptions 
removed, especially from %rebgui-edit.r; and that /dialog (hence 
popup) code has been rewritten to support true modal dialogs (that 
can in turn call additional modal dialogs). The later improvements 
are courtesy of recent REBOL/VIew popup changes.

I'm looking at adding a simple format mask attribute to RebGUI for 
editable widgets such as field, area, edit-list and drop-list. Basic 
idea is that if a bitset! exists in the spec it is assigned to a 
new 'mask attribute which is checked prior to every keystroke that 
would insert a char into the text attribute. This would allow specifications 
such as:

	display "Test" [
		field (charset [#"0" - #"9"])
		field digits
		area no-special-chars
		field phone-chars
	]


and has the advantage that the code resides within the RebGUI edit 
feel and can be used by any editable widget. Specification, as above, 
is also natural as bitset! is not mapped to any other attribute and 
is a natural mapping for character edit masks.


If an invalid char is encountered then the keystroke will be discarded 
and perhaps the field can blink or flash as a visual cue?


I'm also toying with adding a datatype! attribute to the spec which 
would be used like:

	display "Test" [
		field digits integer!
		field digits-and-seperators date!
	]


and create an on-unfocus trigger that tries to "set-text self form 
to-datatype" and blanks or blinks the field on failure (and prevents 
leaving the field).


Need to nut out exactly how this would work, but the question is, 
is this useful for folks; or is it more trouble than it's worth (given 
that it is not a fully fledged edit mask solution).

What font names look good? List them here and I'll add them to the 
default ones.


Note that as the new ctx-rebgui/font? function filters out fonts 
not available on the machine running RebGUI we can build up a superset 
of default font names for the big three: Win, Max and *nix.

Ashley;  Well I'm more confused than when I started.  I got sick 
of bad Courier and fixed it.  It had to do with the order of 100dpi 
and 75dpi font lists and removing ghostscript font mapping.  Anyway, 
now REBOL/View can't find Serif, Sans Serif or Monospace.  The "real" 
names "DejaVu Serif", "DejaVu Sans", and "DejaVu Sans Mono" work 
in font [name: ] blocks.  So, I can't help much yet.

The short list (and I'll need to look into this more)  is
DejaVu Sans Mono
  for a good font-fixed
DejaVu Serif
 for a good font-serif
DejaVu Sans
 for a good font-sans-serif
These names may be very specific to my setup...not sure yet.


These fonts should map to "Monospace" "Serif" "Sans Serif", which 
I just broke.


And after I mucked around   the stock font names, which on this REBOL/View 
 2.7.5.4.2 18-Mar map to

font-fixed = "courier"  font-serif = "times"  and font-sans-serif 
= "helvetica", all look way better now.


Maybe I'll just let you get on with it, and quit mudding the waters 
 :)

IMO it's required
 ... agreed. Added to both table and text-list.

Build 74 uploaded to SVN. Includes the following additions:

1) New action object used as follows:

	box "" red
		on-click		[
			print "click"

   system/view/focal-face: face	; required to pick up scroll events
			system/view/caret: face/text	; required to pick up key events
		]
		on-alt-click	[print "alt-click"]
		on-dbl-click	[print "dbl-click"]
		on-scroll		[print scroll]
		on-key			[print ["key" event/key]]
		on-over			[print "over"]
		on-away			[print "away"]
	;	on-focus		[print "focus"]
	;	on-unfocus		[print "unfocus"]

2) New layout keywords added as follows:

	text "Test" text-color blue
	text "Test" bold
	text "Test" italic
	text "Test" underline


3) New 'examine function added to provide detailed information about 
a widget:

	>> examine table

Also a number of fixes:

1) Multi-row Shift hilight selection fixed (pekr)
2) Dialog has parent option by default (Frank)
3) Keystrokes on a button no longer passed along (Graham)
4) request-password enhanced to allow following:

		request-password/check [if (length? text) < 6 ["Problem"]]

5) /scroll option removed from display

6) /min-length & /max-length refinements removed from request-password

7) /no-action option added to select-row function of table & text-list


WARNING: These changes are wide-reaching and have not been fully 
tested ... some things may have been broken. Full documentation in 
preparation.

Pekr; If this is an open question, and not just to Ashley,


I use what I'm given.  In that I build apps (not many so far) using 
the toolkits I see in front of me.  I'll definitely retrofit my existing 
Fire and Rescue Management app with a Menu once the flurry of RebGUI 
development slows down a bit (and please don't slow down, love the 
flurry).


Unless my systems crash, I spend zero time optimizing, wait I take 
that back, I try and follow my own style guides while I'm writing. 
 There is the odd backtrack to get a tab panel to line up nicely 
inside another.  Other than fixing glaring visual ugliness, no optimizing.


I design with a 'small town business model'.  I hand deliver applications.


If I go and snag a feature that goes quirky during my initial testing, 
I dump the widget and look for another.  My 0.4.0 build of RebGUI 
had sticky persistent drop-list's so I used labels and a special 
requestor.  I'm not sure I'll retrofit these.


The easier things are out of the box for me, the happier.  Give me 
the tool, describe how it works and I'm satisfied (when it's as elegant 
as REBOL, RebGUI and RebDB).

Build 75 uploaded to SVN. Fixes some problems introduced in build#74 
and improves widget documentation. See here for a complete list: 
http://www.dobeash.com/RebGUI/widgets.htmland also the updated %tour.r 
Widget and Function Ref tabs.

hmm, maybe drop-list and-edit list could work with keyboard (arrows, 
scroll wheel) too, but those are all imo minor features missing ...

dbl-click for table & text-list broken by build#74. On the list to 
fix.

mailing list

Looking at the new algorithm again, a lot of effort goes into weighting 
word use (the values block) which in turn is only used in one place 
... to determine the "best" candidate replacement. Given that a spell-checker 
just needs to return a sorted candidate list and the remainder of 
the algorithm handles this quite well, I'd be quite happy with a 
cut-down version that excludes the whole dict/values logic. That 
way I could use the existing dictionary files I have sourced (sans 
soundex codes).

Error looks like it comes from old drop-list code.

I am using your drop-list code .. no changes.

Agreed. It's one of the things my users have asked for (especially 
on drop-list/edit-list).

A list of your changes would be good, might help to nail the remaining 
problems.

Hmm.  I'm stuck in a edit-list .. can't tab out of it

what a life .. trapped in an edit-list!

I have edit-list in caret-on-focus

and I did a show-focus to get to the edit-list

Uploaded build#81 to SVN. Includes the following changes:

	Fixed label & text auto-sizing (now defaults to -1x-1)
	Spinner now accepts an empty starting value
	hilight-on-focus now works again

 [edit-list field password spinner] are now hilight-on-focus (area 
 remains caret-on-focus)
	edit-list fix

Also updated:
	http://www.dobeash.com/RebGUI/widgets.html
	http://www.dobeash.com/RebGUI/functions.html

why table and text-list are not hilight on focus too?

write my own non-modal ones
 ... what do you do about drop-list and edit-list then?

Agreed, but it's not high on my list of things to do.

An error has occurred.  If this occurred with an upgrade, please 
revert to the older version for the meantime, and report the error 
message as documented below.

make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'clear
    arg2: 'series
    arg3: [series! port! bitset! none!]
    near: [clear f/text 
        all [f/type = 'area f/para/scroll: 0x0 f/pane/data: 0] 
        f/line-list:
    ]
    where: 'clear-text
]

It's occuring only on edit-list widget where there is some text displayed

>> display "" [ el: edit-list data [ "1" "2" ] button "Set" [ el/text: 
1 show el ] button "clear" [ clear-text el
]] do-events

** Script Error: clear expected series argument of type: series port 
bitset none
** Where: clear-text
** Near: clear f/text
all [f/type = 'area f/para/scroll: 0x0 f/pane/data: 0]
f/line-list:

Yesterday I saw interesting widget - kind of tree combined with list-view. 
You simply had tree-view as basic view, but when you uncollapsed 
the node, list-view (table) appeared ... interesting - It allowed 
to logically nest into subcategories, e.g. company, orders, companies 
- list of orders in table style ...

well, not /insert .. perhaps /ins

set 'set-text make function! [
	"Set and show a widget's text attribute."
	face [object!] "Widget"
	text [any-type!] "Text"
	/ins
	/no-show "Don't show"
	/focus
][
	unless string? face/text [exit]
	either all [ ins face/caret ][
		insert skip head face/text face/caret form text
	][	
		insert clear face/text form text
	]
	all [
		face/para
		face/para/scroll: 0x0
		all [face/type = 'area face/pane/data: 0]
	]
	face/line-list: none
	unless no-show [either focus [set-focus face] [show face]]
]

On the list. (when I get a moment or two I'll actually add this list 
to the Trac Wiki; that approach works better than tickets for me).

Something like:

set 'set-text make function! [
	"Set and show a widget's text attribute."
	face [object!] "Widget"
	text [any-type!] "Text"
	/caret {insert at cursor position}
	/no-show "Don't show"
	/focus
][
	unless string? face/text [exit]
	insert either all [ caret face/caret ][
			at face/text face/caret 
	][	
		either caret [ tail face/text ][	clear face/text ] 
	] form text
	all [
		face/para
		face/para/scroll: 0x0
		all [face/type = 'area face/pane/data: 0]
	]
	face/line-list: none
	unless no-show [either focus [set-focus face] [show face]]
]

Missed that one when I converted actions over to on-*. Change:

	unless no-action [action self]

in %table.r to:

	unless no-action [action/on-click self]

Text-list is OK.

Build#91 uploaded to SVN with inbuilt ESC handling. The processing 
 logic is:


1) If a widget has focus (e.g. an area or field) let it handle the 
ESC
2) If it's assigned to a widget then do the associated action

3) If a popup (including choose: drop-list, edit-list, menu) is active 
close it

4) Otherwise, treat the ESC as a close event (i.e. invoke close handler, 
check for app exit, etc)

drop-list: I face the same problem as with check-group, where I need 
an ID for the entries. For example:
	- I have a drop-list with country names
	- My app supports DE and EN language

 - Depending on the language, the drop-list has different data and 
 shows different texts

 - to avoid a database lookup, internal LUT, I would like to get back 
 an ID of the entry
	- this frees me to use the (changing) text representation

As last time, my radio-group change wasn't liked. We will derive 
a special kind of drop-list.

Robert, how would you like your drop-list strings to be associated 
with your id's ?
1)
	data: ["apples" "bananas" "cherries"]
	ids: [3 15 220]
or
2)
	data: [ [3 "apples"] [15 "bananas"] [220 "cherries"] ]
or
3)
	data: [ ["apples" "bananas" "cherries"] [3 15 220] ]

or something else?

Couldn't the data block *index* of the currently shown string be 
stored in an attribute of the drop-list face ? When the action is 
called, you could then access the index and refer to your list of 
ids which you maintain separately (and however you like).

Robert, give us some of the actual strings you put into the drop-list.

This is interesting to me because I will write a VID drop-down list 
shortly, and the application requires showing only a certain field 
from a multi-field row of information, but without losing the association 
with the row. The displayed text is not a key field in the row in 
my case either.

drop-list:	data [1 "apples" 1 "bananas" 2 "cherries" 3]

Like in radio-group. Preselecting entry 1.

index: Changes if you have entries order changes. Alphabetical sorted 
list of same things in different languages can have different order. 
Solution must be position independent.

Can the data change during the life of the drop-list ?

Robert, looking at drop-list.r, it appears to me (*if* you can guarantee 
unique strings in your data) that you can maintain the selected id 
externally using the on-click action.

This is something that potentially affects many list-type gadgets/widgets.

(As possible with the original VID list style.)

But I think you're right, the fastest thing to do is derive your 
own drop-list widget.

Can the data change while the drop-list is open ? ie. you click the 
down arrow to open the list, then some other asynchronous event in 
your program changes the data and asks the drop-down to refresh itself. 
(This is pretty extreme, but, just in case.)

Ok, so DROP-LIST calls CHOOSE, passing it DATA.
Then CHOOSE makes a popup FACE-ITERATOR, linking it to DATA.

The FACE-ITERATOR's PANE function just assumes the data is one item 
per row. (Or shows each complete row of the data.)

Robert, I have it working. I derived 
	drop-list.r -> drop-list-Anton.r     3 lines changed and 1 added
and 
	choose.r -> choose-Anton.r     1 line changed

Official CHOOSE probably doesn't want to be modified, but you could 
just add the modified CHOOSE function into the drop-list.

Another way of achieving the same effect is to simply populate %locale.dat 
with the required language/domain specific substitutions and let 
layout do its thing. e.g.:

	words: [
		"AAA" "My-AAA"
		"BBB" "My-BBB"
	]

then:

	drop-list data ["AAA" "BBB"]


I just don't see how changing radio-group and drop-list [only] solves 
anything. What about text-list, table, drop-list or any other widget 
that display's a value or values?

Ashley, for tables I have always a hidden column with a record ID. 
This ID is used through all the program.


For drop-lists I "store" the text of drop-list/picked at the moment. 
Hence if you have several languages, at one time you store the DE 
version at an other one the EN version. So, one solution is, I have 
to translate to the "master" language that's used in the database.


But what if syntex changes? Than I have to update all old entries. 
Using IDs frees me from this but adds an other level of indirection. 
The common way would be to normalize my database model and use other 
tables to get IDs, and than store those etc. IMO that's the way to 
make apps complex and slow.

e.g. you have a list-box for fruits: ["apples" "bananas" "cherries"] 
.... that can't be sufficient in any way - it could be, if those 
"texts" could serve you as index to some localisation table:

langs: [cz "Cesky" us "English" de "German"]
fruits: ["apples" "bananas" "cherries"]

trans: [ ;table-id (name), lang, key, translation
fruits  [
    cz  [
       "apples" "jablka"
       "bananas" "banany"
       "cherries"  "tresne"
    ]
 ]
] 

select trans/fruits/cz "apples"

just an example (not practical one :-)

I18N: We have written an own I18N system, that can handle all UI 
aspects dynamically. Table columns, drop-list data etc. Works very 
well. And it can be used not only inside GUI stuff but through the 
whole code.

For example you just specify the "master-language" drop-list data, 
provide a translation and it will change on the fly.

If I need to translate UI, drop-list elemetns plus whole data, I 
refuse to use external system for it - it belongs into tables with 
other data, at least if it concerns data itself. UI elements can 
be in catalogues, no problem here. But - whatever works for particular 
usage case is ok ...

Build#94 uploaded to SVN. Contains minor tooltip, drop-list, request-menu, 
on-click and on-alt-click fixes.

I've renamed mine thus:
rebview1.3.050.3.1.exe
rebview1.3.061.3.1.exe
rebview1.3.2.3.1.exe
rebview2.7.000.3.1.exe
etc. so that they sort correctly in the file list.

Is there a way to make a horizontal scroll bar on a table?  Or maybe 
to make a text-list or area have the horizontal scroll bar?  It may 
be to use the slider widget, but documentation is a bit scarce.

effects/radius: 0 for group-boxes?
 ... effects/radius is global. It is currently used by:

	group-box
	panel
	tab-panel
	tooltip

and can be set as follows:

	ctx-rebgui/effects/radius: 0

Is there a way to make a horizontal scroll bar on a table?

 No, nor with text-list or area. Same issue with tab-panel. This is 
 quite deliberate and you may wish to refer to my comments from 10th 
 March this year headed, "A word on my design philosophy, ...", to 
 see why. ;)

I got it
SAVE %listdir.r  :LIST-DIR

Try
  mold :list-dir
to get the source in a usable form

Interesting,  MOLD :LIST-DIR returns the results inside of { }, where 
:LIST-DIR doesn't

or you can use the clipboard
IN R3:
write clipboard:// to-binary mold :list-dir
(similar in R2)

I noticed that under HELP LIST-DIR, the arguments state 

    path -- Accepts %file, :variables, and just words (as dirs) (file! 
    word! path! string! unset!)

I get the first two ie  %/c and  :VAR-DIR, but what about "just words..."
Can anyone give examples of the third type of argument?

it should work as-is to my mind
list-dir c
(same as list-dir %/c)

The relevant portion of the LIST-DIR source is this:
    switch type?/word :path [
        unset! []
        file! [change-dir path]
        string! [change-dir to-rebol-file path]
        word! path! [change-dir to-file path]
    ]
You should try SOURCE MORE for a simpler example of this method.

LIST-DIR is one of the console interactive functions, so it is acceptable 
for it to have an optional parameter without a refinement - otherwise 
you should avoid that method. The function you should use inside 
code, rather than interactively, is READ.

LIST-DIR currently needs work (mostly better formatting), but the 
behavior you describe is by design.

In R3, have we a function to replace a list of values by anorther 
one currently ?
(don't remember)

About LIST-DIR:

R3 have some UNIX kinda commands, like ls. I think, Carl was tired 
of typing:
list-dir %script
and just wanted to type:
ls script


But it doesn't work with /c, because it's seen as a refinement datatype, 
and ls doesn't allow that. It's a mistake, as I see it. You can do 
it by:

myls: func ['path] [ls (form path)]
myls /c

I think that nothing is set in stone, ne? It all started with the 
lack of decomposition from gob to face, no? Maybe the system could 
keep the list of references somewhere, no? Or simply face could be 
extended with the list of gobs it is composed from?

Generally we'll have to talk to Cyphre one day. His bug list is getting 
quite large.

Anton, the --do bug is known, cross-platform (not just Linux), and 
part of a half-dozen bugs that can be fixed by rewriting one function. 
It's the next R3 thing on my todo list, when I get the chance. I'm 
swamped with work at the moment.

BrianH, cool, that it's next on your todo list - glad you've noticed.

I tried in r3-alpha to make a list of things, to be tested, with 
a hierarchy from a description from Carl. (The r3-status.r script) 
But it didn't happen the way, I had in mind.

Geomol - I have to object. Before complaining about the way the projects 
is run, please check the following:


 - do you really understand, how the project is being run at all? 
 Because quite frankly, you are not using fair arguments here imo. 
 I can agree, but only to some extent, that things are being done 
 in a chaotic way. But - being close to Carl and trying to listen 
 to him and COMMUNICATE with him, I can understand the aproach he 
 takes. 


- one of your false arguments is, that putting things into CureCode 
is not helpful - CureCode was chosen by Carl and the community as 
a streamlined channel for bug reporting. Now please don't tell me, 
that even some low level bugs are not reported? There is a changelog 
which simply proves you being wrong.


- Before some releases Carl asks BrianH to change CureCode items 
rating to fix most important stuff - so how comes that our aproach 
does not work? Please post bug reports, talk to Carl or BrianH to 
raise the importance - doesn't following section show we finally 
got our requested - release early, release often?
http://www.rebol.net/wiki/R3_Releases


- and to be honest - you are one of persons being added to the r3-gui 
world. Some time back Carl had to add even lamer like me to the list 
:-) - and you know why? Because he was not getting much of response. 
He nominated top community gurus to help with the GUI. Actually, 
the same happened during the Gab's VID3 project - only me, Henrik, 
and BrianH commented. It seems to me that some ppl prefer to chat 
about science and belief systems instead of helping to develop R3 
;-) (I am not dismissing anyone's right to come here to chat about 
anything - this place is really a rebol pub where we meet, but the 
other worlds were specialised, yet lacked the input from community, 
even if asked for help)


- in order to get more ppl involved in R3 development at native level, 
it is clear where do we need to get - we've got R3 chat to be base 
of new Altme, new BBS, new DevBase. In March plan Carl clearly outlined, 
that in order to get sources out, we need rebin, plugins. They are 
now postponed due to modules, security, but still a high priority. 
How do I know? Because I was not lazy and asked Carl the specific 
question.


- we also get improvements on other fronts - we have got new streamlined 
Docs. I suggested Carl to add community section, then also new R3 
section to rebol.com page and to produce detailed changelogs. These 
all are small steps, but steps which make a difference.


Now please tell me - how complaining here can make situation any 
better? How many bugs have you posted, how many rebdev messages you 
have asked to Carl? Why don't you talk about your concerns with Carl? 
He will respond to you, like to me or anyone else - either via chat, 
or via a Blog article.


As for me, I am quite fine with how R3 is progressing last few months. 
Yes, we are slow on the whole project, but we are still doing a good 
progress imo.

Responding to Pekr's comments:


- I've communicated with Carl privately before. Starting on the OS 
X port more than a year ago is one example. Lack of info back to 
me made me stop. It's in a group in r3-alpha, you don't have access 
to.


- About CureCode, I didn't argue, it's not helpful. I don't care, 
what bug report system is used, as long as it works. Curecode is 
one of the best such systems, I've seen. Yes, low level bugs are 
reported. That's not the problem. It doesn't make much sense to me 
to work on a building (in lack of better metaphor) at the 123 level, 
when the basement isn't stable. Question is, how long this situation 
will last, before I see a stable version across platforms. My guess 
is years, therefore my concerns.


- r3-gui. Again it doesn't make much sense to me to work on GUI, 
if the core has many bugs.


- You list many topics in monthly plan. Development is going on at 
all levels of the building. I would start by making a solid basement, 
then make my way up. Making any level finished, before going to the 
next. It's just another way of doing things. I have good experience 
doing it the way, I try to describe.


- About docs. It's about time, something is done with the docs. I 
had huge problems figuring out, even how to test R3 back in the r3-alpha 
days. Docs were confusing, lack info, etc. Some months ago I tried 
to figure out, if I could port Canvas RPaint to R3. I stopped quickly, 
when I couldn't find the docs to do even simple things.


Well, you ask, why I complain. Initially I just said, how I felt. 
Loosing faith in the project. I really hope, it'll happen one day. 
But as I see it, it'll take years. I feel like sharing this view 
with others. Then you can use it as you wish. I need to figure out, 
what I'll do with my own development.

If you don't watch Chat, you probably also missed Carl's info - he 
is working on a list of items, which will turn R3 into beta.

I made r3-status.r script based on that list from Carl. So no, not 
ignored.

I also worked with someone in r3-alpha to do tests, that would make 
all those low levels a green ok in r3-status.r.

What I mean is, let's take first point in Carl's list. Scanner bugs. 
Are there any? Is
--1:23

a bug? Yes, it is. I don't have time to find all these low level 
bugs, but it seems, I easily find some of them, when I start looking. 
So problem maybe is, that people are not looking, and Carl don't 
document, how people can look for these things. It's because the 
whole thing is closed to some degree.

Pekr, look at the bugs in Curecode and look at the test priority 
list by Carl. The bugs are reported, and they are not fixed for years. 
And new low level bugs emerge now and then. My guess is, because 
they way, the whole thing is run. Work on all levels of the building 
at the same time. Not good.

Pekr, this example with proxy, we see things differently. As I read 
your words, you're complaining, we don't have proxy for the http 
scheme (after maybe 2 years). I can only talk for myself, but the 
reason, why I don't look into things like that, is because it's way 
down on Carl's list (maybe third or fourth priority). I would like 
to see the first levels bug-free and stable, before I move on. (And 
you don't hear me complain about proxy. :-) )

It's a bug in the first of Carl's list of alpha testing priorities. 
We should be far beyond this level, but we're not.

Steeve.. I don't care if it's hash, map, list, block or object.. 
I need fast lookup for key-value pairs

I used hash! to build a long list of de-duplicated words. It was 
by far the fastest way in R2.


I was pleasantly surprised when I found that using map! and storing 
every associated value as #[none] was quicker in R3 than hash! in 
R2. It just seems wrong to be wasting all that memory storing all 
those unnecessary ones.

Devbase contains detailed list of stuff which is going to be a 3.0 
release. The link is not supposed to be made webpublic though ....

BrianH: do we post R3 beta item list somewhere here in non web-public 
group, or we keep the link in Chat only?

Got it... NF to list new files

Is there any command to list all topics with files?

BrianH;  All my nodes have a %user.r.  I define all my comand line 
shortcuts there.
Things like

ls: :list-dir
dir: :list-dir
cd: :change-dir
pwd: :what-dir

~: :view-root
.: %.
..: %..

scripts: :view-root/library/scripts


And those usually work best with GNU/Linux when I just know it'll 
look in ~/.rebol/view

you may come with something completly different, i just want the 
list of variables which have different values

Steeve, I can guarantee that if bugs are not reported they won't 
be fixed at all. It is completely inappropriate to compare the R2 
project to the R3 project. Bugs weren't getting fixed in the proprietary, 
release-rarely R2, but they *are* getting fixed quite regularly in 
the semi-community, release-often R3 project.


We are in alpha, and still in the design phase with much of the core 
of R3. We only have so many people actively contributing to R3, only 
so much capacity. And you might recall how much we have been insisting 
that people not use R3 in production yet, that it is not ready. This 
means that the main product that is setting the priorities of what 
gets fixed or implemented is R3 itself. And that product is still 
being built.

No regression allowed

 - are you kidding? Large quantities of R3 are brand new code. It 
 isn't regressing, it just hasn't caught up yet.


And don't assume that the code will work the same in R3 as in R2 
- we aren't even trying to be compatible with R2 except where appropriate. 
We're fixing design shortcomings in R2, not just bugs, and that means 
incompatibilities sometimes. Compatibility with R2 is considered 
a nice thing to do, but not as high a priority as doing things right, 
adapting REBOL to handle the needs of today and tomorrow.


And speaking of priorities, they are not absolute. We set priorities 
relative to what we are working on now and what we will need next. 
Once those things are done, we bump the priorities of the next things 
on the list.


We recognize that vectors are important, but they are not as important 
as security and modularity *right now*. We needed modules settled 
now because the plugin model depends on them, because it would help 
us design the security model, and because the GUI and mezzanine code 
needs organization to be further developed.


We need the plugin model because it affects the host interface design, 
and the host interface needs a redesign before we can release the 
host code. We need to release the host code so that more people can 
fix bugs like that OS X bug PeterWood mentioned.


Things are going to get fixed, but most fixes require other things 
to get done first. We are focusing now on the bottlenecks, the bugs 
or waiting improvements that are blocking the most. Right now the 
highest priorities are those that are blocking people from contributing 
to R3, because the resource we have the least of is people that are 
willing to help.