AltME groups: search

Behavior and structure are together in the layout, yes, but in a 
way that is easily seperable. And that doesn't matter because the 
layout won't have appearance code in it.

Well, I've done that in my own VID extension kit (which I'm still 
contemplating whether I will release some day): Provide more styles 
with very specific purposes. This strongly reduces the need to be 
specific many times all over a layout and the layout becomes much 
smaller and cleaner. Also avoiding stylize inside the layout helps.

again this also comes from the concept of styles that are described 
by purpose rather than appearance, so you don't want a red or blue 
button, but an ok or close button.

So I have a white "save" button .. but once they edit something, 
the button changes to green.

that could easily be part of a style

you could describe in your layout code that it's a SAVE-BUTTON style 
and nothing else. then in your style code, you add logic to change 
the color depending on the state of your user's need to save content.

Graham, sort of like in browsers where links you have been to are 
a diff colour?
What about colour blind people?

Might be interesting to build a little check box into buttons you 
have already pressed and completed (or something).

In theory you can force people to walk a path, in the case of the 
task example I just gave, we can't do that, since you can click on 
anything.

well, if  you're a Mcdonald user .. put a disclaimer in it!

Make a button a shade of the BG colour, and do nothing.

I'm very carefull of colour blind issues, have been on all my interfaces...simple 
trick in the old days was to view it on a B&W TV or device.

Now I have to take screen shots from time to time nad review with 
no saturation.

That was my point of the "check mark" a little icon.  Check out FamFamFam.com

Although what I would like is a key or button you press that "reveals" 
things about the UI.

Also, a way to view all buttons, and assign keys.  This should be 
system wide.

Anyway I hope R3G has robust keyboard handling .. for speed a mouse 
driven gui sucks

Javascript does a pretty decent job of creating GUIs ... I don't 
think one should be criticized for looking there for inspiration

Javascript *plus extensive frameworks and bug fixes* does a pretty 
decent job of creating GUIs.

and the way you can stop a current animation

Nowadays there is no web without JS
 - I take it you are not:
- Blind
- Using a text-mode browser (similar constraints to blind)

- Running a safe browser (similar constraints to Firefox with the 
NoScript extension)

Of course there is the web without JS - otherwise "Unobtrusive Javascript" 
wouldn't be needed.

Here's a non-contrived example for separating structure from form.

Kib2: Not my call, though I think chat could use better user management 
functions before we open it up again. We need to be able to *delete* 
users and all of their messages to deal with spammers - not just 
disable. We also need for the admin to be able to rename a user on 
request, to cut down on duplicate user accounts when users change 
their mind about their ID - we already have those.

At present I allow users to write a custom screen in RebGUI that 
loads into a tab.  Of course they can write as much REBOL code there 
as they want.  But it would be safer if they just wrote presentation 
layer stuff .. and let my program allow the appropriate functionality.

Eg. if submitting a form, a JS enabled browser would see an acknowledgement 
in the div below the form, but a nonJS browser would be taken to 
a new page with the acknowledgement

Pekr, working for a web company, those "anomalies" are the bane of 
my existence :(

I wonder why there should be a problem to have decent JS engine for 
mobile platforms? Don't they have full browsers already?

Mostly not. Only a few new phones made in the last year come close.

The iPhone is a more popular new phone than any of the other new 
smartphones, but is still a tiny fraction when compared to *all* 
new smartphones, let alone the regular phones.

This is a little off-topic for the group though :(

Oh well, a R3 interpreter written in JS seems necessary then.

Pekr, Brian has a very very long todo list :)

We offer a cool HTML only interface, this ensures we work woth almost 
everything (we call this Amish Quilt)
We plan to offer a step up which offers "some" JS"
Then there is Quilt (JS + HTML only).


Several people are not playing with iPhone only client applications 
that will interface to Qtask.

I expect that my work on some of my todo list will take the form 
of helping others do it - it's more of a to-get-done list :)

However, I was not precise enough about my todo list. No REBOL interpreters 
are on it - I want a REBOL-to-JS compiler.

Who wrote the JS REBOL interpreter I tried a year ago? Gabriele?

I have a question about the Gui_Basics example in the R3 docs.  The 
ex. under Adding styles won't work for me.  title "Opinion Survey" 
comes back with title having no value - this after load-gui

i try to load rebDB-203 in R3 .................          but R3 return 
a error when a try to do a "db-create my-table [id date name]"   
   with  >> db-create "my-table" [id date nom]

** Script error: db-create does not allow string! for its 'table 
argument

** Note: use WHY? for more about this error

i do after if a load %my-copy-db.r

In general you would be very lucky if a fairly large R2 product works 
directly under R3.

or perhaps R3 guru would give us a better way to do this ;-)

