AltME groups: search

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

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?

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.

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.

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

Yes, I know. I think it will make more sense, when I get more container 
styles done. It will be very useful in the case of a date field style, 
table style and calendar style. There was a problem in the past with 
aligning multiple styles in a nice-looking way. Container solves 
that.

what I would like to understand is, why was not it possible to be 
solved by group or panel, technically. But I'll wait, because in 
fact I don't know, what is container about. I thought, that panel 
is the container already. I would not like to find out, that the 
reason is, that the design is flawed, and hence the situation has 
to be patched by introducing yet-another-style-for-each-new-situation 
...

just something that was missing

 - couldn't be panel and group fixed to work like Container? :-) What 
 is their other difference other than Container aligns, but panel 
 and group don't? :-)

Yeah ... I think it's crazy.  Perhaps Carl subconscioiusly fears 
failure and doesn't realy want to release alpha - so he keeps coming 
up with blocking requests like this.

Unfortunately I am beginning to see Carl as the weakest link in this 
whole process.   The last time this happened ...  Jaime went to his 
house to persuade him to release something, and he did.  Now Jaime 
is gone ....

Perhaps all the R3 contributors need to get together to formulate 
a strategy/plan .... and present it to Carl.  Otherwise we're all 
wasting our time here.

with setting up the new server and software

Carl once again runs in circles, and ppl are becoming upset. Still 
dragging our attention by blogs, questions, but with zero resolution 
to final decisions. This project is pretty much missmanaged, and 
RT without marketing manager and really a solid aproach is a bad 
joke.

I think Carl will do it quite quickly, and all his reasons for it 
hold water

he's already said he does not  want to be distracted from GUI and 
core

And I think he wants to write a Rebol client as well ....

I was actually surprised that he considered the available alternatives. 
I know they suck and need to be replaced

Do you think the solution lies in making my and Carl's opinion out 
ot be nonsense?

The reason he gives is totally inadequate ... it's just some type 
of internal conflict resolution he is making to try and delay

and Kaj, and Oldes are supporting instrumentals

We really need to get to the state, where others can start to participate. 
And it will happen only if there is some kind of DevBase functional 
and Carl ready to upload R3 sources in there. I do understand the 
need for the existance of supporting infrastructure, but it can be 
done in parallel. We constantly wait for this or that, instead of 
releasing something ..

never minds. I say - release on monthly basis, ppl will sort it out. 
Those releases are really needed, even if supporting infrastructure 
is not there. We have clever devs here, we can sort it out and work 
on things in parallel. Simply put - give ppl somting, and they will 
shut up :-)

I am simply not buying and agreeing to everything Carl says, just 
because he is well respected guru. If you think I attack Carl or 
others, you are wrong. I am just against some basic principles of 
management .

my methods

 are general project management methods, why should it differ for 
 R3? The real problem imo is, that Carl is used to work either in 
 really small teams, or alone. I can understand his pov about the 
 code quality, and imo it is difficult for hime to find "leutenants", 
 but at least BrianH imo passes the requirement. Pity Ladislav is 
 not awailable anymore.

You're also not doing social software in a loosely connected community, 
you're doing line-of-business softtware in command-and-control organisation

There are relevant discussions, but that is not the criteria for 
a web public group. You need to consider everything written here 
to be advertising copy, not just arguments amongst ourselves. This 
is not the place for negativity and defeatism.

I am used to face "problems" as they come. We will come to some resolutions, 
and it will soon enough be hopefully the thing of the past, albeit 
recorded. It is goog we talk about all such things. But - no problem 
to get into private channel, if the group wishes for .....

In AltME, yes, and it's also far too late for RT to prevent these 
opinions

And yes, I am fully aware of what a web-public forum is.

I think I have just made it clear that I don't think it's too late 
for R3. Far from it, as the point is that we are very near to being 
able to start with it, and good progress is being made

and no release = no distance

I am not a physicist, Graham, I am a programmer. There is little 
force and infinite distance involved in my work.

Yes, I am in a profession where we practice transparency, and evidence 
based methods.

As is more and more REBOL code and communication

And what when it does in a few weeks?

Carl has evaluated the alternatives and has seen that using them 
would cost him at least as much time, spent on competing products 
instead of REBOL

And there we are again...

Now who's going around in circles, and who's making progress?

And that, presumably, is why you chose REBOL all those years ago

People are going to use REBOL to write forum software, or the many 
applications that do the same thing, technologically speaking. We 
will need to have test apps of that nature to make sure that apps 
of that kind will work. The reason that tool-builders use their own 
tools during their development process is to make sure that their 
tools work, and to get ideas. That is why other programming languages 
use tools built in those programming languages.

Go back to the alpha world and read. Remember that this is a US holiday 
weekend.

I have already had to skip a night of sleep because of the holiday 
overhead, and even then haven't had time to do any REBOL work. You 
are picking the wrong time of year to get impatient.

