AltME groups: search

Now Gabriele says he wants to concentrate on VID ( which was only 
going to take a few days ) because it was hard and pop was easy.

That doesn't seem a technical reason to me.

we did have the previous vid debacle where it seemed egos got in 
the way, and we had a proliferation of resizing schemes

VID is much more visible than pop. For some people, the fact that 
REBOL has a simple declarative GUI is the *only* reason they noticed 
and subsequently use REBOL. I think the focus on VID is the right 
call.

Well, it's actually perfect for trying to bag up as priorities and 
get them sent to Pekr and user.r.  Don't worry about having a voice, 
we are attempting to start a funnel channel.  As Graham says, the 
majority usually rides the top of the bell curve, and if that information 
can be summarized, it can't hurt.  No actual guarantee of it helping 
but it can't hurt and it's bound to influence to some degree or other.

Graham, even if most developers wanted HTTP first, keep in mind that 
RT has specific goals to reach, because it's a company with investors 
and eventually products or services to sell.

just a joke. :-)

If you would ask RT to have guy(s) to define their marketing aproach, 
they should use Robert + me (eventually :-), but developers would 
not have a say here ...

developers would not have a say here
 <--- that would terrify me. it's why I work usually alone. :-)

Waiting for VID (a feature I'm not waiting for) is at the expense 
of getting paws on all the new language features (which I am most 
certainly looking forward to).

Everyone;  Send a note to Pekr regarding either technical or emotional 
concerns (read as ANY concerns/kudos/ideas).  We are hoping to start 
arming him with raw data for reporting to RT.  Our chats here are 
not reaching as far as their potential.  Treat Petr as the User Advocate 
... it's in his REBOL job description now.  :)

I should note that it is a bit preliminary. RT did not accepted me 
as a community representative. It is just that I chat with Carl from 
time to time and he seems to listen to some ideas. Not just mine 
ideas, but from other ones too.

By Blog entry, we aren't asking for a crafter piece of literature. 
 Just a heads up on direction changes and very quick progress statement. 
 One or two sentences every couple of weeks would likely due the 
job.

Fireside was delayed BTW. Carls says most of the work except a few 
forms is done. He hoped that it would come up sometime today, so 
let's see about that in a few hours.

I spent a long time learning the intricacies of R2 (aside from basic 
primers, it was my first language).  I don't suppose it will take 
as long to pick up R3, but hammering away at the console, figuring 
how different approaches work, interact, all the subtleties -- it'd 
be useful to learn sooner than later.  And given that R2 changed 
constantly as I was learning, I have no problem assuming R3/Core 
now may not be R3/Core of the actual release.

REBOL [
    Title: "Formatting dialect"
    Author: "Carl Sassenrath"
    Date: 01-Jun-2007
    Version: 2.99
    File: %format.r

    Purpose: "Simple, powerful string formatting; well padding at least"
    History: [
        01-Jul-2007 2.99 "Carl" "first R3 alpha"
        02-Sep-2007 2.99 "Bluey" "prepped for R2"
    ]

    Comments: {R3 format will be more powerful, this is a teaser version}
    Usage: {
        format rules values
          /pad padding-character; defaults to space
        rules include the following dialect messages;

          integer!              sets width left aligned (trailing spaces)

          negative integer!     sets width right aligned (leading spaces)

          string!           inserts the string based on position in rules

          char!          inserts the character based on position in rules

        rules can be a single message or a block! of formatting messages;

        rules can also be a word evaluating to a single or message block!
        Examples:
          format 5 12 == "12   "
          format -5 12 == "   12"

          format/pad [5 "---" -5] [12345678 1] "0" == "12345---00001]
    }
]

format: make function! [
    "Format a string according to the format dialect."
    rules {A block in the format dialect. E.g. [10 -10 #"-" 4]}
    values
    /pad p
    /local out val
][
    p: any [p #" "]
    unless block? rules [rules: reduce [rules]]
    unless block? values [values: reduce [values]]
    val: 0
    foreach item rules [
        if word? item [item: get item]
        val: val + switch/default type?/word item [
            integer! [abs item]
            string! [length? item]
            char! [1]
        ] [0]
    ]
    out: make string! val
    insert/dup out p val
    foreach rule rules [
        if word? rule [rule: get rule]
        switch type?/word rule [
            integer! [
                val: first values
                values: next values
                pad: rule
                if negative? rule [
                    val: form :val
                    rule: negate rule
                    pad: rule - length? val
                    if positive? pad [out: skip out pad]
                    pad: length? val
                ]
                change out val
                out: skip out pad
            ]
            string! [out: change out rule]
            char! [out: change out rule]
        ]
    ]
    if not tail? values [append out values]
    head out
]

printf: make function! [
    "Formatted print."
    fmt "Format"
    val "Value or block of values"
][
    print format fmt val
]

Chris: that's exactly why i've been saying all the time that we should 
just release whatever the state, instead of doing a feature complete 
"core" for xmas, which would only hurt RT and not help people here.

Nope it's a step toward an end I do believe.  I like it as it allows 
for padding and alignment, but it's not the real format dialect yet, 
afaik.

sqlab; I'm smiling as I type this, so...

Psst, don't complain too loud or I might get cut off from showing 
off non-production sanctioned versions of functions.  I don't think 
the wait is going to be much longer but I feel for rebol trenchers 
and think the community deserves to see some of what is going on, 
so I asked to release a few mezzanines.


I was hoping it might motivate a rebol or two to expand on it, and 
reinforce the belief that community involvement is not only going 
to be a good thing, but a great thing.  Plus it's a good function 
for what is does imho.

Hmm, my post looks a little weird coming out after Gabriele's.  I 
was in the midst of typing and staring down at the keyboard.  Sorry 
Gabriele;  the abrupt Nope that started my post wasn't meant in response 
to yours.  It was meant for the ...does not solve...

I've been studying some books on software engineering, and the more 
I learn the more I like rebol. As hard as it may be to be patient, 
I'm for not rushing RT.  Let them have the peace they need to devote 
themselves to producing the cutting edge technology we expect from 
them.  Let them do the work in the order they know to be most logical. 
Regular updates on progress would be encouraging, of course; especially 
for the pros here that need to be able to give their customers valid 
facts in order not to lose them.  Also, putting the major emphasis 
on a simplier, more capable View is great as far as I'm concerned, 
as View is what I've had the hardest time learning, and is also what 
I think will make the greatest difference for RT's success.

I can see new View in web-browser plug-in along with new VID as a 
killer app in itself ....

I have the only "difficulcy" with View - it is when I try to think 
how to "integrate it with web the other way =  not View in a browser, 
but pure View app, being able to display html container. We would 
have to be able to link to mozilla embedding product, or khtml one, 
or create at least simple html viewer. But then I worry where do 
we end - creating View based web-browser? :-)

ah, what a sarcasm :-) But I bear with you, Graham. My personal understanding 
is, that behind the scenes, Carl is preparing for the community release, 
using FireSide (DevBase), which should be ready as we speak. I await 
some news in few days, and we let you imediatelly know, what is going 
to happen next.

For the record: I was opposed to the idea of Fireside from the beginning, 
because I thought he meant yet another forum/communications channel, 
since he talked a bit about allowing communication with "hundreds 
of users", not so impressive. We have enough of that with AltME.

When he talked about the existing framework, the working prototype, 
the source code altering and finally the code submission model, I 
changed my mind. I think this tool can be very powerful.

a close button that close the window down .. but say I need to add 
additional functionality?

do I need to create a new type of close button?

And a good reason to educate people ;-)

Rebgui has done a lot of work here

so, if one platform lacked a feature .. it meant none of the others 
could have it

we should in fact be able to scale down from full graphics to text 
console, if it's possible to make a usable interface in that.

I meant in terms of where a UI can be displayed. Not whether we can 
hard scale it to a PDA or an HDTV like they do. If you want to display 
big and pretty buttons on an HDTV, you'd use one set of styles. If 
you want to display on a text only console, you'd use a different 
set of styles, but the layout code would be the same. Some work needs 
to be done here before I can say anything more. We're only testing 
ordinary WindowsXP graphics for now.

how do you setup forms on a text console?  use escape sequences??

You can use terminal escape codes for that, or usually, you use a 
library such as Curses or S-Lang

the layout engine can with the use of styles generate a flash or 
javascript gui ??

Years ago there was a project trying to do this in XML, UIML

I admit I hadn't thought of that. I actually have a project on hold 
for VID->HTML forms in R2.

Looks like Oldes is doing a R2 layout on Flash

a killer user of R3

I was thinking more of a code generator

If you want a killer app, let's finish VID3, put extension things 
in-place, simply create "a platform", then let's create browser plug-in 
- that is a killer app, because it provides you with seamless integration. 
And it will work out of the box, no REBOL code changes or limitations.

V3 won't be there until it can build a browser window

that scales as well as a web browser

Not my Firefox that is hanging my machine all the time for a while

a browser container for IE or whatever would be very nice

The need to render simple HTML & PDF within the app is the reason 
I have not used R2 on internal projects. I've had to move on to web 
apps and I'm using more Python now than Rebol. The screenshot on 
Henrik's blog is very, very good! Web apps, for good or bad, are 
here and now and "rich" web app frameworks  are  actively being developed. 
Rebol faces a lot of competition in this area. The R3  potential 
is amazing and whilst I have my own priorites for new features, I 
look forward to trying out the beta when it's released. Can I just 
say thanks to all of the developers for their hard work so far.

Perhaps we need a list of deal breakers like this?

Printing has always been a major problem

But since it has been a platform specific problem - it has never 
been addressed

If rebol is going to be a dll .. won't that help there?

I mean after one buys a couple of sdks and /pro versions .. there's 
no real need to purchase any more.

It's a dead end as a source of revenue unless you have lots of new 
users

shouldn't be a problem in R3.

can't tell yet. no tests that big have been run yet. there are a 
few recycle bugs that are being fixed.

the decompress function has a memory limit option. it's been discussed 
whether it should be removed or not, but such things will be necessary 
in an embedded environment.

and if you're running a non-gui app .. any difference?

I just started an R3 console. Everytime R3 starts, it displays a 
splashscreen with rich text, a picture and two buttons in it. When 
I close it, stats returns 1276368 bytes.

got a screenshot ?

I think there is a blurred one somewhere...

I hope you are just trying to keep a secret from us all Henrik because 
it would be worrying to think such design decisions haven't been 
made yet.

do you think that it will be impossible to make such a design decision?

I was meaning how to enter the different styles inside a text box 
.. would it need a menu bar to pick the different styles

it probably would. there would be great value in a single text editor 
style with toolbar and things.

of course it would be nice to be able to cut and paste some rich 
text html and have it come out the same in a rich text box

Pekr


Hi. To answer your question, I was thinking about the WxWidget/Gtk/Tk 
toolkits. They have a basic HTML control. Given the web-rich nature 
of Rebol, this would be a great feature. Not Python per se, but the 
wrappers around those toolkits.

I don't think RT will do that on their own. That would be a third 
party project.

I think that as long as a driver can be written for a device, R3 
can support it.

and simple things like right click on a text box brings up copy/paste 
support

it will be essential, so yes, it will be made. there is a simple 
text list now that has multiple resizable columns, very small (and 
ugly in appearance) and fairly fast.

and then R3 LIST-VIEW would just display whatever is fed to it. that's 
a smarter way to do it.

I imagine we'd use a sort index like now and just point to the different 
lines in the data block as the list view is rendered.

Gob arrangement? Dunno. But you try to suggest, that when you have 
1000 rows as a recordset, you have 1000 rows od another data for 
the display? :-)

