AltME groups: search

do we have any news on whether viewand/or vid will be included with 
the Beta?

I think that View is part of the release .... not much was said about 
VID prototype. Last time I asked it was not done yet ...

vid will be there, so we'll be a bit late.

Gabriele - including VID prototype? :-)

I think the main focus will be to make a good .dll core for now with 
a VID prototype. Getting that right first will make plugins, rif 
and all that easier.

I would like View to become new cross platform gui toolkit, as Qt 
is, GTK is, etc., and if ppl would find it easy to use, especially 
to create non-traditional UIs, then actually we will have something 
nice in hadns ... it all depends upon VID completness. I hope it 
reaches at least state of RebGUI ....

i'm secretly using it in vid proto so to make the chances of it being 
in higher ;)

Gabriele - how goes VID prototyping? What is its status? :-)

well, some layouts can be used, but things like ACROSS, BELOW, PAD 
are not in VID 3 (yet?).

an evolution of Vid rather than a revolutionary product

Graham, I don't think I FEEL quite up to it yet. :-) I don't even 
know yet how to code with GOBs properly, as they are a bit harder 
to manage than faces. There will hopefully be a solution to that.


There is a much better text list already in VID3 than in the old 
VID. It even has columns. :-)

I just really hope that new VID will be fully featured GUI system, 
and that it will support most things needed to do larger business 
apps ....

Pekr, the prototype feels a lot more feature scalable, if it's any 
comfort. No real dead ends as in R2 VID.

My understanding is that Vid will be incomplete again

Gentlemen, please remember, this is a prototype, so don't get too 
upset. I don't know how far it will be done when the beta comes out, 
but already now it feels far, far more capable than R2 VID.

Graham - but we can complete it. But only if basic subsystems are 
flexible. I hope those will be. I will not accept any "you can code 
your own VID" excuses. If there are going to be any, we are really 
doomed.

Graham - so far you can use RebGUI, no? If it needs year, then let 
it be one year. But I want to be able to comment on things like focusing 
etc. I don't want R3 VID being limited in any aspect ....

Henrik - is there a concept of window in new VID? As I said - I would 
like to have one. We should decide upon what will view/new do. I 
am not sure I want it to open new OS level window. That will make 
plug-in apps suck big time. I would welcome the choice - for desktop 
apps let it be e.g. OS window, for plug-in, VID windowing ....

a way to render a browser window inside a vid window, or mpeg inside

Think of ViewTop for e.g. It is like desktop. Why not to have VID 
level windowing? Not as a default, but as an option?

give me one single reason to have vid level windowing (it's just 
a style away to be possible - the system does not care at all about 
how "windows" are implemented)

ok, but if you think about your app, you need dialog box, right? 
And what did currently R2 plug-in did? It popped-up in front of your 
browser ... that is not good. So to avoid this, you need something 
like windowing styles directly in VID level ....

VID does not even need to know about it.

Pekr, in the plugin, you specify an initial window which appears 
in the browser. You are not allowed to open new OS-level windows, 
therefore if you want to open new windows they must be VID-level 
windows. How do you do that ? You add faces to the first face's PANE, 
 start calling them "windows", and use code such as Cyphre's SWIS 
system to implement it. Simple as that.

Anton - that is exactly what I am saying - VID level windowing. But 
what Gabriele suggests sounds like something else.

skinning is completely abstracted and you can have whatever look 
for the styles. currently we only use draw, not images, but some 
styles may require images. anyway it depends on the skin, vid does 
not care at all what you do.

(i personally prefer parse, but the new one is more efficient and 
so better for simpler dialects like vid etc.)

Henrik - you know me and you know what I fear - pekr coming to final 
r3 VID, playing with it for few minutes, asking - how would I do 
that? And getting the answer, that it was not inteded to do such 
a thing and that it would require VID rewriting :-))

Henrik - re VID - currently simple apps, because of incomplete style-set, 
no? But foundation is stronger than VID2, isn't it?

I would like to first see new View with rich-text, VID, ability to 
embed externall windows (e.g. video player, etc.), decent sound, 
really good VID, tools like screen painter, debugger, cross platform 
rebgui to give initial boost to apps, and then further fine-tuning 
using DirectX or View plug-ins (access to buffers etc.)

You could steal them to REBOL though. Starting with some wrappers, 
doing similar screens as VID skin, etc. :-) That could be good commercial 
enterprise REBOL start :-)

