World: r3wp

s

sorry

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

working a bit on date styles.

view [year-calendar 2008]

gives: http://rebol.hmkdesign.dk/files/r3/gui/153.png

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

http://rebol.hmkdesign.dk/files/r3/gui/007.mov<-- older video of 
slider styles here. same area as shown in the blog.

Looks good Henrik.  I don't care much for the  orange.  Maybe a yellow 
would be nicer.  So square-ish - maybe round the corners on the month 
panes.

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

Yeah I figured the round stuff would be more difficult.

Will it be possible to use bitmaps as in R2? For example extend effect 
was very useful. I really don't think, that we must draw everything.

I haven't used effects at all yet, but I think it's possible.

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