There was a grid cotrol for VB, TrueGrid from Apex Software; it had 
a callback mode, where it requested data dynamically (like LIST) 
and fired update events if the user edited something. The only data 
it need to duplicate, IIRC, was for the set of displayed rows.

regarding Henrik's blog, i should note, that being semantic is what 
i was suggesting with my old notes about how r3's gui should be. 
that would give us a great power... but many people are against it, 
so it won't happen soon.

Do you mean that a button will now just be a button ?

i mean, that the app programmers only specifies what he *means*, 
not what the UI should look like. "I want to get a string from the 
user". "I want to get the name and birth date from the user, and 
show the age". how this looks depends on 1) the look defined by the 
gfx designer (which can be the programmer himself, if he is able 
to do that too) 2) user preferences, to the point that an advanced 
user should be able to edit the UI.

Use CSS 2.1 styles on widgets. Create widgets ("classes") in VID-the-sequel 
and render them to Rebol or XHTML + Javascript. That way you can 
mobilize the entire web community to get a UI that renders both to 
a RIA and to the web.

Petr, CSS doesn't control behaviour, and nor should it.  At it's 
most complex, it has different rules for different states -- a:hover, 
a:visited, input:focus -- which is how I'd like a style system to 
work.

A small example.

Chris, I would abandon VID3 immediately and use RebGUI if it were 
ever to behave like a web "application". Designing application user 
interfaces with HTML and CSS is a complete nightmare.