So, very very theoretically, today is the day? :-) If there is no 
release for another let's say 2 - 3 weeks, maybe at least preliminary 
access to docs could be allowed? well, or another VID screenshot? 
:-)

latest R3 alpha, which came a few hours ago has:

- built in VID
- built in HTTP
- more undocumented features
- about the same amount of documented features as last alpha
- dll file is 262 kb
- exe file is 336 kb


There are 225 bugreports in our database, of which perhaps half are 
fixed. Two reports were added today.

That's my status update for now. :-)

I hope VID is shaping well :-) I was quite worried, when I read your 
"quirks document" :-)

btw - I had an idea, nothing concrete, but - could it be possible 
to build styles in complete visual style, almost without coding? 
Imagine visual style builder. You basically would have container 
and you would be able to place gobs there. You would have also available 
palette of handlers, which you could kind of plug into your container. 
Then you would have available testing methods for dragging, mouse 
moving, and test how your style reacts. It would kind of remind Photoshop 
work with layers. It would create tree structure and then it would 
compose a style for you as a resul, with minimal coding effort. Just 
not sure it would be possible. But - for new VID, you guys should 
thought in such an abstract way to make it possible :-)

I think it is more View kernel related than VID related?

So, Henrik - are you familiar with new VID to that extent, so you 
can start porting your grid? :-)

A little update from Alpha testing. Since last time, this happened:

- POWER can now handle negative number and exponent

- Some bugs fixed regarding: money!, path, VID crash, change/part, 
read, function and closure recursion crash, compose/deep
- New dictionary! datatype (replacing hash!)
- A lot is going on in the graphics, VID and DRAW groups
- Ongoing work to get the test methods to perfection

We're now on Alpha 49.

When will we be able to comment on new VID? I have found out link 
to docs. But I also don't want to open some discussion here, when 
other ppl might not be informed. The trouble is, that just because 
we are not let in in the early state of development, we might miss 
the influence on what the new VID will all be about ....

I read every VID related doc more than 5 times, and I am only slowly 
starting to get the idea behind it :-) So I wonder - is new VID conceptually 
so complicated, or there is still not enough docs to get the idea? 
:-) There are already things I like a lot, but there are also some 
worries, although those migh show as minor. Maybe some better explanation 
(more docs) will help the situation ...

The trouble is, that just because we are not let in in the early 
state of development, we might miss the influence on what the new 
VID will all be about ....


Do you really, really want that? The only thing you'll get is "design 
by commitee" and slowing things down.

you asked at one point how much the docs correspond to the state 
of VID, and I think they are revealing probably 60-70% of what is 
there now.

having used VID3 for a bit now, I can tell you, it's SO EASY. it's 
amazingly simple, compared to the R2 VID. it's possible to do things 
in 10 lines of code that would require 500 lines of R2 VID code.

btw - looking at RebGUI docs, and thinking about VID2, I found out, 
that I like keywords very much (effect, font-size .... , on-click 
etc. in RebGUI). I hope that concept lives and is not replaced by 
awful with/options aproach, which burns you deep inside VID internals 
...

E.g. - let's look into some VID reference Introduction. Some may 
find it vague, and saying nothing:


By their nature, graphical user interfaces (GUI) are more descriptive 
than they are functional. In REBOL, the Visual Interface Dialect 
(VID) provides an efficient method of describing GUIs. VID is implemented 
as a layer that rides on top of the REBOL/View graphical compositing 
system. VID provides shortcut expressions that are automatically 
translated into View objects and functions. You can seamlessly combine 
VID and View code and data for great power and flexibility.


Whereas for me, it s real jewel, as it introduces me into concept 
of relation of View and VID.

and as for VID3 kicking ass - I hope so, as I like my little fights 
with Bobik between VID and PythonCard, so I really hope I have some 
new fresh blood in my veins for my new round of evening tea talks 
;-)

I am a new programmer - how it connects? I want to have some imagination 
about it. btw - that was the most difficult part of VID vs View. 
At least when I taught Bobik VID. Once you needed to go deeper, non 
skilled View guru would get lost ...

there's a lot more interconnection between words in VID now.

Petr, then you should not complain about VID, but about the docs. 
Problem is, we don't have anyone to write them. Brian is doing his 
best, but I don't expect him to be able to just do *everything* (user.r, 
testing, writing docs...)

Maybe I could help with docs, but not sure if I would be able to 
understand new VID to that extent, to be able to write one ...

