AltME groups: search

radio-group - will do, later today.

table font size - you guessed correctly, it uses the global setting. 
I'll see how easy it is to get font [size: 8] working with it (like 
other basic widgets).

hmm, but that is how radio buttons were meant to be - always just 
one answer. If you need something like that, I am not sure it is 
good design to have no radio button in a group having selected, because 
you can't do reverse operation - once you click on either option, 
you can't get back to state, where no radio group is selected. So 
- my opinion is, that in such case you should add another option 
to your group, stating "none" or something like that. Well, just 
my opinion ...

what do you mean by "more consistent look"? Overall refactoring of 
RebGUI? Hmm, maybe Henrik needs to be put on contract for one week, 
to change default coloring and styling, to make RebGUI more attractive 
:-)

yes, it's harder to do nice looking buttons against a bright background.

But, imo, if you want to change fields, it should be on pair with 
drop-downs etc., which do use field too ... and if you put fields 
into tab, group-box, those would need change too imo ...

I would finish button first - making it taller few pixels? Then move 
on to tabs maybe .... group box and panel - do you like them rounded? 
I am not sure what my own answer is :-)

I also feel like doing a bitmapped theme. It's easier to do.

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.

I haven't delved to deep.  The last cut of RebGUI I pulled out of 
svn causes a segmentation fault on my Debian Etch RC1 system.

>> do %tour.r
Script: "RebGUI widget tour" (16-Feb-2007)
Script: "RebGUI system" (18-Feb-2007)
>> q
Segmentation fault
[blue-:-dev]:~/gui/rebgui$

Note I did nothing other than start tour, and close it

REBOL/View 1.3.2.4.2 16-Mar-2006 Core 2.6.3

[blue-:-dev]:~$ uname -a

Linux dev 2.6.18-4-686 #1 SMP Wed Feb 21 16:06:54 UTC 2007 i686 GNU/Linux

Just so ya know.

build#60 committed to SVN. Added Henrik's button widget with 2 minor 
modifications:

	1) Over color defaults to colors/over
	2) All of init inlined into the effect facet


The first change is self-explanatory, the second follows the principle 
that init should do as little as possible (facet code is evaluated 
once while init code is evaluated every time the widget is used). 
This change has one subtle side-effect, the "Refresh Display" button 
of %tour.r no longer works for all widgets (button in particular). 
This will be fixed in a future build.


One thing to note about the new button widget is its default size: 
15x6 instead of 15x5 units. This should not be a problem for most 
buttons, but may have spacing/alignment issues for inline buttons.


Note that the button change necessitated a small change to request-date 
which is now working again.

Anyone have an example of how the drop-tree works?  This brings up 
a drop tree but can't figure out how it is supposed to work yet


display "drop tree test" [ drop-tree data [ "root" [ "item1" [ 1 
2 3 ] "item2" [ 4 5 6 ] "item3" [ 7 8 9 ] ]] [ pri
nt face/text ] box 40x60 ] do-events

If you do change it I will just have to keep the old version

Robert, did you get a chance to do the tool-tip test with tour.r 
against your version of rebgui.r? If so, what was the CPU reading 
and what value did you have for tool-tip-delay? As I mentioned before, 
I think tool-tips are dying on 'find-face when the display is sufficiently 
"complex".

I think we drift to far away

 ... depends on the extent to which you have changed/enhanced core 
 RebGUI functionality (e.g. rebgui-*.r scripts). If most of your changes 
 are isolated to new/enhanced widgets then there is really no drift; 
 you can plug your widgets into the standard RebGUI engine and it 
 will all work. If you want to keep your changes in sync then I suggest 
 2 simple practices:


 1) If you need a version of a standard widget (e.g. radio-group) 
 to do things that are app or design philosophy specific then create 
 your own widget instance and suffix it with an identifier, say XP 
 for XPeers in your case (e.g. radio-groupXP). Suffixes are preferred 
 over prefixes as the alphabetical sort order of the widgets determines 
 their load order which may affect dependencies ... see text.r and 
 label.r for examples of this.


 2) Only keep and maintain a divergent Widgets directory ensuring 
 that your widgets continue to work with the standard RebGUI engine 
 (i.e. rebgui-*.r scripts). If you need the base engine enhanced (e.g. 
 to support tool-tips or proportional resizing) then let's isolate 
 those changes and get them into the base distribution.


