World: r3wp

Carl wants to stick to devbase instead of using Hg

and he can't decide on whether to use a BBS or not.

We are using a BBS, just not a web-based one.

I mean now. We don't know yet whether we will be switching from the 
AltME BBS to another one.

The problem with AltME is not that it is not a BBS, but that it isn't 
a very good one for our purposes.

BBS's predate the web, so you can't just assume that a BBS would 
be web-based.

I recall zmodem protocols :)

acoustic coupled modems

good old fido net

Those were the days :)

Nice - screenshots there - http://www.rebol.net/wiki/GUI_Panels- 
they are nicely self-explanatory addition to source codes ...

I have deleted the REBOL Developer's Networking Group on Linkedin 
due to lack of participation.

Has anyone involved with VID3.4 development looked at MigLayout, 
the Java layout manager (http://www.miglaout.com), for inspiration? 
I've recently started using MigLayout with Groovy and this manager 
is great for intuitive programmatic control placement. I'm guessing 
that whomever is doing all the hard work in R3 has really thought 
about the problem and will provide smilar functionality and ease 
of use, but just in case, it might be worth a look.

The Java WebStart Swing demo on the page allows you to see the source 
as well as the individual constraints by right-clicking on a control.

are u sure for the link ?

add a 'y"

looking for screenshots...

I don't think there are screenshots - the live swing demo app is 
probably the best way to see/experience how the manager works - you 
don't need to install anything (you do need a Java VM, though)

Short VID3.4 status:

- Some extra formatting options in the DOC style.

- I added a numeric field today similar to the one on my old blog 
site for VID, except that this one took half a day to do instead 
of a week and was way easier to implement.

- Skin is changing appearance a bit, both to simplify and to extend 
its possibilities. This made it possible to build pixel-perfect text 
areas, lists and other combined faces, finally.

- Some bugs remain in the layout engine which make certain layouts 
look a little messy. Still not sure that MAX-SIZE is the right approach.

- Added CONTAINER to help produce aforementioned pixel perfect styles. 
As a bonus, such styles will have a common border, which we then 
can change in a simple way.

- Looked a bit at a CALENDAR style for a date picker, but decided 
that it is better to wait a bit with that to finish some other base 
styles first.

Any word on the updated alpha release timing yet?

I think we have moved into a time dilation field

I believe the American holiday season starts today, so I'd guess 
we're looking at next year now.

next year? That would definitely suck. I want something for Christmass 
to play during the long holiday nights ....

Henrik - were there any draw fixes done? Or Cyphre still not being 
involved?

Henrik - what was the problem of former skin, that it did not allowed 
us to have pixel-perfect text areas, etc.?

btw - thanks for update, I was currious, what is happening in GUI 
field, as r3-alpha is mainly discussing supporting infrastructure 
nowadays ....

Henrik - re MAX-SIZE - what was the technique Gabriele used in his 
VID3? Is the model different?

- No time table given, so I can't say when there will be a release. 
I can only say that we're moving forward all the time, fixing bugs, 
adding new styles.

- No DRAW fixes yet. I haven't seen Cyphre since 5th November. We 
can work around most DRAW bugs for now.

- Skin lacked a CONTAINER style to put things in. Lining up scrollers 
with text fields, lists, etc. proved to be problematic. When one 
looked OK, the other would look terrible. We had TIGHT, GROUP and 
PANEL, but none of those are useful as decorative containers. CONTAINER 
works llike the frame of a painting, and now all styles that use 
CONTAINER look almost identical and pixel perfect. It also allows 
me to build complex field styles, like a search field with icons 
or numeric field with arrows.

- MAX-SIZE: It's a combination of weighting and maximum size of a 
face. When you set MAX-SIZE, it will affect the layout of the face 
in code, even if you are nowhere near maximum size, something I would 
never expect such an attribute to do. Setting MAX-SIZE correctly 
is an annoying process of trial and error, can't be predicted and 
depends on the MAX-SIZE of other faces in the panel, which requires 
debugging and studying other styles or setting them manually with 
a lot of typing. There are also magic numbers, so sometimes you use 
a size of 4000 and other times 100000 to achieve similar results. 
This is really the only part of VID3.4 that I don't like. However: 
There are still bugs, so intended behavior may turn out to be much 
better than I think. I can't remember what VID3 uses, but I would 
guess it's a more traditional weighting model.

Why there is another style needed, to properly align elements? Why 
isn't panel and group enough?

panel is for grouping whole groups of faces with a big frame around 
it. group does the same without a frame (no draw block). tight is 
like group, except without spacing. container is like tight, but 
has a visible frame that does not have the same apperance as panel.

That sounds confusing - couldn't it be just variations of one style? 
:-)

no :-)

As for max-size, not sure if it can be usefull at all ...

it's easier to show in screenshots. hopefully I'll get the server 
up again next week.

I don't understand how group and panel could be usefull, if it can't 
precisely align elements? Why not use container all the time then?

I'll wait for screenshots.

it does precisely align them, but the draw block is not suitable 
for that.

You also often mention bug in layout. Is layout so complicated, that 
its bugs can't be fixed? :-)

they are just not fixed yet. there are many things to do.

Would adding more skilled developers help the case? E.g. Anton, Gabriele?

Already asked for both a long time ago, but neither one reacted. 
:-)

Hmm, who else's there? :-) Ashley is not much active here lately, 
and not sure who else is skilled for VID work ....

There is the matter of getting into the VID 3.4 code which would 
take a few days, before changes could be made and those changes must 
be of very high quality. I'm not sure it's of much help right now 
to speed up the process, but in longer term it would help getting 
some details right.

Thanks for the update Henrik, always good to hear about what is in 
work.

no problem

Henrik - but it would really not hurt to get VID 3.4 out for all 
interested users. It is not about VID 3.4 development itself, but 
about getting familiar with what we already have. I expect VID3.4 
being in a state, where most of concepts are already in place and 
fixed?

There are probably about half the concepts in place at this time. 
I still don't know if Carl gets a good idea and decides to do some 
changes.

Will there be any conclusion to parse REP, or was it another blog 
teaser (= without decision announcement)?

Carl is very quiet on it, so, not sure.

Henrik - missing your screenshots :-) Curious to see panel, group, 
tight and container differences ...