(btw i started doing easy-vid3 using easy-vid text as reference to 
make it "similar" in how it reads etc. but i don't have enough time.)

been working on the vid docs for a few days already.

Brian - I exactly understand what you mean. The bad thing is, that 
when you feel you have something to say to the design itself, you 
can't, or you don't want to, to not spoil the chefs. But - I will 
write docs only to desing I have 100% trust into. So far I have some 
worries. Those are more philosophical ones. E.g. worst part I read 
so far was 'tight command, which imo has bad influence on how VID 
code "feels". So - at first run, I will try to read most past discussions 
and try to understand new design philosophy. There surely are differences 
to VID2, mostly that styles seem to be organised in groups (columns). 
I can't e.g. see VID2 keywords like 'at, 'across, 'below, 'return, 
etc. - so, how I said - I first need to study the design. Then I 
will have some questions. 


I will ask those questions to Gabriele privately, to not flood the 
group, and because he is master designer. I think that guys managed 
to create strange atmosphere here. Since when is the design a closed 
effort to those who are interested in the design process? I don't 
remember it happening even with View 1.0 - ally mailing list. Everybody 
interested could reply at least on mailing list - no wait and see 
mode. That is exactly why I asked for the design docs first, althought 
I understand Gabriele's point of rather coding first. But the aproach 
of "watch, but don't spoil" excludes others from the design.


So once again - if I find new design unpleasant to use, difficult 
to use and explain in the docs, I may also departure from the effort.

Petr, well, there must be one designer. since we already had like 
7 years of feedback on the design of vid, i'm not really sure much 
more is necessary, but we're always listening for comments. your 
problem is that you always make assumptions and then complain based 
on your assumptions. please stick to facts. the fact is, that i've 
been in the rebol community since 1999, and I have implemented many 
VID apps. I read the ML, I read here every day, I read reboltalk.com, 
I read every ticket in RAMBO. i'm not really sure you know what vid 
should be that much better than me or anyone else here.

Gabriele - lol. I accept your pov. But how is something I don't necessarily 
like being an assumption? I of course agree with you, that you are 
pretty much skilled person, based upon your REBOL experience, but 
apparently also by using (coding for) MUI on Amiga, LaTex, etc. My 
issues come from different perspective. I have no assumption how 
VID works internally, but that does not prevent me from seeing single 
syntax of some commands for e.g.

Now back to VID and syntax. It is now for you Gabriele, you surely 
will understand my reasoning. I don't mind if you don't agree with 
me. We are here not to necessarily have identical opinions ....

Let's say I am very average rebol coder, and that I also had one 
person, which I taught REBOL, VID specifically. I saw various VID 
code in the past, some was pretty and self explanatory, some was 
more messy. I e.g. liked simplicity in most of IOS reblets. The ugliest 
design in VID2 is a list for me. Thru all those years, I catched 
several ppl, to not really get it. It is kind of "usage pattern", 
and if it repeats, then we should think, if the aproach is best for 
the user. E.g. list style assumed cnt word in its block, and it was 
really confusing.

When teaching VID, my basic understanding was, that Bobik generally 
liked it very much, unless he had to touch its internals. The last 
escape was 'with. Creating new style was mostly a show stopper. What 
I and even him really liked, were facets. It is like the last easy 
chance of how to move upon the surface (VID), without the need to 
go under (View).

What I speak about here is mostly feelings. But sometimes how we 
feel about the code for the first time also might mean, that we either 
stick with the tool, or we leave it. If I can see few lines of VID 
code and not being able to understand what it does, unless there 
are comments or the need to go to the docs, then it is not good for 
the tool. It should be mostly obvious at first sight ....

To better understand my very general concern, not concrete complaint. 
Let's talk simply command usage, e.g. zip:

zip.exe what -a param1 -b param2 param3 -c param 4 
zip.exe/a/b/c what param1 param2 param3 param4


As you can see, in REBOL there is much more emphasis put onto user 
remembering the order of the paramteres, whereas in the first example, 
user simply takes desired parameter, and in THAT context, specifies 
the parameter value. It is shorter path, and user does not need to 
follow long patterns.


VID, in relation to above exple, might or might not be similar. We've 
got facets, which too, allow immediate context modification of particular 
parameter. For me facets are one of the strongest aspects of VID 
semantics and how it relates to lower layers.

Then we've got keywords for VID, which I like less. They are somewhere 
in your VID code, and mostly are as switches - 'at, 'pad, 'tab, 'across, 
'below, 'return. They are more difficult to follow, because they 
somehow "fly" in your code, and you have to look for them, to know 
actual state, when writing your code.


And now to styles - I don't like too much, if something outside my 
style, influences my style. So, how self-explanatory is "tight right 
off left 50% top 100%"? There are few possibilites, well, yes, based 
upon my assumptions:


1) the design, from my pov, is not right, and 'tight should be a 
facet to the style. We reach philosophical difference of object.show() 
or rebolish show object (or more objects).