And Carl's arguments are flawed.

you must have the password and accept to be raped by the gurus

*smile* no fear here, they would find I'm old and thick skinned, 
a scary combination!

OK, I got a quick job: I need to make a one-month calendar in VID3.4 
complete with day names and dates. I just need the algorithm to generate 
the necessary VID block. It must be coded in R3.

The input is a specific date and the output is the month that date 
sits in. It's OK if we can get more features in, such as week numbers.

Is there any way to get our hands on the latest Alpha build?  I would 
like to start to plan for migration to REBOL3 of some scripts and 
plan for REBOL3 in current work.  Especially regarding ports and 
series handling.

Personally, I''m doubtful of the value of a new release at this stage 
other than a tangible display of progress. From all that has been 
told in public, this release will have lots of unfinished code and 
no doubts lots of loose ends.

It will be an exciting time. You won't be able to assume that your 
code will continue to run unchanged on future builds, but your code 
will influence the changes made in the future, and any bugs you run 
into will get fixed. It should be fun :)

Sounds like you're arguing for Carl to release now and not wait for 
his BBS script!

I would if he were talking about DevBase (and did), but I think you 
are overestimating just how long it will take to write. We aren't 
talking about a web forum here, it is clear from the blog that he 
is talking about a R3 GUI client. He can knock that out in no time.

We could write a server using the methods and code of DevBase - it 
wouldn't even have to run on R3 at first.

DevBase uses the database of AltME to store its data, has a working 
R/S interface, runs just fine. Change the data model and you would 
have a forum server. Servers are really very similar.

It doesn't even have to have a web interface at first, and then we 
could write one on Cheyenne.

S3 for message storage, SDB for message tags and indices

By "eventually" and "not at first", I mean after the R3 release. 
We are already using Cheyenne for the bug tracker, and we will be 
putting in bug reports to that as well on the tracker itself. Bugs 
don't get fixed if they don't get noticed, and they don't get noticed 
if the tool isn't getting used. We need users for R3, and those users 
are apps.

First client prototype (30-Nov-2008) 8.1 KB in size, and first server, 
4.6 KB. Written by Carl Sassenrath.
 :)

and very busy already 

data: [
]
[command-error]

Now, there is in fact a part of the R3 GUI I want to release for 
testing and that is the color conversion functions.

Carl makes R3 usable the only way you can... create a test application 
that has enough real world charateristics to be representative of 
real life work being done in R3.

Look closer, you see:
- server
- async web network client 
- GUI
- local and remote data storage

 and so on.

Carl states in the blog, that he is considering to use it for developer's 
discussions, and I don't agree to that, unless I can see, that the 
plan is really well though out. It will not be forum, it will be 
still worse than altme, it will not be searchable, etc.

The whole idea is confused and misplaced

but fields and lists in particular use them.

I was sooo sure there would be alpha tonight ... the new moon was 
in an equilateral triangle with Jupiter and Venus at sunset here 
in Minnesota ..

Looks good.. and the sliders from Carl's blog as well.

Paul, yes, colors are experimental right now and definitely not final. 
rounded corners are a little harder to do.

As for date field, it is imo ugly - the whole skin is starting to 
look like old grey unix, weighting of fonts is overloaded for smaller 
buttons and labels ....

CharlesW, VID and VID3.4 are very different, so it doesn't really 
pay to start out in VID and you can't port anything.

Pekr, a slider is not used to represent data. It is used to adjust 
data. And it's already used in at least two places.

The wait is frustrating. I have been so tempted to learn and use 
NewLisp for my projects but love the lispy forthish nature of rebol.

I think that if Carl generally releases alpha to the public, the 
more and more will be done in R3. We might be close the boundary, 
when we should start using R3, even if not complete ...

CharlesW, there are some differences, like unicode, but go ahead 
and get a good feel for it.

just one question about R3:

to convert a 32 bits integer to a binary serie i currently use that 
trick:
>>my-int: 150
>>debase/base skip tail to-hex my-int -8 16

it's quite inelegant and memory consuming (especially the to-hex 
function)
we need a more speed and compact function in R3.
I know another one trick using struct! but it's slow too.

To convert binaries to integers we don"t have such problem, cause 
[to integer! my-binary] works well and is short.

i need it cause my script works well with R3 alpha and R2 too.
to-hex returns longer strings in R3 than in R2

Small status update:


- Mostly doing code cleanups and bug fixes now, so changes are not 
very visible.

- Carl has worked on window positioning and popup offsets, which 
were not working correctly. This should finally enable us to get 
popup styles done. Actually I've already done the first for date 
field. Popups are very simple to do, compared to VID. Just open a 
modal window without a border.
- Icarii has begun working on R3 styles too now. Thanks!