You should be able to create and maintain your own widgets without 
worrying about divergence as most of the design effort should be 
going into the functionality of the widget(s) themselves. If your 
widget needs specific changes/enhancements to the base engine then 
we need to sync those changes at the point you need them. Trying 
to retrofit these after the event, and after multiple divergent engine 
changes, is going to cause problems as you've discovered.


From my end, the 3 major changes you should probably try and work 
back into your fork are:

	1) UI settings: mostly confined to rebgui-ctx.r

 2) rebind func added to all widgets prior to init and rebgui-widgets.r 
 enhanced

 3) tab-panel rewritten to operate significantly more efficiently 
 (tab-panel.r and associated rebgui-edit.r changes)

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.

BTW: Can we somehow align while you do RebGUI 2? I want to follow 
the new release and provide our code to it as well.

Now I have hundreds of these requesters coming up 


The file framework/libraries/gui.r was modified locally and a new 
version from the server is available. Do you want to create a backup-copy 
of the local file?

finished now .. it was about 50 files or so that I had to do this 
for.

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'll do some more investigating and get back to you here.  Thanks 
again.

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

As RebGUI is aproaching 1.0 release, I would like to know your opinion 
on following - how do you construct and optimise your GUI? So far, 
if you look at tour.r, it reminds me of one big dialog configuration 
box. Not sure what to do about it, maybe it is a given, as widgets 
we have do suggest such layouting. This debate could open discussion 
about eventual addition of potentially missing widgets. My questions 
are:


- are you missing kind of MDI application scheme? Parent window, 
containing one or more child windows, which are not able to being 
moved away from its parent. We used that design much, but I am not 
sure anymore it is vital, as with latest system, we use two monitor 
set-up, and by simple accelerator key we can navigate window being 
moved between displays. Having MDI available, we would probably need 
rebol/view native windowing system. So - is anyone missing something 
like that?


- do you somehow optimise your display? Isn't it like following? 
- with using tabs, everything is in memory, whereas it eventually 
is not needed? How do you divide your application, if you would like 
to have kind of load-on-demand aproach?


What styles do we miss, to further help us have more complete GUIs? 
I created screenshot of potentially two usefull widgets:

http://www.xidys.com/widget-drop-tab.jpg
http://www.xidys.com/widget-vertical-tab.jpg


Especially with the second one, I think it could be usefull. It is 
used by many applications. It is kind of mixture of tab and tree, 
but not necessarily with multi-level aproach, just one level of nesting, 
mostly represented by icons, text, or icons plus text. I would like 
to know your opinion.

Do you think that it would be possible for tour.r, to include e.g. 
one tab, showing how focusing works, including buttons? E.g. by default 
some element would have focus and you would be able to tab-focus 
between most ui elemetns?

... and I must laugh, as we still think, that most ppl are able to 
sort out, what to actually do. That is total mistake, however, and 
prevents many from even trying rebgui.

isn't it possible to do some automated builds to .zip file? PeterD 
- I can sedn you new version from time to time ....

The 'correct function is *very* slow, takes almost 4 seconds to do 
the following:

	>> correct "caustic"


Also, where is the bin file sourced from and are other languages 
supported?

Wonder how easy it would be to do real time spell checking?

how easy it would be to do real time spell checking

 ... with a cut-down version of Ladislav's code (mainly limiting edits 
 to one char distance) speed is no longer an issue. I'm looking at 
 using draw to red underline all spelling errors in a text face and 
 then only popping up the spellcheck box on right-clicking a misspelled 
 word.


Problem is synchronizing red underlines with scrolling. R3's rich 
text support would make this trivia [by comparison] to implement.

Updating my script to latest rebgui .. have to do show-color: :set-color 
etc as too much code to change.

F1 - F12? Do you have a sample of the code you've had to add back?

sometimes one has to do these things !!

Is it safe to assume that messages will always be in ascending age 
order? i.e. Do we need to cater for message insertion at top? Or 
message numbers that are in descending order? I want to avoid having 
sortable columns. Simple but functional is good.