2) 'tight does not affect real/internal margin of particular style, 
it stretches spacers used in group column model

3) the name is not self explanatory. Even first sentence description 
talks about margins. So why not 'margin or 'set-margin, which would 
be much more obvious at first sight ...

And you see, those issues might look as absolutly minor, for most 
of guys here. I am not language purist. I don't care much how you 
cook VID inside, but how will VID level code attract the eye of newcomers. 
We want to have millions of them, right?

Those aspects are nearly psychological, but judging upon my experience, 
when trying new stuff, I mostly follow following pattern - see screenshots, 
download product, install, try to run it with some examples, look 
at sources. Only if I am interested at first sight, I consult docs. 
I think that might be pattern of most newcomers .... if VID code 
will be obvious, they will stay and go eventually deeper. There is 
why I care so much for the "surface" of the things ....

There was a time, just when VID3 discussions had started last year 
that it was proposed to make VID3 way more scalable and powerful 
at a slight cost in ease of use. It certainly is way more powerful 
now. I can't see any dead ends or impossibilities where I'm sitting, 
like you can with R2 VID, but the ease of use never went away. It's 
a lot easier to use than R2 VID. I'm also betting that implementing 
new features will be a breeze compared to the wrestling you had to 
do for R2 VID.

Any reason why the new vid dialect can't be back ported to r2?

graham, there are way too many dependencies on R3 to backport R3 
VID to R2. It would probably also take as long time to port it as 
it has taken to write it.

petr, what would having pop or imap change? (btw, ftp... that's a 
mess of a protocol. find someone wanting to write that one :P) i 
really don't understand the point. pop and imap are "trivial". VID 
is the focus. i can't wast time on pop now. that can be done later 
on. i must spend my time on what's important - VID. having an R2-like 
R3 is just crazy. R2 is already here.

Gabriele - I really don't understand your aproach. I don't believe 
you are able to finish VID sooner than in few months of work. You 
seem not to be able to understand fundamental reason behind what 
I say. I dare to say, that developers should not be allowed to talk 
how to aproach product strategies, sorry ;-)

Pekr, you can say that about many things. There are many protocols. 
Which one should go in first? HTTP was logical here. Now which one 
goes next? If Gabriele spends time on FTP and not on VID, I can't 
work on skinning. It could be other things, but VID is far more important 
right now than FTP, because FTP is probably fairly trivial to do, 
but still a one-man project that should be done when Gabriele can 
be free to do that.

We talk two complety separated issues here. First is my proposal 
to AT LEAST release Core like products. You talk about current development 
aproach. Of course VID is more important. But you still describe 
model which is happening here, which is like without any strategy 
being defined.

yes, that would be a good argument, but Carl wants VID out as quickly 
as possible.

petr: no matter how much time does vid take, either we release in 
whatever state it is, or we wait until it's finished. inventing something 
unrelated like adding pop just takes time from the end goal of R3, 
and does not help anyone. people want a toy to play it? so, let's 
just release early and often, no matter how badly it crashes or how 
much it destroys your hd - we put a warning in there. people want 
a finished product? then, just wait until it is there, and don't 
tell me you want a date for it, because noone in the world is able 
to give you one.

Ingo - but Gabriele is coding VID, which is too only a rebol level 
code, not C one ...

Now imagine that most developers use core and web servers, they will 
want http(s) before they want VID

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.

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.

excepting VID is still incomplete after how many years??

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

what you guys seem to not want to understand is that delaying VID 
may be good for you but it *hurts* RT. so, well, it ends up hurting 
you too in the end. talking does not change that simple fact.