I believe, at some point, that actually some VID3 to xhtml plus js 
plus css could be done, but as a subset of VID3 functionality. But 
I refuse to limit VID3 in the very beginning design phase to some 
weird css model a priori.

they had a good semantic model for VID purposes

Henrik: that's not exactly what I'm driving at.  From a visual pov, 
it's very easy to put together an interface in HTML -- it's the behaviour 
part that bites.  Also, frameworks are becoming far more savvy -- 
they may not have the lexical elegance of Rebol, but others are narrowing 
down the patterns that make developing browser-based semi-distributed 
applications much easier.

Petr, I can't say I disagree with much Henrik put on his blog -- 
I have been advocating something similar for some time. It sounds 
consistent with the intent behind CSS, thus I'm curious exactly what 
aspect of CSS Gabriele and perhaps Henrik take issue with.  imo, 
the concept of a visual language that is hierarchial and context-specific 
is sound.  The actual implementation of CSS is kindof ugly..

Look at it another way -- if you are building a web application, 
you hire a designer to work on the interface.  The designer may adjust 
some of your HTML templates, but most all the work can be done with 
a style sheet.  That's it.  They don't need to go tinkering in your 
application code, they just need to know the elements of the interface 
and the range of states of those elements.  They code the CSS, bundle 
the images, then they're done and you can slot it into your interface 
without modification.