do [insert face/options 'no-title]


or you may want to create the face directly in view with the 'no-border 
option

I asked Cyphre to do so, even to upgrade Grid to follow beta 2. I 
hope we have only one system, not incompatible forks.

the problem with the chat widget is when I try to fill it in the 
do block of the display

I used it as many others. I and others found problems on lower levels, 
reported them, but some are still not solved.


Take money! as example. At some point, it became impossible to specify 
currency with the money! datatype. When did that happen? Why wasn't 
it noticed (maybe it was, I really don't know)? Why hasn't it been 
fixed? Other bugs depends on this datatype. I won't do the detective 
work to figure this out. Proper testing sessions would have found 
it, as soon as it emerged.

Gabriele, would you like it to be open? How do you see the R3 project 
heading?

For me is R3's show-stopper missing hash! and still buggy map! which 
is supposed to replace hash! So I agree with Geomol, that the core 
bugs should be fixed before playing with the high level or new functionalities 
(like threads). But I'm not so pessimistic, the things move on. And 
I don't need R3 so much now. I can do what I do in R2.

For the last few releases we have been working on stuff that is even 
more core than datatypes: Getting modules, LOAD, DO and codecs to 
work right. These are so low-level that even Unicode bugs are lower 
priority right now.

whoever asks here, gets info from those informed, most importantly 
from BrianH. Now tell me, with other technologies - do you ever get 
so close to the core dev team? And please don't try open source crap 
on me. Python is open-sourced, yet 3.x effort was done by concentrated 
team.

I will go so far, that I even think that some part of the community 
became so ignorant, that making R3 fully open sourced would not change 
a bit of this situation. Some real work is needed, and ppl here complain 
that they don't have time to even scan sources of available info. 
Now tell me, how the same ppl are supposed to do any quality code 
for R3, even if it would be open-sourced? Once again - GUI is open-sourced, 
protocols are open-sourced, yet ppl don't even care to test or give 
a feedback.

My friend moved to Python (while still using REBOL), claiming it 
is open-sourced. He found some bug, but he was not able nor willing 
to fix it himself. Having sources available was no difference for 
him. He even did not know, where to post bug precisely and he got 
only vague response. Have you ever reported Mozilla or SQLite or 
any other bug? I did. With mozilla it sitted there unfixed for one 
or two years. So please don't tell me, that fully open-sourcing R3 
would make any difference nowadays, when the product is still under 
heavy design and development. Noone claims it is even beta. If RT 
does not release, we complain, if they do release, we complain. Maybe 
Gabriele and Henrik were right in the past - with such public treatment, 
maybe RT should not release until some beta or RC ....

No, I really don't think. I stated it clearly - I have enough experience 
with management to understand current situation and I can tell you 
- having full sources available nowadays would make NO difference 
to speed or quality of R3 development. When product is stable, I 
can imagine how sources do really help ppl to track potential problems, 
provide fixes. But many parts of R3 are simply missing, not yet done. 
Now how many of us here are able to produce the C code quality Carl 
would accept into REBOL anyway? Sooner or later we are going to get 
plug-in interfaces - then we can experiment with some C code extensions 
...

It's like when carl opens RAMBO some years ago the goal was to get 
some tickets time to time to do some bug fie time to time but as 
teh community worked alot on tracking bugs and doing suggestion the 
number of tickets was massive do you think that's the same thing 
being alone to solve 10  bugs than being alone to solve 4000+ bugs 
?

and submiting a bug with aving a hand on the source code is improvement 
of the information even if in the end that only CArl who solve the 
bug saying him  this doesn't work properly we expect that and in 
the source code we can see that issue and we propose to solve it 
like that what do you think that's in my opinion a better way to 
get dynamism in the community and even ppl skills enhancement  than 
only getting a black box where you can just say when i do that i 
expect that and that doesn't work

It's like making games.. if you are cloning another then you have 
a model that you just need to do as efectively and good as you can 
and add a few features and twists here and there. If you are developing 
an unique gameplay, you don't code it up.. you prototype .. work 
here and there because you learn what to do next as you do things

but then if you make dificult for your clients the way to know what 
you do and when you do  to you think your clients are taking you 
serriously starting from the begining

Imagine a client giving a taste to a programer and the programmer 
flee away don't get any news dor month and then comes back with oups 
sorry here is your program dear client ?  Do you think the client 
 will take that attitude as a serious matter ?

plus no one knows if in the 2 years to come Carl would have a totally 
different feeling on what he wants rebol to do

do I need to NEW-USER ?

PeterWood:R3/GUI/General>> more 3365

 ** Script error: submit-of? does not allow none! for its fid argument

 ** Where: case all submit-of? case what-file? more-file parse try 
 either either forever command-loop make context do catch applier 
 do try chat
** Near: case [

    is-submit? msg [msg]

    is-name? msg [submit-of?..
.

--- Note: unexpected error logged to error-log.txt

you can't. you need a higher ranked person to do that. I'll see what 
can be done.

shadwolf:R3/OS-Targets/OSX>> more 3365

** Script error: submit-of? does not allow none! for its fid argument

** Where: case all submit-of? case what-file? more-file parse try 
either either
forever command-loop make context do catch applier do try chat
** Near: case [
    is-submit? msg [msg]
    is-name? msg [submit-of?...

--- Note: unexpected error logged to error-log.txt

I've been using hash! for a bit, but there are too few advantages 
for it to be directly useful. The main advantage is supposed to be 
speed, but usually when you need to do real work with a hash! you 
need to convert it to a block!, which slows the whole script down 
more than if you just used block! correctly from the beginning.

i want to post in server admin to remove shadw0lf  user how do i 
do it ?

So, what do we want to do about it? We are at a point where we need 
to finalize the hash datatype for REBOL 3.0. It is possible to make 
some change

when do you need hash ... hum when you deal with a database to make 
a cashing system to not have to use the database access on any request 
for example

or when you want to do a similar thing like a dictionnary (for search 
engine design are widely derived from hash table concept)

Pekr r3 doesn't exist ... I know i'm a stubborn moron  ^^ that's 
my way to be 1st it's on R2 complete and full wrokking then i will 
adapt it to rebGUI then i will do REBOL IDE then in that time R3 
will be official released and i will do the port

since that's do the makes the rest of the work more easy to grow

sure in our area-tc taht would be a plus to be able to handle ctrl+wheel 
action to grow shrink the text size (like you can do in any modern 
web browser for example) or to be able to set through a config panel 
the font size and type of your choice

Ok, good enough.  I think that will work.  I'll modify some of my 
scripts to use that method and then do some benchmarks...

What do you think of system object? It looks chaotic to me. It makes 
no sense for me to rename, or move stuff around.

Oh, do you mean %USERPROFILE%, which is similar to %HOME% on Linux? 
It's the same either way, really.

BrianH: yes, but I work in Total Commander, and I work with directories. 
I need to learn how to do some shortcuts, because going down that 
directories to locate some file is a pain :-)

READ/text seems like a lock, sorry. You may think that text is just 
another data format, but it is the *most common* data format, and 
tends to be processed in large quantities. You say that codecs can 
be chained, but they currently can't - you can apply them one at 
a time, with all of the intermediate forms in memory at some point. 
If we do text the way you ask, then every load of text for processing 
will have the additional overhead of a full duplicate of the ram 
and two series moves, plus a few lines of code. READ/text is a shortcut 
that will save a *lot* of overhead during what may be REBOL's most 
common operation.

I don't agree that text preloading would cause a duplicate. Are you 
trying to suggest, that codecs are such pigs, that they do first 
read the whole file, and then decode? Then the system is flawed, 
because what you do with the 9GB video then?

Pekr give CArl the link to the wiki track he will get some of hours 
past days coding experience what we tried and why we concluded in 
doing the things the way we do them

Pekr, right now codecs only decode binary! and encode to binary! 
- I mean values of the datatype binary! that are already in memory. 
So yes, codecs currently *do* require that you read the whole file 
first. Streaming isn't there yet.

but it would be cool to do a whole shell as a module. how much? 10-20k?

I have thought of using user.r or Rebol.r as a way to run a script 
to log my execution of scripts, although I have not done so.  I tend 
to think of those two items as a "hook" where I can execute my own 
generic code for whatever purpose needed.  I have often thought of 
having either Rebol.r or User.r enforce protect on system words and 
then make sure Rebol.r or User.r is read only, but there may be other 
ways to do this better.  I am still new to rebol.

BrianH:  I use user.r for a few little things, but mainly I get it 
to call my anton-user.r script. I forget when but there were some 
instances  (when I was on Windows) where rebol would overwrite user.r 
(testing a fresh rebol beta?). That's why I decided to get all my 
code out of it and just DO my anton-user.r script from it. On linux 
I also set system/options/home where I want (not the user directory).

I don't change environments much. All new rebol executables are placed 
into the same directory and beaten with a stick until they work using 
the same user.r and my anton-user.r script.

BrianH: I don't agree to your nor Carl's reasoning towards patches:


1) I use custom patch for URL ftp format, which goes probably anti 
RFC, but is very practical (@, # in username). Putting those things 
into DevBase is nto an option - it would not be accepted

2) As Carl suggested, building custom rebol.exe is not an option 
too, because - I don't want tonnes of various rebol.exes around, 
one adding this thing, another one changing the other thing.

3) This whole thing is not a big deal, I just will have to add do 
%my-init.r into the beginning of each of my scripts, which sucks 
though ...

Gabriele - I know - but do you remember how RT refused to allow dot 
in the front of email adress, because it went against RFC? :-) Hopefully 
we can fix it.

Gabriele - what is the problem with chunked mode of http 1.1 protocol, 
so that it is currently disabled? Any advice for a set-up, of how 
to debug it best? What is the chunked mode good for? I am willing 
to do some tests to track possible problems, so any quick pointer 
would be fine ...

It should be fairly easy to make the change in REBOL, that you now 
do with a patch in user.r. I'm wondering, why it hasn't been corrected? 
Does it have other consequences?

I would also like to ask about one Carl's Chat message, describing 
DELECT. Do I understand it correctly, that first Carl thought that 
DELECT might be used for some interfacing, but that DELECT is kind 
of functional/procedural aproach which does not fit the concept, 
and hence instead Carl is considering action! kind of aproach?

BrainH: it scares me a bit - dialecting was supposed to be one of 
REBOL's holy grails. Where have we improved performance of REBOL 
specifically? Or in other words - were dialects here because they 
gained us some speed? I think not. 


As for DELECT, I think that with advent of parse improvements, it 
will not be used much, if used at all. What do you think?

Maybe we got unicode encoding end escape encoding confused.


As I see it, given correct rules, auto converting of user input to 
correct url can be achieved. I made this function to illustrate, 
what I mean (it's not optimized, but should be easy to read):

encode-url: func [input /local url components host] [
	components: parse input "@"
	host: back tail components

	url: clear ""
	append url components/1
	components: next components

	forall components [
		either components = host [
			append url "@"
			append url components/1
		][
			append url "%40"
			append url components/1
		]
	]
	url
]


I can use it both with and without specifying %40 for the first @ 
in the url:

>> encode-url "ftp://[name-:-home-:-net]:[pass-:-server-:-net]"
== "ftp://name%40home.net:[pass-:-server-:-net]"
>> encode-url "ftp://name%40home.net:[pass-:-server-:-net]"
== "ftp://name%40home.net:[pass-:-server-:-net]"


It will give correct result in both cases (I use strings, but of 
course it should be url! datatype in REBOL). Now comes unicode. Given 
precise rules, how that should happen, I see no problem with encoding 
this in e.g. UTF-8.


So I think, it's possible to do this correctly. But maybe it's better 
to keep it simple and not do such auto convertions. In any case, 
the behaviour needs to be well documented, so users can figure out, 
how to create a valid url. I had same problem as Pekr years ago, 
and I missed documentation of that.

The O3D plugin from google takes up about 15 MB of disk space. I 
wonder how many kb it would take to do the same thing in R3 using 
ReBrowse.

re the %rebol.r and %user.r files:
* I do not use %rebol.r for anything

* I use %user.r to set up my personal preferences on every machine 
so, that it looks like I expect it to: defining my personal "absolutely 
necessary" functions

Ladislav (continued from Rebol vs. Scheme), FUNCTOR currently isn't 
being used by any mezzanine code, so if we want to change it now 
is the time. If we go with your initialization block idea:

- The initialization would have to be performed at function creation 
time, not first call.

- The init block would be only the starting spec for the static object, 
not  the final spec. We'd need to still do the search-for-setwords 
that FUNCT does, or there'd be no point to including FUNCTOR.
- I'd suggest that the parameters be in spec, init, body order.

Ladislav, the reason we are asking about how people use %user.r is 
so that we make sure that alternate facilities exist to do what people 
did with %user.r, but safely. The old behavior of %user.r will be 
going away in R3 for security reasons. However, we have your uses 
covered by our plans:
- Preferences will be handled by the new %user.r
-You can include your must-use functions in a module.

They could be initialized at first call. We already have facilities 
to do what you describe.

Actually, we are going to make a DEFAULT function, but that is one-value-at-a-time 
until DO/next works.

So far FUNCTOR hasn't really been used, so now is the time to change 
it if we are going to do so. The variable capture is a must though, 
since it will be used where the spec can't be specified by the user.

Currently,  i have a crash  when i start the chat with r3-a48 under 
Vista.
Obviously, i can't see what is the bug, 

And when i try with the previous version i got  (a42)
i got this error: 
--- Note: checking for new messages

*** RebDev Error: server connection failed, is server down? (server-failed)
** Script error: cause-error-here has no value

** Where: error if unless request-serve if check-msgs check-new make 
context do
catch applier do try chat
** Near: error result


We have no way to return in a safe situation and can't guess what 
is the bug indeed.


Is Carl aware of that problem, i didn't see anything related to a 
crash of a48 when starting the chat ?

Please, don't say to me, the only hope is to do a foreach loop.

Steeve, that is the incorrect method. If the bugs are not posted 
NOW, they may be harder to fix when R3 goes beta. We don't know, 
but Carl  has stated several times that when Core issues need to 
be looked in to, we must do that now.

Priority is not a parameter in the REPORTING of bugs. It is a paramenter 
in FIXING the bugs. I don't see how software development could work, 
if everyone posted bugs based on perceived priority on whether they 
would be fixed. Carl expects us to do alot of the work with finding 
bugs. When they will be fixed is up to him.

Steeve - your attitude is the same what DocKimbel showed here some 
two weeks ago. I thought that I am talking to adult ppl, and I really 
don't understand such childish behaviour. Such an attitude is treat 
to those, who try to actually do something. Do you really think that 
the rest of us would not like to have R3 available few years ago?

... everybody is free to do anything actually ...

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.

My only problem is that you have to use the money datatype to use 
this number format. It could be useful in other places. But I think 
we've had this discussion before.

If you do a ? datatype!, in R3 you get:


money!          datatype! high precision decimals with denomination 
(opt)

So you may wonder as a beginner why the description is like that.

Typesets are really useful - do you want to write all of that out? 
Plus, they are implemented as bitsets, so they are really efficient.

Ladislav, I have no idea. What do you need to-binary on decimal for?

it was actually Geomol on 8-Apr, who too refused to submit bugs, 
as those might not be corrected anyway


Pekr, I don't refuce to submit bugs! I have submitted bugs after 
we discussed it here. I just see little point in submitting bugs. 
And I have the practical problem with finding time to submit all 
the bugs, I could. But I do something, I consider even better than 
submitting bugs in the current situation. I have done some development 
lately, that test the REBOL scanner deeply. I have collected all 
my findings in a document, that I'll give to R3 developers, when 
I'm finish. The scanner is just one part of REBOL though.

could you be more specific? what did you do that caused the examples 
not to work?

Brian: do you have proof that value slots are bigger in R3? I'm not 
aware of it being compiled for 64bit system (thus, no 64bit pointers), 
and there's more than enough space in 16 bytes to hold a 64bit integer!

This is the very minimalist event handler i use to do my tests on 
gobs and events.
then, just add your gobs into the main screen gob

set 'screen system/view/screen-gob
unless system/view/event-port [
	system/view/event-port: open [scheme: 'event]
]
system/view/event-port/awake: func [event /local gob offset ev][
	ev: map-event event
	gob: ev/gob 
	offset: ev/offset 
	switch event/type [
		move [...]
		up [...]
		down [...]
		...
	]
	tail? screen
]

append screen make gob! [...]
do-events