I, for one, am not suggesting to delay VID, I (and others) just want 
to know what is possible with the new iteration of the core language 
(and no, I don't mean the bullet-point feature list).  If there's 
bugs or no VID at this point, so be it  -- the perfectionism seems 
to be alienating the 'have-nots' here.

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

Graham - yes, he was - his FireSide (aka DevBase) R2 VID based tool. 
It is not created from scratch, as it was already used in the past, 
but Carl wanted to do some small changes, to better fit R3 model. 
It was supposed to be done yesterday or today. We will see.

there is an effects lab written in VID3 that would be impossible 
to make in VID or at least very difficult. would probably require 
2-3000 lines of VID code.

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

I thought about VID3-2-Flash converter, but I am not sure those things 
are possible, without REBOL. Remember - VID is being parsed, 'parse 
is evaluated in REBOL. REBOL is everywhere in the equation. The trick 
is - show Flash, Ruby, Python guys, that View is nice and runs in 
the browser. Then they will try to copy it. Then they will find out, 
they need REBOL anyway. Then they will find out, that REBOL is actually 
smaller, than most of their libraries. Then they will drop Ruby, 
Python etc. :-)

Henrik: Is your VID-LIST  going to be built into VID3?

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.

How you do such thing as drag & drop of an icon, where icon look 
during the drag period, if it animates, screams at you, whatever 
:-), is dependant upon VID stylesheet?

http://www.ross-gill.com/r/vid-css.html

HTML is also designed for documents, yet is being used for many of 
the applications that the new VID is designed for, no?

Chris: my point exactly. VID should map to the DOM with CSS and use 
REBOL instead of Javascript (or alongw ith....)

Chris - if CSS does not control behavior, nor should it, - as you 
say - then - screw it. You guys should decide - if you want web, 
go web. But don't try to degrade VID3 to CSS model, because it would 
ease your life - your web life. You are not in VID land anymore.

If you want to build your web apps, then you have everything you 
probably need, no? html, js, css. Where's the place for VID there? 
Why the translator? Because some JAVA monkeys do that? Yes, because 
noone is going to tolerate monstrose JAVA web browser plug-in, which 
badly failed. Why don't you ask Flash guys for Flash to xhtml + css 
translator? I am against andy degradation of possible VID advancement.

they had a good semantic model for VID purposes

If we are to, as you say 'screw', separating visual from function, 
then why bother when we still have VID 2?

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

Though don't misunderstand me -- I am not suggesting VID 3 should 
be an HTML/CSS/JS layout engine.  All I'm saying is learn from the 
good, proven concepts that exist in their design.

Chris - I know, I remember your position. Was it REBOL2 or REBOL1 
world we were discussing that? VID 1.3 time. I too, asked Henrik/Gabriele 
about CSS. Because it would be cool, if we would be close to standards. 
Not because of standards themselves, but because of easy of deployment. 
But, as far as I understand the situation - Gabriele understands 
CSS, and so far, VID3 seems more flexible. If it would be upon to 
him, he would even more separate (completly) app logic and user interface.

For those not being on r3-alpha world. R3 development was "resumed". 
Not that it was halted, but I hade private chat with Carl for few 
days, and we got into agreement into how to proceed. I wonder, if 
I am working as an marketing RT guy already? :-) Well, it was nice 
and realistic chat. We identified, that priorities have to be sorted. 
And I suggested Carl to blog about it. Developers were polled for 
the priorities, and we found out, that there are mostly two groups:


- one that prefers View/VID plus schemes being done, so that ppl 
can continue with their app development

- and the other group, who would like to have surrounding infrastructure 
implemented. You probably will not be surprised I belong to this 
group :-) 


As for infrastructure, I simply asked Carl, if we get any improvement 
to dll component, and he admitted, that that might be task for us, 
using plug-in API - simply a cleaner and abstracted aproach. But 
- in order for plug-ins to work, we need modules. So - the next focus 
is to get module system working. It is a logical step imo.


RT working on modules does not mean VID should be halted. VID (whole 
View) will be most probably fully open source, so it is more of a 
community aproach. Ah, and we were scared a bit by consideration 
of dropping of R3. Due to architecture changes for R3, Rebcode might 
not be so fast as in R2, but developers said their NOOOOOO, so I 
hope Rebcode will come too in some form :-)


Ah, and as developers complained a bit about rebol console, Carl 
said well then, as you wish, and uploaded C source code for stdio 
device into DevBase.


Guys, my belief is, that things will start to move faster and faster 
with DevBase and cooperation.


Disclaimer: none of above is direct quote from my talks with Carl. 
It is just my understanding of current situation ....