Where I have designed VID interfaces, I (or someone else) have had 
to implement my designs in lower level code, and still there are 
portions beyond my control.  And a change in the visual may change 
the functionality of the application..

Yeah, why use a standard if you don't have to.

GUI & functions: The only way I think we really can let GUI people 
work on it wihtout disturbing the code is to use a event model. So 
a GUI widget just sends an event to some rebol internal event-handler 
& dispatcher and this calls the app code.

So a GUI could look like this:
	...
	save: button "Save" [signal-gui 'save-contact-record]
	...

And to make it even more "self-contained" we could use:
	...
	save-contact: button "Save"
	...


And the GUI system would send a message of the form [save-contact 
left-click] or [save-contact right-click] etc.

Chris: "From a visual pov, it's very easy to put together an interface 
in HTML -- it's the behaviour part that bites."


From a visual pov, it's very easy to put together a document in HTML. 
For application interfaces, it's way too underdimensioned for the 
needs we have. I have been working for years with HTML+CSS+Ajax interfaces. 

 hope with VID3, I won't have to do that ever again. It's almost a 
 sad parody of real user interface construction. I'm amazed that people 
 are already forgetting how real user interfaces work.

Visually, it's very easy putting together an application inteface 
in HTML too.  Perhaps we have a different model of what an application 
is?

I hope I'm not infringing on a copyright but this quote from the 
commentary of the Halloween I document 

http://catb.org/~esr/halloween/halloween1.htmlexplains that phenomenon 
quite nicely.

<q>

The difference here is, in every release cycle Microsoft always listens 
to its most ignorant customers. This is the key to dumbing down each 
release cycle of software for further assaulting the non-PC population. 
Linux and OS/2 developers, OTOH, tend to listen to their smartest 
customers. This necessarily limits the initial appeal of the operating 
system, while enhancing its long-term benefits. Perhaps only a monopolist 
like Microsoft could get away with selling worse products each generation 
-- products focused so narrowly on the least-technical member of 
the consumer base that they necessarily sacrifice technical excellence. 
Linux and OS/2 tend to appeal to the customer who knows greatness 
when he or she sees it.The good that Microsoft does in bringing computers 
to the non-users is outdone by the curse they bring upon the experienced 
users, because their monopoly position tends to force everyone toward 
the lowest-common-denominator, not just the new users.
</q>

It has always been a mystery to me how REBOL is the best language 
for abstraction, yet almost all its applications are a mishmash of 
layers that should have been separated out

Like R3 is introducing a programming-in-the-large model, VID3 needs 
a designing-in-the-large model

I'll +1 on Kaj's remarks.  I'd like to see Gabriele be allowed to 
apply some genius to VID3 then drag the rest (most) of us up to where 
we should be.  Chris and Henrik and Robert and Maarten et al will 
then produce all the cool code we've come to expect, but from a higher 
view point and perhaps from a slightly different slant than we are 
used to. imho.  And I do hope that VID3 work will be as shareable 
as the best of the library functions, umm, we don't really have yet. 
 :)

There is potential for R3 to have access to last console expression 
results.  Any suggested names?

>> 2 + 3
== 5
>> 3 * result  ; where result is some new REBOL function.
== 15


I'm a forther so I suggested  .  (dot), but Carl hinted he has been 
waiting for the perfect use of that symbol.  Is this it?  Looking 
for a good name for last-console-result.  Of course my example is 
trvial, it'd be more useful for longer expression and save on a  
temp:  while working the console.  For me, I'd prefer something short, 
easy to type (avoiding shift if possible) and having some meaning. 
 That may exclude . as dot is really forther common speak and would 
be meaningless to many.  I want to push for this feature as I'm continually 
up arrowing and adding temp: to test expressions.

I'd go for that one too, but it's an Invalid money!  It would require 
a special hook in the scanner.

well, that would make for a lot of hard to read code :-)

heh:
 . + .. + ... * .. + ...
reminds me of a certain very annoying language :)