World: r3wp

Should new development initatives that require GUI be done in R2 
or should one wait for R3? What would the porting excercise be like 
if I were to start with R2?

Slider is really nice, but quite honestly - how often, if ever, do 
you use slider in your app to represent data? I would welcome more 
practical styles as tabs, tree-view, list-view (grid)

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.

Date field is not complete.

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.

Understandable.

I would also say that the 'wait is frustratig. Reading the docbase 
article about 'wait in GUI does not satisfy me. I thought we are 
away from stupidly blocking GUIs.

Do you think it would be too risky to develop with the Alpha? How 
different is the core?

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.

The feeling I get from documents such as the Wait_in_Wait page is 
that R3 is still being prototyped.

Yes ...

Wait .. wait ... wait ..

me too ;-)

sh

ou

should that not be resolved by usage of different tasks ?

doesn't look like we have multithreading

it"s what i would say, thanks

differents threads

... separate timers ...

in fact there sou

argh.. what with my keyboard...

Carl is updating the wiki, but who is coding ?

One of our .net programmers showed me something kinda cool yesterday. 
They were "child" windows of a main window that would align together 
if you brought one within a certain proximity to the other. From 
that point the top bar from either window moves both. Of course it's 
not as cool as having draggable screens like we did in '86 but...

some mac programs does something similar. I know the technique.

WinAmp does this, yes?

yes

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.

idealy, [to integer! to binary! my-int] should return my-int, it's 
not the case currently

You don't need to "skip tail" :
>> debase/base to-hex 123456 16
== #{0001E240}

I agree that R3 should provide a better way to achieve that.

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

Btw, you can also use a struct! value to convert integer to binary.

At least in R2.

in know the trick with struct!, but my tests show that it's not faster 
than using [debase to-hex]

for info, to convert an integer to a binary with struct! , we do.
>>str: make struct! [int [integer!]] [0]
then
>>str/int: 150
>> third s 
== #{XXXXXXXX}
which is the integer in little endian format

i don't know why but  it seems that it's not faster than the [debase 
to-hex] method

Observe progress of internal releases here:

http://www.rebol.net/wiki/R3_Releases

... noses pressed against  window ...

noses pressed against gobs

gobs in the noses pressed against the glass in front of the gobs

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

Is orientation of group vs panel fixed already? Btw - that you very 
much for update!

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.

Simply put - when you look into RebGUI widget directory, you can 
see all widgets, which imediatelly make sense for user - when you 
compare it with the list provided, the difference is very obvious 
- every one single self-descriptory, usable, vs. chaos ...

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.

As for MAX-SIZE - what does Carl thinks conceptually about your concerns?