is the same for rebgui............il would like to see a R3

a R3 demo that do all rebgui do

The table name you supply to db-create should be a word! not a string!

>> ? db-create

USAGE:

	DB-CREATE 'table columns

DESCRIPTION:

	Creates a table.

	DB-CREATE is a function value
.

ARGUMENTS:

	table (word!)
	
	columns -- Column names (block!)

But when you correct that you get a real R3 compatability error:

>> db-create my-table [id date norm]

 ** Script error: write does not allow string! for its value argument

** Where: db-create

** Near: db-create my-table [id date norm]

It took a full week to compensate for the changes and bugs. I think 
about half of that could be prevented after fixes and more attention 
to compatibility

ok seem we must do a real port effot from R2 script to R3 !!!!!

In fact, it's not the demo. Doing a "load-gui" from the console crashes 
all.

there used to be a jpeg loader, but it has been removed for now due 
to changes in LOAD and we're awaiting mediatypes, which would handle 
image loading.

I haven't tried it in a while, so it may be an older bug, but it 
has been working for me in the past.

I can see now that it tries to load main.r, but that will fail. This 
gives a dialect error instead of a file error. Interesting.

There's an even better way if you are logged in to CureCode:


Select "Change Log" from the menu bar and it lists the tickets fixed 
in the release.


You can look at previous release by using a drop down version selecter.

at R3-alpha world Carl stated that he found a bug in rich-text gamma 
correction.

Carl says that rebol.net will go down for a bit, due to moving it 
to a new server.

Is there any 'Challenge' channel for submitting a problem ?

I just read about 'gather function and would like to ask about its 
area of usage? In the past, in FoxPro DB days, there was common method 
to get all for related data, via function called gather, and the 
reverse was to set a form from an array, via scatter fucntion.  I 
think that if gather takes just one field from objects, we might 
use good name for some limited functionality, whereas it could be 
good name for GUI forms (panels) and gathering of info from all objects 
in one run?

BrianH, no, absolutely not. :-) Pekr asked, as far as I can tell, 
that he wanted to use GATHER for a specific form data collecting 
function and we shouldn't need that.

You may be right about an opposite to GATHER.


Getting multiple fields will complicate GATHER. What is the output 
format going to be? In the form it is now, it's a good allround way 
to get one set of values from a block of objects. Use GATHER multiple 
times to get different values. Then use a different function afterwards 
to manipulate the blocks you have made with GATHER.

Typing accented strings is ok in the command window,  but raises 
an error when read from a file:   a: "terminé"  syntax error invalid 
string {"terminé"}. Is there a new  write or read option for text 
files with accented letters ?

coming fast a furious

There are some things I can't understand in the demo : when you click 
on source, you don't get the full source but just a part of it.

Also, I've tried launching this script (from Dragger demo) :

REBOL [ ]

load-gui

view [

doc {
^-^-^-===Drag the boxes

^-^-^-Blue boxes are unbounded.

^-^-^-Red boxes are parent panel bounded.
^-^-}
d1: free-drag
d4: lock-drag red
panel 0 80.200.80.80 [
    d2: free-drag
    d3: lock-drag red
]
]

...and got a parse error : why ?