- Still baffled at the concept of MAX-SIZE. There are some places 
where it just doesn't work (see my later screenshots with a funny 
curled-up scroll-bar).

- I'm very pleased with my container style. It has proven to be very 
useful and we will build many more styles with it.

- Autogenerated style list and style tree (will publicize this soon 
here. R3-alpha users can see them in Users/Henrik/style-tree.rmd 
and style-list.rmd)
- Over 80 styles now. I suspect there will be 10-20 more.

- Color policies are being settled, so you can abstract colors away 
from a style into a theme.

- Each style will eventually get a tag block. This makes it possible 
to tag a style as 'internal or 'advanced, depending on where it's 
intended to be used and what it can do. This is very useful in documentation, 
and for some styles that need to work together in specific ways. 
It also makes it possible to hide advanced styles from end-users, 
who won't need to use them directly.


For those who have missed it, screenshots and videos are here: http://rebol.hmkdesign.dk/files/r3/gui/index.rsp

Henrik - the problem with the list is its complexity. I am not sure, 
I would like to see hidden advanced styles, but various variants, 
and styles as 'clicker, which has no benefit for an end user, unless 
he/she is ready to produce his own ones, based upon 'clicker.

The distinction boundary and suggestion of how to think about tagging, 
is imo - VID level user, making GUI, not wanting to create style, 
vs style tweakers, vs style authors ... - but that is only suggestion.

The style list is only there to describe the styles as they exist 
and are defined in the system: As a single flat list. The 'parent 
value is the only thing to make it into a tree. A tag block would 
help us group it however we want. I don't think there will be problems 
describing the styles in the documentation in a clear fashion.

Henrik - what is in system metrics? Is there resolution only? Or 
also other aspects? In the past, I tried to wrap rebol to win32 funcs, 
to detect properly multiple monitors and their orientation, but was 
not successfull at the task. It would be nice, if we would have such 
funcitonality ...

Henrik, I went through all of your videos and it looks awesome. Had 
there been any discussion on an HTML viewer widget?

I wish the teasing would stop or at least be backed by a well thought 
out and valid date.

Oh ...?  I looked at the data format and it looked similar to LNS 
format

Carl and Maarten are working on it now.

Ok, I'm building it of several parts. (This may change if I find 
some more clever way of doing it.) First there is a DATA-GRID, which 
is a TIGHT style that contains actors to generate a grid view and 
links to a block of data. DATA-GRID is a slave style in that you 
link it to a data block and then it will display what it can display 
of that block from a start index set in the style, so it works like 
a data window. TEXT-GRID is currently just a variant of DATA-GRID 
with different spacing between cells.


Next, we can move that start index around by attaching a scroller 
to the DATA-GRID, and set the DATA-GRID's ON-SCROLL actor to set 
a new index, based on the input from the scroller. The scroller will 
be set based on the size of the data block versus the size of the 
data grid. Presto, a functioning list view.

I will explain sorting, filtering and all that later.

I think I need to re-read all those tight, panel, group, container, 
as those styles are similar and I don't understand why and when should 
I pick, when starting to do something ...

PANEL - When you need to group faces together loosely with a nice 
frame.

GROUP - When you need to group faces together loosely without any 
frame.

TIGHT - When you need to group faces together tightly without any 
frame.

CONTAINER - When you need to group boxes and controls. This is for 
specific styles and not for beginners.

You might need to deal with that anyway. I find myself needing to 
place a number on how many columns I need most of the time, and how 
hard is it really to type a single digit? :-)

Henrik - do we have anything like "anchor"? I do remember, from Romano' 
s styleset resizing model, that you could anchor your element to 
some other, and it stayed that way. Maybe it is not needed with recent 
resizing model?

How does 'tight differ to 'group (both without frame), if I would 
choose 'group and set spacing to 0x0?

it was quiet simple and effective

There will be unicode support in new gui, as the all R3 core is already 
unicode aware. Problem is probably the input, but it's not such a 
big problem and will be done soon.

Cyphre is  not working on R3. He is working on Qtask. I don't know 
what exactly.. it was a joke a little bit. It has nothing to do with 
Carl and any BBS

And... https://www.qtask.com/files.cgi/ForREBOL3?tab=get&uuid=EXBGS47FCJ7A291SVTW9WDTTD1QT&filename=For REBOL3

Richard is 185cm, I'm 187cm, so, having checked, I'm tallker (and 
bigger).  I'm 100 kg.

Graham, in case you missed it: The BBS gave a good range of bugs 
to fix. It was probably built in half a day. The rest of the time 
was (and still is) spent fixing bugs in the core and my skin. We 
are not "wasting time".

First alpha release in January, and we're now in December, and writing 
a simple app exposes major bugs in core/vid .... it's really all 
quite tragic.

The mantra of iterative development is release early and often. Frequent, 
tangible, working releases are at the heart of the iterative approach.