World: r3wp

It's a little buggy ATM and needs more features, but the resize algorithm 
resizes the UI, no matter what you resize: the window or an element 
in the UI. So if you have a box in the middle of the window with 
stuff around it, and you make it bigger, the other elements are automatically 
displaced.

what's missing?

Proper even spacing between UI elements. I think the window also 
sometimes does not resize properly, if content is resized. I may 
have missed some ways to do things in the layout dialect, so I may 
be wrong.

still in the prototype stage, so some things will probably change.

how compatible is the vid3 dialect with current vid?

Gabriele should answer that...

He's gone for the night

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

Ok, so largely the same then

the principles are the same, just allows for resizing, so some new 
words to handle that are in there.

an evolution of Vid rather than a revolutionary product

hopefully also FEEL hell will be either gone or at least very reduced.

what do you FEEL about porting list-view ?

auto resizing needs imo to support - resizing in x, or y axis, or 
both. Then we need anchoring - I wont e.g. button corner to be always 
aligned to area bottom-left point. Then we need the ability to turn 
reizing off for certain elements. Then we need limits for particular 
elements, to aviod unwanted resizing sizes ... etc.

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

nice screenshot. But at first sight I miss on some fundamental elements 
- no accelerator keys yet? No visual focus representation? Is there 
focusing system inside already?

the current look of the ui is a bit ugly.

partial focusing is there, but these things you mention are still 
in the design phase.

what's wrong with the UI look? :-) I think it's perfect. ;-)

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

It looks like mix of Amiga OS and some old kind of unix flavor .....

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

and it will be up to the community to complete it

I hope so ... as for actual look, I don't care much yet, as it can 
be fixed by some gfx artist later. I care more about subsystem as 
keyboard support (focusing), visual representation of focusing, disabling/enabling 
ui elements, flexible resizing, on-something handlers rather than 
one feel func, and self-encapsulated styles - no external dependencies 
....

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.

pekr, there are a few on-something handlers in there already.

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.

So, what I prefer for initial release is - introduce us to particular 
subystems, give us doc with description of how you aproach UI creation. 
Styles can be added later. But I want to have flexible base first, 
which will count on all things needed to support big GUIs.

pekr, about a gfx artist... maybe we already have one? :-)

Henrik - do you find gobs to be more difficult concept than faces? 
Or is it just that gobs are new, and you have to switch your thinking 
to the new concept?

Chris? :-)

perhaps :-)

or perhaps not... but the look might change a bit. perhaps the gradient 
color will change. :-)

insufficient! :-)

Pekr, sorry I'm teasing you about the GFX, but the final look will 
stay secret until it's done, as it's not open for commenting.

My guess is it will be a year before we can build large applications 
with it!

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

ie. I don't expect it to spring fully formed

keyboard support for games

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

keyboard handler? it needs to improve - there were no key-up events 
iirc, and also some very basic and needed key combinations to be 
supported - ctrl tab - this one is really needed to switch between 
tabs ...

Pekr, GOBs are more difficult, because they are more flexible and 
low level, so if you want to build just a three layer face of a color, 
a text and an effect, you need 3 GOBs. You need to define them and 
then put them together correctly. But there will likely be a simple 
way to build complex GOB setups skin makers, perhaps a dialect, so 
the outcome will be simpler than it was in R2.

I prefer non OS look, own style, which will identify rebol app. Definitely. 
All claims of otherwise I find false and unsupported by reality check. 
But I don't probably want my app to behave differently keyboard, 
focus wise, etc. Could be tough to achieve, as I remember OS-X has 
its own specifics :-(

re OS-X - I mean complete behavior of app in regards to system, docking 
etc.

pekr, "is there a concept of window in new VID? As I said - I would 
like to have one."


I don't really know, as I haven't looked at this part of VID3. Windows 
are different from GOBs. There are "Window GOBs", but I don't know 
exactly what that means.

oh, well, next time i'll forbid people from posting screenshots. 
:)

graham: the dialect is different, because it uses new dialecting 
methods from r3. also, the layout is intended to be abstract rather 
than concrete (ie you don't normally specify the size of things). 
the rendering is fully up to the "skin" and not to the layout dialect.

petr, you can't say what resizing is missing before knowing how it 
works. :)