Henrik: so what's the point having a 'source' button if these styles 
are hidden ?

Don't you think a 'full source' might be better, it's confusing.

they are not "hidden". they are just not part of the standard style 
list. and you can't create free-drag or lock-drag items in your layout 
without creating a style.

there is a strong separation between the layout and the style code.

The error that has occurred above is that the "demo-let" that kib2 
looked at is not properly documented. Its script header should declare 
what its dependencies are and in what environment it should be run. 
This is a constant source of time-wasting for everyone, as an undocumented 
script apparently advertises that it has no dependencies and can 
run on its own. So all new-comers to the script will try it in the 
console themselves and see it doesn't work. Now the wondering begins: 
"is it supposed to be working or is it still in development?" etc. 
It's not kib2's fault for not having studied how the R3 GUI works.

Let me just temper that - it just shows that the script is not complete, 
and this is understandable in a system which is in flux.

Actually size of the image does not seem to be the prob as this works: 

SQL reduce [{insert into images values (?,?,?,?,?,?,?,?)} "img/1" 
"img/2" "img/3" "img/4" "img/5" pic "img/7" "img/8"]
where pic is a large 4000x3000 full color photo.
I get no error.

But if I loop 50 and insert the above data 50 times I get an error???

If you think there were a lot of changes in the last alpha, you should 
see the next one. I have fixed most of the bugs in LOAD and DO :)

Alert shouldn't present a scroller unless their is scrollable text. 
 Additionally the text on alert should be centered along with the 
button.  I know that alert is just preliminary for now.

I like the fact that it was going to take on a CSS type of method.

I'm wondering now if r3 eats a lot of CPU when running the upgrade 
procedure under linux or just by using READ with HTTP. It does so 
under OSX.

Pekr, there was an opinion for a name-change. See group "Survey Group" 
in R2-Alpha world, that you have access to. I guess, they ended up 
as mezz to be more compatible with existing code.

I've experienced some pauses in VMWare, but attributed them to R3 
building the text for the Text View pane. There is also a bug that 
causes it to lock up if you click buttons too quickly in the HTTP 
pane.

Why are minimum-of and maximum-of being mezzanines now, instead of 
natives as in R2?

Because we are cleaning down the core in R3, and those functions 
are rarely used. They are fast enough as mezzanines - the FORSKIP 
loop they call is native in R3.


Mezzanines can be better for some purposes too - REBOL is a much 
more powerful language than C for some things, so it is sometimes 
a good idea to write the functions in REBOL instead, particularly 
when it needs to be flexible. This is why LOAD is a mezzanine in 
R3 (which calls native code to parse the REBOL data), and half of 
DO is an intrinsic (a built-in function written in REBOL that is 
called by native code).

The new DevBase (3) mostly works now. I posted some suggestions today, 
but it is usable as-is. I'm only using DevBase 2 for historical reference 
now. DevBase 3 doesn't have a reviewer concept, so I'm going to ask 
Carl what the new acceptance policy is - I have the rank to accept, 
but the guidelines need to be updated for the new model. Most of 
my todo list for DevBase 2 is already implemented in DevBase 3, so 
in many ways it is already a vast improvement.

I find I'm using the help function in the console all the time. It 
would be good if the help function could have some refinements for 
searching throughout the function definitions, or limit the search 
to specific parts of the definitions. Would this be a difficult enhancement?

this would be really cool  just like searching the man pages in unix... 
the easiest way to find a shell command when you can't remember it. 
 :-)

Yes, I saw the partial word search, but that onl searches within 
the word, not its definition. Also nice would be something like smalltalk's 
ability to find methods by supplying a signature example - i.e. give 
me all functions where the arguments are <integer>, <string>

perhaps as a refinement to HELP, such as help/args integer!

Yes, please post that to CureCode.  It's a brilliant idea!

well, when learning a language, you need all the help you can get 
- if I know the datatype of the args, I would probably like to know 
all the things I could do with them (append one to the other, multiply, 
union, etc)

wasn't aware that a set of datatypes was a type itself

I have a long time proposition for help on dialects. Imagine e.g. 
VID, where styles do have help strings too. Gabriele proposed:

help/vid button

... whereas I proposed: help/dialect vid button

Not sure, if we can make help system pluggable that way?

The typeset! type is a new addition in R3, and emulated in R2-Forward. 
TYPES-OF returns the type spec of a function in both.

I like the idea of a refinement to have HELP search, but I think 
all of the options can be collapsed into one /search refinement. 
Search for a datatype could check type specs, for a refinement could 
check for supported refinements, for a string can search doc strings, 
maybe more.


In general we prefer full words for options, particularly for user-level 
functions like HELP, so maybe /args is not the best name for this 
option - that's why I suggested /search. Please don't call the refinement 
/find or /all, because that makes the implementation of HELP incredibly 
awkward.

Maybe a /dialect 'name option, with installable dialect help? DELECT-style 
dialects like Draw and VID could have autogen docs too.

If the /search option is OK with you, please add a comment to the 
ticket saying so, so that the developers will do that instead.

I just read your comments Brian and I'm not sure what you're suggesting 
allows for the flexibility I was trying to get. It seems to me that 
there are not too many 'components' in a word definition. What I 
see when I get help is USAGE, DESCRIPTION (at the top level and at 
the refinement level), ARGUMENTS (and their type).  What I was after 
was a way to compose the help query to be very specific, but it seems 
to me that what you outlined would follow a certain lookup order. 
Did I misunderstand? With only the components just mentioned, is 
it too much to specify them specifically and in parallel with each 
other?

I would probably also add a /limit datatype!/typespec! option to 
refine searches.

the typeset! is specified as a block? [integer! string!] ?

No, it's a set of types. It is emulated as a block of types in R2-Forward, 
but the usage is basically the same.

so no to "it's specified as a block", but what about the order being 
lost?

Typeset! is a new datatype in R3. Function argument type specs are 
converted to typesets at function creation time.

There is no order in a typeset!, it's a set.

It's the way it is in R2 as well. The order has never mattered. HELP/search 
of a typeset! is covered in the comment - I'm not rewriting it :)

so specifying help/search integer! string! would create a typeset! 
of those datatypes, no? I'm just thick and what I was asking above 
is how do you specify a typeset! - in your comment you only show 
help/search integer! (though you mention that the last value could 
be a datatype or typeset)

HELP/search (to-typeset [integer! string]) so far. HELP/search [integer! 
string!] sounds like a good equivalent - I'll add it to the comment.

I suspect there is a misunderstanding here. It seems to me Adrian 
wants to search for functions that take two arguments, one integer! 
and the other string!. It seems to me Brian proposes a /search refinement 
that searchs for functions that have one of the arguments accepting 
integer! or string!. These are two very different things.

Gabriele: Brian explained to me that the order of the arguments in 
the spec is not preserved when a word is defined since the spec args 
are kept in a typeset! which doesn't preserve the order. In the last 
part of the comment to the ticket, he describes how you would specify 
a typeset! in the /search refinement (help/search [integer! string!]). 
This would let you search for definitions where at least two of the 
arguments are integer! and string! - in any order. It's not exactly 
what I was asking for, but it's all that can be done with the metadata 
that is retained from the definition.

Adrian, what Brian is proposing will get you most of what you want, 
but what you are asking for seems to be a bit to specific and from 
my perspective doesn't add enough value to be worth the time to implement. 
 With intuitive sorting you'ld get all of the functions that require 
both an Integer! and a String! first followed by those that require 
an Integer! or a String!.  About 80% of the reason that I actually 
use Help is to see the order in which a function expects it's arguments 
to be in.  Searching for [Integer! String!] will list the functions 
that opperate on a string and require an index to that string at 
the top of the list and I think that's what you're really looking 
for.  Some people think in oppisite directions and want to declare 
the index first and others want to declare the string first.  It's 
just a matter of preference and doesn't change what the function 
does.